Minimig Discussion Forum

Hi,

I was thinking a bit about alternate cores on Minimig board and here is idea that I'm thinking of.
Minimig has MC68K and PIC or ARM.

For emulating C64 or Spectrum, MC68K would be Idle but we can't really emulate floppy because requires extensive changes on PIC or ARM core.

Idea I'm having is to enable FPGA core bootrom to load file through PIC or ARM.
This would enable us to load emulated platfom roms instead compiling them into FPGA.
To to achieve this we would need new bootrom in selected core and new command for PIC or ARM

When boot is finished FPGA is reset and it is running target emulation.

Since now MC68K is free it would be wise to use it to emulate external devices for other core.
Similar to C-One project where one extra MC68K is added just to run Minimig OSD and Menus, ARM controller C source is compiled using Dice C on Amiga.

So here is how would boot process look like.
1.) FPGA Core is loaded
2.) Boot rom is started
3.) Target Platform ROMs loaded in RAM through PIC or ARM core
4.) Target Platform OSD, Menus and disk/tape emulation loaded in RAM
5.) Core is reset and Emulation is started

What needs to be done:
1.) Enable PIC/ARM to send file on request to FPGA
2.) Enable PIC/ARM to load different FPGA core through menus
3.) Recompile current PIC/ARM menus using Dice C on Amiga to be useful on other core.

What would be gain of all this.
1.) We could distribute core and sources open source
2.) Each user could put their own ROMs of target device on its own SD/MMC card and we would not distribute illegal stuff
3.) Not including ROM on FPGA would save us FPGA space

Anyway I need to check minimig schematic to see if it is possible to do it as described e.g. if SD/MMC card is wired to FPGA in a way that it can be used directly without PIC/ARM support (after target emulation is started).
There also might be some other issues preventing this to work as described that I don't know.

What do you think about this concept?

Quille

Your idea is totally welcome! This would make Minimig bcp even more interesting for other ppl.

Also the idea using PIC/ARM to handle rom image upload is very nice, it would indeed release much of FPGA space and copyright issue
Unfortunately Im not able to do this kind of adaption in HDL or even PIC/ARM code but would be very happy to see it working!

Its almost nice to even impress ppl. to let run an Amiga and in next step a whole VIC20/C64 on the same nice little platform
Please give it a try, I will assist in any possible way.

Yes, I second this idea. Would be cool!!


Espen

@quille

Good luck with your research, I have been hoping that something like that would be possible since I first got my minimig.

I would really love to have a ZX Spectrum, C64 or Atari core for my minimig that I could select at boot time, and I am sure their are a number of other systems that could be recreated using the Minimig hardware if it could be made to select which core to run a boot time, without having to manually reflash the PIC or ARM controller board.

I know that no other cores are widely available at present for the Minimig but until it is easier to change which core you are running I can not see that changing.

Jan D. made a multi-core PIC firmware some time ago. It was very useful since any *.bin file could be select and load in OSD menu without swapping sd-card. This methode could also work in current ARM and PIC core/firmware, it just require a bit more program space. Im not sure if it still will fit in Quille's PIC release since it almost fill out the MCU flash memory.

Also one have to check Jan's firmware source to know how to engage OSD in bootloader picture. I guess he just trigger the OSD as soon as FPGA was started. Would be great to have this kind of chioce back in current firmware
But until now there only is a very few alternative core available. Also those core are unable to use neither PIC or ARM feature. FPGA64 and VIC20 core is running for themself and depend on external IEC device like real 1541 floppy drive.

Hi,

I was away for a while so no minimig development, started to work after hollidays and got huge pile of bugs and issues to resolve. Anyway I'm returning to normal now.
I have installed xilinx web pack, managed to compile minimig core read few tutorials so I can start learning.
I'll try to finish/quit this weekend HDD multi block transfer for pic firmware so I can start new cycle of development.
First order of work will be loading alternate core through menus, I was checking Jan D. source allready to see how he didi't.

I was looking for spectrum fpga core but I couldn't find any sources, my idea was to start with spectrum because there is ResiDos and supports loading stuff from SD/MMC card but unfortunately looks like that there is no VHDL/verilog sources available for SD/MMC HW like http://www.zxbada.bbk.org/zxmmc/

My idea was to load spectrum core and roms and spectrum core could take over loading software from sd/mmc using residos and zxmmc.

That was idea at least I'll see how it goes

So if you have more info about zx spectum FPGA sources or other retro computer leave links here

Welcome back

Nice idea to handle alternative core also in current PIC firmware!

I have a clue in my mind to spare special MCU coding for alternative core:
At first normal Minimig core will start-up. Then choose "alternative core" in OSD out of a special named folder like "ZX-Spectrum" or "VIC20"... MCU now will return into rom-upload routine and pick "kick.rom" out of this folder. This file will contain i.e. the spectrum rom image (file still has to be 256/512kb in size). After that the actually alternative FPGA core will be load and engaged. This core must access s-ram at same address as prev. kick.rom image was load (in Amiga terms: $F80000).
Also this alternative core must be able to access SPI bus. Inside the special folder there also will be .adf image in name, but inside this image would be data matching just loaded core image format like .d64 or .<zxs>.

The "kick.rom" also could be stored as now in sd-card root, named vic20.rom, spectrum.rom etc. It would not even require changing of ROM upload routine.

Its a bit tricky but will not require much special handling inside the MCU.

Here are sources for a Spectrum 128 FPGA Core.

http://alexfreed.com/FPGApple/DE1_ZX/

Some Info about a 48K Core
http://zxgate.sourceforge.net/

If you´re interested i could send you the zxgate files.

Dirk Thanks!

Please send me zxgate also, I was checking sourceforge but I couldn't download source but I really need to install some CSV client since I only have SVN currently.

Regarding alternate cores here is progress so far:
I' can't fit in original pic with HDD multi block transfer and alternate core loading together so I have added few defines to enable/disable each feature.

Multi block transfer is still not finished only HDD code is reorganised a bit to allow it.

However, due to my curiosity, I have added menu loading of alternate core and currently I was trying with VIC20 core.

I'm still having issues loading alternate core, so any help would be appreciated.
Here is what is happening:
1.) When I try to load core, function fails to get INIT_B high so programming can't be started.
2.) I have analyzed JanD. code a bit and noticed that he is using this sequence prior to sending FPGA data.


I'm using only:


When I add:


I have managed to load VIC20 core only once and reset on minimig fails to reload original core.
So I can only assume that core programming sequence is wrong for reprogramming FPGA and somehow works after pic reset.

JanD also says in his comments:


I suspect this is related to core itself and mapping pins to avoid SPI operation interference.

I have uploaded code to trunk, if anyone wishes to take a look, It will fail to load core but rest works fine.
I'm going to investigate this further...

Boing4000 I like the idea in general but c64 and vic20 have 3 different rom files at least 3 parts.
There is also issue of loading of cartridge roms like RESIDos for spectrum etc.

So I'm considering to take Minimg parts like Bootrom, OSD display, SPI ,Keyboard etc and make this as part of any other core so bootrom can take over handling complex scenarios like rom loading etc, I would also need to tako part of floppy and display adapters too.

But this part of verilog should be small as possible for us to be able to fit in other cores but this would always be part of any core developed for minimig.

I'm still light years away from it but I'm learning and having fun , but one step at the time.

Quille

Thats all right!
Even with Jan' PIC firmware Minimig board is unable to re-load the original core if the VIC20 core is active.
With FPGA64 it works because this one handle SPI data line in different ways.
In general the alternative core must handle SPI right to allow propper PGM-reset.