SDL1 open issues

It is most likely that there will be no SDL1 improvement due to the problems of the QEMU G4 Pagasos SM502. SDL is outdated.

I have posted a "hack" patch (working version) for SDL. If anyone would be able to take a look at it thank you very much.
The SDL code does not change for anything other than Pegasos2/G4/SM502. The rest of the AOS4 hardware remains safe.

https://github.com/AmigaPorts/SDL-1.2/issues/5


Thank you

@smarkusg

I'm worried about a potential issue if application requests 32-bit bitmap but gets 16-bit. If application doesn't check what it gets, then it will crash probably or at least render incorrectly. EDIT: I forgot SDL actually allocates a shadow surface so application should get bpp it wanted.

Maybe we can write a small example which tries to render in 32 8-bit (like XRick), and test that on QEMU and others?

EDIT: fixed some issues in original response.

@Capehill

No problem - I will send you my @ on PM(you don't have to reply if you don't want to). Send me the code to check and I will recompile and check

Thanks !!!!

----------

Just a little more info for people who may come across this thread and read- QEMU, it doesn't work, it doesn't work well and they may misinterpret something.

There are currently three emulation machines on which you can run AmigaOS 4.1 FE.
sam460ex, pegasos2 and AmigaOneXE (not yet in the stable QEMU release as of 7.11.2023).
The current best performing one is the pegasos2. If the "machine" is run with a G4 processor (default value) I may experience problems with the SDL1 library.
You can run it with a G3 processor ( add the -cpu G3 option at startup) - then there are no problems with SDL1. It runs stably and possibly even faster in some cases.

AmigaOneXE emulation is mainly intended for people who own or have owned a real AmigaOneXE and have the operating system.
They then don't have to incur any costs to buy an operating system to run QEMU/AOS4 on their current hardware. I would add from myself - if there are one..five.... twenty former AOS4 users who can't own real PPC hardware and run the emulation, it will be a success.
On this emulation there are no problems with SDL1 with a G4 cpu.

*) information about AmigaOneXE comes from the maintainer of the above mentioned machines at QEMU - Zoltan Balaton

@smarkusg
The interesting part is that SDL1 only has problem on pegasos2 while it works on amigaone (SDL2 works on both). Since these two machines use the same code in QEMU (except the north bridge/system controller but that's only maps things in memory so does not contribute to graphics functions) I wonder how can this be? I'd expect this to either work for both pegasos2 and amigaone or be broken on both but not what we see here. So it may mean that either the AmigaOS versions for these machines (kernel or some library?) or SDL1 itself contains some code that detects this and handles it but it's only activated on amigaone and not for pegasos2? If that's the case then fix should be to activate that for pegasos2 rather than hack around it.

We're using siliconmotion502 driver which is limited to 16 bit due to some graphics library issue not supporting the format this display controller uses and this chip is found on sam460ex but not normally on amigaone or pegasos2 so it's strange why only pegasos2 has a problem with it and what makes it work with amigaone. I don't see anything that could explain this in QEMU as that's using the same code for both machines so it should be something running on the virtual machine so something within SDL, AmigaOS or firmware (but the firmware is not really involved in graphics either so not likely to have a role in it either). Is there anything SDL does differently on amigaone and sam460ex compared to pegasos2?

@balaton
I understand this very well. But what should someone do who wants to compile code that is based on the old SDL1 ?
He has to keep waiting for something that someone can discover.... or it will not be fixed at all. He can possibly compile the program with the dynamic SDL1 library and in the future the old one with the "hack" will be replaced.
As @jorg wrote, dynamic libraries are not shared anyway.
That still leaves sdl12-compat possibly ...
You have to see it from the other side how I look at it

@smarkusg
I get that, just wanted to say that hacking things to work without thinking why it's broken might fix that case but break something else and then we're at the same place. So maybe it would be a good idea to try to get to the bottom of the issue and find out what's actually broken so it can be fixed without breaking something else and getting a better understanding of it. I can't imageine why it works on amigaone if SDL itself or something in AmigaOS does not handle that in which case it could do the same on pegasos2 as well.

@balaton
Quote:The firmware is executing the x86 BIOS ROM of gfx cards.
If the (emulated) SM502 has a x86 BIOS ROM it could be that it's BIOS code changes some endian mode and only works correctly with the SciTech x86emu used by U-Boot, but not with the x86 emulator of the Pegasos2 SmartFirmware?

@joerg
sm501 does not have x86 BIOS, it's not a PCI card only a PCI device that can be plugged as a card in QEMU but it's just the chip. The sam460ex firmware may have some code to init and use this chip to output during firmware but I don't think amigaone u-boot or pegasos2 SmartFirmware would recognise and do anything with an sm501/sm502 (we don't get picture with sm501 on these until AmigaOS boots) so it's the siliconmotion502.chip driver that inits it and sets it up and that driver is the same on all machines (we add it to amigaone and pegasos2). So I think if we see difference that should come from SDL itself or maybe AmigaOS but most of AmigaOS is also the same version for amigaone and pegasos2 except the kernel and some drivers but those drivers are not related to sm501 as that's only on sam460ex version. So unless there's some code in AmigaOS which is always there but only active on sam460ex and amigaone I don't see how could it behave differently on pegasos2.
Do we have the source of the SDL1 version that works on amigaone but has issue with pegasos2? Did anybody look at that source to see if it has something to handle sm502/sam460ex/amigaone which may not work on pegasos2?

@smarkusg

Did you ever try to force XRick to use SDL_SWSURFACE (bitmaps in RAM) instead of SDL_HWSURFACE (bitmaps in VRAM)? Does it change anything?

@balaton

the sm502 driver set chip endianess to big endian writing 0 into register 0x005c.
This seems not to work in PCI mode (the chip remain in little endian mode), but maybe on the Pegasos emulation there is some side effect ?

@Capehill
Quote:

SDL_SWSURFACE I have checked with vo_sdl in mplayer - without any additional tricks it did not do anything. defined here
https://github.com/khval/mplayer-amiga ... ab/src/libvo/vo_sdl.c#L46


To be sure, I will recompile the xrick with "SDL_SWSURFACE" and write if here the result.

EDIT: 9.11.2023

I have recompiled the test programs that are included in the SDL sources.
Simple programs and you can possibly change the add-on options. I don't have the xrick sources for sd1 on disk anymore and don't have much time to recompile them.
I am sure you are familiar with these test programs - if you need to test any of the options, please let me know.

https://ibb.co/7t4S8Lj


with "testpalette" forcing -hw (SDL_HWSURFACE) crashes my system.
I guess that means SDL_SWSURFACE is used all the time by Qemu and SM.
The SDL -hw hack works, but it definitely does not use SDL_HWSURFACE

All in all, after further consideration, I think there is probably no point in using the hack, but rather in fixing the cause of the problem as @balaton wrote.
At the most QEMU Pegasos 2 for the time being with G4 cpu emulation will work with problems until a possible solution of the problem.
As I wrote above - if you need to test something let me know.

thank you in advance for your help

@m3x
In QEMU only little endian mode is supported, you should get a log message about it when running with -d unimp if you try to switch to big endian. I don't see such logs so I don't think the driver is switching to big endian. According to chip docs value 0 is the default and means little endian so maybe that's why it stays in little endian? Emulating this in QEMU would not be easy though, a device can be big or little endian but switching between the two is not really supported so if the driver does not do that yet and works in little endian already then please don't change it. (Or you can but then we'll likely have to stick with old driver version on QEMU.)

I've asked it before somewhere but can't find the post now: The latest sm502 driver version only seems to work with 4.1 FE Update 2 but not with vanilla 4.1 FE on the install CD. This is a problem when installing AmigaOS on QEMU because people can't use the latest sm502 driver but have to install with an older sm502 version from 4.1 Update 3 then install 4.1 FE updates before they can install the latest sm502 driver. Is there a way to support 4.1FE without updates as well to simplify this installation?

Here's my original question with more info:
https://www.amigans.net/modules/newbb/ ... id=143798#forumpost143798

@balaton

could be a compilation problem, as I used a different gcc, will try using another one.

@m3x
Thanks, we'll try it when you post it.

Other question was if you have souces for AmigaOne XE u-boot. We'll have emulation of this machine in upcoming QEMU but we can't include the firmware binary without source so people will have to download separately. The sam460ex sources were public so that u-boot is included with QEMU so sam460ex emulation just works. It would be nice to have the same for amigaone too but the sources of that seem to be lost, so only hope if somebody like you who had it before still has it somewhere. I've tried to reconstruct it from the partial sources that were in upstream u-boot long ago and while I can compile it it seems to be missing something as running anything from it fails (that is it detects the machine and can use u-boot commands but when it tries to run VGA BIOS or run the boot loader then it crashes with some exception so there must be something missing from these sources). In case you had a source which worked at some point it would be helpful even if it does not compile any more. As these sources are GPL these should be public anyway but Hyperion seems to have lost it so they could not find it any more.

@balaton

I've searched some very old HDs but haven't found anything interesting so far.

@m3xQuote:

It would be very nice of them if they could release an updated version of the Silicon Motion chip that works with AmigaOs4.1 FE without Update 1/2. Of course, only if it doesn't cause too much trouble for you.

My current installation instructions describe the route via AmigaOs4.1 Update 3 (before Final Edition), which is no longer accessible for AmigaOs4.1 FE owners, which also makes sense.

As already mentioned, their driver works very well with AmigaOs4.1 Update 2, but we cannot use it for the main installation under Qemu. If you decide to update this driver again, I would offer myself as a beta tester.



Otherwise we should get back to the actual topic.