Lochstreifen einlesen unter CP/M

    • Offizieller Beitrag

    Hallo!


    Ich wollte unter CP/M mit meinem TA PC einen Lochstreifen einlesen über die serielle Schnittstelle. Die habe ich mit der Steckbrücke auf dem Mainboard auf 300Bd konfiguriert, genauso wie den Leser/Stanzer.


    Nun habe ich gedacht mit PIP A:TEST.ASC=RDR: oder PIP CON:=RDR: müßte ich den Leser abfragen können, aber das funktioniert nicht.... Der Lochstreifen läuft durch, aber das CP/M bekommt davon nichts mit.


    Der Befehl wird angenommen ohne Fehlermeldung, aber der Rechner friert ein. Auch ein CTRL-C wird nicht mehr angenommen.


    Das gleiche bei PIP PUN:=CON:. Hier kann ich Eingaben tätigen (bekomme sogar ein Echo zurück) aber auch hier kann ich nicht abbrechen mit CTRL-C.


    Irgendjemand eine Idee? Ajax kämpft ja auch grade mit der seriellen das TA PC, vielleicht hast Du schon was erhellendes herausgefunden?


    Am Atari ST (mit dem gleichen Kabel) geht es einwandfrei.


    Gruß

    Stephan

    • Offizieller Beitrag

    Das mit dm Kabel muss nichts heissen. Es gibt genug Möglichkeiten.


    Unterstützt das CPM des TA PC das IOBYTE? Und sind die entsprechenden Schnittstellen unterstützt?

    • Offizieller Beitrag

    Das mit dm Kabel muss nichts heissen. Es gibt genug Möglichkeiten.

    Ja, es gibt das IOBYTE. Wenn ich STAT DEV: eingebe, sehe ich auch PUN: / RDR:


    Leider schweigt sich als Alphatronic PC CP/M Handbuch völlig aus, was den Gebrauch der Schnittstellen anbelangt.

    • Offizieller Beitrag

    Es kann aber sein, das hinter PUN und RDR nur Dummyfunktionen implemtiert sind.

  • Wenn du an die serielle Schnittstelle ein Terminal anschliesst, und mit pip etwas dahin kopierst, kommen da Zeichen an?

    Die Einstellungen werden über das BIOS vorgenommen. Eventuell gibt es passende Tools die das Einstellen und ins BIOS patchen.

    Suche Teile und Geräte für DEC PDP8 Systeme, DEC PDP 11/40 (Unibus) und Teletype ASR-33+ ASR-35. Sowie Zubehör, Doku usw. aus dem Umfeld.

    • Offizieller Beitrag

    Da alles hardware-abhängige im BIOS liegt, musst du für sowas den Hersteller fragen.


    Wenn das IOBYTE unterstützt wird, hast du für jedes Gerät 4 Möglichkeiten .

    Jetzt kann es aber sein, dein Gerät hat nur 2 oder 3 Schnittstellen. Oder nur Unidirektional (z.B. Drucker). Dann kann es sein, das der Hersteller einige Funktionen nur als Dummy implementiert sind.

  • Leider nein ... ich komme an die Kiste auch grad nicht ran. Ist die Buchse so belegt, dass man ein normales Nullmodemkabel verwenden kann?


    Gruß

    Robert

    NCR DMV/Olivetti M20/ITT 3030/DEC Rainbow 100/Siemens PC-D/OlyPeople/MFA 8085/TA Alphatronic

  • Hast Du denn schon alle Geräte durchprobiert? Ich habe gestern auch lange mit dem MFA gebraucht, um das richtige Gerät für die zweite serielle Schnittstelle auf Florians Z180 Karte zu finden, weil ich nicht in den Quellen nachgeschaut habe.

    Es muss ja nicht ptp: und ptr: sein, es kann auch tty: oder uc1: etc. sein.


    Auf jeden Fall würde ich es erst mal mit schreiben versuchen, also


    pip tty:=test.txt


    und sehen, mit welchem logischen Gerät auf der seriellen etwas kommt (mit Schnittstellentester prüfen).

  • Da bei meiner Pertec das CP/M auch nicht das IO-Byte unterstützt, habe ich mit tools wie IOMAP.COM und SURVEY.COM Hinweise über genutzte Adressen bekommen. Mit einigem Ausprobieren konnte ich dann direkt in Assembler die serielle Schnittstelle ansprechen. Allerdings gelang mir das nur wegen der Ähnlichkeit zur Altair 8800, da konnte ich Code übernehmen und musste quasi nur die Adresse anpassen.

    Wenn du ein Programm hast, was die Schnittstelle anspricht, kannst du das disassemblieren um herauszubekommen wie die Schnittstelle initialisiert wird?

    Suche Teile und Geräte für DEC PDP8 Systeme, DEC PDP 11/40 (Unibus) und Teletype ASR-33+ ASR-35. Sowie Zubehör, Doku usw. aus dem Umfeld.

    • Offizieller Beitrag

    Hast Du denn schon alle Geräte durchprobiert?

    Nö!


    Jetzt gehts.



    "UR1:" ist der Reader

    "UP1:" ist der Stanzer


    Retroorgasmus.::domina::


    Eine blöde Sache noch. Nach dem Lesen CRT:=UR1: hängt er sich auf. die PIP Prompt "*" kommt nicht wieder. Auch CRTL-Z geht nicht. Jemand eine Idee? Kann ja nicht sein, daß ich nach dem Lesen eines Lochstreifens einen Reset machen muss.


    Dieser Stanzer ist mit Abstand das coolste was ich mir die letzten Jahre gekauft habe. Mit Ausnahme der T100s vielleicht :)

  • Eine blöde Sache noch. Nach dem Lesen CRT:=UR1: hängt er sich auf. die PIP Prompt "*" kommt nicht wieder. Auch CRTL-Z geht nicht. Jemand eine Idee? Kann ja nicht sein, daß ich nach dem Lesen eines Lochstreifens einen Reset machen muss.

    Ich bin jetzt nicht der große CP/M Fachmann, dafür habe ich zu wenig Routine in den letzten Jahren.

    Aber wenn Du mit pip crt:=ur1: arbeitest ist das m. E. wie eine Eingabeumleitung, und er erwartet Consoleneingaben vom Leser.

    Als erstes würde ich das Ctrl-Z über den Leser schicken, d.h. ein 0x1A zum Schluss lochen bzw. einen speziellen Streifen damit hinterher schicken.

    Besser wäre es vermutlich, in eine Datei zu lesen, dann behält deine Konsole die Kontrolle.


    Ist jetzt alles ins blaue geraten, praktische Erfahrung habe ich da auch nicht. Könnte ich aber bei Gelegenheit nachholen - der GNT ist nämlich wirklich coooool!! :love:

  • cp/m IO - Betrachtungen

    Ich meine beim cp/m werden mit pip zwei grundlegende Datenströme verarbeitet. Als Block - Datenstrom ist das was jeder vom File IO kennt. Das macht intern pip - mit dem cp/m (FCB-Infos) ab.

    Hintergrund

    Es ist verdeckt bei cp/m char-Files normal ein EOF 1A h vorhanden. Falls nicht im File nach der FCB- Datenlänge

    kein EOF vorhanden ist, wird der source-Datenstrom ( aus dem FCB lng. key) beendet. Fertig.


    char Datenstrom ( beachten ) beim char source-device!

    Jetz kommen die Zeichen- Datenströme besser als charcter (get) - (put):

    Als Beispiel - in .plm :

    GETSOURCE: PROCEDURE BYTE;

    /* GET NEXT SOURCE CHARACTER */


    Mögliche Abhilfe:

    Daher meine ich, dass bei einer externen source char-device beteiligt (wie der schöne Lochstreifen - Leser) ist, dann klar- muss als ENDE ein "ENDFILE" code irgendwann kommen. DAS ist üblich der HEXA 1A h oder 27 d, oder besser als Tastatur Ctrl. Z !

    Als z.B. vom Lochstreifen.


    Nach dem Lesen CRT:=UR1: hängt er sich auf. die PIP Prompt "*" kommt nicht wieder


    Also müsste mal beim LS-READER - im Lochstreifen ein EOF vorhanden sein.

    Dann sollte wieder ein PROMPT vom pip kommen. Weil die Operation beendet ist.


    Weil hier nicht beim LS-STANZEN von einem TXT-File offenbar keine Probleme im Beitrag stehen, ist der PIP Prompt frei - oder ?


    Leich ist sowas zu probieren:

    Die vorher aufgerufene Lochstreifen LESE Mimik aufrufen.

    Aber vorher schon die V24 LS-Verbindung nicht benutzen, sondern ein Terminal mit richtigen Parameter per V24 einrichten. Jetzt etwas Text vom Terminal eingeben. ENDE mit Ctrl. Z das ist 1A h oder immer noch EOF!


    (Alte Erfahrung mit dem Lochstreifen - bei sogar der Urahne wie bei der Z23 - noch in Bochum Ruhr-UNI habe ich damit gewerkelt!)


    Grüße und viel ERFOLG!

    Helwie44

  • Beim PIP sollte etwas in den DR cp/m Unterlagen stehen. Beim Stanzen eines LS können mehr oder ein zusätzliches Ctrl. Z am ENDE gestanzt werden. Denn nur ein richtiger TXT Lochstreifen beendet die EINGABE - später.

    ( wo kann ich nicht auf die Schnelle finden - aber vor Jahren sowas gelesen)

  • The following list describes additional device names that can be used in PIP commands.

    • NUL: sends 40 nulls (ASCII 0s) to the device. This can be issued at the end of punched output.
    • EOF: sends a CP/M end-of-file (ASCII CTRL-Z) to the destination device (sent automatically at the end of all ASCII data transfers through PIP).
    • INP: is a special PIP input source that can be patched into the PIP program. PIP gets the input data character-by-character, by CALLing location

    EOF:

    alles klar?

    • Offizieller Beitrag

    Also: Geht!

    Ich kann eine Textdatei auf Streifen schreiben mit

    UP1:=CRT:,EOF:


    Wenn ich die Eingabe mit CTRL-Z abschließe, wird anschließend noch ein EOF geschrieben


    Ein späteres einlesen mit


    CRT:=UR1: geht einwandfrei. Die Prompt kommt wieder zurück!


    Leider geht


    PIP CRT:=UR1:,EOF: nicht- damit kann ich also keinen Lochstreifen sauber einlesen, der kein EOF Zeichen hat.


    Aber ich kann einen Lochstreifen mit diesem Zeichen hinterherschicken und dann kommt die Prompt wieder.


    Hab ich schon gesagt, daß ich den Stanzer klasse finde? Anschaulicher geht Rechentechnik nicht, man sieht jedes Bit :)

  • Aber ich kann einen Lochstreifen mit diesem Zeichen hinterherschicken und dann kommt die Prompt wieder.

    Na prima! So ungefähr habe ich mir das auch gedacht. Schön, dass es klappt.



    Hab ich schon gesagt, daß ich den Stanzer klasse finde? Anschaulicher geht Rechentechnik nicht, man sieht jedes Bit :)

    Ja, kommt mir bekannt vor ;)


    Ein ganz gewaltiger Vorteil dabei ist das Format, die Geschwindigkeit und die geringe Lautstärke. Das Teil kannst du überall mitschleppen und an fast jedem Rechner betreiben. Ich habe den gerne an einem HX-20 vorgeführt, da habe ich mir ein Programm geschrieben, das lesbaren Text auf dem Streifen erzeugt. Kommt immer wieder gut, und jeder will einen Streifen mit seinem Namen haben :)



    Eine PDP 8 mit ASR33 ist zwar eindrucksvoller, aber auch deutlich unhandlicher...