Die space for m68k on FPGA?

[freqmax]

I know it has been written in some other thread but how much of the FPGA Spartan 1600 used in the FPGA Replay is used by the plain 68000 CPU ?

Need the number to figure out if another CPU implementation is realistically possible.

[freqmax]

68020/0507070 is way more complex and therefore uses way more transistors.

[freqmax]

I' curious if an 80386 + VGA can be implemented on the existing FPGA Replay.

Other CPU:s like MIPS, ARM, SPARC etc.. could also be of interest. Especially to explore software that are designed for platforms that now are quite hard to find.

an FPGA on a PGA carrier to replace 68060 which are so hard to find the good ones now.[/url]

I like the idea. Power through the socket might be an isssue thoe.

[freqmax]

I know, but how much FPGA resources they use is another..

[freqmax]

DosBox with 68k Dynamic Recompilation should be able to achieve 386 emulation speeds on a fast 68060 or fpga 68k CPU. The bonus is that the Amiga can multitask at the same time

Problem is that some of the interesting applications and reason to run 80386 software on real hardware is very low latency. This is very true for parallelport bitbanging DOS software. So it's the same issue as with software emulated Amigas. They can't deal with latency and propagation races properly.

So a very common setup like 80386+VGA+Soundblaster with many lovely parallelports would be just the thing to make use of existing DOS bitbanging software.

@MikeJ, If you succeed to run TurboC in 80286 mode using outportb(0x378,0xF0) etc and some VGA demos with sound I thing the re-implementation can be called a success.

A more specific setup would be:
CPU: 80386 - least complex x86-processor with the greatest software compatibility
FPU: 80387 - IF space is available
Video: VGA -perhaps CGA/EGA as options, again for compatibility
Sound: Soundblaster 16
HDD: P-ATA < 8GB
Floppy: 2x 1,44MB
Serial: 16550 that can dump contents to flash or use Ethernet
Parallel: 8255 with real world I/O
Ethernet: NE2000

Of course OSD options to enable/disable as desired could be used. And loadable setups associated with a bootimage etc.

The main point is 80386+VGA and access to I/O via (many) parallelports such that bitbanging DOS stuff can be made to work. So rather more real world I/O than anything else. By using 80386 instead of 8086/286 one get the benefit of being able to run Unix or Windows. Perhaps one could fix the ten or so 80386 errata (bugs) at the same time.

[freqmax]

The FPGA used in Replay is not likely to have the die space to handle 386 + m68k at the same time. And emulating 386 on a 68060 on a FPGA is an so inefficient solution I recommend: Think again.
As for PPC it has been discussed before. The size is just too big to be practical. It's way better to use the ASIC PPC until moores law makes it feasable.

[freqmax]

The ARM CPU on the FPGA Replay is most likely busy serving the FPGA with disc emulation and doesn't have the code space to do much else. The transfer capacity to the FPGA may also be a serious bottleneck.

[freqmax]

Which will cause incompatabilities..

[freqmax]

The Amiga and 68k platform is dead until someone provides a pathway to ASIC with high volume and low price for consumers. Because m68k on mobile phones would be cool and perhaps way nicer to program.