Hallo Erhard,

durch den letzten Post habe ich den Thread hier erst gesehen. Sehr cool. Ich habe für das hier:
https://www.youtube.com/watch?v=tiLB8PQUJtc

auch ewig rumprobiert und am Ende durch Trial & Error es hingebracht, dass es auf 2 Tapes richtig synchron läuft. An der SIO Routine und den Timingergebnissen bin ich daher sehr interessiert.

Und ja: Dank Data Becker ist da Hobby auch nach so viele Jahren noch immer interessant

Hi Jac,

irgendwie habe ich das Gefühl, daß die 3 geladenen Blöcke in dem Video die Demo wohl eher nicht enthalten ist ....

Meine Cassetten-POKEY-Routine ist sicher kein eleganter Code. Er macht das Allernotwendigste für den Test: Bytes vom POKEY lesen und aufsteigend ins RAM kopieren. Ein Abbruch erfolgt bei Rahmenbitfehler, Overrun, Prüfsummenfehler und wenn man die SHIFT-Taste drückt.

C'est ca.

Ich habe den Test mit Milkrace jetzt einige male gemacht. Die so gelesenen Daten sind authentisch. Jetzt gleich kommt eine Datasette dran.

CU, Erhard

Hallo Erhard

Erhard hat geschrieben:Nicht ein einziger Abbruch beim Lesen über das SIO2USB Interface von APE.

Hast Du Thomas und Harry schon darüber informiert, dass Steve ihr SIO2USB nachbaut?

Aber mal im Ernst: Bitte nenne das SIO2PCviaUSB nicht SIO2USB. Es führt nur zu Verwirrung. Dass die Amis das SIO2USB nicht kennen ist ja schon schlimm genug, aber wir sind da besser informiert.

Tschüß

Mathy

Hi Mathy,

Mathy hat geschrieben:Bitte nenne das SIO2PCviaUSB nicht SIO2USB. Es führt nur zu Verwirrung.

da hast Du wohl recht. Mir war "SIO2PC Interface USB Edition" aber einfach zu lang. Gut, ich nenn das Teil ab jetzt APE-USB. (Man könnte es auch AUSI nennen für APE USB SIO Interface ). AUI geht ja auch nicht weil schon besetzt.

CU, Erhard

Der Test mit Datasette
===================

So, ich habe gestern noch das Lesen von einer XC12 getestet.

Testobjekt war die Cassette mit dem Spiel Milkrace.

Das ganze Band wurde problemlos gelesen, die Daten sind verifiziert.

Für mich steht damit fest, daß die meisten Ladefehler von Cassette durch den dafür zuständigen Teil im Atari OS verursacht werden.

Also geht die Suche in dieser Richtung weiter.

CU, Erhard

Hallo Erhard

Erhard hat geschrieben:... ich nenn das Teil ab jetzt APE-USB. (Man könnte es auch AUSI nennen für APE USB SIO Interface ).

Auf AtariAge habe ich schon mal geschrieben dass man es SIO2PML nennen sollte statt nur SIO2PC, da man das Teil ja auch unter MacOS und Linux benutzen kann. SIO2PML hört sich aber, wenn man den letzten Teil auf Englisch ausspricht, sowohl für Niederländer als auch für Deutsche irgendwie komisch an.

Tschüß

Mathy

Hallo,

es gibt ein neues Testergebnis:

Ich habe das ROM ins RAM kopiert und dann die Laderoutine verändert. Statt der gemessenen Baudrate wird einfach fest $05C0 als Teiler verwendet.

Damit habe ich dann 10x hintereinander in BASIC mit CLOAD ein BASIC-Programm (ca. 10 Minuten Ladezeit oder so) geladen.

Null Fehler.

Als Nächstes kommt ein entsprechned verändertes ROM. Dafür muß ich aber mal erst schauen, wie die Prüfsumme berechnet wird und diese dann eintragen. Damit werde ich dann lange Tapes booten.

CU, Erhard

Hmmm,

von OS-Problemen oder Bugs bei der Tape-Wiedergabe (oder Aufnahme) habe ich leider keine Ahnung. Ich habe mit 30, 35, 40 Jahre alten Tapes und aktuell ca. 400 Konvertierungsversuchen von Tape2Disk folgende (allgemeine/simple/naive/...) Beobachtungen gemacht:

- Verschleiß des Bandes, dadurch endlos Ladefehler (teilweise Ab/Auflösung der Beschichtung, so dass das braune Band plötzlich durchsichtig wird, wie am Anfang der Cassette)

- tausend Knicke, tausend Abstürze (jedes längere Pausieren des Datenrekorders führt zu einem Knick im Band, also so schnell wie möglich die Stop-Taste drücken; stürzt das Tape bei diversen Versuchen immer wieder an der gleichen Stelle ab, so ist es wohl leider defekt; stürzt das Tape hingegen immer wieder an anderen Stellen ab, muss man Geduld haben und hoffen, dass es irgendwann doch einmal durchläuft; hatte schon Tapes, die 20-30x an versch. Stellen abstürzten, ehe sie endlich einmal durchliefen)

- Staub, Dreck, Schmutz, Fingerabdrücke, Ablagerungen, Pilze, etc. (es ist nicht einfach, das Magnetband zu reinigen, ohne es zu beschädigen oder zu zerstören, gerade bei 30-40 Jahre alten Tapes)

- Rädchen drehen sich nur schwer oder gar nicht mehr, Cassettenrekorder ächzt und quietscht und beibt nach einer Weile stehen z.B. weil die Cassetten übereinander gestapelt wurden und die unterste Cassette längere Zeit höherem Druck und Belastung ausgesetzt war; auffällig ist, dass der 1010 Motor stärker zu sein scheint, als der XC-11 oder XC-12 Motor. Drehen sich die Rädchen mit der XC-11 oder XC-12 nicht mehr, lässt sich die Cassette oftmals noch mit der 1010 laden, geht es auch mit der 1010 nicht, kann man's vergessen, auch das Hifi-Tapedeck oder andere Tapeconverter können diese Tapes dann nicht mehr abspielen. (Komplettes rück/vorspulen nutzt hier fast nie was, die Wiedergabe funkt. danach trotzdem so gut wie nie; Cassette öffnen und nur zu 90% wieder schließen geht meistens auch nicht, da nur wenige Cassetten Schrauben verwenden und Plastiknasen abbrechen bzw. nur "zuschnappen", wenn man das Tape wieder vollständig schließt; hatte mal eine solche Cassette geöffnet und nur zu 90% wieder geschlossen, die Rädchen drehten sich danach wieder problemlos, jedoch gab es nach einigen Sekunden Bandsalat im Datenrekorder...)

- Kopierschutz der z.T. an den merkwürdigsten Stellen Pausen oder Sprünge macht (und hier stürzt das Programm nur allzu gerne ab) oder das Vorhandensein einer Floppy (alternativ eines Freezers, ML-Monitors, etc.) testet und sodann nicht weiterlädt (einige Ariolasoft-Titel, z.B. Hotel, Slotmachine, Airline, etc.) oder zwar weiterlädt aber am Ende einfach kein Bild anzeigt (z.B. Zaxxon von Datasoft)...

- die meisten Tapes nutzen den "Leader" gar nicht, d.h. man muss das durchsichtige Band vorspulen und erst danach mit der Wiedergabe beginnen, es gibt jedoch einige Ausnahmen (z.B. alle Dixon's Pack Tapes, hier muss man bei der Wiedergabe mit dem Leader anfangen, damit die Pause am Anfang lang genug ist)...

- zu leise Aufnahmen, Programmbeginn wird nicht erkannt, z.B. bei vielen Dixon's Pack Tapes (in ganz seltenen Fällen auch mal zu laute Aufnahmen, z.B. mit CAS2WAV selbstgenerierte Tapes)

- fürchterliches Pfeifen oder schreckliche/scheußliche/nervige Musik, z.T. auf dem Datenkanal (führt immer wieder zu Abstürzen)

- unterschiedliche Länge der Datenblöcke, neben den Standard Datenblöcken mit 128 Bytes (ca. 90% aller kommerz. Tapes) auch Datenblöcke mit ca. 256 Bytes, ca. 384 Bytes (Creative Sparks), ca. 512 Bytes (Novagen), ca. 1k (English Software), ca. 2k (Dig. Integration, Fighter Pilot), ca. 16k (z.B. Aackosoft und BC's Quest for Tires als ein einziger Datenblock für das komplette Spiel), etc.; wobei stets mit Standard Datenblöcken begonnen wird und dann entweder ganz ohne Pause oder mit viel zu kurzer Pause auf non-standard Datenblöcke umgeschaltet wird...

- unterschiedliche Baudrate, neben der Standard Baudrate von 600 Baud werden auch bei kommerz. Titeln (nicht nur bei Rambit Turbo Tapes!) hin- und wieder fastloader oder turboloader verwendet (z.B. Gremlin Graphics, "Zone-X" mit 600 Baud und 9:xx Minuten Ladezeit auf einer Tapeseite und ca. 800-900 Baud und 6:xx Minuten Ladezeit auf der anderen Tapeseite, getestet mit mehreren dieser Tapes, also kein Zufall!)

- unterschiedliche "Gaps" (Pausen zwischen den Ladeblöcken, also short IRG's a la CLOAD/CSAVE oder long IRG's a la LOAD"C:"/RUN"C:" ) z.B. viele Databyte Tapes, die einen Bootloader mit long IRG's haben, während das Programm mit short IRG's lädt; bei manchen Publishern wird das komplette Programm mit long IRG's geladen (z.B. Death Race und Crack Up von Atlantis) und dadurch die Ladezeit unnötig verdoppelt, obwohl man es ebensogut mit short IRG's und dadurch nur halb so langer Ladezeit hätte einladen können...

- ein deutlicher Knick auf einer Tape-Seite, der sich nicht beheben lässt führt immer wieder zum Absturz an dieser Stelle, die andere Seite läuft jedoch seltsamerweise oftmals fehlerfrei (obwohl da ja auch der Knick vorhanden ist, nur halt an anderer Stelle; blöd natürlich, wenn die andere Seite ein anderes Spiel oder eine andere Computerversion enthält)

- mehrere Computer-Versionen auf einem Band (und Atari irgendwo mittendrin oder am Ende, da macht das Suchen richtig Spaß, z.B. Avalon Hill oder MCG; kommerz. Angaben von Zählwerksnummern stimmen nie bzw. variieren zwischen versch. 410, 1010, XC-11 und XC-12 stark; beispielsweise zählt mein japan. 1010 Zählwerk doppelt so schnell, wie mein XC-11 Zählwerk und das japan. 1010 zählt auch schneller/langsamer als das Hong Kong 1010)

- und viele andere Späße mehr (z.B. "!"-Loader oder sonstiger Bootloader mit anschließendem COM-File, Basic Game mit ML-Header, Programm benötigt nicht nur OS-A oder OS-B, sondern auch noch Basic Rev. A, z.B. viele ältere Epyx / Automated Sim. Programme von 1980/81/82, etc., etc.)

Mittlerweile wundere ich mich, dass immer noch mehr als 50% der A8 Tapes auch heutzutage noch laufen bzw. abgespielt+gelesen werden können, wenngleich die Ausfallraten (genau wie die Preise bei ebay) stetig weiter zunehmen. Ob auch Flashspeicher in 30-40 Jahren noch weitgehend fehlerfrei gelesen werden können ? (Ich denke nicht, Tim.)

P.S.: Du willst lange Tapes testen, Erhard ?!? Also Tapes bei denen ein Part besonders lang ist (z.B. Thomahawk von Digital Integration, ein Part mit 437 Sektoren auf DOS 2 Disk bzw. mehr als 400 Blocks auf Tape) oder Tapes bei denen das Programm insgesamt sehr lange ist, da es endlos oft nachlädt (z.B. Nightmares von Byte Back mit über 700 Sektoren auf DOS 2 Disk bzw. mehr als 650 Blocks auf Tape Seite A+B oder für Masochisten Gauntlet mit ca. 1180 Sektoren auf DOS 2 Disk bzw. mehr als 1000 Blocks auf Tape Seite A+B)...

Erhard hat geschrieben:Hallo,

Damit habe ich dann 10x hintereinander in BASIC mit CLOAD ein BASIC-Programm (ca. 10 Minuten Ladezeit oder so) geladen.

Null Fehler.

Als Nächstes kommt ein entsprechned verändertes ROM. Dafür muß ich aber mal erst schauen, wie die Prüfsumme berechnet wird und diese dann eintragen. Damit werde ich dann lange Tapes booten.

CU, Erhard

Probiere mal, auf Tape Seite A ein kurzes Programm zu speichern, dieses 10x laden, ohne Stop zu drücken (es müsste an dieser Stelle ein Knick entstehen). Dann auf Tape Seite B ein langes Programm speichern, welches das Tape komplett oder fast komplett ausfüllt (an der Stelle des Knickes funkt. das Speichern nicht richtig oder nach einer Weile das Laden nicht mehr)...

Genau das passiert u.a. wenn man öfter Tapes lädt und in der Zwischenzeit Kaffee / Tee trinken geht...

Hi,

erst mal vorab - hier geht es mir in erster Linie um Fehler, die nicht durch die Cassette selbst verursacht werden, sondern möglicherweise durch die Laderoutine des OS.

Deshalb verwende ich auch für Tests hauptsächlich digitale Quellen (z.B. CAS-Datei via APE oder SDrive-Max), bei denen das Verhalten einigermaßen wiederholbar sein sollte.

CharlieChaplin hat geschrieben:jedes längere Pausieren des Datenrekorders führt zu einem Knick im Band

Leider sind die Datasetten zu billig gebaut. Ein automatisches Lösen der Andruckrolle von der Kapstan-Welle bei Pause oder Motor-Off wäre schon echt toll, haben wir aber leider nicht.

CharlieChaplin hat geschrieben:Verschleiß des Bandes

Deshalb rate ich jedem, der archivieren will, das Band möglichst einmalig mit einem guten Tapedeck abzuspielen, mit dem PC als Wave-Datei aufzunehmen und alle weiteren Arbeiten zur Archivierung und / oder Wiederherstellung auf dem PC durchzuführen und nur notfalls erneut auf die Cassette zurückzugreifen.

Leider sind neue MCs weder marktgängig noch günstig erhältlich.

CharlieChaplin hat geschrieben:Staub, Dreck, Schmutz, Fingerabdrücke, Ablagerungen, Pilze

Hatte ich auf meinen (wenigen) Tapes bislang nicht.

CharlieChaplin hat geschrieben:auffällig ist, dass der 1010 Motor stärker zu sein scheint

Klaro. Die 1010 hatte ja auch ein eigenes Netzteil während bei der XC12 die gesamte Stromversorgung über das SIO-Kabel gesaugt wird und wenn dann noch Kontakte nicht blitzeblank sind ....

CharlieChaplin hat geschrieben:Cassette öffnen und nur zu 90% wieder schließen

Du könntest zur Wiedererstellung das Band mit den Wickeln in ein nicht verbogenes und schraubbares Cassettengehäuse transplantieren ...

CharlieChaplin hat geschrieben: Vorhandensein einer Floppy (alternativ eines Freezers

Gibt es echt Titel von Anno Dunnemals die es schaffen, einen Freezer 2011 zu erkennen?

CharlieChaplin hat geschrieben:zu leise Aufnahmen, Programmbeginn wird nicht erkannt, z.B. bei vielen Dixon's Pack Tapes (in ganz seltenen Fällen auch mal zu laute Aufnahmen, z.B. mit CAS2WAV selbstgenerierte Tapes)

Für zu leise Aufnahmen hilft die Bearbeitung am PC: Wave-Datei und dann in HEX / CAS-Datei umwandeln. Über die Hex-Datei kann man unregelmäßige IRGs und Baudraten aufhübschen, wenn kein Kopierschutz zu Grunde liegt. Und dann am besten mit Altirra aus der CAS-Datei eine Wave-Datei erstellen, weil der nicht 100% Lautstärke verwendent (also kein Clipping und geringerer Klirrfaktor) und einen Post-IRG erzeugt.

Darüber hinaus ist Dein Beitrag sehr interessant und ich fände es gut, wenn Du Dein Wissen über die Cassetten zumindest tabellarisch bündeln und zur Verfügung stellen würdest.

So a la:

Titel, Herausgeber, Band, Kopierschutz (J/N), Probleme, ...
FEUD, Bulldog Software, BASF, unbekannt, bleibt bei Block 423 hängen, ...

CharlieChaplin hat geschrieben:Du willst lange Tapes testen

Das B.C. Quest for Tires wäre ein guter Test, glaube ich.

Erhard

Neues Testergebnis
=================

Hi,

ich habe mittlerweile ein modifiziertes OS in meinem XE, bei dem die Lesebaudrate für Cassette auf 600 Bd festgenagelt ist.

Bislang habe ich folgende Lesetests durchgeführt:

- Milkrace über APE -> kein Fehler
- Milkrace über XC12 -> kein Fehler
- Zybex über XC12 -> kein Fehler

Sonst hatte ich eigentlich immer Abbrüche innerhalb der ersten 10 Blöcke.

CU, Erhard

Nunja,

Milk Race stammt ja auch von Mastertronic, dieser Publisher hat meines Erachtens die qualitätsmäßig besten Tapes benutzt, es wurden stets standard Baudraten und standard Blocklängen, sowie short gaps (short IRG's) und keinerlei Kopierschutz benutzt, mit lediglich einer einzigen mir bekannten Ausnahme: Gunlaw by The English Software Company (ESC, published by Mastertronic), dieses nutzt die typische ESC Blocklänge von ca. 1k als Kopierschutz, alle anderen Tapes nutzen nur Blocklängen von 128 Bytes. Sämtliche Tapes (außer Gunlaw!) von Mastertronic konnte ich bereits in den 90ern mit C-Sim 1+2 (von R.David) und Super-C-Emulator (von mhs) kopieren, konvertieren und von Diskette laden; in diesem Jahr habe ich nochmal alle meine ca. 400 Tapes mittels tape2disk gesichert (oder dies zumindest versucht) und wieder gab es mit Mastertronic absolut keine Probleme!

Wesentlich schwieriger sieht es da bei den Tapes von "Dixon's Pack" aus, da diese qualitätsmäßig saumies sind, zumeist viel zu leise aufgenommen sind, etc. wodurch ich mir diese Tapes fast immer mehrfach besorgen und dutzendfach kopieren musste, bis ich auch nur einmal eine fehlerfreie Kopie bekam. Die Publisher US-Gold und Americana schneiden leider auch nicht so gut ab, was ich aber nicht auf die Qualität der verwendeten Tapes, sondern genau wie bei Databyte, auf die Beliebtheit der Spiele zurückführe, die vermutlich immer wieder mit dem Datenrekorder geladen wurden, was dann eben zu verstärktem Verschleiß / Abnutzung und vielen vielen Knicken im Band geführt hat.

Bei Zeppelin Games (Zybex, Draconus, etc. früher auch bekannt unter dem Namen Cogito) habe ich rein subjektiv festgestellt, dass die grünen Tapes fast immer fehlerfrei bei mir liefen, während umgekehrt die schwarzen Tapes fast immer abstürzten - nur warum dem so war/ist, kann ich mir nicht so recht erklären. Leider steht auf den Tapes so gut wie nie die verwendete Marke drauf, BASF war die einzige Ausnahme, die hin- und wieder explizit erwähnt wurde (bei ca. 5 von 400 Tapes, die anderen 395 gaben die Marke nicht an!), es macht also gar keinen Sinn, die Cassetten Marke in eine Liste/Tabelle einzutragen, da man sie fast nie erfährt!

In meinen Listen (altmodisch: auf Papier!) notiere ich folgende Infos:

- Name(n) des Programms (manchmal hat ein Programm unterschiedliche Namen auf dem Tapecover vs. Bildschirm, z.B. Heartache vs. Heartbreak; Wizard vs. Wizard Spell, etc.)

- Publisher (nicht Autor oder Copyright-Inhaber; z.B. Databyte, während das Spiel von Datamost stammt)

- Ergänzungshinweise (z.B. a) aus Compilation: Four Great Games, Smash Hits, etc., b) NSB für non-standard-blocks, c) OLD-OS für Tapes die OS-A oder OS-B und ggf. Basic Rev. A benötigen)

- no load: Tape lässt sich wegen NSB nicht kopieren oder Tape lässt sich zwar kopieren, läuft jedoch mit CSIM nicht von Diskette

- T2D: Tape lässt sich kopieren, läuft mit CSIM (aktuell: Howfen-Tape-2-Disk, CasDis, CSIM 1+2; eventuell noch Transdisk 4 von C.Gibbons) von Diskette

- Data: Tape lässt sich kopieren (mittels C/D-Copy auf standard DOS 2 Disk; nur Tapes mit standard Blocks)

- Freeze: Software-Freezer für Tapes mit NSB, die sich nicht kopieren lassen oder Tapes mit standard Blocks, die sich zwar kopieren lassen aber nicht von Disk laufen (getestete Software-Freezer: a) The Freezer! von C.Gibbons, b) Pro-Copy und c) The Reset Machine aus Abbuc Magazin 29); Vorteil: Freezer-Kopie läuft selbständig als Bootdisk (Freezer wird zum Laden nicht mehr benötigt)...

Das sind erstmal mehr als genug Daten für mich, doch wie schonmal irgendwann erwähnt erstelle ich keine CAS Dateien, sondern Daten-Kopien (mittels C/D-Copy auf DOS 2 Disk) und CSIM-Versionen oder Freezer Versionen auf Diskette...

P.S.: Ich besitze keinen Freezer 2011 (oder neuer), jedoch konnte der alte Engl Turbo Freezer via Software erkannt werden, besonders einfach war der Turbo-Freezer mit XRAM zu erkennen; der AMC hatte in einigen Programmen einen Schutz gegen den Engl-Freezer (mit + ohne XRAM) eingebaut, ob auch Tapes so einen Kopierschutz haben, weiß ich nicht bzw. kann ich mangels Hardware nicht testen. Einige Tapes sind jedoch gut gegen sog. Software-Freezer geschützt...

Hallo Erhard

Erhard hat geschrieben:Leider sind neue MCs weder marktgängig noch günstig erhältlich.

OK, ist zwar auf Niederländisch, aber... Guckst Du hier.

Tschüß

Mathy

Hi,

CharlieChaplin hat geschrieben:erstelle ich keine CAS Dateien

ich finde es schade, daß Du nicht mal mindestens eine Wave-Datei erstellst. Du machst Dir sauviel Arbeit, aber das Fehlen der Wave-Datei verhindert sowohl jede nachfolgende Analyse (egal wer da was analysieren möchte) als auch die Neuerstellung eines Quasi-Originals.

Ich glaube, daß Deine Forschungsergebnisse viel Wissenswertes zum Atari Preservation Projekt beitragen können. Vielleicht klopfst Du da mal an?

CharlieChaplin hat geschrieben:NSB

Äh, was ist NSB?

Erhard

Hallo Mathy,

(neue Cassetten preiswert in bestellbaren Längen)

Mathy hat geschrieben:Guckst Du hier.

Das ist ja mal ein interessanter Hinweis.

Damit könnte man defekte Tapes reparieren. Am besten natürlich, wenn das alte Gehäuse schraubbar ist.

Fehlen halt nur ein paar Infos zur Gehäusequalität (schraubbar, zusätzliche Bandführung ja/nein, guter feiner Andruckfilz, Gleitfolie ja/nein (wär etwas übertrieben)).

Erhard

Erhard hat geschrieben:Hi,

Äh, was ist NSB?

Erhard

Nun, das stand weiter oben:

"- Ergänzungshinweise (z.B. a) aus Compilation: Four Great Games, Smash Hits, etc., b) NSB für non-standard-blocks, c) OLD-OS für Tapes die OS-A oder OS-B und ggf. Basic Rev. A benötigen)"

Dies ist meine gewählte Abkürzung für non-standard-blocks, also Tapes deren Blocklänge größer/länger als 128 Bytes ist (zB. Novagen, ESC, Creative Sparks, etc.)...

Hi,

CharlieChaplin hat geschrieben:NSB für non-standard-blocks

ah, danke.

Erhard

Hallo lieber Erhard,

ich lese diesen Thread schon seit Beginn mit und finde das ausserordentlich spannend, was Du so alles testest und rausfindest. Ich hatte damals 1983 eine 1010 zu meinem 600XL und wie oft waren die Tapes nicht mehr lesbar oder nur nach dem 2. oder 3. Versuch. Eine Plage ohnegleichen. Und die C64 user hatten Turbotape, was war ich neidisch…
Es scheint ja das schlecht von NTSC auf PAL angepasste OS die Wurzel des Übels zu sein. Kaum zu glauben, dass das erst 35 Jahre später jemand rausfindet!

Viele Grüße und "Mööööp press START" bzw CLOAD[RETURN]
F.

Hi Florian,

FlorianD hat geschrieben:ich lese diesen Thread schon seit Beginn mit und finde das ausserordentlich spannend,

vielen Dank hierfür. Ich bleibe dran, soweit es der kärgliche freie Teil der Freizeit erlaubt

Viele Grüße

Erhard

Beim Stöbern im Altirra Hardware Reference Manual http://virtualdub.org/downloads/Altirra ... Manual.pdf bin ich zufällig über folgenden Absatz auf Seite 78 gestolpert:

Atari OS C: handler

The cassette (C:) handler in the Atari OS has a bug where it can rarely compute bogus baud rates due to
improper reading of VCOUNT. The OS tries to read both VCOUNT and a frame counter maintained by the VBI
and assumes that scan line 248 or higher (VCOUNT ≥ 124) always occurs after the VBI, but this is not the case.
ANTIC triggers the VBI about a dozen cycles after VCOUNT increments to 124, so it is possible for
VCOUNT=124 to occur both before and after the VBI. The former causes an erroneous baud rate to be
computed by the OS.

Wenn sich das OS mit der Berechnung der Baudrate "verhaut" würde das sehr gut die Framing-Fehler erklären.

so long,

Hias