Neben Simple Stereo und VBXE hat Candle noch einen interessantes I/O-Board entwickelt.

Alles zu sehen auf http://spiflash.org/

Hat schon jemand Erfahrungen mit dem I/O-Board?

Hi!

GoodByteXL hat geschrieben:Hat schon jemand Erfahrungen mit dem I/O-Board?

Nicht direkt, aber ich bin in recht regem Mailkontakt mit Fatih, dem Entwickler von AspeQT, und wir haben uns gemeinsam mit dem "synchronous mode" beschäftigt (oder soll ich besser sagen rumgeärgert :-)

Ich hab' hier einen USB-Seriell Adapter mit einem FT232BM Chip (gibt's für ca. 10 EUR von Digitus unter der Nummer 70146, der Nachfolger 70146-1 hat einen FT232RL Chip), auf dem I/O Board ist ein FT232R drauf (sozusagen ein erweiterter Nachfolger des FT232BM). Mein SIO2PC Interface hab' ich so erweitert, daß RTS vom PC mit der Bidirectional Clock am SIO-Stecker verbunden ist.

Leider scheint der FT232 Chip im Synchronous Mode einige Bugs zu haben (er funktioniert nicht in allen Geschwindigkeiten so wie er soll), nach einigem Experimentieren hab' ich aber rausgefunden, daß mein Chip bei 480kbit/sec (ergibt netto dann 240kbit am SIO Bus) korrekt funktioniert. Wie's auf der Atari Seite mit dem Pokey damit aussieht hab' ich aber nicht getestet. Nun warte ich auf Fatihs Tests mit dem I/O Board.

Bevor jetzt aber zu grosse Erwartungen aufkommen: im "normalen" Betrieb schafft der Atari gerade eben 126kbit, um höhere Geschwindigkeiten zu erreichen muss man den Bildschirm abschalten und benötigt speziellen Loader Code - ähnlich wie bei den verschiedenen Turbo-Tapes - mit den standard SIO Routinen geht da nix mehr.

Im "normalen" (asynchronen) RS232 Modus sind die FTDI Chips übrigens wirklich gut. AspeQT läuft damit unter Linux sehr rund, sogar in einer Linux-VM unter Linux klappte es :-) Nach den Erfahrungen mit anderen USB-Seriell Adaptern (vor allem dem Billigschrott mit Prolific Chips) war ich da sehr skeptisch.

Zu den restlichen Features des I/O Boards (zB PS/2 Interface) kann ich leider garnichts sagen.

so long,

Hias

HiassofT hat geschrieben:Hi!

GoodByteXL hat geschrieben:Hat schon jemand Erfahrungen mit dem I/O-Board?

Nicht direkt, aber ich bin in recht regem Mailkontakt mit Fatih, dem Entwickler von AspeQT, und wir haben uns gemeinsam mit dem "synchronous mode" beschäftigt (oder soll ich besser sagen rumgeärgert ...

Hm, klingt ja nicht uninteressant. Wenn man die bi-direktionale Speed bei SIO zuverlässig anheben könnte, wäre so manches USB-Geräte eine prima Ergänzung.

Damit käme man zwar nicht an die von dir empirisch festgestellte Grenze von 30KB/s über die SIO heran (wenn man mal die theoretische Grenze für die SIO-Speed berechnet, käme man bei SIO_max auf ca. 15,5KB/s).
Also genug 'Luft' ...

Der ATARI macht schon über den PBI sozusagen standardmäßig 50KB/s mit dem MSC, die praktische Grenzgeschwindigkeit des PBI mit IDE-Geräten liegt bei ca. 70KB/s (optimiertes KMK-IDE). Wäre das eine Möglichkeit? Sijmen hat ja mit seinem MyIDE über den Cart-Port ähnlich hohe Geschwindigkeiten erreicht.

Man bräuchte so etwas wie einen "USB-to-parallel"-Adapter? Damit könnte man richtig Dampf machen...

Hallo Walter!

GoodByteXL hat geschrieben:Hm, klingt ja nicht uninteressant. Wenn man die bi-direktionale Speed bei SIO zuverlässig anheben könnte, wäre so manches USB-Geräte eine prima Ergänzung.

Wie meinst Du das? Der SIO Teil am I/O Board ist im Prinzip nichts anderes als ein "normales" SIO2PC Interface. USB Geräte kann man da nicht dranhängen.

Damit käme man zwar nicht an die von dir empirisch festgestellte Grenze von 30KB/s über die SIO heran (wenn man mal die theoretische Grenze für die SIO-Speed berechnet, käme man bei SIO_max auf ca. 15,5KB/s).
Also genug 'Luft' ...

Kurz ein Wort zu den Zahlen: bei SIO werden pro Byte 10 Bit übertragen (Start-Bit, 8 Datenbits, Stop-Bit). Bei 126kbit/sec sind das also ca. 12.6kByte pro Sekunde, davon muss man aber noch etwas für den Protokoll-Overhead abziehen. Ich hab' noch mal eben getestet, bei 126kbit/sec dauert Lesen und Schreiben einer DD Disk ca. 17 Sekunden - das sind dann also netto knapp 11kByte pro Sekunde.

Im synchronen Modus wird's ähnlich sein, falls er einwandfrei funktioniert (da sind wir uns noch nicht 100% sicher, sowohl Fatih als auch ijor hatten gelegentliche Probleme festgestellt - das könnte am Pokey liegen, bei ca. 2 von 100 Paketen gab es in den Tests Fehlern). Ich rechne mal damit, daß die reale Geschwindigkeit dann bei ca. 20-22 kByte/Sekunde liegen dürfte. Aber eben nur mit ausgeschaltetem Bildschirm/Interrupts etc.

Der ATARI macht schon über den PBI sozusagen standardmäßig 50KB/s mit dem MSC, die praktische Grenzgeschwindigkeit des PBI mit IDE-Geräten liegt bei ca. 70KB/s (optimiertes KMK-IDE). Wäre das eine Möglichkeit? Sijmen hat ja mit seinem MyIDE über den Cart-Port ähnlich hohe Geschwindigkeiten erreicht.

Man bräuchte so etwas wie einen "USB-to-parallel"-Adapter? Damit könnte man richtig Dampf machen...

Abgesehen vom Aufwand (ein "PBI2PC USB" Interface wäre alles andere als trivial) würde ich aus dem Bauch heraus vermuten, daß es ein Stückchen langsamer sein wird als die normalen PBI Geräte. Spricht der Atari das Gerät an, muss der Zugriff erst mal über den USB Bus an den PC übermittelt werden, der bearbeitet dann den Request, und schickt die Daten über den USB Bus zum Gerät zurück. Bei einer Festplatte am PBI entfällt die Verzögerung über den USB, die hängt ja "direkt" am Atari.

so long,

Hias

HiassofT hat geschrieben:...Der SIO Teil am I/O Board ist im Prinzip nichts anderes als ein "normales" SIO2PC Interface. USB Geräte kann man da nicht dranhängen...

Ähsö - naja, ist auch gut, da die serielle Schnittstelle so langsam ausstirbt. War wohl Wunschdenken von mir ...

Kurz ein Wort zu den Zahlen: bei SIO werden pro Byte 10 Bit übertragen (Start-Bit, 8 Datenbits, Stop-Bit). Bei 126kbit/sec sind das also ca. 12.6kByte pro Sekunde, davon muss man aber noch etwas für den Protokoll-Overhead abziehen. Ich hab' noch mal eben getestet, bei 126kbit/sec dauert Lesen und Schreiben einer DD Disk ca. 17 Sekunden - das sind dann also netto knapp 11kByte pro Sekunde.

Im synchronen Modus wird's ähnlich sein, falls er einwandfrei funktioniert (da sind wir uns noch nicht 100% sicher, sowohl Fatih als auch ijor hatten gelegentliche Probleme festgestellt - das könnte am Pokey liegen, bei ca. 2 von 100 Paketen gab es in den Tests Fehlern). Ich rechne mal damit, daß die reale Geschwindigkeit dann bei ca. 20-22 kByte/Sekunde liegen dürfte. Aber eben nur mit ausgeschaltetem Bildschirm/Interrupts etc.

Ganz schön fix.
Frage zu den Zahlen: bei Speedbyte 0 erreicht doch der A8 die theoretische Max.Speed von ca. 15,5KB/s auf der SIO [1773447/2/(Speedbyte+7)/8/1024=15,4632...KB/s bei PAL], falls ich da nicht falsch liege. Ist natürlich brutto und theoretisch, aber wenn ihr mit 20-22KB/s Daten schieben wollt, wie verarbeitet der A8 das? Puffer zum Ausgleich?

Hallo Walter!

GoodByteXL hat geschrieben:Frage zu den Zahlen: bei Speedbyte 0 erreicht doch der A8 die theoretische Max.Speed von ca. 15,5KB/s auf der SIO [1773447/2/(Speedbyte+7)/8/1024=15,4632...KB/s bei PAL], falls ich da nicht falsch liege.

12.6 KB/s: 1773447/2/(Speedbyte+7)/10/1000 = 12.667

Ist natürlich brutto und theoretisch, aber wenn ihr mit 20-22KB/s Daten schieben wollt, wie verarbeitet der A8 das? Puffer zum Ausgleich?

Daran arbeitet Fatih. In seinem aktuellen Test-Code liest er einfach fix 256 Bytes, macht aber keine Fehler Checks (Framing Error, Overrun o.ä.). Das spart schon mal ein wenig Zeit im Vergleich zu meinem Highspeed Code - da checke ich pro Byte auf Break-Taste, Framing Error und Overrun, ausserdem muss der Highspeed Code mit beliebig langen Paketen umgehen können (1, 4, 12, 128, 256 Bytes etc.).

In meinem Highspeed Code berechne ich die Checksumme innerhalb der Schleife, Fatih hat den Teil ausgelagert und berechnet sie nach dem Empfangen des Pakets. Fairerweise muss man die Zeit dafür aber natürlich mit einrechnen, die Netto-Datenrate wird dadurch etwas geringer.

Zu guter letzt darf man auch nicht vergessen, daß das Abschalten des ANTIC DMAs und der NMIs einiges bringt. Besonders im Graphics 0 Modus ist der ANTIC DMA wirklich schlimm: in der ersten Bildschirmzeile jeder Graphics-0 Zeile bleiben der CPU nur 17 von 114 Taktzyklen, den Rest klaut sich der ANTIC. Wenn man nun bedenkt, daß pro Sekunde ca. 15000 Bildschirmzeilen dargestellt werden und bei Pokey Divisor 0 ca. 12500 Bytes pro Sekunde verarbeitet werden müssen ist es fast schon ein Wunder, daß sich das überhaupt ausgeht. Bei noch höheren Geschwindigkeiten, wenn pro Bildschirmzeile mehr als 1 Byte verarbeitet werden muss, geht das natürlich schief - die CPU bekommt einfach zu wenig Zeit und "verliert" Bytes.

Bei den NMIs ist's ähnlich: wenn ein NMI "feuert" ist die CPU auch gleich mal für etliche Zyklen mit dem Interrupt-Code beschäftigt - bei hohen Übertragungsraten kann da wieder schnell mal ein Byte "verloren" gehen.

Ich bin schon gespannt wie Fatih die Timeout-Behandlung (ohne NMIs) löst und welche Übertragungsraten dann wirklich machbar sind. Es bleibt also spannend :-)

so long,

Hias

HiassofT hat geschrieben:Hallo Walter!

GoodByteXL hat geschrieben:Frage zu den Zahlen: bei Speedbyte 0 erreicht doch der A8 die theoretische Max.Speed von ca. 15,5KB/s auf der SIO [1773447/2/(Speedbyte+7)/8/1024=15,4632...KB/s bei PAL], falls ich da nicht falsch liege.

12.6 KB/s: 1773447/2/(Speedbyte+7)/10/1000 = 12.667

Klar, Matthias, 10 Bit und Dezimalpräfix. Vergesse ich manchmal, dass ein Byte nicht zwingend ein Oktett sein muss und die Berechnung umgestellt wurde von 1 KB=1024 Bytes auf 1 kB=1000 Bytes. Ansonsten müsste es 1 KiB heißen. Immer diese Änderungen

HiassofT hat geschrieben:Ich bin schon gespannt wie Fatih die Timeout-Behandlung (ohne NMIs) löst und welche Übertragungsraten dann wirklich machbar sind. Es bleibt also spannend.

Allemal - da geht noch 'was mit unserem Oldie .