Junior Computer ][

Quote from klaly

Ich verstehe leider noch nicht ganz wie die Baudratenerkennung funktioniert, ...

Ich hab die Baud Raten Erkennung über die Abfrage des Terminal Typs ( ESC [c ) realisiert. Die Anfrage wird mit den verschiedenen, möglichen Baud Raten an das Terminal gesendet und es wird dann auf eine (sinnvolle) Antwort gewartet. Daher muss man auch keine Taste drücken, das Terminal antwortet ja selbstständig. Ich hab auch noch nicht erlebt, dass das nicht, oder erst nach mehrmaligen Versuchen funktioniert hätte. Eventuell stimmt da was mit deiner RS232 Verbindung nicht, oder HyperTerminal hat da irgend ein Problem (hatte bei mir aber auch immer funktioniert).

Ich hatte jetzt übrigens gestern wieder fehlerhaften Zeichen auf dem Terminal. Da lief es dann auch unter 9600, 4800 und 2400 Baud nicht sauber. Irgendwann war mit 19200 Baud alles wieder in Ordnung und 9600 lief auch. unter 4800 un d 2400 Baud kamen allerding wieder vereinzelt Schrottzeichen. Ich hab dann die 6551 und den MAX232 getauscht. Ohne Veränderung. Ich glaube, das bei mir der USB-Seriell Wandler die Probleme bereitet, was ich auch bei dir klaly vermute.

Nach dem ich jetzt nach langem Suchen feststellen musste, dass in meiner Haupt Interrupt Routine im ROM ein kleiner, aber sehr gemeiner Bug beim Aufruf der User IRQ Routine sitzt, läuft die Leseroutine für die Datasette fehlerfrei. D.h. geschriebene Bitmuster können nun problemlos wieder eingelesen werden. Allerdings meist noch mit ein paar Bits Versatz, da ich die Synchronisation noch nicht implementiert habe.

Wegen des Fehlers muss ich jetzt leider mein Versprechen brechen, die bisherigen System Routinen nicht mehr zu verschieben, da ich jetzt noch zwei Befehle ziemlich am Anfang des Codes einfügen muss. Mit der Herausgabe der ROM Version 1.0 werde ich dann aber die Liste der Einsprungadressen aller System Routinen, mit ihren Funktionsbeschreibungen herausgeben und den Stand somit einfrieren.

Heute Nacht versuche ich erst einmal die Bit-Synchronisation hinzubekommen. Danach muss ich mir mal überlegen, was ich alles im Header drin haben möchte. Da lasse ich mich aber von bereits bestehenden Datenformaten inspirieren.

Quote from Reinhard

Deswegen macht man am Anfang oder Ende des ROMs eine Sprungtabelle...

Fakt ist, dass es schon seit einiger Zeit für die Ein-/Ausgabe Routinen (umschaltbare) Standard IO Sprungtabellen gibt, die z.B. auch der Basic Interpreter nutzt. Deshalb ändert sich dort auch nichts. Bei weniger wichtigen Funktionen habe ich mir das aber gespart. Letztlich war es für mich Ziel bis zur Version 1.0 alles soweit aufgeräumt zu haben, dass es zu keinen Verschiebungen mehr kommt, und dass sollte auch klappen. Bei Nuller Versionen ist halt noch vieles Volatil.

Sprungtabellen sind aber eben auch eine enorme Leistungsbremse. Gerade wenn man repetitiv darauf zugreift, möchte man so etwas (als Assembler Programmierer) auf einem 1MHz System schon mal garnicht nutzen...

Quote from Reinhard

ach ein JMP mehr (3 Bytes) macht sooo viel aus?

Irgendwie verkehrte Welt, es sei denn die dahinter liegenden Codestücke haben weniger als 30 bytes ...

...ohne Worte...

Hier mal der neueste Stand bzgl. Schreiben und Lesen auf/von Datasette.

Etwas aufgehalten hatte mich jetzt ein ständiger, sehr nerviger Lesefehler, der immer bereits während der Synchronisation auftrat. Nach ein wenig Vorspulen und neuaufzeichnen waren dann alle Fehler weg. D.h. das Band hat an mindestens einer Stelle vermutlich eine schlechte Magnetisierungsschicht, was eventuell auch die vorherigen Probleme verursacht hatte.

Wie auch immer, das Lesen klappt jetzt völlig Problemlos und ohne Datenverluste.

Die Daten werden oben direkt von Band gelesen und ausgegeben. Die Aufzeichnung habe ich jetzt 30 mal, jeweils ohne Fehler wieder eingelesen. Ich gehe also davon aus, dass das jetzt auch keine Zufallstreffer sind.

Für die Aufzeichnung nutze ich nun für Nullen 128uS High- und 128uS Low-Phasen. Bei Einsen jeweils 256uS H/L. Für den obigen Testtext mit 128 Zeichen, den ich 128 mal aufgenommen habe (also genau 16KB) lag die Durchsatzrate bei 341 Byte/s, also 2728 Bit/s. Das könnte man zwar eventuell noch etwas beschleunigen, aber ich denke, so ist die Aufzeichnung ziemlich fehlertolerant.

Die Leseroutine ist, wie bereits erwähnt, jetzt als Interrupt Routine realisiert, welche bei einer fallenden Flanke ausgelöst wird. Fallend daher, weil die Datasette beim lesen das invertierte des augezeichneten Signals wiedergibt. Beim Eintreten in die IRQ Routine wird zunächst ein Zähler abgefragt, welcher bei einer Null (256uS Laufzeit zwischen zwei Flanken) noch nicht und bei einer Eins (512uS) bereits abgelaufen ist. Danach wird der Zähler wieder auf seinen Wert von 384uS gesetzt. Das klappt extrem fehlertolerant und gibt genügend Zeit zwischen den Interrupts zur Verarbeitung der Daten.

Ich möchte jetzt die Schreib-/Leseroutinen so umbauen, dass ich sie eventuell direkt mit den XModem Routinen nutzen kann. Dann würde ich zum Einen einiges an Code sparen, zum Andern kann ich dann gleich die CRC Prüfsummenberechnung von dort für die Datasette übernehmen.

Quote from klaly

Inwieweit ist die Datasetten Aufzeichnung "eigentlich" noch Commodore (PET2001) kompatibel ?

Völlig inkompatibel. Und auch ein völlig anderes Aufzeichnungsformat.

Quote from klaly

Gibt es da eigentlich dazu schon eine kurze Anleitung wie schreiben, bzw. lesen mit Datasette funktioniert ?

Ich mache jetzt erst mal alles soweit fertig, dann gibt es mit der neuen ROM Version natürlich auch eine Erweiterung des Handbuchs bzgl. Datasette.

Übrigens werden die bisherigen Routinen nun doch nicht verschoben. Ich habe die kleine Routine zum Anzeigen des Prozessorstatus, welche direkt hinter der Haupt Interrupt Routine stand jetzt einfach weit nach hinten geschoben. So hab ich noch Platz, um die Main IRQ Routine bei Bedarf zu erweitern, und ich kann die Prozessorstatusanzeige dahingehend ändern, dass statt eines einzelnen Hex Bytes für die Anzeige des Prozessorstatusregisters die einzelnen Flags noch angezeigt werden also z.B. (NV-BDIZC).

Nach Toast_r s für mich erhellenden Erklärung, wie der C64 (und vermutlich auch PET und VC20) mit den Tasten der Datasette umgeht, hab ich jetzt mal in dem angehängten Demoprogramm eine Timer IRQ Abfrage wie beim C64 im 1/60 Sekunden Takt eingebaut. Aufgefallen ist mir, dass bei dauerhaft laufender Abfrage, die XModem Routine öfter Schreib-/Lesefehler produzierte. Deshalb muss ich dann in der endgültigen Version bei XModem Übertragung den Timer Interrupt vorrübergehend deaktivieren.

Wie auch immer. Das kleine Programm kann jetzt mal beliebig auf Datasette den "schnellen braunen Fuchs" schreiben und lesen.

Nach dem Laden der Bin Datei via XModem, einfach mit 200G starten. Wenn das Programm läuft, startet der Motor dann automatisch beim Drücken einer der Tasten PLAY, REW und FWD, und stoppt natürlich dann auch wieder nach drücken der STOP Taste. Ihr könnt jetzt also beliebig hin- und herspulen.

Durch drücken von S wird der Text aufgenommen (128x128 Byte), mit L geladen und Q beendet das Programm, womit auch die Interrupt Routine beendet wird, und die Tasten der Datasette dann nicht mehr reagieren. Wärend dem Speichern oder Laden (dauert ca. 45 Sekunden) könnt ihr jederzeit, durch drücken der STOP Taste auf der Datasette, den jeweiligen Vorgang abbrechen.

Es wäre super, wenn alle, die schon ein IO Board und auch eine Datasette haben, das Programm mal auf Herz und Nieren testen könnten, um eventuelle Fehler zu finden. Einzig mir bekannt ist bisher, dass es jetzt noch nicht NMI fest ist. D.h. drücken der ST Taste auf dem Junior hinterlässt gerade noch einen unaufgeräumten Zustand, was natürlich noch behoben wird. Ich bin gespannt, was ihr noch alles findet.

Im nächsten Schritt kommt jetzt der Datei Header dran und echte Daten sollen dann geschrieben und gelesen werden...

Danke euch allen.

Hallo Klaus,

ich nehme immer den A65. Der läuft unter Windows.

Hallo Norbert,

wahrscheinlich hat die Load Routine nicht genügend Sync Bytes gefunden. Wenn du etwas weiter zurückspulen kannst, sollte das eigentlich kein Problem sein. Als kleine Anzeige wird einmal nach dem Drücken von PLAY und dann jeweils nach 256 gelesenen Sync Bytes ein Punkt auf dem Terminal ausgegeben. Du solltest also mindestens zwei Punkte angezeigt bekommen, besser drei. Falls das nicht der Fall ist, läuft das Band einfach weiter und sucht nach genügend Syncs. Drücken der STOP Taste sollte das wie gesagt natürlich abbrechen. Falls du am Anfang des Bandes aufnimmst, achte bei normalen Bändern auch auf das Vorlaufband, auf dem ja nichts aufgenommen werden kann. Bei Computerkassetten gibt es das ja im Normalfall nicht. Eventuell waren da bei dir noch ein paar cm Vorlaufband unter dem Schreibkopf. Ich werde trotzdem mal weitere 256 Bytes Sync zusätzlich mit abspeichern, um da mehr Sicherheit beim Lesen zu haben.

Spule am Besten für deine Aufzeichnung mal zB. auf 020 und beim Abspielen auf 018 oder 019, dann sollte das klappen.

Hallo Norbert, ändere mal bitte bei dir nach dem Laden von Test.bin an der Adresse 0348 den Wert von 03 auf z.B. 06. Die Zahl minus Eins gibt an, wieviel 256 Byte Sync Blöcke als Vorspann auf Band gespeichert werden. Bei einem Wert von 06 solltest du dann beim Wiedereinlesen "Press PLAY......" sehen, bevor dann der Text gelesen wird. Der erste Punkt wird ja bei dir noch angezeigt, was signalisiert, dass das Drücken der PLAY Taste erkannt wurde. Die restlichen 5 Punkte sind dann jeweils für die erkannten Sync Gruppen. Werden weniger als 256 Syncs erkannt, fängt das Synchronisieren von vorne an.

Interessant ist deshalb, dass bei dir aus dem ersten Punkt sonst nichts mehr angezeigt wird.

Stoppt den die Datasette, wenn du nach dem Load Befehl die STOP Taste drückst, oder läuft dann der Laufwerksmotor auch noch weiter? Das wäre dann ja ein Zeichen dafür, dass die Routine bei dir vollkommen abgeschmiert ist.

Auf dem IO Board besteht ja die Möglichkeit, rechts neben dem Datasetten-Anschluss die Signale per Pin Header abzugreifen. Ich hatte da zum Testen jetzt immer mein Oszilloskop am Anschluss CR (Cassette Read) hängen um die gelesenen Signale mitschneiden zu können. Wenn du den oben genannten Wert dann mal auf 80h stellst, dann solltest du mit einem Speicheroszilloskop problemlos den Sync Wert 2E (sorry, ich konnte da leider nicht widerstehen ) also binär 00101110 sehen können, der dann wie folgt aussieht

Das letzte Bit ist bei mir wegen der nach einem vollständigen Byte folgenden Abfrage der Key_Sense Leitung von 256us auf 322uS gestreckt. Der Messpunkt für ein sicheres Eins Bit liegt bei Werten größer 384uS. Eventuell reicht da bei dir auch die Zeit nicht aus, weil dieses letzte Null Bit womöglich länger als 384uS dauert.

Du könntest dann mal den Wert an Adresse 0379 von 4E auf 4F oder 50 ändern, um da nochmal 8, bzw. 16uS dazuzugeben.

Quote from NorbertJ

Ach ja, bei STOP läuft die Datassette weiter.

Das ist bemerkenswert. Denn an dem Punkt , an dem es bei dir nicht weiter geht, sind nur zwei Dinge passiert.

WAITPLAY    LDA    CASS_SENSE    ; Check sense line status
                BNE    WAITPLAY    ; If <> 0, wait if Datasette key pressed down
                LDA    #'.'
                JSR    COUT        ; Print '.' as a detection signal
                JSR    CASSRW_ON    ; Turn off key detection interrupt and turn on Bit read interrupt
STARTSYNC    LDA    #$00
                STA    STATUS        ; Initialize Bit arrival flag
WAITBIT        LDY    #PORTB        ; Set index to Port B
                LDA    (IOBASE),Y    ; Load Port B
                AND    #$20        ; Test cassette sense line at PB5
                BNE    BREAKSYNC    ; If sense line is high, PLAY key is no longer down -> exit.

Erstens, durch ein JSR zu CASSRW_ON, wird der 1/60 Sekunden Interrupt zum Abfragen der Datasettentasten deaktiviert und der Interrupt zum Erkennen der Bitflanken aktiviert.

Danach wird in einer Schleife die Bit Status Variable abgefragt. Direkt am Anfang der Schleife liegt die Abfrage der Datasettentasten, die jetzt manuell erledigt werden muss, da ja der 1/60 Sekunden IRQ deaktiviert ist. Sobald hier erkannt wird, dass keine Taste mehr gedrückt ist, beendet die Read Routine mit der Meldung "Break", abschalten des Motors und wieder umschalten der IRQs. Das funktioniert bei mir immer, auch wenn beim Lesen kein Signal ankommt, weil z.B. die Kassette garnicht eingelegt ist. Hier läuft bei dir der Motor ja einfach stur weiter.

D.h. also, dass in deinem Fall der Rechner entweder in der CASSRW_ON Routine (unwahrscheinlich) oder der dann laufenden Bitflankenabfrage in der Interrupt Routine hängen bleibt.

Ich melde mich heute Mittag nochmal bei dir und wir probieren mal eventuell ein paar Code Varianten aus, wenn du Zeit und Lust hast.

So, der Fehler ist - zumindest bei Norbert - behoben. Ein Interrupt hatte sich beim Schreiben soz. durch die Hintertüre eingeschlichen. In der Schreibroutine hatte ich aus versehen die Interrupts der VIA nicht komplett abgeschaltet, sondern nur vom Tick-Interrupt auf den Bit-Read-Interrupt umgeschaltet. So konnten beim Schreiben der Bits, die über den Lesekopf zeitgleich wieder eingelesenen Signale weitere Interrupts auslösen und das Schreibsignal modifizieren. Da war Norberts Laufwerk offensichtlich für so etwas empfänglicher als meines, denn bei mir ist der Fehler nie aufgetreten.

Ich habe jetzt also am Beginn der Schreibroutine die Interrupts mit einem SEI Befehl vollständig deaktiviert, so wie ich es auch in den XModem Routinen machen werde.

Jedenfalls habe ich jetzt wohl auch verstanden, warum beim C64 beim Laden/Schreiben von/zu Datasette der Bildschirm deaktiviert ist, der wird da wahrscheinlich auch durch einen Interrupt refreshed und der ist ja, wie Toast_r schon gesagt hat, hier dann eben auch disabled.

Ansonsten habe ich die Routinen noch etwas aufgeräumt und so nochmals ein paar Byte eingespart. Falls außer Norbert noch jemand die Routinen testen

kann und mag, wäre das Klasse.