MiSTer FPGA Forum

Pop this on your sd card, then start the minimig hybrid core:
https://github.com/scrameta/MiSTer_Hybrid_Support

I’m using TomB’s uae4arm

Interrupts wired up, a bunch of not-needed graphics sound code and threads disabled.

DiagROM seems to be running well.

Real kickstart gives me a yellow screen briefly then it reboots. This is even before getting to the disk prompt etc.

OK, jit from uae4arm lives too.

Next, wire up interrupts again, then to workbench... Tomorrow!

I also think its probably pausing the jit to do other uae stuff, so I should find/remove that too.

I'm trying again to get uae4all working. This code is really non-trivial to tear apart, I've tried about 3 times, so I'm trying to instead get it running with minimal changes. Memory -> point to hps/fpga bright or memory instead GUI -> just make it start straight away video/audio -> point to the dummy device Once that lives I can try turning off so...

So I was thinking, perhaps it'd be better to change how the hard disk works in hybrid mode. Its kind of bonkers to go the route it goes... sd card->ide.cpp->spi->fpga->hps/fpga bridge->qemu :lol: It'd probably make more sense to go sd card->qemu. I've noticed the MiSTer poll slows down when qemu is used. I don't know yet if this is cpu contention o...

Well I updated a new core and matching qemu with what I have to github - hardware description, patched qemu and the compiled setup one: https://github.com/scrameta/Minimig-AGA_MiSTer_Hybrid https://github.com/scrameta/qemu_MiSTer_Hybrid https://github.com/scrameta/MiSTer_Hybrid_Support The changes did not give as big a boost as I hoped, though they...

Some promising experiments with fifos for immediate write completion and pipelined reads...

Anyway long story short, there is a 10 cycle (at 114MHz) 'waste' overhead due to the HPS-FPGA bridge. Then another 4 cycles (average) due to clock domain alignment (from 28x7 to 28). So 14 cycles waste per transaction. So I guess we have only ~6 cycles (1.5 cycles at 28MHz) to do the actual memory access to still reach TG68 level memory access perf...

Actually TG68 has a similar pattern on bustest. i.e. slow/fat/slow/fast. Just its fast is very fast!

So I wrote a very simple program in devpac: loop: move.l $100000,d0 move.l $100004,d1 move.l $100008,d2 move.l $10000c,d3 move.l $100010,d4 move.l $100004,d5 move.l $100008,d6 move.l $10000c,d7 jmp loop Which I captured in signaltap, specifically the chip sdram reading signals. Firstly here is how it looks on TG68: read_tight_loop_unrolled_tg68.png...

Well faster ram is always good. It doesn't help with this bottleneck much probably. Although... there are always alternative approaches. In this one I took the approach of leaving the core mostly intact. Then I plumbed in the CPU emulator using the HPS-FPGA bridge to access chip ram and hardware registers. I think we're stuck with the HPS-FPGA brid...

Yes it seems stable at 1.2GHz. Though I didn't run it for long... I'm investigating speeding up the chip/chipram access. This goes via the full HPS-FPGA bridge. I have a few thoughts on this: i) Frequency the bridge is clocked at. ii) Increase bridge width iii) Try the lightweight bridge (supposed to be faster) iv) Burst support So far on these: i)...

It’s reserved for fpga but you can still mmap it from the Linux side. Though the cpu cache is disabled by default, so it’ll be slow without enabling it. eg https://github.com/scrameta/MiSTer_Hybrid_Kernel_Module

Some thoughts on chipram speed...

Actually on the bustest qemu does about the same as an A1200 (6MB/s). However the TG68k does much better than the A1200 (18MB/s).

The ARM should be able to benefit from the same, even if its own caching is off. However its after the HPS-FPGA bridge bottleneck.

So, since I vanished since January did anyone try anything fun with this? Aranym jit, emu68k?

I also noticed in sysinfo that 'chip speed vs A600' is 12 for the tg68k. Its about 3.18 in qemu.

Now 701545*12/3.18 =~2600000. Very similar to the drive speed fraction, hmmm.

One more data point, at 1200MHz Musashi is still not worth it. Still significantly slower than TG68 (like 30% of the speed...). Qemu seems worth it, other than the latency...

Now, back to "why does it feel slow".
Sysinfo drive speed (DH1):
with ARM as cpu: 701,545 bytes/second
with 68020 soft core: 2,665,871 bytes/second

So drive reads are almost 5x slower, which would make things like browsing disk feel slow. All down to interrupt latency?

Real dhrystones:
400MHz: 47169 dhrystones/s, 26 DMIPS (and mouse jerky!)
800MHz: 84033 dhrystones/s, 47 DMIPS
1000MHz: 126582 dhrystones/s, 72 DMIPS
1200MHz: 169491 dhrystones/s, 96 DMIPS

So with the overclock patches on my rt kernel and sysinfo fake dhrystones:
400MHz: 4368, 4.6 Mips, 1.3 Mflops
800MHz: 35589, 37.1 Mips,9.6 Mflops
1000MHz: 50494, 52.7 Mips, 13.6 Mflops
1200MHz: 65776, 68.7 Mfips, 17.6 Mflops

No, I'll have a try.

I was just trying it with the preemptive kernel patch (https://mirrors.edge.kernel.org/pub/lin ... s/rt/5.15/). It boots and works though didn't feel better in workbench, though I've not actually measured interrupt latency with it.

I updated qemu, but it failed with an unaligned access exception. So I've not committed that build for now. This is the issue I had before with the last update until I found a single qemu patch to revert(https://github.com/qemu/qemu/commit/0ca ... 8ef78de5f4). I tried the equivalent change, with no improvement.

Updated core and MiSter here in here:
https://github.com/scrameta/MiSTer_Hybrid_Support

They seem to work fine.

I checked musashi, no changes on github. There are updatee to qemu, I might give it a spin to see if it works but don't expect anything significant.

I updated my mister. The kernel build did change, but the version is the same. I guess just a recompile to change settings. So, the modules do not need recompiling. If I put back the old patched MiSTer binary from here (https://github.com/scrameta/MiSTer_Hybrid_Support) then minimig hybrid still works. Anyway I'll update and rebuild the core and pa...

I’d love more work put into a faster 680x0 core. Hybrid is all well and good, but the latency and timing on a real core will be much tighter. I also prefer real logic.

I did that at first, but I was sketched out by the chroot folder needing to be inside linux.img (after expansion), and then it might also disappear at any update in the future. I did the reverse instead, just made mister packages for said other distro: https://github.com/amstan/MiSTerArch . I was installing dosbox from the package manager in it fo...

I got the audio underrun error too. I didn’t look into this or the file select crash since it was enough to get a quick benchmark.

Here is the uae4arm.sh emulator binary. Again I built it on ubuntu armhf so its a non-compatible lib stack so comes complete with libs and a script to start like qemu. http://www.64kib.com/mister_hybrid_files/uae4arm_dir.tar.gz Extract it then cd into the folder and run uae4arm.sh Best to do it on the mister video screen after pressing F9 on menu. ...