Hi,

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

Das ist Balsam auf meine Seele.

Denn wenn ich das OS Patche und die Baudrate festnagele, klappt das Laden sehr gut.

Was aber immer noch nicht erklärt, warum Dein Rechner sehr viel weniger Ladefehler hat als mein_e_ Rechner haben :-/

CU, Erhard

Hallo Erhard,

Erhard hat geschrieben:Was aber immer noch nicht erklärt, warum Dein Rechner sehr viel weniger Ladefehler hat als mein_e_ Rechner haben :-/

Das kann Zufall sein, bzw daran liegen, dass ich viel weniger Testläufe gemacht habe als Du und so mein Sample zu klein war.

Ich hab' mal versucht grob die Fehlerwahrscheinlichkeit abzuschätzen (wohlweislich hab' ich die Uni-Skripten zur Vorlesung Wahrscheinlichkeitsrechnung vor ca 1 Monat entsorgt, etliche Dinge hab' ich nach 25 Jahren wieder vergessen, vermutlich sind da ein paar Fehler und Ungenauigkeiten drin).

Ein Atari PAL Frame dauert 312*114=35568 CPU Zyklen. Von diesen sind 12 "gefährlich". Da der SIO Code 2 Mal VCOUNT und RTCLOK+2 lädt (zu Beginn und am Ende des Bytes) gibt's insgesamt 24 gefährliche Zyklen für den Beginn des Sync-Bytes.

Da ein Byte i.a. kürzer dauert als ein Frame (ausser die Baudrate wär mit 500 komplett daneben) kann die Messung nur beim Beginn oder am Ende des Bytes, niemals jedoch bei beiden falsch sein.

Die Wahrscheinlichkeit, dass die Messung (und damit die berechnete Baudrate) eines Blocks OK ist ist somit (35568-24)/35568 = 0.9993 (oder 99.93%).

Die Berechnung der Wahrscheinlichkeit ob ein File mit mehreren (hunderten) Blocken OK ist, ist etwas tricksig. Da der Start des nächsten Blockes nicht wirklich unabhängig vom Start des vorigen Blocks ist, sind die Ereignisse vermutlich voneinander abhängig und vermutlich auch nicht gleichverteilt sondern Gauß. Da hätte mir das entsorgte Skriptum vermutlich weiterhelfen können...

Für einge grobe Abschätzung muss es also die (vermutlich falsche) Annahme von Unabhängigkeit und Gleichverteilung tun, dann lässt sich das auch sehr einfach berechnen. Kann aber gut sein, dass die Wahrscheinlichkeit dass es gut geht in Wirklichkeit viel höher ist.

Bei den 207 Blöcken von Milkrace wäre demnach die Wahrscheinlichkeit, dass das Laden OK ist 0.9993^207 = .8695, also etwa 87%. Sprich, in ca 1 von 8 Versuchen gibt's im Durchschnitt einen Fehler.

Selbst wenn die Abschätzung daneben ist und die Fehlerquote in Wirklichkeit nur bei 5-10% liegt merkt man das in der Praxis. Ein Fehler alle 10-20 Läufe ist immer noch recht viel.

so long,

Hias

Hi Hias,

HiassofT hat geschrieben:Sprich, in ca 1 von 8 Versuchen gibt's im Durchschnitt einen Fehler.

tja, ich habe aber in 10 Versuchen eher 8 Fehler ....

Wenn ich Oszilloskop-Screenshots vergleiche, ist das Signal von APE via APE-USB-Interface am verwaschensten. Ich denke, daß das Signal jittert.

Aber auch das dürfte bei Deinem APE ja dann nicht anders sein und müßte eine recht ähnliche Fehlerquote verursachen.

Über ein SIO2PC ist es nicht wirklich besser. Auch bei einer Datasette ist die Fehlerquote sehr hoch. Nur bei einem SDrive-MAX ist sie sehr viel niedriger.

Und bei im OS fest eingestellter Baudrate klappt das auch mit APE.

Ich habe bei Lotharek "10502PC/ Sio2PC-USB" bestellt, mal schauen ob sich damit was ändert.

Was mich auch sehr interessieren würde ist wie lange es dauert, bis eine Baudrateneinstellung des POKEY am Aus- bzw. Eingang wirksam wird. Schließlich muß das ja "Durchgeklockt" werden, oder?

CU, Erhard

Ehrlich gesagt hab' ich im Moment keine Ahnung was genau da schiefgeht oder schiefgehen könnte.

Für weitere Tests ist es aber auf jeden Fall sinnvoll, den VCOUNT/RTCLOK+2 Bug zu fixen damit Du diesen als Fehlerquelle ausschliessen kannst. So lange der Bug da ist wissen wir nie 100% ob die Fehler daher rühren oder von wo anders.

so long,

Hias

Hallo Erhard & Hias,

im Rahmen von Schleife88 habe/ musste ich mich auch wieder mit der gewöhnlichen Datasette auseinander setzen.

Während die Übertragung von Schleife von einem XL direkt zum zweitem XL relativ einfach war

Code: Alles auswählen

XL1
DataOut
NOR (NAND)
Proceed
XL2

ist es beim FSK - Signal (scheinbar) nicht mehr so einfach.

Also habe ich eine Datasette genommen, eine Kassette rein und geladen (hier Jet Boot Jack 139 Block). Wobei es mir nicht darauf ankam ob das Programm vollständig geladen wird.
Dann habe ich auf der PCB der Datasette das "Signal vom Band" gesucht. Am Ausgang des 1. Transistor (Q5) und am Eingang des OPV (PIN9) konnte ich das Signal gut erkennen.
Was jedoch nicht funktionierte, das Signal am Eingang des 1. Transistor (Q5) bzw. am Tonkopf nachzuweisen. Die Störungen durch diverse SNT und LED waren erschreckend hoch. Mit einem DSO konnte ich das Signal gar nicht nachweisen. Nach Abschalten von LED und SNT war auf einem analogen Oszi ein Signal im einstelligen mV Bereich vorhanden. Ob solche Störungen auch das Laden eines Programmes beeinflussen, kann ich nicht einschätzen. Auf jeden Fall waren die Störung größer als das Nutzsignal. Erstaunlich, dass ein Laden überhaupt funktionierte. Vermutlich leisten die Filter in der XC12 gute Arbeit. Ich weiss auch nicht welche Störungen ich über die Messleitung eingefangen habe.

Gruß

Nun,

eine recht gängige Fehlerquelle bei mir war/ist die (Aufnahme)Lautstärke der A8 Cassette. Wenn ich die 30+ Jahre alten A8 Tapes mit meiner 1010 direkt abspiele, so gibt es da recht viele Hänger und oftmals wird das Programm wegen zu geringer Lautstärke gar nicht erkannt. Bei mikroskopisch-kleinen Kratzern oder Knicken (sichtbar nur mit Lupe oder Mikroskop) hält die 1010 sofort an bzw. stürzt sofort mit einer Fehlermeldung ab...

Irgendwann hat mich das sehr genervt, seither stecke ich alle A8 Tapes in meine Hifi-Anlage und a) spiele sie dort mit meinem JVC Tapedeck ab und b) verstärke die Lautstärke mit meinem Pioneer CD-Rekorder (im Aufnahme-Pause Modus, Aufnahmeregler zumeist auf maximum gedreht) der mittels Tape-Adapter mit der 1010 verbunden ist. Ca. 80% der Tapes die zuvor mit der 1010 ständig abstürzten laufen nun zumeist fehlerfrei (nur 20% laufen auch weiterhin nicht). Alle micro-Kratzer oder micro-Knicke werden vom Hifi-Tapedeck einfach ignoriert und sodann die Daten auch von der 1010 mit Tape-Adapter akzeptiert. Tapes die ursprünglich zu leise waren sind nun endlich laut genug. Kurzum, bei 10 fehlerhaften Tapes liefen nachher 8 via Hifi-Anlage (Tapedeck + CDR) und Tape-Adapter in der 1010 einwandfrei und ich konnte die Daten kopieren. Natürlich bewirkt die Hifi-Anlage bzw. das Tapedeck keine Wunder, richtig fette Knicke auf der A8 Cassette sind natürlich weiterhin hörbar und führen zum Absturz des A8 Kopierprogramms. Und manchmal foltern die Cassetten mein Tapedeck (und meine Ohren!), weil sich die Rädchen gar nicht oder nicht richtig drehen wollen (hörbares, lautes quietschen, häufiges Stoppen der Cassette)...

Habe auch einige A8 Tapes auf CD-RW aufgenommen (statt Aufnahme-Pause einfach Aufnahme mit 44khz, stereo) und verwundert festgestellt, dass die 1010 zwar die Daten von CD problemlos akzeptierte, jedoch nachdem ich die CD-Aufnahmen am PC in WAV konvertiert hatte (16Bit, stereo, 44khz), die meisten WAVs mittels A8CAS nicht in fehlerfreie CAS Dateien konvertiert werden konnten (A8CAS gab dutzende Fehler aus). Also habe ich es gelassen, auf diese Weise CAS Dateien auf dem PC zu erstellen (keine Ahnung, warum das so nicht funkt. will). Könnte zwar mein Tapedeck direkt an den PC anschließen, doch wenn A8CAS die Daten von der CD schon nicht akzeptiert, warum sollte es dann die Daten vom Tapedeck akzeptieren ?

P.S.: Um die 1010 zu betreiben nutze ich normalerweise SIO + Netzteil, bei der 1010 mit Tape-Adapter nutze ich jedoch nur SIO (kein NT). Dadurch gibt es keine Gleichlaufschwankungen/Motorschwankungen und die Daten kommen trotzdem an (die Rädchen des Tape-Adapters müssen sich nicht drehen, es reicht wenn der Tonkopf des Tape-Adapters die Daten wiedergibt bzw. an den Tonkopf der 1010 weiterreicht)...

CharlieChaplin hat geschrieben:Habe auch einige A8 Tapes auf CD-RW aufgenommen (statt Aufnahme-Pause einfach Aufnahme mit 44khz, stereo) und verwundert festgestellt, dass die 1010 zwar die Daten von CD problemlos akzeptierte, jedoch nachdem ich die CD-Aufnahmen am PC in WAV konvertiert hatte (16Bit, stereo, 44khz), die meisten WAVs mittels A8CAS nicht in fehlerfreie CAS Dateien konvertiert werden konnten (A8CAS gab dutzende Fehler aus)

Das liegt wahrscheinlich daran das du dann 2 mal konvertierst und mit jeder Konvertierung gibt es Verluste. Ich habe sehr gute Erfahrungen gemacht indem ich mein Tapedeck direkt an meine PC Soundkarte angeschlossen habe und es mittels "Audacity" in WAV Format aufgezeichnet habe.

Gruß
Thomas

Hallo,

HiassofT hat geschrieben:Ehrlich gesagt hab' ich im Moment keine Ahnung was genau da schiefgeht oder schiefgehen könnte.

Für weitere Tests ist es aber auf jeden Fall sinnvoll, den VCOUNT/RTCLOK+2 Bug zu fixen damit Du diesen als Fehlerquelle ausschliessen kannst. So lange der Bug da ist wissen wir nie 100% ob die Fehler daher rühren oder von wo anders.

so long,

Hias

Das scheint nicht der einzigste Fehler im Kassetten-Treiber zu sein. Ich habe per Zufall gesehen, dass nach den Speichern eines Basic-Programms mit CSAVE am DataOut ein (gerundet) +5V / 5,3KHz Signal ausgegeben wird. Wozu das?

Ein END sollte alle Kanäle schließen.
Sollte, nur ist es jetzt der 6-fache Wert von rund +5V / 31,7 KHz !?!

Erst ein Reset beendet den Spuk.

Getestet mit 130XE, 800XL, 600XL, XL/XE OS Rev 2 und SPOS 1.33N, ATARI-Basic (Rev.B)

Gruß

So ein F***,

ich hab hier soeben eine kilometerlange Antwort geschrieben und beim Absenden kam die Meldung, daß ich mich neu einloggen muß. Diesen Fehler hatte ich schon ewig nicht mehr.

Ich hab aber genau null Bock, alles noch mal zu tippen.

Sollten wir auf der Fujiama drüber sprechen.

CU, Erhard

Erhard hat geschrieben:So ein F***,

ich hab hier soeben eine kilometerlange Antwort geschrieben und beim Absenden kam die Meldung, daß ich mich neu einloggen muß. Diesen Fehler hatte ich schon ewig nicht mehr.

Ich hab aber genau null Bock, alles noch mal zu tippen.

Sollten wir auf der Fujiama drüber sprechen.

CU, Erhard

Habe ich auch schon mehrmals hier berichtet (und das nervt mich immer noch). Wenn ich längere Antworten im Abbuc Forum schreibe oder zwischendrin mal zum Essen muss (weil Frau gerade zu selbigem ruft), dann ist beim anschließenden Absenden der Text komplett weg, mit dem Hinweis, dass man sich neu einloggen muss.

Als Tips und Antworten habe ich bisher nur gesagt bekommen, dass ich a) den Antwort-Text vor dem Absenden kopieren könne (das mache ich seither fast immer, wenn ich es mal vergesse - Text wech) oder b) den Text in einem Editor o.ä. schreiben und dann mittels copy+paste einfügen könne (das mach ich nie)... aber an dem eigentlichen Problem wurde bis heute nicht gearbeitet bzw. etwas verändert...

Wenn ich im AA Forum eine Antwort schreibe, dann kann ich zwischendurch eine längere "Sitzung" halten oder Harry Potter 1-8 gucken und wenn ich den Text danach erst absende gibt es trotzdem keine Probleme, der Text erscheint vollständig im Topic, ohne dass ich mich nochmal einloggen muss. (Wenn der Text aber einmal gepostet + erschienen ist, so hat man als non-subscriber nur ca. 15 Minuten Zeit ihn zu editieren, wurde als Sicherheit eingebaut, damit manche Querulanten ihre Aussagen nicht um 180 Grad drehen bzw. total verändern.)

-----

Zitiere hier mal aus dem Spezialforum, Topic "Forumsoftware verrückt geworden?" von 2015...
Re: Forumsoftware verrückt geworden?

Beitrag von CharlieChaplin » So Nov 08, 2015 6:06 pm
Nunja,

ein anderes Problem besteht darin, wenn man lange Antwort-Texte für ein Forum-Topic schreibt.

Man meldet sich zunächst ordnungsgemäß an bzw. loggt sich ein und antwortet auf einen Topic. Dauert das Schreiben der Antwort länger als x-Minuten (bei mir 10 Minuten?) und man drückt am Ende auf den "antworten" Button, so kommt das System wieder mit dem Login - und danach ist der ganze zuvor geschriebene Text weg !!

Das ist mir schon mehrmals passiert, zuletzt gerade eben. Zumeist habe ich dann keine Lust, den Text nochmal neu zu schreiben und der User erhält dann halt keine Antwort auf seine Frage...

Das Problem, kenne ich auch zur Genüge...
Ich schreibe dann halt immer - wenn es nicht bloß eine kurze Antwort ist - erstmal lokal im Notepad (Editor)
und kopiere es dann später als Forumposting.
Ist jetzt nicht die Knallerlösung, aber schont ungemein die Nerven .

Gtx.,
andY

Hallo Leute

Hoffentlich kommt Carsten dieses Jahr zur Fujiama, damit er uns erzählen kann, wie weit er mit der neuen Forumssoftware ist.

Tschüß

Mathy

Hi,

ich hatte mir angewöhnt, vor Berühren des ABSENDEN Knopfes den Text in die Zwischenablage zu kopieren. Irgendwie habe ich es mir wieder schleichend abgewöhnt. Muß ich dringend wieder ändern. Das nervt zwar ein bischen, aber deutlich weniger, als wenn der Text ganz weg ist und der blöde Browser ihn bei "zurück" auch nicht wieder zum Vorschein bringt.

Vielleicht liegt das an der Lebenszeit des Anmeldecookies?

Mathy hat geschrieben:Hoffentlich kommt Carsten dieses Jahr zur Fujiama, damit er uns erzählen kann, wie weit er mit der neuen Forumssoftware ist.

Ich hege die Befürchtung, daß ihm Job, Frau und Kinder da nicht allzu viel Zeit übrig lassen.

Ich hab ja schon ohne Family nicht genug freie Freizeit.

CU, Erhard

Hi,

HiassofT hat geschrieben:Für weitere Tests ist es aber auf jeden Fall sinnvoll, den VCOUNT/RTCLOK+2 Bug zu fixen
Hias

wie gesagt, wenn ich das OS anpasse und dort feste 600 Baud Leserate programmiere, dann treten Fehler so gut wie nie auf. Ist natürlich keine Lösung. Ich denke, der Atari hat zu oft Probleme beim Zählen oder Messen der Sync-Bits. Vielleicht Spikes, Störungen, zu flache Flanken oder was weiß ich.

dl7ukk hat geschrieben:

Bei welcher Datasette beschreibst Du das mit Q5? Ich hab leider nur Schaltpläne von einer 1010 und Q5 in der 1010 muß ja nicht an der gleichen Stelle sitzen wie Q5 in einer XC11 oder XC12.

CharlieChaplin hat geschrieben:A8CAS gab dutzende Fehler aus

Ich komme mit A8CAS ziemlich gut klar. Man darf einen Unterschied nicht vergessen: der Atari weiß, was er vom Band zu lesen hat. A8CAS dagegen ist ein Programm zur Umwandlung von WAVE Daten und es interprätiert dabei keine Laderoutine oder so was. Also weiß A8CAS auch nicht, ob ein Spike ein Spike oder ein Kopierschutz ist. Deshalb muß der Anwender bei A8CAS die Intelligenz in den Verarbeitungsvorgang einbringen. Ich verweise da auf meine Magazinbeiträge.

dl7ukk hat geschrieben:Basic-Programms mit CSAVE am DataOut ein (gerundet) +5V / 5,3KHz Signal

Ich vermute da mal einfach Bugs in den Routinen CSAVE und END. Am besten wäre es, wenn am Ende eines Abspeichervorgangs auf Band noch mindestens eine halbe Sekunde SPACE gesendet wüde und nicht mit der letzten Flanke des letzten Bits auch der Motor abgeschaltet würde.

CU, Erhard

Hallo Erhard,

dl7ukk hat geschrieben: Am Ausgang des 1. Transistor (Q5) und am Eingang des OPV (PIN9) konnte ich das Signal gut erkennen.

Erhard hat geschrieben:Bei welcher Datasette beschreibst Du das mit Q5? Ich hab leider nur Schaltpläne von einer 1010 und Q5 in der 1010 muß ja nicht an der gleichen Stelle sitzen wie Q5 in einer XC11 oder XC12.

Sorry; hatte ich nicht erwähnt --> XC12

Auszug:

Ehrhard hat geschrieben:Ich vermute da mal einfach Bugs in den Routinen CSAVE und END. Am besten wäre es, wenn am Ende eines Abspeichervorgangs auf Band noch mindestens eine halbe Sekunde SPACE gesendet wüde und nicht mit der letzten Flanke des letzten Bits auch der Motor abgeschaltet würde.

Denke ich auch!





Gruß

Erhard hat geschrieben: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

Data Becker, schnell geschrieben für die schnelle Mark.....hab' mich schon bei den Peeks/Pokes geärgert, dass sich der Autor nicht an die offiziellen Einsprungadressen gehalten hat.

Hallo Erhard

Schau doch mal hier im Mitgliederbereich bei den Schaltplanen nach. Da gibt's "130 - Servicemanual Recorder XC 11 + XC12".

Tschüß

Mathy

Hi,

dl7ukk hat geschrieben:XC12-Schaltplan.jpg.zip

oh, danke. Bei Jerzy hatte ich schon zu suchen versucht, aber irgendwie hat mein Link zu dessen Webseite zuletzt ins Nirvana gezeigt (nicht die Band).

slx hat geschrieben:Data Becker, schnell geschrieben für die schnelle Mark.....hab' mich schon bei den Peeks/Pokes geärgert, dass sich der Autor nicht an die offiziellen Einsprungadressen gehalten hat.

Tja, vielleicht hatten die damals noch kein von Atari zur Verfügung gestelltes OS Quellisting

Mathy hat geschrieben:Schau doch mal hier im Mitgliederbereich bei den Schaltplanen nach. Da gibt's "130 - Servicemanual Recorder XC 11 + XC12".

Ich finde im Mitgliederbereich keine Rubrik "Schaltpläne", auch nicht bei den Downloads. Aber vielleicht hast Du ja eine "special extended edition directors cut uncut-version" der ABBUC Webseite ?

CU, Erhard

Erhard hat geschrieben:

Mathy hat geschrieben:Schau doch mal hier im Mitgliederbereich bei den Schaltplanen nach. Da gibt's "130 - Servicemanual Recorder XC 11 + XC12".

Ich finde im Mitgliederbereich keine Rubrik "Schaltpläne", auch nicht bei den Downloads. Aber vielleicht hast Du ja eine "special extended edition directors cut uncut-version" der ABBUC Webseite ? :-)

Ist etwas versteckt (unter Baupläne->ABBUC Bauplan Service), mit der Suchfunktion und dem Begriff "XC12" ist das Manual aber auffindbar:
http://www.abbuc.de/mitgliedschaft/down ... xc-11-xc12

Zum Thema gut versteckt: ich hatte letztens nach den kommentierten OS Listings von kr0tki / Tomasz Krasuski gesucht (die sind SEHR hilfreich und gut!), die (mWn) aktuellste Version gibt's hier:
https://atariage.com/forums/topic/20113 ... nt-4118825

so long,

Hias

dl7ukk hat geschrieben:Die Störungen durch diverse SNT und LED waren erschreckend hoch.

Das auch ohne SNT und LED-Lampen das Signal nicht so toll war, müssen auch die Entwickler der XC12 bemerkt haben und haben noch einen zusätzlichem Kondensator von 10nF eingebaut. Im Schaltbild (Auszug) habe ich diesen Kondensator rot dazu gemalt.


Auf dem Foto der Leiterplatte ist schön zu erkennen, dass zum Einbauen des zusätzlichen Kondensators die Lötaugen aufgebohrt wurden. Damit auch die "Beinchen" des Kondensators Platz haben.



XC12 PCB: PM 440I-4 Rev.A

Gruß