MINIMIG HARDWARE COMPATIBILITY & NEW TURBO MODE!

[Darrin]

mahen wrote:
Any news about a possible PAL 60 Hz hacked build ?

Not yet.  Yaqube is a bit busy moving house at the moment (I believe).

[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).

[Belial6]

Ok, so does that put using something like the PIC18F67J60 back as the beast way to expand the MiniMig?  Or is there a simpler way to get Ethernet down to 3 or less data pins?

[wolfchild]

May I suggest looking into the ENC28J60, connected to the expansion header?  Or something like this: EXTERNAL LINK

Maybe someone with good HDL programming skills could add an SPI block for the expansion header and implement a memory mapped SPI interface, accessible from the Amiga software side.

As for the PIC18F67J60, it seems like a PIC and ENC28J60 in one chip.  Personally I see the PIC as a bottleneck performance wise, and would tend to prefer an alternative processor, paired with a separate Ethernet controller chip.  An ARM7, like Yaqube is using would be the best way forward.

[Belial6]

Whatever gets Ethernet on the MiniMig with the smallest hardware investment possible.  I just want to see Ethernet combined with the virtualization of ports over that Ethernet connection.

Can SPI be done on the pins left on the header?

Boing400 said:

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

That only leaves 3 data pins, and SPI appears to need 3 + one enable line for each device.  So, 4 for Ethernet.  Although, pin 9 being for SPI_Dout and hardwired to PIC Pin 15, implies that SPI is already implemented.  Does that mean we only need 1 of the User pins?

If the problem with that is that the three non-Enable lines are not exposed to the expansion header, then perhaps it would behoove us to try and talk Yaqube into exposing them from his board, as Pin 9 being PSI_Dout, implies that SPI lines have been run to the PIC socket that Yaqube will be plugging his board into.

[freqmax]

P-p-please skip the Ethernet-over-SPI thing. It's not needed and any solution using this approach will have a severe bottleneck in its path. Add the complexity of getting the ether-spi chip do the right things. And every manufacturer have their own setup..

The FPGA can do all ethernet stuff you can ever dream of. The only reason to use the MCU for ethernet is lack of i/o on the FPGA.

If there's got to be more chips. It's way more useful to have another FPGA + Ethernet_PHY rather than a more complex MCU with a lot of support chips.

Another idea came up.. maybe the NTSC/PAL, 15/31 kHz switches can be made as configuration bits on the SD-flashcard ..?

[Belial6]

So, Boing4000 says there are not enough pins.  You say there are?  Are you suggesting that the 15/31 kHz pins could be repurposed to give us the pins we need?

Would this allow us to do a simple cheap network upgrade?

[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

[freqmax]

Time for writing a more optimized tcp/ip stack...

[mahen]

Something as simple as an IRC client would be amazing. Some IRC servers provide gateways for all IM services. Would be amazing not to start a 3 Ghz computer just to chat

BTW, OT : did anyone try to hook up their minimig to a regular 15 Khz TV ?

Personally I think I will use the minimig to write reports etc. as plain text files. Usually when I write something on my computer I can't help checking thousands of things on the web. In the end, I waste 90% of the time

[Dwyloc]

boing4000 wrote:
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

Cool it nice to have the comparison as it helps to give a better idea of how powerful a minimig would be with hard disk emulation.

The answer being some were between an A600 and an unexpanded A1200 without AGA but with a built in scandoubler.

Which is what I was I expected but its nice to see it confirmed.

[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.

[Dwyloc]

Anyone know what happened to the software compatibility page http://www.opencircuits.com/Minimig_Software_compatibility it now stops at Alien Breed Tower Assault?

[Dwyloc]

OK I guess someone just deleted the lower part of the page by accident so I have re-added it by taking the removed part from the edit history.

If someone has/is trying to reorganise the page sorry in advance for undoing your changes.

[yaqube]

@Sascha

I haven't changed anything to disk dma slot allocation. Dennis used 4 slots for disk dma transfer, Amiga uses 3. The disk data transfer speed is quite hard to estimate since many different things affect it. Disabling PIC's debug info speeds the tranfer a little. I have also experimented with 6 transfer slots and speed gain was noticeable but some games had problems with running.

I have also modified the FPGA interface to the CPU and got it running synchronously with 28 MHz clock. SysInfo reports 3.00 speed of A600. I have also run the CPU with asynchronous interface (more cycles required for synchronization) to estimate maximum operational frequency. Mine (20 MHz part) seems to work correctly with ~39 MHz (5.5x7.09MHz) but reported speed by SysInfo is 3.06 times A600. I think I will stick to 28 MHz synchronous design. Memory access speed is a drawback.

[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?