Extending the ATR file format

[HiassofT]

I hope we can get these 512 byte per sector ATRs working with SIO2SD (a firmware patch is required).

I'll put this on #1 of my TODO list after I fixed pokey divisors 0 and 1. If the Atmel has enough RAM it shouldn't be too hard. This weekend I implemented support for 512 byte ATRs in AtariSIO, still have to do some testing, but the first tests looked fine.

 

I can't tell when I'll start with the SIO2SD stuff, first I have to dig into the source code, setup build environment and verify that compiled the source code really works. Currently I'm hooked up with Pokey testing, just discovered some really, really weird behaviour yesterday (details will be posted in the "POKEY serial and IRQ timing details" thread soon).

 

so long,

 

Hias

[flashjazzcat]

I'll put this on #1 of my TODO list after I fixed pokey divisors 0 and 1. If the Atmel has enough RAM it shouldn't be too hard. This weekend I implemented support for 512 byte ATRs in AtariSIO, still have to do some testing, but the first tests looked fine.

 

I can't tell when I'll start with the SIO2SD stuff, first I have to dig into the source code, setup build environment and verify that compiled the source code really works. Currently I'm hooked up with Pokey testing, just discovered some really, really weird behaviour yesterday (details will be posted in the "POKEY serial and IRQ timing details" thread soon).

That's great news. I can't wait to see what you come up with. Your research into SIO is always fascinating to me.

[Shawn Jefferson]

It's almost incomprehensible to me. But I'm glad someone is doing it.

[+Stephen]

Yeah - it sure is fun to read.

[flashjazzcat]

I finally got hold of the SIO2SD firmware source code last night: time permitting, I'm going to have a crack at building it just for laughs. I've located the sector size routines and sure enough anything but 128 or 256 bytes gets ignored. Shouldn't be too hard to modify the code to cope with 512 bytes per sector and more. Divisor 0 and 1 are beyond me, though: I'll leave that to Hias!

Edited September 1, 2010 by flashjazzcat

[HiassofT]

Yeah - it sure is fun to read.

I'm glad you are enjoying it! Doing this research stuff is also a lot of fun for me, we have this ~30 year old computer here and there's still new things to discover. Absolutely amazing.

 

I finally got hold of the SIO2SD firmware source code last night: time permitting, I'm going to have a crack at building it just for laughs. I've located the sector size routines and sure enough anything but 128 or 256 bytes gets ignored. Shouldn't be too hard to modify the code to cope with 512 bytes per sector and more. Divisor 0 and 1 are beyond me, though: I'll leave that to Hias!

Feel free to go, this means less work for me :-)

 

I certainly don't want to discourage you, but when I compiled the 2.5 source today I saw that the current code already uses 1831 bytes of RAM (out of 2048). And in addition to that, the CPU also needs some space for the stack... So it could get quite tricky to get 512 byte sectors working with SIO2SD...

 

so long,

 

Hias

[flashjazzcat]

Feel free to go, this means less work for me :-)

 

I certainly don't want to discourage you, but when I compiled the 2.5 source today I saw that the current code already uses 1831 bytes of RAM (out of 2048). And in addition to that, the CPU also needs some space for the stack... So it could get quite tricky to get 512 byte sectors working with SIO2SD...

I'm aware that the RAM is nearly full, but the sector size recognition routines quite repetitive, in as much as they could be "collapsed" some if different sizes were catered for. There's an ssize variable that at the moment only takes 128 or 256, and hopefully that value will cascade through the rest of the firmware. It should be a case of making ssize a product of LSB+MSB*256 rather than explicitly checking solely for 128 or an MSB of 1. Of course, some major re-writing will be needed to make room for a bigger sector buffer.

 

Another thing I might run into trouble with is the special 128 byte sectors. IIRC, the first 3 sectors of a 256 byte per sector disk are 128 bytes each. Is this still the case with 512 byte per sector disks?

Edited September 2, 2010 by flashjazzcat

[drac030]

Another thing I might run into trouble with is the special 128 byte sectors. IIRC, the first 3 sectors of a 256 byte per sector disk are 128 bytes each. Is this still the case with 512 byte per sector disks?

 

No. While implementing the new format into SDX, after some consideration of pros and cons, I decided to make a cut with this nonsense. So the only density where the size of first 3 sectors is different than the rest, is the regular "DD" (= 256 bytes per sector).

 

Obviously, a serial drive won't boot (except from a customized OS). But I don't think it is a real problem, one can always mount a DD image as D1 and boot from there.

Edited September 2, 2010 by drac030

[flashjazzcat]

Thanks for that info: just need to find 200-odd bytes of free RAM now.