Faster CPU for Minimig core?

[dshadoff]

I feel like every time this topic comes up people vastly underestimate the amount of effort required to have the 'hybrid' system that keeps getting proposed.

Anybody who isn't writing cores is vastly underestimating the effort of pretty much any request that is made.

[LamerDeluxe]

That is a thing with software engineering in general (as well as graphics design).

[ron]

I don't wish what I'm going to say sounds like sarcasm, but ... when there isn't even an open core of 68030, don't you think the expectations are too high?

Forget about the Apollo Team's Vampire, it's a proprietary core and will not be used outside its projects. According to a Finnish colleague, they say the Vampire's core reeks of Coldfire. There is no data to support this claim, but it is clear that MISTer poses a serious threat as far as its intentions are concerned.

Perhaps an alternative is to start with something more affordable, like the M68030, also a PMMU and it would be the gateway to cores that support Atari Falcon 030, Macintosh II, Amiga 3000 and even NeXT.

Dreaming is free, I'm just trying to be realistic with the items currently available. No acrimony, please. The best of the news for those of us who like Motorola processors would be a functional 68030 core. Those are major words.

[throAU]

other than the mmu which isn’t used by amigaOS, the 020 and 030 are functionally identical.

the only difference is cache and manufacturing process/clock speed which is irrelevant to mister as mister itself is on a far more advanced process - the simulated 020 is much faster than a real a3000 and has the same instruction set and runs the same code.

sounds like what some people really want are 68k MMU and FPU. and if you’re running amigaOS both are mostly irrelevant. unless you’re running amiga unix or linux i don’t believe the MMU is used anywhere?

unless code is actually checking for an 030 somehow it should just run on simulated 020 unless it uses mmu. and if it doesn’t run, and performs some sort of check and doesn’t use the mmu all that is required is to lie to the OS.

simulated 040 is a different thing entirely and it has an extended instruction set

[lordoftime79]

Could the 020 core be made as fast as the vampire cpu?

[robinsonb5]

Could the 020 core be made as fast as the vampire cpu?

The current core? Probably not - the things you need to add in order to get Vampire-like performance aren't easy to just bolt-on to an existing design.
To run at Vampire-like speeds you would need - in approximate order of difficulty:
* Deeper pipelining - breaking each unit of work into smaller chunks so the clock speed can be increased.
* Branch prediction - reducing the amount of time wasted waiting for memory.
* Decoding instructions into an issue queue
* Figuring out which instructions can run and which are blocked by other operations
* Dispatching queued instructions into one of two or more execution units
* Register renaming - remapping logical registers to a much larger pool of physical registers - reduced the number of hazards between instructions and makes the multiple execution units more useful.
* Probably a dozen other things I've missed!

In short, months and months of work.

Or to summarise the summary: don't hold your breath!

[ericgus09]

In short, months and months of work.

Or to summarise the summary: don't hold your breath!

took the Apollo team years .. so .. probably more like years and years.. just to be realistic.

[lordoftime79]

so I am gonna show just how much I dont understand FPGA stuff now but cant the code be opened and the mhz section just be changed to a new higher speed?

[robinsonb5]

so I am gonna show just how much I dont understand FPGA stuff now but cant the code be opened and the mhz section just be changed to a new higher speed?

The logic in an FPGA design is broadly made up of combinational logic, where the data flows freely through the gates as fast as the FPGA allows, and of registers (almost like "checkpoints"). At a clock edge, whichever logic level is present at a register's input is latched, and held at the register's output until the next clock edge.

So you might have a path that looks like

Code: Select all

[input]  ----> [not] -----> [output register]

where the output will be the opposite of the input. Data will reach the output register very quickly since there's basically just the one gate to go through, so it's likely to be very fast.

You might also have a path that looks like:

Code: Select all

                               --------
[32-bit input]  =============> |       | 
                               |  ADD  | =====> [is bit 33 == 1?] -----> [overflow register]
[another 32-bit input]   ====> |       |
                               ---------

Adding a pair of 32-bit numbers requires a lot of gates, and the incoming data will take some time to filter its way through and reach the output register. If the clock pulse comes too soon, the output register will latch an incomplete result and the design will fail.

The longest path on the TG68 typically needs at least 20 nanoseconds for the data to filter through (depending on the FPGA type, and not counting any external logic like memory caches). This places an upper limit on the clock frequency of around 50 MHz, again, depending heavily on the FPGA and the characteristics of the rest of the design. (It's sometimes clocked faster than that, but when it is, there's a "clkena" signal which causes the registers only to latch one clock in 4 or more.)

All of which means, to increase the clock frequency you need to identify any paths which are longer than the desired frequency allows, and break them up so that less work is done between each register. The work will now take more clock cycles to complete, but it can still be a net win if the overall speed is faster, because it often means the separate stages that replace the original path can be overlapped with the next set of data. It's much easier to design from the ground up with those principles in mind than to adapt an existing design, however.

[throAU]

Just thinking outside the box (literally)...

What's the capability of the IO header on the DE10-Nano? It's fast/capable enough for SDRAM; would it be fast enough for a RAM+CPU board, like we used to have in trapdoor expansion for amiga 1200 and the like?

i.e., for those who really want a faster CPU in their simulated amiga, would it be feasible for one of those people to look at an expansion board with say DDR2-SDRAM and a PPC (or higher end 68k based - maybe ColfFire?) processor on it? I mention PPC as there are already physical PPC accelerators that exist for real hardware.

i.e., shift away from trying to design (which is no doubt a huge effort) and fit a more advanced processor into the FPGA, and hook it up via an expansion header, like was used in real hardware?

I'm sure real 68k CPUs must be cheap now?

IIRC, the original Minimig box had a real 68k on it with FPGA custom chips only (or is my brain not remembering properly)?

I mean just looking on mouser, a ColdFire physical processor is like $60... which I do not think would be cost prohibitive in itself if people genuinely want a faster, hardware based amiga. I mean if you want a real A3000/A4000 - just finding one is difficult and they go for stupid money, and are 30yo, etc.

https://au.mouser.com/Search/Refine?Keyword=MCF530X


i.e., the custom chips, IO, etc. would be hosted via mister, the processor+RAM expansion would do most of the grunt work and access the chipset via the header? Obviously this would need re-work of the core to accommodate but would (I guess?) be less work that designing/testing/etc. a new CPU core?

[ericgus09]

so I am gonna show just how much I dont understand FPGA stuff now but cant the code be opened and the mhz section just be changed to a new higher speed?

There is no "code" .. and a FPGA has no master CPU like a raspberry Pi has, this is not like a software emulator that runs on a commodity CPU which on the fly translates every instruction executing on the guest (i.e. amiga 68 machine code) to its own op-code i.e. ARM on a Pi.. an fpga is just a chip with a bunch of undefined logic gates that do nothing until a gate map (aka "core") is loaded that tells the FPGA gates how to configure themselves.. much like etching silicon does with conventional chips.. unlike conventional silicon chips you can re-arrange these gate mappings as often as you like, with real silicon once its "etched" its unchanging for the rest of time..

[kolla]

Back in the days (mid 90ies) some fellow computer student friends and I concluded that the probably easiest and cheapest way for us to get faster Amigas, would be to use mind altering drugs that changed our own perception of time - maybe something to consider, hehe

[kolla]

sounds like what some people really want are 68k MMU and FPU. and if you’re running amigaOS both are mostly irrelevant.

Not really - FPU is supported and is used when available, by OS libraries.
But that is really beside the point, which is that there is plenty of SOFTWARE that not just use FPU, but sometimes require FPU.

If all you want to use AmigaOS for is to launch games, then sure, neither are of much use. But for many of us, that's not what this is about, we wish to run the same software we used to run on our old Amiga systems, and that includes also software that require FPU. My real Amiga systems always had FPU available, it used to be the cheapest upgrade possible (along with FastRAM), several Amiga systems shipped with FPU (and some that didn't still featured a spot ready on the montherboard, like A1200.)

unless you’re running amiga unix or linux i don’t believe the MMU is used anywhere?

Or NetBSD?

The MMU It is used here and there, but mostly for things that are irrelevant for MiSTer (overcome hardware issues, like initializing zorro3 DMA)

And Thomar Richter has been busy for years (decades?) with his MMULib package, that use MMU for many good and useful things (softkicking, copying kickstart to FastRAM and protecting it and lots more), but most of them again are not so relevant on "unreal" FPGA systems like MiSTer.

unless code is actually checking for an 030 somehow it should just run on simulated 020 unless it uses mmu. and if it doesn’t run, and performs some sort of check and doesn’t use the mmu all that is required is to lie to the OS.

From what I understand, the only way to detect which 68k CPU you have, is to throw code at it and see what sticks, so I don't think you can just lie
But I really don't know of any software that specifically require 68030 not just 68020.

simulated 040 is a different thing entirely and it has an extended instruction set

And that is a CPU that isn't really well supported by the OS... especially the FPU, which is disabled on boot and only activated by Setpatch via 68040.library, that emulates 68882 FPU instructions not found in the 68040... so that games can boot from floppy and not cause guru from checking for 68882

[kolla]

Just thinking outside the box (literally)...

What's the capability of the IO header on the DE10-Nano? It's fast/capable enough for SDRAM; would it be fast enough for a RAM+CPU board, like we used to have in trapdoor expansion for amiga 1200 and the like?

i.e., for those who really want a faster CPU in their simulated amiga, would it be feasible for one of those people to look at an expansion board with say DDR2-SDRAM and a PPC (or higher end 68k based - maybe ColfFire?) processor on it? I mention PPC as there are already physical PPC accelerators that exist for real hardware.

Hm, now you make me wonder... you don't have a MiSTer, do you?
You are not aware that the Minimig based core for MiSTer already can configure 384MB of FastRAM, that is DDR?

I'm sure real 68k CPUs must be cheap now?

Not really, they are getting hard to come by (which is why this FPGA stuff is a thing in the first place...), espeically 68060 are rare and expensive.

IIRC, the original Minimig box had a real 68k on it with FPGA custom chips only (or is my brain not remembering properly)?

Correct, Minimig v1.0 and v1.1 used/uses 68SEC000, the very last 68k that was in production. But Minimig is also more than 10 years away.

I mean just looking on mouser, a ColdFire physical processor is like $60... which I do not think would be cost prohibitive in itself if people genuinely want a faster, hardware based amiga. I mean if you want a real A3000/A4000 - just finding one is difficult and they go for stupid money, and are 30yo, etc.

https://au.mouser.com/Search/Refine?Keyword=MCF530X

Only the MCF5102 can potentially be used since it has extended 68040 code compatibility, the rest are very much incompatible with Amiga 68k software.

i.e., the custom chips, IO, etc. would be hosted via mister, the processor+RAM expansion would do most of the grunt work and access the chipset via the header? Obviously this would need re-work of the core to accommodate but would (I guess?) be less work that designing/testing/etc. a new CPU core?

Easiest path to fast CPU+FPU is to use software emulation on the ARM.

[throAU]

Hm, now you make me wonder... you don't have a MiSTer, do you?
You are not aware that the Minimig based core for MiSTer already can configure 384MB of FastRAM, that is DDR?

Have a mister + 128 MB expansion and use it, including for minimig. Had a couple of real amigas in the past.

Maybe I should clarify my thinking (which may not be clear) behind putting the RAM and CPU on the same board: to enable VERY fast access to the hosted RAM from the add-on CPU without needing to go over the expansion IO to the DE10 - and use that purely for the custom chips implemented in the mister.

i.e., the CPU+RAM board has its own very fast ram via a local bus on the expansion board, and the Mister simply becomes an amiga chipset (or AAA or AAA+ or even more advanced no-yet-existing follow up amiga compatible chipset - but for now, AGA) accessed via the GPIO header - rather than the processor living in FPGA and accessing memory via the relatively slow GPIO header.

Just a thought experiment anyhow (hence, "thinking outside the box" - as in outside of the mister FPGA for a CPU upgrade ) - as many have said, I personally think that if you want a fast amiga just use WinUAE, and if you want to actually get work done with apps needing fast hardware, use a modern platform. Was thinking it may enable much faster than CPU emulation via the ARM HPS - because the ARM side in the mister is not particularly fast?

I do think if you want a super-fast "amiga" CPU, you probably want to go PPC anyway. There already exists add-on PPC accelerators, they've been around for real hardware for ages...

[Bas]

These threads sort of got me wondering. There is a lot of push-back against the ideas proposed here: FPU, MMU and faster clocks. The whole reason why I'd want any of these would be to open the platform up to more software and I'm quite aware that said software would be very much niche.

As it stands now, the MiSTer gives me a damn near perfect Amiga 500 for which I'm intensely grateful. I never owned anything faster than that myself so I can't really compare the AGA bits with any real systems.. but I'm guessing the A1200 is also fairly well covered by MiSTer these days.

Assuming that I'm not too far off the mark with the above, what else would the future development path of Amiga on MiSTer be if not the niches already described?

[lordoftime79]

I thank you guys for educating me on how FPGA's work - this is all very interesting! So then why not replicate a buffee or PI storm and have a option in the core to use the ARM CPU to emulate the amiga CPU at a much faster speed (as thats what those projects do)

[throAU]

As it stands now, the MiSTer gives me a damn near perfect Amiga 500 for which I'm intensely grateful. I never owned anything faster than that myself so I can't really compare the AGA bits with any real systems.. but I'm guessing the A1200 is also fairly well covered by MiSTer these days.

I used an A1200 a fair bit back when they were current and IMO the Mister is a comparable experience with faster CPU.

Compatibility with Mister is better than I remember with the A1200 hardware in fact, as it is trivial to simply boot a different configuration fairly fast (bearing in mind my A1200 was hard drive rather than booting from flash) rather than relying on relokick floppies or hardware switches to go back to kickstart 1.3, going into the boot menu to turn off the 68020 cache (non-original amiga users may not even know about holding down both mouse buttons on boot to access the equivalent of UEFI/BIOS on kickstart 3.x - which still works in Mister when using kickstart 2.x/3.x), etc.

Sure, the FPGA compatibility isn't perfect, but vs. using a real A1200 when they were released, there's far less quirks to deal with using Mister today than there was on real hardware in the early-mid 90s until/unless you used various work-arounds.

[ericgus09]

I thank you guys for educating me on how FPGA's work - this is all very interesting! So then why not replicate a buffee or PI storm and have a option in the core to use the ARM CPU to emulate the amiga CPU at a much faster speed (as thats what those projects do)

I think something like that is in the works .. but you didnt hear it from me and thats all I know about it.