SDrive-Arm (SDrive2) issues/questions

[gargoyle]

I have been playing around with my new SDrive² in order to learn the details of the operation as I have never owned any SDrive version, so my first impression is a lack of documentation specific to this particular SDrive. In actuality the lack of thorough documentation is nothing specific to this particular hardware, and is a rather common occurrence among the new 8 bit Atari hardware vendors/hobbyists, save a handful.

 

So playing with it until it fails is the only way to learn about the intricacies of a particular hardware. Anyway the following are a few of my findings. Mind you some of those may be due to my own ignorance of the hardware, still I consider myself rather established in testing various devices.

 

Speed Issues:

1) The device comes with factory default high-speed index of $06 (69000bps) and after my testing of various different speeds I think there is a reason for it. I am not sure whether the limitation is in the FW or the ARM processor but it looks like any speed index smaller than $06 either does not work reliably or at all. $05 for instance sort of works with SDX (with ATARI.SYS driver) but the speed testing software RWTEST fails with a Device Timeout error. At speed indexes $04 to $00 SDX cannot even recognize the drive. This is happening with an Atari computer upgraded with Ultimate1MB. The same computer has zero issues with a SIO2PC-USB running at any speed within the allowable range (indexes $0 to $28)

 

2) Trying to set the speed from within the SDrive menu using CTRL-U or U chokes the computer and one needs to press the BREAK key to regain control of the keyboard. The speed changes but not without using the BREAK key.

 

3) Trying to save or read the configuration file within the SDrive menu while the selected SIO speed index is $05, fails with Device Timeout error. Changing the speed to something else restores normal operation.

 

4) Sometimes (often enough to mention here) when loading the SDrive menu the computer chokes just before the directory entries are displayed. Pressing the BREAK key resumes, and the directory is displayed.

 

 

File system issues:

1) I initially formatted the SD card with FAT16 and copied SDRIVE.ATR and my own ATRs to it. SDrive menu started to load but then stopped on a black screen and started to buzz continuously as if it was polling the drive non-stop. So it never worked. Then I thought about formatting the card with FAT32. This seemed to fix the issue. I am not sure whether FAT16 incompatibility is by design?

 

2) During testing there was a time when the file system on SD Card got corrupted. Some ATRs copied to the SD card from the PC did not show up at all in SDrive² menu. Reformatting the card fixed the problem.

 

3) ATRs with a sector size greater than 128 bytes cannot be accessed by SDX. The drives mounted with such ATRs either are not recognized or error out when accessed. SDX normally has no issue with such files when they are accessed through a SIO2PC. I am not sure whether this is by design or a bug in the FW of SDrive²

 

 

So my conclusion is that the FW may be in need of some overhaul. Some of these problems may be unique to my case, if so please let me know. Also please feel free to add your own observations/issues.

Edited June 20, 2017 by gargoyle

[gargoyle]

Errata:

 

Speed Issues:

 

1) SDX error displayed should read "Device NAK" not "Device Timeout".

3) Speed index $05 should read $04

Edited June 20, 2017 by gargoyle

[sloopy]

You are at the cusp of the abilities of that Atari, some will do better and others will be stable at $06 and no more...

 

You can get a Timeout as the Atari can receive some of the data, but not the whole data frame...

 

When you hit the break key, the Atari resets its speed setting to the new speed, until you do this the Atari does not know the SIO speed has changed.

 

As for your file system issues, I have not used mine enough to comment.

 

sloopy.

[flashjazzcat]

Errata:

1) The SDX driver is called ATARIDOS.SYS, not ATARI.SYS.
2) ATARIDOS.SYS is a filesystem driver and isn't responsible for SIO transfers.

SIO.SYS (DEVICE SIO) is the SDX SIO driver and it's known or has been known to have issues with SIO2SD: http://atariage.com/forums/topic/229273-sdx-and-sio2sd-dont-seem-to-get-along/. Unsure if the same problems exist with SDrive, but there's another thread on low divisors with SDrive: http://atariage.com/forums/topic/219211-sdrive-high-speed-sio/

Changing a device's baud rate on the fly isn't usually going to work and will typically produce SIO hang-ups unless you reset the OS (this causes high-speed enabled operating systems or drivers to issue a speed poll to the device and refresh the internal speed index table).

As Sloopy says, there are other hardware factors which may impede the machine's ability to handle low divisors. In any case, I have an SDrive² here which I can test when I get time. We'll see if low divisors work with the U1MB's PBI high-speed SIO code.

Edited June 20, 2017 by flashjazzcat

[pseudografx]

Speed Issues:

1) The device comes with factory default high-speed index of $06 (69000bps) and after my testing of various different speeds I think there is a reason for it. I am not sure whether the limitation is in the FW or the ARM processor but it looks like any speed index smaller than $06 either does not work reliably or at all. $05 for instance sort of works with SDX (with ATARI.SYS driver) but the speed testing software RWTEST fails with a Device Timeout error. At speed indexes $04 to $00 SDX cannot even recognize the drive. This is happening with an Atari computer upgraded with Ultimate1MB. The same computer has zero issues with a SIO2PC-USB running at any speed within the allowable range (indexes $0 to $28)

Using a different DOS often helps. Under QMEG, for example, values up to $02 work well. Some Atari machines require a hardware hack on the SIO lines. I'm sure somebody here will know what has to be soldered there. Anyway, even at $06 the speed is quite decent, compared to stock 1050 (19200bps) or XF551 (38400bps).

[a8isa1]

I have been playing around with my new SDrive² in order to learn the details of the operation as I have never owned any SDrive version, so my first impression is a lack of documentation specific to this particular SDrive. In actuality the lack of thorough documentation is nothing specific to this particular hardware, and is a rather common occurrence among the new 8 bit Atari hardware vendors/hobbyists, save a handful.

 

So playing with it until it fails is the only way to learn about the intricacies of a particular hardware. Anyway the following are a few of my findings. Mind you some of those may be due to my own ignorance of the hardware, still I consider myself rather established in testing various devices.

 

Speed Issues:

1) The device comes with factory default high-speed index of $06 (69000bps) and after my testing of various different speeds I think there is a reason for it. I am not sure whether the limitation is in the FW or the ARM processor but it looks like any speed index smaller than $06 either does not work reliably or at all. $05 for instance sort of works with SDX (with ATARI.SYS driver) but the speed testing software RWTEST fails with a Device Timeout error. At speed indexes $04 to $00 SDX cannot even recognize the drive. This is happening with an Atari computer upgraded with Ultimate1MB. The same computer has zero issues with a SIO2PC-USB running at any speed within the allowable range (indexes $0 to $28)

 

2) Trying to set the speed from within the SDrive menu using CTRL-U or U chokes the computer and one needs to press the BREAK key to regain control of the keyboard. The speed changes but not without using the BREAK key.

 

3) Trying to save or read the configuration file within the SDrive menu while the selected SIO speed index is $05, fails with Device Timeout error. Changing the speed to something else restores normal operation.

 

4) Sometimes (often enough to mention here) when loading the SDrive menu the computer chokes just before the directory entries are displayed. Pressing the BREAK key resumes, and the directory is displayed.

 

 

File system issues:

1) I initially formatted the SD card with FAT16 and copied SDRIVE.ATR and my own ATRs to it. SDrive menu started to load but then stopped on a black screen and started to buzz continuously as if it was polling the drive non-stop. So it never worked. Then I thought about formatting the card with FAT32. This seemed to fix the issue. I am not sure whether FAT16 incompatibility is by design?

 

2) During testing there was a time when the file system on SD Card got corrupted. Some ATRs copied to the SD card from the PC did not show up at all in SDrive² menu. Reformatting the card fixed the problem.

 

3) ATRs with a sector size greater than 128 bytes cannot be accessed by SDX. The drives mounted with such ATRs either are not recognized or error out when accessed. SDX normally has no issue with such files when they are accessed through a SIO2PC. I am not sure whether this is by design or a bug in the FW of SDrive²

So my conclusion is that the FW may be in need of some overhaul. Some of these problems may be unique to my case, if so please let me know. Also please feel free to add your own observations/issues.

I can't speak of your other issues but your speed issue #1 was/is true of the original SDrive. To use smaller speed divisors in original SDrive we use Hias' Reichl's beta SDrive firmware. Even divisor 0 works when one of Hias' ultraspeed drivers (patched OS, MyPicoDos, HISIO.COM).

 

I assume the firmware's features could be implemented in SDrive².

 

[edit]

sorry about posting an incomplete message. I was still editing but I have arthritis in my left thumb which sometimes brushes the laptop's touchpad. Usually causes unintentional text pasting but sometimes unintentional keystrokes.

Edited June 20, 2017 by a8isa1

[lemiel]

There is small knowledge in the wild that Hias had patched SDrive firmware.

Is someone using SDrive-ng? Is it working with smaller divisor values? (Sorry Kris. Translation from Czech to English still in queue, but 20% of work done.)

[a8isa1]

There is small knowledge in the wild that Hias had patched SDrive firmware.

Is someone using SDrive-ng? Is it working with smaller divisor values? (Sorry Kris. Translation from Czech to English still in queue, but 20% of work done.)

I didn't know SDrive-ng existed!

 

I don't wish to derail *this thread* but I have one quick question. Can I replace the Atmega8 in a classic SDrive with an Atmega328, load the SDrive-ng firmware, and then have FAT32 and SDHC support?

 

-SteveS

[gargoyle]

You are at the cusp of the abilities of that Atari

 

 

As Sloopy says, there are other hardware factors which may impede the machine's ability to handle low divisors

 

Please see OP re: "The same computer has zero issues with a SIO2PC-USB running at any speed within the allowable range (indexes $0 to $28)"

 

 

SIO.SYS (DEVICE SIO) is the SDX SIO driver and it's known or has been known to have issues with SIO2SD

 

 

SIO.SYS /A is what I really meant. The /A switch causes SDX to bypass high-speed operation and let the OS handle SIO. That's what i always use working with SDX using the high-speed OS from the Ultimate 1MB.

 

Changing a device's baud rate on the fly isn't usually going to work and will typically produce SIO hang-ups unless you reset the OS (this causes high-speed enabled operating systems or drivers to issue a speed poll to the device and refresh the internal speed index table).

 

I am not sure whether SDrive2 actually changes the speed on the fly when one presses CTRL-U or U. Actually, thinking about it maybe it does and that's probably why saving the settings fail right after speed index is changed to $04.

[gargoyle]

Using a different DOS often helps. Under QMEG, for example, values up to $02 work well. Some Atari machines require a hardware hack on the SIO lines. I'm sure somebody here will know what has to be soldered there. Anyway, even at $06 the speed is quite decent, compared to stock 1050 (19200bps) or XF551 (38400bps).

 

Oh I know all about the SIO capacitors hardware hack, but my Atari works just fine with SIO divisor 0 (zero) when an SIO2PC is used. I see no computer related reason for it to fail at the same speed with another peripheral device. This leads me to believe the limiting factor here is the peripheral not the computer. Yes, it is true that divisor $06 is enough for most if not all purposes but the issue here is to find the reason why it is failing. Maybe the reason is hidden between the lines of the original SDrive documentation. The docs say SDrive supports 19 to 69K bps. SDrive² on the other hand doesn't seem to specify any speed limits, and using an ARM processor i assumed that it would support all SIO speeds. I may be wrong in my assumption, but I guess only the author of the new firmware can verify that.

[sloopy]

 

 

 

Please see OP re: "The same computer has zero issues with a SIO2PC-USB running at any speed within the allowable range (indexes $0 to $28)"

 

 

 

 

SIO.SYS /A is what I really meant. The /A switch causes SDX to bypass high-speed operation and let the OS handle SIO. That's what i always use working with SDX using the high-speed OS from the Ultimate 1MB.

 

 

I am not sure whether SDrive2 actually changes the speed on the fly when one presses CTRL-U or U. Actually, thinking about it maybe it does and that's probably why saving the settings fail right after speed index is changed to $04.

 

That would be the other issue most likely... The divisors are not exact, and as you get into the upper speeds, the Atari has less tolerance for 'drift'... You also have the issue of how off the crystal is from exactly 1.79Mhz...

 

I will test mine tonight and see what it says... as my 800XL wont work reliably on divisors below about 4-5 on SDrive Micro, SIO2PC (Serial), SIO2PC-USB, or on my SDrive Nuxx...

[sloopy]

 

Oh I know all about the SIO capacitors hardware hack, but my Atari works just fine with SIO divisor 0 (zero) when an SIO2PC is used. I see no computer related reason for it to fail at the same speed with another peripheral device. This leads me to believe the limiting factor here is the peripheral not the computer. Yes, it is true that divisor $06 is enough for most if not all purposes but the issue here is to find the reason why it is failing. Maybe the reason is hidden between the lines of the original SDrive documentation. The docs say SDrive supports 19 to 69K bps. SDrive² on the other hand doesn't seem to specify any speed limits, and using an ARM processor i assumed that it would support all SIO speeds. I may be wrong in my assumption, but I guess only the author of the new firmware can verify that.

 

 

You can try hooking it up to a scope (and not one of those USB dongle types, something with 50-100Mhz resolution), and looking at the timing of the bit pulses...

 

sloopy.

[gargoyle]

To use smaller speed divisors in original SDrive we use Hias' Reichl's beta SDrive firmware. Even divisor 0 works when one of Hias' ultraspeed drivers (patched OS, MyPicoDos, HISIO.COM).

 

And I do use an Atari computer with Ultimate 1MB upgrade with high-speed SIO drivers enabled. Again I have no issues with an SIO2PC-USB even at divisor 0.

[gargoyle]

There is small knowledge in the wild that Hias had patched SDrive firmware.

Is someone using SDrive-ng? Is it working with smaller divisor values? (Sorry Kris. Translation from Czech to English still in queue, but 20% of work done.)

I've actually came across that patch while searching for answers, but is that firmware usable with SDrive², wasn't that written for the original SDrive?

[gargoyle]

 

That would be the other issue most likely... The divisors are not exact, and as you get into the upper speeds, the Atari has less tolerance for 'drift'... You also have the issue of how off the crystal is from exactly 1.79Mhz...

 

I will test mine tonight and see what it says... as my 800XL wont work reliably on divisors below about 4-5 on SDrive Micro, SIO2PC (Serial), SIO2PC-USB, or on my SDrive Nuxx...

I own all models of the Atari 8 bit line, among them a 800XL, a 130XE and a 600XL are the ones that I actively use (all NTSC). None of these computers have speed issues with my SIO2PC-USB, so i tend to blame the peripheral implementation rather than my computer's tolerance in these speed issues.

 

Unfortunately, I don't own a scope so I have no means to observe signal timing, just trying to use my common sense and logic.

Edited June 21, 2017 by gargoyle

[sloopy]

I own all models of the Atari 8 bit line, among them a 800XL, a 130XE and a 600XL are the ones that I actively use (all NTSC). None of these computers have speed issues with my SIO2PC-USB, so i tend to blame the peripheral implementation rather than my computer's tolerance in these speed issues.

 

Unfortunately, I don't own a scope so I have no means to observe signal timing, just trying to use my common sense and logic.

 

 

My apologies, I am not being clear enough and leaving out information...

 

Your SIO2PC-USB I would guess is probably a FTDI based one? Or one of the AtariMax units? (others are similar, but not all. and I am most familiar with the FTDI FT232RL as I have sold hundreds of sio2pc-usb adaptors with them)

 

The issue is the Atari uses non-standard baud rates, the FTDI chip in your SIO2PC-USB is capable of selecting speeds that are non-standard to a rather high degree of resolution. These SDrive type devices are not...

 

Different high speed drivers on the Atari will be more 'accepting' of data rates ( 'baud rates') that are off 'standard' or even try to be closer to common rates. Even the Atari 'standard' rates of 1x, 2x, 3x are not the same as true RS-232 rates (Serial/SIO@2x = 38400bps/38730bps, Serial/SIO@3x = 57600/59387)

 

The speeds for the divisors below 10 are:

divisor 10 = 52400

divisor 09 = 55675

divisor 08 = 59387

divisor 07 = 63628

divisor 06 = 68523

divisor 05 = 74233

divisor 04 = 80982

divisor 03 = 89080

divisor 02 = 98797

divisor 01 = 110598

divisor 00 = 125000

 

'Standard' data rates are:

110, 150, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600

 

Which as you can see the Atari is no where near in the higher reaches... But the serial-USB controller (such as the FT232RL) can use 'odd' rates as its speed can be defined using a number that is 'user' generated and allow 'steps' in speed that can more accurately match POKEY in terms of speed.

 

sloopy.

[flashjazzcat]

The same computer has zero issues with a SIO2PC-USB running at any speed within the allowable range (indexes $0 to $28)

Certainly, although this is a different device so we shouldn't rule anything out (although see below).

 

SIO.SYS /A is what I really meant. The /A switch causes SDX to bypass high-speed operation and let the OS handle SIO. That's what i always use working with SDX using the high-speed OS from the Ultimate 1MB.

Or "DEVICE SIO /A" in CONFIG.SYS. If you use the PBI HSIO in U1MB, the /A switch is unnecessary since the PBI code gets to handle the IO before anything else.

 

I am not sure whether SDrive2 actually changes the speed on the fly when one presses CTRL-U or U. Actually, thinking about it maybe it does and that's probably why saving the settings fail right after speed index is changed to $04.

 

In fact when I tested my own SDrive² more thoroughly, I could pretty much reproduce every issue reported here. This is on a machine which works well at divisor 0 using SIO2SD and a generic FTDI SIO2PC. I contacted alsp about some of the problems and he told me:

 

1) Divisor needs to be saved to the configuration (using Ctrl-W)

2) Divisor only persists when software is launched directly from the loader menu

 

The practical upshot of this is that I can see no way to use a custom SIO divisor with SDX, since SDX can not be launched from the SDrive loader. On every occasion, by the time I ended up in SDX, IO was back to divisor $06 speeds.

 

I was sent SDrive² because someone put me forward as a candidate to re-write the loader menu, but regardless of if/when that happens, I think some changes to the MCU firmware will be required to rectify the issues under discussion here.

[a8isa1]

Certainly, although this is a different device so we shouldn't rule anything out (although see below).

 

Or "DEVICE SIO /A" in CONFIG.SYS. If you use the PBI HSIO in U1MB, the /A switch is unnecessary since the PBI code gets to handle the IO before anything else.

 

 

In fact when I tested my own SDrive² more thoroughly, I could pretty much reproduce every issue reported here. This is on a machine which works well at divisor 0 using SIO2SD and a generic FTDI SIO2PC. I contacted alsp about some of the problems and he told me:

 

1) Divisor needs to be saved to the configuration (using Ctrl-W)

2) Divisor only persists when software is launched directly from the loader menu

 

The practical upshot of this is that I can see no way to use a custom SIO divisor with SDX, since SDX can not be launched from the SDrive loader. On every occasion, by the time I ended up in SDX, IO was back to divisor $06 speeds.

 

I was sent SDrive² because someone put me forward as a candidate to re-write the loader menu, but regardless of if/when that happens, I think some changes to the MCU firmware will be required to rectify the issues under discussion here.

The SDrive (the original SDrive) does indeed require the configuration program to set it's I/O speed. Even if you set the configuration in 'auto' mode it still runs behind the scene before booting from its logical D1:.

 

Another problem is the original AVR library used for Atmega development has the device operating as if it had a real UART making speeds beyond 57600 bits/sec incompatible with the Atari.

 

Hias Reichl created his own library for his firmware to use with SDrive. I'm pretty sure SDrive then uses bit-banging for the higher speeds. I don't recall if the source code was made available. I'm sorry. I don't have a head for details and I have a bad memory and Hias first wrote this firmware back in year 1 of SDrive (2009?).

 

Hias MyInit utility, used to build the MyPicoDOS loader for Atari DOS and MyDOS disks, has the ability to build a custom version for SDrive. When this custom version of MyPicoDOS runs it configures SDrive to use divisor 0 or divisor 1 (default set by user within MyInit). The new high speed for SDrive gets used regardless of what speed setting has been set in SDrive's configuration program. Please remember that these and all high speeds (above 57600) require Hias' firmware.

 

As a side note I love Hias' suite of utilities. It makes it possible to boot games at high speed even on my stock 800.

 

Perhaps a utility could be written that would let SDrive's speed be changed after SDX has booted in a similar fashion to what the custom MyPicoDOS loaders do.

 

I have no idea if any of the above is applicable to the SDrive²

Edited June 21, 2017 by a8isa1

[VicViper]

Is this device not compatible with rom files? just tried to load up Galaxian and had.... problems. Also, there is no problem putting folders inside of folders on the SD card correct? like if i was to make a G folder inside of the GAMES folder?

[+Stephen]

Is this device not compatible with rom files? just tried to load up Galaxian and had.... problems. Also, there is no problem putting folders inside of folders on the SD card correct? like if i was to make a G folder inside of the GAMES folder?

No - it only "simulates" a floppy drive.

[VicViper]

No - it only "simulates" a floppy drive.

Is it really only a floppy drive, or just a "Drive." Will it not run games that where originally on tape?

[VicViper]

Also, what is the largest format of micro SD this will work with?

[+Philsan]

Is this device not compatible with rom files? just tried to load up Galaxian and had.... problems. Also, there is no problem putting folders inside of folders on the SD card correct? like if i was to make a G folder inside of the GAMES folder?

It's not compatible with ROM files but all ROMs are available as XEX files (single executables files) and you can load them wih SDrive (and all other devices that emulate disk drives).

Yes, you put folders inside folders.

[HiassofT]

The source of my patched SDrive firmware is included in the ZIPs, just look into src and src/ChangeLog.txt. Some more details about the changes are in this thread: http://atariage.com/forums/topic/145072-sdrive-at-126kbitsec-please-help-testing/

 

As the atmel has a quite simple UART I changed the serial transmission code to do bitbanging and stretch the start bit by a little bit to compensate for the odd pokey receive timing behaviour. see the code and comments in src/bitbang.s for more details.

 

Another alternative to compensate for POKEY read timing is to use a slightly slower transmission speed, eg 125000 bit/sec instead of the nominal 126.7/127.8 kBit/sec.

 

so long,

 

Hias

[gargoyle]

Or "DEVICE SIO /A" in CONFIG.SYS. If you use the PBI HSIO in U1MB, the /A switch is unnecessary since the PBI code gets to handle the IO before anything else.

 

Yes, i no longer use SIO /A since the day I upgraded my Ultimate with your PBI version of the firmware. Before that I used to have HIAS high-speed patched OS in one of the OS slots and was using that with SDX.

 

 

 

1) Divisor needs to be saved to the configuration (using Ctrl-W)

2) Divisor only persists when software is launched directly from the loader menu

 

1) Yes, that's what I observed too.

2) If that's true then SDX should not have been affected by the speed change within the SDrive² menu, but it is. For instance change the speed to $28, save it and press INVERSE key to reboot. SDrive^2. is now in drive emulation mode with the set and saved speed. When the computer drops to the BASIC prompt, press HELP and RESET to show the Ultimate menu. Then enable PBI and SIO drivers, finally reboot with SDX enabled. You will see (or rather hear) that SDX is in standard SIO speed despite the active high-speed SIO driver. You can repeat this process with different speed indexes and test the speed with RWTEST.

So the short of it SDX is actually affected by the speed change in SDrive² menu. What is NOT affected in my opinion is the SDrive menu loader itself. It always seems to load at a given speed regardless what has been set and saved in the menu (and my guess is it is the speed index $06).