Not much of it though. I just measured the power consumption of my amp, and it uses about 5 mA when there's no sound, and up to about 60 mA when playing loud sounds.
I also measured how much power a PCW keyboard uses. It's about 65 mA.
So there you go.
I built an amp for my sound chip, which is largely the circuit on this page, without R2, and with a small capacitor between pins 4 and 6 (GND and VSS), because without the capacitor there was a huge amount of hum, but with it it's almost silent. Now I don't have to connect it to my guitar amp any more. The next thing to do (with this circuit) is to build it onto the stripboard.
I was reading John Elliott's keyboard protocol information, and noticed that he says that he didn't know the exact timing for the keyboard. So I thought I'd find out, and connected a PCW keyboard up to my logic analyzer.
I was interested to find that although the overall idea is as he describes, the fine details of the wire protocol are actually a little different:
I tried three different PCW keyboards (all from 8256s), and they all had the same timings. The values transmitted did match John Elliott's description.
I imagine the actual timing of this is fairly irrelevant though — so long as the clock signal is within certain tolerances I would guess that the gate array just clocks the signal in on the falling edge of the clock.
So here's the output from the logic analyser, with some times added. The times seemed to be fairly consistent, but I should probably have used fewer decimal places. The overall time of a transmission of the keyboard state (top chart) should be pretty accurate though, as I took the time for 50 transmissions and divided it down, and the time for one row of transmissions (second chart) was also averaged from 8 transmissions.
This weekend I got the sound chip wired up on the stripboard — this time with real sockets for the sound output and joystick port, which is much nicer than the random wires I had hanging off my desk before.
I've also been working on making the SD card drivers more robust — I'm actually paying attention to reponse codes and checking timeouts, so if you remove the SD card you get appropriate CP/M error messages.
I've spent the last week moving my circuit from breadboard to stripboard. It's taken this long because I kept getting bored of soldering lots of tiny wires and going to do something less monotonous. But I got it all wired up in the end, and it's working too, although it took a bit of debugging to get there. Initially I missed off a few essential wires — for example, I'd forgotten that I'd wired the Z80's RESET signal into the CPLD's GSR input on the breadboard. Then, even when I was fairly sure all the wires were in the right place, it still refused to work. So I used a multimeter to check if there were any shorts between adjacent pins, and discovered that D2 and D3 were shorted by a loose ball of solder. After removing that (and giving the rest of the board a blast of compressed air for good measure), it all seems to be working perfectly.
It's a little bit Heath Robinson though. I've used stackable headers all over the board, which means that I get a socket on top, and nice long pins underneath to solder wires to. Then there are two long pin headers at the end of the board — one has my CPLD breakout board connected to it, and the other has the 50-way cable from the PCW connected to it, which then loops around and connects to the underside of the CPLD board. It's messy, but effective. And it frees up my breadboard for more experimentation. Of course, when I get a PCB fabricated then it'll be done properly!
Here it is: (Oh, and I haven't done quite finished the sound or video circuitry — I wanted to be sure the RAM, ROM and SD card worked first).
I've been fiddling with the SD card driver settings, and now I have 3 drives instead of 4. Maybe I'll have a different number tomorrow.
I've halved the number of tracks, so that each disk holds 8 Mb instead of 16 Mb. That gave me 6 drives instead of 4. But then I added hash tables, which I think will make directory operations faster once I have a lot of files on the disk, and the number of drives dropped down to 3. I was hoping that by halving the disk size then there would be enough memory for 4 drives with hashes, but apparently not. However, there's always a chance I might find some magic combination of settings which lets me do that.
I've also got my mapping programme working, so I can use all 2 Gb of my SD card, by mapping drives to different areas of the card. I'm not sure what the terminology should be. I think it might be accurate refer to it as mounting partitions.
And as well as that, I modified my VHDL code so that my ROM is switched in immediately — it no longer waits for the PCW's boot code to execute. Since doing that, sometimes my PCW doesn't boot, and I have to switch it off and on again. I'm not sure if this is because I've dislodged some wires and the circuit is slightly dodgy, or if the PCW isn't quite ready for full speed operation immediately — the original boot code executes really slowly, which might give things time to settle down, perhaps.
I guess I should switch the VHDL code back and see if it starts being reliable again.
I said I wasn't going to stop the PCW project just yet, so here's a bit more progress. I got multiple logical drives working on the SD card this evening. I should probably change the message — drives C, D, E and F are all on the same card:
I started with 32Mb partitions, but CP/M was only letting me create two drives before running out of memory, so I reduced the size to 16Mb, because I though having multiple drives might be more useful. Especially as I've started to add the ability to map more partitions on the SD Card to the four drives. The FID file keeps a record of which partitions are mapped where — I just need to write a user programme to switch the partitions in the drives now.
RC2017/10 is over, and it’s time to sit back, have a bit of a rest, and do one final write up. Before carrying on with the PCW project anyway, because I still have lots of ideas of more things to do.
I set out without a huge amount of direction. I had just bought an Amstrad PCW for £5.50 the day before the challenge began, so I thought doing something for RC2017/10 would be a good idea, but I wasn’t sure what, and I didn’t think I’d have enough time. I started doing my project anyway, before deciding about a week later that, since I was starting to really get into the project, I should actually join the challenge.
My plan initially was to get the PCW’s motherboard working outside of its case, so that I could have a PCW which didn’t take up so much space. I found a small form factor PC at work which was being thrown out, and planned to put the PCW into it, but it needs to be properly wiped and signed off by IT before I can use it, and unfortunately that hasn’t happened yet. So my initial aim hasn’t quite been completed, although I did get the PCW motherboard running without its case, PSU, monitor and floppy drive as a proof of concept, so I should be able to do this once the case is available.
I did manage to do the following things though:
And I learnt quite a few things as well:
What plans/ideas do I have for the future:
It's the last day of RC2017/10, and since I had initially said I wanted to get my PCW working without its screen or disk drives, I thought I should try doing that. I had a spare motherboard, so I plugged it in to my circuits, connected it to a power supply, and it actually worked. Well, it nearly worked - my spare motherboard only has 256Kb of RAM, but my SD card driver currently uses page 16, so it hangs once the FID driver loads. Also, my power supply connection was dodgy, so I had to hold it to make it work, which meant I didn't have a spare hand to photograph it working. But I've now proved it works, so I just need a case and decent power supply to put it in. And I need to get everything put on a PCB.
I've also tidied up the boot code so the screen doesn't have rubbish on it, but has lines appearing as J15CPM3.EMT loads, like a standard boot, except they're vertical, and much faster.
After much reading of CP/M source code and stepping through the code in Joyce for DOS, I finally tracked down the vital byte to change so that drive C: is the default drive on my PCW. Now when the computer boots it looks on drive C: for PROFILE.SUB and doesn't care if there's no disk in drive A:. Although it still switches the drive motor on for some reason.
I thought I'd do a little speed comparison, so here is a programme I wrote a few years ago which loads a photo on the PCW, first being loaded from the floppy disk, and then from the SD card.