VAPI library source code

[Shannon]

ok guys. Thanks for the manual link. @Mclaneinc Is the set you provided the FARB set? I want to make sure that whatever I have is the correct set for this game. Because I know it's protection is a monster..

[phaeron]

 

ACK timing, and in general timings that depend on the firmware are, surprisingly, quite critical. They usually need more precision that timing that relates to the actual disk.

 

The reason is that firmware timing is (almost, due to running off its own clock) cycle accurate. So if some program depends, probably unintentionally, on very strict firmware timing, chances that would run fine and would be released like this.

 

On the other hand, if some program depends too much on timings related to the disk, it would not work. Disks and drives are not very precise, both mechanically and magnetically. Too strict timing and the very same disk might fail in other drives, or even a different original copy might fail in the same drive, etc. ...

 

I haven't found that to be the case. The end-to-end time -- command start to final checksum byte -- is important for many disks due to phantom sector timing, but I didn't even notice an issue with ACK timing until recently I measured it. Part of the reason is that the ACK timing is shadowed by rotational latency, so most read routines will be insensitive to it unless they have a timing-related bug. Out of the original VAPI disk set on Atarimania, I think only about four disks are unable to boot with SIO patch enabled on Altirra, and that's a case where the ACK simply doesn't exist.

[ijor]

 

I haven't found that to be the case. The end-to-end time -- command start to final checksum byte -- is important for many disks due to phantom sector timing, but I didn't even notice an issue with ACK timing until recently I measured it. Part of the reason is that the ACK timing is shadowed by rotational latency, so most read routines will be insensitive to it unless they have a timing-related bug. Out of the original VAPI disk set on Atarimania, I think only about four disks are unable to boot with SIO patch enabled on Altirra, and that's a case where the ACK simply doesn't exist.

 

I didn't mean that the ACK timing is the most important one, or even that timing is the most important aspect for emulating copy protected images. Not if you measure importance by the number of titles that depend on it.

 

I meant that timings that depend on the firmware require more precision than timings related the actual disk recording. And it's not just the ACK timing. Another important one is the actual sector data transfer time from the drive to the computer. Because the drive bit bangs the serial port, and because of the overhead of the transfer routines, total transfer time is not really bit-transfer-time*number-of-bits. It's longer ...

 

Third party firmware (let alone third party drives) might have different routines that would take a different total time to perform the transfer. As (I believe) I mentioned some time ago, one notable case is the Happy 1050. The Happy routines have slightly less overhead between each byte. This difference is enough for breaking some Broderbund releases. The original disk doesn't load on the Happy, not even when the Happy is configured in Unhappy mode. Note that I'm not talking about hi-xfer or warp speed that have an actual higher bps.

 

Now, the computer doesn't really see the transfer time by itself. From the point of view of the computer it's just part of the sector reading time. So you might emulate the whole thing correctly without considering the exact transfer time. But that would mean then that you are compensating and not emulating the disk recording time accurately. It works because actual disk timing emulation, again, doesn't need so much precision.

 

This of course, affects very few titles. In the mentioned case it's even just specific versions (e.g. one version of Choplifer) of a few titles.

[ebiguy]

Can someone explain how many bytes can be written to a single track in the 810.

But, I am more interested in how to compute it (using the drive RPM, the FDC frequency, the internal clock divisor, etc) than the final result.

Thank you.

[phaeron]

The Atari FM format uses 4us (microsecond) bit cells and a disk rotation rate of 288 RPM (revolutions per minute). The 4us bit cell time comes from the FDC dividing its 1MHz clock input by four. Two bit cells are used per data bit, one for clock and a second for data, so 8us / data bit. There are no framing (stop/start) bits, so 8 data bits per byte.

 

(60000000 microseconds / minute) / (288 revs / minute) = 208333.3 us/rev

(208333.3 us / rev) / (8 us / data bit) = 26041.7 bits / rev

(26041.7 bits / rev) / (8 bits / byte) = 3255.2 bytes / rev

 

Note that this is the unformatted capacity; the formatted capacity is 128 * 18 = 2304 bytes. The difference is needed to accommodate sector headers, checksums, gaps between sectors, and the gap at the end of the track. One 810 ROM formats sectors as follows:

• 6 x $00 bytes
• 7 bytes for sector address field (IDAM, track, side, sector, size, 2x CRC)
• 17 x $00 bytes
• 1 byte for Data Address Mark (DAM)
• 128 data bytes
• 2 bytes for data field CRC
• 9 x $00 bytes
• 3 x $FF bytes

This gives an overhead of 45 bytes per sector. The remaining gap is at the end of the track so the drive doesn't overrun the track during formatting if its clock is slightly slow or the disk is rotating slightly fast.

 

For drives that spin at 300 RPM (XF551) or 360 RPM (PC HD capable), the bit cell period is shortened to 3.8us or 3.2us to compensate so it ends up the same on disk.

[ebiguy]

Thank you very much for your explanation.

You end up with the same result I had

 

I thought that the bytes could not fit in the track because of the first 256 bytes before the index address mark.

If you add these bytes to the rest, it exceeds the 3255 but in fact these bytes are there only to be sure that the space betwwen the last sector and the first sector is also formatted but it is partially overwritten when writing the last sector.

 

One more question then.

If we use the Archiver/Editor (which has by default the same byte layout, gaps included), we see can see that we can not add another full sector or the first one disappears (its ID being overwritten by the last sector).

But trying to do so with a 1050 works perfectly. 19 full sectors is OK.

I tried that with several drives, all at 288 RPM.

 

How do you explain this difference ? Your calculatiions should be valid on both drives (810 and 1050) and the 19th sector should not fit in any drive.

[phaeron]

Yes, the disk drive purposely overwrites the track during formatting to ensure that the whole track is written. The index sensor is not used in Atari drives, so the firmware has to be conservative about the required length.

 

I think the 1050 uses a slightly different track layout than the 810 -- a quick look at the disassembly shows one less gap byte between sectors. The SuperCard Pro dumps I have from a real SD disk formatted on a 1050 also show some slight anomalies, like a single bit shift between the address mark and the data mark. You'd have to use a modified 1050 to format with more than 18 sectors/track, so its track layout could vary even more. I couldn't tell you the details without actually looking at a bit-level dump from the disk.

 

With custom formats, it is possible to shrink the gaps significantly to squeeze more sectors onto the track. The gaps exist for two reasons, one to handle slop when rewriting sectors due to timing and speed variation, and to give the FDC enough time for internal operations between the address mark and the DAM. Beyond that, the only other hard requirement I know of is that the FDC requires one full sync byte prior to the IDAM/DAM.

[ijor]

As phaeron is saying, custom firmware (or hardware) can use different gap lengths and easily accommodate one extra sector. Gap III, the gap between sectors can be reduced down to two bytes, or even just one if you are not going ever to write the sectors (just format). The gap between the last and the first sector can also be reduced, as much as you dare you have the actual current RPM of the drive.

 

This is true for the 810 and the 1050.

 

 

The SuperCard Pro dumps I have from a real SD disk formatted on a 1050 also show some slight anomalies, like a single bit shift between the address mark and the data mark.

 

This should be only an artifact of the write splice when writing the sectors afterwards. Should not be any bit shift at format time.

 

[ebiguy]

And do the address marks need to be byte aligned between each other ?

I mean when the FDC detects an ID address mark, does the Data address mark need to be exactly several bytes later.

For example if I have

ID byte

header

2 CRC

17 x $00 bytes

3 bits (clock & data)

DAM

etc

Is the DAM detected by the FDC or not ?

Edited August 1, 2016 by ebiguy

[ijor]

And do the address marks need to be byte aligned between each other ?

No. They don't have even to be bit aligned. As a matter of fact, they usually aren't. When you later write the sector data, both marks loose their original alignment.

 

 

For example if I have

ID byte

header

2 CRC

17 x $00 bytes

3 bits (clock & data)

DAM

etc

Is the DAM detected by the FDC or not ?

Yes. But you can't create such a gap at format time with the FDC, you need custom hardware, like say, a BitWriter, at least.

 

[ebiguy]

Another question about the 810 stepper motor.

This is a 2 phases motor so the head is moved by setting thi sequence :

PHASE1 + PHASE2

PHASE2 + PHASE3

PHASE3 + PHASE4 and so on.

 

Do you know what happens if this sequence is used

PHASE1 + PHASE2

PHASE2

PHASE2 + PHASE3

PHASE3

PHASE3 + PHASE4 and so on.

 

Does the head move when setting only PHASE2 after PHASE1+PHASE2 ?

If yes, would it be a half track move ?

I did not try it yet on the real 810 drive but can do it if nobody has the answer.

[ijor]

Another question about the 810 stepper motor.

...

Do you know what happens if this sequence is used

...

 

I'm not sure. Not really my area of expertise. May be the guys that repair drives know better. Bob, Brian?

[phaeron]

There are some possibly pertinent references to quarter tracking in the Apple Disk II literature, where the stepping pattern is altered to cause the head to stop halfway between normal stepping locations. I'm not sure how much it can be related to the 810, since the stepping pattern appears different -- Disk II stops with one phase, whereas the 810 stops with two. It's reported to not be that accurate, though, so if you can do similar on the 810, the same probably is true.

[gianlucarenzi]

Is there any chance to have VAPI library running under Linux? I do not have any Windows machine, so it would be great if the Atari 1050 Disk Drive connected to SIO2USB from PC should read tracks for dumping original disks I currently own...