FPGA Replay Board

[freqmax]

You can connect another FPGA to the expansion port. The base FPGA is wired directly to the expansion port (no FSB).
(So picasso96 etc.. could be implemented)

Asfaik, lest mikej says something else.

[freqmax]

JimS, I was referring to implementing another RTG in a FPGA daughterboard. Maybe soft-68060 is doable as well

A cool thing would be multiple video output RTG card. Like running 8 monitors from the same Amiga..

[freqmax]

As I understand it there's 32 MB on the baseboard and those 4x SDRAM (128 MB) are on the future add-on 68060/ethernet etc.. expansion board. In that case it's still in development and replacing them with better options for DRAM would be easy. In particular different type of DRAM-stick could pack more memory in the same space. Provided the I/O interface isn't a pain to interface.

A caveat with DRAM in general is to watch out for obsolence. That can make sourcing the components a pain.

In case of crisis, just spin a daughterboard full of DRAM sockets. And have 20 GB ram if you need..

Something that could be useful is an expansion connector on the backside of the board such that one can stack several of them ontop of each other just like PC/104:

[freqmax]

Implementing some 3D and texture acceleration is possible with the FPGA. Infact the CPU doesn't need much involvment at all perhaps.

Anyone has an estimation on the diffeculty level?, and what other functionality could be needed?

Any CPU specificly targeted towards FPGAs should emply parallism and pipelining as much as possible.

[freqmax]

Where is the statement that it's 64 MB onboard?, last update on that issue said 32 MB asfaik.

[freqmax]

Seems Mikej upgraded to 64 MB. Anyway any hinderance to make use of the full 16 MB maximum the 68000 can address ?, the full control should make this possible.

I don't think there will be any audio delay issues with OctaMED or anything else unless Minimig also have such issue. An FPGA can work cycle exact. Something software can't do unless the realtime capability is sacrified. Or you can run the whole hardware simulation loop in less than a cycle of the emulated system.

[freqmax]

Frankly speaking I don't know why some people spread around false information about installed memory size.

Asfair he used a 32 MB chip in an earlier PCB schematic. But technical data has to be compiled from different sources and files. Thus mistakes are easy.

(ie find the hopefully latest schematic, find the DRAM chip in the schematic, lookup the datasheet, calculate for ddr/bit width etc..)

The TG68K in 68000 mode can access full 32-bit address space (like a real 68012 CPU) and use additional 48 MB of RAM. But because some programs  cause problems when running in this configuration I have decided to limit address space to 16MB when 68000 mode is selected. Full address space is accessible in 68020 mode.

My thought was more on make use of all memory ranges. Even those that can't be expanded on a real Amiga. In particular CHIP ram tend to be scarce. And there should be no reason for that to be that way using FPGA+DRAM.

[freqmax]

If there's demand for another batch. How long would it take to realise?

Btw, do the boards come pre-assembled with the BGA mounted FPGA from China. Or is that done by the same machine that do the other components?
BGA tend to be a pain-in-the-ass

Regarding expansion boards. Maybe a solid power supply solution should be planned for so that it won't overload weak or loose DC-plugs, fit common power supplies, don't become a birds nest etc..

[freqmax]

ATX PCB adapter?

[freqmax]

MikeJ, Isn't 500 boards a huge economical risk? The first 100 boards should be no problem. But 500..

[freqmax]

How does the Amiga side know or even change to other ADF:s or HDF:s ..?

There's no "change disk automaticly" API in Amiga..

Though autoboot.adf or autoboot.hdf is a good idea.

[freqmax]

Thinking about this for a while.. this renaming business maybe isn't such a good idea. it might be better with a configuration file that points to the .adf or .hdf file to boot.

If the filesystem were a unix one, a quick filelink would solved it

[freqmax]

Oh, the world would be a better place if everything was running on unix

On the practical side implementing a unix-fs might be tough for a microcontroller..

But how are we going to access the minimig config file from the amiga os when that file resides on the root of the sd card ?

The same way you switch discs right now?

Otherwise a simple block interface to the raw SD-card from the Amiga side could make workable.

[freqmax]

Alternative A
I think that it would be cool if ADF format also had a small section inside itself (e.g. 64kb) to hold: Info on the adf-contents, a screenshot, +++
This info could then be shown in the selector.

OR

Like the IFF chunks?

Alternative B:
Put a .adx file in parallell with the .adf file where x stands for "eXtra" so that if the adf file has such a daughterfile, the amiga selector uses this for displaying extra info on the adf file -- and he .adx file can hold e.g. a jpeg + text etc...

Those infofiles tends to get lost..

[freqmax]

Before using the RP9 format, check that it's copyright free.

Serial link to the floppy seems overkill. All those serial commands has to be implemented in the MCU or RTL.. messy. Better to just add another block interface.

[freqmax]

If you can tell the microcontroller (ARM) what image to "boot" it's doable.

The open question is what machine/OS will be used as a platform for the menues, an Amiga might be overkill for the task. It will also require an interface from the computer side to interface with the microcontroller in a consistent manner without bootlenecks.

Block access might be convinient but may also make it possible to corrupt the entire fashmemory. An alternative is to limit access only to a single data block of configuration files.