I found the source of my Minimig-core problems – one was a misrouting of the SD-card’s chip select signal, and the other was interference from the Action Replay module, which isn’t usable with this version of the core anyway, so I’ve simply disabled it.

The core itself now runs very nicely on the C3 board, with the same basic feature set as the Chameleon core:  On top of the normal Minimig feature set, thanks to the efforts of Tobias Gubener it supports 68020-compatible soft processor, and up to 8 meg of Fast RAM.  My own tweaks to the OSD firmware added support for WinUAE-style HDFs and direct SD card access as well as some other minor tweaks.

There are plenty of further tweaks to be made and problems to solve, but after the frustrations of trying to get it working a few days ago, it’s nice to be able to play some Amiga games on it today!

Here’s Syndicate (courtesy of WHDLoad)

And the workbench from my old A4000, running from an SD card partition.

(The original was DblNTSC.  Interesting that PAL Hi Res should look good on a widescreen monitor!)

Full source and bitstream files for the core are available for download here.

So Close!

Here’s my Cyclone III board nearly running the Minimig core.  For it to be getting as far as this error message means it’s correctly loading and running the OSD firmware from the SD card.  I just have some SPI bugs to iron out, but after that I hope it’ll actually run, and then I can figure out how to give the emulated Amiga access to more of the 32 meg of RAM this board contains.

What will be very interesting is to see whether this version suffers from the same build-to-build stability problems that plague the Chameleon port of the core (since hardware-wise it’s almost identical).  Once again, my ultimate goal is to have multiple ports of the core buildable from a single source tree.

Experimenting with TG68

Part 10 – Multiple Boards

Now my A/V and power boards are built and working, I want to run the TG68 MiniSOC project on the Ebay-sourced Cyclone III board.  Rather than just port the project to the new board and then neglect the DE1, what I’ve done this time around is to make a single source tree usable with both the DE1 and C3 boards.

In order to keep things straight, I’ve adopted the following directory structure:

  • RTL – modules belonging to the project itself, and which can be used on either board
  • C3BoardRTL – toplevel and support modules specific to the Cyclone III board
  • C3BoardRTL/Generated – Megafunctions specific to the Cyclone III board, such as the PLL module, BootROM and Character RAM.
  • C3BoardProject – The Quartus project file and the generated .sof / .pof files end up here.
  • DE1RTL – toplevel and support modules specific to the DE1 board.
  • DE1RTL/Generated – PLL, BootROM, CharRAM, etc.
  • DE1Project – The Quartus project file, etc.

At some stage I shall add port the project to the Turbo Chameleon 64, too, and have a third platform buildable from the same source tree.

There are three other noteworthy developments since last time:

Firstly, I finally received the Max3232 chip I was waiting for, so the power board now sports an RS232 serial port, tested and working.

Secondly, as well as receiving an S-record over the serial port, the boot firmware can now load a program (again in S-record format) directly from an SD card.  If you want to try it out, just copy the file CFirmware/out.srec to the root of the SD card, and rename it to “boot.sre”.  As before, you’ll want test.img on the SD card too.

Finally, since my A/V board supports 6-bit per gun video output and the DE1 only supports 4, I’ve moved the dithering out of the vga controller and into a generic module which is instantiated by the board-specific toplevels.  A generic parameter sets the number of available bits per pixel and adjusts the dithering accordingly.

Full source is available, as always, for anyone who might be interested:

I also promised in my last post to release the Eagle files for the VGA board once I’d tested the PS/2 sockets, so again, for anyone who might be interested:

A custom VGA output board

The Cyclone III board I’m using has a nice roomy EP3C25 FPGA with about 25,000 logic elements and 32 meg of SDRAM, but is rather lacking in ports for talking to the outside world.  I plan to add an RS232 serial port to the power board which featured in my last post, just as soon as I receive the requisite components.

The power board connects to the two least useful of the board’s GPIO headers; most of the IOs on these headers are used up by the SDRAM, but the other two GPIOs are almost fully functional.  (On the EP3C16 version of the board, all 36 IOs on these headers are available – but the EP3C25 needs more power pins, so a few of the IOs are unavailable to me.)

In approximate order of importance, the ports I want to add to this project are:

  • VGA
  • PS/2 keyboard and mouse
  • Audio
  • SD card
  • Joystick (9-pin DSub, Atari/Amiga style)
  • Ethernet – if at all possible.

The VGA port requires three individual resistor ladder DACs, which means a fairly high component count, so I wasn’t keen to try building this particular interface on stripboard.  Therefore I decided to try having a custom PCB made.

I used the freeware edition of Eagle to produce the schematic of my board and lay it down, and learned a great deal in the process.  Since including just the VGA port would have been a waste of the remaining pins on the header, I also included the PS/2 ports and audio port on this board (using the DE1 and Minimig schematics as reference).

I made a few mistakes in the process, which I shall avoid next time!  Most importantly, I wasn’t entirely clear about which side of the board was which.  I now know that by default components placed in Eagle are assumed to be on the top layer of the board, with through-hole components being soldered at the back – but I routed the traces on the top layer, intending to treat that as the solder-side and place the components on the other side.  I’d correctly flipped the components to deal with this, but it confused the PCB fab house and delayed things a little.  What I should have done was place everything the right way round, then route the traces onto layer 16 (the back of the board) instead of layer 1.

I used Futurlec to make the PCBs; they seem to be the most affordable option for a hobbyist who only wants a couple of boards.  Because I’d opted for the cheapest shipping method, the boards took a couple of weeks to arrive, but I received them on Friday, and have almost finished populating the first one!

This board attaches to J1 on the FPGA board, and provides a 6-bit resistor ladder for each colour, giving a theoretical 262,144 colours without dithering.

I haven’t yet tested the PS/2 sockets, since I’m waiting for a delivery of the right value of resistor to complete the board – but once it’s verified as working I’ll make the Eagle files available for download.

The 6-bit resistor ladder probably deserves some explanation, since it was an interesting problem to solve.  The VGA specification says that the maximum voltage on the R, G and B pins should be 0.7v, and the load on these pins (i.e. the monitor) should have an impedance of 75 ohms.  The FPGA either drives each pin to +3.3v or to gnd, so the FPGA, the resistor ladder and the load form a complicated potential divider.

Since it’s non-trivial to calculate the voltage produced for an arbitrary input to the resistor ladder, I created a spreadsheet to do the job, and found a combination of standard value resistors that would give a maximum value very close to 0.7v.

The spreadsheet, in case anyone’s interested, can be found here.

The resistor values I settled on were:

  • 525R (formed with a 1K and 1K1 in parallel – which, yes I know, adds a large potential error where you want it least, but also gives you scope to trim that error by swapping resistors in the hope of finding a good match.)
  • 1K1
  • 2K2
  • 4K3
  • 9K1
  • 18K

So does it work?  As always, a picture speaks a thousand words: