TG68 - The Open Source Minimig CPU into the FPGA

[freqmax]

@Dennis:
What do you think Minimig2 should contain?

(btw, do you happen to have the appropiate *.ut and *.xst files for Minimig?)

[freqmax]

@Belial6:
Or you could use: http://www.xess.com/prod035.php3

Which have 2,5 times logic array of XC3S400. Should be enough for Minimig + MC68000. Builtin PS/2 port, VGA, RAM.
MMC interface, Sound etc.. can be added with some very simple circuit to the prototyping header.

[freqmax]

You could always cut a board to allow screwing a smaller board  into it. And then attach the larger board to the case.

If the VGA port is insufficient, there's always the possibility to add to the expansion header instead.

Xilinx have Linux development enviroment. And license is alright.

[freqmax]

@amigadave:
The board doesn't have lines to display *all* colours of the Amiga. Ie max 512 colours.
But this doesn't prevent it from running minimig. And should more fance colouring scheme be desired. One can always add something on the prototyping header. With throughhole stuff (easier).
The important thing is that it has onboard RAM (32M) and that now when the cpu + custom circuits can all be done in HDL. All the messy SMD soldering can be done away with.

[freqmax]

There's also this alternative:
http://www.enterpoint.co.uk/moelbryn/darnaw1.html
(140 USD, 110 EUR)

Then add a through hole accessory board with:
 * Video out (VGA/SCART)
 * Audio  
 * Joystick
 * Flashmemory card
 * Keyboard (PS/2)
 * RS232
 * +5V and +3,3V regulators

And it will do the same as a Minimig1 provided the softcpu and sdram interface is up to the task.

[freqmax]

For development purposes a real MC68020 plus 5V<->3.3V interface would be useful. Since you can then run the softcore  "68020" and the real thing in parallel executing the same instructions.
Then trigger points within the code can catch any anomalities. And the transactions causeing it can be logged.

Also what benefits does 68060 have over 68020 that really makes a practical difference from a functional view?, as the ballgame becomes different when you can do things in HDL.

Is there anyone that could make a realistic estimate of the FPGA capacity needed for AGA ..? (diesize x nm process), to nail weather it's feasable or have to be postponed for years until logic capacity goes down in price.

I did an rough estimate in Oct-2005 on the number of gates in the Amiga using the pictures of Lorraine#1 #2. By using the average number of gates in 74xx logic chips say 60 gates x 30 rows x 5 columns x 15 boards = 135000 gates.

[freqmax]

Guess the 2 instructions in parallel can be achived with some instruction decode pipeline?

[freqmax]

One could call it configuration file, design file, HDL files etc..

Regarding 68020, is it mainly the 32bit capability that is needed/wanted from a 68000->68020 upgrade?
In such case maybe a hybrid solution where the HDL 68000 is made 32-bit capable is an easier and faster approach to accomplish any 68020 needs?

Other factors are ofcourse FPU, and MMU. I know MMU is used by unix operating systems. But for anything else are these things really used in the Amiga enviroment?

Trying to find a less burdensome upgrade path.

I also think any software emulate cpu will just like UAE have problems with latency.

[freqmax]

You can make it run more cores this way:
1) A coreselector is loaded and run just like "minimig1.bit" is now. Once this is running it will put up a fileselector. And any selected core will have it's filename written to a eeprom area in the PIC18.
2) The PIC18 will reset the FPGA by playing with the PROG, INIT_B etc.. signals. And load the core again, but now using the filename selected in eeprom.

So a two-stage loader could make it happen with current pcb layout.
The default action if no bitfile is selected is to start the "last one selected" within 5s or such.
One could also use a small file on the flashmemory for bitfile selection. Maybe that would be a more portable idea.

Regarding ethernet. What you will need is a PHY. And you will need to wire up RX_Clock, RX_Datavalid, RX_Error, RX_Data[3:0], TX_Clock, TX_Enable, TX_Error, TX_Data[3:0].
For 1 Gigabit mode an additional 4 more databits will be needed per direction (GMII). Possible you may need MCLK and MDATA to configure the PHY aswell, but the defaults seems alright. A minimal setup will be 12 IOs and a full at least 16 IOs.

[freqmax]

13 USD for another chip is a bit. Esp considering the FPGA is 25 USD..
I don't propose 1 Gbps for Minimig. But it might be easier to source those chips etc..
Because 10M ethernet can't be accomplished without external hw, and 10/100M chips are the slowest ones that exist. 10/100M is the best choice.

[freqmax]

What do you mean by frontpanel..?
Can't you use the FPGA to manipulate the m68k ..?

[freqmax]

Some Administrator, plz reisize or disable this huge picture..

@downix:
Ofcourse you can manipulate the m68k, simple connect to the jtag interface of fpga. Or even use any existing RS232. Or a planned 10/100M ethernet.

[freqmax]

@amigadave:
What do you mean by DCTV ..?

[freqmax]

@MiniMorph:
We'r missing Macintosh 68k, and Sun-3 :-D

[freqmax]

I think both Mac68k and Sun3 is quite simplistic in their design compared to Amiga. After all there's a reason for the fame of Amiga.

I think the linux sources for Mac/68k might be of interest.
68000 based macs:
http://en.wikipedia.org/wiki/Compact_Macintosh

Same for Sun-3.