Shut up and drive

[buddpaul]

What are the fundamental differences between the different Atari disk drives? Is one faster/better/easier than another?

[Bryan]

What are the fundamental differences between the different Atari disk drives? Is one faster/better/easier than another?

Well, it's complicated.

 

Atari originally had a low-density format that netted you about 90K per disk (810)

 

Then they developed a double density drive but never released it (815)

 

A big list of 3rd party drives appeared that supported the double density mode.

 

Atari invented a new "Dual-Density" drive that fell in between single and double density (1050). The only rationale for such a move is that it made the drive electronics a little cheaper.

A big list of 3rd party drives appeared that supported single, double, and dual modes.

 

Atari's last 8-bit drive supported all modes, plus double sided disks. (XF551)

[sup8pdct]

>Atari originally had a low-density format that netted you about 90K per disk (810)

 

this one come in 2 types. one without a data separator and one with. also 2 different mech were available

One had a reputation for not centering the disks properly.

 

>Then they developed a double density drive but never released it (815)

There is a version of dos 2.0 (2.0D) that was for this drive. The dos leaked out, the drive didn't.

 

>A big list of 3rd party drives appeared that supported the double density mode.

 

>Atari invented a new "Dual-Density" drive that fell in between single and double density (1050). The only rationale for such a move is that it made the drive >electronics a little cheaper.

More like what ever mode the disk was formated in, Dos 2.0S could still read it, tho not to full capacity. The electronics saved was 128 bytes of ram for the sector buffer. The 1050 has the most upgrades available for it as well, making it the most useful or all drives to have.

 

>A big list of 3rd party drives appeared that supported single, double, and dual modes.

 

>Atari's last 8-bit drive supported all modes, plus double sided disks. (XF551)

Also support for high speed SIO tho it is the slowest of all high speed that were already available from 3rd party vendors.

A couple of upgrades are available for the XF551.

 

James

[Marius]

Also support for high speed SIO tho it is the slowest of all high speed that were already available from 3rd party vendors.

A couple of upgrades are available for the XF551.

 

James

 

I have always been wondering why could atari release such a terrible drive. I had a xf551 and it broke in a few years. I hated the slow I/O, and the drive went crazy when you switched disks with different formats.

 

The nicest part of this drive were the possibility to hook up a 3.5" mechanic in it (and change eprom).

 

And I liked the XE look very much.

 

But as I said: It broke very soon. I don't have the parts anymore.

 

Greetz

Marius

Edited August 27, 2007 by Marius1976

[sup8pdct]

Also support for high speed SIO tho it is the slowest of all high speed that were already available from 3rd party vendors.

A couple of upgrades are available for the XF551.

 

James

 

I have always been wondering why could atari release such a terrible drive. I had a xf551 and it broke in a few years. I hated the slow I/O, and the drive went crazy when you switched disks with different formats.

 

The nicest part of this drive were the possibility to hook up a 3.5" mechanic in it (and change eprom).

 

And I liked the XE look very much.

 

But as I said: It broke very soon. I don't have the parts anymore.

 

Greetz

Marius

 

When the XF551 first came out here in Australia, they wouldn't work. It needed a rom upgrade from V7.0 to 7.07. When the drive was programmed, they didn't take into account the slightly different timing of the PAL computers so the serial bus speed was out of spec for Pal computers. I compared the roms and there is only about 8 bytes different.

CSS did 3 things for the XF551. one was a duel drive upgrade which I got. It also didn't work on PAL computers so I sent off the Differences to the creator and he duly fixed it. The duel drive upgrade makes the xf551 handle more like a 1050 but double sided and with a 3.5" mech as well in the one drive.

 

James

[ijor]

When the XF551 first came out here in Australia, they wouldn't work. It needed a rom upgrade from V7.0 to 7.07. When the drive was programmed, they didn't take into account the slightly different timing of the PAL computers so the serial bus speed was out of spec for Pal computers. I compared the roms and there is only about 8 bytes different.

 

Interesting. Do you happen to still have the difference between both versions? I suspect it wasn't exactly that they didn't take the PAL timing in account, it was probably a bug.

 

The difference between PAL and NTSC clocks is quite small, less than 1%. This is not too significant for async serial that has a much higher tolerance.

 

Now, if my math is correct, a bug in the ROM making the "bit loop" one cycle faster would still (barely) work with NTSC computers. But it would quite off from nominal, that when you add the PAL difference it then would break.

 

Checking the ROM does look like there is a serial routine patched. Hmm, the most "basic" MCU I ever worked with, was the 8051. But it now feels like the ultimate powerful micro in comparison with the 48 used in the XF551

[sup8pdct]

When the XF551 first came out here in Australia, they wouldn't work. It needed a rom upgrade from V7.0 to 7.07. When the drive was programmed, they didn't take into account the slightly different timing of the PAL computers so the serial bus speed was out of spec for Pal computers. I compared the roms and there is only about 8 bytes different.

 

Interesting. Do you happen to still have the difference between both versions? I suspect it wasn't exactly that they didn't take the PAL timing in account, it was probably a bug.

 

The difference between PAL and NTSC clocks is quite small, less than 1%. This is not too significant for async serial that has a much higher tolerance.

 

Now, if my math is correct, a bug in the ROM making the "bit loop" one cycle faster would still (barely) work with NTSC computers. But it would quite off from nominal, that when you add the PAL difference it then would break.

 

Checking the ROM does look like there is a serial routine patched. Hmm, the most "basic" MCU I ever worked with, was the 8051. But it now feels like the ultimate powerful micro in comparison with the 48 used in the XF551

 

Not at the moment.

That is what I figured was wrong in the first place. they programmed it and made loops etc bigger till it worked

Also, at what clock speed is the 8050 in the XF551 clocked at? I think it was 8Mhz.

Are you at all familer with the 8040/50? it only has 256 bytes of memory and in that are some pointers are kept, so how is a full DD sector buffered?

 

James

[ijor]

Not at the moment. That is what I figured was wrong in the first place. they programmed it and made loops etc bigger till it worked

 

Again, I don't think it was exactly like that. It seems there was a bug in one of the serial routines (there are several). It still works despite the bug with NTSC machines, almost just by chance. So they just fixed the bug.

 

Also, at what clock speed is the 8050 in the XF551 clocked at? I think it was 8Mhz.

 

At 8.33Mhz.

 

Are you at all familer with the 8040/50? it only has 256 bytes of memory and in that are some pointers are kept, so how is a full DD sector buffered?

 

Using lot of trickery. Not only that is has no more than 256 bytes of RAM, it has a single CPU register! They are saving a few bits of info in the timer, SP, user flags, and in the unused I/O ports. The "pointer" issue is solved by handling the last two bytes without a pointer in separate "unrolled" code. This way the pointer is not needed for these last bytes, they go to a fixed location.

 

What seems to me however, is that the checksum is ignored when receiving a frame! (they had no place to save the computed checksum for comparison). :!: :!: Horror! Worth to try sending a frame with bad checksum on purpose, just to verify if I'm correct.

[ijor]

What seems to me however, is that the checksum is ignored when receiving a frame! (they had no place to save the computed checksum for comparison).

 

I was wrong. Checksum is verified (in a rather clever way). At the point that the checksum is received, all the memory is used with the sector data. Timer holds a temporary, FDC registers also have data, and the computed chksum is stored in the accumulator. There is no place to actually "read" the checksum.

 

So they just compare each bit of the checksum as it is being received!

[ijor]

Checksum is verified (in a rather clever way).

 

Just in case somebody is interested on how this is implemented:

 

Imagine you have a similar task in a 1050. You are receving a double density sector, 256 bytes. You have no more RAM, the 1050 has just 256 bytes. All your registers are busy with some data, including the SP. All the I/O registers available are also busy. No place at all to store another byte!

 

You hold the computed checksum in the accumulator. You are receiving serially the checksum at bit 6 of the RIOT... This is, more or less, the equivalent 650X code:

 

SEC        ; Sentinel bit
loop:
NOP        ; Delay (several NOPs)
ROR A      ; Next bit of checksum into carry
BCS  L1   ; Bit was set

BIT IOPORT    ; Read serial bit into V
BVS error       ; Checksum error
BVC L2
L1:                  ; When bit was set
BIT IOPORT
BVC error
NOP 
L2:
CMP #0
BEQ done       ; When sentinel bit was shifted
CLC               ; Needed for next ROR
BCC loop        ; Next bit
done:

[sup8pdct]

Checksum is verified (in a rather clever way).

 

Just in case somebody is interested on how this is implemented:

 

Imagine you have a similar task in a 1050. You are receving a double density sector, 256 bytes. You have no more RAM, the 1050 has just 256 bytes. All your registers are busy with some data, including the SP. All the I/O registers available are also busy. No place at all to store another byte!

 

You hold the computed checksum in the accumulator. You are receiving serially the checksum at bit 6 of the RIOT... This is, more or less, the equivalent 650X code:

 

 

Very clever.

Have you seen the CSS single and duel drive upgrade? It has a completly rewritten rom and a small module with several wires.

The modual on the duel drive upgrade also enables the 2nd drive.

Without this modual the upgraded rom wont work. There is a hell of a lot of code to go through just to find the revelent bits of code to delete out. I had a look but not understanding the 8050 rom code very well meant i couldn't find it.

 

James

 

James

[sup8pdct]

I have the rom files here of the CSS duel drive upgrade 1.2 and 1.3. The 1.2 is the NTSC version and the 1.3 is the one fixed up to work on PAL and should work on NTSC as well. You want to look at them? I thought I had the ver 7.0 here somewhere but will have to dig deeper.

email me at sup8pdct@hotmail.com.

 

James

[MrMartian]

I have the rom files here of the CSS duel drive upgrade 1.2 and 1.3. The 1.2 is the NTSC version and the 1.3 is the one fixed up to work on PAL and should work on NTSC as well. You want to look at them? I thought I had the ver 7.0 here somewhere but will have to dig deeper.

email me at sup8pdct@hotmail.com.

 

James

 

I for one, would love to have them. I'm always playing around with the firmwares in my drives trying to tweak them and add little features.. Having more to look through would be great!

[ijor]

I have the rom files here of the CSS duel drive upgrade 1.2 and 1.3. The 1.2 is the NTSC version and the 1.3 is the one fixed up to work on PAL and should work on NTSC as well. You want to look at them? I thought I had the ver 7.0 here somewhere but will have to dig deeper.

email me at sup8pdct@hotmail.com.

 

Yes, it would be interesting, I'll email you.

 

But it will probably be difficult to follow the code without knowing what is inside the module. CSS was very fond of heavily copy protecting their products (quite ironic when coming from the company most specialized in "hacker" tools ). So I'd guess the module has "something", at that time they might even put a PAL there just for making reverse engineering more difficult.

 

And yes, following the XF551 ROM code is not easy at all. The code must be complicated for overcoming the lack of RAM. That's why I thought initially it doesn't verify the checksum.

 

Btw, it is interesting that the CSS ROM has the same PAL issue. It means it wasn't coded from scratch, but they just modified the copyrighted Atari ROM

[sup8pdct]

I have the rom files here of the CSS duel drive upgrade 1.2 and 1.3. The 1.2 is the NTSC version and the 1.3 is the one fixed up to work on PAL and should work on NTSC as well. You want to look at them? I thought I had the ver 7.0 here somewhere but will have to dig deeper.

email me at sup8pdct@hotmail.com.

 

Yes, it would be interesting, I'll email you.

 

 

 

And yes, following the XF551 ROM code is not easy at all. The code must be complicated for overcoming the lack of RAM. That's why I thought initially it doesn't verify the checksum.

 

Btw, it is interesting that the CSS ROM has the same PAL issue. It means it wasn't coded from scratch, but they just modified the copyrighted Atari ROM

 

There is a very big difference between the orignal atari rom and the CSS one. Where the atari rom has quite a bit of space, the css one has a lot less.

As for the modual, Would say there is some code in it somewhere that checks to see if it is there. finding it is the hard part.

James