12-30-2013, 10:02 AM
I have not looked at .p64 images, but I read it was not flux, but more like IPF where it tries to describe the layout - instead of just doing it.
As far as emulations are concerned, the coding to implement flux level data is far easier than having to implement something that "describes" the format. With flux support you just emulate the exact hardware like the real thing. When you do this, flux files (no matter who/what generates them, as long as they are accurate) will give you 100% compatibility. The idea of an IPF being some sort of perfect representation of the disk layout for a particular program is ludicrous at best. EVERY single disk produced on a TRACE machine was different. There is no way to have one sample represent all samples that were produced. Knowing this, the obvious step is to make a foundation that will allow any and all of those versions to work.
There are programmers that can look at the requirements to implement a simple clocking mechanism vs. a complex check of data, timing, and cases, and will know immediately which is easier to implement. The .stx format for the Atari ST is really complex and involved (like IPF). If the raw flux data was just clocked in the background as the virtual disk was "spinning", then the data separator emulation will be just like the real thing. Out comes the data exactly like the real hardware. This is how SCP's floppy drive emulator will work as well. There is a single clock that is loaded with each flux transition and is clocked out on the RDData line, just like the real hardware. When the head is stepped, the file pointer is moved to the correct offset and the new data is clocked out from that point. When the wrap point occurs, the data pointer is reset back to the start.
As far as emulations are concerned, the coding to implement flux level data is far easier than having to implement something that "describes" the format. With flux support you just emulate the exact hardware like the real thing. When you do this, flux files (no matter who/what generates them, as long as they are accurate) will give you 100% compatibility. The idea of an IPF being some sort of perfect representation of the disk layout for a particular program is ludicrous at best. EVERY single disk produced on a TRACE machine was different. There is no way to have one sample represent all samples that were produced. Knowing this, the obvious step is to make a foundation that will allow any and all of those versions to work.
There are programmers that can look at the requirements to implement a simple clocking mechanism vs. a complex check of data, timing, and cases, and will know immediately which is easier to implement. The .stx format for the Atari ST is really complex and involved (like IPF). If the raw flux data was just clocked in the background as the virtual disk was "spinning", then the data separator emulation will be just like the real thing. Out comes the data exactly like the real hardware. This is how SCP's floppy drive emulator will work as well. There is a single clock that is loaded with each flux transition and is clocked out on the RDData line, just like the real hardware. When the head is stepped, the file pointer is moved to the correct offset and the new data is clocked out from that point. When the wrap point occurs, the data pointer is reset back to the start.