What is IPF?
#11
IPF can be extended to support whatever is required. That said, it currently doesn't support a few schemes found on Amiga, such as Dungeon Master v2.x and a few of the Psygnosis games that use a fairly unique encoding method.

See here for more detail, specifically the link in that first post.

In short, SPS group has to extend IPF to give it a way to describe that format.

I've always thought IPF was great format for mastering disks, but was surprised that they came up with a way to use it in emulators. It's sort of odd, and requires a DLL file that acts as a drive emulator to feed the parent emulator the data it's requesting.

A flux level image seems more natural to me, but puts more onus on the emulator author to now add low-level disk drive emulation to the code in order to read/write flux data as the drive would see it, including all the quirks inherent in those drives (exactly how timing violations are handled, weak bits, drive spin up, head seek times, mechanical variations, etc).

I think I saw somewhere that the MESS authors were implementing some sort of flux level images for their disk-based systems. If anyone's hardcore about emulation accuracy, it's them.
Reply
#12
If your emulation is going to emulate the hardware (which it should), then flux implementation is much easier than having to do conversions and extra clocking. For example, to add density support to .g64 images you would need to fetch density data for every single GCR byte and adjust the clocking - and guess what? That's still not enough for 100% compatibility. .stx format for the Atari emulators has a 32us clocking window which is not enough for 100%. IPF is also limited in this respect. As an emulation author myself, I definitely would want only 100% compatibility for my emulation if it was possible, and would do whatever is necessary to make it happen.
Reply
#13
I'm not sure that IPF is limited in that regard, previously noted functional omissions aside. IPF is just another way of describing what flux is contained on a track of a disk. It does it (as LordCrass pointed out so vividly) by providing a set of instructions on how to generate the flux transitions on a track, vs. scp or KF streams which are more of a super-high-resolution scan. Both, properly executed, will get you to an identical copy of the flux transitions on a destination disk. But, you make an interesting point otherwise.

Essentially, what is needed is a disk format to describe what a disk holds, at the lowest level possible, which, agreed, is the flux level. But, that's not useful in and of itself. Those flux transitions mean nothing to hardware (or emulated hardware) without something to transform them from those flux transitions to meaningful data. And, that is going to be unique for each controller (yes, you may get lucky with some widely used common controller chips). But with the Amiga and 15*1 drives which use very unique controllers, the best way to get traction with emulator authors is to provide the hardware emulation layer in an easily-consumable abstraction layer. Your thread on eab.abime.net with Toni is a perfect example. And, that's not going to be an easy task, based on what I saw with the recent 1541 changes to VICE. And, I think that having .scp (or any other 1541 format) not be supported by VICE would be a huge mistake and impediment to its long-term.

Jim, I recognize and appreciate that you see the KryoFlux team as the competition, and I'll bet they see you in the same light. But (and this is to both groups) having product differentiation based just on unique file formats just seems like it will be, long-term, detrimental to the retro-computing community at large. I'd rather see competition based on the hardware and the imaging/analysis/verification software; not on a file format.

@LordCrass: thanks for the link; not sure how I missed that when searching!

Thanks,
Robert
Reply
#14
Vice already supports a .p64 file format, which is a flux-level format. I haven't looked at it, I don't have any images in this format, and I don't know how well it currently works. If it works well, it may just be a matter of supporting conversion from scp to p64, much like g64 is natively supported.
Reply
#15
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.
Reply
#16
Another big advantage of using .scp flux level files in an emulation is that it is extremely easy at that point to use the SCP hardware to read/write real disks. The data returned from the SCP hardware is the same data contained in the files. The drive emulation would only need to send motor on/off and head step commands to the SCP hardware and the read/write would be the same as the .scp flux data format.
Reply




Users browsing this thread: 1 Guest(s)