MiSTer FPGA Forum

Posted: **Sat Mar 06, 2021 1:39 am**

Tbh having a 68040/60 option would be great as a dev environment for me. Having a super small sized ASM dev setup to dabble into Amiga coding without having to break the bank on a warp card (and equally capable 68060) would do wonders to the current Amiga demoscene.

And no, a WinUAE dev setup really isn't optimal for that. It's fine for the basics but not for any kind of serious scene work imho

Also I would love if we could get a 68030/40 core to open up Falcon core development

Posted: **Sat Mar 06, 2021 2:02 am**

I agree I really do think the Mister core has potential for so much more than just playing the old Amiga games - lets use it!

Posted: **Sat Mar 06, 2021 2:04 am**

Fularu wrote: ↑Sat Mar 06, 2021 1:39 am Tbh having a 68040/60 option would be great as a dev environment for me. Having a super small sized ASM dev setup to dabble into Amiga coding without having to break the bank on a warp card (and equally capable 68060) would do wonders to the current Amiga demoscene.

And no, a WinUAE dev setup really isn't optimal for that. It's fine for the basics but not for any kind of serious scene work imho

Also I would love if we could get a 68030/40 core to open up Falcon core development

Yep !!!

Posted: **Mon Mar 08, 2021 11:24 am**

Just a quick question that's kind of related, although not directly to speed...

One of the main things that I use an Amiga for is watching demo's. Love 'em. Now I know they are a problematic use case because so many do timing related things and so on. I see a lot of AGA demos with issues that don't have issues on other systems (Vampire, my 060 GBA1K, etc) and after following the discussion here, I'm wondering if using 68000 instead of 68020 would maybe help? Can you even use 68000 with AGA? Didn't the A1200 have 02/AGA ? I'll go and try that idea out and see what happens!

Also, I'd like to see an FPU for demos. I can always manage to find the few that want an FPU and refuse to run

Oh, PS: On the topic of Vampires. With the addition of RTG, I think MiSTer is getting near as good as Vampire. It already does RTG better. I had one for 5 months last year and sold it again. Primarily because it just couldn't deliver what it was sold as delivering which was 1920x1080@60Hz. I still keep an eye on them with a view to buying back in again one day and as far as I know it still can't achieve the advertised resolution(s). Clearly this is personal, and not everyone's use case, but for me the RTG is primarily for Workbench and a few SDL ported games and the rest is down to PAL. MiSTer is pretty well getting there for me in that regard now.

Posted: **Mon Mar 08, 2021 4:52 pm**

OK, so of course, you can't have AGA on 68000 since the A1200 was an 020 machine and that's what the A1200 ROM is expecting. At least that's why I assume that it won't boot for me if I try that.

What's really bugging me now is that once today, just once, I had a demo run perfectly on me that I haven't been able to get to run OK before or since. Mesmerized by PMC. (warning: the tune is an ear worm!) Try as I might I can't workout which combination of settings, ROM and OS it worked with. Probably not helped by the fact that it may not have been from a cold boot.

Anyway, that's got nothing to do with this thread!

Posted: **Mon Mar 08, 2021 4:55 pm**

AGA is absolutely compatible with the 68000, despite never having been shipped in that configuration.

Posted: **Mon Mar 08, 2021 6:16 pm**

Must have been something else with my config stopping it from booting then which wouldn't surprise me at all. It looks a lot like my HDF is just a clone of my 060 machine that I've tweaked a bit but I can't really remember what I did to build it.

My problem is solved now anyway. I feel rather dumb admitting this, but I almost always set "Video area by : Blank+" in the OSD options. Simply because it tends to fit my screen better. Of course, I guess it also changes /VBLANK - because that was the setting preventing a lot of my demos from working properly. Setting it back to "Blank" and now the ones that weren't working before miraculously are. Where's that facepalm when you need it !!

So basically, ignore me. This is pretty sweet now. FPU would be sweeter, but other than that...

Posted: **Tue Mar 09, 2021 10:49 am**

FEMU works, but is super slow (using the math libraries). What potentially could be done, is to use FEMU as a starting point for FPU emulation on the ARM processor.

Posted: **Tue Mar 09, 2021 11:14 am**

kolla wrote: ↑Tue Mar 09, 2021 10:49 am FEMU works, but is super slow (using the math libraries). What potentially could be done, is to use FEMU as a starting point for FPU emulation on the ARM processor.

It would also be possible to implement some FPU functions as memory-mapped registers which an FEMU-type program could poke. Is FEMU's source available?

Posted: **Tue Mar 09, 2021 11:28 pm**

https://github.com/nonarkitten/femu

Posted: **Wed Mar 10, 2021 6:42 am**

hi can someone make a build package ready to install please ?

Posted: **Sat Mar 13, 2021 8:44 am**

breiztiger wrote: ↑Wed Mar 10, 2021 6:42 am hi can someone make a build package ready to install please ?

What do you mean by “a build package”?

I have dockerfiles for building kernel and firmware, building the minimig core is still a “manual” job that takes place in Windows (AFAIK).

Posted: **Sat Mar 13, 2021 8:47 am**

i have understand it's code for amiga 68k gcc and execute on maiga side

isn't that ?

Posted: **Sun Mar 14, 2021 3:28 pm**

I think he means the fpu emu

Posted: **Mon Mar 15, 2021 8:28 am**

oh, that - http://amiga.kolla.no/femu.zip

Posted: **Tue Mar 16, 2021 8:41 am**

thanks a lot !!!

Posted: **Sat Mar 20, 2021 4:20 pm**

The new https://www.buffee.ca/ accelerator project (love the name) is very interesting and could be a possible future solution. Buffee is using an ARM processor for 680x0 emulation/JIT and interfaces directly with Amiga hardware (currently OCS/ECS based systems). But thanks to Buffee being open source as well, the software portion of it could be adapted for the Mister.

https://github.com/nonarkitten/pseudo-jit

Posted: **Sat Mar 20, 2021 5:49 pm**

richx wrote: ↑Sat Mar 20, 2021 4:20 pm The new https://www.buffee.ca/ accelerator project (love the name) is very interesting and could be a possible future solution. Buffee is using an ARM processor for 680x0 emulation/JIT and interfaces directly with Amiga hardware (currently OCS/ECS based systems). But thanks to Buffee being open source as well, the software portion of it could be adapted for the Mister.

https://github.com/nonarkitten/pseudo-jit

Kinda cheating is it not? .. if you are doing that, might as well run FS-UAE emulator in frame buffer mode like Basilisk II does .. but thats kinda defeating the entire purpose of the mister/fpga to recreate the hardware not run a software emulator.

Posted: **Sat Mar 20, 2021 7:32 pm**

ericgus09 wrote: ↑Sat Mar 20, 2021 5:49 pm Kinda cheating is it not? .. if you are doing that, might as well run FS-UAE emulator in frame buffer mode like Basilisk II does .. but thats kinda defeating the entire purpose of the mister/fpga to recreate the hardware not run a software emulator.

Not exactly, it would probably be the fastest CPU option with the current Mister setup, while still using the FPGA side for the Amiga hardware. Sure, a 68060 performance level FPGA core would be a very nice option as well, but other than the closed source Vampire, I'm not aware of any others yet.

Posted: **Sun Mar 21, 2021 12:09 am**

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.

Posted: **Sun Mar 21, 2021 3:13 am**

zakk4223 wrote: ↑Sun Mar 21, 2021 12:09 am 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.

Posted: **Sun Mar 21, 2021 9:13 am**

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

Posted: **Sun Mar 21, 2021 11:00 am**

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.

Posted: **Mon Mar 29, 2021 6:10 am**

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

Posted: **Mon Mar 29, 2021 7:53 am**

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

Posted: **Mon Mar 29, 2021 10:59 am**

lordoftime79 wrote: ↑Mon Mar 29, 2021 7:53 am 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!

Posted: **Mon Mar 29, 2021 4:28 pm**

robinsonb5 wrote: ↑Mon Mar 29, 2021 10:59 am 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.

Posted: **Mon Mar 29, 2021 5:00 pm**

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?

Posted: **Mon Mar 29, 2021 6:06 pm**

lordoftime79 wrote: ↑Mon Mar 29, 2021 5:00 pm 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.

Posted: **Tue Mar 30, 2021 12:33 am**

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?

MiSTer FPGA Forum

Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?

Re: Faster CPU for Minimig core?