VAPI Image back to disk

[HiassofT]

Is the 128 byte limit in the first three sectors only enforced by DOS in software when writing the boot sectors in double density to insure boot compatibility with the OS? OR, is it the drive controller itself that is hardwired to do this with the first three sectors? If a floppy is formatted and DOS/bootloader is NOT written then can the entire 256 bytes of the first three sectors be read/written on Atari drives?

It's the drive's firmware which truncates the first three sectors to 128 bytes, and I guess it's up to the drive which data it writes to the second half (haven't checked this, in AtariDsk I just padded the remainder of the sector with $FF).

 

This happens at the SIO level, so a XF551 / Happy / Speedy will only accept 128 bytes for the first 3 sectors - no chance to access the remaining 128 bytes. But as the whole disk is formatted with 256 byte sectors, you could upload some code to your Happy / Speedy to access the whole 256 bytes.

 

so long,

 

Hias

[kenjennings]

Is the 128 byte limit in the first three sectors only enforced by DOS in software when writing the boot sectors in double density to insure boot compatibility with the OS? OR, is it the drive controller itself that is hardwired to do this with the first three sectors? If a floppy is formatted and DOS/bootloader is NOT written then can the entire 256 bytes of the first three sectors be read/written on Atari drives?

It's the drive's firmware which truncates the first three sectors to 128 bytes, and I guess it's up to the drive which data it writes to the second half (haven't checked this, in AtariDsk I just padded the remainder of the sector with $FF).

 

This happens at the SIO level, so a XF551 / Happy / Speedy will only accept 128 bytes for the first 3 sectors - no chance to access the remaining 128 bytes. But as the whole disk is formatted with 256 byte sectors, you could upload some code to your Happy / Speedy to access the whole 256 bytes.

 

I found source code for MyDOS and confirmed the way it behaves. It goes out of its way to insure read/write to the first three sectors is done with only 128 bytes.

[ijor]

Which 360K drive is in your opinion the best one for writing with kryoflux? The C64 people should face the same problem, dont they?

 

I'm afraid I don't have a specific model recommendation. Yes, C64 people should be in a similar situation, but last time I checked they still didn't support C64 write back. So don't count of C64 people having (at least not yet) more experience than us on the matter.

 

In general, I would try to avoid if possible the oldest drives. The more newer drives tend, naturally, to have electrical characteristics more similar to HD drives. Use the shortest (and best, ideally shielded) possible cable. Do not connect two drives at the same time. If present and possible, remove any resistor termination pack from the drive (but then you might need to put it back when connecting the drive to some other hardware).

 

Would be a pleasure, to upload dumps in a public place. But I thinks one of SPS people should create the public place and do some communication.

 

I doubt very much they would ever do something like that (but I don't blame them). If we want a public raw dump repository we would need to arrange for that by ourselves.

 

Would anyone know WHY the original drive designers decided to invert all the bits on the disks?

 

I remember reading some kind of explanation long ago. I can't say for sure if it is the real reason, and now I don't even remember where I read it

 

What I read is that it was just a simple, silly, but actually harmless bug on the very first 810 firmware. The 810 hardware uses a very old FDC (the actual floppy controller) that has an inverted data bus interface. So you must invert any data that you send to or receive from the FDC. The bug was that they forgot to invert the bytes for the actual data sectors (or they inverted it twice, don't remember)

 

Once the drive was released with the bug, and once disks were written and mastered inverted ... then every future compatible drive had to follow through.

[Shannon]

I remember that it was myutil on the PC that had the first documentation of inverted data that I saw. It's also true that using 1.2M drives causes problems for SD/DD systems because the track is narrower (so more tracks can be written). This means if you re-write old disks on a HD drive, the middle of the old track is erased but the outer edges will contain traces of the old data. This makes the disks unreliable unless they are degaussed first.

 

Interesting.... I had a PC program that a guy gave me that let me write to SD/DD disks on a PC. It had similar issues. After a few writes to the disk it would become unreadable in the Atari and I would have to reformat it.

[fiath]

Would be a pleasure, to upload dumps in a public place. But I thinks one of SPS people should create the public place and do some communication.

 

I doubt very much they would ever do something like that (but I don't blame them). If we want a public raw dump repository we would need to arrange for that by ourselves.

 

I support them being public as I said before. It's not our data after all.

 

Anyway, we need to update our server, so having an alternative location for them to reside would be useful for us too.

[fibrewire]

Any update on a dump site? Is there unanimous decision for the format Atari images generated with Kryoflux?