Minimig PCB run - interest thread

[freqmax]

Page 106 of 442:
http://www.freescale.com/files/32bit/doc/ref_manual/MC68040UM.pdf?fpsp=1

A quick count gives 43 ctrl + 32 adr + 32 data = 107 i/o pins.
So there's at least 27 new pins to connect. And the current setup only have 4 free. Thus a serious reorganisation with a southbridge solution or a enterpoint/uk PGA socketed solution would be needed.

So it proberbly can be done. But not as a plugin solution to the current setup.

As for kickstart/WB I think dennis have to tell

Btw, found another assembly house: http://www.creationtech.com/printed_board_assembly.shtml

[freqmax]

UAE hardfile support is plain verilog hacking :-)
Though the MCU would need some additional code to support write operations.
As for replacing the cpu, it's mainly a question about weather the number available fpga i/o's are enough.

[freqmax]

The datasheet for MC68040 I looked at says Vcc 0V-7V. So I guess 3.3V operation is ok. S-ATA is nice but requires either an transceiver/PHY => more pins. Or an FPGA with S-ATA port => Virtex-4 FX => Significantly more cost & use of bga packages.

[freqmax]

ivier:
I think it's possible to get usb by simple using two pins on the fpga, albeit maybe only usb1.1 at 12Mbps. For usb2.0 at 480 MBps it may need a PHY chip.
But any cpu to shuffle data will likely slow things down a lot.

Seeing a lot of suggestions for Minimig. I think actually USB makes most sense. As one can get keyboard, mouse, joystick, mass storage, rs232, soundcard, ethernet (netboot!), etc.. from ONE usb port via an hub.

As for USB2 it's a real FAKE, your equipment can be USB2 complaint but unable to perform 480 Mbps operation!

JimS:
Actually to enable higher speed, voltage is lowered. This is related to flank times and P=U²/R ie the energy dumped during switching.

[freqmax]

How is software compability for running with a 68020, 68040 or 68060 instead of 68000 ..?  esp for games.
If there's any minor incompabilities is it realistic to let the fpga hide those from the software. As the FPGA sits in between the cpu and ram ..?

CD32Freak:
I think people want some hardware misses patched, like pin81/19 swap, or-gate for the sd/mmc interface etc..

Then there's the issue of finding an pcb maker that will assemble the boards for a reasonable price. And that you can rely on.

[freqmax]

Any particular parts that are hard to source ..?
Any tip on FPGA sources except digikey?

[freqmax]

My idea was to use a "better" cpu for other purposes than to run WHDLoad.
WHDLoad is just a bonus :-)

[freqmax]

I think what is required to satisfy most people. Is a board with various fixes (or-gate to sd/fpga/mcu, fpga spi_dout pinswap etc..). And this board should have at least all large smd components assembled.

I have compiled a list of fixes that should be considered:
http://www.opencircuits.com/Minimig_Board_v1.0_documentation

[freqmax]

What will the v1.1 board improvements be ..?
* Or gate between fpga/mmc spi?
* Spi_dout fpga patch?
* Pin headers?
* DCM generated color clock?
* One or two SRAM chips?
* Video D/A resistor ladder linearity fixed?

Btw, is it possible to make the mc68000 behave like a mc68020 or such via fpga tweaks? (and make aga or such feasable)

[freqmax]

Xenepp:
I think you misunderstood me. My idea is weather it's possible to "fake" a mc68020 with a mc68000 using the fpga that sits like a spider in the wire network. Ie using only hdl (verilog) tweaks.

[freqmax]

Xenepp:
Well the idea was to just implement the 020 exclusive features  in the FPGA. And let the present 68k handle the rest.
(makes me wonder how hard it's just to swap the current 68k to something else, pin compatible?)

Dennis:
Are crystals X1 and X2 operating in parallel or serial resonance mode?

For pcb v1.1 makers:
I have sorted the issues I have discovered and found mentioned on amiga.org here:
http://www.opencircuits.com/Minimig_Board_v1.0_documentation

There's a non obvious issue with the video D/A. The original resistor values cause a dent in the desired vs actual output value. The math and results are here:
http://www.opencircuits.com/Minimig_Video_d/a_resistor_ladder
My patch also make better use of the full signal swing available.
In short the resistor ladder should use 4220 ohm, 2100 ohm, 1050 ohm, 523 ohm (1% tolerance). In order to avoid this.

I also found that the output D/A also needs a translation table to match input data with correct output amplitude due how ohms law works. Anyone found this in the verilog sources? Amber & Agnus is likely candidates..

[freqmax]

alexh wrote:
Q. Can you get SMT resistors of such wild values?

Value  - Digikey ID
523    - RR12P523DCT-ND
1.05K  - RG20P1.05KBCT-ND
2.1K   - RR12P2.1KDCT-ND
4.22K  - RR12P4.22KBCT-ND

Package 0805, 1/10W, Thin film, 10 pcs/order asfair.
Total cost ~2 USD.

Actually when I did the math the thing I was looking for were the available resistor values. The most important is to check that Vpp-peak is lower than 0.7V at all times. So the values may be wild for humans. :-D But they fit digikey ordering and the equations.

As for improvements, how about wire the mcu spare i/o to another pin header?  (just like it's done on the fpga)
http://www.opencircuits.com/Minimig_MCU_user_I/O

[freqmax]

alexh:
Why would not simultaneous floppy and harddisc (file) access work?
Btw, Write operation is not even implemented atm :roll:

amigadave:
I know some local companys that can produce a minimig from drawings. But they cost a lot more than china. Otoh they are reliable and will deliver. And I can personally inspect the companies.
One prototype one-off board would proberbly go for around 220 EUR. (way less for many boards in a batch)
Assembly is approx 428 EUR start cost, and 7.5 EUR per board.
Considering this I prefer the China route  ;-)

[freqmax]

alexh:
One could implement a queue or semaphore that sends out one request to the MCU at a time. Floppy & Harddisc doesn't have to access the MMC simultaneously in the physical sense.

[freqmax]

I checked the MCU firmware:
http://www.opencircuits.com/Minimig_Board_v1.0_mcu_firmware

And these changes seems to be needed in order to allow an harddisc emulation:
Define "struct adfTYPE dh0;"
Update User() to handle selection 'dh0' aswell. Current implementation decides you ALWAYS want 'df0' :-)

Make HandleFpgaCmd() to take more parameters and make them variable size per request.
Modify ReadTrack() such that it doesn't presume 11 sectors per track.
Make a SectorToFpga() function that don't stuff sector header formatting into the transfered sector.

The rest is to make the FPGA to present the SPI transfered sectors to appear magicly from the Gayle ide controller.
What part would impose a data rate limit faster than is currently available? Even hardware banging floppy loaders can't get around that each track-to-track move needs 3 ms. Which should allow one to send a harddisc sector in between if so required.

[freqmax]

Is /FPGA_SEL2 unused ..?
I can't find any use of it in either the FPGA or the MCU firmware.