Any need for a MiniMig 3.0?

[freqmax]

@Illuwatar,
NatAmi etc.. No hardware out, and nothing on licenses asfair. Fpgaarcade is nice and it's actually on its way out. But you could be the first to combine Minimig with an ZorroII slot (use the resistor + protection diode trick and check slewrate). Use SDRAM instead of SRAM = Plenty of more RAM for the same money x16 or such. Or make your board dual use. Standalone & daughter card. Minimig with yaqube ARM.
Portable version with TFT (rip screen & keyboard from a ultramobile). Include Ethernet onboard etc.

I think however it's wise to share the same hardware API from the HDL code. However pins may differ (.ucf). SPI commands should be as similar as possible etc.. However an 4-bit SD-card bus and mode might improve performance seriously.

AJCopland, 16 MB is max addressable for 68000 24-bit anyway

One little crazy idea.. How about hooking up an board with JTAG, "Keyboard/Mouse", video grabber. And let ppl develop remotely via internet to increase the number of possible developers? I know there's some catches. But it should help.

[freqmax]

Any surplus source of iPads with broken motherboard..?

[freqmax]

Fpgaarcade already found a solution to that problem by letting the PCB manufacturer solder on the BGA chip. And solder the rest by himself.

[freqmax]

The useful suggestions seems to be:
 * Zorro-II bus (AJCopland,freqmax).
 * PCI slot (billt).
 * PCMCIA slot (Sparky).
 * SDRAM to the full 16 MB (AJCopland). (Any leftover could be used for RAM disc)
 * SODIMM slot (billt).
 * Yaqube's ARM (AJCopland).
 * Secondary FPGA to allow TG68 development (AJCopland).
 * 4-bit path to SDcard to speedup transfers (freqmax).
 * Floppy drive port (Sparky).

Guess Zorro/PCMCIA expansion slot. 16 MB SDRAM. Secondary XC3S500e FPGA. And 4-bit SDcard path would be useful and still not rocket science. It's very much about priorities.

[freqmax]

SODIMM = DDR => CAS latency and double clocking => A pain to code. Don't think 16-bit 44 kHz is compatible with much classic software.

AGA supports needs 32-bit dataport I think. And thus 68020 is a requirement. And the reason to push softcore 68020.

S-ATA is a pain to find interface chips for. The only one I found has a chip bug. And P-ATA uses lot's of pins and is an electrical soup from hell. Flashmemories like SDcard is way easier to handle.

[freqmax]

One could use a row of pads on the PCB and some string of nails to connect quickly for testing BGA chips?
(like "bed of nails")

I think any Stockholm house will be expensive

[freqmax]

Zorro-II because any cards available already has drivers. This is not so likely with PCI cards. There are drivers for some PCI cards thanks to the bridge-board era.
PCI-express requires messy interface chips.
PCMCIA because it's used in A600/A1200.                  
Which bus to use is very much a already written drivers & support game.

As for DRAM. SDRAM is the least complex with most memory and availabilty sweet spot. I agree that soldered chip is the best. But then a socket enables a wider choice for use as RAM disc or to aid cpu upgrades.      
As long as the chosen CPU is 68000/68010 any memory above 16 MB is pointless. Because the it only has an 24-bit address bus.

Floppy drive port, can be just a dual use of existing i/o ports where you can use the board to rip Amiga discs. As Catweasel and similar products are not very common.

An FPGA allows as well to use ports for more than one purpose. Same port could work as ZorroII/PCMCIA/Floppy port etc.. Not something easily done previously.

[freqmax]

Is there HDL (Verilog) code already to support dynamic ram with CAS latency, or has it to be written ..? I have some vague memory of someone already writing this.

Maybe the AD724 can be eliminated by generating the waveforms digitally inside the FPGA. When some MCUs can generate color CVBS, an FPGA ought to be able to. Saves a 12 USD chip. The quality might suffer some. But if picture quality is of interest. Then RGB should be used

[freqmax]

Maybe it's possible to use a cheaper AVR/PIC and use it solely to boot the system and let the FPGA have a small softcore MCU to do the rest.      
(I hope MFM encode/decoding is done in the FPGA already)

RTC clock can be had with an plain connection to add a battery.

Zorro, IDE, Parallel etc.. can be done with a general I/O and then just use mechanical adapters to accomplish the function desired.

Maybe it's feasable pricewise to replace the 68000 with an FPGA now ..?

It's always possible to provide solder pads for expansions. And then users can decide to add functionality later on.

[freqmax]

The 68020 improved this over 68000:
 * 32-bit address & ALU.
 * 3 stage pipeline.
 * Instruction cache of 256 bytes.
 * Unrestricted word and longword data access.
 * 8x multiprocessing capability.
 * Larger multiply (32×32 -> 64 bits) and divide (64÷32 -> 32 bits quotient and 32 bits remainder) instructions, and bit field manipulations.
 * Addressing modes added scaled indexing and another level of indirection.
 * Low cost, EC = 24-bit address.

68030
 * Split instruction and data cache of 256 bytes each
 * On-chip MMU (68851).
 * Low cost EC = No MMU.
 
68040
 * Low cost LC = No FPU.
 * Low cost EC = No FPU & MMU.
 * Instruction and data caches of 4 kilobytes each
 * 6 stage pipeline.
 * FPU lacks IEEE transcendental functions capability.
 * FPU emulation works with 2E71M and later chip revisions.

68060
 * Integer pipeline.
 * Two cycle integer multiplication unit.
 * Branch prediction.
 * Low cost: LC = No MMU.
 * Low cost: EC = No MMU & FPU.
 * Dual instruction pipeline.
 * Instructions in the address generation unit (AGU) and thereby supply the result two cycles before the ALU.  

[freqmax]

The more that is invisable to software, the easier it's to implement

However programs might expect unaligned access to have a speed penalty. And also the timing characteristics of pipeline might be expected by some software.

But it might be worthwhile to just go for the obvious stuff like 32-bit modes. And see how much software will manage with that. Most cycle accurate demo/games were for 68000 anyway
Better to take on the AGA cloning then.

I don't find any source code for the Mico32 cpu project. Seems locked up.

[freqmax]

So the question is if it's easier to implement m68k instructions into an structure already having ICache, DCache, pipeline, and JTAG. OR adding ICache, DCache, pipeline, and JTAG to an existing 68000 clone ..?

Or even doing it from scratch.

Is there any real use for any better cpu than 68020 besides FPU & MMU ..?
The clocking limit of the physical Motorola incarnations won't apply to softcores for better or worse..

I see 68020 (or better) just as a stepping stone for AGA graphics. That is clone it while hardware is available.

[freqmax]

jkonstan, I like your suggestion
Btw, what resistance do you suggest for those series resistors?

Keeping source code compatibility ought to be the priority. Not to keep binary compatibility. Especially when the benefit is such a huge RAM expansion.

Any excess RAM can be used as disc. Or even enable one to halt an "memory image" and run another etc..

If a 68020 is in the pipeline it might be economicly sound to replace the current 68000 with an XC3S500E FPGA:
68000 (8 MHz) = 5 USD          
XC3S500E = 21 USD
68020 (33 MHz) = 41 USD
(digikey.com)

[freqmax]

Better a small run before a big one to find the hardware bugs

If it's possible to get an BGA FPGA assembled like 'mikej' got then it's also possible to rid of the MC68HC000 cpu and the current PQFP FPGA. It should even be possible to use a simpler MCU by moving the mainload onto the FPGA (ie softcore MCU).

Please also take care of the SPI-MMC-FPGA issues when making a new board :
http://www.opencircuits.com/Minimig_Board_v1.0_issues

[freqmax]

@FrenchShark: Any Verilog/VHDL sources for that SDRAM functionality?