Hallo,

da ich derzeit einige 1010S, 1010C, XC11 und XC12 zur Reparatur habe war und bin ich gezwungen, mich mit dem Thema zu beschäftigen.

Beim Laden habe ich häufige Fehlschläge und ich dachte zuerst, es läge an den Laufwerken.

Also habe ich mit einem HiFi-Tapedeck einige Originale in Form von WAVE-Dateien digitalisiert, Störungen aus den WAVE-Dateien rausgeschnitten und dann mit WAV2CAS entsprechende HEX und CAS Dateien erzeugt.

In den HEX Dateien kann man prima lesen, ob die Prüfsumme der Datenblöcke OK ist und wie lang jeweils die Gaps sind. Meine Vorlage sind jetzt also fehlerfreie CAS Dateien.

APE kann CAS-Dateien über das USB-Interface an einen echten Atari so abgeben, als wäre ein Cassettenlaufwerk angeschlossen.

Hier bekomme ich aber leider auch recht oft Lesefehler - und zwar meistens Error 143. Hierbei handelt es sich um einen Rahmenbitfehler, das heißt daß mit Start- und Stopbit irgendwas nicht in Ordnung ist.

Mit dem Freezer habe ich mir dann im Fehlerfall die Datenblöcke im Lesepuffer des Atari angeschaut. Bei bislang allen Rahmenbitfehlern steht im Puffer:

03FD: 55 55 F8

Die beiden 55 sind die Bitfolgen, mit denen der Atari die Baudrate mißt. Danach kommt das Byte, welches das Format des Datenblockes angibt. Bei einem vollen Datenblock muß das Byte auf $FC lauten.

In der HEX und CAS Datei steht ein FC drin.

Mit einem Logikanalysator habe ich D_IN mitgeschnitten und ein RS232 Interpreter erkennt dort ebenfalls 55 55 FC ...

In Binär (rückwärts, da im seriellen Datenstrom das niedrigste Bit zuerst kommt) sind:

$FC = % 00111111
$F8 = % 00011111

Das sieht für mich nun so aus, als würde der Atari / POKEY das Startbit als Datenbit 0 lesen, womit aus $FC eben $F8 wird.

Die Frage sind:

- warum passiert das
- warum nicht immer
- warum auch nicht zwingend bei den gleichen Blöcken

Mit dem 400er OS scheint der Fehler seltener aufzutreten, aber da bin ich noch nicht sicher.

Nun, wer hat eine Idee? Kleiner Bug im XL OS?

Ich habe mir mal flüchtig die SYNC-Routine angeschaut. Wenn ich das richtig sehe, werden im ersten Durchgang 10 Bits gelesen, um an der dafür nötigen Zeit die Baudrate auszupeilen. Dann kommt noch mal was mit 9 ? Bits ? Das wären dann Startbit und 8 Datenbits. Das Stopbit dann eben nicht. Paßt ja auch, dann hat der POKEY etwas Zeit, das Startbit zu finden.

Ich müßte mich da jetzt echt reinknieen, aber vielleicht kann ja jemand den Quellcode schneller verstehen als ich.

Viele Grüße

Erhard

Hi,

hier ein Nachtrag mit Infos zum Timing, die ich herausgefunden habe:

Bei 600 Bit/s ist ein Bit 1,666 ms lang, 10 Bits ergo 16,666 ms.

Gemäß "All About Cassett Tapes" hat VCOUNT vor und nach den 10 Bits idealerweise ungefähr den gleichen Wert.

Die Rechnung geht wie folgt:

NTSC:
262 Scanlines x 114 Taktzyklen pro Scanline / 1789772 Hz = 0,01668 Sekunden = ca 16,68 ms
Das entspräche in der Tat der 10 Bits aus dem Syncbyte.

PAL:
312 Scanlines x 114 Taktzyklen pro Scanline / 1773447 Hz = 0,02 Sekunden
Das entspricht eher nicht der Dauer der 10 Bits aus dem Syncbyte und entspräche eher 500 Bit/s.

Die Routine im OS zum Berechnen der Bitrate liest ja nun das PAL/NTSC Flag aus und sollte da entsprechende Anpassungen vornehmen.

Quellen:
All about Cassette Tapes, Atari, 1979-11-17
PAL/NTSC, www.myatari.com/nirdary.html
ANTIC, GTIA and timing info, www.atarimax.com/jindroush.atari.org/atanttim.html

Hallo,

es gibt ein paar neue kleine Erkenntnisse.

1) Unterspannung
---------------------
Bei Datasetten wie der XC12 wird das Laufwerk allein über die SIO-Leitung MOTOR mit Strom versorgt. An der Datasette gemessen habe ich 4.4 Volt bei zwei SIO-Kabeln, verbunden über einen SIO-Hub. Den SIO-Hub hatte ich an ein eigenes Netzteil angeschlossen - bringt aber nichts, da ja die MOTOR-Leitung direkt vom Atari kommt und somit nicht von der Stromversorgung des SIO-Hub profitiert. Um wieviel eine solche Unterspannung nun das Signalverhalten verschlechtert konnte ich bislang nicht ermitteln. Besser dürfte es jedoch wohl kaum werden.

2) SIO-Kontakte
-------------------
Durch Zufall hab ich ein SIO-Kabel bewegt, während die Datasette aktiv aber der Ccomputer noch nicht mit Laden beschäftigt war. Dabei hat die D-IN LED des SIO-Hub geflackert. Das lag an einer leichten oxydierung der Kontakte im SIO-Stecker. Hier verbirgt sich also eine weitere Fehlerquelle. Wenn man einen SIO-Stecker mit flachen Federkontakten hat, dürfte sich dieser mit einem der Länge nach halbierten Streichholz (ohne Zündkopf) einigermaßen reinigen lassen. Dünne Pappe könnte reißen. Hier besteht noch Probier-Bedarf.

3) Signalstärke
------------------
Einige Cassetten haben von der Signalstärke nachgelassen. Um wieviel kann man eigentlich nur in einem Cassettenrekorder feststellen, der über justierte Aussteueranzeigen verfügt. Bei -6 dB ist meines Wissens die Spannung schon nur noch halb so hoch. Entsprechend stärker wirken sich Störsignale aus. Als Gegenmaßnahme kommt hier nur eine Neuaufnahme der Cassette in Betracht. Siehe hierzu mein Artikel im Forum "Anderes" unter ATPP.

Erhard

Hallo,

mal wieder einige neue Erkenntnisse.

Man sollte ja meinen, daß wenn man als Ladevorlage eine .CAS Datei hat, die ja nun mal digital ist und diese Datei dann über ein Interface APE mit USB-Interface oder SDrive-MAX lädt, man immer oder zu mindest in der Regel zu einem gleichen Ergebnis kommt - komme ich auch, aber weit anders als gedacht:

Über APE mit dem USB-Interface schlägt das Laden sehr häufig fehl.

Über ein direkt angeschlossenes SDrive-MAX schlägt das Laden deutlich seltener fehl, aber einmal pro Booten reicht ja auch ....

Wenn man das SDrive-MAX über einen SIO-Hub mit externer Stromversorgung betreibt, klappt das Booten relativ oft.

Eine volle Spannungsversorgung ist also offenbar sehr wichtig.

Warum das mit APE und dem USB-Interface so oft fehlschlägt muß ich noch versuchen herauszufinden.

CU, Erhard

Erhard hat geschrieben:Hallo,

es gibt ein paar neue kleine Erkenntnisse.

1) Unterspannung
---------------------
Bei Datasetten wie der XC12 wird das Laufwerk allein über die SIO-Leitung MOTOR mit Strom versorgt. An der Datasette gemessen habe ich 4.4 Volt bei zwei SIO-Kabeln, verbunden über einen SIO-Hub. Den SIO-Hub hatte ich an ein eigenes Netzteil angeschlossen - bringt aber nichts, da ja die MOTOR-Leitung direkt vom Atari kommt und somit nicht von der Stromversorgung des SIO-Hub profitiert. Um wieviel eine solche Unterspannung nun das Signalverhalten verschlechtert konnte ich bislang nicht ermitteln. Besser dürfte es jedoch wohl kaum werden.

Du könntest probeweise die 5V für den Motor von einem externen NT einspeisen; damit wären Spannungsschwankungen, die die Motorreglung evt. nicht mehr ausgleichen kann, eliminiert.
Evt. kommt es zu Gleichlaufschwankungen durch (überalterte) Antriebsriemen? Du könntest auf einem (einwandfrei laufendem) Hifi-Tapedeck einen Sinus aufnehmen und auf der Datasette abspielen und mit einem Scope kontrollieren ob der Sinus ohne Frequenzschwankungen wieder rauskommt.

Sleepy

Hi Sleepy,

Sleepy hat geschrieben:Du könntest auf einem (einwandfrei laufendem) Hifi-Tapedeck einen Sinus aufnehmen und auf der Datasette abspielen und mit einem Scope kontrollieren

das dürfte so nichts bringen. Damit man auf einem Oszilloskop noch irgendwas erkennen kann sollten es höchstens 10 Wellen sein. Bei 3 KHz sieht man also einen Ausschnitt von einer dreihundertstel Sekunde. Oder anders gesagt, man muß 300 mal in der Sekunde gucken, ob es 3 KHz sind

Wenn das so eiert, daß man da was sieht, dann hat das Ohr das schon lange vorher erkannt.

Und so kleine Drops auf dem Band, die einzelne Bits im Datenstrom killen, erkennt man da sowieso nicht.

Und das alles erklärt immer noch nicht, warum der am meisten auftretende Fehler der Rahmenbitfehler beim Block-ID-Byte ist.

Hast Du eine Datasette? Hast Du Tapes? Hast Du einen Freezer? Dann lade doch mal selber ein paar Tapes, halte den Rechner bei einem Fehler an und betrachte mal golfende Speicherinhalte:

2EE-2EF ;ermittelte Baudrate
300-30F ;DCB (bei 303 steht der Fehler)
3FD-47F ;CASBUF (bei 3FF steht das Block-ID-Byte)

CU, Erhard

Erhard hat geschrieben:HHast Du eine Datasette? Hast Du Tapes? Hast Du einen Freezer? Dann lade doch mal selber ein paar Tapes, halte den Rechner bei einem Fehler an und betrachte mal golfende Speicherinhalte:

Ja (diverse)
Ja (etliche; irrc auch Leaderboard-Golf )
Ja
Wäre möglich.

Wenn es wider erwarten keine "echten" Ladeabbrüche gibt, reicht es den Ladeabbruch zu provozieren (z.B. <Pause> am Tape drücken)?

Sleepy

Erhard hat geschrieben:H
3FD-47F ;CASBUF (bei 3FF steht das Block-ID-Byte)

Den ganzen Block?!? Oder reicht nur $03FF?

Sleepy

Hallo Sleepy,

Sleepy hat geschrieben:Wenn es wider erwarten keine "echten" Ladeabbrüche gibt, reicht es den Ladeabbruch zu provozieren

ne, der Fehler muß schon von selber kommen. Es geht ja genau darum herauszufinden, welche Fehler warum kommen

Sleepy hat geschrieben:Den ganzen Block?!? Oder reicht nur $03FF?

Für das ID-Byte reicht natürlich das Byte. Wenn man sehen will, ob sich der Fehler mit verschobenen/m Bit(s) durch die Daten durchziehen, bräuchte man den Block. Und wenn man auch noch wegen der Prüfsumme schauen will natürlich auch.

Bei so Emus wie APE kann man ja via Freezer in einen virtuellen Drucker "dumpen", da braucht man nix abtippen.

CU, Erhard

Hm, ich hätte das natürlich mit echter Hardware probiert (da kenne ich mich besser aus & die Hardware steht schon auf dem Tisch ).

Mal sehen ob der Datenblock auf den Bildschirm passt, dann mache ich ggf. einen echten Screenshot.

Sleepy

Hallo,

ich hab noch mal ein paar neue Daten:

Ich habe heute mal ein Oszilloskop an D_IN des POKEY angeschlossen und mir mal die Signale angeschaut. Und was ich sah war übel. Deshalb hab ich von den folgenden 4 Tests jeweils ein Video gemacht.

Als Vorlage dient eine künstlich gefertigte .CAS Datei, die bis auf das Block-ID-Byte nur $55 enthält. Dit Baudrate ist auf 600 gesetzt und der IRG auf 250 ms. Für Versuche mit analogen Geräten habe ich daraus mit Altirra eine .WAV Datei erstellt und die als Audio mit einem HiFi-Tapedeck auf eine eingemessene Fe2O3-Cassette mit -1dB Pegel aufgenommen.

Test 1 (Atari XC 12):
ein heftiges Geflacker in der Bitbreite auf dem Bildschirm. Grob gesagt schwankt das zwischen 1.45 und 1.6 ms.

Test 2 (APE mit USB Interface)
sporadisches minimales Zucken in der Bitbreite. Grob geschätzt zwischen 1.58 und 1.65 ms.

Test 3 (SDrive-MAX)
sieht nach einer absolut stabilen Bitrate aus.

Test 4 (HiFi-Tapedeck über Cassetteninterface)
genauso schlecht wie Test 1

Damit kommen eigentlich Gleichlaufschwankungen und Störungen über die Stromversorgung augenscheinlich eher nicht als primäre Ursache in Betracht. Im Fall von Test 1 und Test 4 dürften die Schwankungen wohl eher vom Tondekoder kommen. Bei den Mark- und Spacetonfrequenzen hat er aber auch nur 6-8 Wellen pro Bit.

Danach habe ich noch einmal versucht, das Spiel Milkrace zu laden. Mit der XC 12 oder über das Cassetteninterface ist das Thema nach dem zweiten oder dritten Block durch.

Komischerweise geht das über APE auch nicht viel besser. Beim dritten oder vierten Block wird das Block-ID-Byte schon fehlerhaft gelesen ($F4 statt $FC) und der erkannte Teiler für die Bitrate (DPEEK ($2EE)) ist $5B3.

Mit dem SDrive-MAX dagegen lädt Milkrace (gleiche .CAS Datei) komplett durch.

Warum geht das also mit APE, was ja nun eine digitale Quelle verwendet und eine doch ziemlich gute Signalform produziert, so schlecht?

Weiterhin interessiert mich, warum der Atari bei SDrive-MAX und bei APE als Bitratenteiler $5BE errechnet. Ich habe mal den POKEY manuell programmiert und meine, daß der Teiler für 600 Hz $5C6 ist. (Okay, der Unterschied ist ziemlich klein, wüßte ich aber trotzdem gern).

Also: weiter forschen.

CU, Erhard

Hi,

so, ich bin wieder etwas weiter.

Nachdem ich mit einem Logikanalysator mal auf 200 MHz Samplerate hochgegangen bin zeigten sich an einigen sehr wenigen Stellen doppelte Flanken von 10 ns. Allerdings nicht mitten in einem Bit sondern zu Anfang oder Ende eines Bits. Damit stellen sich dann wieder Fragen:

- kommen diese Flanken überhaupt am POKEY an?
- bekommt der POKEY die mit?
- warum bekommt der POKEY die mit? (eigentlich samplen UARTs asynchrone Daten in der Mitte des Bits)

Den offenen Fragen ungeachtet habe ich auf einem Experimentierboard eine kleine Schaltung aufgebaut, die solche hochfrequenten Überschwinger rausfiltern soll. Bei dieser heuristischen Vorgehensweise ist eine Schaltung aus zwei BS 170 MOSFETs mit je einem Tiefpass am Eingang und in der MItte entstanden.

Der Tiefpass in der Mitte wurde zu einem RC-Glied von 2K an 75 nF. Laut Internetrechner ergibt sich hier eine Grenzfrequens von ca 1000 Hz. Darauf hin habe ich mir noch mal die Schaltpläne der Atari 1010 angeschaut: auch hier gibt es vor dem Ausgangstransistor einen zweistufigen Tiefpass aus 4K7 an 0,033 uF. Auch hier ergibt sich eine Grenzfrequenz von ca 1000 Hz.

Nun, was soll ich sagen. Nachdem ich das APE-USB-Interface über meine Schaltung mit dem Atari verbunden hatte ist es mir mehrfach gelungen, das Spiel Milkrace zu laden.

Danach habe ich es mit meiner XC 12 probiert. Da geht es noch nicht ganz so gut, aber schon sehr viel besser.

Warum ist diese ganze zusätzliche Filterei nötig? Gibt es POKEY-Serien, die fehlerhaft sampeln?

Ich benötige hier Kontakt zu dem Entwickler / den Entwicklern des POKEY-VHDL-Projekts.

Viele Grüße

Erhard

Hallo Erhard,

vielen Dank das du uns "live" an deinen Experimenten teilhaben läßt.
Auch wenn ich nicht alles was du schreibst zu 100% verstehe, so ist doch der tiefere Einblick in die "Eingeweide" der Kassettentechnik auf dem ATARI eine super Sache.
Bin ja selbst Fan dieses Mediums, allein schon wegen der Möglichkeit der Tonspur...

Viel Erfolg weiterhin beim Analysieren und halt uns auf dem laufenden!

Viele Grüße

Tigerduck

Hallo,

Tigerduck hat geschrieben:Viel Erfolg weiterhin beim Analysieren und halt uns auf dem laufenden!

- schön, daß es jemand liest
- noch schöner, daß es jemanden interessiert
- am schönsten zu erfahren, daß dem so ist



Vielen Dank für die Rückmeldung (Denglisch: das Feedback)

Viele Grüße

Erhard

Na, verfolgen tu ich das auch. Wenn ich auch nicht immer alles verstehe - so tief gehen meine Kentnisse in die Tiefen des ATARIs nicht immer - ist es doch interessant zu verfolgen / beoabachten. Wenn geht helfe ich auch gerne (die Tests mit den Freezer sind nicht vergessen; ich habe nur noch nicht die Zeit gehabt / genommen).

Es ist vermutlich ein allgemeines "Problem" dass man (oder auch frau) sich nur meldet wenn es Probleme gibt oder etwas schief läuft. Wenn alles klappt und läuft bekommt man - wenn überhaupt - nur sehr spärliches Feedback...

Sleepy

Hallo Erhard

Mein Interesse zu diesem Thema ist eher Sinusförmig, dass Du dich da so reinkniest finde ich aber super.

Tschüß

Mathy

Hi Erhard,

für mich sind Deine Erkenntnisse ein Stück auf dem Weg zum Verstehen von Schleife88.
Ich danke Dir !!

Hi,

vielen Dank für euer Feedback - ich bleibe dran

Allerdings demnächst etwas seltener, da mein Urlaub rum ist.

Viele Grüße

Erhard

Hallo,

endlich habe ich mal wieder ein bischen Zeit, um hier weiter zu forschen. Ich habe so einige Tests gemacht und etwas recherchiert. Hier so ein paar Ergebnisse:

Systemtakt = PHI(0)
Systemtakt PAL: 1.773.447 Hz
Systemtakt NTSC: 1.789.772 Hz

Wenn die POKEY-Zähler im Modus 16-Bit verwendet werden, berechnet sich das Ergebnis nach

f(out) = PHI(0)/(2x(AUDF+7)

Wenn man sich nun die Routine zum Schreiben auf Cassette im OS anschaut, wird dort der Wert $05CC in AUDF3/4 geschrieben. Ausgerechnet ergibt das:

In einem PAL-Rechner:
1.773.447/(2x(1.484+7)) = 594,7

In einem NTSC-Rechner:
1.789.772/(2x(1484+7)) = 600,19

Ich habe den Wert an einem PAL-Rechner mit einem Frequenzzähler an C_out des POKEY nachgemessen. Der Wert stimmt überein.

Eigentlich müßte der POKEY mit folgendem Wert als Teiler beschrieben werden:

AUDF = 1.773.447 / (2 x 600) -7 = 1470,8725 -> 1471 -> $05BF

Da haben wir also schon mal eine Stelle im OS, wo wohl jemand eine Umstellung auf PAL vergessen hat. Nicht daß die 6 Baud Unterschied eine große Rolle spielen, aber das ist mein Anreiz nachzuschauen, was da vielleicht noch nicht stimmt.

Ich habe zwischenzeitlich eine kleine Routine in Assembler geschrieben, über die der POKEY zum Lesen von Cassettendaten direkt angesprochen werden kann. Da ist die Baudrate einfach auf 600 fest eingestellt. Was soll ich sagen? Nicht ein einziger Abbruch beim Lesen über das SIO2USB Interface von APE.

Allerdings liest die Routine die Daten bislang ohne Prüfsummenberechnung und - vergleich ein. Das kommt jetzt als nächstes. Wenn das dann nachweislich mindestens 20x fehlerfrei funktioniert werde ich es noch mit einer echten Datasette testen. Wenn das dann auch funzt liegen meines Erachtens die Ursachen für die sehr häufigen Abbrüche durch Rahmenbit-Fehler in der Art, wie das OS den POKEY vorbereitet.

CU, Erhard

Hi,

Unstimmigkeit in Büchern festgestellt PAL/NTSC ($62):

Data Becker Atari 600XL/800XL Intern
PAL=0
NTSC=1

Atari Profibuch
PAL=1
NTSC=0

Fehler im Data Becker:
$D20F -> Schattenregister 562 = $262 (562 ist aber $232)

CU, Erhard