MINIMIG HARDWARE COMPATIBILITY & NEW TURBO MODE!

[boing4000]

To the idea of using Spare-I/O as an ethernet port would require 4 wires (2 sender and 2 receiver lines). Spare-I/O only offers 3 Bit.

As in Dennis' schematics to find:
Pin 1-2 is permanent VCC = +3V3
Pin 3 Spare-I/O in/output User0
Pin 5 Spare-I/O in/output User1
Pin 7 Spare-I/O in/output User2
Pin 9 SPI_Dout (hardwired to PIC Pin 15)
Pin 4, 6, 8 and 10 is GND

For PAL60 question... Is the NTSC firmware not working as an real Amiga using NTSC Agnus? As far as I checkt it out, all software is running like on e.g. A500 with closed NTSC jumper near Agnus. Also almost every game and demo/intro/cracktro is able to work in NTSC (I did just a test, no real need for NTSC here).

[boing4000]

Its possible. The 15/31khz jumper is just another i/o line to the FPGA and can be reconfigured from input to output. Together with 3 Spare i/o line 4 wires are available. But it would be permanent to this core build! If once set to be an output the user can no longer change the frequence. Perhaps Jakub can also add the 15/31khz mode to the OSD :-)

Be aware that Minimig just have 1.5MB of available RAM and this will limit the TCP/IP apps to be used. Gegesis will take a lot of RAM to work, I tried it using an A1200 with 2MB Chipram and PCMCIA Nic with the famous NetBootDisk. After booting in CLI with genesis 577912 byte was already used by the TCP/IP Stack. No application was started, in Minimig would be a maximum of 917 kb free memory left.

I made some benchmarks on 14MHz version.
SysinfoV3.24 says Factor 1.77 vs A600 (using Kick 1.3)
An AIBB6.5 Minimig-Module is available here: Minimig14MHz.aibb

[boing4000]

Yes the line-test is very interesting, nearly at A1200/AGA speed.

@Jakub
I found out that maybe the DMA timing in your current firmware will switch to higher rate while writing on floppy. Tested with Kick1.3, playing .MOD file and formating a floppy disk using DosControl4. Each track writing the MOD run faster then it should. But no crash or something, also the floppy data was correct written.
In games it will not interfere until now. Tested with Pinbal-Dreams, Giana Sisters and Turrican-3.

[boing4000]

@Jakub
OK I was just wondering about that timer speedup in playing mod files. But it will not occur at all time, maybe in a special way from a few mod player routine. CIA timer are very stable and the internal DosControl modplayer is not affected by the disk writing.

Wow thats great news very nice to see that the 68k can run at that speed! Maybe you can let me know the changes so I can test it on my 16MHz designed SEC000. But I think it will also run at 28MHz.

Generic question... you are using the PIC internal eeprom to store the permanent OSD settings. Will the PIC also store the settings every time a reset is triggered and no change was done? I think the eeprom is in general a flash-rom and can also be written about a maximum of say 100.000 times each bit.
I limit the changes to a minimum, don't want to stress the single bits inside the PIC too much.
Therefor I would ask if you are planing to change CPU speed in OSD to let it non permanent. Startup could be 7.09MHz and by user change set to 14-28MHz. After any hardreset (power off) the core would set the speed back to standard.

What do you think about it?

[boing4000]

Hi Jakub,

I've just tested that implied player on real OCS A500 and it shows the same behavior as in Minimig! So no problem with DMA timing or whatever :-) *happy*

If you want to try it out, take a look at this image: AMEGAPck.adf
Let it boot and choose any mod file. Change floppy image while guru-message. LMB to reset and boot workbench (or doscontrol) to format any other floppy image. Real Amiga500 just freeze in 2nd formating. Music is still playing ;-)

Then I'm satisfied that PIC eeprom will take the changes for a long time!

[boing4000]

Something different... Maybe I found a bug in the current core (copper) by running the demo "Rampage  by The Electronic Knights". The demo freeze shortly after the beginning and only show a wild flickering chipram bitmap.

Using e-uae in Linux give a clue what possibly went wrong:
"Program uses Copper SKIP instruction." --> Minimig freeze here
"B-Trap ffec at 00038066 (0xb4ee206e)" --> e-uae freeze here

Even e-uae freeze but after the point of Minimig. I think this demo is hacking the custom chips to its limit or at least in an extraordinary way.

@Jakub
perhaps you find some time to take a look at :-)

[boing4000]

Yeah, I call that a mini Minimig ;-) Nice work!

Additional info for Jakub:
Turrican-1 is unable to write its highscore to floppy. Floppy image is writeable. Here is the PIC debug dump:

Code: [Select]


Inserting floppy: "TURRIC1 ADF", attributes: 20
drive status: 03
*44:0:99E0-97C4->1:97C3-95A4->2:95A3-9384->3:9383-9164->4:9163-8F44->5:8F43-8D24->
6:8D23-8B04->7:8B03-88E4->8:88E3-86C4->9:86C3-84A4->A:84A3-8284+++->0:81C5-0000->1:0000:OK
*1:
#SYNC:
Second sync word missing...
WriteTrack: error 21
#SYNC:T44S0
WriteTrack: error 27

I hope this will help a bit to find the reason :-)

EDIT:
Just found out that e-uae also have problems in this matter:

Code: [Select]


Disk decode: checksum error on sector 1 header
Disk decode: weird sector number 18
or
Disk decode: checksum error on sector 10 header
Disk decode: weird sector number 70

This message appears in attempt to write highscore to the same adf image.
Perhaps my image is damaged, it would be helpful if anyone else could try this.

[boing4000]

This could work but require a fullscreen framebuffer in the onboard memory. The FPGA is not capable of doing this inside. Also the already limited amount of s-ram will shrink again.