[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hardware musings



Ed Eastman wrote:
PS. Here is a sample of what I would expect in the data file:

Apple 2 Bit Stream format for the 5.25 bit copy replication of the disk II bit stream. Note each track is pre-synchronized, the emulator or hardware would need to keep track of the spinning 'angle' and the track to track seek time for protected disks only. (See LSB of FlagByte1.)

Header section, 512 bytes:
'Apple 2 Bit stream'
Rev#: two bytes
Image Checksum: 4 bytes  (algorithm TBD)
FlagByte0: 1 byte
   MSB = High = Write Protect
   LSB = Protected disk
other misc flags and bytes available as revisions are made

Track table offset 32 (157 entries, one per possible track):
    0: two byte length, one byte checksum
 0.25: two byte length, one byte checksum
 0.50: two byte length, one byte checksum
 0.75: two byte length, one byte checksum
    1: two byte length, one byte checksum
 1.25: two byte length, one byte checksum
 1.50: two byte length, one byte checksum
 1.75: two byte length, one byte checksum
    2: two byte length, one byte checksum
...
   38: two byte length, one byte checksum
38.25: two byte length, one byte checksum
38.50: two byte length, one byte checksum
38.75: two byte length, one byte checksum
   39: two byte length, one byte checksum
39.25: two byte length, one byte checksum
39.50: two byte length, one byte checksum
39.75: two byte length, one byte checksum
   40: two byte length, one byte checksum

Offset 512bytes: Track 0 bit stream (always)
+ Offset 6.25k: 2nd stored track bit stream
+ Offset 6.25k: third stored track bit stream
...
through the last stored track

File length would vary depending on how many entries in the track table.


And now that I have it written instead of in my head, I see a couple improvements that could be made right away. There could be a 'normal flag and thus reduce the size of the necessary table.

Also use a binary table instead of a byte sized table. Use a half a byte or nibble to show tracks in storage.

1 0 1 0 would be track x, not 0.25, 0.5, not 0.75, etc.

This way the length table and checksums could be reduced in size to the actual number of tracks stored x3 bytes each. This may also make room for a larger checksum if desired by the image creator.

I also noted that unless quarter tracking on a spiral, no disk will have tracks closer than .75 tracks away. or a total of 48 tracks stored assuming you used quarter tracking between 35 and 40.

It all gets a bit complicated.  Even if you assume only 36 tracks in use.

I think there should also be a 'non standard' flag. A bit for 40 tracks, a bit for half tracking, and an additional bit for quarter tracking. That way the track storage table can be managed. Of course a static mapping as suggested earlier may not save many bytes in the image file, but most of the time it will be emulated A2s anyway.

Well whomever writes the program to read a bit stream from an A2 diskette can save the data and make a table however they like.

Thankx,
Ed