I want o take a stab at designing my own SD memory disk drive for my Atari 800. I have fairly detailed technical documentation but would appreciate some thoughts on how to go about it.

Some background. The computer communicates to all external devices over an SIO port. Each device responds to its address. The protocol is exclusive to Atari. Communicating to the device and getting it to respond on its address is not the problem.

I would like to make my drive compatible with the legacy disk drive. But I also want to keep the SD memory chip compatible with DOS so I can easily load programs from a PC.

But first a basic general question. The manual says the format command writes sector addresses onto the tracks. Now I know I need to look deeper into the manual but hoping someone could get me started on the basics so I know what to look for. In general what would this look like? Formatting a disk is something I never gave much though to of exactly how it works. So how does it work?

Now for thoughts of being compatible in both worlds. The old diskette drive is only 90K. I need to check for the maximum limit the OS can handle but something tells me it is not much more than that. So one thought was to "format" memory instead. On boot up of the virtual drive files would be loaded from the SD drive into memory.

Another thought was to not worry about formatting at all (at least form the Atari drive stand point). When a read or write is requested by the host Atari, the software in the MCU would do the translation to access the data on the SD drive using the modern FAT system.

Thoughts on that?

 

Lotharek may help you... http://sio2sd.gucio.pl/wiki/SoftwareATARI_en

He has done loads of conversions.... I have one for the Amiga and the old BBC B+...

http://atariage.com/forums/topic/249128-atari-800-and-sio2sd/ Also discussed here..

 

Original floppy formatting was (for the most part) done in tracks and sectors. Tracks were concentric bands around the hub, and sectors were the pieces each track was broken into. The farther out the track from the hub, the more sectors it had. In many cases, the track(s) near the hub were reserved for disk information- where files began, how many sectors allotted to a file, and hence the source of a disk directory. Each sector tended to have a header stub, and one of the things it had in that stub was what the next sector was, so that the disk driver could simply follow the trail of sectors to recover the file. Simplistic, but it worked.

 

Original floppy formatting was (for the most part) done in tracks and sectors. Tracks were concentric bands around the hub, and sectors were the pieces each track was broken into. The farther out the track from the hub, the more sectors it had. In many cases, the track(s) near the hub were reserved for disk information- where files began, how many sectors allotted to a file, and hence the source of a disk directory. Each sector tended to have a header stub, and one of the things it had in that stub was what the next sector was, so that the disk driver could simply follow the trail of sectors to recover the file. Simplistic, but it worked.

Yes but how did the drive know where the sectors and tracks were? I do seem to remember the pointer you mentioned. Sort of like a linked list.

I think I have a sector reader in my stash somewhere. If I can get the disk drive up and running, that might shed some light on to how it all works.

 

Lotharek may help you... http://sio2sd.gucio.pl/wiki/SoftwareATARI_en

He has done loads of conversions.... I have one for the Amiga and the old BBC B+...

http://atariage.com/forums/topic/249128-atari-800-and-sio2sd/ Also discussed here..

Looks like he has a driver. That would make things a lot more simple. I would need to figure out how I would get it loaded initially and how I would make it emulate the existing disk driver. I have written a driver for an RS232 interface I designed back in the day. Atari could not have made it easier to add your own drivers. They really did a fantastic job with the OS.

I also think there is an open source project out there for the Arduino.

I would need to decide if I want to go Arduino or pic. I am far more familiar with the pic. Actually never worked with Arduino but the Arduino has a far more mature SD memory and supported library. There is one for the pic out there but I don't think it is widely used.

 

The one thing I like about Arduino...I can get almost ANY micro... I use a pic32 on a chipkit board... I just download the relevant .Jason file and viola!! Arduino and pic32... I have an M66k ( teensy 3.6 ) 32 bit... Downloaded the .Jason from their site and... Viola!! Arm32 on the Ardunio..

Same code... on both the pic32 and ST32.. All pin mapped so all I need to do is remap the io…. The M66K has a 4bit SD interface which is magic for speed.

 

Found a little more info on how the computer communicates to the disk drive


Put Sector with Verify
Put Sector (No Verify)
Get Sector
Format

Each operation takes a device ID. For the disk drive that is 0x31 through 0x34 A command byte follows the device

So for example to put a sector with no verify, the computer will send a $31 (for disk 0) then a 0x50, low byte of sector, high byte of sector, checksum of the sector bytes, a 128 byte block and finally a checksum of the data.

Seems pretty straight forward and it should be fairly easy emulate this with a MCU.

What is still need to figure out is how to respond with error status.

Also what I need to figure out is how the computer knows how much space is on the disk? Unless that is all handled in the FAT? So as long as I have my FAT, file area, etc. etc in the correct "sectors" The OS should handle everything else for me. Does that should plausible?

And I would guess my format command would do nothing but setup the FAT and any other needed files.

 

I have old "Spectrum" gear... They have a Microdrive...( Continual tape ) It works in very much the same way..... I have tons of information on these things as I hope to interface one of these drives to a pc via USB... I have written the code on a Pic and I'll be able to read and write the tape.. No FAT though A format just fills the whole tape with logical 1..

 

This guy did a really nice job. He didn't just emulate an 810 drive with an SD card, he packaged it in a case that looks like a miniature 810 drive - that's style!

https://rossumblog.com/2011/05/04/a-little-atari-810-disk-drive/

 

Hello,

How about a gigastone sd to usb adapter?
https://www.walmart.com/ip/Gigastone-MicroSD-HC-16GB-C10-U1-with-SD-and-USB-Adapters/39991565

Bertus

 

This guy did a really nice job. He didn't just emulate an 810 drive with an SD card, he packaged it in a case that looks like a miniature 810 drive - that's style!

https://rossumblog.com/2011/05/04/a-little-atari-810-disk-drive/

Yes saw that thanks it is a beauty.

 

Hello,

How about a gigastone sd to usb adapter?
https://www.walmart.com/ip/Gigastone-MicroSD-HC-16GB-C10-U1-with-SD-and-USB-Adapters/39991565

Bertus

LOL the Atari was LONG, LONG before USB was even a glimmerin Bhatt's eye.

 

One thought I had was to use the right memory cartridge which is almost never used. I need to check the docs to see if the OS checks for the right one and then loads software or it is for an expanded cartridge only. In other words the left cartridge access the right.

I would need to use the right because the BASIC, Assembler etc cartridges go in the left.

 

As I said earlier... The guy named Lotharek did an SD for the BBC B+ This uses the exact same CPU.

I know you probably want to do it yourself.. BUT!! Look at the web site and see if you can get idea's

https://lotharek.pl/products.php?id=16

 

As I said earlier... The guy named Lotharek did an SD for the BBC B+ This uses the exact same CPU.

I know you probably want to do it yourself.. BUT!! Look at the web site and see if you can get idea's

https://lotharek.pl/products.php?id=16

Yeah I know thanks. Looked at his site. I did not see source. As I mentioned there is also an Arduino project out there that I think is public source.

I can to the conclusion that the cartridge slot idea won't work for a disk drive. I would have no easy way to get to and from the MCU on the cartridge as there are no data lines. I would probably map in my own registers to some how get data there but that would not be an easy task.