P64

[LordCrass]

This originally started in the Amiga section, but I'll post my response here since it's not relevant to Amiga.

I took a brief look at the P64 format described here and unless I've misinterpreted it, it seems that it does represent flux "pulses" at a possible 3.2M positions per track. They also appear to include the concept of flux pulse strength, which represents a relative probability that the given pulse will actually trigger.

In theory that is accurate because magnetic field strength is not binary, but I'm not sure if anything would ever require this level of detail.

[admin]

Thanks for the link. I am not sure why you need the magnetic signal strength as that is not available on any computer system ever made, and you can easily determine if there are weakbits in a flux stream on the fly. Seems like a waste of 4 bytes, but I am sure that VICE uses this field to determine weakbits.

I will have to format a disk with VICE in .P00 mode (as they call it) and look to see if it really matches this file description. If so, I would need to figure out what the flux transition time is that they are expecting. It says a 0-65535, a 16 bit value, but it does not state the sampling rate. You can't use a hard coded 0 .. 3199999 range as described as that would not handle short tracks and long tracks correctly or drives set to 297.5 RPMs, etc. I will have to figure this out. If it really supports flux correctly, then EVERYTHING would work and we can abandon g64 format completely for VICE.

[LordCrass]

They state the sampling rate is 16MHz (every 62.5ns).

[admin]

They state that there are 3200000 samples possible, but there is no info on what happens when the track is shorter than 3200000 entries. I just need to format a .P00 disk and look at the image.

[jupp]

I am not sure why you need the magnetic signal strength as that is not available on any computer system ever made

the p64 format represents what is actually on the *disk*, not what whatever apparatus may read from it. so to represent a disk which has weak bits resulting from writing with lower write current, you have to save that info too. and since the emulation tries to emulate what does actually happen - you'll have to use an image that has that info. granted, such image can not ever be produced by reading a disk with a regular floppy drive - but it could be produced from preserved data using software that simulates the respective mastering process.

If it really supports flux correctly, then EVERYTHING would work and we can abandon g64 format completely for VICE.

thats the whole point of the p64 format - the g64 format isnt suited to represent every possible disk. (and also pretty much all g64 implementations are broken in one way or another - making it a hit and miss game for picky titles, which will work or not randomly on different emulators and devices)

They state that there are 3200000 samples possible, but there is no info on what happens when the track is shorter than 3200000 entries.

3200000 samples represent one revolution sampled at 16mhz and 300rpm, it can not be shorter or longer than that (even if the disk was written at whatever other rpm). think of it as an angle rather than a unit of time.

[admin]

3200000 samples per track would yield megs of data, just like flux images. The .P64 format is about 200K for an entire disk, so clearly it is missing a huge portion of detail. Even if the samples were 8 bits wide, there is no way to represent flux level data in such a small file size. An 8 bit cell @62.5ns would also give you a max of around 16us, which is nowhere near enough to represent weak bits.

Is there any actual documentation about this format other than what is listed on the VICE page?

[BeRo]

I'm the designer of the P64 file format, and one of the authors of the new 1541 drive emulation logic code in VICE (and Micro64).

And why P64 files are not big:

1. The P64 files contains the raw NRZI flux pulses, but only the actual existing NRZI flux pulses in a sparse array list (and as linked list while emulation run time, for fast insertions and deletions of NRZI flux pulses at emulated write accesses), and not in a dense array list.
   
2. And the P64 files are encoded with a range coder, so they are basically compressed. The range coder stuff is also descripted in the P64 file specification.
   

And the 1541 drive electronics has a lowpass-filter-like valid pulse detector, which only passes pulses that are at least 2.5 microseconds in duration. Any pulses than 2.5 microseconds are suppressed, so this effectively rejects any noise above 400 kHz. So 16 MHz sampling rate at circa 300 RPM +/- are really more than enough here.

[LordCrass]

Hi BeRo, nice to see you here.

I'm wondering why you chose a 32-bit value for the flux strength. I would think an 8-bit (or even lower) resolution would suffice, no? Or is the added resolution essentially a freebie when using range encoding, since nearly every disk image is going to use 0xffffffff for every defined flux strength?

[BeRo]

Or is the added resolution essentially a freebie when using range encoding, since nearly every disk image is going to use 0xffffffff for every defined flux strength?

Yep

And you can find the free-to-use BSD-licensed reference P64 library implementation in C at http://redmine.micro64.de/projects/micro...cification

[admin]

I'm the designer of the P64 file format, and one of the authors of the new 1541 drive emulation logic code in VICE (and Micro64).

And why P64 files are not big:

1. The P64 files contains the raw NRZI flux pulses, but only the actual existing NRZI flux pulses in a sparse array list (and as linked list while emulation run time, for fast insertions and deletions of NRZI flux pulses at emulated write accesses), and not in a dense array list.

What do you mean by "existing"? SCP generates a list of flux transitions, representing every transition that occurs. This is the only way to provide complete flux data support. Are you building data as it is used or something? Wouldn't formatting a disk fill in all of the data?

And the P64 files are encoded with a range coder, so they are basically compressed. The range coder stuff is also descripted in the P64 file specification.

And the 1541 drive electronics has a lowpass-filter-like valid pulse detector, which only passes pulses that are at least 2.5 microseconds in duration. Any pulses than 2.5 microseconds are suppressed, so this effectively rejects any noise above 400 kHz. So 16 MHz sampling rate at circa 300 RPM +/- are really more than enough here.

That is not quite correct. Pulse widths can be less than 1 microsecond and as long as tens of thousands of microseconds. The LPF circuitry ends up helping invalid flux times being caused with low flux durations, which is why there is some much of a drive to drive difference. This was corrected by the 2nd version of the ASIC w/preamp circuity used in the 1541-II and 1571 drives. There are some protections (weakbit related) that must have these widths available or you won't have weakbit support. SCP can duplicate all of the Mindscape weakbit programs (using a single revolution, not comparing multiple revolutions) because I do support the correct range that is available from the data separator. I spent a considerable amount of time reverse engineering the ASIC and comparing that with information I got from Commodore back in the 80's.