MattInX's Miscellaneous Musings Say what now?

Retrochallenge Roundup (and a quick JVC update)

Well, it's the final night of RetroChallenge, so it's time for a closing post. As I'd expected, I didn't get anywhere close completing my goals, with lack of time being the age-old excuse. However, it was still a very productive project and I plan to keep pressing on and making semi-regular posts. Hopefully I can keep the momentum going even through RC is over for another 6 months. Although I didn't get a wiki up and running to store the information I was gathering, it's all up on this blog - so that's a start as far as making it available is concerned.

Other key milestones:

• I hacked together a working PSU for the V86P - learning a lot about switch-mode PSUs in the process
• I reverse engineered the output stage of the original PSU, using photos and some measurements being taken remotely, and captured the result as a kicad schematic
• I'm most of the way through a PCB layout for the charging section of the PSU, which will provide all the necessary voltages to the V86P to run and charge the NiCd pack given only a sufficiently beefy 8.5V PSU. The missing piece is finding a case I like, then I need to tweak the board dimensions to fit
• II got the V86P running with both its internal HDD and FDD
• I found datasheets for most of the key ICs in the system
• I'm about half-way through mapping out the pinout of the hard disk controller to motherboard interface pinout
• I confirmed the pinout of the 26-pin JVC interface
• I identified the SHIP_READY and SERVO_GATE lines as signal that the heads were parked and a sector index respectively
• I identified that DOS sees a 4 head disk with 512 byte sectors, but the disk itself only has one head select line - possibly there's some logic for splitting 1k sectors into two logical heads - developing some basic C routines to call BIOS int13h
• I've confirmed I can read the ECC blocks from the data block via DOS int 13h calls, which should make reverse engineering the polynomial used by the controller relatively straightforward
• And lastly, which I'm going to cover below - I think I've finally confirmed the disk is storing 2,7 RLL encoded data

I was able to borrow a DSO from a friend (thanks Daniel!) This allowed me to take a look at the signal on the /READ and /WRITE lines of the controller, with the hope of confirming what my little USB analyzer was showing. The result is as follows:

Read

Write

Looking at the traces, this looks like the read and write pulses are about the same width, with read being slightly shorter, and on closer examination, not quite so square. I suspected the issue might be the cable length between the logic analyzer and the break-out board. I shortened the cable as much as possible and ran another read test. This yielded the following result:

This looks a lot better, and has the regular pulse chain I was originally expecting to see.

The datasheets for the OMTI 5055 and 5027 recommend using a value 0x33 for the inter-sector gap (and pre-index and post-index gaps) on RLL encoded drives. When you encode 0x33 using the 2,7 RLL code OMTI (and most other disk vendors of the time) used, you get 00010000 - which gives a repeating pattern of one pulse, then seven periods of nothing, then another pulse. That's exactly what that trace appears to be.

Following the inter-sector gap, we get an ID pre-amble of 0xFF, repeated several times (the exact count is up to the controller programming). 0xFF encodes as 10001000, so you get a pulse then three periods of nothing, followed by another pulse. Following that is an ID sync byte of 0x62 (which is 0010000001000100), then a marker byte of 0xfe (1000100010000100), then finally the sector data.

So as my parting image, here's what I saw when I looked at a trace, starting at the beginning of a sector - just compare it to what I described above: