[Vampire] The AMIGA Future Is NOW! AROS!

[mikej]

Is Mike still around here? Would be interesting to see if he'll be able to/want to add the SAGA code to the FPGA Arcade boards.

Hi, sometimes yes.

I've no idea what SAGA is? If it's documented / open source then potentially, I see it as a 3rd party add-in to the original machines, much like an RTG graphics card.

I'm trying to model the original hardware/CPU as accurate as possible. Additions I have made, such as expanding the address range of chipset memory pointers for example, are configurable.

I'm spending time working on a Slower CPU which is more accurate
(and the rasp pi compute module running just CPU emulation)

/Mike

[mikej]

I just read the thread. We already have two hdl implementations of the AGA chipset, mine and the minimig derived one. We have extensions such as extra memory, RTG, AHI audio etc already.

I guess the game here is to add propriety extra features and build a new platform, but that potentially breaks back compatibility. For them it makes sense to open source that part of the design to encourage people to use those features. Personally I'm much more interested in a new, cycle accurate (and high performance compatible) open source CPU, which is what we are working towards.
Why not just compile AROS to cheap modern CPU platforms?
/Mike

[mikej]

"

I must say I'm more interested in the ARM board being made to run a 68k emulator and appear as a real 68k cpu to the Amiga than anything else at the moment.
though.

This is what I'm doing. The FPGA will have a cycle accurate 68000/20 based closely on the original device, probably with some optional speed ups similar to the current design.

The 68060 add on board is pretty much done, and I'm playing with the PI compute module as a fast 68060 emulator. It has something called SMI which allows me to directly connect it to the FPGA. As the PI is just running the CPU, it's very fast even on a single core.

David has been doing some excellent bare-metal work here emulating the 6502.

https://github.com/hoglet67/PiTubeDirect

[mikej]

Where do I start?[/LIST]

• AROS runs hosted on Linux on the RasPi already.  There's hardly any software that runs on ARM AROS.  Same goes for x86 and AMD64.

The CM3 module is emulating just the CPU - so it looks like a fast 68K

• Running UAE4ARM on a RasPi 3 is good enough to emulate an A1200 quite well already.

Running the chipset in the FPGA and the CPU in the ARM gives (in my view) the best of both worlds. And there will be a CM4 etc in future cheaply to speed up the CPU. It also has local memory and HDMI out obviously as well.

• The SAGA core implements the chunky and YUV modes as a third playfield by re-purposing a register in AGA that was intended for a greyscale monitor that was never produced.  It's not a separate RTG mode, it's all integrated.  THat's actually the main reason for AROS: new graphics drivers that work as one.

If this is documented then it would be trivial to add the additional modes to any of the current hardware FPGA platforms

• Since the closed-source 68080 core performs as well per clock as a Core2 Solo, it'll keep up with the modern systems quite nicely!  Especially when compared to an ancient 68060 clocked at twice the clock speed!  Note:  The minimum clock speed of the '080 is 78 MHz already so I hope you can clock your 68060 board at a minimum of 144 MHz...  ;-)

113MHz, but it has MMU and FPU.

[mikej]

as a comptent person you probably are aware that 68k mmu emulation wont work with jit. without jit emulated 68k cpu is slower than apollo core. that has been measured.

I was talking about the real 68K here. What is possible on the quad core 1G ARM remains to be seen when it is just running CPU emulation.

I'm more interested in performance per $. A CM3 module is something like 30$ and has 1G RAM and HDMI out. It's tough to compete with that with the FPGA.

I started this looking at the zynq SOC chips which have a fast FPGA device and on-board ARM, but it's still more cost effective to strap the CM3 module onto a spartan7 FPGA or something similar.


http://www.fpgaarcade.com/punbb/viewtopic.php?id=1221

[mikej]

Do you see any possibility to make an acc card for "real" amiga hardware using the RPi Compute module?

This was discussed. I have no interest in doing it, the accelerator market is somewhat saturated. It's much easier to interface the compute module directly to the FPGA as you can control timing. To fit in a 68K socket you would need a bridge device so you are losing the cost benefit. Perhaps a zynq with embedded CPU core would be interesting, but they are quite pricey.

"We know that we can put APOLLO in to an ASIC."

I can put anything into an ASIC. My day job is working for a fables ASIC house that actually makes chips (specialist high performance 28nm CPUs amusingly). I keep meaning to run the TG68K CPU through the Cadence synthesiser and get a timing estimate - it would probably go at least 500Mhz, maybe more.

That doesn't mean it's going to happen though. Licence costs for the tools, cells and memory compilers are very steep, as are the production costs. We make high price devices so there is a business case. I don't see a fast 68K processor selling for more than a few$ - it's got to compete against Atmel etc who make really quite nice ARM based SOCs.

There is test, characterisation and a million other things to consider apart from having just the RTL.

NXP still make 68K devices. While making a few hobby FPGA designs is not going to interest them, they will aggressively protect their IP if you try to make a business out of it.

The vampire core is fun and seems to work well, but I don't believe it's going to take over the world (unless ARM was to vanish tomorrow).
/Mike

[mikej]

500MHz? Sounds realistic with a little tweaking.
Possibly higher with cache and a bit more work.
But once its finalized in dedicated silicon, no more changes...;-(

You can park some wafers during production so you can do metal mask changes later without re-running the whole process. Let's you correct minor bugs for less cash.

The amount of verification done on ASIC designs is huge to avoid this kinda thing. ...