Hi!

Ich hab den Fehler beim Schreiben bisher nur ein einziges Mal reproduzieren können, weiss aber glaubich woran es liegt: die Empfangsroutine ist etwas zu strikt bei den Timeouts.

Hier eine aktualisierte Version, die Empfangsroutine ist nun etwas toleranter, damit sollte das Schreiben bei Divisor 0 nun gehen:
http://www.horus.com/~hias/atari/ataris ... 101.tar.gz

Wegen Highspeed+Pause: hab im Kernel Treiber einen Kommentar gefunden, der darauf hindeutet dass es mit QMEG OS 3 Probleme gibt. Hab damals wohl mit allem möglichen getestet, selber verwendet hab' ich diese Version aber nie :)

so long,

Hias

Hi Hias,

ich habe auf dem M61PMV die Version 181101 problemlos installiert.


Die Kondensatoren (Data in/out, Command, Proceed) und den SIO-FiFo habe ich jetzt aus dem 600XL raus genommen, schon um klare Verhältnisse zu haben.


Beim Lesen mit 125000 Bd läuft es recht gut, es gibt zwar noch Meldungen, aber keine Abbrüche.

Beim Schreiben mit diag-ext-write.atr kommst es aber immer zu Abbrüchen.


Und mit den Kopierprogrammen Copy2000 und Sectorcopy 1.5 geht es nur noch bis Pokeydiv 4

Dafür läuft diag-ext-write nun fast ohne Probleme...


Irgendwas muss ich verändert haben, ich weiss nicht was?? Was besonders ärgerlich ist, da ich nun auch einen Lenvo ThinkPad mit Intel-Chipsatz zum Testen habe...

Da ist aber richtig der Wurm drin, nun ist auch der M61PMV richtig böse abgeschmiert ...
Lange nicht erlebt.
Schau'n wir mal

Gruß

Hi Hias,

den Fehler habe ich noch nicht gefunden. Der Versuch auf die Ver vom 25.10 zurückzugreifen, brachte auch nichts.
Am Sio2Pc(Usb) wird es wohl nicht liegen, dass ist getauscht. Der Usb-Hub sollte auch in Ordnung sein; beim Verbinden am USB Port wird von ohci auf ehci (lsusb -t) gewechselt.

Vielleicht ist beim harten Absturz des M61PMV, mehr zerstört worden, als vermutet. Und mein zweiter PC (MSI-Board) bringt es einfach nicht ....

Nun gut, ich bleibe dran.

Die Absturzursache könnte ein unsach- und unzeitgemäßes abziehen der USB-Kamera gewesen sein.

Gruß

Hi,

ich bin ein Schritt weiter. Ich kann nunmehr mit diag und HS "0" schreiben, aber nur mit "4" lesen. Ich werde heute Abend den FiFo wieder in A8 einsetzen und mal sehen was passiert. Bei HS "2" z.B. gibt es gar keinen!! Traffic.

Ich habe -nur nochmal erwähnt- die Kondensatoren von Data IN & Out und! Command & Proceed entfernt, dass sollte aber keinen Einfluss haben.



Bis dahin

Hallo Andreas!

Die Fehler bei Sektorcopy und Diskcopy sind normal, die Highspeed Routine ist zu langsam und die FIFO hat das kaschiert. Am besten ist es, wenn Du einen Sektor Kopierer ohne eigene Highspeed Routinen nimmst und ein OS mit meinem Highspeed Patch - damit sollte es dann gehen. Oder zum Testen halt die diag ATRs.

Irgendwas scheint auf Deinem PC atariserver gelegentlich zu blockieren, was dann zu Timeouts in der SIO Routine am Atari führt.

In der aktuellen Version hab' ich noch einen zusätzlichen Check eingebaut, deshalb erhältst Du dann gelegentlich Fehler im Log Fenster angezeigt ("send Command ACK failed") wenn atariserver erkannt hat, dass es unterbrochen wurde.

Der Fix in der Empfangsroutine hilft wohl nur wenig, atariserver kann nun beim Schreiben die Daten empfangen, "Receive Data Frame failed" erscheint dann nicht mehr im Log Fenster wenn atariserver blockiert war, aber die Antwort von atariserver kommt zu spät beim Atari an, also gibt's wieder ein SIO Timeout.

Eine gute Nachricht hab' ich aber auch: die Fehler von hier viewtopic.php?p=80312#p80312 kamen ziemlich sicher von den Kondensatoren - die scheinen nun behoben zu sein.

Ich habe hier am uralt Laptop und am RPi1 noch mal getestet, da funktioniert Lesen und Schreiben bei Divisor 0 wie geschmiert. Einzig als ich am RPi1 Chromium gestartet hatte hab's einen ganz kurzen Aussetzer und diag-ext-read hat eine "00 8A ..." Zeile ausgespuckt.

Schau mal ob am PC irgendwas im Hintergrund läuft das den Rechner (kurz) blockieren könnte. USB Geräte die den Bus belegen können auch stören (also abstöpseln). Festplattenzugriffe oder regelmässige CDROM checks im Hintergrund können auch eine Ursache sein, ebenso die Stromspar Modi der CPUs. Oder auch der Grafikkartentreiber. Ja, da gibt's leider viele Möglichkeiten...

Teste am besten einfach mal am Thinkpad, dann hast Du einen Vergleichspunkt.

so long,

Hias

Kurzes Update: Ich kann "00 8A ..." Command Frame Timeouts am uralt Laptop provozieren, wenn ich die Bildschirmhelligkeit verändere - das macht dann wohl ACPI Bios calls und blockiert kurz das System.

Ich hatte auch 2 Timeouts/Abbfüche beim Scrheiben, die traten auf als der Bildschirmschoner (nur Screen blank / LCD Backlight abschalten) aktiv wurde. Und ein "Receive Data Frame failed" als ich den Bildschirm wieder aufgeweckt hatte (Touchpad berührt).

so long,

Hias

Hi Hias,

meine "Rechentechnik" habe ich wieder in den Griff bekommen und habe die selben Ergebnisse wie vorher. Unbedachtest nächtliches Hantieren rächt sich manchmal.

Ich habe nun den IBM (Lenovo) ThinkPad R52 zum Testen benutzt. Infos über den Laptop sind angehängt.
Aber es ist, trotz Intel - Chipsatz genauso wie bei den Desktop Rechnern mit AMD.

Schreiben geht fast immer mit Pokey-Div 0 mit minimalen Aussetzern.

Lesen geht ohne Probleme bis Pokey-Div 4 wunderbar. Ohne die Tiefpässe in den I/O Leitungen des XL's und mit dem Sio-FIFO von Simius (bei den Desktop Rechnern mit AMD zusätzlich mit USB-Hub) läuft es bis Pokey-Div 0 mit seltenen Aussetzern (und ab Pokey-Div 2) richtig stabil.

Wenn die COMMAND-Steuerung abgeschaltet ist (none), läuft read und write bis Pokey-Div 1 super, Und bei "0" mit seltenen Aussetzern, mit diag......atr. Die Sektorkopierer sind da etwas toleranter. Ich kann natürlich nicht genau sagen, ob dabei doch einzelne Bytes fehlerhaft kopiert wurden. --> siehe Folgendes

Beim Testen bin ich noch auf etwas Anderes gestoßen. Die md5 Prüfsummen, der mit einem Sektorkopierer erstellten Ziel-ATR, waren nicht identisch mit denen der Quell-ATR. Ich habe das am R52 mehrfach überprüft.
atariserver: c LW #2; 180kB oder 360kB und am Ende mit w gespeichert. Es wurde jedes mal für das Ziel-ATR eine von der Quell-ATR verschiedene Prüfsumme, aber (für das Ziel-ATR) immer die selbe Prüfsumme (natürlich 180/360kB verschieden) angezeigt. Ein willkürlicher Fehler läßt sich damit wohl ausschließen. Ich weiss nicht, wie ich sehen kann, ob die Prüfsumme wirklich vom neu geschriebenen ATR ist, oder vom ATR aus dem Cache kommt. Das würde zumindest die Übereinstimmung der Prüfsummen beim Ziel-ATR erklären. (Die Ziel atr hatten den selben Namen.atr - Das sollte ich ändern)

Dein Code scheint/ ist besser als meine HW. Wenn Du noch Infos brauchst, melde Dich!

Warten wir auf das RPI. Ich hatte bei Dir gelesen .... Raspbian, aktuelle Version, Levelshifter, war das Alles, was ich brauche?

Vielen Dank für das prima Projekt.

Gruß

Hallo Andreas,

wieder mal vielen Dank für die Infos und Tests!

dl7ukk hat geschrieben:Ich habe nun den IBM (Lenovo) ThinkPad R52 zum Testen benutzt. Infos über den Laptop sind angehängt.
Aber es ist, trotz Intel - Chipsatz genauso wie bei den Desktop Rechnern mit AMD.

Ich hab' grad noch mal mit meinem alten Pentium 4 (IDE Festplatten, Nvidia Grafikkarte) getestet, diag meldet da ab und zu "00 8A ..." Timeouts wenn auf die Festplatte zugegriffen wird - zB wenn ich Firefox starte. So lange ich den Rechner "in Ruhe" lasse läuft es aber mit dem FTDI Adapter stabil.

Hab' dann auch noch mal am RPi1 mit FTDI Adapter den "Mischbetrieb" mit der Speedy getestet, Speedy auf D1:, atariserver auf D2:, Sectorcopy aus dem Speedy ROM gebootet und dann Images hin und her kopiert. Hab' bei atariserver verschiedene Pokey Divisor ausprobiert (9 wie bei der Speedy, runter bis 4) und mit / ohne Command Line - hat soweit alles gut geklappt!

Beim Testen bin ich noch auf etwas Anderes gestoßen. Die md5 Prüfsummen, der mit einem Sektorkopierer erstellten Ziel-ATR, waren nicht identisch mit denen der Quell-ATR. Ich habe das am R52 mehrfach überprüft.
atariserver: c LW #2; 180kB oder 360kB und am Ende mit w gespeichert. Es wurde jedes mal für das Ziel-ATR eine von der Quell-ATR verschiedene Prüfsumme, aber (für das Ziel-ATR) immer die selbe Prüfsumme (natürlich 180/360kB verschieden) angezeigt. Ein willkürlicher Fehler läßt sich damit wohl ausschließen. Ich weiss nicht, wie ich sehen kann, ob die Prüfsumme wirklich vom neu geschriebenen ATR ist, oder vom ATR aus dem Cache kommt. Das würde zumindest die Übereinstimmung der Prüfsummen beim Ziel-ATR erklären. :?: (Die Ziel atr hatten den selben Namen.atr - Das sollte ich ändern)

Das ist interessant. Kannst Du mir mal das original ATR und das vom Sektor Kopierer erzeugte ATR schicken? Dann schau ich mir das mal genauer an.

Evtl. sind auch nur ein paar unbenutzte Bits im ATR Header unterschiedlich. Lade das original ATR in atariserver und speichere es dann unter einem neuen Namen ab. Vergleiche dann mal die md5sum dieser beiden Files.

Ich hab hier mal mit Copy2000 2.41D und Divisor 4 getestet, da war das kopierte ATR identisch zum original ATR.

Warten wir auf das RPI. Ich hatte bei Dir gelesen .... Raspbian, aktuelle Version, Levelshifter, war das Alles, was ich brauche?

Ja, das ist's im Wesentlichen. Du kannst auch einfach mal mit dem FTDI Adapter oder SIO2PC USB testen, das ist das was ich die letzten Tage hauptsächlich gemacht habe.

Noch ein paar allgemeine Tips zum RPi:
Nimm am besten das offizielle RPi Netzteil (mit 5.1V und 2.5A). Die RPis sind recht pingelig was die Stromversorgung angeht und die meisten Handy Ladegeräte schaffen das nicht ordentlich - was dann zu sehr seltsamen Fehlern führen kann.

Bei den SD Karten gibt es enorme Unterschiede in der Performance. Ich verwende aktuell die Sandisk Extreme A1 mit 32GB. Die läuft gut und flott im RPi und ist gut und relativ günstig zB bei Amazon erhältlich. Vorsicht mit eBay, Alibaba, Amazon Marketplace und co, es sind leider viele Fälschungen unterwegs.

so long,

Hias

Hallo Hias,

Es war die Nachtigall und nicht die Lerche !

Da ich an diesem Wochenende <in den Nächten> meiner Nebenbeschäftigung *dem Geld verdienen* nachgehen muss, wollte ich diese Zeit auch nutzen. ... Den zum Testen benutzte 600XL (64kB) kann ich jedoch nicht mitnehmen, weil er "Hausarrest" wegen der abgebrochenen Invers Taste hat. Also habe ich einen 130XE genommen, der mich schon auf die VCFB2018 begleitete.

Um sicher zu sein, dass der 130er die VCFB2018 gut überstanden hat, habe ich ihn nochmal zum Testen angeschlossen. Und was passiert; alles läuft wie geschmiert. atariserver, Pokey-Divisor 0 ist kein Problem! Mit dem TP Laptop sogar ohne USB-Hub. Beim MSI MS-7327a Tower mit USB-Hub. Alles bei Pokey-Divisor 0.
Schau Dir den Bildschirm an.

Habe nicht erwartet, dass so etwas möglich ist. Zumal der 600XL völlig in Ordnung ist (nur die abgebrochene Taste). Es lag am ATARI 600XL !!!

Dabei ist mir noch was beim atariserver aufgefallen.

(load) l #1 MyDos360K.atr
c #2 1440 D

Also ein ATR's mit 360K, wie von einer XF. #1 MyDos gebootet und per Dos Menü mit "J" die "Disk" nach #2 kopiert. (Das XE-OS hat Hisio-Patch ) In dem Moment, wo MyDos die Disk/ATR in #2 formatiert, wird das ATR in #2 auf 720D halbiert! upps. Das ist sicher ein Fehler von MyDos beim Erkennen der Disk/ATR. Aber blöd ist es schon.
In diesem Zusammenhang gleich die Frage, was passiert mit dem Speicher, wo das ATR liegt. Ich habe auch schon bei anderen Flop-Emulatoren bemerkt, dass ein Format-Befehl die Größe ATR ändern kann. Kleiner wird kein Problem sein, aber größer? Überschreibt das ATR mit seiner neuen Größe einfach benachbarte Speicherbereiche? Das könnte fatal sein.

Dort ist auch Copy 2000 V 2.51Q drauf, wo mir die fehlerhaften Prüfsummen auffielen. Schicke mir doch bitte das Copy2000 2.41D, dann kann ich das vergleichen.

Bei Deinem atariserver werden mit Trace (T 1) die gelesene und geschrieben Sektorenummern mit read% und write% ausgegeben. Bei write steht in Klammern (verify) (oder so, habe ich jetzt nicht notiert...) Auf was bezieht sich dieses (verify) (oder so, habe ich jetzt nicht notiert...) Du liest doch nicht wirklich noch einmal die Sektoren vom ATR, oder?

Das ist interessant. Kannst Du mir mal das original ATR und das vom Sektor Kopierer erzeugte ATR schicken? Dann schau ich mir das mal genauer an.

Evtl. sind auch nur ein paar unbenutzte Bits im ATR Header unterschiedlich. Lade das original ATR in atariserver und speichere es dann unter einem neuen Namen ab. Vergleiche dann mal die md5sum dieser beiden Files.

Das kann ich erst Morgen am Tage machen, die Antwort dann wieder in der Nacht. Es kann natürlich an dem 2000 2.51 Q liegen. Da ein ATR eben kein echtes QD ist.

Noch ein paar allgemeine Tips zum RPi:
Nimm am besten das offizielle RPi Netzteil (mit 5.1V und 2.5A). Die RPis sind recht pingelig was die Stromversorgung angeht und die meisten Handy Ladegeräte schaffen das nicht ordentlich - was dann zu sehr seltsamen Fehlern führen kann.

Danke für die Info, da werde ich drauf achten, auch wenn das Paket schon unterwegs ist. Aber zumindest kann ich die Spannung überwachen und ggf. ein größeres C noch mit anschließen.

Bei den SD Karten gibt es enorme Unterschiede in der Performance. Ich verwende aktuell die Sandisk Extreme A1 mit 32GB. Die läuft gut und flott im RPi und ist gut und relativ günstig zB bei Amazon erhältlich. Vorsicht mit eBay, Alibaba, Amazon Marketplace und co, es sind leider viele Fälschungen unterwegs.

Bei meiner RPI 2B lag eine Trancend 8GB bei, die werkelt nun eine ganze Weile schon ohne zu murren. Da habe ich Ersatz da und wollte so was nehmen. Zu langsam?

Gruß

Nachtrag:

Copy2000 2.41D hat sich erledigt
Bin auf AA fündig geworden.
Danke CharlieChaplin

md5sum ...

Version 2.51Q does the same but with 90k/130k/180k/360k - it can read the 360k/DSDD XF551 format, but it does not write the XF551 360k format (the difference here is the handling of the backside, Copy 2000 writes the backside of a 360k disk in the opposite way the XF551 does, so don`t use Copy 2000 2.51Q with an XF551 drive...)

Hallo Andreas,

dl7ukk hat geschrieben:Habe nicht erwartet, dass so etwas möglich ist. Zumal der 600XL völlig in Ordnung ist (nur die abgebrochene Taste). Es lag am ATARI 600XL !!!

Interessant. Im Moment hab' ich keine Ahnung was da am 600XL schiefgehen könnte. Ich glaub Jürgen hat mal geschrieben, dass einige Pokeys - auch mit entfernten Kondensatoren - Probleme mit hohen Baudraten haben, selber reproduzieren konnte ich das bisher aber nie.

Also ein ATR's mit 360K, wie von einer XF. #1 MyDos gebootet und per Dos Menü mit "J" die "Disk" nach #2 kopiert. (Das XE-OS hat Hisio-Patch :wink: ) In dem Moment, wo MyDos die Disk/ATR in #2 formatiert, wird das ATR in #2 auf 720D halbiert! upps. Das ist sicher ein Fehler von MyDos beim Erkennen der Disk/ATR.

Ja, ich glaube mich dunkel dran erinnern zu können, dass das ein Bug in MyDos ist. Es erkennt 360k Disks wohl fälschlicherweise als 180k und formatiert dann die Ziel-Disk auch in 180k.

In diesem Zusammenhang gleich die Frage, was passiert mit dem Speicher, wo das ATR liegt. Ich habe auch schon bei anderen Flop-Emulatoren bemerkt, dass ein Format-Befehl die Größe ATR ändern kann. Kleiner wird kein Problem sein, aber größer? Überschreibt das ATR mit seiner neuen Größe einfach benachbarte Speicherbereiche? Das könnte fatal sein.…

Da brauchst Du Dir keine Sorgen zu machen. Wenn Du ein ATR lädst oder eine Disk mit "c" neu anlegst dann holt sich atariserver den dafür benötigten (RAM) Speicher und kopiert ggf den ATR Inhalt dort rein. Beim Formatieren wird der Speicher freigegeben und ein neuer Speicherbereich genau in der Grösse des gewünschten Formats geholt (und ausgenullt, so wie beim Formatieren einer Disk).

atariserver verhält sich damit genau so wie eine normale Floppy, bei der Du zb eine DD Disk auch einfach in SD neu formatieren kannst. Einziger Unterschied ist, dass atariserver nicht automatisch das ATR überschreibt / vergrössert / verkleinert solange Du es nicht abspeicherst (zB mit "w" "a" um alle Änderungen zu speichern).

Dort ist auch Copy 2000 V 2.51Q drauf, wo mir die fehlerhaften Prüfsummen auffielen. Schicke mir doch bitte das Copy2000 2.41D, dann kann ich das vergleichen. [/quote]
Danke, ich hab einen kurzen Test mit Copy 2000 V 2.51Q gemacht und das Ergebnis war katastrophal - auf der Kopie war nicht mal mehr ein lesbares Directory drin. Diese Copy 2000 Version scheint also ziemlich kaputt zu sein (keine Ahnung woran's genau liegt).

Copy2000 2.41D hab' ich übrigens von dem von Dir verlinkten AtariAge Posting - das erkennt aber 360k nur als 180k (so wie MyDos).

Hab' dann mal das DISKCOPY von Turbo Dos genommen, die Highspeed Routine kommt zwar nicht mit den hohen Geschwindigkeiten klar, aber bei Divisor 8 hat es eine perfekte 1:1 Kopie Deines MyDos360K.atr Files erzeugt.

Bei Deinem atariserver werden mit Trace (T 1) die gelesene und geschrieben Sektorenummern mit read% und write% ausgegeben. Bei write steht in Klammern (verify) (oder so, habe ich jetzt nicht notiert...) Auf was bezieht sich dieses (verify) (oder so, habe ich jetzt nicht notiert...) :?: Du liest doch nicht wirklich noch einmal die Sektoren vom ATR, oder?

"write" und "write with verify" werden von atariserver exakt gleich behandelt. Da atariserver die Sektor-Daten nur ins RAM kopiert würde ein Vergleich nicht viel Sinn machen. Würden dabei Unterschiede auftreten hast Du wohl viel grössere Probleme (defektes RAM, PC würde garnicht ordentlich laufen).

Danke für die Info, da werde ich drauf achten, auch wenn das Paket schon unterwegs ist. Aber zumindest kann ich die Spannung überwachen und ggf. ein größeres C noch mit anschließen.

Die neuen Himbeeren überwachen die Spannung selber, bricht sie zu stark ein erscheint ein gelber Blitz rechts oben am Bildschirm und der Kernel loggt eine Fehlermeldung in dmesg ("Under-voltage detected!"). Mit "vcgencmd get_throttled" kannst Du auch checken ob der RPi seit dem Einschalten wegen Übertemperatur oder zu niedriger Spannung runtergetaktet wurde - wenn alles OK ist siehst Du da als Wert 0x0.

Die Spannungsüberwachung im RPi reagiert übrigens sehr flott und meldet auch wenn die Spannung für ein paar Millisekunden (oder noch kürzer) zu niedrig war. Sowas kann man sonst nur mit einem (Digital/Speicher-)Oszi wirklich checken, mit einem Multimeter sieht man sowas praktisch nie (die sind viel zu langsam dafür).

Bei meiner RPI 2B lag eine Trancend 8GB bei, die werkelt nun eine ganze Weile schon ohne zu murren. Da habe ich Ersatz da und wollte so was nehmen. Zu langsam?

Schwer zu sagen. Kann sein, dass die sehr in Ordnung ist, kann sein, dass sie absoluter Schrott ist - oder irgendwo dazwischen. Das kommt auf den genauen Typ der Karte an und eigentlich hilft nur selber testen da die Hersteller gerne mal den Namen gleichlassen aber das Innenleben verändern.

Für den Einsatz als "Betriebssystem Festplatte" ist es wichtig, dass die SD Karte gut mit kleinen Blöcken umgehen kann, vor allem beim Schreiben. Gerade in diesem Bereich gibt's riesige Unterschiede und die übliche "Class 10" etc Kennzeichnung sagt darüber nichts aus - die bezieht sich nur auf das sequentielle Schreiben.

Nun gibt's (endlich) die "A1" und "A2" Klassen die genau diesen wichtigen Bereich abdecken. A2 bringt in der Himbeere wohl nichts - die Karten sind teurer als A1 und vor kurzem hab ich einen Bericht gelesen, dass eine A2 Karte langsamer als A1 war, weil der SD Controller nicht mit A2 umgehen konnte. Aber A1 ist eine nette Sache die es viel einfacher macht gute SD Karten für die Himbeere zu finden - deshalb auch meine Empfehlung.

Hier noch ein Link zu einem SD Karten Vergleich (brauchst nicht alles lesen, die erste Tabelle mit dem IOPS Vergleich ist aber sehr aufschlussreich)
https://forum.armbian.com/topic/954-sd- ... ment-49811

Ich hab' hier eine etwas ältere 8GB Transcend Class 10 SD Karte (volle Größe, nicht micro-SD), die hatte ich vor kurzem in einer alten Himbeere zum Testen verwendet (war die erste frei Karte die ich gefunden hatte). Damit lief Raspbian ewig zäh ("apt-get upgrade" dauerte ewig und 5 Jahre), hab' dann mit iozone3 im SD Kartenleser am PC getestet und die 4k Block Schreibperformance war unter aller Sau - locker um einen Faktor 20-50 langsamer als alle anderen (Samsung und Sandisk) Karten hier.

Wie gesagt, es kann gut sein, dass Deine Transcend in Ordnung ist, wollte nur ein Beispiel bringen dass es grosse Unterschiede in der Performance geben kann.

so long,

Hias

Hi Hias,

bevor ich zur Schicht muß, noch kurz eine Antwort. Das mit denSpeicherkarten sehe ich mir später an.

dl7ukk hat geschrieben:
Habe nicht erwartet, dass so etwas möglich ist. Zumal der 600XL völlig in Ordnung ist (nur die abgebrochene Taste). Es lag am ATARI 600XL !!!

Interessant. Im Moment hab' ich keine Ahnung was da am 600XL schiefgehen könnte. Ich glaub Jürgen hat mal geschrieben, dass einige Pokeys - auch mit entfernten Kondensatoren - Probleme mit hohen Baudraten haben, selber reproduzieren konnte ich das bisher aber nie.

]
Das kann ich Morgen überprüfen, den Pokey im XE habe ich gesockelt.

"write" und "write with verify" werden von atariserver exakt gleich behandelt. Da atariserver die Sektor-Daten nur ins RAM kopiert würde ein Vergleich nicht viel Sinn machen.

Das ist verständlich. Hängt die Meldung also mit den Einstellungen im (hier) MyDos zusammen? Aber das ist ok.

Die ganze Palette von Sektorkopierern bremsen Deine HS-Routine ganz schön aus. Das Kopieren einer Disketten 360K in MyDos mit der Funktion C geht gefühlt doch schneller. Das die Dichte-Erkennung ein Problem ist muß mal bekannter gewesen sein. Ich glaube mich zu erinnern, dass das TOP Team genau deshalb die XF Utilitys anbot.

Übrigens bei MyDos konnte ich diesen Problem mit O - Config lösen. Das #2 wurden 360K und 1440 Sectoren angegeben und dann klappt es auch mit dem duplizieren der Disk.

Ja, ich glaube mich dunkel dran erinnern zu können, dass das ein Bug in MyDos ist. Es erkennt 360k Disks wohl fälschlicherweise als 180k und formatiert dann die Ziel-Disk auch in 180k.

Ich check das Morgen auch nochmal.

Code: Alles auswählen

dl7ukk@HP635a:~/TP-R52$ md5sum M*
Das ...Original
6a2c8d5dbba4c2d969b75468b048ec39  MyDos360K.atr

noch mal gespeichert
6a2c8d5dbba4c2d969b75468b048ec39  MyDos360K-2.atr

mit COPY2000 V2.51Q kopiert
6a2c8d5dbba4c2d969b75468b048ec39  MyDos360k-copy2000-v251q.atr

und hier fehlerhaft SECTORCOPY 2 by HWL
b858e4e468029ac0e5fe69a90797ac5a  MyDos360k-sectorcopy-2.0byHWL.atr
dl7ukk@HP635a:~/TP-R52$


COPY2000 V2.51Q kopiert auf jeden Fall 360k fehlerfrei. Das ist ja schon mal was. Ob es auch mit weniger klar kommt probiere ich Morgen noch mal aus.

Da brauchst Du Dir keine Sorgen zu machen. Wenn Du ein ATR lädst oder eine Disk mit "c" neu anlegst dann holt sich atariserver den dafür benötigten (RAM) Speicher und kopiert ggf den ATR Inhalt dort rein. Beim Formatieren wird der Speicher freigegeben und ein neuer Speicherbereich genau in der Grösse des gewünschten Formats geholt (und ausgenullt, so wie beim Formatieren einer Disk).

atariserver verhält sich damit genau so wie eine normale Floppy, bei der Du zb eine DD Disk auch einfach in SD neu formatieren kannst. Einziger Unterschied ist, dass atariserver nicht automatisch das ATR überschreibt / vergrössert / verkleinert solange Du es nicht abspeicherst (zB mit "w" "a" um alle Änderungen zu speichern).

Danke für die Erklärung.

Gruß

Mit diesen USB-Adaptern läuft doch dauernd was schief:

Auf der Fujiama hatte ich erstmals Pokey Zero am Laufen, zu Hause mit absolut gleichem Setup ging nur noch normale Geschwindigkeit.

Ein anderes mal läuft alles wieder auf dem Acer Aspire One (1,6GHz Atom), aber auf dem Asus (2,5GHz Intel i5) geht gar nichts.

Da man am PC ja so gut wie gar nichts mehr unter Kontrolle hat, wünsche ich mir einfach wieder eine Nachfolge des alten MS-DOS-Programms SIO2PC unter FreeDOS oder sowas.

Hallo Mirko,

ich kann Deinen Frust verstehen. SIO2PC von Nick Kennedy/ WA5BDU war unter DOS eine prima Sache, wenn auch mit einem kleinen Bug beim Erstellen der ATRs. Und heute nehme ich SIO2BSD auf der Kommandozeile. Das läuft doch gut.

Bei mir geht Pokey 0 auch nicht immer. Ich hatte 3 FTDI USB <-> Kabel gebaut, wo ich ausgetestete FTDI Kabel vom Chinamann genommen habe. Die brachten es wirklich. Frag mal Ralf ob er noch Eines übrig hat. Oder Du schwimmst mal über die Oder zu Lotharek. Sein SIO2USB(PC) bringt auch 125000Bd, ist aber leider nicht ganz billig und mit Versand ganz schön happig. Aber sehr gute Qualität!!

Pokey 8 oder dreifache SIO Geschwindigkeit machen eigentlich alle FTDI Kabel aus der Bucht oder so. Und mehr konnte Nicks Programm auch nicht, soweit das im Gedächtnis geblieben ist. Und Du bleibst mit dem SIO2USB (RAF), XDOS ... kompatibel.

Wenn Du diesen Thread etwas weiter oben schaust, da sind ein paar Screenshots von atariserver. Mir gefällt er immer besser.

Und am Sonnabend trifft sich AiB in Johannisthal

Gruß

Hallo Andreas,

Das ist verständlich. Hängt die Meldung also mit den Einstellungen im (hier) MyDos zusammen? Aber das ist ok.

Wenn ich mich richtig erinnere schreiben die meisten DOSen per default mit Verify. Das bremst zwar, war aber damals bei Disketten durchaus sinnvoll. Mit div. Optionen, Config Tools oder Pokes kann man den Verify aber meist abschalten.

Die ganze Palette von Sektorkopierern bremsen Deine HS-Routine ganz schön aus. Das Kopieren einer Disketten 360K in MyDos mit der Funktion C geht gefühlt doch schneller. Das die Dichte-Erkennung ein Problem ist muß mal bekannter gewesen sein. Ich glaube mich zu erinnern, dass das TOP Team genau deshalb die XF Utilitys anbot.

Die XF551 war auch bei weitem nicht so weit verbreitet wie die 1050er. Inkompatible 360k Disk Formate der verschiedensten DOSen und Bugs in der XF551 (ich sag nur Dichte-Erkennung) waren auch nicht sehr hilfreich. Insofern ist das 360k Format auch eher ein Exot und es ist nicht allzu verwunderlich, dass es nicht so viel Unterstützung hat wie SD/ED/DD.

Übrigens bei MyDos konnte ich diesen Problem mit O - Config lösen. Das #2 wurden 360K und 1440 Sectoren angegeben und dann klappt es auch mit dem duplizieren der Disk.

Ah, guter Tip, vielen Dank!

Code: Alles auswählen

dl7ukk@HP635a:~/TP-R52$ md5sum M*
Das ...Original
6a2c8d5dbba4c2d969b75468b048ec39  MyDos360K.atr

noch mal gespeichert
6a2c8d5dbba4c2d969b75468b048ec39  MyDos360K-2.atr

mit COPY2000 V2.51Q kopiert
6a2c8d5dbba4c2d969b75468b048ec39  MyDos360k-copy2000-v251q.atr

und hier fehlerhaft SECTORCOPY 2 by HWL
b858e4e468029ac0e5fe69a90797ac5a  MyDos360k-sectorcopy-2.0byHWL.atr
dl7ukk@HP635a:~/TP-R52$


COPY2000 V2.51Q kopiert auf jeden Fall 360k fehlerfrei. Das ist ja schon mal was. Ob es auch mit weniger klar kommt probiere ich Morgen noch mal aus.

Ich hab nochmal getestet und nun war die COPY2000 V2.51Q Kopie bei mir auch fehlerfrei mit identischer md5sum. Keine Ahnung was genau da beim vorigen Test schiefgelaufen ist, hier hängen grad viele Kabel rum und vielleicht hat eines der dickeren gegen den Ramdisk-Config-Schalter gedrückt und in einem ungünstigen Moment die 1MB Ramdisk ausgeschaltet.

Das BIBOSOFT / HWL Sectorcopy 2.0 macht bei mir übrigens auch fehlerhafte Kopien - getestet mit 1MB RAM Erweiterung, 512k RAM Erweiterung aus dem Freezer und ohne RAM Erweiterung:

Code: Alles auswählen

4f3a1f45a4a5f30cc4214b8a4de527ad  MyDos360K-sectorcopy2-1MB-ramdisk.atr
4f3a1f45a4a5f30cc4214b8a4de527ad  MyDos360K-sectorcopy2-512kB-ramdisk.atr
e336cefe4e818ffce91bce100776355b  MyDos360K-sectorcopy2-no-ramdisk.atr

Da scheint das Programm einen Bug zu haben und macht einige Bytes (mit RAM Erweiterung u.a. im Boot Sektor) kaputt:

Code: Alles auswählen

hias@camel2:/tmp$ cmp -l MyDos360K.atr MyDos360K-sectorcopy2-1MB-ramdisk.atr
    17 115 377
    18   3 377
    19   0 377
    20   7 377
    21 340 377
    22   7 377
    23 114 377
    24  24 377
    25   7 377
    26  10 377
    27  10 377
    28   1 377
    29 363 377
    30  33 377
    31   2 377
    32   4 377
    33   0 377
    34 375 377
    35  12 377
    36  13 377
    37 254 377
    38  22 377
    39   7 377
    40 255 377
    41  23 377
    42   7 377
    43  40 377
    44 130 370
321708 320 337
321709   5 377
321710  40 377
321711  63 377
321712  76 377
321713 242 377
321714   0 377
321715 275 377
321716 100 377
321717   3 377
321718  20 377
321719  26 377
321720 256 377
321721 306 377
321722  33 377
321723 251 377
321724  10 377
321725 340 377
321726 101 377
321727 320 377
321728   2 376
364559   0 250
364560   0 375
365071   0 251
365072   0 375
365839   0 252
365840   0 375
367119   0 253
367120   0 375
367887   0 254
367888   0 375
368143   0 255
368144   0 375

Code: Alles auswählen

hias@camel2:/tmp$ cmp -l MyDos360K.atr MyDos360K-sectorcopy2-no-ramdisk.atr
233873   0 377
233874   0 377
233875   0 377
233876   0 377
233877   0 377
233878   0 377
233879   0 377
233880   0 377
233881   0 377
233882   0 377
233883   0 377
233884   0 377
233885   0 376
291997 356 357
291998 131 377
291999  10 377
292000  70 377
292001 260 377
292002  14 377
292003 315 377
292004 130 377
292005  10 377
292006 360 377
292007  27 377
292008 110 377
292009  40 377
292010 311 377
292011  27 377
292012 150 377
292013 110 377
292014  30 377
292015 110 377
292016 251 377
292017  11 377
292018 240 377
292019 375 377
292020  40 377
292021 134 377
292022   7 377
292023 150 377
292024  40 377
292025 374 377
292026  27 327
350138 153 177
350139  40 377
350140  43 377
350141 233 377
350142 112 377
350143  56 377
350144  40 376
365454   0   4
365455   0 256
365456   0 375
366478   0   4
366479   0 257
366480   0 375
366734   0   4
366735   0 260
366736   0 375
366990   0   4
366991   0 261
366992   0 375
367502   0   4
367503   0 262
367504   0 375
368014   0   4
368015   0 263
368016   0 375

Hmmm, mir kommt vor, wir testen nun hauptsächlich Sektorkopierer - ist aber auch in Ordnung :-)

so long,

Hias

Hallo Andreas

Probier doch mal MyDOS 4.55 beta 4. Lee hat einige Bug gekillt, darunter sollte, wenn mein Bio-FlashRAM mich nicht trübt, auch der VTOC-Bug sein.

Tschüß

Mathy

Nun,

MyDOS erkennt selber eigentlich nur single (128b) und double (256b), mehr nicht. Mit dem Menüpunkt "O" muss man dem DOS mitteilen bzw. einstellen, ob es sich um 40 oder 80 Tracks (oder HDD) und um einseitige oder zweiseitige Formate handelt. Größere ATR's werden glaube ich nur als HDD-Images gesehen, also unter Menüpunkt O ggf. die Frage "high capacity drive?" mit "Y" beantworten und dann für ein 360k ATR-Image einfach 1440 Sektoren in DD formatieren (ggf. mit P zuvor noch auf DD umstellen, z.B. 1,d für Drive 1 oder 2,d für Drive 2, usw.).

Copy 2000 war eigentlich für die Floppy 2000 gedacht, also ein PC-LW mit eingebauter Speedy. Version 2.41D kann nur max. 180k, das D steht für double; Version 2.51Q war ursprünglich im ROM der Floppy 2000 II und kann zwar 360k, Q steht hier fälschlicherweise für Quad, doch wird die 2. Seite anders als bei der XF gelesen/geschrieben (oder genauer, bei der XF ist das andersrum). Angeblich soll Copy 2000 V2.51Q sowohl das XF551 als auch das HDI/Floppy 2000/usw. 360k Format lesen können, schreiben kann es nur das HDI/Floppy 2000/usw. Format - also nicht mit der XF551 benutzen, es sei denn, es wäre eine Speedy-XF... (ja, die blöden kleinen Inkompatibilitäten mit zweiseitigen A8 Disks und ob die 2. Seite von innen nach außen oder von außen nach innen oder PC-like gelesen/geschrieben wird)...

Wenn du Sektorkopierer mit Pokey-Divisor 0 oder 1 benutzen willst, dann keine Kopierer nutzen, die für ultraspeed, turbo, happy, speedy, etc. gedacht sind, da diese zumeist eine bestimmte "Höchstgeschwindigkeit" erlauben (z.B. bis Divisor 6, 5 oder 4) und darüber hinaus Mathy blitzen, äh, nicht mehr arbeiten. Eine Ausnahme scheint bisher nur Copy 2000 zu sein (eigentlich für Speedy gedacht), dass ich vor ein paar Jahren, als ich noch XL's mit U1MB und 4 OS hatte, auch mit SIO2SD und im U1MB gewähltem XL-HI-OS mit Divisor null betreiben konnte. Ansonsten besser einen Kopierer nehmen, der gar keinen Speeder eingebaut hat und bei einer normalen Floppy nur mit 19k2 Baud laufen würde - diesen Kopierer dann mit XL-HI-OS auf Divisor null beschleunigen klappt meistens (allerdings ist man bei der Formatwahl 90k/130k/180k/360k/... des Öfteren etwas eingeschränkt)...

Ich habe vor ein paar Monaten noch einen uralten A8 Sektorkopierer gefunden, bei dem man die Anzahl der Sektoren manuell angeben kann und auswählen kann ob man mit 40 Tracks, 80 Tracks oder 35 Tracks bzw. 77 Tracks formatieren möchte und ob es single/FM/128b, medium/MFM/128b oder double/MFM/256b sein soll; zudem kann man mit Ramdisk/XRAM kopieren oder ohne. Das Programm hat wie MyDOS keinen Speeder eingebaut und ich lade stets manuell einen ultraspeed-Treiber (von Bob Woolley) davor, sowie einen Ramdisk-Treiber für MyDOS. Der Kopierer überschreibt dann das DUP.Sys in der RD nicht und lädt und schreibt wunderbar mit ultraspeed. Da jedoch wie gesagt kein Speeder im Kopierprogramm eingebaut ist, dürfte es nicht auf ultraspeed (Divisor 5 oder 6) beschränkt sein und ggf. auch mit XL-Hi-OS und Divisor 0 laufen. Mit dem Kopierer habe ich auf einer Hyper-XF schon erfolgreich Disketten mit 360k und 720k in ultraspeed kopiert (und auch das sector interleave funkt. einwandfrei)... bei Copy 2000 bin ich hingegen mit V2.41D und 2.51Q auf 180k beschränkt, da auch bei 2.51Q das 360k Format der XF551 nicht unterstützt wird (gibt einen Error beim formatieren und/oder schreiben)...

Von zwei Abbucianern (E.Pütz und C.Strotmann) gab es auch mal Sektorkopierer, die wahlweise mit zwei Floppy-Laufwerken oder zwei HDD-Partitionen laufen; sie unterstützen keine Speeder, man gibt die Anzahl der Sektoren (720-65.535) manuell ein, wählt die Dichte (128b oder 256b) und kann dann loskopieren. Beide Kopierprogramme waren auch mal auf einem Abbuc Magazin drauf. Für sektorweises Kopieren von Floppy=>Floppy dürften die uninteressant sein (keinerlei Speeder, kein xRAM, etc.), jedoch für Kopiervorgänge von Floppy=>SIO2xyz oder von Floppy=>PC mit Divisor null (mittels XL-Hi-OS) könnten die wiederum interessant und geeignet sein...

Hallo Mathy & Andreas (CharlieChaplin),

vielen Dank für die Tips!

Ich konnte mich dunkel dran erinnern, dass es mal diese "einfachen" Sektorkopierer gab, wusste aber nicht mehr genau wo ich davon gehört/gelesen hatte.

Werd' mich dann mal auf die Suche danach machen, oder einfach die Diskcopy Funktion in MyDos nehmen.

so long,

Hias

Hi Hias,

HiassofT hat geschrieben:Hmmm, mir kommt vor, wir testen nun hauptsächlich Sektorkopierer - ist aber auch in Ordnung
Hias

richtig --- zurück zum atarisio und da konnte ich nun keine Fehler mehr in der Übertragung finden oder besser gesagt, alle Probleme lagen nicht beim atarisio und das ist doch was.

Neben dem was für Morgen noch anliegt, werde ich den HP Laptop und den Tower mit dem M61PMV Board testen. Wobei ich recht sicher bin, wenn ich nichts verdrehe, wird auch das gehen. Wenn das durch ist, kann ich etwas Platz schaffen ... Parallel dazu ist auch die Oberfläche dran. Ein prima Funktion ist die Dateiauswahl bei "load" und "write" per Enter. Ich sollte mir mal einen Zettel hinlegen, damit ich nichts vergesse. Das Formatieren eines Atr im MyDos Format geht auch schon mal. .. und der Aufruf des Directory auch. Und nicht zu vergessen, der Quelltext läßt sich problemlos compilieren. Es gibt zwar ein paar Warnungen, aber keine Fehler!

Schnell, einfach und bei 130k, 180k, 360k auch richtig funktioniert das Erstellen von atr. Was ich dann, wieder mit DiskCopy und md5sum überprüfe. Das Prüfen könnte ich aber auch am Atari mit dem VTOC Fixer (ich hoffe der heißt so) oder dem CRC vom vor/vorletztem SW-Wettbewerb erledigen....

Nicht so ergonomisch finde ich S für den Pokey Divisor, da habe ich öfter das kleine s erwischt. Aber das ist für den späteren Einsatz nicht wichtig. Da wird die Baudrate kaum so oft gewechselt. Und das funktioniert prima!

Gruß

Hello Leute

Wenn ich mich recht entsinne, erkennt MyDOS fast alles was schon formatiert ist. Bei 4.55 beta 4 sollte der Percom-Block jetzt auch richtig gelesen werden. Ist schon eine Weile her, aber ich glaube der wurde damals richtig gelesen und dann überschrieben.

"High capacity drive" habe ich meines Erachtens nie benutzt, auch nicht mit den Festplatten an der BlackBox.

"Sector kopieren" kann MyDOS auch. Einfach bei Option "J" zum Beispiel "1,2(1-1040)" eingeben. Hier wird von Laufwerk 1 auf Laufwerk 2 kopiert, Sektor 1 bis einschliesslich Sektor 1040. Wenn man dann noch irgendwo "/N" einfügt, wird das Ziellaufwerk nicht formatiert.

Tschüß

Mathy

PS unter "O" kann man bei 4.55 wählen ob mindestens 3 oder mindestens 4 Ziffern benutzt werden sollten bei der Sektorangabe.