A short history of Amstrad

Amstrad is a strange company. It's not as well-known as some of its contemporaries: Commodore, Sinclair, Atari. The computers it used to produce are not as highly regarded as those of the others either. This is a bit unfair, I think, heck, they even bought Sinclair after one too many bone-headed decisions by Sir Clive.

Allan Sugar the founder and Amstrad the company, started their career by producing low-end HiFi equipment. Their shtick was to build things that looked expensive, but were in fact cheap. Back in the '70s and '80s, the way you listened to music was that you bought a record player, a radio an amplifier and a cassette deck. These you stacked on one another, creating your HiFi setup:

At least that's what you did, if you had the money. If you didn't, that's what you aspired to do. So, if you were tight on cash, you went to Amstrad who would give you a single box with all of these components in it:

This allowed for significant price-cuts. For instance, you didn't need four different power-supplies. You could remove a bunch of cables and connectors, even save on the case material. Just look at the internals of this same product:

The integration (and the associated savings) is obvious. Yet, the styling of it was as if the components were still separate: cheap but looks expensive. Of course this gave them the smell of turd in the high-held noses of HiFi purists and snobs all over the world. Mr. Sugar and Amstrad couldn't care less though as long as the money was flowing in. And flowing in it did.

So naturally, When it came to produce microcomputers, they followed the same strategy. Also naturally, they carried over their reputation for producing cheap crap. In this market however, there was a major difference: their main competitors did the same. Sir Sinclair was famous for his price-cutting measures. Across the pond, Jack Tramil at the helm of Commodore did it in aces too. Yet, it seems only Amstrad got stuck with this reputation.

My experience with Amstrad computers started late. I came across their CPC664 model in what must have been '92 or '93. I had grown up on Commodore machines and by that time, I graduated to PC clones. Yet, I was impressed. This machine was pretty good for an 8-bitter: full-sized keyboard, built-in floppy drive, a semi-integrated monitor, built around a Z80 processor.

It looked a bit dated, and of course it was dated by that point. Still, it could run decent games in reasonable resolution and in color. It had the standard Basic interpreter in ROM and came with Logo on a floppy disk. Even more interesting to me at the time, it could also run CP/M.

Back to the present

Now, why did I start caring about these machines in 2024? That's because of Zilogs decision to discontinue the Z80 line. I was working on UnIC already and was thinking about showcasing it with a retro-project. The opportunity presented itself: use UnIC as a Z80 replacement. For that, I needed a retro-computer as the recipient of the organ-donation.

My thoughts immediately went for the CPC664. Soon however it became obvious that that particular machine is unobtanium and even its bigger brother, the CPC6128 is pretty damn expensive. This is when I learned about another line of Amstrad machines. The 'serious' ones, the PCW line.

These machines go on eBay for somewhat reasonable prices, especially in the 'untested/for parts' condition. The default assumption with these sales of course is that what you get are broken, but I was after a cadaver anyway.

From box to boot

So, soon enough I had a big box arrive at my front door. Two, in fact:

I've unpacked the machine, turned it on and ... nothing. Well, not a big surprise there.

Trouble-shooting for these things follow a rather predictable order: check power, check clocks, check reset, check bus activity, check memory. Oh, and check capacitors along the way. Rooting around the power supply, I soon realized that several rails were dead. Only the -24V power for the printer came up (yeah, this thing comes with a printer, but its powered by the monitor; the old Amstrad method in action). Some digging around showed that one of the electrical fuses were busted.

This fuse kills the 12V supply rail, but along the way it also impacts the 5V one: even though the 5V gets generated by an independent secondary winding, the reference regulator for it gets supplied by 12V. There were two options why the fuse could have died:

1. It died of old age
2. It died a heroic death, protecting the rest of the circuit from impending doom.

The fuse itself is guarding the main transformer - which I measured to be working. Transformers are custom-made for almost every power supply and irreplaceable by all accounts. So it's pretty important to figure out which option I'm dealing with.

Luckily, for a different project, I bought a bench supply which had current limit and programmable voltage capability. I could easily sub it in right after the fuse and safely test if things were in good shape. I set it's voltage to 12V and gradually increased the current limit. The voltage stabilized at around 0.5A. No smoke either; quite a relief.

So, it's the fuse then. I can buy replacement ones - and I really should - but for now, just shorting it will do.

At this point I could verify that the CPU was released from reset, that the clocks were clocking and the monitor came alive as well: I was greeted with a green glowing screen and ... nothing else.

First I was surprised by this, but later I learned that this is normal: this machine doesn't have a traditional EPROM in it - which should have been obvious by visual inspection, but, you know... All it has is a very small boot ROM that tries to load the first sector of an inserted floppy and then execute it. I had no floppy drive attached to the motherboard at this point (safety first), so it just got stuck on the green screen.

Side-bar: the how to boot without an EPROM? And why did the designers go down this road? Here's my reconstruction of what conspired, a rather ingenious design decision:

The machine has only a few major components: the CPU, memory, a central, custom gate-array, a floppy controller (split in two chips) and the printer interface:

Adding an EPROM would have been a rather large cost-adder (and we all know how Mr Sugar feels about that). However, since this machine always came with a floppy drive, one could get away with very little ROM; just enough to bootstrap from a floppy. A few hundred bytes should suffice. But where to find a place for that? None of the chips I've listed have any permanent storage - even the custom ULA couldn't even dream of such luxuries in those days.

Or is there? You see, there's one thing I haven't told you yet: the printer controller is an 8041. This is the same thing that the PC/AT used for its keyboard interface. It is somewhat similar in spirit to what the very early PIC micro-controllers were and is billed as a "universal peripheral interface 8-bit microcomputer". It is a small microcontroller attached to some GPIOs and a bus-interface to talk to a bigger host processor.

Crucially, it contains some ROM for it's own code. A whole 1kB of it. Now, if there's some space left in there, one could imagine using that leftover storage for bootstrapping the Z80.

There are three major problems to overcome. The first is that the 8041 can't expose its ROM to the host CPU. It can respond to requests, and given the right programming, that response could be a byte from the ROM, but it's going to be very slow. Somehow, the Z80 will have to be slowed down enough to be able to read the bytes from the 8041.

The second is that the Z80 normally likes to see peripherals in it's I/O map, not in it's memory map. A machine already containing 256kB of memory certainly doesn't want to waste address space for an I/O peripherals. And the Z80 can't execute out of I/O space.

The last problem is that, even if the 8041 is memory mapped, it can't decode more than two addresses: it has a single address line. So, how could the Z80 execute from this place? The answer is the following:

During boot, the chip-select for the 8041 is decoded to the whole (probably lower 1024 or so bytes) of the address space. A0 of the 8041 is driven to some constant level. This way every read (instruction or data) from that address region ends up going to the 8041. It in turn responds by a series of bytes from it's ROM while the ULA yanks on WAIT to slow the Z80 down sufficiently. It doesn't matter what the address is: the 8041 simply streams out a sequence of bytes, one for every request. With careful coding, this can make the appearance of legible code for the Z80. It can't do much of course. For instance, it can't execute branches, loops, conditionals, etc. What it can do is to have a series of instructions that store content in RAM. That's just a boring sequence of LDI instructions. When that's done, the last instruction can jump to the RAM location it just have written, where now the real boot-loader resides. The actual boot process is a little more complicated, but really just a little. You can see all the details documented here:

https://www.chiark.greenend.org.uk/~jacobn/cpm/pcwboot.html

Back to my particular machine: it did nothing interesting, but - again - that shouldn't be surprising. All this tiny boot-loader can do is to load the first sector from a floppy disk and execute it. It can't afford the niceties of giving user feedback or painting a pretty logo on the screen. As I mentioned I didn't have the floppy drive connected, but even if I did, I had no floppy disks for it. Not to mention that these floppy drives all used belt drive mechanism. These belts all become brittle and broke. I found mine in many pieces strewn around the innards of the drive.

A new belt needed to be ordered and floppies needed to be acquired, with the right content on them. To make matters worse, Amstrad machines are notorious to use a now extinct 3.0" floppy format:

So, go through all of that ... or get a Gotek.

The choice is obvious. Once the Gotek arrived, I needed to set it up. One thing to do was to create an adapter ASAP: Amstrad or whoever made the 3.0" drives, in their infinite wisdom used the same 4-pin power connector as PCs did (and the Gotek uses), but reversed the location of the +5 and +12V supplies. That's not good if mixed up, thus the urgency.

The data connector is also different, albeit the signals are the same so an adapter cable is needed for that as well:

One thing not required, but nice is to replace the stock firmware with the much more user-friendly FlashFloppy.

Finding and downloading disk images turned out surprisingly difficult. I though these machines were better cared for on the Internet. There is a nice PCW emulator out there though, which allowed me to make sure the images actually work (and see what they should be doing).

I had some trouble getting the jumper settings for the Gotek right, for quite a while nothing really happened. The trick was to move device select jumper from the 'S0' to the 'motor' or 'MO' position:

With that final tweak, the machine booted for the first time.

RAM issues

All was good, until I started the basic interpreter. It reported some outrageous amount of free memory. Way more than what was there in the system. Typing in even the most simple program hung the machine. Now, the first idea that comes to mind in such cases is bad memory. The second would be bad power supply quality. Or in reverse order. Maybe. At any rate, since I was just in the power supplies, I knew they were stable and there aren't large electrolytics on the mainboard that could cause problems by drying out.

I tracked down a memory test program for CP/M (I think it was called UMPIRE), loaded and ... bang! Almost immediately errors started to fill the screen. Documentation wasn't the strong suite of programmers even back then, so I don't quite know what the reports mean, but the code (20) I thought would mean that bit 5 might be bad.

The memories called out on the schematic are just regular 256kb DRAM chips. I have a stack of them from some previous project I can't even recall. The chips are even socketed on the board, so it should be easy. Since I have a bunch of these chips and I wasn't all that interested in tracking down which chip in particular was at fault, I replaced all 8. Rebooted and... The screen was all screwed up! Every character appeared to be printed twice. Yet, the machine booted all the way to CP/M. I could type. It wasn't really legible, but it certainly seemed to work. This is very strange. What kind of problem could cause this? It obviously had to do with the memory, but how can the CPU work perfectly well from the same memory that the video so patently can't. This was a mystery.

I failed to take a picture with all DRAM chips replaced, I only have one when all the odd bits are of the replaced kind:

It's a cool effect, if you asked me. In fact, if I was given this picture and asked to come up with a root cause, the last think I would have suspected was memory. Yet, here I was.

A closer investigation of the memory chips revealed that the ones in the machine are not 41256-s (the ones I had) but 41257-s. What could the difference be? I was aware of various manufacturers giving their memory slightly different part numbers apparently just for the heck of it. Is it one of those cases? Especially since the schematic calls out the same memory type for both banks and everyone and their grandmother swears that second bank contains 41256-s:

Turns out it's not. The 41257 is a special kind of DRAM, where page-mode addressing is replaced by CAS nibble addressing. Looking more carefully at the schematic, it is even called out: 'nibble mode' it says on the right. For this chips, once a RAS cycle is started, up to four CAS pulses can be issued without a CAS address and 4 bits are output from four different addresses.

This is in contrast with the 41256 chip, which needs a new CAS address for every CAS pulse:

The end result of this is that if I replaced the 41257-s with 41256-s, what it did was to make it repeat the same output twice (or four times, depending on how the PCW drives the chip) instead of outputting different data per the designs intention.

Furthermore, if this kind of special addressing is only used during video memory reads (which makes sense: the CPU can't do bursts, while the video is really ideal for it), this difference would only screw up the video display.

Now that's fine and all, but where to find a replacement 41257? This is a rather special chip, not the garden variety 41256. Luckily I've found someone in France selling a few for a reasonable price, so - after the lengthy process of crossing the Atlantic - I got my replacement chips:

While I was waiting, I took a scope-shot of the RAS and CAS signals going to the DRAM chips, which I then promptly lost somehow. So, to show you what's going on, I had to recreate the waveforms in WaveDrom:

On the bus you would see these four different cycles repeating. First a video memory read with the infamous second CAS pulse that engages the nibble-mode of the 41257. Then, you get a refresh cycle, followed by a second video access. The last cycle is for the CPU with the much more familiar RAS/CAS timing. These cycles are of course delineated by precharge periods which are required by all DRAMs.

Each cycle lasts 250ns, so the repetition rate is 1MHz. To foreshadow something that comes much later: this means that the CPU, clocked at 4MHz only gets access to the memory every 4th clock cycle: the WAIT signal is a 25% duty-cycle, 1MHz wave. It also means that the system doesn't use the Z80s refresh cycles at all, those are wasted. Since the Z80 is absolutely memory-bound, this configuration must mean that the processor is running at a fraction (not exactly 1/4th, but close) of its full speed. Crazy to think that, especially because the machine feels responsive, not just in CP/M, but in it's word-processor and even in SymbOS, a modern graphical OS:

The display

The display resolution is 720x256. It otherwise follows TV timings, so the horizontal scan rate is 15.625kHz with the active period of 52us. The display is black-and-white, each pixel is 1 bit. This means that a new byte is needed from memory every 570ns. The previous timing setup yields 4 bytes in 1us, or 1 byte every 250ns, twice the rate needed.

Why? Very good question, especially considering how detrimental it is for CPU speed. I would love someone with deeper knowledge of the system shed light on this. It's not like the ULA with its 3312 total (NAND-2 equivalent) gates could do anything fancy, such as caching a scan-line.

Are we there yet?

Almost. With the fixed fuse, the replaced memory, the Gotek drive the machine was working. The only problem left was that it reported having 2 floppy drives. This was a bit of a problem and stem from the fact that the selection of the Gotek was solely based on the 'Motor ON' signal. An external OR gate (active-low AND logic) was needed to make sure the Gotek is only selected when both 'Motor On' and one of the 'Drive select' pins is active. This mod is detailed here.

With that, the machine now thinks it only has a single drive, but for some reason still doesn't allow (or recognize really) the original floppy drive as a secondary drive. Because, yes, I did get my replacement belt and some floppy disks, so it would have been nice to be have both hooked up. This is all the more mysterious as the schematic clearly shows a selection jumper on the drive-select pins:

Well, maybe not all that clearly at this resolution, so here's the link to the original: pcw8256 service manual, see page 15 and 16.

Either way, it works, I even found a 3D printable design for a front-cover for the Gotek that fits in the 3" floppy opening on the PCW. Many thanks to my friend, Gabor who printed it out for me!

Putting all the pieces together have left me with - as far as I can tell - a perfectly functional PCW8256. Which enables the second part of the saga: braking it with my UnIC Z80 replacement, but that is another tale for another day.