Hi,

ich habe gestern die neueste Version von APE ausprobiert - und dies ist die erste APE-Version, die auf meinem PC wenigstens ab und zu einen Sektor zum Atari übertragen kann (SIO2PC.COM unter Windows ME funktioniert). An den Geräuschen, die der Atari dabei macht, kann ich hören, dass die Kommunikation zwar funktioniert, aber massive Timing-Probleme auftreten. Hat jemand schonmal untersucht, ob sich APE an das von Atari festgelegte SIO-Timing-Protokoll hält bzw. welches Timing es denn genau benötigt? (Jedenfalls scheint APE vor dem Senden von Bytes nicht zu prüfen, ob der Atari die Commandleitung aktiviert hat, um einen neuen Commandframe zu übertragen )

Gruß Dietrich (der hofft, irgendwann einmal eine APE-Version zum Laufen zu kriegen)

Why don't you try APE for DOS? That works for me always.
The windows-version (win98SE) has problems with 100% reliable 2x or 3x SIO speed.

(P1-133Mhz, 16Mb)

Cheers,
Sijmen.

Hallo Dietrich!

Dietrich hat geschrieben:Hat jemand schonmal untersucht, ob sich APE an das von Atari festgelegte SIO-Timing-Protokoll hält bzw. welches Timing es denn genau benötigt? (Jedenfalls scheint APE vor dem Senden von Bytes nicht zu prüfen, ob der Atari die Commandleitung aktiviert hat, um einen neuen Commandframe zu übertragen :( )

Deine Beschreibung passt ziemlich genau zu dem Verhalten, das vor ein paar Tagen einige User im MyIDE Forum auf www.atarimax.com Forum beschrieben haben (in Kombination mit meinem Highspeed SIO Patch). Siehe den Thread "MyIDE and APE Warp Speed", speziell die letzten Postings.

Kurzfassung: Ich habe ein Testprogramm geschrieben, bin zu einem ähnlichen Schluß wie Du gekommen und Steve Tucker hat zugegeben daß das höchstwahrscheinlich ein Bug in APE ist.

Genauer angesehen habe ich mir APE nicht, ich verwende kein Windows :-)

so long,

Hias

@mr-atari: I'll try it later, currently I'm using SIO2PC.COM (works fine also).

@Hiassoft: Interessanter Thread, danke. Nur bei mir funktioniert nicht mal Normalspeed richtig. Ich werde es jetzt mal mit einer SIO-Routine probieren, die möglichst keine Timingbedingungen an SIO-Geräte stellt. Wenn die auch nicht geht, liegt es eben an Windows...
Wie ich gesehen habe, macht das Atari-SIO einen STA WSYNC vor dem Empfang eines ACK/COMPLETE/ERROR. Das kostet bis zu 200us, könnte also die Ursache sein, wenn APE die Timingbedingungen nicht einhält. Mal sehen ...

Gruß Dietrich

Obwohl ich hier 4 PCs und 3 Laptops stehen habe, hatte ich noch keine Konstellation in der APE oder SIO2PC oder ProSystem Probleme machte. (Plus 2 weitere PCs in den vergangen Jahren)

Mag sein, dass APE sich nicht an die Standards hält. Dennoch lief es immer problemlos. Mittlerweile konnte ich drei anderen helfen ihr Interface zum laufen zu bringen. Der Fehler steckte zweimal im Detail weil man irgendwo vom Standard abgewichen ist, beim dritten mal war das Interface nicht i.O.

@Dietrich:
Im Mitgliederbereich findest Du eine Schnellhilfe zum Thema Interface+Software

SIO2PC/APE-Hilfe -> Problembehebung -> Schnellsuche

Schritt für Schritt durchgehen. Nichts auslassen, auch wenn es abwegig erscheint. Wenn der Fehler nicht gefunden wird, den Text am roten Stop-Schild lesen und ernst nehmen.

andreasb hat geschrieben:Im Mitgliederbereich findest Du eine Schnellhilfe zum Thema Interface+Software

SIO2PC/APE-Hilfe -> Problembehebung -> Schnellsuche

Im Abschnitt "Welche Software verwendest Du" ist mir noch ein kleiner Fehler aufgefallen: dort steht "16C89" statt "14C89".

Ansonsten noch ein Tip (Andreas, bitte auch noch in die FAQ mit aufnehmen):

Wenn die IDE Festplatte(n) oder CDROM(s) im PIO-Modus statt (U)DMA laufen, kann es öfters zu Aussetzern bzw. Timing-Problemen kommen, da dann das System gelegentlich für kurze Zeit blockiert ist. Die aktuelle Einstellung läßt sich im Gerätemanager (unter "Festplattencontroller" oder wie das immer genau heißt) abfragen.

Den Tip mit den VIA-Treibern sollte man auch durchaus ernst nehmen. Speziell der Treiber für den Festplattencontroller war in der Vergangenheit öfters Mist. Hier lieber auf den Treiber von Microsoft zurückgreifen, der läuft für gewöhnlich hinreichend stabil.

so long,

Hias

So,

habe jetzt mal mit einer hochperformanten selbstgeschriebenen SIO-Routine APE getestet. Lesen geht jetzt - sogar in Ultra-Speed (boah, ist das schnell, APE verwendet $08, d.h. 59000 bps). Und ohne einen einzigen Fehler (ich habe einen Dauertest gemacht, der beim allerersten Fehler aufhört, keine Retries wie im Normal-SIO). Beim Schreiben friert allerdings mein PC ab und zu ein (da hilft nur noch die Reset-Taste) Ist das schonmal jemandem passiert?

@andreasb: Boah, der Mitgliederbereich ist ja wirklich gelungen. Endlich mal kein Rumrätseln mehr mit SIO2PC!

Gruß Dietrich

@Hias: Gute Tipps. Ich werds schnellstmöglich übernehmen

Dietrich hat geschrieben:boah, ist das schnell, APE verwendet $08, d.h. 59000 bps

Falls es wen interessiert: Vor einiger Zeit habe ich mal Messungen gemacht, wie lange das Einlesen einer 180k (DD) Disk dauert:

Code: Alles auswählen

XF551 std speed:     128 sec  ->  1.4kB/sec
XF551 hi speed:       80 sec  ->  2.3kB/sec

1050 Speedy std:     114 sec  ->  1.6kB/sec
1050 Speedy hi:       53 sec  ->  3.5kB/sec
1050 Speedy hsscopy:  44 sec  ->  4.2kB/sec

AtariSIO std:        100 sec  ->  1.8kB/sec
AtariSIO xf551:       57 sec  ->  3.2kB/sec
AtariSIO hi:          34 sec  ->  5.4kB/sec

XF551 hi speed und AtariSIO im XF551 Modus nehmen als Speed Byte $10, die Speedy im hi Modus $09, AtariSIO im hi Modus $08. Was HSSCOPY bei der Speedy genau für eine Geschwindigkeit nimmt, weiß ich nicht (die Anleitung spricht von 90k, jedenfalls lädt HSSCOPY eigenen Code in die Speedy).

Wie man aber gut aus der Tabelle erkennen kann, bringen höhere Geschwindigkeiten als 3xSIO bei normalen Laufwerken fast garnichts. Die Latenzen (Lesen des Sektors von der Disk, Trackwechsel) machen dabei schon einen guten Teil der Gesamtzeit aus.

so long,

Hias