An arcade classic revisited…

If like me you grew up in awe of the high-end Sega arcade machines with their moving cabinets – Space Harrier, Outrun, Afterburner and Galaxy Force – then you no doubt have fond memories of the music from these games.
I just stumbled across this excellent remix of one of the most memorable tunes from Afterburner II – hope you enjoy it as much as I did:

>>>>>>Acceleration!

Following on from the addition of the Two Way Cache in my last post, I’ve made some more speed improvements to the Chameleon 64’s Minimig core.

Firstly, I’ve added a single-word write buffer, which means when the CPU writes to Fast RAM it doesn’t have to wait for the write to complete.  Provided completing the write takes priority over any potential reads from the same address, and the Cache is updated to reflect the new data, then the CPU can continue merrily processing.

Secondly, I’ve added a second access slot to the SDRAM controller, which means in many cases the wait for RAM service is reduced from a worst-case 24 cycles to 17 cycles.  The downside is that because RAM operations between the two access slots overlap, they can’t be to the same RAM bank.  For this reason I’ve remapped the RAM so that bank 0 contains Chip RAM, Slow RAM, Kickstart ROM and OSD RAM, leaving banks 1-3 free for Fast RAM.  Chip RAM and Kickstart ROM accesses can thus now overlap with Fast RAM accesses.

Finally, I’ve simplified the TG68 wrapper so that it no longer uses the enaWRreg signal to synchronize the CPU to the Amiga’s 28MHz clock.

Between them these changes give an average speed increase of about 65%. Continue reading

Experimenting with TG68

Part 12b – a better cache

I’ve *finally* found the subtle bug that was causing my two-way cache to fail.  The symptom was that the boot process would appear to work fine, loading an S Record off the SD card, but having loaded it, the code would fail to start.  It was as though the bootloader was ignoring the S9 record at the end of the firmware file.

After various fruitless attempts to track this down, and to construct artificial testcases to trigger the behaviour, I finally added some serial debugging breadcrumbs to the first-stage bootloader.  From this I found that the final S9 record was being treated as thought it were an S1! Continue reading

Experimenting with TG68

Part 12a – a better cache

The TG68MiniSOC project has so far used a very simple cache for the CPU.  The SDRAM controller is set up to use four-word bursts, so the cache simply stores each complete burst.  Under this scheme, when data is read sequentially from RAM, only one read in four will need to wait for the SDRAM controller.  This is the simplest possible example of a Direct Mapped cache, with just a single cacheline. Continue reading

DB9s and Matrix Board

One thing I’ve always found annoying when working with DB9s is that the staggered pins makes them incompatible with matrix board.  The simplest solution has always been to just put the DB9 on the end of a cable, and either solder the cable directly to the board, or use a box header, which has parallel rows of pins.

A few days ago I was hit with a flash of inspiration – and now I can’t believe I didn’t think of this solution sooner! Continue reading

Slow progress, but progress nonetheless!

I’ve recently pushed some changed to the TG68MiniSOC Github repo at https://github.com/robinsonb5/TG68_MiniSOC.  Changes this time round include:

  • increasing the system clock frequency to 133MHz.  In order to do this I had to add some wait states to the processor, but the increase in RAM bandwidth makes it worthwhile.
  • Adding some more robust filtering to the PS/2 clock signals.  At the faster clock speed I was finding that the mouse and keyboard were misbehaving – it appeared as though there were spurious clock edges causing the receiver to get a bit or two out of sync with the keyboard and mouse.  After trying various tweaks to the PS/2 module’s parameters with no success, I tried running the PS/2 clock signals through the debouncer I mentioned in the post about latching power circuits – and that seems to work like a charm.
  • Since two of the target platforms have 32 meg of RAM, and since I now have a Platform Specific register the firmware can read to query how much RAM is present, I’ve moved the base address of the hardware registers.  Previously they were at 0x800000, which is 8 megabytes into the address space.  This works out nicely on the DE1 which only has 8 meg of RAM, but on the Chameleon and CIII board the base address needs to be above 32 meg.  So I’ve changed it to 0x80000000 – or 2GB.  Chances are I’m not going to encounter an FPGA dev board with more than 2 gig of RAM! Continue reading

Experimenting with TG68

Part 11 – porting to the Turbo Chameleon 64

After porting the Minimig core to my ebay-acquired Cyclone III board, I’ve spent some time this week porting the MiniSOC project to the Turbo Chameleon 64.

Hardware-wise the TC64 is very similar to the CIII board – the FPGA is identical, and there’s the same amount of SDRAM – albeit with a slightly different layout – so porting projects from one to the other is fairly straightforward.  The only complicated part is routing certain signals through a CPLD which is used in the TC64 to multiplex some of the IOs, and as a bonus, to provide 5v tolerance.  This is taken care of in the Chameleon-specific toplevel, meaning once again that the same basic source tree can be built for DE1, the CIII board and now also the Turbo Chameleon 64. Continue reading

New Amiga games in 2012? Yes indeed!

When I returned to the Amiga scene about a year ago I was amazed to see just how much interest and development there is for retro systems  –  it appears I’m far from alone in believing that computers took a wrong turn back in the 90s!

New games are still being written for a wide variety of retro platforms, and the Amiga is no exception.  Spotting the need for a central hub to highlight new releases, Robert Hazelby has just started a new Blog – Amiga Gamer.  If you’re interested in hearing about new Amiga releases, be sure to check it out.

The Minimig core in action

I needed a bit of a break from wrestling with timing constraints and trying to figure out how to make the core stable from build to build, so figured I’d make a video of the Minimig core in action.  This is the first time I’ve used this particular camcorder, so forgive the shaky camerawork!