I'm trying to convert my emulator (UniPCemu) to use cycle-accurate Floppy disk timings (using a single timing handler, which counts time in nanoseconds, based on the timeouts specified).
Maybe move the discussion to the Kryoflux forums. They basically get those timing values from the Reader Hardware so they should know them as well as their standard deviation. They can probably also provide a suitable image format as simple binary images do not include any disk mastering information which would be required if you do a more exact emulation.
I've implemented basic step rate timings(and calculations for head load/unload). I've applied the step rate to the seek/recalibrate commands and fixed them in the latest commits.
I'm still wondering about the timings of reading/writing sector data. I cannot find anything apart from the head (un)load timings in that case. Anyone knows how long it takes to read/write a sector(and multiple sectors in a row)? What are those timings? I cannot find anything in the 82077AA manuals.
Edit: Looking at Bochs:
1 // time to write one sector at 300 rpm 2sector_time = 200000 / BX_FD_THIS s.media[drive].sectors_per_track; 3bx_pc_system.activate_timer(BX_FD_THIS s.floppy_timer_index, sector
Since the value in sector_time seems to be usec, that means 200usec per full rotation? So it takes that long to buffer a full cylinder to transfer from the floppy disk? So add the head load time to the first sector transferred only for the correct timings?
So does that mean that at 300 rpm, every round actually reads a whole track? Since the time for a round is divided by the amount of sectors per track/cylinder, does that mean that it simply differs in speed by only reading one track for each time the floppy disk turns 360 degrees? This happens no matter what the density(sectors per track times average bytes per sector)?
Yeah 300 RPM is 5 Hz, so each track repeats under the head every 200ms. So basically when the controller tries to read a sector, or multiple sectors, it has to wait until the correct sector happens to move under the head and then it can read one or multiple sectors.
But there's two things (maybe you don't need to emulate these but anyway), the sectors might be interleaved so even if you could read 18 sequential sectors from one track in one rotation of a floppy, if you order the sectors physically from 18 to 1 instead of from 1 to 18, then the disk needs to rotate 18 times to read them in correct order. Some games might use this for detecting if it is running on a copy or factory formatted disk, if it takes too little time to read a whole sector.
And physically a track has an index mark, some pre/post gaps between sectors and a sector consists of two portions, one that tells which sector is next and then after some gap there is the data of the sector. These are all specified for different floppy formats.
- The heads can be read sequentially (top/bottom of the disk), directly after each other(Sequential floppy LBA addressing).
- The track/cylinder are the rings from the outside to the inside of the platter.
- The sector is a pie slice of the track, which can thus be read both sides at the same time(Multi Track)?
Yes, and the order is for a given track, you can first read all sectors with head 0, then just switch to read all sectors with head 1, before moving on to next track.
superfury wrote:
Also, the size and location/order of a sector on the ring called track/cylinder might be random, defined by the formatted layout?
Might be. To the floppy drive, or to the floppy itself, a track is just a looping stream of magnetic pulses, and the controller has to work with that under software control. There was also few tape drives that could be connected to the floppy interface.
What happens when a multitrack read is executed on side 1? Side 0 reads/writes automatically continue reading/writing side 1 when EOT is reached, finally finishing leaving it at the next track, side 0. But what happens during a EOT MT read/write on side 1(Read sectors wirh MT on head 1)? Does it read side 1, then side 0 of the same track, finishing by leaving it in a state of side 1 on the next track? So essentially EOT which sets the head to the original head finishes the command and increases the track/cylinder number?
So:
Normal read until EOT: Reada track using specified head. Track is increased, Head set and left at used head.
MT read until EOT on head 0: Track is read on head 0 sector n until EOT. Head becomes 1. Track is read on head 1 sector 1 to EOT. Head becomes 0 causing the command to finish and track to be increased.
MT read until EOT on head 1: Track is read on head 1 sector n until EOT. Head becomes 0. Track is read on head 0 sector 1 to EOT. Head becomes 1 causing the command to finish and track to be increased.
What happens when a MT read on side 1 is issued? Does it read side 0 of the same track after it and finish, giving the result of side 1, next track?
Btw, when is the head reloaded during implicit seek and read/write sectors? Is it first loaded, then seeking, then reading/writing? Or is it seeking, then loading, then reading/writng?
What happens when a MT read on side 1 is issued? Does it read side 0 of the same track after it and finish, giving the result of side 1, next track?
Multitrack reads end at eot on side 1.
superfury wrote:
Btw, when is the head reloaded during implicit seek and read/write sectors? Is it first loaded, then seeking, then reading/writing? Or is it seeking, then loading, then reading/writng?
Presumably, it'll act as if it did an explicit seek followed by a read but it's not documented so you'd have to try it on a real device.
Some half-related info:
- A cute trick done eg on Atari ST was to use custom disk routines where you'd read one side first, then the other. As a result, the 'clicks' for moving the head from one track to the next sounded twice as fast as normal.
- On Amiga, there was no way to read a single sector. Since it only takes 200 ms to read a full track, this was negligible compared to the search to that track.
Therefore, the Amiga would always read or write an entire track to disk, even if you modified only a single sector.
This allowed them to apply an optimization: the track could be considered a ringbuffer of sectors. This meant that it didn't matter where you'd start to read or write on disk. You'd just read the whole track in memory, starting from an arbitrary sector. You could then do a quick scan through memory to find the first sector in the track.
When writing back the track, you could again just write the whole ringbuffer to the disk immediately. This meant that you didn't have to wait for the appropriate sector to appear under the head.
- Floppies are somewhat speed-sensitive. No floppy drive will spin at *exactly* 300 rpm. You'd have some amount of deviation from one drive to the next. So you won't need true cycle-accurate emulation of the whole floppy drive. Perhaps not even for the controller itself. As long as you're 'in the ballpark', things should work fine.
I mean the Kryoflux images are basically the times between magnetization changes. So you could make one thread simulate the rotating disk by just setting the currently visible magnetization to the head(s). With slightly more effort you can even implement a slow rotation start/stop as well as a slightly variable final speed and stepper times that are also a bit different each time. You can even change the sampled streams after one rotation as typically tracks are sampled five times.
In reality the exact timing is also not the same for each rotation. Even if you step to a track the head never lands at the same ideal position and this can change the magnetization timing as well.
On controller side you can read the magnetization the head 'sees' that the other thread generated with timing given by the image streams. I think this helps already greatly to get an accurate emulation. All the assumptions that there is already a certain disk structure present is a strong simplification. In reality you can image a paper disk or change the disk to another one while a program reads, which is btw used for automatic disk change detection also on PC by some programs.
The different disk images use 300 RPM as a default, except 1.2MB 5" floppy disk images, which use 360RPM. Although the read/write speeds aren't implemented yet(Only seek times for seek and recalibrate commands atm).
Strange enough: it seems to abort the transfer of data on the Generic Super PC/Turbo XT BIOS v2.6?
The log of booting MS-DOS from hard disk on XT emulation, then "dir a:", which fails with a not ready error.
It seems to start the DMA transfer, but it is either never transferred, or the transfer has a problem(there isn't the required message that the transfer has finished ("FLOPPY: Finished transfer of data (1 sectors)" to be exact). So could this mean a problem with DMA transfers?
Edit: It seems the DMA controller had a little problem with the last conversion to the new byte addressing replacement of bitfields. It was anding the mode control register with C0 and checking the resulting value against 4 and 8. This is, of course, supposed to be anding with C instead. Now DMA transfers function properly again, and the XT can read the floppy disk properly again:)
I've improved the floppy disk emulation a bit. It now should properly step to cylinder 0 using timed stepping during recalibrate, and to cylinder X during seek.
