Tynemouth Software: Toshiba HX-10 MSX Repair

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here we have a Toshiba HX-10 MSX computer. I got this quite a while ago, because I didn't have one, and also because I was considering doing an MSX multicart or SD interface or something like that.

This conforms to Microsoft's MSX standard, with a Z80, 64K of RAM, TMS99xx video chip. These MSX machines were made by companies like Sony or Toshiba, without a legacy of computer hardware, so they signed up to follow a standard. Shame it didn't catch on.

Being more familiar with the HiFi and video world, they were more consumer friendly, often with built in power supplies rather than lots of extra wires and boxes. They would usually have great picture quality, with things like SCART connectors and AV jacks to make connecting to a TV much easier than on some other machines.

As far as I remember, this one was working, but now it's just giving a blank screen. Sync is being generated, so the power side is probably OK, and it is making a regular clicking noise (on the audio, not the cassette relay).

One of the standard tests on these is to try the caps lock key. If it is partly running, pressing the caps lock key will toggle the caps LED. Nothing was happening. Another thing to test is pressing keys should give a click sound, and pressing ctrl+G, which should make a beep. No response to any of those. (spoiler warning: the above photo with the caps lock LED on was taken after I fixed it.)

Inside is a very neatly laid out board. There is also an add on board at the side which appears to be an adaptation to generate the PAL video standard.

The boards are clearly marked with lots of well spaced parts, although there a quite a lot of parts not fitted. Looks like there has been a bit of Muntzing going on. We (snip) don't (snip) need (snip) all (snip) these (snip) decoupling (snip) capacitors.

Nothing looks obviously bad in here. Voltages were fine, clock and reset pulses OK, data lines wiggling suitably. Everything was apparently fine.

Some of the chips are socketed, so I'll check those first.

Swapping the Z80 made no difference,

Nor did the TMS9929 video chip, although I noticed the legs were quite tarnished, so I gave those a quick clean.

The next socketed chip is the ROM, I took that out and read it in an EPROM programmer as a 27C256 (always remember to switch of ID check when doing this).

I dumped the ROM, and a quick scroll through and all looks OK, at the end there was the copyright message.

I tried running without the Yamaha sound chip, again no change. So, running out of things and trying to skirt around the massive tiny pinned TCX-1007 ULA chip - if that's gone, I'm in trouble.

I suppose the next step would be to check out the sixteen RAM chips. 8x 4164 chips making the main 64K of RAM, and 8x 4116 chips making the 16K video RAM.

Faced with that, I decided to leave it for the moment. I'd dug the machine out to try out Misfit's new game Rodman on the MSX, so I resigned myself to playing Rodman in an emulator. I downloaded openMSX, and fired it up. It started in MSX2 mode, but I wanted to go plain MSX. To change that, I needed to select a machine to emulate and thought I may as well select the Toshiba HX-10 since there was one sitting on the bench right next to me.

It failed to start, saying it needed a ROM image. Aha, I've got one of those, I just read it in to check it. So I copied the ROM into the emulator and reselected Toshiba HX-10.

It flagged up the SHA1 checksum didn't match what it expected, and then proceeded to show a blank screen, with a ticking sound. Yes, exactly the same as the real hardware was behaving. Hmm, so is the ROM bad?

I googled up a archive copy the the ROM and compared them, and there were some differences. I tried that ROM image with the emulator and it ran fine. It is looking like the ROM is bad. I burned an EPROM replacement and tried to boot the real hardware and up came the boot screen.

There were quite a few differences between the ROM images, so I thought it might have been a different revision, but I noticed a bit of a pattern to the bad bytes. Scrolling down, there were similar but different patterns in clear blocks. (a shout out here to HxD, a great hex editor I use all the time)

Intrigued, I wrote a little program to take the two ROM images and XOR them. This gave a file which only shows the bits that were different. If the files were identical, the output file would be full of zeroes, but this has sections with lots of 4s, and one with lots of 10s and so on.

Any byte in that 256 byte block in the ROM image that already has bit 2 set reads fine, anything that doesn't have bit 2 set appears to be 4 higher than it should be, 32 reads as 36. 08 reads as 0C etc.

It appears that throughout the ROM certain 256 byte blocks have one or more bits stuck on. Not a failure mode I have seen before.

If this were an EPROM, I would try reprogramming it, since the bad bits were high, the default state, but the MB83256 is a mask ROM, which is programmed in the factory, so I'll leave the EPROM in place.

All back together, ready to try it out.

That's booting up fine, with no other apparent problems. (It seems it is meant to show less than 32K available to BASIC on a 64K machine?)

OK, that's about the limit of the programs I feel like typing in today. Over to the tapes.

I had initially expected it would use the same cassette lead as the BBC Micro and Oric, but it appears not, so I'm using a little ad hoc cable with my good old Sony TCM-818 tape deck.