So this site, like any site that accepts comments, receives its fair share of spam. Akismet does a pretty good job of keeping them at bay, but sometimes the weirdest ones get through.
This one’s bizarre enough that I almost approved it – but I don’t want to reward the spammer by sharing the actual advertised link site! so….:
Christian Vogelgsang, who a couple of years ago collected together the git repository of Tobias Gubener’s Minimig_tc64 project and ported the OSD menu code to GCC – thus sparking my interesting and subsequent foray into the world of FPGA development – has been hard at work once again! This time he’s succeeded in adding support for the Chameleon’s clockport to the Minimig core, which means that in theory a good proportion of clockport peripherals should now be usable!
So far it’s only been tested with a Silver Surfer card – it will be most interesting to see which cards work without any further changes, and which prove to be troublesome.
Links to source, binary and details of a small hardware hack required can be found on Chris’s blog – but before downloading and trying them take note that
THIS MUST NOT BE USED WHILE THE CARTRIDGE IS PLUGGED INTO A C64.
The IO mux code has been stripped right down to bare bones to give usable clockport performance, and the synchronization with C64 bus cycles is no longer present, so a connected C64 will definitely crash, and may even be damaged.
With that warning in mind, do check out his work here: http://lallafa.de/blog/2013/09/a-clockport-for-chameleon64s-minimig/
You may have noticed the new “ZPU” section on the header of this site. The ZPU is a very useful little processor, and I think it’s under-appreciated because of a lack of documentation and design examples – so I’m trying to redress the balance a bit with my ZPUDemos repository.
So far I have a very simple Hello World project, which on an Altera DE1 board takes up a tiny 684 logic elements, including RS232 transmission. The ROM is also pretty tiny, bearing in mind it’s written in C, at under 2kb.
The repo also now contains Dhrystone benchmark projects, which use the ZPUFlex variant both with and without the optional hardware instructions, turning in about 1.7 DMIPS for the barebones configuration, and 5.1 DMIPS for the version with optional hardware instructions enabled.
More demos will follow in due course.
My nieces visited today – and spent a very happy hour playing two of my old favourite games – Pang and Lotus II. Both games went down extremely well with the girls despite being released about 10 years before they were born! While I still find a lot of fun in classic games, it’s encouraging to see that they’re enjoyable even to the iPad generation.
I was rather amused, however, that they were playing such ancient games on brand new, 2013 hardware: For Pang we used Majsta’s prototype Vampire 500 board, while we ran Lotus II on one of Till Harbaum’s prototype MIST boards!
So while I’m experimenting with FPGA boards I generally upload a design into them at runtime via a USB-Blaster JTAG cable, and only rarely do I store a design permanently in a board’s configuration device.
Some of the boards I use have two separate connectors for the USB Blaster – one for direct programming of the FPGA and the other for Active Serial programming of an EPCS series flash device. Others have an onboard microcontroller which handle configuration – and then there’s the Vampire 500 board. This has a single JTAG connector and an EPCS4 configuration device, but no immediately obvious means of programming the EPCS4. Continue reading
…is directly proportional to the value of equipment destroyed!”
I don’t know who first coined this phrase, but it’s always struck a chord with me.
I came close to gaining lots of experience in the last week!
My Vampire500 board came with “some assembly required” – the FPGA, SDRAM and level translators were all in place, but installing the non-essential stuff – the micro SD slot and PS/2 socket – was left as an exercise for the user!
I want to press the Micro SD slot into service so that I can load alternative Kickstart ROMs, because my old A500 board has kickstart 1.3, and I need a more up-to-date ROM to test Zorro III autoconfig, and to run certain test software.
As it happens I haven’t done any surface mount work before, so I was a bit nervous about attacking an almost-one-of-a-kind board with a soldering iron – but after butchering the control board from a dead hard-drive and convincing myself that I *am* capable of soldering on that scale, I had a go at mounting the micro SD socket. I was relieved to find that it has locating pegs that fit holes in the PCB, so at least I didn’t have to worry about alignment.
Well it *looks* OK – now to see if it actually works!
Building on my previous rather perverse mashup of Amiga and ZPU technology, my old Amiga 500 motherboard currently has not just one, but *two* ZPU processors!
After spending a satisfying few hours tracking down a stubborn bug which turned out to be a mere bad solder joint, my old A500 motherboard is now able to boot using the Vampire500 board in place of the CPU!
Unfortunately, since that means I can now play some old favourites on the board (in the name of testing, of course!) there probably won’t be much more progress today!
I have an Amiga with a ZPU processor!
So what possessed me to create such a perverse combination? Quite simply that it synthesizes in about a third of the time that a TG68-based equivalent would, which speeds up the development cycle significantly while I’m bug hunting.
(I will admit there’s an element of “because I can” there, too!)
This not-very-exciting screenshot shows a simple program running on the ZPU, and testing the reliability of reads and writes to Chip RAM through the Vampire500. The program simply sets up a 2-colour high-res screen, clears the framebuffer, and then repeatedly adds 1 to each longword within the framebuffer. Any glitches in either reading or writing would thus be cumulative, so if I can leave the program running for a while and if the pattern on screen remains in nice neat columns (which it does), I can be sure that no glitches have occurred. (Or that any errors are perfectly consistent!)
Of course, a ZPU-based Amiga is of no practical use whatsoever, besides assisting in debugging the Vampire500 – but I find myself idly wondering how practical it would be to use a more modern CPU – such as, perhaps, the OR1200 – and then emulate the 68000 in firmware?
Anyhow, pipe-dreams aside, the next task will be to take a checksum of the Kickstart ROM, since ROM reads are the only kind I haven’t yet tested.