Amstrad CPC 6128 Repair

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Quite often, when I get machines in for repair, they come with the statement along the lines that 'it was working fine, then one day it just stopped working'. Usually with no explanation (see an old blog post for some suggestions). However this time, the explanation was given.

The owner had been using this with the original monitor, but had wanted to move over to a less bulky LCD screen. The Amstrad CPC machines are powered by the monitor, so to do that, you need a separate power supply. He had bought a kit that came with all the bits. As you can see, there is a lot going on here. If you know about the way these work, you may have already worked out what happened.

The CPC 6128's longer, more colourful, little brother, the CPC 464 has two sockets on the back, both connected to cables coming from the Amstrad monitor. 5V DC in and RGB out.

The CPC 6128 in addition needs 12V DC in for the floppy drive, so they rightly decided not to fit an additional socket, and instead added a cable coming out of the CPC 6128 that would plug into the monitor for the 12V.

The kit the owner bought came with two power supplies, one 5V and one 12V. An RGB SCART lead is provided, which taps the 5V power to provide the switching signal to the TV, and a cable which wraps around to the side to pick up the audio out.

As if that is not complicated enough, there are two powers supplies, both with 2.1mm DC jacks. The 5V one plugs into the SCART lead pass through, and then into the CPC 6128. The 12V side is dealt with using a short socket to socket cable which reverses the polarity and the gender, and allows the 12V PSU to be plugged into the lead from the CPC 6128. Can you guess what happened?

Yes, he accidentally mixed them up and sent 12V into the 5V rail. Ooops. When this happens, it can cause all sort of problems. Any of the chips on the 5V rail could have fried. This could be tricky, as in this generation of CPC 6128, almost all of them are soldered directly to the board.

I started with the easy ones. The Z80 and the gate array were socketed, so I swapped those out for known working ones, no change. I did test those two chips out in another 6128, and they were working, so that's a good start,  not everything has been fried.

The screen is there, with a random pattern. This could point to a RAM failure. There are sixteen 4164 RAM chips on the board, all soldered in of course. One or more of those has failed. But which ones?
The Z80 in the 6128 has a 64K address range, so cannot directly address the 128K of RAM. The right hand 8 chips form the lower 64K, and these work in the same way as the CPC 464 (which only has 8 chips and 64K of RAM). These are split into four banks of 16K (banks 0-3). The screen uses bank 3, and the stack etc. is built downwards from the top of the bank 2. Since it is not booting, there is at least one fault in the lower 64K of RAM, meaning it is likely that at least of one those eight chips has failed.

The CPC 6128 has an extra 8 chips, another 64K of RAM, forming banks 4-7. There are various modes that are used to access this RAM, controlled by a paging register. The easiest way to use these allows you to access any of banks 4-7 in place of bank 1. To do this, there is a small logic array, a 16L8 PAL. This controls the two highest address lines (which select the bank) and CAS (chip select) lines that go to the RAM chips, so it will enable the appropriate bank of RAM by switching the CAS signal, and if necessary, adjusting the upper two address bits (i.e if you have bank 7 in place of bank 1 the RAM chips need to see a different address to the one that was requested to be read).

Rather handily, the logic array is socketed, so a quick test you can do is bypass all that and setup the upper 64K as the main RAM, so the system is using banks 4-7 in place of banks 0-3. This is only for testing, as it disables the original lower 64K. But this will show if the upper 64K of RAM is OK. The connections are A14 in to A14 out, A15 in to A15 out, CAS to CAS1 and 5V to CAS0 (to disable it). So the address lines are unmodified, and chip select always selects the upper 8 chips, with the lower 8 always disabled.

Success, we have a boot screen, and what is now effectively an Amstrad CPC 664. This board is actually designed so it can be 64K only. This would be done by not fitting the upper 8 chips and the PAL chip.

There are two jumpers above the PAL (LK5 and LK6) that can be fitted to link A14 and A15 ins to outs, and another (LK8) which links CAS to CAS0.

So it looks like the upper set of 8 RAM chips (the ones on the left) is OK, so that has narrowed the fault down to the eight chips in the lower half (the ones on the right). But which ones?

It would be possible to do some simple tests from BASIC, if that RAM could be accessed, but it is currently hard wired disabled. However, the PAL chip is compatible with a modern 16V8 GAL, so if I program a new GAL chip, I could control the bank switching. To test this, I wrote a simple set of equations which mirrored with wiring above:

A14OUT = A14;
A15OUT = A15;
CAS0 = 'b'1;
CAS1 = CAS;

With that burned to a GAL, it again booted. That's handy, that'll save me wiring that up with jumper wires again. Now that I can control bank switching, I think the best option is to set it up with banks 4,1,6,7. That uses the upper 64K for the areas required to boot, but opens a window of 16K in the middle up to the lower 64K (which we know is faulty). With BASIC booted, I would be able to peek and poke at the faulty RAM from BASIC.

A14OUT = A14;
A15OUT = A15;
CAS0 = CAS & !A15 & A14;
CAS1 = CAS & (A15 # !A14);

Maybe not the best way to do it, but CAS0 (the lower 8 chips) is enabled when A15 is low and A14 is high (bank 1). When A15 is high or A14 is low (the other three banks), the upper 8 chips are enabled.

That booted, and I was able to try poking addresses in that range and peeking back at the values. The idea being, if there is a RAM fault, with values will be wrong. I chose the range of 20000 to 30000 arbitrarily as it is comfortably within bank 1 (16384-32767).

The first test program went through poking 0 and checking if the value read back was 0. That would show up any bits that were stuck high. It was clear the numbers were all out by either 16 or 64. (80 is both 16 and 64). Excellent, that is exactly what I wanted to see.

I repeated the test, this time poking 255 to show up any bits that were stuck low, and again it was 16 (255 - 239 =  16). So there are (at least) two failed chips. I removed and replaced the chips which were D4 and D6 in the lower bank and retested.

Excellent, no faults found by my simple test program. Here I added 0x55 and 0xAA to the test patterns to test alternating 1s and 0s. This is a far from complete RAM test, notably there are no test for any addressing problems, but the simple data bus tests all passed.

Next I removed my test GAL and went back to the original PAL, so bringing the lower 64K back into use, with the new use chips, and it booted.

I found a RAM test program presumably for a CPC464, that tested the first 64K, and that passed. (I also retested with the bank 4,5,6,7 GAL to check the upper bank)

In order to prevent this happening again, I've put some heatshrink over the inline connections on the 12V power supply, so it is fixed to the line socket, so the owner shouldn't be able to mix them up again.

It's still quite a convoluted setup, but it's all working nicely.

Disks are reading correctly.

And the programs on them running.

As are cassettes.

And you know what I am going to try loading?

Yes, and that loaded fine.

I played a few levels, and didn't have any problems, so that looks like it's sorted. Ready to go back to it's owner.

I've had a few more Amstrad machines arrive recently to add to my collection, including this one where the packaging is probably worth more than the (faulty) computer inside.

And this one, which was described as 'untested', and if you look carefully you will see if the board is quite a late, short CPC 464 board, but the cassette deck is an early one, intended to connect to the earlier, much longer PCB, so the cable doesn't reach the shorter board!

Hopefully the result of this is that somewhere there is a long board CPC 464 machine, working nicely with the cassette drive from this machine.

The story of the SD2PET Future

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

This is the story of the SD2PET future. Are you sitting comfortably? Then I'll begin.

The SD2PET future is a new disk drive replacement for the Commodore PET and CBM range of computers, and it is available to buy now. It is not, however, the product we planned to build.

Way back in the distant mists of time (well, 2014), I repaired a Commodore PET 4032 computer and started looking around for SD card storage options as I didn't have much software on tape. I couldn't find any available to buy, I did find one that had been sold for a while, but it seemed was no longer in production, and the creator wasn't responding to messages. I ended up making a version of that using an Arduino as a base, and whilst it worked, its functionality was limited to load and save PRG files, it didn't support disk images or any of the BASIC 4 disk commands etc.

I was then pointed towards another project that was still going, but it was at the other end of the scale, a bit overkill for what I needed, with options for a realtime clock and network interface and a big LCD display etc. In consultation with the creator of that project, I built a cut down version, the PET microSD. I kept all the pinouts the same, so it could use the same firmware as the larger device.

This worked very nicely and did exactly what I needed. When I wrote this up on the blog, there was a lot of interest, and I sold out of the first batch of PCBs I had ordered.

Given the success of those, I got in some more PCBs and took the opportunity to redesign the board to offer some different options for mounting the drives. They also went blue at this point.

2016, I'd been making these for a couple of years, usually in small batches to keep up with orders. Then one day I built a batch of boards and quite a few of them didn't work. With a little rework, I got a few more of them working, but there were still too many that appeared fine, but didn't work. This continued with the next batch, even more that didn't work. It wasn't clear what the issues was, my soldering and surface mount assembly skills were acceptable, no obvious problems there. I had no issues like this with any of the other things I was making at the time, most were pretty near 100% yield. These were less than 75%. Had I got a batch of bad, fake, or mislabelled parts somewhere along the line? was there something up with the firmware? I did find older versions worked better than the ones that were current at the time, but I never did get to the bottom of the issue.

I was busy on some other things at the time, so sold the last of the working ones and marked them as out of stock. The requests kept coming in asking when they would be available again (and did I have just one left that they could buy?). I was advised to simply drop the product, as it just wasn't working, but I decided I couldn't let people down, so I said I would do one more batch, and setup pre-orders for a month or so in early 2017. To rule out any problems with the previous PCBs, I relaid out new versions of the PCBs, with wider spacing, and to ease the manufacturing process, the original double sided board was slightly enlarged and made single sided. I ordered lots of boards, and a complete set of new parts from a different supplier to build more than enough for the pre-orders and to leave some for stock.

Despite everything, the yield this time was even worse, more than half the boards were not working. Many now exhibiting an issue where they would give an error the first time they were accessed, and then work fine after that. In brief, it would start up fine, and would start to respond to the first request from the PET, but part way through the communication, it would stop responding. Trying again immediately and it would always start working correctly, and would keep working until a power cycle. But would always fail the first access after power on. I tried all sorts, swapping parts between good and bad boards trying to narrow it down. In the end, I had to order even more parts to build another batch of boards to complete the last of the preorders. After all that work, I had ended up making a loss on the whole thing due to the number of bad boards and so that was it, the PET microSD was dead. I have since heard that the person selling the larger version was having similar issues and an equally poor yield.

I decided the best option was to start again, design my own PET disk drive, write my own firmware. There were various options for code to access the SD card, and I could learn the D64 image mounting etc. from SD2IEC. I kept going back to that design, as the Future Was 8 bit version had been refined over time, and had proven very reliable in service, with very good yield, few returns and lots of happy customers. Based on that, I tried to use many of the same parts as the SD2IEC in the new design, and also in the name, the SD2PET was born. The IEEE-488 interface hardware and software I would start again from scratch, and go back to the protocol specifications, and design afresh, trying to simplify things where possible. The amount of time that I spent starting at diagrams like these.

Since I had handed over production of the VIC20 Penultimate Cartridge to The Future Was 8 bit, and they were doing a splendid job of making those, it seemed the way to go was to see if they wanted to make the PET disk drive. For that to happen, it had to be good. It had to be reliable, it had to work every time, it had to work as soon as the customer took it out of the bag and plugged it in. Nice and simple, no need to read through lots of instructions. It also had to look nice and be unnecessarily small and so on. The original PET microSD designs of bare PCBs plugged into the back of the PET weren't really in the TFW8b style, it would need to be in a nice moulded case for appearance, and also for protection. At the time we looked at a few options, but didn't think we would have a suitable case for a drive that would plug directly into the PET, and it would be difficult to justify the tooling costs of making one specially for the PET.

After a while I came up with the idea of using the SD2IEC case. This is the disk drive replacement for the C64 / VIC20 etc. That would solve the presentation issues, it just needed a way of doing the cable at the PET end. There we hit a slight snag as when we couldn't source any suitable cable to connect to the IEEE-488 port. There are 24 pins, 8 data, 8 control lines and 8 grounds. and we couldn't get any cable thin enough to fit with the SD2IEC case.

Another delay, more thought, and then I came up with splitting the design into an IEEE-488 interface that would plug into the PET and an SD card reader in the SD2IEC case. With a limited number of connections needed between the microcontrollers in the two parts, we could use the same cabling as the SD2IEC. That looked like a winner, so we put that up as 'coming soon', and I got on with the design work again.

More delays at this point due to other projects, and the SD2PET wasn't working out as easily as hoped. The PET does some interesting things with the IEEE-488 standard, a particular example that took far to long to deal with was the DIRECTORY command which keeps stopping and starting reading one or two bytes at a time and then switching the bus around and calling a halt, then starting again.

The project has progressed to the point where we are choosing case colours. I was still working on the firmware, and also on various other projects. I don't think we've talked about this before, but your reward for reading this far is to hear about one of many products that don't quite make it to production for one reason or another. Usually that they are simply not good enough to put the names of Tynemouth Software or The Future Was 8 bit to them.

This was SD2ELK, a disk drive replacement for the Acorn Electron. The idea basically to give the Electron a ROM slot and a user port and then use one of the BEEB MMC type devices that normally plug into the BBC. The plan here was to reuse the case from the DivMMC future, and to that end, some white versions were commissioned to fit better with the Electron.

This hit the snag that most of the Electron software wasn't designed to run from disk, and expected PAGE to be set to E00, but the disk controller needs to use some of this RAM, so sets PAGE to 1200 or higher, so not many things worked out of the box. We didn't think that was going to be good enough, we didn't want people going through a whole load of programs and none of them working. There were a few options to investigate to get around this, but essentially, it wasn't the right solution. (we note that since then someone has done pretty much the same thing, and unfortunately has the same issues with the disk controller PAGE offset).

At around the same time, we got in the quotes for the tooling required to make the new connector for the SD2PET that houses the small circuit board for the IEEE-488 interface. That was working out a bit expensive than expected, so the price of the SD2PET as it was then, was going to work out a little on the high side. I remember a phone call with TFW8b discussing the end of the SD2ELK project and 'what are we going to do with all these white div cases' and the cost implications of the 'soap on a rope' version of the SD2PET.

During that I started sketching out a new idea. Take my original redesigned SD2PET, before it was split into two halves, and that would fit into the divMMC future case. Thus the SD2PET-CR was born, a cost reduced version in an alternate case style that would be available for anyone unhappy with the price of the other version (now dubbed SD2PET + to avoid confusion). The + refers to the extra features that will be on the + version, controlled by the two function buttons on the case. The CR only has a reset button.

The divMMC future case has a cutout for a 9 way D joystick connector. That is not required here, so a blanking plate is used to allow the power input cable to exit (there is no power on the IEEE-488 connector, so 5V is tapped from the datasette in the same way it is done on the C64 SD2IEC).

With SD2PET CR renamed as SD2PET future, and the main stumbling blocks in the SD2PET + resolved. These went onto pre-order. I was told that everyone would go for the plus version, and we could quietly drop the future version when no one ordered it. But people did order it. It didn't sell as many as the plus, but enough to make it viable.

And then a request along the lines of 'can I use a standard BBC SD card reader on a BBC Master Compact?' turned into 'can you make me an SD card reader for a BBC Master Compact?', which turned into 'I could probably do quite a nice one in an SD2IEC case', which then turned into 'could you use that on other BBCs?', which turned into SD2BBC.

That followed the same ideas as I have mentioned before, use the experience from previous designs and common parts and circuits where possible, so this took what I had learned from the SD2ELK, and the case and SD card power circuits from the SD2IEC. It did however mean that I was diverted from SD2PET again, and you may have noticed a run of blog post of BBC micro repairs in order to test this on a range of machines.

Of course, I've recently been doing the same thing with PETs, so expect a lot of upcoming PET repairs with one of these plugged into the side.

Due to a delay in the production side of the SD2PET +, the SD2PET future has arrived first. These are shipping now, with the plus version to follow as soon as we can.

Update:

The second batch of these has been built and it now shipping, a slight change has been made. The original batch (now #rare) has a black drive reset switch, and a clear button fixed in place above the indicator LEDs. The new batch now have a flush clear section above the LEDs instead.

These are also now available from my Tindie store.

2022 Update: The SD2PET future is now the main model, and is now just referred to as the SD2PET. Available now from  The Future Was 8 bit