Using C64 Core on MiniMig boards.

[mikej]

Peter's C64 core has already been ported and runs on my standard Spartan3e board (we have been chatting for a while). I haven't released the port on fpgaarcade as I'm waiting to include a highly accurate SID port - and it needs the DDR RAM controller which is not quite finished yet. The Replay (fpgaarcade) dev board will run multiple cores out of the box, including my VIC-20 core (also available on C-one) and my ST core.

There is no reason Peter's core would not run on the original Minimig board. You just need to change to top level wrapper file to get the correct IOs. It would also need some work to get the tape or cartridge interface to talk to the SPI connection to the SD card.

More info is available on the SID and VIC2 chips thanks to Michael's very impressing IC die scans :
http://mail.lipsia.de/~enigma/neu/6581.html

/Mike

[mikej]

probably. We have been working on the code for the Atari Jaguar and un-released Atari Jaguar2 for a while.....

[mikej]

The FpgaArcade (now called Replay) board has the following :

Large Spartan3E device (1200). 3x minimig size
Expansion connector for real processor or other IO (like a real SID) / Ethernet. 68K daughter board already designed to test the 68K soft core. I can't remember the exact number, but it's got about 100 IO pins and another 30 odd input only pins plus some clocks and power on the expansion connector.

ARM micro controller for hardfile support + USB.

24 bit DVI(HDMI) output + analogue output.
Good quality Wolfson audio DAC.
32 MByte memory.

SVHS/Composite video (on tiny expansion board)

small form factor (17cm x 8cm) and fits in an ITX case.
External input connectors for wiring joysticks / buttons up in an arcade machine.

It has been a long time in development, as I keep adding bits to it. It was completely finished and ready to be manufactured before we decided to move from the AVR to the ARM controller. Should be done in another week. Price is unknown but will become clearer once I get the first batch made.

The reason I designed this board was so I can run the game cores I develop. I did the vic-20 core used on C-one and I have a cycle accurate ST chipset. I also debugged and maintain the T65 and T80 CPUs used in a lot of projects.

Any board is only as good as the software and firmware support - without this it doesn't do much. I'm an FPGA engineer, so I will continue to support the Amiga and other cores on this platform. Other people can continue to port them to other boards if they wish. Most of the emails I get are people having problems getting things to work on other boards, so having one "reference" board will from my point of view save me a lot of time.

What it will do is boot multiple environments from the OSD menu. An environment includes ROMs and the FPGA image. The ROM files are copied over to the memory at startup. You can then select a run-time image, either a floppy or later a hardfile image the FPGA can access while it is running.

My aim for platforms (initially) :
(working code exists for all of these on my other boards)

Amiga A500 - Minimig core + Mike memory controller
Atari ST - Mike + Wolfgang)
Vic20 - Mike
C64 - Peter + Mike SID
Spectrum
BBC B
Bally Astrocade
+few others

Pacman / Pengo
Frogger / Scramble
Defender
Asteroids
StarWars
Spaceinvaders


/Mike

[mikej]

Palm,
well, I'll say it before anybody else does - I would wait until you see pricing and the board is up and running and available for shipping.

We could hit some snag before then, but I hope not.

As the boards get more features porting the code between them does get more difficult. The integration with the micro controller is also a big deal - hence the last minute change to the ARM.

/Mike

[mikej]

Yes. I have changed to the same controller to make sharing code easier.
/Mike

[mikej]

"C64, Spectrum and Atari ST Cores, let's make sure the Minimig as it is gets fully supported and fully used.

Then, all together, we can provide an updated version which can offer more."

I actually agree, that's why I have been using the Xilinx Spartan3e "standard" board for ages. However, I really want a board with the features I want - so I designed one. That is the one I will support from now on, it just takes too much time to do multiple ports. I feel the current minimig board is too feature limited.

To answer some other questions I have been getting, the Replay board will only be available fully assembled and tested - it's not easy to build by hand even with professional tools.

/Mike

[mikej]

I'm using my own DDR controller, I was not happy with the Xilinx one - and there are complications with me re-releasing the code for it.

You can run in internal block RAM to play with it, download the code from Peter's website, change the UCF and it just worked.

Mail me at the fpgaarcade address and I can send you the wrapper files for the internal RAM version if you need.

/Mike

[mikej]

I quite like the idea of a Hardware Abstraction Layer, for, um, hardware

I try and do this already to an extent. The game cores have a pixel clock input and pins like "button_a" etc. A top level wrapper file maps this to the FPGA IO pins and sorts out any interfacing and board/clock issues.

However, as often as not, IO interfaces require core changes to make them work, for example the DRAM controller on my board is separate from the main design. You could easily write an SRAM controller which did the same sort of thing for a different board, but that requires a good understanding of what exactly it does and then you have to verify it. Sometimes it's much easier to make the changes in the core, which breaks the whole idea.

/Mike

[mikej]

Peter's original code is available here :

http://www.syntiac.com/fpga64.html

I currently still use ISE 9.2 service pack3 as it, well, works. ISE 10.1 is probably ok but I don't trust new Xilinx software as a general rule.

Webpack is ok for the Spartan3.
http://www.xilinx.com/ise/logic_design_prod/webpack.htm

I don't use the GUI, I provide a batch file which runs the tools. You can practice on my VIC-20 core.
Download,
replace the dummy ROMs with real ROMs in \roms directory
run build_roms.bat (produces VHDL ROM files)
run build_xst.bat

.bit file produced.

You can then modify the .prj and .scr files for the C64 files.
/Mike

[mikej]

"BTW: Above, you write ".bit file produced". Do you mean ".bin file" (as in, the file I can rename to minimig1.bin and boot up at the minimig) ?"

A .bit file is produced automatically - it contains a header with some extra info in. If you add the options to bitgen -Binary Yes (from memory so might be wrong) then the tool will produce a .bin file which is just the configuration data. That's what you need for the SD card.

There is something called a parallel cable 4 which runs a lot faster than the basic parallel configuration cable and is cheaper than the USB one - although not as fast. I found somebody making a clone of the Xilinx USB cable really cheap but I can't remember where I saw it. Probably in China.

/Mike