SDrive-Arm (SDrive2) issues/questions

[gargoyle]

Sorry, duplicate due to connection problem, deleted.

Edited June 22, 2017 by gargoyle

[VicViper]

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.

I see, any good sources for XEX files? I had been grabbing file dumps from Atarimania but alot of them seem to not work with this device.

[+Philsan]

The best source: http://www.mushca.com/f/atari/index.php?idx=A

[alsp]

 

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) 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).

 

 

Sorry, miss this thread at the beginning...

 

I'm not very deeply dive in High speed modes because don't have any extension for my Atari yet. But to check that its work I've used TurboDOS and when I set up lower divisor and start turbodos it's works with high speed quite correct.

But As I know current XEX loader (used in FW) don't use high speeds now, its use bios routines to access SIO - so if you have modified for high speed AtariROM than (I hope) after starting SDrive.atr it should use selected high speed mode.

SDrive.atr needed just to setup device firmware and select required parameters, all other works done by Atari itself. SDrive only respond to drive access requests and if software access drive with usual speed - it will be usual.

Other variant - change loader to use high speed. In general XEX loader can use its own routines to access drives and reprogram SIO for high speeds.

 

PS: I plan to make possibility to move configuration from emulated drive to sd card itself, and in this case SDrive will able to read configuration without launching sdrive.atr.

PPS: UART programming routines used in current firmware should setup SIO speed quite accurately because using fractional dividers for base frequency, so it should works with any speed modes at the end of stabilization.

[Roydea6]

 

Sorry, miss this thread at the beginning...

 

I'm not very deeply dive in High speed modes because don't have any extension for my Atari yet. But to check that its work I've used TurboDOS and when I set up lower divisor and start turbodos it's works with high speed quite correct.

But As I know current XEX loader (used in FW) don't use high speeds now, its use bios routines to access SIO - so if you have modified for high speed AtariROM than (I hope) after starting SDrive.atr it should use selected high speed mode.

SDrive.atr needed just to setup device firmware and select required parameters, all other works done by Atari itself. SDrive only respond to drive access requests and if software access drive with usual speed - it will be usual.

Other variant - change loader to use high speed. In general XEX loader can use its own routines to access drives and reprogram SIO for high speeds.

 

PS: I plan to make possibility to move configuration from emulated drive to sd card itself, and in this case SDrive will able to read configuration without launching sdrive.atr.

PPS: UART programming routines used in current firmware should setup SIO speed quite accurately because using fractional dividers for base frequency, so it should works with any speed modes at the end of stabilization.

I think that I screwed the Sdrive.atr, and need another. Could you please post the original SDRIVE.ATR. I am using a different microSD card than the one sent with package.

[alsp]

I think that I screwed the Sdrive.atr, and need another. Could you please post the original SDRIVE.ATR. I am using a different microSD card than the one sent with package.

You can find it on github

[gargoyle]

I am using a different microSD card than the one sent with package.

 

Did the package include a microSD card? I didn't get one with my package and don't remember it being mentioned here: http://atariage.com/forums/topic/262509-sdrive-arm-preorder/page-1

[alsp]

 

Did the package include a microSD card? I didn't get one with my package and don't remember it being mentioned here: http://atariage.com/forums/topic/262509-sdrive-arm-preorder/page-1

 

It was small bonus for first fully assembled orders...

[gargoyle]

 

It was small bonus for first fully assembled orders...

 

Ah ok then.

[BillC]

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

There are utilities to convert boot tapes to boot floppies, I did this with a tape of Space Invaders Deluxe when I got my first 1050, but I believe the program I used only worked for single stage tape programs. An ATR of such a floppy should be compatible with any drive emulator.

 

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

AFAIK the SDrive only works with SD cards, not SDHX/SDXC, which have a limit of 2GB. From what I read this was a limitation of what the creator was able to achieve for the ATmega8.

The SIO2SD can handle larger SD cards because it uses the ATmega32, but I believe the V.3 firmware is required for this.

[alsp]

AFAIK the SDrive only works with SD cards, not SDHX/SDXC,

 

Subject device support SDHC and FAT32, so there are no limits...

[Roydea6]

I just now got around to noticing the RO/RW switch on the Sdrive2.

 

Question: Just when would anyone move the switch to RO, and WHY?

[alsp]

I just now got around to noticing the RO/RW switch on the Sdrive2.

 

Question: Just when would anyone move the switch to RO, and WHY?

 

Just because it is drive emulator =) and like and on real disk you able to adds write protection.

[Stormtrooper of Death]

Transdisk is an old utility disk that was for sale in the 80s/90s, that is able to copy multi-part tape games to floppy. Might be handy for the SD memorycard floppy emulators.

[Roydea6]

96 02 80 16 80 00 00 00 00 00 00 00 00 00 00 01 ATR header with last byte being 01 usually Write protects the atr in most emulation. Does this hardware follow this concept??

[gargoyle]

96 02 80 16 80 00 00 00 00 00 00 00 00 00 00 01 ATR header with last byte being 01 usually Write protects the atr in most emulation. Does this hardware follow this concept??

 

Since this is not part of the official ATR header, it probably doesn't.

[alsp]

 

Since this is not part of the official ATR header, it probably doesn't.

 

Right, there is no support of such feature for a while. Is it really needed?

[HiassofT]

The original ATR specs from Nick Kennedy's SIO2PC readme.txt defines the 9th byte of the header as "disk flags", containing the write-protect flag in bit 5:

 

STRUCTURE OF AN SIO2PC ATARI DISK IMAGE:

It's extremely simple. There is first a 16 byte header with the following
information:

WORD = special code* indicating this is an Atari disk file
WORD = size of this disk image, in paragraphs (size/16)
WORD = sector size. (128 or 256) bytes/sector
WORD = high part of size, in paragraphs (added by REV 3.00)
BYTE = disk flags such as copy protection and write protect; see copy
protection chapter.
WORD=1st (or typical) bad sector; see copy protection chapter.
SPARES 5 unused (spare) header bytes (contain zeroes)

...

Recall that an SIO2PC disk image has a 16 byte header.  There are a few
bytes now used to tell SIO2PC about the good/bad status of the disk.
The 9th byte of the header contains information in individual bits.  Bit 4 =
1 means the disk image is treated as copy protected (has bad sectors).
Bit 5 = 1 means the disk is write protected.  The 10th and 11th bytes of
the header are a word which contains the number of the first (or of a
typical) bad sector.  What I mean by typical is that it does contain both
bad sector status and good sector status.

Since I use that feature quite often I've added support for that write-protect bit in my patched SDrive firmware versions.

 

so long,

 

Hias

[gargoyle]

My mistake, so it does have the write protect bit on the 9th byte, must have missed that when i last looked at the specs as i wasn't really interested in the copy protection and didn't read that section.

Edited June 27, 2017 by gargoyle

[gargoyle]

 

Right, there is no support of such feature for a while. Is it really needed?

 

I don't know others, but i don't need it

[ijor]

 

Right, there is no support of such feature for a while. Is it really needed?

 

I guess it's a lot a matter of personal preferences. But for me it is much more important the write protect physical switch. As a matter of fact, if the write protect bit in the ATR image is supported, I would like a way to override it. But then again, that's me.

[AtariGeezer]

Steven Tucker's v3.00 ATR Header does use the last Byte as a Flag for Write Protect as described here:

https://www.atarimax.com/jindroush.atari.org/afmtatr.html

[HiassofT]

Given the (ab)use history of the ATR format I'm not surprised at all to see these descriptions that deviate from the standard. Also note that Jindroush' description lists the high part size of the paragraph only as a byte instead of a word. If the CRC word from this description (on an unaligned offset BTW) would have anything other than 0 in it's low byte the image won't load on any other implementation that reads high paragraphs as a word. I haven't come accross any images with CRC values set in the wild though.

 

so long,

 

Hias

Edited June 30, 2017 by HiassofT

[AtariGeezer]

Also note that Jindroush' description lists the high part size of the paragraph only as a byte instead of a word. If the CRC word from this description (on an unaligned offset BTW) would have anything other than 0 in it's low byte the image won't load on any other implementation that reads high paragraphs as a word.

 

so long,

 

Hias

That is true, that wouldn't allow 16meg ATR's. I'll revise my program to use the correct Flag Byte....

[HiassofT]

That is true, that wouldn't allow 16meg ATR's. I'll revise my program to use the correct Flag Byte....

16meg ATRs will work fine as long as you make sure byte 8 of the header is set to zero. With 3 size bytes the limit is 2^28 (3*8 + 4, since size is stored in 16-byte paragraphs) i.e. 256MB.

 

Currently we aren't hitting that limit, but we're already near it. The!Cart programming images for the PC use a sector size of 8k, an image of 65535 such sectors would have 512B. As The!Cart is only 128MB that'd still fit into 3 size bytes.

 

Anyways, fixing the program and making sure the size is stored correctly as 2 words is a good idea. AtariSIO and AspeQt/RespeQt read 2 words, so if someone would actually store part of a checksum in the highest bytes these programs would probably reject the ATR (as they'd see an xx GB image).

 

From a quick glance at the source code it looks like the Atari800 emulator also uses 2 size words, but has write protect at byte 16 instead of 9. Altirra checks only the first size word in case of <= 256 bytes per sector and doesn't read the size header bytes at all for larger sector sizes and relies on the file size instead. When writing an ATR it writes out 3 size bytes and has the 8th byte always set to 0.

 

so long,

 

Hias