By the way, your MilkyTracker images and videos show different colors than usually. Is that some theme or a color channel issue?
Interesting, what should MilkyTracker look like?
I have not changed anything in the settings of MilkyTracker. Even setting the default theme under AmigaOs4.1 does not help. Maybe it is because of Wazp3D, or the 16 bit screenmode, I have no idea.
Ok I was able to reproduce it under WinUae with Wazp3D SDL2 OpenGL, in software mode MilkyTracker works and has slightly different colors. This confirms that Wazp3D is causing the wrong color display. But I still don't understand why under Qemu/Pegasos2 emulation it doesn't switch to software mode if the settings are set for it.
I could also debug it if they tell me what to do. But maybe you have another idea ?
Edited by Maijestro on 2023/4/30 9:15:32 Edited by Maijestro on 2023/4/30 11:11:45 Edited by Maijestro on 2023/4/30 11:28:50 Edited by Maijestro on 2023/4/30 11:41:48
My plan is to provide you a debug binary with serial or console prints because I don't have QEMU yet. Do serial logs work with QEMU (sashimi etc)?
But I will first try to fix the issue with 16-bit mode where "software" renderer is swapped to "compositing" because I can reproduce it myself when SDL_FRAMEBUFFER_ACCELERATION is 0.
My plan is to provide you a debug binary with serial or console prints because I don't have QEMU yet. Do serial logs work with QEMU (sashimi etc)?
I can't answer that exactly, I haven't tested it yet. But Qemu has a serial output, theoretically it should work.You should try Qemu/Pegasos2 it is really incredibly fast. I personally prefer real hardware too, but the availability is very bad.
Quote:
But I will first try to fix the issue with 16-bit mode where "software" renderer is swapped to "compositing" because I can reproduce it myself when SDL_FRAMEBUFFER_ACCELERATION is 0.
Then it seems to be indeed a problem with SDL/Software settings under AmigaOs4.1. Strange that nobody has reported it yet.
Then it seems to be indeed a problem with SDL/Software settings under AmigaOs4.1. Strange that nobody has reported it yet.
Because nobody is using 16 bit screen modes on real Amiga NG hardware? What QEmu seems to emulate is an impossible combination of PReP hardware with OpenFirmware (Pegasos 2), AmigaOne was CHRP using U-Boot instead, and a V'ger or Apollo G4 CPU, but using the Sam4x0 onboard GPU (SM 502). Even on the Sam4x0 systems with onboard SM 502 next to nobody used it (2D only, 16 bit only, way too small max. resolution), but a PCI Radeon gfx card instead, with 32 bit screen modes and 3D HW acceleration.
Because nobody is using 16 bit screen modes on real Amiga NG hardware? What QEmu seems to emulate is an impossible combination of PReP hardware with OpenFirmware (Pegasos 2), AmigaOne was CHRP using U-Boot instead, and a V'ger or Apollo G4 CPU, but using the Sam4x0 onboard GPU (SM 502). Even on the Sam4x0 systems with onboard SM 502 next to nobody used it (2D only, 16 bit only, way too small max. resolution), but a PCI Radeon gfx card instead, with 32 bit screen modes and 3D HW acceleration.
You can help to develop a suitable driver for Qemu or AmigaOs4.1.
Sure the sm502 is not optimal and limited to 16 bit, but for the first time we have a very good alternative to WinUae and also on Mac with m1/m2 chipset and the driver even has 2d acceleration.
And how fast the whole thing already runs you can see for yourself from the many videos. Instead of complaining about it, we should be satisfied with what is currently possible. ZBalaton is already working on a better driver that might be 16/24/32 bit and 3d accelerated, but since he doesn't have any help it will take a long time until it is available.
One more thing Qemu is optimized for 32 bit output and is now limited by the driver to compute everything down to 16bit which requires additional CPU power and yet is the fastest emulation currently available.
@Maijestro Of course it's a good emulation, but with such a strange emulation combination you can't expect that most software works on it. For example my AmigaOS 4.x SFS versions include checks for working and supported CPUs (different CPUs need different code for fast and reliable DMA transfers), and because the default QEmu CPU emulation emulates something completely broken and not supported by AmigaOS 4.x instead it of course refuses to work...
joerg wrote:@Maijestro Of course it's a good emulation, but with such a strange emulation combination you can't expect that most software works on it. For example my AmigaOS 4.x SFS versions include checks for working and supported CPUs (different CPUs need different code for fast and reliable DMA transfers), and because the default QEmu CPU emulation emulates something completely broken and not supported by AmigaOS 4.x instead it of course refuses to work...
I already mentioned that you can use another CPU -cpu g3 or -cpu 7447 which is fully supported under AmigaOs4.1, check that and SFS will not be a problem anymore, also Ranger under AmigaOs4.1 shows the CPU correctly.
Qemu 8.0 Pegasos2 uses in the default setting a G4 7400 CPU so there are of course problems under AmigaOs4.1. ZBalaton is aware of the problem and with Qemu 8.1 there will be a change of the CPU as default.
Due to the many feedbacks this problem was solved, but did not make it into Qemu 8.0. The emulation can only be improved by help and feedback, but to criticize what does not work does not bring anyone further.
It has already been checked and reproduced that SDL in 16 bit is a problem, SDL should work in all modes and I don't expect anything, I just reported this bug and I am aware that an emulation can't be perfect like something that runs on real hardware. Software can be customized and I would of course support the SDL developers with testing as I unfortunately can't program.
Found the issue. https://github.com/AmigaPorts/SDL-2.0/ ... /SDL_os4framebuffer.c#L47 R5G6B5PC mode is missing in this switch-case which leads to unknown pixel format, which leads to NULL SW surface, which finally leads to SDL creating another renderer which happens to be the "compositing" because it's first on the list.
I expect this can be fixed for the next SDL2 RC, plus I will rebuild MilkyTracker again, too.
Probably SDL_FRAMEBUFFER_ACCELERATION should be disabled by default, so that use of PatchCompositeTags can be avoided on WinUAE when choosing "software" driver.
@Capehill I am looking forward to giving that fix a check with LiteXL which was reported that it doesn't look quite well on 16-bit screens. I will recompile it with the latest version when you have that released.
It seems to me that LiteXL renderer is still buggy and cannot work on anything else than 32-bit surface due to way it's writing the data (it assumes 1 pixel is 32-bits).
Found the issue. https://github.com/AmigaPorts/SDL-2.0/ ... /SDL_os4framebuffer.c#L47 R5G6B5PC mode is missing in this switch-case which leads to unknown pixel format, which leads to NULL SW surface, which finally leads to SDL creating another renderer which happens to be the "compositing" because it's first on the list.
I expect this can be fixed for the next SDL2 RC, plus I will rebuild MilkyTracker again, too.
Probably SDL_FRAMEBUFFER_ACCELERATION should be disabled by default, so that use of PatchCompositeTags can be avoided on WinUAE when choosing "software" driver.
This is great news, then they have found the perfect solution and it will run the same on all systems.
It will probably also solve the problem with ScummVM since it also uses the SDL output. Thank you very much again for your support.
I am looking forward to the next SDL release and Milkytracker.
Debug binary has serial prints which should be visible with sashimi or dumpdebugbuffer command.
It turned out that SDL2 doesn't actually have all required pixel formats so framebuffer code now uses always 32-bit ARGB bitmap and lets the OS do possible conversions to the desktop format.
Side effect might be that even LiteXL starts to work better on 16-bit screen but it's just because it gets lucky. It should still verify the destination format.
I will update SDL2 archive later if this works OK on QEMU.
Debug binary has serial prints which should be visible with sashimi or dumpdebugbuffer command.
It turned out that SDL2 doesn't actually have all required pixel formats so framebuffer code now uses always 32-bit ARGB bitmap and lets the OS do possible conversions to the desktop format.
Side effect might be that even LiteXL starts to work better on 16-bit screen but it's just because it gets lucky. It should still verify the destination format.
I will update SDL2 archive later if this works OK on QEMU.
Wow you are good ,-) It works perfectly now ! Great work, I am thrilled.
Correct color representation in 16 bit mode software SDL2...Wazp3d is no longer needed thanks to them.
Side effect might be that even LiteXL starts to work better on 16-bit screen but it's just because it gets lucky. It should still verify the destination format.
About LiteXL, since v2.1.1r1, which is the current public one, this is working already on 16bit screens, tested on both my microA1 and my X5000. But it didn't work on Qemu, possibly for the reasons you mentioned. Now that I compiled it with the latest SDL, it seems to work fine there as well.
Thank you again for the great work you are doing with SDL
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
