PCB design

Well, I've spent a long time on this, but I think I'm pretty happy with the layout now. Tomorrow, I'll hopefully resize all the power lines a bit and add some ground planes...



I'm amazed how long PCB design takes... Still, the end result should be good. It's got scart, 2 joysticks, tape in, USB (with about 10 dedicated pins to the atmel which should provide serial, misc I/O and JTAG), PS/2 keyboard, SD card and a bunch of expansion headers offering 14 I/O. Additionally, there's another 4 lines from each of the FPGA and atmel tied together so the atmel can access the SD card via the JTAG which could also be used as general purpose I/O.

Let's hope that when I get this board made it actually works...

Bubble Bobble running now

So, this is an awesome game and I thought it'd be as good as any to test out my FPGA board... actually, better than most because I don't currently emulate disk IO... :)

Sadly, it kept crashing on the intro screen... it's supposed to play music and carry on, but it just sat there with ghosts moving around but nothing much happening. I eventually tracked it down to when I'd modified the WAIT_n logic the other day... and IN r,(C) worked fine but IN A,(n) returned n instead of the data. And it just so happens that bb4cpc uses that method for determining the vblank. Interestingly, it only actually used that for music playback.

Anyway, bb4cpc running on my CPC FPGA board:


I also decided to register a domain name as things are progressing well now. Shorty, catchy, to the point: cpcfpga.com :)

Instruction timings take 2, also did I mention my video works?

This news is about a week old now, I just never got round to posting it. My new SCART interface is perfect. Rock solid, awesome, etc... And yet, I only discovered that by accident!

So, if you remember back a week, you'll remember I'd built a new SCART board with transistors to provide a higher current, etc. Well, this board features a socket instead of being wired up directly to a SCART lead. As a result, I wired it up wrongly and when I swapped the composite over to composite out instead of composite in, the jittery sync problem disappeared. I discovered by chance, when I was trying to put the audio on the correct pins that as soon as I connected them up, the picture was jittery and stable when i disconnected them. After a bit of investigation, I realised that the tape input on my new board was left floating and I was outputting that bit to the speaker resulting in random white noise. That explained the rubbish sound quality, but not the jittery video sync... well, that seems to just be because I'm pumping 3.3V down the audio pins in the scart cable and it's either overloading the TV or inducing stray pulses on the composite line. I've not reworked that circuit yet to reduce the voltage, instead just stopped tape input noise being sent to the speakers (much like a 464plus).

Anyway, I then discovered quite by accident that if I use my gold plated SCART lead direct into the TV, the picture is perfect. Stunningly good, in fact, but any combination of the other leads or SCART box I have makes it look speckly. Obviously, a good quality SCART cable does matter!

And so, to tonight's news...

I realised a while ago that the instruction timings weren't actually correct. It turns out the T80 soft core asserts IORQ on the rising edge of T2, not after it as the Z80 manual suggests. I guess this is reasonable, but means that my logic sees IORQ a cycle earlier than it should and so IO instructions weren't getting stretched enough in all cases. I finally made a workaround tonight, and the results seem pretty close to the software emulators now:



Basically, the image shows the colour palette is only out by 3us... this could be fixed by a simple delay, but I just want to make sure that everything else is timed correctly first!

Botched attempt at a new SCART board

I've had a pretty bad cold now for just over a week and on Saturday, rather than face the outside, I knocked together a new "SCART board" that turned into an "almost everything but the kitchen sink" board:

I got a bit carried away designing - I even reworked all the top half memory board too, until I discovered that whilst my DIP32 chip fitted over the 3x20 way header perfectly, the smaller SMD chips I have left would have to be placed on the board and there wasn't room to run all the traces without reordering all the pins.

But this board did have a tape adaptor (in, out and motor), PS/2 keyboard, audio jumpers (so I could connect a speaker instead of going through SCART) and a breakout connector for the 3 buttons I'd originally designed for (which are implemented by the left 3 push switches on the mainboard). However, it looks like this board didn't really work...

Basically, the reason for designing this board at all was that the picture from the current board didn't work too well. It's a bit shimmery and the sync seems "iffy". As in, the picture is fine for a while and then just wobbles a lot and the picture disappears. There isn't a picture at all even on my TV downstairs and the new 12" TV I bought for the FPGA was very twitchy.

Eventually, I had the bright idea of measuring the current and realised that I was drawing far too much current through the FPGA, whose pins are supposed to drive about 8mA. I was probably easily exceeding that on the sync and quite close for RGB. So, I decided I need to drive the current through transistors and as luck would have it, I found a few BC548s knocking around in my electronics tub from an IR receiver I was building years ago.

After a simple start with all the SMT components, I moved on to the headers. Soldering these on top of the board was a mess. Most of the plastic melted. I'm going to have to get some SMT ones that are designed for this. Matters weren't helped by the really small pads I'd used for the headers. I'd designed my own component based on a 20x2 way header and beefed it up to 20x3 way using a python script. This was mistake 1. The original board was done with 3 separate 1x20 way headers which leaves big pads. I'd forgotten how hard solder is to actually get to stick to thin traces. I then realised that the transistors on the underside didn't fit because of all the banks of jumpers on the FPGA board that disconnect all the LEDs and switches on the board. So, I had to desolder them and bend them to fit. This ripped up all the collector traces. HURR!

After much fiddling, I eventually patched up the board, measured all the resistances for complete traces or shorts and all was well. Plugged it in and... NOTHING. Perplexed, I plugged it into the TV in parallel via my 3 way SCART block (a bad idea, but worth it) - there were patches of colour overlaying the other picture, so something was working... but the sync was all wrong.

I decided the TV couldn't possibly be presenting 75 ohm impedance and so my voltage divider wasn't working, but this wasn't it either - I fashioned a 68 ohm resistor out of 100 and 220 through hole resistors and measured the voltage and sure enough, it was about 0.065v which was about right for the sync pulse at 16/64 duty cycle. Stumped, I prodded around the scart box and discovered that pin 20 wasn't supplying a voltage at all... But pin 19 was. Then it dawned on me. SCART leads swap a few of the connections.

I started hacking up the composite trace with a sharp knife and then joining it up at the correct place. Plugged it in and the picture was terrible. Eventually, I got a half decent picture by applying a lateral pressure to the SCART socket, so clearly either the plug or socket isn't very high quality, but after all that work, it's not all that much better than before. Here's the test picture:

The sync is a bit more stable on the new TV, but doesn't seem to work at all on my LG. There's a slight bend at the top of the screen (although that could just be the test pattern not providing a correct sync of 5 half lines at the top of the frame) and the image still has speckles here and there. So, basically, back to the drawing board. Still, at least I've learned a few more soldering DON'Ts in this process! But seriously, SMT is so much easier, I can't wait until I'm using a custom board where I can just heat gun the whole thing!

New mystery hardware

Today, I built some new hardware... I won't tell you just yet, because I'm sure you can guess what this is going to be from the PCB. You'll also notice that I plonked the image down too close to the edge leaving a very nasty trace which I had to patch up later. When I was designing this is all looked really tiny, so I left lots of space between all the components that I certainly don't think I actually needed as the board looks very empty...


If you're still guessing, here's a hint. It uses this circuit twice...

Here's a nice "arty" shot of the board, and if you haven't guessed already, you'll see the header now has a keyboard socket plugged into it (taken from an old PC which very handily just had a 5-pin header on the motherboard that this plugged into):


All in all, I'm pretty happy with this. There's a few spurious issues - on reset you quite often get a few seconds of random keypresses and occasionally key make/break scancodes are missed resulting in missed or repeated keypresses. But it's close and was pretty fun to do some soldering again!

And here's the obligatory youtube video... :)

A momentous moment...

So, I knocked up some ROM bank switching code this morning before work and only got to try it out this evening... and discovered after a few hours the simple mistake I'd introduced to keep myself on my toes... ;)

Anyway, with that in place, copying the ROM images to the flash ROM and making a bootloader to pull them in and I get this:


It's obviously pretty flakey... it worked in this shoot, but it seems to have about a 50-50 chance of actually booting and sometime between recording that video and writing this, I've noticed the cursor is no longer solid but stripey. But, this thing is so close now I can almost reach out and touch it... :)

After a bit of tweaking, I seem to have instructions timings just about correct... I'd hyper-corrected all memory accesses meaning there was an unnecessary wait state in a normal memory read which only seemed to show up in the 4-3-5 T-state pattern used in relative jumps, so those instructions were padded out to 1us longer than on a real CPC.

Additionally, I'd been struggling with the interrupt generation for a couple of days with it resolutely refusing to work right. I tracked that down to a typo and I was resetting the counter on the 2nd pixel in a hsync rather than the 2nd hsync in a vsync... Ooops!

So, compared to WinAPE, it's almost there now...

Tomorrow I'll try to get ROM banking working at which point I might be able to get BASIC booting. At the moment, there's a single "ROM" which is used for the boot image.