MattInX's Miscellaneous Musings Say what now?


The JVC 26-pin Interface – Part 3

Ok - so I should probably have written this post in May last year when it was all still fresh in my memory, except I never seemed to have time, then I forgot all about it, so here we are. In the intervening time, I've had a couple of folk contact me - some asking about progress because they too have these drives and are looking at either reading the disk or replacing it, but I also had a note from Oleksandr Kapitanenko over at PortaOne recommending DREM, which is a device that I was aware of thanks to the TRS-80 Trash Talk podcast. Apparently in the time between me originally looking at the device and the time I started posting on the subject, they've added support for the 26-pin bus. So if you're one of those people who have a system with this interface and a dead disk - that might be a solution for replacing the drive and I highly recommend getting in touch with them. I'm still interested in digging into the V86P's specific setup, so there will be more posts on the subject coming up.

If you've not read the previous posts recently, here's a quick recap of where I'd got to (and partly for my own benefit to wake up the appropriate neurons): I'd reverse engineered the interface to the point where I could confirm the pinout and signalling; I'd identified /SERVO_GATE was a sector index pulse; I'd identified the configuration from the datasheet indicating the on-disk layout of a sector; I'd been able to dump a sector with its ECC data via DOS; I'd confirmed the controller is using 2,7RLL encoding; and I'd successfully identified the start of the sector pre-amble and sector marker. This post is going to try and get written down what I did in the month following that last post.


V86P Expansion

Retrochallenge RC2017/04 might be over, but I'm going to try and keep moving on this project. I'd already started on the pinout for the internal connectors used by the hard disk controller, and finishing that off seemed like a fairly straightforward task. Having done that, the Expansion Bus header on the back of the system was just a matter of following the same process.

I started off with the hard disk controller, a multimeter, and the datasheet for the OMTI 5090 IBM PC Bus Interface controller. The datasheet has the pinout for the IC, along with a table identifying which pins were for the system bus, and which were for the system interface. For each of the system interface pins, checked for continuity to each of the pins on the header connecting to the motherboard. This got most of the header identified, with just a few unlabelled pins. To get those, I basically did the same thing on the motherboard, except in this case identifying the signals was more difficult. On the motherboard, many of the signals need to be buffered (or in the case of address lines, latched). For that, Victor just used 74-series logic - 74HCT244 and 74HCT373 specifically, which is well documented. I traced the signals from the connector to the appropriate buffer output, looked up the input on the datasheet, then traced the input back to the main Chips & Tech 82C100. From there I could identify the signal.


Reverse Engineering the V86P PSU (Part 1)

My V86P did not come with a PSU - this makes things all sorts of interesting. Whilst 8.5V isn't hard to get from a bench supply, it's not a particularly common voltage for off the shelf PSUs, especially not at 4A (which is what the original unit is rated for). To top things off, I've suspected for a while that a good chunk of the NiCd charging circuitry is inside the PSU, rather than than the laptop itself, but precisely how much I didn't know. I started with a few simple tests with an ohmmeter between the various power input pins, and was able to confirm that two pins on the 6-pin PSU connector are connected to Gnd, two pins are connected together (I know from the site that these are the main 8.5V in), the pin immediately above these connects directly through to the positive pin of the NiCd battery pack, and the last pin is an unknown. The PSU connector is located on a separate PCB under the motherboard, inside a metal housing that makes up half of the battery compartment. A short cable protrudes from this housing which connects to a 6-pin header on the motherboard, and a pin just above the power switch. There's also a separate wire that goes to a ring loop which goes through one of the motherboard screws - presumably chassis ground.


The JVC 26-pin Hard Disk Interface (Part 1)

As I've mentioned in a previous post, my V86P is the higher-spec model containing a 20MB hard disk. Back in the mid to late 1980s, IDE was still relatively new and most systems were still using ST-506 interface drives, albeit using RLL rather than MFM to increase data rate and capacity. For example, I remember the Viglen Vig II 16MHz 286 we bought as our family PC back in '88(or so) had a 40MB RLL drive. Laptop form-factor systems were also relatively recent, with the floppy-based Toshiba T1100 being released in 1985 and the hard-disk enabled T1200 in 1987. Obiviously desktop drives of the era weren't ideally suited to laptop use, at that time 5.25" half-height was the dominant form-factor. The ST-506 interface also required two separate cables connecting the drive to the controller: a 34-pin control cable on which drives could be daisychained, and a 20-pin data cable from each drive directly back to the controller. These connectors alone take up almost 3.5" of space along the edge of the HDD logic board, and that still leaves power, which makes developing an alternate interface fairly logical.


Getting things running

As I mentioned in my previous post, my friend Chris over in the UK was able to aquire a Victor V86P laptop, and very generously sent it on to me. The V86P is an IBM PC XT compatible laptop, released in 1989 by Victor Technologies. Quite a neat little unit, they had the following specs:

  • 80C86 CPU running at 10MHz (with 4.77MHz available as a keyboard shortcut)
  • 512k or 1MB RAM
  • Either 1x 720k FDD and 1x 20MB HDD
    Or 2x 720k FDDs
  • CGA graphics, capable of driving either the LCD panel or an external display
  • Monochrome LCD display (no backlight)
  • 1800mAh 6V NiCd battery pack
  • CMOS BIOS configuration storage, backed by supercapacitor
  • Real Time Clock
  • 1x Parallel Port
  • 2x Serial Ports (16450 UART)
  • Expansion bus connector

What’s that? It’s Retrochallenge time again?

Victor V86P

I'm sure pretty much everyone in the retrocomputing world would agree when I say that nostalgia is a major driving force in the hobby. Everyone has their own stories about the systems in their collection: maybe it was their first computer, maybe it was the system they had at school, maybe it's something they drooled over at the time but weren't able to get. For Retrochallenge 2017/04, I thought it would be good to have a trip back to revisit one of the systems I regretted selling when I was a teenager and subsequent adventures with a replacement.


Sorry? I can’t hear you!

The original ZX Spectrum was typically connected to a portable audio cassette recorder to load and save programs. Later on, Sinclair released the Interface 1 with the Microdrive, a miniature tape interface that wasn't the most reliable (possibly a post on this at some point in the future). Several third party vendors released disk interfaces with varying degrees of popularity. For the most part though, tape was the the format software came on.

As time progressed, and every other system was already using disks (or so it seemed), Amstrad decided to try and breathe some new life into the Spectrum by releasing the +3, with its built in disk drive. Possibly too little too late, and probably not helped by their choice of format, the +3 was the last of the Spectrum line.


Adding composite video out to the +3

Now I have a working power supply for the Spectrum +3, I need some way to see what's being output. In its original configuration, video is output either a PAL RF signal on UHF channel 36 (UHF 36 was used a lot like VHF 3/4 in north america) or as RGB on the Peritel socket. The RGB signal doesn't help much here - whilst in the UK, TVs have a SCART socket with RGB inputs, in north america, TVs have YCbCr component inputs, so some circuitry to do conversion is required. That being said, the RF signal is generated from a composite signal - in earlier model Spectrums, it's just a matter of disconnecting the input to the modulator, disconnecting the output of the modulator from the socket, and connecting the input to the socket. Unfortunately, with the later model Spectrums, Amstrad mixed in the audio (as an FM signal), and that tends to upset TVs when you include it on the composite video input.


Replacing the ZX Spectrum +3 PSU

Seeing as the A1200 PSU replacement went so well, it was time to have a go at the ZX Spectrum +3. Much like the A1200, this also requires +5, +12, and -12V rails, with a similar sized casing (slightly wider and shorter). The original PSU was linear with a big, heavy, transformer - not ideal when you're trying to keep weight down for shipping. As a result, I'd already opened up the case and removed the existing supply before shipping the system. What I had in front of me was an empty shell.


A timely reminder

We all make regular backups, right? These days, it's easy to setup something largely fire and forget - things like crashplan, backuppc, timemachine, etc. What about our older systems? Making a working copy of your disks used to be standard practice; likewise saving your important files to more than one disk. How about backing up hard disk based systems? Sure, there was software out there to backup everything, but unless you had a tape drive you needed to use a lot of floppies. I remember backing up my Commodore A590 wasn't too bad - it was only a 20MB disk, and writing out to 880kb floppies meant you only needed 15-20 disks. When I got my A1200 with it's massive 60MB disk, I don't recall if I ever did a full backup - after all, I had all the programs on floppy, and I had my data backed up on floppy. Even if I had a backup from the last time it was in use, it wasn't in amongst all the disks I brought over with it. Nor, it seems, were any of my workbench disks. I'm sure you can see where this is leading.