I've started to revisit some of my demo source code from last year, but I still think I'd rather be playing with hardware!
Saturday, 21 April 2012
Still no news
Saturday, 14 April 2012
Long wait
I was pointed to this blog which is pretty interesting and talks about some similar timing and signal noise problems to what I used to see on one of my earlier PCBs: Veronica - VRAM.
Also, over the Easter weekend I went to Revision in Saarbrucken. Unfortunately, I'd spent so much time designing this PCB that I'd not had chance to code anything demowise, but it was still nice to pull out the assembler and do some pure software development over the weekend. I've found away to speed up something I http://www.blogger.com/img/blank.gifwas working on last year, although ihttp://www.blogger.com/img/blank.gift'll involve a lot of meticulous cycle counting.
There were 2 very good demos by Benediction, and I also spent a while chatting to these guys which was great as it's the first party I've been to where I've actually found any fellow CPC coders! Krusty also gave an overview presentation on the CPC which will have helped to make more people aware of the CPC. Anyway, their demos are here (and both came 3rd in their respective categories too which was aweseome given the competition):
Wake UP!:
and Stop that nyan cat!:
One final project that was phenomenal was lft's Parallelogram demo running on an FPGA that won the wild competition:
I had a few good conversations about my FPGA here too - it seems a lot of people are interested in this.
Monday, 2 April 2012
The specs are still a bit in-flux at the moment as it'll largely be a case of what I manage to get it to do. Basically, I "needed" to build my own board because I ran out of gates on my Actel evaluation board. On that, in 250K gates I had equivalent to a 464 and the off the FPGA, I had a 512KB memory chip providing 256KB RAM and 8 ROMs. Sadly, I ran out of gates before I could do a disk interface or any "plus"http://www.blogger.com/img/blank.gif features. The gate counts are a bit lower than some of the other CPC implementations on FPGA because I decided to do it all myself apart from the T80 core and I was treating this project as a learning exercise in how to write efficient VHDL.
This board has 400K gate Xilinx FPGA, a SCART socket, an SD socket on the underside, 2 seperately wired joystick ports (so no clash), 2MB flash and 512KB RAM, tape in, 14 GPIO pins, 12 IO pins wired directly between FPGA and AVR and an additional 4 FPGA and 4 AVR pins that I thought could be jumpered together together to allow AVR access to the SD card or provide a header to a different SD card socket or just used as more GPIO. Additionally, as I'm still experimenting, the AVR clock can be jumpered to run from an FPGA output and vice-versa.
Connecting a standard CPC keyboard directly would be possible because there are just about enough GPIO pins available, but I'll probably make a breakout board that somehow multiplexes the 10+8 keyboard lines to the 8 GPIO header next to the joystick ports. I must admit, putting this thing inside a real CPC keyboard is something I'd like to do too... :)
Regarding the pin 5 (and also pin 9) on the joystick ports - I thought about what to do about these, whether to make them IO, put 3.3V out on one, etc but I decided it was best to just to stick to Atari joystick with second button. I don't think I've ever seen a 3 button joystick. The only thing I could think of would be the AMX mouse, but that'd probably require 5V and level converting all the lines, so it'd be easier just to implement mouse via the PS/2 socket (and maybe do a second PS/2 socket on a later version of the board).
In terms of features I intend to use the AVR for are: JTAG programming of FPGA PROM, JTAG programming of FPGA (for development), serial port to CPC and a PC side debugger.
Despite it's CPC bias, I guess it could also be used as a generic FPGA development board that just happens to have 2 joystick ports, PS/2 keyboard and a SCART socket with 3x 2 bit DAC.
In terms of CPC "hardware" features I want to add, the 2 main features I want are hardware emulation of the CTM monitor so that horizontal smooth scrolling works on LCD TVs, and saving the last frame to memory so that the display can be "paused" when debugging, like the software emulators do. Basically, I'd like it to be as nice to develop on this hardware as it is with a software emulator. Additionally, I believe I can get the SPI chip running quickly enough to to random access, which would allow 128 ROMs.
I was also working on a simple software flash filesystem that operated like |DISC, although I put that on hold while I designed the PCB.
So, all in all, it's a bit ambitious... :)
"final" layout
Anyway, I've tidied it up some more, added ground planes, a power LED and put some text on the silkscreen...

It'll be good to think about something other than PCBs for a while... :)
Sunday, 1 April 2012
PCB design

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...
Sunday, 19 February 2012
Bubble Bobble running now
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 :)
Wednesday, 8 February 2012
Instruction timings take 2, also did I mention my video works?
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!