Apple //c für Robotik nutzen?

  • Guten Tag,


    habe mich hier (ganz frisch) registriert, weil ich einen Apple IIc nach vielen Jahren Rumstehen aktivieren möchte, um damit eine kleine Eisenbahnanlage zu steuern. Das ist im Prinzip eine blöde Idee, weil diese Schüssel gar keine RS232 oder ähnlich gut beschriebene Schnittstelle hat, mit der das kein Problem wäre.


    Also muss wohl der Druckeranschluss herhalten. Es entzieht sich aber schon völlig meiner Kenntnis, ob dieser Port überhaupt eingehende Signale ermöglicht. Ein paar Rückmeldungen sind schon erforderlich, damit ein Programm, das es auch erst noch zu schreiben gilt, vernünftige Entscheidungen über den Fahrbetrieb fällen kann.


    Kann mir jemand helfen, den Druckerport ausreichend zu verstehen, damit ich geeignete Relaiskarten bauen kann?


    Die zu steuernde Anlage hat nur ein Innenoval und ein damit in beiden Richtungen verbundenes Außenoval und eine Diagonalverbindung im Innenoval, also auch die Möglichkeit, einen Zug zu wenden. Von dieser Diagonale gehen noch zwei Abstellgleise weg. Also zwar nicht so simpel wie nur zwei Ovale, aber es würde im ersten Schritt genügen, wenn der IIc nur die zwei Ovale kollisionsfrei steuern kann.


    Die Fahrzeuge laufen mit 9V DC (Märklin Miniclub, Spur Z).


    Wenn dieses Projekt jemanden reizt, bitte ich um Kontaktaufnahme, denn im Februar soll das Ergebnis bereits in Rotenfels bei Gaggenau im Unimogmuseum vorgeführt werden.


    Bestes aus Berlin

    __________________
    Bestes aus Berlin


  • Danke für den Hinweis,
    zunächst habe ich mal eine Beschreibung der 'seriellen Schnittstelle des //c gefunden. Bei asimov gibt es dazu noch diesen Link:
    apple ii super serial card. Ob das eine in den //c onboard eingebaute Karte beschreibt, kann ich nicht beurteilen. Steckkarten gibt es ja beim //c nicht.
    Jetzt fehlt mir noch ein Gerät, das den Rückmeldezustand der Anlage in "Data In (RxD)" verwandelt und die "Data Out (TxD) in Signale formt, mit denen ich Relais ansprechen kann. Möglicherweise gibt es so etwas fertig zu kaufen oder man kann es sich z.B. aus einem Arduino bauen. Damit verlasse ich allerdings mein Fachgebiet zu 100%. Ich könnte höchstens eine Platine nach Bauplan löten.


    Also, nicht, dass das falsch verstanden wird. Ich will keineswegs digitalisierte Loks steuern. Mir genügt es völlig, Streckenabschnitte ein - und auszuschalten. Es gibt zwar Decoder für Z-Lokomotiven, aber ich habe nicht vor, sie zu digitalisieren. Es soll vielmehr so funktionieren, wie man es 1983 im Hausgebrauch gemacht hätte. Von Lokdekodern hat man damals noch geträumt. Viel wichtiger ist sowieso, dass die Strecke überwacht wird.


    Bin für jeden weiterführenden Hinweis dankbar.

    __________________
    Bestes aus Berlin

    Einmal editiert, zuletzt von Symbiont ()

  • Zu den "Rücksignalen" von den Loks kann ich nichts sagen, aber der //c hat in der Tat eine Super Serial Card eingebaut - von daher stehen die Weichen computerseitig auf "grün" :)

    Loading Integer BASIC into Language Card

  • Na das ist ja schon mal pfundig. Damit müsste es zumindest theoretisch möglich sein, eingehende und ausgehende Signale zu programmieren. Meine Programmierkünste siedle ich bei 0 an. Ohne ein Hilfsprogramm, das mir die Umsetzung auf den Serial Port übernimmt, kann ich einpacken. In BASIC gibt es ja wohl kaum vordefinierte Befehle, wie man bestimmte "Begriffe" über den Serial Port jagt oder täusche ich mich da?

    __________________
    Bestes aus Berlin

  • Alle IIc's haben eine RS232 kompatible Schnittstelle (Modem-Port) fest eingebaut, wie hier schon erwähnt wurde, szsg. eine SSC. Mit einem passenden Level Shifter kannst du so auch einen Arduino ansteuern, die Ein-/Ausgabe steuerst du mittels Applesoft Basic direkt an, sollte also alles funktionieren. Die Grundlagen sind wirklich gut dokumentiert, das Handbuch von der SSC ist auch schonmal ein guter Anfang :) ... Die Frage ist ob der Aufwand lohnt, obwohl ich den Nostalgiefaktor durchaus teile und verstehe, aber mit "nur" einem Arduino fährst du da glaube ich besser, der IIc wäre da eigentlich nur zusätzlicher Ballast.

  • Hallo x5900
    Dass der Modem-Port quasi eine RS232-Schnittstelle ist, wusste ich nicht. Danke für den Tipp. Dann müsste ggfs. ein Adapterkabel ausreichen, falls ich ein externes Gerät finde, das die Befehle in Schaltzustände übersetzen kann und Streckenzustände zu codieren versteht. So ein Gerät braucht im Prinzip jeder Roboter. Wie nennt man das? Bin ich da mit dem Begriff DA-Wandler bzw. AD-Wandler auf dem Holzweg?

    __________________
    Bestes aus Berlin

    • Offizieller Beitrag

    Hallo


    Das ist schon eine richtige RS232 Schnittstelle, nicht nur "quasi". Das Gerät vor Deiner Anlage wäre mehr als ein AD/DA Wandler. Der würde nur aus Spannungs- oder Schaltzuständen digitale Signale machen. Du brauchst ein Interface an der RS232 Schnittstelle. das ein kleines serielles Protokoll versteht und (mal rein hypothetisch formuliert) weiss, dass der Empfang von "10101010" bedeutet " Weiche an Anschluss A des Geräts jetzt nach links" und "10101011" dann "nach rechts" bedeutet.


    Dafür gibt's in der Modellbahnszene bestimmt Geräte oder Bauanleitungen. Wenn das Protokoll halbwegs dokumentiert ist, sollte sich in AppleSoft BASIC die Steuerung schon programmieren lassen.


    Übrigens: Andere machen sowas auch, schau mal hier: http://www.gerhards-moba.de/technik/digitalsysteme/


    Gruss- Georg B. aus H.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • Hi,
    vielen Dank für die Tipps soweit.


    Irgendwie finde ich nicht die geeigneten Relaiskarten, mit denen man a) Fahrstraßen auf der Strecke schalten kann (Velleman) und b) Rückmeldung über besetzte Gleise an den Rechner schicken kann. Bei den aktuell erhältlichen Relaiskarten habe ich Zweifel, dass sie sich von einem 8-bit-Bus steuern lassen. Schlimmer ist es noch beim Rückmeldeproblem. Wenn ich nach Encoder suche, dann kommen ausschließlich Treffer über Geräte, die mechanische Stellungen in elektronische Messbegriffe umsetzen. Mir würde es völlig genügen, wenn ein Potenzial von 5V an einem Fühler-Pin zu einem 8-bit-Rückmeldebegriff an die RS232 umgebaut würde. So etwas muss es doch z.B. als Temperaturfühler o.ä. früher schon gegeben haben. Es erscheint mir äußerst sonderbar, eine Relaiskarte zu bauen, die nicht von vornherein eine Wirkkontrolle als Eingang besitzt. Wozu soll die denn gut sein? Soll der Rechner wie ein Blödmann agieren? Damit ist doch nie etwas geholfen.

    __________________
    Bestes aus Berlin

    • Offizieller Beitrag

    Ein Rechner mit frei programmierbaren I/O Ports wäre für Dein Vorhaben sicher besser geeignet.
    Sämtliche Commodore 8-Bit Rechner haben sowas, nennt sich dabei User-Port.
    Das ganze kann man bitweise als Eingang oder Ausgang definieren.
    Sowas über RS-232 abzuwickeln erscheint mir viel zu umständlich.
    Die RS-232 I/O-Hardware, die Dir fehlt, wäre im Prinzip ein eigenständiger Rechner,
    da die seriell empfangenen Befehle erstmal verarbeitet werden müssen.
    Selbiges gilt für die zurückzumeldenen Zustände.
    Wenn Du nicht irgendwas fertiges findest, was mit genügend I/O und einem einfach abzufrühstückendem Protokoll daherkommt, ist am Ende der Aufwand dafür größer, als für die eigentliche Steuerungsaufgabe.

  • Hier ist noch eine Idee:


    1. RS232-Port als I2C-Schnittstelle "missbrauchen" (Link1, Link2)
    2. An die I2C-Schnittstelle handelsübliche IO-Umsetzer anschließen, z.B. PCF8574 oder PCF8574A


    Auf diese Art und Weise sind ganz einfach 128 Ein- und/oder Ausgänge zu realisieren. Zu klären wäre allerdings noch, ob der IIc seinen seriellen Port auch in einer Weise programmieren lässt, damit die Umsetzung auf I2C funktioniert (z.B. einzelne bits schieben). Dafür könnte man dann noch ein LCD anschließen, eine Uhr, ein Gyroskop, Luftdrucksensoren, EEPROMS ... 8o


    Ciao, Michael

    :tuschel: Suche: BeBox, Commodore 900, KIM-1 :tuschel:

  • Danke für eure Antworten,
    Auf den I2C-Bus brauche ich nicht auszuweichen, nur, damit ich mehr pins erhalte. Mir genügen 8 Relais vollkommen, um die wenigen Fahrstraßen zu regeln, die diese Primitivanlage überhaupt ermöglicht. Das soll gar keine dolle Anlage werden, weil sie ins Regal im Arbeitszimmer passen muss und nur drei Züge zur Verfügung stehen. Was interessant erscheint, ist die Möglichkeit der Rückmeldung. Aber da sehe ich noch nicht, warum das unbedingt über den I2C gehen muss. Ich hoffe in der Tat, entsprechende externe Karten zu finden.
    Einen Commodore extra anzuschaffen und den IIc zu verhökern, kommt mir jetzt, wo ich mich mit dem IIc vertraut gemacht habe, nicht mehr in den Sinn. Mich wundert nur, dass es keine kompletten Robotik-Experimentierplatinen gibt, die die RS232 vollständig ausreizen. Das mag mit dem Programmieraufwand zusammenhängen, weil ein 8-bit-Programm naturgemäß nicht sehr leistungsfähig ist. Dennoch ist die Anforderung sicher nicht neu, dass man ein Steuersignal sendet und dann eine Quittierung zurück an den Rechner senden will. Die RS232 scheint mir dafür nicht der Engpass zu sein. Für die 24 Begriffe, die die hardware senden bzw. empfangen können muss, sehe ich auch nicht, dass ein eigener Prozessor inkl. Programmierung der externen Hardware benötigt wird. Das sollte sich doch noch mit herkömmlichen IC abbilden lassen. Das ist aber nur eine Vermutung. Bauen könnte ich das nicht selbst. Deshalb hab ich jetzt mal beim AK Modul Bus angefragt. Bin sehr gespannt, ob die da was machen können. Etwas abseits des Projektziels ist es, sich neue hardware bauen zu lassen. Ich nehme aber an, dass sie dabei auf Bauteile zurückgreifen, die es anno 1985 schon gab.


    Was die Programmierung betrifft, bin ich noch nicht in Applesoft Basic eingearbeitet :nixwiss: . Wenn das jemand deutlich schneller zustande bringt als ich, dann bin ich da auch nicht für Unterstützung böse :anbet: .

    __________________
    Bestes aus Berlin

  • Hallo Stefan,
    das Problem dieser verfügbaren externen Karten ist der fehlende Zusammenhang zwischen Aktion und Rückmeldung. Die RS232 wäre prädestiniert, einen Befehl in die Peripherie zu schicken und unter GLEICHER ADRESSE ggfs. zeitlich versetzt eine Rückmeldung zu erhalten. Das hat man früher durch mechanisches Blocken von Stellhebeln realisiert. Die Aufhebung einerStreckenfreigabe MUSSTE vom Fahrdienst quittiert werden.
    So ähnlich stelle ich mir die RS232-Kommunikation auch vor: Bevor nicht eine Rückmeldung erfolgt ist, stellt sich der Aktor gegenüber neuen Befehlen tot, es sei denn, alle gestellten Fahrstraßen verlieren gleichzeitig per Reset ihre Gültigkeit.
    Die einzige Steuerung, die im Prinzip so tickt, ist die von GAHLER+RINGSTMEIER. Hier weiß der Rechner definitiv, was gespielt wird, weil er sich der Streckenzustände systematisch vergewissert. Das überlässt man nicht dem Prozessor, der denkt, er wisse, was aufgrund seiner Aktivitäten los sein müsste.
    Wenn ich mir die erhältlichen Karten angucke, dann müsste ich aber genau so (dusselig) programmieren, weil der Rechner erst mühselig erklärt bekommen muss, welche Rückmeldung zu welcher Aktion gehört. Diesen Teil könnte auf ganz primitive Weise schon die hardware abdecken. Man könnte sich hunderte überflüssige Programmzeilen ersparen.

    __________________
    Bestes aus Berlin

  • Gerade sehe ich eine Nachricht, die ich vom AK Modul Bus erhalten habe. Darin wird mir anstelle des SERAI812 das AD210 empfohlen, das hierbeschrieben ist.


    Das sendet die Rückmeldedaten als Byte-Werte über die serielle Schnittstelle.
    Allerdings nur 2 Analog-Eingänge und mit 38400 Baud. Das dürfte den IIc vmtl. überfordern.

    Zusätzlich wird mir bei simplem Abfragen von Betriebszuständen (An/Aus) ein digitales Interface wie das RD30 vorgeschlagen, das insgesamt 30 digitale Ein- und Ausgänge hat, wovon 24 Masse-bezogen sind und 6 über Optokoppler komplett galvanisch getrennt sind. Eine Spannung ab etwa 3V am Eingang ergibt eine “1”, wobei die Spannung bis 24V betragen darf. Das wäre für die 9V-DC-Technologie der Märklin-Miniclub-Anlage optimal.

    Der Zustand der Eingänge wird, sobald ein Eingang seinen Zustand ändert, über die serielle Schnittstelle in Form von 4 Byte-Werten ausgegeben, wobei auch per Steuerbytes jeder einzelne Eingang separat abgefragt werden kann. Die Kommunikation erfolgt mit 9600 Baud, 8 Bits, kein Parity, 1 Stoppbit (9600 8N1). Das klingt besser, aber ob der IIc damit klarkommt und wie ich demzufolge programmieren muss, habe ich noch nicht verstanden. Immerhin wird bei der Beschreibung auf eine Anwendung als Modellbahnsteuerung verwiesen. Das werde ich jetzt erst mal studieren und dann weitersehen.

    __________________
    Bestes aus Berlin

  • Nach weiterer Recherche bin ich über zwei RS232-kompatible Interfaces vom AK Modul-Bus KainkaLabsgestolpert, die mir für das Modellbahnprojekt ausreichen würden:


    Relaiskarte für Fahrstraßenschaltung: RIST mit 8 Relais, die auch Netzspannung schalten können.


    Encoderkarte für Gleisbesetztmeldung: RD30 mit 30 Eingängen.


    Leider nicht gerade billig, aber sehr gut dokumentiert, was für mich als Informatik-Greenhorn wichtig ist.


    Spannend ist auch der link beim RD30, wie Herr Hellkötter dieses bereits zur Steuerung einer Modellbahn eingesetzt hat: ELEXS


    Ich weiß, dass solche modernen Komponenten nicht so ganz stilecht sind am IIc und dass es Probleme mit den Baudraten geben kann. Aber in der Kürze der Zeit habe ich noch nichts Besseres gefunden. Sehr gerne würde ich natürlich antike Karten verwenden, die den gleichen Zweck erfüllen. Allerdings muss ich dann auch wissen, wie sie per Programm angesprochen werden müssen. Ohne Doku wird das ein zu aufwändiges Glücksspiel.

    __________________
    Bestes aus Berlin

  • Hallo Kollegens,


    ein Kabel und einen USB-Adapter habe ich inzwischen, wie auch die angefragten System-Dienstprogramme. Vielen herzlichen Dank sag ich mal, ohne Namen zu nennen.
    Jetzt kann ich theoretisch, vielleicht sogar praktisch, Daten auf meinen IIc übertragen. Allerdings habe ich Zweifel, dass das schon das Problem löst, wie ich den RS232 über die Serial Card ansteuern kann.


    Inzwischen nenne ich eine Velleman Relaiskarte K8056 mein eigen, die ich mit 2400 Baud, ohne Parität, 8 Databits und einem Stopbit anquatschen könnte. Die spannende Frage ist, ob das die Super Serial Card im IIc kann und ob es im Anleitungsheft dieser Karte beschrieben ist, bzw. woher sonst ich erfahre, wie ein Programm mit der Serial card in Kontakt treten muss. Ist das Finnigan-Buch da aufschlussreich?


    Velleman tut sich natürlich leicht, win95 und höher als Kompatibilitätsangabe zu geben. Dafür haben die ja sogar selbst ein Programm zum Download, für das sie auch den Quellcode freigeben. Ich will es aber partout mit dem IIc hinkriegen, weil der auf der Ausstellung Ende Februar richtig antik wirkt.


    Kann mir da jemand mit Recherchen in seiner Literatur helfen?

    __________________
    Bestes aus Berlin

  • Hallo,


    Ich denke die Karte mit dem //c anzusteuern soll kein großes Problem sein. Im Handbuch von der SSC Karte kannst du eine Liste der Befehle und ein Beispielprogramm finden, das dir weiterhelfen kann.
    https://archive.org/stream/a2_…_Manual#page/n23/mode/1up
    Einfach die passende Parameter eintragen. Wahrscheinlich wirst du kein Terminal Modus aktivieren wollen sonder einfach die Befehle von deinem Programm gesteuert schicken. Viel Erfolg!

  • Hallo inmitten der närrischen Tage,


    In Berlin merkt man zwar nichts davon, aber wenn man noch woanders Verwandtschaft hat...


    Inzwischen habe ich den USB-RS232 Converter, die K8056 Relaiskarte von Velleman und einen völlig intakten und sogar gereinigten Apple IIc inkl. seriellem Kabel am Start. Der Rechner hat sämtliche Diagnoseprogramme anstandslos überstanden.


    Wozu ich ADTPro eigentlich brauche, verstehe ich im Nachhinein nicht. Das Programm ist primitiv und ob es funktioniert oder nicht, ist gar nicht leicht festzustellen. Ich bediene es exakt nach Anleitung inkl. dem nach Anleitung selbst gebauten Kabel, aber ich kann nicht erkennen, ob überhaupt etwas am Apple ankommt. Es bleibt auch offen, ob man sich den Converter ruiniert, wenn man die Pins im Stecker kurzschließt, wie auf der ADTPro-Seite empfohlen. Wozu soll ich PRODOS auf den IIc übertragen, wenn ich eine funktionsfähige Disk dafür habe? Was kann der ADTPro Client auf dem Apple? Darüber habe ich genau gar keine Information gefunden. Da hat wohl einer die Lust am Dokumentieren auf halber Strecke verloren.


    Meine naive Vorstellung von bootstrapping war, dass ich über ADTPro quasi ein auf einem heute aktuellen Rechner geschriebenes Programm für den Apple compilieren und auf eine Floppy im Zielrechner schreiben kann. Pustekuchen, wie es aussieht.


    Mit der Velleman-Bausatz-Karte bin ich auch nicht wirklich glücklich. OK, sie war billiger, als die Karte von Kainka Labs und man versprach dort ebenfalls, ein Windows-kompatibles Bedienprogramm via RS232 zu haben.


    Dann kam die Ernüchterung. Das Demoprogramm zum download bei Velleman kann nur den COM1 oder COM2 bedienen. Beide sind an meinem aktuellen Arbeitsrechner schon besetzt. Wegen einer Pillepalle-Anwendung werde ich nicht anfangen, die Funktionsfähigkeit meines wichtigsten Arbeitsgeräts zu riskieren. Warum ist das Demo-Programm zu doof, höhere COM-Ports zu bedienen? Im Velleman-Forum heißt es dazu, dass das Programm so alt sei, dass man sich auf mehr COM-Ports seinerzeit nicht eingestellt hat. Das haben sie schon 2006 geschrieben. Eh klar, dass man bis heute keinerlei Fortschritt braucht, weil man das ja getrost dem Kunden überlassen kann. Solche Hersteller hab ich ja gefressen. Abkassieren, leere Versprechen machen, aber nichts leisten wollen. Wäre das in meiner Firma vorgekommen, hätte ich gleich mal einen rausgeschmissen. Solche tüchtigen Mitarbeiter braucht man nirgends! X(


    Jetzt stehe ich also ohne Programm zum testen der Karte am COM5 da und habe noch nie selbst programmiert. Es kommt nun also der schwere Teil, obwohl die Aufbauanleitung ab Kapitel 20 (Seite 10) schon ein paar Hinweise gibt:
    Velleman Anleitung


    Dort steht:
    To execute a command, the correct sequence needs to be sent to the K8056.
    Basically, a command sequence looks like this (Böhmische Dörfer!):
    1. CHR$(13)
    2. card address (1..255)
    3. instruction
    4. address (1..255) or relay# ('1'..'9' ASCII)
    5. checksum (2-complement of the
    sum of the 4 previous bytes + 1)
    3) Instructions :
    'E' :
    Emergency stop all cards, regardless
    of address. Carefull, relays turned
    on by open collector inputs will not be turned off by this command).
    'D' :
    Display address. All cards show their current address in a binary fashion.
    (LD1 : MSB , LD8 : LSB)
    'S' :
    Set a relay. 'S'-instruction should be followed by relay # '1' to '8'.
    ('9' sets all relays at once).
    'C' :
    Clear a relay. 'C'-instruction should be followed by a relay # '1' to '8'.
    ('9' clears all relays at once.)
    'T' :
    Toggle a relay. 'T'-instruction should be followed by a relay # '1' to '8'.


    'A' :
    Change the current address of a card.
    'A'-instruction should be followed by the new address (1..255)


    'F' :
    Force all cards to address 1 (default)


    'B' :
    Send a byte. Allows to control the status of all relays in one instruction, by
    sending a byte containing the relay status for each relay. (MSB : relay1, LSB : relay8)


    4. Program example :
    see Velleman site (www.velleman.be)


    Für mich ist das so aufschlussreich wie ein chinesisches Telefonbuch. Wie das noch so zu verpacken ist, dass die Super Serial Card es tatsächlich über den TxD sendet, ist in meinen Augen ein Wunder. Ich bin in der von cybernesto genannten SSC-Anleitung ausgestiegen, als es um die Speicheradressierung ging. Mangels jeglicher Programmiererfahrung kann das nur in die Hose gehen. Ich verstehe nicht so ganz, warum man sich auf so einem Detailniveau bewegen muss, wenn doch der Rechner mir dienen soll und nicht umgekehrt. Wenn ich mir die Applesoft BASIC Programmieranleitung dazu angucke, wird mir erst richtig schlecht. :fpa:


    Da lobe ich lieber einen Fuffi aus, den sich derjenige mit ein paar Programmzeilen schnell verdienen kann, der das schon mal gemacht hat. :thumbup:
    Ich kann gerne im Gegenzug anbieten, ein paar Platinen zu löten. Das kann ich gut und zuverlässig. 8-)

    __________________
    Bestes aus Berlin

    • Offizieller Beitrag


    Wozu ich ADTPro eigentlich brauche, verstehe ich im Nachhinein nicht. Das Programm ist primitiv und ob es funktioniert oder nicht, ist gar nicht leicht festzustellen.


    Hier läuft ADTPro an einem kleinen PC mit USB/Seriell Konverter und meinem Apple //c ganz hervorragend. Es wird auch vielfach von Apple II Nutzern weltweit genutzt- das Problem muss bei Dir liegen! Entweder ist das Kabel falsch oder der USB Konverter taugt nix- das ist leider nicht selten.


    Gruss- Georg B. aus N.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • Schön, wenn dieses ADTPro über den USB-RS232 Converter bei euch irgendwas macht. Aber was ist der Zweck? Ich erkenne im GUI nur, dass ich PRODOS und einen vermeintlichen ADTPro Client auf den Apple schieben kann. Und was hab ich davon? Das brauche ich doch gar nicht. Ich leg die PRODOS Floppy ein und starte und gut ist. Mehr kann ich mit ADTPro auch nicht erreichen, wenn ich das richtig interpretiere. Das enttäuscht mich sehr.


    Meine Erwartungen waren deutlich höher, wenn ich schon eine hardware-Lösung zwischen neuer und alter Welt habe. Ich hätte jetzt erwartet, dass sich ganz neue Welten auftun, weil ich quasi jeden Quellcode aus dem gesamten Internet-Universum auf den Apple laden kann, sofern er nicht größer als 128k ist. Ich erkenne aber nicht, wie das mit ADTPro gehen könnte. Ob schnell oder langsam, ist mir dabei völlig schnuppe. Universell soll es sein. :evil:

    __________________
    Bestes aus Berlin

    • Offizieller Beitrag

    Hmm... mal die Doku gelesen?


    wenn ADTPro ersteinmal läuft, hast Du Zugriff auf das freigegebene Verzeichnis im PC und kannst heruntergeladene Diskimages z.B. im DSK Format auf echte Disks schreiben. Das hast Du davon.


    Gruss- Georg B. aus N.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • Hallo Georg,


    danke für den Tipp. Diesen Teil der Doku hatte ich tatsächlich noch nicht gesehen. Unter einem Diskimage verstehen wir ein Programm mit Bootsequenz, richtig? Der variable Teil daran ist das Programm selbst, während ADTPro die Bootsequenz selbständig hinzufügt oder muss das bereits auf dem PC gemeinsam compiliert werden?


    Wenn es mir also tatsächlich gelingen sollte, ein Basic-Programm zur Steuerung der Relaiskarte bauen zu lassen, dann müsste daraus ja noch ein Diskimage werden. Wie und wo geschieht das?

    __________________
    Bestes aus Berlin

  • Moinmoin.
    Ein Diskimage ist eine Datei, die dem Rechner einen Datenträger vorgaukelt.
    ADTPro (kenne ich nicht, macht aber nichts) bietet dir die Möglichkeit, Diskimages (hier: virtuelle Floppies) von einem anderen Rechner zu öffnen, damit du den Inhalt (hier: Dateien auf der virtuellen Floppy) dieser Images auf eine richtige Diskette kopieren kannst.


    Ich denke, du solltest mal einen Crash-Kurs in Sachen Emulation machen, damit du nicht an deinen Gesprächspartnern vorbeihörst und -redest.
    Wäre für dich vermutlich effizienter, und du würdest dich nicht herumärgern, weil irgendetwas nicht so klappt, wie du es dir gedacht hast.

    • Offizieller Beitrag

    Unter einem Diskimage verstehen wir ein Programm mit Bootsequenz, richtig?


    Nein, falsch.


    Ein Diskimage ist eine 1:1 Kopie einer echten Diskette in einer Datei. Diskimages dienen dazu, echte Disketten auf anderen Rechnern abzulegen/ zu archivieren, per Netz transportierbar zu machen und wieder echte Disks zu erzeugen. Das ist nötig, weil eine Diskette ja nicht nur die Dateien selbst, sondern auch ein Dateisystem, ggfs. einen Bootblock und (auch beliebt) vielleicht Kopierschutzinfos von früher enthält. Dateiweises Kopieren würde diese Informationen nicht retten, Diskimages können das.


    ADTPro (kenne ich nicht, macht aber nichts)


    Stell Dir ADTPro auf dem Apple II (Client) einfach wie Diskcopy auf dem Mac vor. Unterschied: Es gibt eine Java-basierte Serverkomponente (Windows, Linux, Mac), mit der ein Client vom Apple aus kommuniziert. Das geht per serieller Schnittstelle, Ethernet (Uthernet-Karte) oder (wacklig) per Soundkarte und Kassettenport am Apple. Der Server gibt ein Verzeichnis frei, das der Client sehen kann und Images dort kann der Client dann auf Disks schreiben. Ausserdem kann man mittels eines anderen Clients auch ein Verzeichnis auf dem Server als Diskettenlaufwerk auf dem Apple einblenden. Der ADTPro-Server kann mittels Eingabeumlenkung seinen Client per Verbindung auch auf dem Apple "eintippen" und dann ein Betriebssystemimage übertragen. Das löst das Henne/Ei Problem (wie übertrage ich ein Betriebssystemimage, wenn ich noch keine Betriebssystemdiskette habe). Darauf hat symbiont oben abgehoben- nur ist das eben nur die initiale Funktion von ADTPro und nicht die einzige.


    Gruss- Georg B. aus N.

    Denn Feindschaft wird durch Feindschaft nimmermehr gestillt; Versöhnlichkeit schafft Ruh’ – ein Satz, der immer gilt. Man denkt oft nicht daran, sich selbst zurückzuhalten; Wer aber daran denkt, der lässt den Zorn erkalten. Sprüche von Buddha, aus dem ‹Dhammapada›.


    Mein Netz: Acorn | Atari | Milan | Amiga | Apple //e und IIGS | Macintosh | SUN Sparc | NeXT |SGI | IBM RS/6000 | DEC Vaxstation und Decstation| Raspberry Pi | PCs mit OS/2, BeOS, Linux, AROS, Windows, BSD | Stand-alone: Apple //c und III | Commodore 128D | Sinclair QL | Amstrad | PDAs

  • Vielen Dank für die Antworten. Natürlich ist es mühsam, mich in so kleinen Schritten an mein Ziel anzunähern. Mein Interesse gilt aber nicht in erster Linie den Computern, sondern dem Nutzen, den sie abwerfen. Wenn ich mich zum Gefangenen von Chiffrierungen hätte machen wollen, dann hätte ich die Wahl gehabt, als es darum ging, ein Studium zu wählen. Mich an die Bedingungen anzupassen, die mir Maschinen stellen, halte ich nur bedingt aus. Es nervt mich ganz ungeheuer, warum nicht schon immer alles daran gesetzt wurde, solche Situationen zu vermeiden. Ich pfeffere schon mal eine elektronische Zeitschaltuhr in die Tonne, wenn ich sie nicht sofort begreife. Für solche Drecksprodukte hab ich keine Zeit.
    Selbst höhere Programmiersprachen erscheinen mir immer noch viel zu kleinkariert. Man kann damit nicht annähernd den Erfolg haben, den man sich wünscht, weil der Teufel viel zu viele Gelegenheiten hat, sich in Details zu verstecken. Ich mache auf solche Lücken den ganzen Tag schon Jagd und habe es dabei wenigstens mit Menschen zu tun, denen man einiges an Fehlern nachsehen muss. Umso gnadenloser bin ich bei Maschinen. Die haben sich gefälligst nicht so doof anzustellen, schließlich haben sie keine dummen Handlungsmotive - es sei denn sie werden ihnen einprogrammiert. Sei es aus Nachlässigkeit oder aus Unwissenheit. Eine intelligente Maschine hat gefälligst ihre ganze Kraft darauf zu verwenden, sich funktional zu erhalten, solange es nur irgendwie geht. Bei Baumaschinen und Kriegsgerät scheint das schlicht durch robuste Konstruktion zu funktionieren. Bei Autos und Flugzeugen hängen immerhin noch Menschenleben davon ab. Aber alles, was darunter rangiert, ist zumeist so grottendoof, dass der Fehlerfall wahrscheinlicher ist, als die reibungslose Funktionsweise. Solche Technik kann mich nicht begeistern. Ich beuge mich deshalb nur soweit herab, wie es für ein paar bescheidene Ziele unbedingt notwendig ist. Man bedenke, dass ich nur 8 Relais schalten möchte. Der Aufwand steht schon jetzt in gar keinem wirtschaftlichen Verhältnis zum Nutzen. Und jetzt soll ich mich noch tiefer in Programmierkenntnisse stürzen? Das finde ich nicht attraktiv. Ich werde irgendwen bestechen, der das für mich macht. Ich hab z.B. noch ein NetGear ReadyNAS rumstehen, das ich tauschen könnte gegen den Applesoft BASIC-Code für die Velleman-Relaiskarte. Klingt das nicht nach einem Deal? Einen Kollegen hab ich heute schon fast rumgekriegt damit.

    __________________
    Bestes aus Berlin

  • Ich verstehe deine Motivation nicht ganz. Einerseits willst Du eine selbsterklärende Maschine, die es dir einfach ermöglicht acht banale Relais
    anzusteuern, andererseits beginnst Du den Thread damit, dass Du egrn mit einem Aplle IIc Deine Eisenbahn steuern möchtest, obwohl es dir
    klar ist, dass das wohl nicht der geschickteste Weg ist. (Hat nicht mal RS232).
    Meine Motivation mich mit alten Rechner auseinanderzusetzen ist gerade herauszufinden, wie man etwas bestimmtes (sinnvoll oder nicht)
    damit erreichen kann. Für mich ist dabei der Weg das Ziel und das Gelingen die Belohnung. Wenn ich es einfach nur nutzen möchte, kann
    ich auch einen Arduino nehmen oder es gleich fertig kaufen.
    In der Zeit der 8-Bitterwar m.E. die Benutzerfreundlichkeit einfach noch zu aufwändig. Heutige PCs und Smartphone "verbraten" sicher einen
    Großteil ihrer (vergleichsweise) immensen Rechenleistung eben für diese Benutzerfreundlichkeit.
    Ich will dich nicht kritisieren, nur verstehe ich deinen Anspruch an ein so betagtes System nicht ganz.

    Das Genie beherrscht das Chaos

  • Hallo ChaosRom,


    Das Motiv ist eine Veranstaltung für historische Tischeisenbahnen, an der ich als Sammler alten Spielzeugs regelmäßig teilnehme. Der Apple IIc ist ein schön antikes Teil, das zum Thema der Veranstaltung passt, wenn es gelingt, eine Eisenbahn damit zu steuern. Dass das möglich sein muss, war klar, nachdem erkennbar wurde, dass der Modemport sehr wohl alles kann, was dazu notwendig ist. Mich wundert nur, dass das anscheinend noch nie jemand gebaut hat. Da steckt schon der zweite Teil der Motivation drin: Dinge tun, die noch keiner gemacht hat. Das hat bisher auch alles viel Spaß gemacht. Aber jetzt an der Software zu scheitern, weil es keine vernünftigen Routinen gibt, mit denen man ein bisschen ASCII aus dem COM2 pusten kann, das enttäuscht mich schon. Ich wäre der Ansicht gewesen, dass es da eine ganze Bibliothek von Modulen geben müsste, mit denen man sich das flott zusammenklickt. Schließlich gibt es diesen Rechner und Applesoft Basic schon seit über 30 Jahren.


    Aber alles, was ich auffinden kann, ist, was ich hier schon geschrieben habe. Dazu kommt noch die folgende Litanei, mit der ich nichts anfangen kann. Am 26.02. beginnt diese Ausstellung. Von 11.02. bis 19.02. muss ich auf Dienstreise. Also sehe ich keine Möglichkeit, wie ich in so kurzer Zeit aus diesen Trümmern ein funktionsfähiges Programm zimmern soll. Ich brauche wohlgemerkt keinen handshake, sondern lediglich ein paar Buchstaben, die mit 2400 Baud als 8 Databits, 1 Stopbit ohne Parität aus dem TxD rauspurzeln. Wenn das jetzt mal so einfach wäre. Ich steh jedenfalls wie der Ochs vorm Berg.


    Apple II Serial Port Firmware Interface Commands


    also Pascal 1.1 Firmware Protocol serial interface commands
    and Apple II Super Serial Card commands


    ref. The Apple IIgs Firmware Reference
    The Apple IIc Technical Reference Manual
    The Apple IIe Technical Reference Manual



    I. The Command Character


    The normal command character is ...


    Control-I (ASCII $09) in printer mode
    Control-A (ASCII $01) in communications mode.



    You can change the command character. For example, to change the
    Printer mode command character from Control-I to another
    character, say, Control-W, send ...


    Control-I Control-W.


    To change back, send ...


    Control-W Control-I.


    No return character is required after either of these commands.



    In case you want to send the current command character through the
    output stream, the Apple Super Serial Card (or "SSC") allows you to do
    it by sending the character twice in a row. The built-in serial ports
    do not allow this; the character will not be output.


    To send the command character through a built-in serial port, you must
    temporarily change to an alternate command character. For example, if
    the current command character is Control-I and you want to send a
    Control-I out the serial port, then send


    Control-I Control-A Control-I Control-A Control-I


    The first two characters change the command character to a Control-A.
    The third character is the Control-I you wanted to send. The fourth and
    fifth characters restore the command character to Control-I again.


    An alternative is to disable all command-character parsing by using
    the Z command.




    II. Command Strings


    A command string is a letter sometimes with a number prefix and sometimes
    with an E or a D suffix (for "enable" or "disable). Command strings select
    the option to be used; for instance, they may change the baud rate, select
    the data format, and set the parity.


    To generate a command in Applesoft BASIC, enter
    PRINT CHR$ ( 9); "command-string": REM Sends Control-I and a command string


    For Pascal, enter
    WRITELN (CHR(9), 'command-string');



    The following example shows how to generate commands from a BASIC program:


    10 D$ = CHR$(4) : REM Printing D$ will send Control-D (a CR)
    20 I$ = CHR$(9) : REM Printing I$ will send Control-I
    30 PRINT D$; "PR#l": REM Establishes link: BASIC to port 1
    40 PRINT I$; "6B" : REM Changes to 300 baud
    50 ... : REM Continue program



    The commands in the following sections are generated from the keyboard.




    III. Printer/Communications mode Commands


    The following commands are typically useful in either printer or
    communications mode. (Discussion examples use the printer mode command
    character, Control-I. In communications mode, you would use
    Control-A.)



    Baud rate, nB


    You can use the nB command to select the baud rate for the serial-port
    firmware.


    For example, to change the baud rate to 9600, send Control-I 14B CR to the
    serial-port firmware (see Table 5-1).


    Table 5-1
    Baud-rate selections


    n Baud rate n Baud rate
    _____________________________


    0 Default* 8 1200
    1 50 9 1800
    2 75 10 2400
    3 110 11 3600
    4 134.5 12 4800
    5 150 13 7200
    6 300 14 9600
    7 600 15 19,200


    *On the IIgs, you set the default by using the Control Panel.



    Data format, nD


    You can override the Control Panel setting that specifies the data
    format by using the nD command. Table 5-2 shows how many data bits
    and stop bits correspond to each value of n.


    For example, Control-I 1D makes the serial-port firmware transmit each
    character in the form of 1 start bit (always transmitted), 7 data bits,
    and 1 stop bit


    Table 5-2
    Data-format selections


    n Data Stop
    bits bits
    _____________


    O 8 1 (standard setting)
    1 7 1
    2 6 1
    3 5 1
    4 8 2
    5 7 2
    6 6 2
    7 5 2




    Parity, nP


    You can use the nP command to set the parity you want to use
    for data transmission and reception.


    Table 5-3
    Parity selections


    n Parity
    _____________


    0 None (standard setting)
    1 Odd
    2 None
    3 Even
    4 None*
    5 MARK (1)*
    6 None*
    7 SPACE (0)*


    *Not available on IIgs
    The SCC 8530 does not support MARK and SPACE parity.



    Line length, nN


    The line length is set by sending Control-I nN. The number n can be in the
    range of 1 to 255 characters. For example, if you send Control-I 75N, the
    line length is set to 75 characters. (Note: Use the C command, discussed
    next, to enable line formatting.) If you set n to 0, formatting is disabled.



    Line formatting Enable/Disable, CE and CD


    A forced carriage return is invoked after a lineful of characters by sending
    Control-I CE. For example, Control-I 75N (see "Line Length" above) and
    Control-I CE cause a forced carriage return after 75 characters are typed on
    a line.

    __________________
    Bestes aus Berlin

  • Und hier der zweite Teil der SSC-Referenz:



    Handshaking protocol, XE and XD


    Sending Control-I XE CR or Control-I XD CR to the serial-port firmware
    determines whether the firmware looks for any XOFF ($13) character coming
    from a device attached to the SCC. It responds by halting transmission of
    characters until the serial-port firmware receives an XON ($11) character
    from the device, signaling the SCC to continue transmission. In printer
    mode, this function normally is disabled.


    XE = Detect XOFF, await XON.
    XD = Ignore XOFF.



    Keyboard input, FE and FD


    The FD command is used to make the serial-port firmware ignore keyboard input.
    For example, you can include Control-I FD CR in a program, followed by a
    routine that retrieves data through the serial-port firmware, followed by
    Control-I FE CR to turn the keyboard back on. As a default, the serial-port
    firmware keyboard input is enabled.


    FE -Insert keystrokes into serial-port firmware input stream.
    FD -Disable keyboard input.



    Automatic line feed, LE and LD


    The automatic line-feed command causes the serial-port firmware to generate
    and transmit a line-feed character after each return character. For example,
    use Control-I LE CR to print listings or double-spaced text.


    LE -Add line feeds after each carriage return output
    LD -Do not add line feeds after carriage return output.



    Reset the serial-port firmware, R


    The R command resets the serial-port firmware, cancels all previous commands
    to the serial-port firmware and reinstalls the Control Panel default settings.
    Sending Control-I R CR to the serial-port flfmware has the same effect as
    sending PR#O and N#O to a BASIC program and then resetting the serial-port
    firmware. This call also relinquishes any memory obtained from the Memory
    Manager for buffering purposes.



    Suppress control characters, Z


    The Z command causes all further commands to be ignored. This command is
    useful when the data you are transmitting (for instance, graphics data)
    contains bit patterns that the serial-port firmware could mistake for
    control characters.


    Sending Control-I Z CR to the serial-port firmware prevents the firmware from
    recognizing any further control characters, whether from the keyboard or
    contained in a stream of characters sent to the serial-port firmware. All
    tabbing and line formatting are disabled after a ControlI Z command.


    Important Note


    The only way to reinstate command recognition after the Z command Is either to
    Initialize the serlal-port firmware or to use the SetModeBlts call.




    IV. Communications mode Commands


    The following commands are typically most useful in communications mode.
    (Discussion examples use the communications mode command character,
    Control-A.)



    Terminal mode, T and Q


    The T command transfers you to terminal mode. In this mode, you can
    communicate with another computer or a computer time-sharing service.
    Terminal mode is entered through the BASIC interface. This means that
    you must initialize the firmware by typing IN#n and then sending Control-AT.


    Note: IN#n sets the port input link, and PR#n sets the port output link.
    The lowercase n indicates the port number.


    To quit terminal mode, send Control-AQ.



    Send a Break, S


    Often, when communicating with another computer in terminal mode, you want
    to send a break character to signal the other computer that you wish to
    signal the end of the current segment of transmission.


    To send a break character, send Control-AS CR. This command causes the
    serial hardware to transmit a 233-millisecond break signal, recognized by
    most time-sharing systems as a sign-off signal.



    Echo characters to the screen, EE and ED


    The EE and ED commands are used to display (echo) or not to display a
    character on the video screen during communication. For example, if you send
    Control-A ED CR, the serial-port firmware disables the forwarding of incoming
    characters to the screen. This command can be used to hide a password entered
    at a terminal or to avoid the double display of characters.


    EE = Echo input.
    ED = Don't echo input.



    Mask line feed in, ME and MD


    If you send Control-A ME to the serial-port firmware, the firmware will
    ignore any incoming line-feed character that immediately follows a return
    character.



    Input/Output buffering, BE and BD


    The BE and BD commands control input and output communication buffering.



    Scanning, reformatting, and minor mods: R/ 2004

    __________________
    Bestes aus Berlin