One of the Greatest Mysteries of Amiga Hardware Solved!

27 February 2002

Something that has bothered us about the Amiga hardware for a long time has now been finally solved. All this information has been passed to Toni of the WinUAE development team, and is now available here to anybody else that can use it. Thanks to Hidehiko Ogata who’s system information and dumps helped solve this mystery.

For a normal track read, 12500 bytes of data is expected because of the following:

• Normal DD (double-density) drives perform at 300 rpm:
  • 300 revolutions per minute
  • 300 / 60 = 5 revolutions per second
• The normal clock rate (the rate at data bits are output) is 2 us
  • (1 second = 1 000 000 us)
• Therefore 1 000 000 / 2 = 500 000 bits are written each second.
• Remember we have 5 revolutions per second, therefore:
  • 1 revolution should contain 500 000 / 5 = 100 000 bits
• 1 byte = 8 bits, thus 100 000 bits equals 100 000 / 8 = 12500 bytes.

A real Amiga never outputs this amount of data through writing. Previously, it was thought the slightly varying disk rotation speed was causing the issue (we thought that too). However a real Amiga with a stable 300 RPM drive outputs the amount of data that can be derived from our calculations “clearly” showing the origin of its clocking. The revelation and the solution below is due to our writing tests performed on Hidehiko’s NTSC Amiga equipment and the consistent failing to achieve the expected amount of data, we started to wonder how is that possible, and what the actual values really mean...

Basically, the FDC (Floppy Disk Controller) is not clocked by a separate clock source, but is clearly connected to system clock / video clock by some sort of counter/divider.

The magic number for the counter/divider is 56 / 8 = 7 DMA cycles/data bit, where one data bit is output if the DMA position is used to count.

This means (not considering the slight changes in drive speed RPM) that one track contains:

• 12667 bytes on a PAL machine
• 12797 bytes on an NTSC machine

These values come from the following calculations:

227 DMA cycles * 312.5 lines * 10 frames/56 = 12667.41
227.5 DMA cycles * 262.5 lines * 12 frames/56 = 12796.875

where:

227: average DMA slots on PAL
227.5: average DMA slots on NTSC: (227+228)/2
312.5: average lines on PAL: (312+313)/2
262.5: average lines on NTSC: (262+263)/2

This also solves the mystery of why 12500 bytes are never written, and where the “magic numbers” really came from, not from RPM changes for sure, as previously thought - another undocumented feature finally solved in the Amiga.

This also means if any hardware was used to slow down the video clock, the Amiga was actually outputting less data bits and therefore it completely invalidates the claim to be able to write long tracks that way.

It is a great discovery, as time will tell.

We have now also solved why most loaders read 0×3200/12800 bytes. This work is based on the following...

1. Take the 12797 NTSC value
2. Count for the h/w bug not reading the last word and thus 12799 bytes
3. Add 1, to ensure the partial data byte is completed.

This value ensures, that by reading 12800 bytes, the data written on NTSC machines is read completely for standard tracks written without hardware modifications (long tracks, etc.). This also covers these tracks written on PAL machines since they could write less bytes anyway.

Why did most Amiga developers used that value? Because they were told to! István himself (being an Amiga games developer at the time) never really knew why until now, but the same probably goes for practically all devs out there who wrote their own loaders for their games.