Using C64 Core on MiniMig boards.

[alexh]

There are several open-sauce FPGA cores which work (i.e. fit) on MiniMig v1.1

CPC-TREX
FPGA-64 v0.27
A few Arcade games
MSX II
Sinclair Spectrum
ZX80/ZX81

These are just a few I've played with over the months. With the exception of CPC-TREX (which is written in AHDL and needed converting) all were easy to add a MiniMig I/O wrapper.

Although I never tried it there is also an Atari ST in the form of Suska which should fit although may need a different xtal.

The SD Card I/O and the PIC is harder ;-)

I'll happily walk someone through the process if anyone feels like being a MiniMig HDL coder?

[alexh]

It kinda sucks to have to swap SD card just to boot different cores :-)

It is easily possible but why? What is wrong with the One SD card = one core (plus all the games). I see no problem at all? Especially as 2Gig SD cards are £3.50 each at Tesco! This is certainly a feature request to put at the bottom of the to-do pile.

What is more-likely to suck is that there is very little scope in the PIC for multi-platform support and in my experiments I had to re-program the PIC using the serial cable between cores. (But I wasn't really trying to get a single all-singing all-dancing PIC)

[alexh]

Palm wrote:
Would it be possible to use the core of a C64DTV if it could be extracted somehow

It cannot be extracted. Why not? It's a modern ASIC which was synthesised from HDL and then flattened and implemented using deep submicron technology. Even if you took xray photos of the DIE you'd never work out what was going on. You can extract the information from the much older original C64 ASIC's because they were created by hand in the form of schematics using a much larger technologies making the DIE's almost human readable.

If you knew the C64DTV developers and could get a copy of the HDL source code they used then sure. (But I doubt you'd be able to get them to part with it legally)

But I feel that C64 HDL development has moved on since the C64DTV and the C64DTV was under some price constraints so they had to leave out several seldom used original C64 features.

[alexh]

Quick n dirty ports are very easy. You can usually have something on the screen in 20 minutes. For Spectrum you can create the port very quickly because it was written very well. Add the MiniMig I/O wrapper for CLOCKS, RAM/ROM, VGA, Joystick and keyboard and combine the ROM and an SNA file to replace KICK.ROM. A few pokes and an RUSR and you're playing the game. Not particularly user friendly as it is only one game per SDCARD ;-)

To get it to work better you need a replacement OS or HDL to replicated either the Disciple or +3 interfaces.

Like most things it's no fun once you've got it working a little bit. It becomes "work" to get it that next bit further, at least to me.

[alexh]

boing4000 wrote:
The current PIC (or ARM board) should be able to handle different core files and the extension of disk files (i.e. .adf, .d64, .st etc.). Its also possible to rename all files in .adf as long as the sector size is still 512 byte per block. That would not require different PIC version or bit changes in its firmware, since there is no much space left.

But that's just it, AFAIK they are not the same (although I've never tried)

AMSTRAD / Spectrum +3 DSK format for example has different possible sector sizes and non are the same as Amiga ADF.

However I'm not sure for MiniMig how much of the disk image file access is inside the PIC and how much is inside the FPGA. If all the track/sector handling is inside the FPGA and it just requests data from the PIC as an offset within the file then it should be possible to use the existing PIC (at least for reads).

[alexh]

As I said, doing the initial port is the easy and fun bit. Getting it to be usable is the hard and boring bit.

[alexh]

Palm wrote:
Why not just D64 support from SDIO card ?

Cos it's a load of extra work that's why!

And it's not simple interface logic & wiring work (like porting the core) it's lots of reading about the different image formats, disk drive interfaces, reverse engineering the current FPGA-PIC interface, remembering how to write PIC programs etc. etc.

While you get a big pointer in the right direction cos most cores already done something similar, trying to come up with something that will fit in just makes your head spin.

Once you've got stuff on the screen, interest goes away fast. Plus the FPGA Synthesis & Mapping is not a quick process by any means. Waiting becomes a regular part of your debug, especially as you start uploading PIC firmware via serial.

If there is enough interest and people start posting their source codes (as they are required to) and a dialogue between developers opens then maybe things will accelerate fast. I dunno if you've been reading but there is a distinct lack of technical discussions about FPGA programming and MiniMig here on Amiga.org I just put it down to everyone here being "users" and no-one being interested.

All that said, nothing gets your interest in a project going again faster than competition and collaboration.

[alexh]

Palm wrote:
So, if most "users" out here cannot contribute in a technical way of bringing the development progress fast forwarding, how about if we give out bounties instead ?

The amounts of money involved in these bounties are inconsequential. If it was about money we'd do another few hours of contracting instead ;-)

I'm telling you, as soon as a few engineers start posting their source code, talking about technical problems, goading others to solve them and help out, the projects will start flowing.

At the moment active developers are Tobiflex and Yaqube and RedSkull and they keep their cards pretty much to themselves (either that or they are on another forum?) and I think they have all moved away from the MiniMig 1.1 PCB.

[alexh]

Palm wrote:
Can I use my MiniMig board as a test-board?

Of course. The FPGA image lives on the SD card. You make a new one on the PC with the Xilinx tools, transfer it to the SD card and pop it in MiniMig.

[alexh]

I am not 100% familiar with Yaqube's PIC updates but originally the FPGA image file must be named "MINIMIG1.BIN" and the file to be preloaded into SRAM must be "KICK.ROM" and I think it had to be padded to 512Kbytes but I'm not too sure about that.

[alexh]

yaqube wrote:
The Minimig FPGA file contains a ROM with bootloader for the external 68000 CPU. This bootloader uses Amiga floppy DMA controller to talk to the PIC. The PIC sends an Amiga ROM file which is received by disk DMA and put in the RAM buffer. Then the 68K CPU copies it to the specified location.

Interesting... I do remember something about this... I dont remember it being like you describe (it's complicated, and I'm not one for complicated) but you are the master at this subject. So what did I do?

There is certainly not enough RAM in the FPGA to implement 16Kbytes (let alone 48Kbytes)... I'll have to look back at it see what I did...

[alexh]

I did try on that for a few nights when I got my MiniMig. Tobiflex's excellent TREX CPC is written in AHDL which is a language specifically for Altera FPGA devices. You CAN convert to VHDL/Verilog using tools but they are buggy and produce non-human readable code (plus all the comments go).

Might be worth looking at once more.

[alexh]

yaqube wrote:
The XC3S400 has 16 RAM blocks of 18K bits each. It gives you 32KB of RAM.

Yeah, not quite enough to load 48k ZX Spectrum RAM snapshots via the FPGA IMAGE loading mechanism built into MiniMig's PIC.

Which means :

I never loaded any games (I'm almost sure I did)
I used 16k interface 2 ROM's (Horace goes skiing, PSSST, TransAM etc.) or
I did something else involving the PIC and loading from SD (unlikely as at first my PIC didn't have a bootloader).

[alexh]

I thought that Yaqube's latest MiniMig sources included some sort of filter? Dunno how easy it would be to adapt, credited of course. Some of the more easy filters should be simple to implement from scratch especially having more free space in the FPGA than with an Amiga core.

[alexh]

At this rate you'll have a release ready in no time ;-)