P64

[admin]

Ok, I looked at the link. I will experiment with the .P64 format using my GCR editor and some protection generation routines I did for TurboLok, and a few others.

[LordCrass]

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?

As an extreme example, if there are only 8 flux transitions on a track, you'd only have 8 entries in the chunk, but each entry would include the exact position of that pulse on the track, the strength, and the two associated flags. It's not like there's 3199992 entries of "no pulse here" to go along with it.

Where SCP format has an entry for each time delta (time since last flux transition), in P64 the time delta between 2 pulses is the difference in their absolute positions multiplied by the sampling interval (62.5ns).

[BeRo]

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?

"existing" = every occured transition.

That is not correct. Pulse widths can be less than 1 microsecond and as long as tens of thousands of microseconds. 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.

Nope, what I said, is correct. It is also good documented in commodore documents, and also confirmed by commodore hardware hackers with help of logic analyzers and experiments, who I know and I have also good contact to those.

But of course, pulse widths on a diskette can also be shorter than 2.5 microseconds, but the 1541 drive electronics (the parts after the valid pulse detector) can detect only stuff with at least 2.5 microseconds duration. Just think a step further how can this be also related to the weakbit behaviour which you mean, then you will understand how it works as a whole.

---

As an extreme example, if there are only 8 flux transitions on a track, you'd only have 8 entries in the chunk, but each entry would include the exact position of that pulse on the track, the strength, and the two associated flags. It's not like there's 3199992 entries of "no pulse here" to go along with it.

Exactly

[admin]

I certainly disagree, and I HAVE used logic analyzers on the data (this year) to record the analog transitions - not just the digital transitions, to determine exactly what is happening with the op-amps and the final stage. The LPF does not filter at 2.5us. Look at the component values used in the circuitry for each stage. It's pretty easy to calculate the pass frequency just from that alone, but there is absolutely no denying what an analog capture gives you. I wanted to know the correlation between the actual magnetic reversals and how the ASIC decoded the data. This was the only way to know for sure. I also learned that three 0 bits in a row is allowed with the data separator, which is something that I had always thought was illegal in GCR (and is with Apple's GCR).

You get a flux transition for every single bit cell. GCR data is decoded from flux transitions. Every transition (depending on the length) decodes as a 1,01,001, or 0001 in a packed bit stream. I am curious how not changing the data is going to generate the correct data. This sounds almost like a RLE compression or something.

[BeRo]

It's not a LPF, it reacts only just LPF-like in endeffect from the other side of the view. And read this here from the Commodore 1541 Troubleshooting & Repair Guide:

[admin]

That information is wrong. It certainly passes pulses that are less than 2.5us. My log file shows pulses as low as just under 1us when no disk is in the drive (weakbits). You can see it youself with a scope. Just set the trigger to anything under 2.5us, and do a read with no disk in the drive.

What is also wrong in that information is "not more than two zeros can appear in succession". Even I used to think that 3 or more zeros in a row was invalid. It's not. In fact, there are several V-Max titles (like Sinbad) that take advantage of this fact. 3 zero bits in a row *IS* legal. 4 or more is not. I didn't know this until I looked at the log data with Sinbad, and then started decoding the captured data by hand - then I checked it out with my GCR editor for Supercard+. I had to re-write my GCR decoder to take the new info into account, and when I did the .g64 conversion of Sinbad worked perfectly.

So, someone should throw the above information away - whoever wrote it was guessing.

[BeRo]

Hm, who by us has implemented a working P64&FDI NRZI-flux-pulse-level-based 1541 diskette logic emulation in VICE (P64 only) and Micro64 (P64 and FDI), where V-Max&Rapidlok&FatTracks&RainbowArts&extra-additional-MFM-like-encoded&etc. protected raw-dumped and to P64/FDI image converted games are working without any cracks? Right, me. And I've numerous witnesses.

Only the just remain big issue in my emulation (mainly for example for the copy protection of Galaxian, which are misusing the VIA shift register + VIA timer for checksum-like tests) is the yet buggy emulation of the VIA shift register in connection with a VIA timer, where I'm still searching for good test programs for it, and for people who can write so such test programs for this issue.

[admin]

I have never seen a single P64 disk image of anything protected. Copying a G64 to P64 disk apparently does not work under VICE, at least not with any of my copiers. Also, there are issues with weakbits and byte level density changes with P64 formatted disks.

The information I stated is 100% correct, and the information you posted above is wrong. You would have to know that 3 zero bits in a row are in fact valid. You may not know that flux transitions less than 2.5us do occur, which would explain the weakbit issues I have seen with testing P64 disks.

I know the 1541 pretty well myself. I have a cycle exact emulation that will be released for the SCP, and includes the ASIC emulation along with the 6522's including the timers and buggy shift registers.

[BeRo]

I've many P64 images here, converted from kyroflux raw dump images from a guy and some FDI images from a another guy, and most all of them are working without any cracks.

And converting G64 or NIB to P64 or FDI is a really very bad idea and pointless in the most all cases. G64 and NIB are not NRZI-flux-pulse-level-based diskette image file formats like P64 or FDI.

And I will quote here a guy from the IRC now:

Look at http://www.ti.com.cn/cn/lit/ds/symlink/9602.pdf and http://rootserver.rosseaux.net/stuff/154...ematic.png

The UE4 instrumentation amplifer has a low pass filter, 1.02 MHz is the cutoff at the input. The output of UE4 has another filter, which is 650 kHz, and UD4 is the next stage. The 650khz filter is present again at the output of Q-Out.

Page 3 of that PDF shows the formula t=k*r*c*(1+(1/r)) where t=shortest pulse it will output and 330pf is in the low 10^3pf range. Fig6 on page 5 show the coefficient to be around .4 for low 100s of pf.

The shaping circuitry has pretty sharp 650 kHz lowpass and an additional 1.02 MHz reject.

So it's 344 kHz / 2.468us at the end, also it's a bit higher than the 300 kHz bitrate to compensate for rotational speed misadjustments. That is also what allows the faster bitrates of say... V-Max to work.

[admin]

Like I said, in the real world the LPF cutoff is lower than that, and you do in fact get pulses as low as just under 1us. It's easy enough to see using even a generic scope. Read a disk with the drive door open so invalid flux is generated. On disks themselves, flux transitions are as low as a few hundred nanoseconds, typically during the write splice. So, if you want to "preserve" and emulate the disk exactly, you would need to allow for the complete data. I doubt it matters much for C64 disks, but I want to be as exact as possible.

I am more than familiar with the 1541 schematic. Besides developing RAM boards, digital track displays, and parallel cable add ons, I first developed flux level copying in December of 1984 by replacing the write circuitry in a target drive and using the UE4's output for the source drive. So, 29 years later nothing has changed.