Reviving a dead Spectravideo SVI-328 MkII

April 2011

Occasionally I buy a vintage computer on eBay which is sold "as-is / for parts". Sometimes when I receive them and fire them up, they work, or have only very minor faults. I have repaired many a power supply just by replacing the regulator, which is a very simple and cheap repair. Recently I was fortunate enough to buy a Spectravideo SVI-328 MkII on eBay for only $34 (plus freight). These were new in 1984. It was sold as-is and sure enough, when I got it, it was dead.  I checked all the basic stuff, but still no-go. So then I jumped on the 'Net, as you do these days, to see what experience others had been having with repairing these and what some common faults are. After much searching over a few days, it seems there is very little to be found about these machines. This prompted me to fill the gap by documenting my own experience. So the following is my tech-tale about reviving this little gem.

Symptoms are: on power up both the POWER and CAPS LED's stay on and there is no "beep" as there would normally be. The monitor display is black.

Basics Checklist

Always check the fundamentals first.

• Power Supply. This model contains a number of regulators. These are basic linear regulators and are easy to work with and easy to obtain. I used a multimeter to check their outputs, all were good.

• System Clock. Oscilloscope shows a 3.57MHz signal on the Z80 clock pin, as there should be.

• Reset Circuit. Once again, the trusty 'scope comes in handy. This time it reveals that the RESET line on the CPU looks pretty bad during power up.

The blue trace is the CPU's RESET line shortly after power up - yuk! Yellow is the 5 volt power line, even that looks a bit noisy!

I had a poke around, re-soldered some power supply components and the chips in the reset circuit (7406 and 74LS04). Also replaced the 10uF reset capacitor and the associated 1N4148 diode.

This is how it should look. Yellow is the 5volt line. Blue is the RESET line shown going high ~17ms after power up.  Things are looking more civilised now.

OK got the RESET sorted, now the CAPS LED goes off most of the time during power up, but not always. Still no beep, still black display.

Gather Information

The next thing was to gather as much info as I could find - good old Internet. Found Roger Samdal's site and also Spectravideo.org. There's not much out there about these machines, but from these sites I was able to get circuit schematics, technical manuals and even a ROM listing (though the comments are in German! - Google Translate to the rescue). I've also downloaded the ROM files from one of the emulator sites and completely disassembled them. I did this because I noticed the German ROM listing is missing some pages.

Use Good Tools

OK time to get down to the details and bring in some heavy artillery.  I tried using the OpenBench Logic Analyzer. Starting at the beginning, the micro should be reading op-codes out of the ROMs and executing them, starting at address 0000H. I hooked up the analyser to the first ROM - data bus, chip select and output enable lines. This showed the ROM was being selected and the first few correct op-codes (according to the ROM listing), were appearing on the data bus in the correct order. OK so we now know that the Z80 CPU, ROMs and associated address decoding must be working. It also tells us that no faulty chips are "holding" any data or lower address bus lines in fixed states, so that other chips can't transmit correct values. So what next?

SV328 MkII with OpenBench Logic Analyser hooked up (click for full size)

Reading the ROM listing I find that the CPU doesn't hang around the lower addresses for long, it's first instruction is a JP INIT (Jump to 7B50H) - so let's look at what it does up there. When it gets there it executes what appears to be a small delay loop, then executes two OUT instructions to ports 88H then 8CH. The (German) ROM listing comment is "CAPS LED aus" (off). According to the memory map these ports are the sound chip! huh? So I download the data sheet for the AY-3-8910 PSG sound chip and find out that this chip has 2 general purpose 8-bit ports. I look at the schematic diagram and sure enough, in the SVI-328 they've used these spare ports; Port A is the two joysticks. Port B is bank select lines for expansion, the cartridge, and control of the CAPS LED. You'll recall from the start that the CAPS LED isn't turning off on this machine - AHA! But while that was the case when I started out, it's now only intermittent since I cleaned up the power and reset circuitry. In fact more often than not, it does turn off. But there's still no "beep". The plot thickens.

SVI ROM Listing broken up so it follows the boot sequence. (click for full size)

Further examination of the schematic shows us that the sound chip is selected and controlled via a scary-looking ULA chip!  Scary because it's a custom chip, meaning there's no data about it, and no chance of obtaining a replacement. A little re-jig of the logic analyser connections tells us that the ULA is in fact, putting out all the right signals to the sound chip when these OUT instructions are being executed - phew! This is occurring even on those odd times when the CAPS LED doesn't turn off. It also seems to be sending out the subsequent bytes to the PSG (0EH and FFH, then 07H and 80H). Further probing indicates that the 8255 PIO chip and the TMS9929 Video Processor are not being selected during initialisation, or anytime after for that matter. Looking at the code above, this would suggest that things are getting stuck somewhere around address 34E7. I suspected the sound chip could be faulty, but I'm thinking that shouldn't cause the micro to get stuck (?).  And what's all that other data appearing on the bus? Seen below before and between the 0F and DF going out to the PSG. It turns out these are just normal transitional bus states.

OpenBench Logic Analyser trace showing the PSG control lines BC1 and BDIR going high while 0FH is on the data bus. This is followed by only BDIR going high while DFH is on the bus.

The first action selects register 16 in the PSG (which is general IO port B), the second action writes DF to the chosen register (port B), to turn off the CAPS LED.

Just as an aside, the OpenBench Logic Sniffer/Analyser is an open hardware and open source project. You can buy the fully-built hardware from Seeed Studio for only about $50. You then download the SUMP Logic client software for free! It's probably the cheapest high-speed, 16/32 channel logic analyser around. I also own the Saleae "Logic" product which is also excellent, but it has only 8 channels which isn't enough for this work (they've since introduced a 16 channel model).

I've bought some spare PSG chips and a VDP off eBay, just in case. But I'm reluctant to start removing increasingly rare old chips when I'm still not sure if they're the problem.

Update: 6th May 2011

I just received a second SV-328 MkII bought off eBay. This one is already fully operational. Initially I've swapped the ULA's just to check. It's easy because they're socketed. This had no effect on the problem, and the newer SV-328 still works with the other ULA, which confirms for sure that both ULA's are working correctly.

Update: 29th May 2011

I've built a Z80 In-Circuit Emulator (ICE) see http://www.tauntek.com/Z80-In-Circuit-Emulator.htm This plugs in place of the CPU but allows you to control and monitor it's operation. To use the ICE in the SV328, I had to remove the CPU and install a 40pin DIP socket. I've been able to confirm that the PSG is able to be selected correctly. Same for the 8255 and VDP. The chip select lines (or equivalent) all activate when they're supposed to. My previous setup wasn't quite right and I was getting false information. The ICE is an excellent tool for debuggng because it lets you run your own code and tests independently of the system ROMs. You can also step through ROM code and watch what happens in registers and on the busses (with a logic analyser). When I run a "memory detection" or a "memory test" from the ICE, it detects the low 32kb ROMs (0000 - 7FFFH bank 0), but not the high 32kb RAM (8000H - FFFFH bank 0). If I write specific bytes to RAM addresses, then read them back, it appears as though bits 0, 2 and 3 are mostly (but not always) "locked" into high, low and high values respectively. This indicates 3 possibly flaky DRAM chips.  My thoughts are that if I can at least get the RAM working properly, then I can load some more comprehensive custom diagnostic routines and run them via the ICE. This would allow me to better diagnose the remainder of the system. 

SV328 MkII with the Z80 ICE connected in place of the CPU (click for full size)

Update 7th June 2011 - SUCCESS!

I received an order of replacement 4164 and 4116 DRAM chips from Jameco Electronics. These were cheap so I bought a bundle to stock up for future. I've re-run the above memory tests using the Z80 ICE and these confirm the low-order memory issues. I took the plunge and removed the lower-order four 4164 DRAMs and replaced them with IC sockets. After plugging in four new DRAM chips, the memory tests passed.  I thought, why not try running the ICE CPU at full speed, executing the ROM instructions? - Wow, the machine fully boots! After a bit more testing it seems that I now have another fully operational SV-328 MkII - woohoo!

SV328 Boot Screen - WooHoo!                                    The 4 new socketed DRAM chips (IC5-IC8)

Diagnostic Cartridge

I read in the technical/service manual that there once was a diagnostic cartridge available. This is a good idea and I'm considering making something like that. Maybe by re-programming an old game cartridge. The aim would be to make future diagnostic excercises a lot more straightforward, and even to some extent, more automated.

Update 4th September 2011

I just lost an eBay auction to acquire these cartridges. They went for almost $160 AUD! I consider these to be valuable and rare items from this era, and I intended to share the code from these with the community via this website. Spreading it around helps to perpetuate them. I hope the person who got them appreciates them, and has the wisdom and knowledge to extract and share the code from them, so the code can live on after the original chips die.

Contact Me

My real name is Greg Newton and I'm in Sydney, Australia. If you want to contact me, or you want more information, you can email me at: greg dot newton dot oz at gmail dot com (written like that to avoid spam bots).