Idea of the day - FPGA Amiga on a PCI card (or even a USB stick)

Here's a thought. Back when AmigaOne computers were new, everyone said, quite rightly, 'they can't be true Amigas with hardware backwards compatibility because they don't have the custom chips'.

Also at that time UAE wasn't yet a thing, or at least, the high quality thing it is now.

The world has changed in 20 years. You can now get an 'Amiga on a chip' as per Minimig, Vampire etc.

But all these implementations either standalone, or plug into a classic Amiga.

Wouldn't it be nice if there was a FPGA on a PCI card version, that one could plug into your PowerPC Amiga, and turn it into a true Amiga that could run a sandbox UAE-type software, but run it at original speed accurately by virtue of using the hardware solution i.e. a kind of hardware UAE.

Thoughts?

@NinjaCyborg

Great idea, looks like the never released inside out card. But that one had a cpu added.

You could also use your idea as an aga gfx-card instead of a RadeonHD.


Aren't there any standard fpga on pci card's available?

@benny

Yes Intel has FPGA that can be plugged into the PCIe slot,

the problem here is that AmigaOS4.1 does not respect CHIP RAM address space, when you allocate memory as CHIP you do not get the correct address space, so you need a change in ExecSG so that it does use correct address space, and then you can trap the custom chip address space, the problem however is that there is no safe way, to say you like to allocate address from X to Y as shared address space, and then trap it, so you can’t trap that range of memory in a safe way. There things hidden in AmigaOS4.1, you can’t always read directly from execbase anymore, you get strange results.

Chipset.library was attempt to make software API, so you peek and poke into a virtual chipset, it works by memory translation to overcome this problem, so if have old program and you have source code, you can peek and poke into chipset.library. note that blitter assembler code is easily changed into system friendly code by using graphic library blit functions.

So the problem you have running old software is mostly Paula, and ciaa and ciab timers/chips.
the cooper is interesting, you easily make interpreter for it, it’s not a complicated instruction set.

Another thing is causing problems, is old programs that open screens by asking for 640x480, but does not define mode id or a pixel format will get chunky screen on AmigaOS4, when it depends on Planar, a small patch can most likely fix that, all we need is true color black list.

Another problem is all fakes modes on AmigaOS4.1 is 640x480, that’s also bad because lot of old programs have hard coded bytes per row, instead checking the bitmap. These programs are not updated, or the maintainer ignores bug reports from AmigaOS4.1 users and developers.

I have gone bit more complicated version of that with BetterFakeMode patch, but It has to take over lot of OS, there is lot hidden structure, that I need, to a make it good, it’s hack, I’m not getting bug report and examples I need to figure out how to do it, in nice way, it will be wary hacky. It be better if OS developers looked into this.

I know AmigaOS4.x was never intended to be emulator, and only went for the minimal support, I think there is room for improvements, this is not criticism of people who made this happen in the first place.

I suggested using an augmented MiniMig core as an alternative to modern graphics drivers. It was a possibility that couldn't be made modern because of massive incompatibility between floating-point based 3d acceleration and integer-based Amiga chipset modes.

On another occasion I tried to create a translation layer that would use shaders on modern graphics chips to implement copper-style tricks. It could emulate a palette with copper shading in theory but nothing more. Most modern chipsets aren't designed for palette modes anyway.

Perhaps a hybrid solution could exist: a Minimig core that could output to a texture map so a modern card could display the emulation in a window.

@Samurai_Crow

The third option is what I had in mind. The 'Amiga on a card' should exist as it's own thing, not try to take on other responsibilities covered by off the shelf graphics cards or other things.

@LiveForIt

What about goin the Siamese way, Amiga on a PCI card and just an OS4 app with a screen/window for output? Would that work?

Edit: OS4.1 host use it's RAM, OS 3.X slave use it's PCI onboard RAM?

@khayoz

Quote:

I think be where similar to what we have not with EUAE, naturally advantages can be less hover head host OS.

Disadvantage, can’t run programs side by side, and not step forward.
Price is another disadvantage.
However, if did do complete system we do it on “Ardurino-mkr-vidor-4000” this little bad boy can easily do the timing of CIAA/CIAB and the joystick ports.

https://store.arduino.cc/arduino-mkr-vidor-4000

€62.90, you get it for 50 USD on Amazon.

the Paula stuff can easily redirected to AHI, if AmigaOS4.1 was so kind to add support for old address spaces, so we can ignore that, if the kernel developer be so nice to fix that.

I’m think joystick ports go directly into GPIO pins.

AGA screen modes can be improved by the OS developers, that be best, we lack DBPAL, DBNTSC, and Productivity modes, I’m thinking the GPU can maybe do it using the shader. And lowres / interlace modes are mostly wrong. If this is possible have low CPU usage and good support. (I know its hard to do, no bit opcodes, and no integer, maybe lookup table?), can't have blur when doing 8bit to ARGB code.

Not looking for full 68K system here, we have EUAE that work ok, if that’s needed.

I was hoping to get a cut down version of the PicoEVB for my PineBook Pro and run it under Linux with a MiniMig core variant with the video and audio rendered as memory-mapped I/O to the host hardware. Of course the DevBoard I've linked is way more complicated than it needs to be and it costs $200+ to reflect that. The rest of the chipset emulation can run on one of the little cores on the RockChip RK3399 while one of the big cores can run the actual JIT code.

This chip would be well suited to running on a PCI or PCIe board also. It runs fanless and has enough space for future expansions such as SAGA chipset emulation like the Vampire standalone. I'm not sure how much the FPGA chip costs by itself though.