Ich habe mich die letzten Tage intensiver mit dem Speedy ROM beschäftigt und (nach vielem Fluchen) die Routine zum Empfangen von Daten im Highspeed Mode durch eine neue ersetzt die auch auf NTSC Systemen funktioniert.

Hier ist eine erste Vorab-Version zum Testen: http://www.horus.com/~hias/tmp/megaspee ... 170422.zip

Für die Meaga Speedy einfach das FLASHER.ROM in einen der Mega Speedy slots programmieren (ich hab' zum Testen E4 genommen).

Die ROMs für die Super Speedy (mit supercopy) und die originale Speedy (mit BiboDos bzw HSS Copy) hab' ich auch auf die aktuelle, gefixte Version hochgezogen. Dabei hatte ich wieder einiges zu Fluchen: die Speedy hat ja diese schön standardisierten Einsprungvektoren, aber wer ignoriert die? Richtig, die BiboDos und HSS Laderoutinen der Speedy, die müssen natürlich direkt ins ROM reinspringen... Nachdem ich die ROM-Versionen von BiboDos und HSS dann gefixt hatte liefen sie mit der neueren 1.5er Version (aus der SuperSpeedy) und damit dann auch mit der Version mit dem NTSC fix.

Bitte beachtet: die Version ist noch nicht vollständig getestet, kann also sein, dass da noch der eine oder andere Bug drin schlummert.

Bitte gebt mir Bescheid ob die Test-ROMs bei euch laufen. Wenn möglich testet sowohl unter PAL als auch unter NTSC. Ich freu mich über jedes Feedback!

so long,

Hias

Hallo Hias,
Sorry für meine Fragen (ich bin ja mit ATARI eigentlich erst seit 2009 unterwegs).
Du hast ja den OS Patch für SIO Routinen programmiert.
Wie sah die Welt davor aus ?

Die alten Floppy Erweiterungen (Happy, Speedy, etc.) bringen ja nichts mit dem Standard OS, oder?

Und wenn Megaspeedy orginale ROMs von Speedy, Happy, etc. verwendet - warum musstest Du sie jetzt ändern? Die haben ja wohl Jahre lang (auch mit NTSC Systemen) funktioniert, oder?

Gruß
Marcin

Montezuma hat geschrieben:Hallo Hias,
Sorry für meine Fragen (ich bin ja mit ATARI eigentlich erst seit 2009 unterwegs).
Du hast ja den OS Patch für SIO Routinen programmiert.
Wie sah die Welt davor aus :) ?

Die alten Floppy Erweiterungen (Happy, Speedy, etc.) bringen ja nichts mit dem Standard OS, oder?

Davor sah die "Welt" nicht viel anders aus: es gab verschiedene DOS Versionen (TurboDos, BiboDos, Spartados, ...) die einzelne (zT auch mehrere) High-Speed Varianten unterstützten. Und es gab auch OSse die Highspeed (meist Happy/Speedy Ultraspeed) direkt unterstützt haben.

Was davor gefehlt hat ist eine Highspeed Routine die mit allen Varianten (Happy/Speedy Ultraspeed, Happy Warpspeed, Turbo 1050, XF551) funktioniert und die auch mit der höchstmöglichen Geschwindigkeit läuft. Das hab ich dann in meinem Highspeed SIO Code umgesetzt. Durch die vielen Varianten und die notwendigen Optimierungen für Pokey Divisor 0 ist der Code aber natürlich deutlich grösser als in den anderen Implementierungen.

Und wenn Megaspeedy orginale ROMs von Speedy, Happy, etc. verwendet - warum musstest Du sie jetzt ändern? Die haben ja wohl Jahre lang (auch mit NTSC Systemen) funktioniert, oder?

Happy, Turbo, ... sind davon nicht betroffen aber die Speedy hat nie wirklich auf NTSC Systemen in Highspeed funktioniert. Das Problem dabei ist die Routine die Bytes vom Atari empfängt - zB beim Schreiben auf eine Speedy Disk.

Details dazu in meinem Post auf AtariAge: http://atariage.com/forums/topic/263679 ... try3744285 und Avery's Kommentar dazu: http://atariage.com/forums/topic/263679 ... try3744532

Kurzum: die Routine war auf PAL Ataris schon grenzwertig und versagt bei NTSC Systemen bei langen Transfers (zB 128 oder 256 Bytes am Stück beim Schreiben auf die Disk). Dessen hab' ich mich nun angenommen und das Problem hoffentlich (endlich) in den Griff bekommen.

Es betrifft auch nicht nur die Mega Speedy sondern auch alle anderen (originalen) Speedies.

Beim Entwickeln der Mega Speedy habe ich selber immer nur mit PAL Ataris getestet und ich kann mich nicht daran erinnern, dass einer unserer Tester (durchaus auch mit NTSC Ataris) von Problemen berichtet hätte. Daher hatte ich die NTSC Probleme auch garnicht mehr im Hinterkopf und selber nicht extra auf NTSC getestet.

so long,

Hias

Vielen Dank für die Erklärung.
Interessant, dass sich damals die "Speedy" Entwickler keine Gedanken über NTSC Rechner gemacht hatten...

Hab' gerade eben bemerkt, dass ich vergessen hatte bei den original Speedy ROMs die ROM Checksummen anzupassen - das Speedy Test Programm hat dadurch ROM Fehler gemeldet.

Hier ist ein Update mit gefixten Speedy ROMs (Mega Speedy und Super Speedy ROMs sind identisch zur gestrigen Version):
http://www.horus.com/~hias/tmp/megaspee ... 170423.zip

so long,

Hias

Hallo,

Kleiner Nachtrag.
In den USA hat Steve Carden auch getestet.
Er mag wohl NTSC benützt haben, das wissen wir aber nicht genau.
Denn wir haben nie ein Testprotokol abgestimmt.

Es hat aber mehrere Beta-Tester gegeben.
Fehler suchen und reproducieren mag aber oft sehr schwerig sein und Zufall ist da oft auch ein Factor.

MFG,
Guus

guus hat geschrieben:Fehler suchen und reproducieren mag aber oft sehr schwerig sein und Zufall ist da oft auch ein Factor.

Absolut. Und (da spekuliere ich jetzt ein wenig) es könnte auch sein, dass der Fehler einfach niemandem aufgefallen ist.

Ich bin da auch erst durch einen Bugreport draufgestossen: mit meinem Highspeed Patch im OS funktionierte die Mega Speedy unter NTSC "einwandfrei", mit Jon's Highspeed Code im U1MB PBI Bios aber nicht.

Das machte alles erstmal keinen grossen Sinn, Jon's Code basiert auf meinem und reproduzieren konnten wir (Jon, Marcin und - mit etwas Verspätung nun ich) das auch nicht.

Diese Woche hatte ich mir das dann noch mal genauer angeschaut und gemeinsam haben wir das Rätsel gelöst:

Highspeed Übertragung unter NTSC hat auch mit meinem Highspeed OS nicht funktioniert. Da mein Code bei Übertragungsfehlern aber automatisch auf Standard Speed zurückschaltet gab's keine SIO Fehler. Das ganze hörte sich zwar grausam an (jeder Sektor wurde zuerst in Highspeed und dann noch mal in Standard Speed übertragen), funktionierte aber im Endeffekt ohne dass der User Fehler zu sehen bekam.

Der User hatte auch wohl eine ältere Version von Jon's PBI HiSio Code im Einsatz, die nicht auf Standard Geschwindigkeit zurückgeschaltet hat (Jon's aktuelle Version macht das genauso wie mein Code). Das erklärte dann, wieso der User damit SIO Fehler zu sehen bekam.

Aus dem Blickwinkel des Users betrachtet war der Bugreport völlig korrekt, das eigentliche Problem lag aber ganz wo anders (im Speedy ROM). Bugreports richtig zu interpretieren bzw die richtigen Schlüsse draus zu ziehen ist oft sehr schwierig. Und es kommt auch sehr oft vor, dass man an völlig falschen Stellen zum Suchen beginnt. Aber das kennt wohl jeder, der schon mal selber Hardware oder Software entwickelt hat :)

so long.

Hias

Hallo Leute

Montezuma hat geschrieben:Interessant, dass sich damals die "Speedy" Entwickler keine Gedanken über NTSC Rechner gemacht hatten...

Die Welt sah damals ganz anders aus. Internet gab's noch nicht für jedermann. Erweiterungen aus de U.S.A. waren Schweineteuer. Das ist wohl auch, wieso CompyShop damals auf die Idee gekommen ist selber 'ne 1050-Erweiterung zu entwickeln. Das irgendwer aus der U.S.A. sich in Europa 'ne Erweiterung bestellen würde, darauf ist keiner gekommen. Wieso auch? Europa war für viele normalsterbliche West-Atlantiker noch viel weiter entfernt, als es jetzt für viele noch ist. Und Hardwareerweiterungen hatte man ja dort auf der linken Seite des Atlantiks auch. Erweiterungen die man im eigenen Land in der eigenen Sprache bestellen und in der eigenen Währung abrechnen konnte. Wie gesagt, Internet hatten nur Universitäten und das Militär, PayPal und E-banking gab's vielleicht in den Köpfen der Wenigen, die an der Uni Internet benutzen konnten.

Tschüß

Mathy

Hi Matthias, I am trying to figure out the exact sequence of commands needed for high-speed operation on Megaspeedy (or Speedy in general) by monitoring the serial port, while using ProSystem to copy a disk in high-speed mode. I figured out most of it, however I have never seen ProSystem to change the baud rate using the speed index ($09) returned by the drive It seems to operate the drive at 19,200 bps all the time, even when it accesses a double density disk. It issues a Read Track command ($62) in 19,200 bps. Is that normal? If not, when is the exact time one needs to change the baud rate, and how do we do that? Also, do we have to issue the command frames and data frames at the same baud rate?

Thank you.
Ray

Speedy works exactly as the Happy, you just talk to it in highspeed (divisor 9 = 55.5kbps) - for both the command and the data frame. Using the $3f command to determine the divisor is optional.

I've successfully hooked up the speedy to my PC and backed up a bunch of disks with a 1050-2-PC cable and atarixfer (from AtariSIO) in highspeed mode several years ago. Of course you need a serial port that can be programmed to the rather odd speed.

I never used the read/write track commands of the speedy before, IIRC they just transfer 18/26 sectors with a single command. From looking at the speedy code I guess write track could be problematic in highspeed mode as that seems to be implemented as looping 18 (or 26) times - looping takes time and the Atari would need to do short pauses when sending so the Speedy doesn't miss any bits. My highspeed code does that, but only after every 256 bytes, so SD sectors probably don't work.

so long,

Hias

Thank you for your quick reply.

So if i understand this correctly, i have to use the PAL clock rate of 1,773,447 Hz. to calculate the baud rate, not the NTSC rate. FTDI chip in my 10502PC allows for odd baud rates so that's not a problem. Also if i understand your explanation correctly, i don't have to set bit 7 of DCOMND or any other bit to switch to the high-speed mode. Is that correct?

Thanks again
Ray

Matthias, today while testing my code i also noticed when MegaSpeedy is in US Doubler mode GET PERCOM BLOCK command ($4E) always returns a sector size of 128 bytes even if the disk is double density. When I switch the mode to Speedy or Happy it returns the correct size of 256 bytes. I tried it several times and I get the same result every time. The rest of the Percom info seems to be correct. Could you please verify whether this is a bug in the MegaSpeedy firmware, or in US Doubler ROM, or am i actually missing something.

Thank you.

a8w hat geschrieben:Thank you for your quick reply.

So if i understand this correctly, i have to use the PAL clock rate of 1,773,447 Hz. to calculate the baud rate, not the NTSC rate. FTDI chip in my 10502PC allows for odd baud rates so that's not a problem. Also if i understand your explanation correctly, i don't have to set bit 7 of DCOMND or any other bit to switch to the high-speed mode. Is that correct?

Thanks again
Ray

I actually found the answer to the above question. My code now works in high-speed at 55,420 bps and I can use command $62 for track by track read. No need to change any command bits.