Vamiga: Moira on Raspberry Pi

[dirkwhoffmann]

Has someone got a working Raspberry Pi toolchain installed?

It would be interesting to see if Moira compiles out of of the box and if the test runner could be executed on the Raspberry (I am wondering how fast it would be 🤔). I have no plans to port vAmiga to the Raspberry, but I'd like to make Moira as portable as possible.

https://github.com/dirkwhoffmann/Moira

[dirkwhoffmann]

Here are some interesting runtime results:

With the latest version on Moira, it seems I have achieve the impossible: to outperform Musashi.

Moira on macOS (clang compiler, -O3): 😎

Moira on Linux (gcc compiler, -O3): 😎

Moira on Windows (VisualStudio, release mode, runtime optimisation enabled): 😲

On Windows, Moira runs 50% slower than Musashi 🙈. How can that be? 🤔

BTW, when looking at absolute numbers, my old gaming PC still seems to be a performance beast compared to my MacBook Pro. So sad that it runs Windows, only.

Maybe I configured something wrong in VisualStudio. I am not familiar with it and had to google each and every step to make it (finally) compile my project.

[mithrendal]

Good news for the climate on mother earth. 😎👍🏻

Do you think it is possible to compile it to webassembly (wasm) ? maybe moira runs faster then the cpu of SAE?

[dirkwhoffmann]

I have trouble installing it on macOS Mohave.

I grabbed it via brew install emscripten which worked out fine. After completion, it told me:

Manually set LLVM_ROOT to
  /usr/local/opt/emscripten/libexec/llvm/bin
and comment out BINARYEN_ROOT
in ~/.emscripten after running `emcc` for the first time.

I did exactly this, but when I run emcc hello.c, it terminates with an error message 😕:

...
cache:INFO: generating system asset: generated_struct_info.json... (this will be cached in "/Users/hoff/.emscripten_cache/asmjs/generated_struct_info.json" for subsequent builds)
cache:INFO:  - ok
shared:ERROR: BINARYEN_ROOT must be set up in .emscripten

Have you been more successful on your machine?

[dirkwhoffmann]

Installing on Linux Mint was much easier, so I tried to compile Moira there. Running emcc worked and it produced a.out.js and a.out.wasm. However, running node a.out.js aborts with an error 😢:

Some local count is too large. Any ideas? 🤓

[dirkwhoffmann]

OK, compiling with -O1 did the trick (I started with -O0):

I should be able to execute it inside Chrome, right?

[dirkwhoffmann]

OK, it worked. I can run Moira inside Chrome and I can see the output in the debug console:

But please remind me. Why exactly are we doing this? 🙄

[dirkwhoffmann]

Runtime comparison Web Assembly with -flto -O3:

Moira feels like a lame duck against Musashi here... 🐥

[mithrendal]

Oh sorry, I am back just now. I was disturbed by my 👫...

But please remind me. Why exactly are we doing this? 🙄

Yes it was only a question whether it is possible. But you just proved it, by doing it, nice.
I had in mind to maybe investigate to convert vAmiga into a Webapp which draws itself into a HTML5 canvas. It is much quicker as I thought. Do I interprete the values right, when I say that webasm does the job quicker than on macos ?? Oh no you did run that webasm version on your faster PC right, but still nearly catches up the values of the visual studio version...

[dirkwhoffmann]

Oh no you did run that webasm version on your faster PC right

No, I did run it on my MacBook (Linux Mint runs on my MacBook in a VM and Chrome runs natively). It's almost certainly impossible that the webasm version runs faster. Hence, I expect that the timing measuring code is unreliable (at least when comparing the numbers across machines or operating systems).

[mithrendal]

Have you been more successful on your machine?

I have an older version of emscripten on macos, which I downloaded two years ago and it is still working fine, never upgraded. I downloaded it back then directly from the projects site. But today I would also go the brew way...

I think webasm conversion is interesting but I do feel much more interested in seeing Moira fly in vAmiga now. Maybe I come back to the webasm stuff later. You have done such a huge step in completing a custom CPU which computes in a much more compatible way. Now I want to test out the Moira-Advantage on all those good and problematic games. What do you plan as the next steps ? Maybe to complete the slowBlitter integration ?

[dirkwhoffmann]

I think webasm conversion is interesting but I do feel much more interested in seeing Moira fly in vAmiga now.

Yes, that's my feeling too. I think Moira is well tested by now and probably the most reliable vAmiga component at the moment.

What do you plan as the next steps ?

The next natural step will be to implement bus sharing between Moira, Agnus, and the Blitter. Theoretically, it should be easy, because there are only two things to do:

• Add code to Moira::sync() that executes Agnus to the point in time the CPU has already reached. Now, since we have Moira instead of Musashi, the exact target cycle is known.
• If Chip or Slow Ram is accessed, check if the bus is free. If it isn't, execute Agnus until it is. The elapsed extra cycles are the wait states that have to be added to the CPU clock.

After that, all timing related vAmiga tests should be rerun. This will be the moment of truth. The outcome of these tests will tell us where the vAmiga project really stands.

[dirkwhoffmann]

Here are the results of the first medical examination. Pulse readings (aka interrupt timing) indicate that Moira is quite a healthy girl:

vAmigaTS test case Paula/INT/int1:

Amiga 500 🥰:

vAmiga (Musashi) 🤭:

vAmiga 0.55 (Moira) 😎:

[mithrendal]

only Moiras last line (the 12th) does not match the original output, I am now looking into the test program to understand what you did there...

the 12th line starts with

level4InterruptHandler:
    move.w  #$F00,$DFF180   ;red
    nop
    move.w  #$0F0,$DFF180  ;green
    nop
    nop
    move.w  #$00F,$DFF180 ;blue
    nop
    nop
    nop
    move.w  #$000,$DFF180 ;black
    rte

does a couple of NOPs
dc.w $01FE, $FFFE ; NOP

only one more compared to the 11th line before starting the interrupt level5 handler

level5InterruptHandler:
    move.w  #$00F,$DFF180    ;blue
    nop
    move.w  #$FFF,$DFF180    ;white
    nop
    nop
    move.w  #$F00,$DFF180   ;red
    nop
    nop
    nop
    move.w  #$000,$DFF180  ;black
    rte 

Now I see it, the real machine A500MMSE on the 12th line does first execute the level5 handler and after that the level4 handler. Whereas the 11th line on a real A500 does not execute the level5 handler at all.

In contrast Moira on the 12th line misses to trigger the level5 handler. Line 11th is ok, same as on a real machine.

[dirkwhoffmann]

I didn't look into the test case in detail yet, but the faulty line could also be related to Paula. When INTENA or INTREQ are written, it needs some time until the new IRQ level shows up on the IPL pins of CPU. It might well be that the current delay is wrong by a cycle or two. Also, it might make a difference whether the CPU or Copper writes into those registers.