Hallo SIO2USB-Freunde,

als ich heute mal die ABBUC-PD #217 (SpartaDOS 3.2d + Pascal-Demo) auf dem SIO2USB ausprobieren wollte, hatte ich das Problem, dass der ATARI 800XL oder das SIO2USB (!?) sich während des Ladevorgangs irgendwie "aufhängt". Man kann dann manchmal durch Drücken der BREAK-Taste das Laden wieder in Gang setzen, manchmal aber auch nicht. Auf dem Emu (und ich meine seinerzeit auch auf meiner 1050) gab es das Problem nicht. Weiß evtl. jemand, woran das liegen könnte?

Gruß,

Michael

Hi Michael,

warum weiss ich auch nicht, aber wenn ich Hi-Speed abschalte geht es wieder. BiboDos XF 4 LW hat das auch manchmal.

dl7ukk hat geschrieben:Hi Michael,

warum weiss ich auch nicht, aber wenn ich Hi-Speed abschalte geht es wieder. BiboDos XF 4 LW hat das auch manchmal.

Hmmmm, liegt das nun im SIO2USB oder der Software (SpartaDOS, ...) begründet? Bei XDOS 2.4f z.B. habe ich dieses Phänomen jedenfalls noch nicht beobachtet.

Hi!

mp-one hat geschrieben:Hmmmm, liegt das nun im SIO2USB oder der Software (SpartaDOS, ...) begründet? Bei XDOS 2.4f z.B. habe ich dieses Phänomen jedenfalls noch nicht beobachtet.

Ich vermute das liegt an SpartaDos, genauer gesagt an der dort eingebauten (Highspeed-) SIO Routine.

Auf meinem 800XL, angeschlossen per SIO2PC an meinen Linux Rechner bleibt die Disk auch hängen. Hab's gerade mehrmals getestet: beim ersten Mal ist der Atari ca. bis zur Hälfte des Begrüssungstextes gekommen, danach 2 Mal bis kurz nach den 2 SpartaDos Versionsinfo-Zeilen (der letzte gelesene Sektor war 6).

Wenn ich Highspeed in AtariSIO (meiner SIO2PC Software für Linux) deaktiviere läuft es besser. Keine Hänger bei 3 Versuchen.

so long,

Hias

Hi!

HiassofT hat geschrieben: Ich vermute das liegt an SpartaDos, genauer gesagt an der dort eingebauten (Highspeed-) SIO Routine.
...
Wenn ich Highspeed in AtariSIO (meiner SIO2PC Software für Linux) deaktiviere läuft es besser. Keine Hänger bei 3 Versuchen.

Es sieht danach aus, wenn ich es mit SpartaDos 3.3 pro (von Page 6) probiere, klappt es auch. Bei dieser Version ist das HS auch ausgeschaltet. Jetzt frag' ich mich aber trotzdem, ob es da evtl. doch Unterschiede zwischen den (damaligen) Hispeed-Devices und dem SIO2USB gibt. Es hätte ja sonst schon früher Probleme mit SpartaDos und Hispeed geben müssen. Oder gab es die?

Gruß,

Michael

mp-one hat geschrieben:Jetzt frag' ich mich aber trotzdem, ob es da evtl. doch Unterschiede zwischen den (damaligen) Hispeed-Devices und dem SIO2USB gibt. Es hätte ja sonst schon früher Probleme mit SpartaDos und Hispeed geben müssen. Oder gab es die?

Ob es damals Probleme gab kann ich nicht sagen, ich habe SpartaDos (so gut wie) nie verwendet. Es kann aber durchaus sein, daß es damals keine Probleme gab, die aktuellen SIO2xxx Geräte sind deutlich schneller als die alten Floppies.

Ich weiss, daß einige Highspeed Routinen Probleme mit SIO2PC (bei 56kbit) haben/hatten. Konkret geht es da um 2 kritische Stellen:

1. die Zeit zwischen Command ACK und dem Command Complete (also wenn zB die Floppy zurückmeldet, daß sie den Sektor gelesen hat)
2. die Zeit zwischen den einzelnen Daten Bytes.

Im SIO Standard ist zB für den 1. Punkt ein Minimum von 250µS vorgeschrieben. Zum 2. Punkt gibt es keine Specs, also zumindest bei 19200 bit/sec darf die Floppy die Bytes direkt hintereinander losschicken (ohne Pausen dazwischen). Bei höheren Geschwindigkeiten haben aber einige Routinen Probleme damit, da sie die Bytes nicht schnell genug verarbeiten können und dadurch einzelne Bytes verloren gehen.

In der Praxis habe ich festgestellt, daß viele Routinen mit dem 250µS Delay nicht klarkommen, deshalb verwende ich als Default in AtariSIO 300µS.

Zusätzlich habe ich einen "entspannteren" Highspeed Modus für Problem-Routinen implementiert, der 1000µS wartet und zwischen den Datenbytes jeweils für die Zeit eines Bits pausiert (lässt sich einfach implementieren, man muss nur beim Senden den UART auf 2 Stop-Bits statt einem konfigurieren).

Mit dem "entspannten" Highspeed Modus kommt übrigens auch SpartaDos klar. Genauer: es genügt die Pause zwischen den Datenbytes einzufügen, die Zeit vor dem Command Complete kann auf 300µS belassen werden. Die Routine scheint also einzelne Bytes zu "verlieren", da sie zu schnell daherkommen.

In der Routine von SpartaDos ist aber noch ein weiterer Bug: Eigentlich sollte nach einigen Sekunden ($306 ist auf $0F gesetzt, also ca. 15 Sekunden) der Timeout zuschlagen. Nach ca. 10 Minuten hängt die Routine aber immer noch, einziger Ausweg ist die Break Taste...

so long,

Hias

Hi Hias,

vielen Dank für Deine ausführliche Antwort! OK, Sparta 3.2d (und wohl auch andere Versionen ) kommen mit HS durcheinander. Nun steht im Handbuch zu SIO2USB zwar, dass für SpartaDos 3.2d ein Treiber für die Echtzeituhr enthalten ist. Beim Test dieses Treibers müsste es ja demnach irgendwie funktioniert haben. Aber vielleicht hat es da ja gerade mal "geklappt".

Vielleicht kann man ja auch die HiSpeed-Routine in SpartaDos abschalten. Außerdem kann man laut SIO2USB-Handbuch über den SIO-Befehl 0x69 eine HS-Routine vom SIO2USB laden. Evtl. kann man die dann auch mit SpartaDos 3.3 kombinieren, das keine eigene HS-Routine hat.

Ich lote halt im Moment die Möglichkeiten aus, mit HiSpeed und dem SIO2USB zu arbeiten. Ein gangbarer Weg existiert jedenfalls Dank Deines für Turbo Basic angepassten HISIO-Patches und BeWeDos schonmal . Momentan erforsche ich die SpartaDos-Schiene. Vielleicht kann ja Walter oder jemand, der SDX 4.42 und ein SIO2USB hat, testweise mal schauen, ob dort alles klappt. Davon gehe ich aber bei einem 2009er DOS mal aus.

Beste Grüße,

Michael

mp-one hat geschrieben:Hi Hias,

vielen Dank für Deine ausführliche Antwort! OK, Sparta 3.2d (und wohl auch andere Versionen ) kommen mit HS durcheinander. Nun steht im Handbuch zu SIO2USB zwar, dass für SpartaDos 3.2d ein Treiber für die Echtzeituhr enthalten ist. Beim Test dieses Treibers müsste es ja demnach irgendwie funktioniert haben. Aber vielleicht hat es da ja gerade mal "geklappt".

Vielleicht kann man ja auch die HiSpeed-Routine in SpartaDos abschalten. Außerdem kann man laut SIO2USB-Handbuch über den SIO-Befehl 0x69 eine HS-Routine vom SIO2USB laden. Evtl. kann man die dann auch mit SpartaDos 3.3 kombinieren, das keine eigene HS-Routine hat.

Ich lote halt im Moment die Möglichkeiten aus, mit HiSpeed und dem SIO2USB zu arbeiten. Ein gangbarer Weg existiert jedenfalls Dank Deines für Turbo Basic angepassten HISIO-Patches und BeWeDos schonmal . Momentan erforsche ich die SpartaDos-Schiene. Vielleicht kann ja Walter oder jemand, der SDX 4.42 und ein SIO2USB hat, testweise mal schauen, ob dort alles klappt. Davon gehe ich aber bei einem 2009er DOS mal aus.

Beste Grüße,

Michael

Als Autor des SIO2USB Uhrentreibers kann ich sagen das ich nie explizit mit SpartaDOS 3.2d getestet habe (d.h. nie mit dem Ziel, die High Speed SIO von Sparta DOS 3.2d mit SIO2USB zu testen, sondern nur die Uhr). Der Uhrentreiber sollte mit jedem SpartaDOS ab Version 2.0 funktionieren, auch mit BeWe-DOS und SpartaDOS X.

Soweit ich verstehe gibt es von jeder SpartaDOS Diskettenversion eine Reihe von DOS-Kernel mit unterschiedlichen SIO-Routinen.

Die Versionen ohne Buchstaben benutzen die OS-ROM SIO (z.b. Version 3.3 oder 3.2)

Die Versionen mit einem Buchstaben angehangen (z. B. 3.2d) haben einen Highspeedtreiber für ein bestimmtes HighSpeed SIO Gerät (also Happy, MIO, XF551 etc).

Erhard "FloppyDoc" Pütz hat hier mal eine Aufstellung gemacht, kann sein das es die mal im ABBUC Mag oder auf der Homepage von Erhard war. Walter 'GoodByte' Lojek kann zum Thema sicher auch Informationen geben.

Mit aktuellen SIO2xxx Geräten solltest Du immer die SpartaDOS Version ohne Buchstaben nehmen, um sicherzugehen. Die Versionen mit Buchstaben sind für eine bestimmte Speeder Hardware aus den 80er Jahren gemacht.

(alle Angaben ohne Gewähr aus meinem Gedächnis, und ich werde auch älter....)

Ich habe mir gerade nochmal den SIO2USB Treiber angeschaut, und dort habe ich geschrieben das ich mit SpartaDOS 3.2d getestet habe
http://atariwiki.strotmann.de/xwiki/bin ... ockUtility

Ich habe aber auf einem Rechner mit Qmeg-OS getestet, so das es sein kann das anstatt der SpartaDOS SIO die Qmeg-OS SIO genommen wurde.

Die HighSpeed SIO zu testen war auch nicht Ziel beim Test mit den Sparta DOS Versionen, sondern das SpartaDOS 3.2d mit dem Uhr zurechtkommt.

Auf
http://www.mixinc.net/atari/download_a8/sdsys.htm
findet man Informationen zu den verschiedenen SpartaDOS Kernel Dateien. 3.2d ist für "US-Doubler" High Speed.

cas hat geschrieben:Ich habe mir gerade nochmal den SIO2USB Treiber angeschaut, und dort habe ich geschrieben das ich mit SpartaDOS 3.2d getestet habe
http://atariwiki.strotmann.de/xwiki/bin ... ockUtility

Ich habe aber auf einem Rechner mit Qmeg-OS getestet, so das es sein kann das anstatt der SpartaDOS SIO die Qmeg-OS SIO genommen wurde.

Die HighSpeed SIO zu testen war auch nicht Ziel beim Test mit den Sparta DOS Versionen, sondern das SpartaDOS 3.2d mit dem Uhr zurechtkommt.

Auf
http://www.mixinc.net/atari/download_a8/sdsys.htm
findet man Informationen zu den verschiedenen SpartaDOS Kernel Dateien. 3.2d ist für "US-Doubler" High Speed.

Hallo Carsten,

alles klar. Ich hatte es halt nur im SIO2USB-Manual gelesen, dass der Treiber mit SD 3.2d getestet ist und mich dann gewundert, da SpartaDOS ja schon beim Booten die HS-Routine zuschaltet und bei mir hier auf dem SIO2USB dann oft hängenbleibt, noch bevor der Prompt erscheint. Es kann gut sein, dass beim Test die HS-Routine des Qmeg aktiv war.


Gruß,

Michael

sorry for english contribution

The problem is probably the HS driver in SpartaDOS 3.2D. With SpartaDOS 3.3b this problem does not occur. That 3.3b version has also highspeed loader.

It's a timing issue.

There are two ways of looking at this problem.

1) the sio2usb is too fast/critical ... since other sio2 systems are able to handle spartados 3.2d, and sio2usb is not able, i'd say: make sio2usb more compatible, and alter the firmware.

2) the spartados 3.2d HS loader s*cks. Also true. So you could decide to skip that version, and use 3.3b, which works with HS and sio2usb.

Sio2USB is a fantastic device. After a buggy start it is really one of my favorite devices. Unfortunately there are some 'strange beviours' like the problem described in this topic.

My advice: get yourself a decent substitution for the internal Atari OS. Like Qmeg. It is great, and sio2usb handles it perfect.

Marius

p.s. with Qmeg HS you'd better use SpartaDOS 3.3a 3.3a does not have the HS loader, so you are sure you use the OS CIOV.

Hi Marius,

meanwhile I have tested SD 3.2g with SIO2USB and it worked well. I think SD 3.2d and 3.2f have problems with the 56.000 baud (nearly SIO 3X) speed of SIO2USB. They seem to be fixed to SIO 1X or SIO 2X.

Gtx,

Michael

Hi everybody,

Sparta DOS:

the first thing I would like to mention is something about Sparta DOS 3.2d: If I remember correctly I found out in the past that this version of Sparta DOS does query the highspeed value from a drive, but does not use the reported value. Instead it uses a fixed highspeed byte. I had always problems using Sparta DOS 3.2 with mixed SIO devices using each a different high speed (APE=8, Speedy=9, Happy=A). This is why I switched to using Sparta DOS 3.3b instead.

SIO2USB:

Marius Diepenhorst had a severe problem with SIO2USB in the past and I worked together with the developers to find out what the matter was. It was discoverd that sometimes SIO2USB did not answer the first command frame after some time of leasure. Later there was a more detailed technical explanation:

"The problem lies within how the SIO2USB measures serial speed and the fact that the POKEY switches on the Clock Out signal even in the middle of a cycle which leads to false bitrates."

The SIO2USB firmware has been updated so that this POKEY bug no longer comes into play. Please use the latest SIO2USB firmware.

Flaky highspeed routines

And yes, I noticed as well that some code exists that does not time out properly in the command frame and only hitting BREAK makes things go on.

Best, Erhard

Hi!

It's so strange, since a few days I'm using my Sio2USB some more than before, and I still (again) got this strange 'hanging' problem.

But also with XDOS24F

Are other people also having issues with this?

It is on 100% standard atari, so the High Speed driver is the one that is inside the DOS itself.

Any help/feedback would be appriciated.

Hi Marius,

did you expect 3.2d to debug itself?

I assume that you read what I wrote about what's wrong with 3.2d ?

Use 3.3b and it will work.

However you should use the latest SIO2USB firmware.

There was an issue in the past where the SIO2USB tried to recognize the SIO-Speed from the first and single transmit clock cycle. Unfortunately it turned out that the POKEY switches on the TX-clock even in the middle of a clock cycle so that calculations based on the first cylce were incorrect.

This was corrected in later SIO2USB firmware versions.

Regards, Erhard

Hi,

It is odd... I have this issue ALSO with Xdos 24F

From time to time suddenly the SIO hangs, and it is not fixable with break either!
I have tested this with newest official firmware (from website) , and with both internal Flash memory and with USB stick and I have tested with 3 different Sio2USB interfaces (I have 7 of these) and they all have the same from time to time.

As always with this kind of problems it does not happen all the time, so it is very hard to debug this issue.

I will try to write a small program that forces the problem to happen, but even that is not so easy.

So if someone has idea or same results: XDOS24F ... please try and let me know; perhaps there is a fix for this dos?

Thanks a lot!
Marius

Hi Marius,

maybe it's a hardware problem.
My SIO2USB often stucked during the transmission. Sometimes, after a short break, the transmission started again.
But most of the time I had to restart the device.
The problem was a faulty IC. The RAF-Team changed it, and now my SIO2USB works perfectly since 3 years.

Tigerduck

But I have seven Sio2USB devices, and they ALL have this issue. 5 of the seven are brand-new, never used... (till now)

I have composed a small, but effective ATR image.
Simply mount one of these two ATR's (they do the same, but one of them is Single Density and the other one is Double Density). Let it run for a while. Big chance that it will hold at some point. simply mount one of the two ATR's to D1:, switch on Atari (do a real power cycle)... and watch and listen. It is a loop... it creates a test.dat file, then it displays that test.dat file, then it shows directory of disk, and then it deletes test.dat file and starts over again. Sooner or later it goes wrong (sometimes you will have to wait a few minutes... so please do not think too soon that this issue does not exist). In my opinion the I/O does not sound quite well too, but I'm very sensitive about such things, other people seem to not hearing that kind of things.

I have been thinking again about comment why SpartaDos 3.2D is not working on Sio2USB. But If what I am having here is the same reason why 3.2d does not work, I am afraid more HS-dosses and tools do not work because of this reason, and I think that is subject for investigation.

The software side (what you run on Atari) does not KNOW what device is connected. It simply expects a device that can handle HS right. If the device can not handle the requested HighSpeed it should answer to the Atari that it can not do HS as requested. And believe it or not... I had this issue with normal sio speed too a few times(!).

Why is this so important for me? Well let me explain.
Few days ago... I had to re-flash my Ultimate 1MB upgrade. I used for the first time my Sio2USB for this. And also here, the sio2usb did NOT handle the high speed right, which resulted in a hanging program cycle of 35% done. It was not possible to get the flasher or sio2usb back to live again due to this.
Result: I had to open my Atari again... I had to take out flash chip of Ultimate 1MB... I had to program it with my Eprom Burner, and place it back in Atari.

So... that was the moment I thought... this is a serious bug.

I hope sio2usb team or someone else can shine some light on this. I think Sio2USB is one of the coolest and finest devices ever created for atari 8bit, so it deserves that this is fixed. Right?

Thanks a lot!
Marius

Hi Marius,

since we definately know that 3.2d has got a certain HS bug that 3.3b does not suffer from - could you check if the problem occurs with 3.3b for a start?

Regards, Erhard

That is a good idea.

I'll do some tests with 3.3b to see what happens. You'll hear from me again soon