Porting a Amiga emulator

Hi

I would like to have a go on uae4arm or Amiberry. I think I will do it native and replace SDL with direct RISC OS graphics.
How can I easiest output bitmap graphics in a window? Ideally I want a RGB buffer that I can write to and that is updated in
realtime.

RO native bitmap format is the Sprite

Sprites are manipulated using OS_SpriteOp

However, you have to do a bit more work because in general you will want to use this call which requires scale factors to specify the size and a translation table to map colours from your sprite’s colour depth to the display’s colour depth.

ColourTrans will help create the translation table, and ReadVduVariables is necessary for calculating your scale factors correctly.

It would be nice if there were one simple “plot this sprite” call, but there isn’t.

The colour format of the Sprite is selected using a Mode Specifier – you will want &301680B5.

OK. Thanks I will sort it out. In Amiga there is something called rastport that I can use to address a window for graphics. In RISC OS ,do I need to follow the coordinates of the window and how does it handle expose events if just painted directly to screen memory?

One thing that I can’t find is where the buffer is that I can write to.

When the window is exposed you get a Redraw Event from Wimp_Poll – the Wimp will already have set a clipping rectangle to protect everything but the exposed part of the window. You work out the offset required by looking at your window’s coordinates (and scroll offsets) and do the sprite plot.

where the buffer is that I can write to

If you mean your sprite, you create a sprite area which is just a large memory buffer, then you create a sprite in there of the required colour depth and dimensions with this call – you can work out the address of the first scanline within that sprite very easily from the definition of a sprite area and the sprite itself, or you can use this call to get the address of the sprite (you still have to offset to the scanlines).

That will allow you to redraw your window on demand, but if you are an emulator or a game, you will want to animate your window. That means asking (or telling) the Wimp to change your window.

Wimp_ForceRedraw is used to ‘dirty’ the window so you will be asked to redraw it by the above redraw event. Faster though is to use Wimp_UpdateWindow which allows you to start redrawing immediately (instead of waiting for the Wimp to return a message asking you to do what you’ve just asked it to ask you!).

Thanks. I just did some sprite plasmas (animations) and it works as expected. I just plotted them to screen.
Next step is the redraw thing.

Hmm

I might need to crosscompile afterall..
cc1plus: out of memory allocating 8392703 bytes after a total of 28332032 bytes
make: * [src/arosrom.o] Error 1

Do you have Aemulor active?

Do you have Aemulor active?

Nope.

http://safir.amigaos.se/bildgalleri/users2/17058_20180410_230337.jpg

Some progress. None of the ARM specific emulator builds easily, but e-uae does.

http://safir.amigaos.se/bildgalleri/users2/17060_20180411_185547.jpg

:)

A bit crashy when I quit it , but it starts.

Just played some Out Run on it , worked great!

Just played some Out Run on it , worked great!

Now I’m interested. I liked that game (about the only one I wasn’t rubbish at, that and Chuckie Egg).

Hmm, I had an arcade emulator which could play Outrun (slowly) on my Pi. I don’t see it now. I wonder where it went? Still, didn’t use it much – too slow.

BTW, please try to keep images directly posted to the forum to a maximum of 600-800 pixels wide. NetSurf isn’t smart enough to size the image to fit the display… :-/
So the “Save reply” button is waaaaaay over there on the right. :-)

BTW, please try to keep images directly posted to the forum to a maximum of 600-800 pixels wide. NetSurf isn’t smart enough to size the image to fit the display… :-/ So the “Save reply” button is waaaaaay over there on the right. :-)

Removed he embed.

The only problem is sound. I am using SDL right now and sound is just super bad. It is the same in Fuse (Spectrm emulator). I
bet it also slows down the emulator (it did with Fuse). So the question is .. can RO cope with sound under extreme load?
I am planning to do native graphics, So SDL will be gone sooner or later.

I have started with native graphics. But something is wrong, my pixelbuffer is always empty and UAE never calls any flush.

The OS takes the following approach to sound:

• Audio is double-buffered; the hardware will be playing from one buffer while the OS is filling the other
• To minimise latency, the default buffer size is quite small (typically 10ms of data)
• Buffer filling is performed from the audio interrupt handler

So for audio which is deterministic (e.g. playing a WAV from RAM, or playing a tracker file), and which isn’t too CPU intensive (so it can run in the interrupt handler), RO’s audio is very reliable. The only thing that will cause hiccups is if something is naughty and disables interrupts for a long period of time, or if a sub-optimal configuration is used. E.g. I think the Pandaboard ends up with 2.5ms buffers by default, because the default buffer size the OS uses was chosen for 22kHz output, but the lowest rate supported by the Pandaboard is 88kHz.

For audio playback which can’t run from IRQ (e.g. it needs to stream from disc/network, or it’s being generated by a complex program like an emulator) then the program/player must create and manage an intermediate buffer of its own. I’m not familiar with how the RISC OS version of SDL handles audio – whether it uses an intermediate buffer or not – or exactly how many steps there are between SDL and the OS (I know that UnixLib tends to use the DRenderer module for audio, and that module has had some problems in the past). Maybe the emulators have buffers as well. And if they’re using pthreads (e.g. they have a dedicated audio thread) then that’ll be another potential source of problems (I’m not sure how good the thread scheduler in UnixLib is)

Maybe Chris Gransden will spot this thread and provide some advice, since he seems to be king of porting apps & games.

BTW, please try to keep images directly posted to the forum to a maximum of 600-800 pixels wide. NetSurf isn’t smart enough to size the image to fit the display… :-/

Rick, please report issues to http://bugs.netsurf-browser.org/

We only stumbled across https://www.riscosopen.org/forum/forums/1/topics/5375?page=2#posts-73327 recently by chance. Anyway, it should be fixed in CI build 4319 (2nd April 2018) or later.

Lots of things seem to affect sound.

The portable module seems to cause CPU clock scaling to reduce CPU clock. It doesn’t seem to take any notice of anything using pthreads.
If the emulation is using all the available cpu resources then sound starts to stutter badly. Amiga emulation struggles on anything less than Cortex-A15. Compiling everything with ‘-mfpu=vfp’ can help.

Amiga emulation really needs a JIT to run fast enough on recent RISC OS hardware.

Removing the overhead of the SDL libraries should be a big help.

Retroarch uses PUAE v2.6.1 which seems faster than E-UAE. Just about runs fast enough on a RPi 3.

The portable module seems to cause CPU clock scaling to reduce CPU clock. It doesn’t seem to take any notice of anything using pthreads.

True – the code in the Wimp which controls the clock scaling basis its decisions on how many null poll events there are per second. So it’s conceivable that a pthread for managing the Wimp frontend could trigger hundreds of null poll events per second, fooling the Wimp into thinking the system is idle, when in reality there are some other pthreads within the same task which have lots of work to do still. (maybe try calling pthread_yield after receiving each null poll event, if I’ve guessed the problem correctly? and of course make sure the app is configured to receive null poll events, otherwise unixlib’s thread scheduler won’t have a chance to run at all)

But there are also some more general issues caused by the OS’s lack of support for threading. E.g. if a pthread thread calls OS_Byte 19 to wait for VSync, that will block all of the threads until the VSync occurs (plus all other Wimp tasks, if it’s a wimp app).

Rick, please report issues to http://bugs.netsurf-browser.org/

Sorry, it’s been like that for such a long time that I’m guilty of the “they already know about this” syndrome. ;-)

I’ll look up the CI build mentioned. Thanks.

Amiga emulation really needs a JIT to run fast enough on recent RISC OS hardware.

I am trying to build uae4arm. But since it needs vfp I need to rebuild every depend .. at least I think so , get “uses vfp but target does not” on every object.

A quick way to build everything as vfp by default,

rename <path to your gccsdk>/cross/bin/arm-unknown-riscos-gcc to <path to yourt gccsdk>/cross/bin/arm-unknown-riscos-gcc.orig
and <path to your gccsdk>/cross/bin/arm-unknown-riscos-g++ to <path to yourt gccsdk>/cross/bin/arm-unknown-riscos-g++.orig

create arm-unknown-riscos-gcc containing,

<path to your gccsdk>/cross/bin/arm-unknown-riscos-gcc.orig -mfpu=vfp -mcpu=arm1176jzf-s "$@"

and

arm-unknown-riscos-g++ containing,

<path to your gccsdk>/cross/bin/arm-unknown-riscos-g++.orig -mfpu=vfp -mcpu=arm1176jzf-s "$@"

then chmod 775 both newly create files.

Thanks for the compiler tips. I have now managed (after a lot of headache and no sleep)
build uae4arm. If I start it from cli (not taskwindow) it starts up its gui.But the
emulator dosn’t works just stops with a pthread error (gathered from *spool).
I have not implemented vsync , so that is one cause to error.
So what is the best way of waiting for vsync in riscos? Nevermind found out.

It crahes before vsync is used. Probably in sound.