Spectrum +2 128K Grey Repairs

Way back in 2017, The Future Was 8 bit was in the process of launching their divMMC future.

To make batch programming of those possible, I designed a rig which would allow 4 divMMC devices to be programmed at a time. This had an impressive looking control box with big buttons and lights and cables and everything.

http://blog.tynemouthsoftware.co.uk/2017/04/divmmc-programmer.html

It utilised four Spectrums, specifically four ZX Spectrum +2 grey boards. Assembled from various spare and broken boards.

Read about the repairs required to get those four boards up and running:

http://blog.tynemouthsoftware.co.uk/2017/06/spectrum-128k-2-grey-repairs.html

Six years on, and the rig is still in regular use programming divMMCs, but a few of the boards have failed and have been replaced with others or taken out of service.

Ahead of a impending large batch of divMMC boards to program, I have been sent the faulty boards to see if I can bring them back to life.

Four boards have arrived, and have numbered them 1-4 on the serial connector on the back of the board.

Board 1

This shows off some of the modifications that have happened to all the boards in service.

I designed a small extender board which is soldered to the edge connector, providing a better connection. If / when it wears out, it can be desoldered and a replaced with a new one.

One of the benefits of using the Grey 128K +2 boards is they have RGB and composite output on the DIN connector. The RF modulators are no longer used, and have been fitted with power LEDs instead.

The LEDs were installed as there had been some problems with bad connections on the power connectors. These had been desoldered and fitted on the back of the board for better wire routing.

The 3 pin connector was originally where the regulator was connected, but since the pinout was 9V in, ground, 5V out, it was repurposed for these boards as 12V in, 0V in, 5V in from the external power supply.

I will look at replacing those connectors as part of these overhauls.

The original Molex KK connectors are 2.54mm (0.1") pitch, so there are a few options, and I have gone for JST XH. These are the same pitch, but I like that they gave multiple points of contact between the crimp and the pin, rather than the single point with the old Molex types.

To simplify things during testing, I went back to the original idea of using that for a regulator, rather than as power input, but I went for a DC-DC converter rather that the original 7805 on a big heatsink.

This board has all the original RAM chips. Well, there's ya problem. At least, I expect it will be.

Power it on gives a black screen. So yes, most likely a RAM fault.

There is a RAM tester ROM in one of the other boards, so I will borrow that and give that a go.

Yes, bad D0, which could mean one or both chips on D0. And also any of the others, since it only shows the first one.

Lets leave that one for a moment, and move onto board 2.

Board 2

This one has was one of the first four, as seen by the 2 sticker on the joystick port.

Like many of the boards in the rack, it is running a replacement ULA, a vLA128 (https://vdrivezx.com/vla128/), trying to save wear on the original ULAs where possible. I was going to give these a full run through, but didn't have time. From what I can see, they did everything the original did without a problem, so an ideal drop in replacement.

In the last repair, quite a few RAM chips were identified as bad and replaced.

I normally try to match brands of RAM, but I didn't have any of the Samsumg KM4164 chips spare when I did that (still don't, for reasons which will become clear as we progress.....).

Another black screen, another RAM fault. D0 again, one or both of those, or more. And neither of those are socketed (yet).

This is a diagram I made for the previous post, so you can see where the D0 chips are and the sockets are not.

OK. I am starting to see a pattern here. Let's try board 3.

Board 3

Well, OK, maybe not. This board has already been harvested for parts. It must have been taken out of service a while ago as it does not have the power LED or rear mounted connections or edge connector extension.

Looks like it has already had the RAM repaired a few times before, originally with the dual wipe sockets, and later by me with the turned pin ones. And has since had several chips stolen.

But at least it had the RAM test ROM chips, which I had already been using on the other boards.

I populated the missing RAM chips and gave it a test.

D7. Bad. Two chances, one of which was socketed.

It wasn't that one.

OK, Maybe board 4 then?

Board 4

Another of the original repairs. This one was missing a ULA, and also it seems I had taken the "nuclear" approach and socketed all the RAM on this one.

I borrowed a ULA and was about to power it on before I had a further look at the RAM chips and realised they were all upside down. Not sure how that happened? (I think TFW8b might have had a late night go at fixing this one.)

And worse than that, three of the chips bore the MT logo of a Micron Technology RAM chip. These are often found in Commodore 64s. Broken Commodore 64s. Rarely found in working Commodore 64s.

I turned them all around and ran the test.

And of course, they failed. Sorry, I had already given up taken pictures of the screen at this point, but you can guess what it looked like.

Lots of bad RAM

It seems all the boards have the same problem, bad RAM, probably quite a lot of it.

I used a ZIF socket for D0 and tried out chips in there one by one to see if it showed D0 bad or not. From that, I managed to find 8 working chips

Only the bottom row is required to boot, this contains the lower 16K of RAM plus the odd numbered banks of RAM.

I kept going until I had a complete working set.

Finally, the RAM test passed.

I will skip over quite a lot of time here,  I went though this cycle quite a few times.

while (faults > 0)

{

IdentifyBadChip();

DesolderBadChip();

SocketBadChip();

InsertGoodChip();

Retest();

}

I got to the stage where I concluded that the best option going forward was to remove ALL the RAM and fit sockets. I wouldn't normally do this, but since these get a lot of use, it will be easier in future to swap out faulty chips.

These are nice boards to work on, the PCBs are good quality, so desoldering chips is fairly easy, other than a few bend over legs on each chip. Most chips fell out as the last leg was desoldered.

I did at one point consider I might be able to get away with just 8 chips, which would only give a 16K machine, but I don't think that would be enough to run the flashing program, the 8K divMMC ROM image and the screen RAM.

I ended up fitting the full compliment of sockets to boards 1, 2 and 4. 

Board 3 was missing various parts already, and also did not have the upgrades of the others, so that one gave up it's remaining RAM chips to help the others.

Between the four boards I had quite an assortment of RAM chips. Various makes and speed grades.

These are all the remaining Samsung KM4164B-15 chips, sorted by date code.

I had already discounted some Samsung chips with a different speed grade (-12 instead of -15), the MT parts and Toshiba parts which didn't match.

After all the tested, I ended up with 10 bad chips (although a further few failed in soak testing).

I had enough chips to populate two of the boards, and do some more testing.

It's a hard job, but someone has to do it.

That's board 2 sorted.

Board 1 also got a full set of chips, but started behaving strangely in soak testing.

It would run the test, pass then the screen would flash blue and then reset.

I wasn't sure what was going on, so I tried swapping out all the RAM with a known good working set (Toshiba chips, not Samsung).

That did the same, so the RAM was probably OK.

I tried swapping the RAM mux chip (Amstrad 40058, next to the Z80), but that made no difference, same with the ULA.

It was only when I swapped the Z80 that the problem went away.

I was also able to create the same problem on another board by installing the bad Z80.

Fitting a new Z80 solved the problem.

I don't know the origins of the part that was fitted, but were NEC really making D780C (Z80 clones) in 2006? or is this a remarked 1980s part?

With a new Z80 (OK, with the old Z80 stolen from board 4), board 1 was now also working.

Board 4 has also been tested, but has been sent back with the last 5 working Samsung DRAM chips, no Z80, ROM or ULA, but can be used as a replacement for any of the other boards, should they fail. And also the two test ROMs that TFW8b sent.

Board 3 is staying with me as a parts board for the moment. And oh look, someone has already stolen the AY-3-8912 for a previous blog post they were writing on AY-3-8912 sound cards for the Minstrel 4D. I wonder who that was?

I think it would helpful to buy or make some replacement plug in RAM modules, as those chips seem to be getting on a bit, and failing in their old age.

---

Advertisements

DivMMC Future

The DivMMC Future is avaiable from The Future Was 8 bit

https://www.thefuturewas8bit.com/shop/sinclair/divmmcfuture.html

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Minstrel 4D Development Part 6 - CRTC Updates

I knew I said I was going to start on the Mini VIC development logs, but I found one more from the Minstrel 4D development, this from September 2022.

Throughout most of the Minstrel 4D development, the video circuitry has been pretty much lifted from the Minstrel 4th.

The same chips in the same configuration, the main difference is the Minstrel 4th had jumpers for PAL/NTSC and normal/inverse, and the Minstrel 4D uses DIP switches for these.

On the original (green) prototype, the DIP switches were up next to the video section, but were later moved to the middle of the board.

I knew that this worked, so could be left alone. However, I set myself a "stretch goal" that if I had time, I would revisit it. I'm still recovering from some health issues, so as a gentle ease back into doing work that required concentration I decided to completely rewrite the code from scratch.

The Minstrel 4th video chip was ...

Hang on, let me just stop for a minute and fix something. I don't like calling it the video chip, it does not actually generate the video signal. That comes from video RAM, feeding font RAM, feeding a shift register, just like in the original Jupiter Ace. Just with a few additions such as optional inversion and a pixel synchronisation flip flop.

The microcontroller generates the video sync and controls the timing of the other bits, the latches, flip flop and shift register. It also counts generates the addresses for the video and character RAM, and just replaces few dozen or so logic chips that originally did the clock, counting and decoding.

I prefer to refer to it as a CRT Controller, a bit like a modern version of the 6545 CRTC used in the Commodore PET etc. I refereed to it in the Mini PET schematics as a "I can't believe it's not a 6545".

The original Minstrel 4th CRTC was developed around the same time as the Mini PET version (I can't actually remember now which one came first), and they share a lot in common.

When I designed the Mini PET 40/80, I revisited the PET code and ended up rewriting it completely. The extra steps required to support 80 column video output would have required a lot of changes anyway, but I wanted to make two main changes to the original code.

1. I wanted to switch to using a timer interrupt to set the horizontal sync pulse at the start of each line. That would keep the timing a lot more consistent, and required less counting of cycles to make sure each code path took the same number of cycles, as I had previously done.
2. The original version had tried to copy the video output generated by the Commodore PET, and other machines of that era. I wanted to improve on that and generate a more correct composite video signal.

I don't really want to get into how the whole things works at this point. I will have to do that again at some point. I say again, as I wrote a huge long scrolling blog post covering all the ins and out of how the Minstrel 4th and Mini PET video worked. That was about 90% complete when it all got wiped due to a bug in blogger. Still bitter about that. Still haven't summoned the energy to do it all over again.

(I did write quite a lot about in for the Minstrel 4th manual, I may adapt and extend that into a blog post at some point)

The reason for point 2 above is that some monitors (it seems mostly ones made by Dell), do not like the simplified style of composite video generated by machines of this era. Everything else seems fine, old CRTs, and most modern LCDs, it is only the Dell ones that dosn't like it. Is that the signal's fault or the monitor?

This photo from George Beckett shows this issue (George is currently doing sterling work putting the Minstrel 4D through it's paces).

All the monitors ancient and modern that I tried it on here did not show this problem.

One line of an 8x8 character on the screen takes 8 clock cycles to draw. Get the timing out by just one clock cycle, and the character appears 1 pixel to the left of where it should be. I can make that happen by removing a critical NOP instruction.

That's just one pixel, it then takes at least 8 lines to get back, hence the slight bend rather than a step.

I have been through the timing of the original code and I cannot see anything out of place like that,(although if there had been, it would have affected all monitors anyway).

I think the issue is due to the vertical sync section of the video signal. The simplified version used on the Mini PET and Minstrel 4th (and most 8 bit machines in the 1980s) has the composite video signal go low for the entirety of the vertical sync segment.

For a period of 8 lines (8 x 64μs = 512μs) the signal simply goes low, as it does for 4.7μs at the start of each line for the horizontal sync pulse.

My intention at the time was to create a video signal the same as the PET or the Jupiter Ace, so I went with that form of signal. More correctly, it should maintain horizontal sync pulses in a specific pattern of pulse lengths during this gap, although none of these machines did that back in the day.

That means there is always a sync pulse to lock onto every 64μs - could the lack of those be what is confusing the Dell monitor?

I had added a programming port on the prototype PCBs, so with the scope hooked up for composite video shots, a logic analyser for timings and a USB TinyISP to program the chip, I was all set to update the code.

I was hoping it would be a fairly simple process of taking the Mini PET 40/80 code, removing the RGBi, PET monitor options and just leaving the interrupt based composite video with the correct vertical sync pulses.

It wasn't.

The Mini PET 40/80 CRTC runs at 16MHz, whereas the Minstrel 4th CRTC runs at only 6.5MHz, so there are only 40% of the available cycles to do things between the various sync and timing signals that need to be generated.

That is quite important when it comes down to such critical timing as this. I did consider moving to a 13MHz crystal to make this twice as fast, but I couldn't get hold of any at the time, and would have needed to add an extra flip flop to divide it down for the 6.5MHz / 3.25MHz used on the board.

There was also an added complication that I hadn't thought about. The PET uses white characters on a black background, so the edges of the screen are all at the black level, you only get peaks where the characters are. This means there is always black around the borders, which acts as a back porch for the video signal. (these are sections between the sync pulses and the actual video data that set the black level. White is the highest part of the signal and these set where black is, about 20% of the signal height - see a previous blog post about adding a back porch to the Minstrel 2 for more information - http://blog.tynemouthsoftware.co.uk/2017/01/minstrel-zx80-clone-video-output.html)

The default option on the Minstrel 4th is black characters on a white background, so the signal needs a back porch and a front porch to set the black level, then the rest is at the white level.

At the end of the visible lines, there is the front porch (don't blame me, I didn't come up with the names). This is 1.65μs of black level just before the horizontal sync pulse takes the signal low.

On the Mini PET 40/80, I used this to set an interrupt that would fire when the horizontal sync pulse was due, so that was always at a precise time.

With the slower clock, 1.65μs is only 10 instruction cycles (one cycle at 6.5MHz is 153ns). That doesn't give enough time to set and wait for the interrupt.

This shot was taken during development, and you can see the top border where I have started the front porch too early, and the rest of the lines where only the character sections are at white level.

In the end, I changed the code so the interrupt occurred at the end of the visible line, the start of the front porch. (ah, see, the name makes more sense that way as well). That was always a fixed length, so the sync pulse was still starting at a consistent point.

There is an awful lot of staring at traces like these checking that each of the lines add up to 64μs, and all the syncs line up.

But it is coming together now, all correctly lines up and working fine on my monitor.

These pictures are a bit grey as I have the brightness turned right up so I can see if there is anything visible around the sides of the picture.

The new more compliant video seems to have met with the approval of the problematic monitors, and everything is looking good now.

---

Advertisements

Minstrel 4D

The Minstrel 4D kits are shipping now, you can order one from The Future Was 8 bit - SPECIAL OFFER - £15 off the Minstrel 4D and free shipping to the USA

https://www.thefuturewas8bit.com/minstrel4d.html

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2022/08/minstrel-4d-overview.html

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, this post contains bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware