What's the best/latest EUAE build for OS4?

something what can be great in our E-UAE - bsdsocket.library support
I know, it is probably not easy....


and also a little offtopic:

speaking about E-UAE, I found strange thing:

- on MorphOS and AmigaOS4 verions of E-UAE not works game Aquabyss
- on WinUAE works

The guru generated in AmigaOS3 inside emulation is mostly 81000005, sometimes 81000009 depended on Memory configuration
The game is written i AMOS and is very big from AMOS point of view. Memory/PPC/BigEndian issue?

No. I don't need to debug it and fix it, but it is a pitty, it is only Amiga game which I must play on Windows

@Sailor
Quote:

Why did you find this strange? In every way, our version lags far behind WinUAE. That was already like this even 10 years ago, but today, the gap between WinUAE and our UAEs is only bigger in all the areas.

@sailor

Quote:

There are all sorts of bugs in AMOS too, and if you configure UAE wrong, AMOS will not run.
one example if you put P96 gfx memory to 0, and activate Picasso96 it will corrupt memory.

Quote:

Nope, it’s a bug in the code somewhere, it’s not hardware related. I barley looked at the code, and pretty sure I can’t fix it. even if I had the source code to game.

Quote:

If you have the source code, you can try running it in Amos Kittens, insted of UAE/AMOS

@Hypex

Quote:

Yes, i think your right, I created my own kaymap to solve some issues like that.

I know nothing of RunInUAE, as I don't use it.

@LiveForIt

I mostly use RuninUAE as it's installed and ready to go. But WB3.1 is pretty basic. I had UAE installed but found it was on my XE HDD that I pulled out.

I also found another annoyance. Screen mode switching. I think it's time screen modes were emulated. I'm kind of over the screen switching last 20 years almost. CRT, LCD, whatever, they are all the same. It takes about 2 seconds for them to sync. Given we have compositing there should be no need for using the real screen mode and for years video cards have been 640x480 minimum so it's pointless as 320x200 or 320x256 won't work on modern hardware. So for me compositing the screen and scaling it to the actual resolution would be better.

The reason this wasn't a problem on real Amigas was because all PAL or NTSC resolutions were a variant of the same screen mode. So the screen didn't flinch. Wish I could screen between different resolution like we could years ago without it blanking out.

@Hypex

Quote:
UAE open and closes library’s when switching between window mode and Fullscreen mode, maybe what you’re talking about.
Quote:

Well as long as your not compositing a larger screen onto smaller screen, now that look truly horrible.

Quote:

UAE Amigfx, does is not use native modes, it just uses native api to set up window mode, and full screen modes, and modes are emulated in the window, or in the full screen mode.

Quote:

I don’t have a NDA with hyperon, so can’t make this changes anyway speaking of (NallePUH and DPaint4), of cause you can try better fake mode hack..
Quote:

Yes but now everyone is using HDMI, DVI, so signal should be digital, so don’t see why, and we don’t have any native planar modes, (unless your on a old BlizzardPPC or CyberstromPPC.)

@LiveForIt
Meanwhile, I'm tinkering with the SDL2 driver within our EUAE and have basic rendering but no working scaling at the moment. But at least when I remove p96 support from SDL code, the emulator no longer "pauses" when I switch to the workbench screen and scroll down. Even with the SDL1 driver and without p96, I see no pauses in this situation, so there probably was something bad related to the p96 code in sld-gfx.c

I also see you continue adding things to ami-gfx.c, so together with the compositing you added, do you think it will be easy now to add scaling support as it was with mplayer, so when the demo asks for 320x240, we can set some options saying to scale it to the full 1920x1080 screen? At least in fullscreen mode that will add a lot. Maybe option can be controled from uae settings, like you set to which size do scaling or something of that sort..

I will try for now to use SDL2 inbuild scaling functionality (which pretty bad looking, but just to see how it works with uae code)

@kas1e

Scaling already works in AmiGfx, trying to add P96 support, removing some CGX stuff, adding some code from SDL, has caused some bug to go away.

but not I’m in limbo, trying to rearrange code, and get the code working again.

I don’t know why MorphOS, developer don’t add their own OS in the build system, it looks cleaner, all the #ifdef, #else, #endif, even if there 90% is shared, it be easy to use diff to check if something is changed or updated.

I don’t want to worry about code, is used or is not used, or if it causing bugs. so I remove it.

@kas1e

The version on github now compiles.
try it out if you like.

@LiveForIT
Quote:

That right, times passed long ago when all amiga oses share same code, it just make it harder to mantain.

Quote:

Thanks, checked. I use this line for configure:




Then on linking i have few "multiply definations" errors.

There changes which probabaly need to add to the repo:

1. in src/audio.c add "extern" to uae_u16 dmacon; " to avoid multiply definitaion of 'my_dmacon'.

2. in src/md-ppc-gcc/support.c add "extern" before frame_time_t timebase; so to not have multiple definition of `timebase':

3. in src/od-amiga/main.c add #include <proto/timer.h> and <proto/wb.h> and comment out :
//struct Device *TimerBase;
//struct TimerIFace *ITimer;
and
//struct Library *WorkbenchBase = NULL;
//struct WorkbenchIFace *IWorkbench = NULL;

that again to avoid multiply definations errors on linking.

4. in src/main.c comment out #include "bsdsocket.h" (to avoid multiple definition of `socketbases')

5. In sleep.h we have define with TimeDelay():



By some reassons i do have undefs to TimeDelay() when linking, so i have to comment this part out, so instead dos's Delay will be used.


After all this done, i have on the linking those errors left:



I find out that open_icon() and dispose_icon() are in the window_icons.c , so probabably this one should be added to the makefiles/etc, to be build/linked automatically.

For now i just compile this file by hands, and link against it.

Then the only "BackFill_Func" undefine remain, and this one i find in "gfx-amigaos/comp.c", which is also didn't build automatically, so i had to compile it also manually and link against it.

Then binary ready.


So then tests starts. For first, i just tried to run my p96 installed OS32 over new binary. On running it ask for screenmode (bring asl requester, before there was none). I choose 1920x1080, and then i have opened 1920x1080 screen, but the whole OS3.2 opens on Pal screen, and in the screen preferenes i didn't have my p96 screenmodes.

But at least whole "PAL" screen opens on the full screen in 1920x1080 seems so.

But when i hit "amiga+M" and scroll WB down, i only see black screen. What mean that probably there some hardcore settings for the opened screen, which is not "system friendly" ?

I then tried to run some demo and it runs in full screen, that for sure. Seems resized as well, but do have "black" and "white" areas around the video.

But it surely works and scalled. Because when i run ranger, i did see 1920x1080 screen created. Through can't see it when scroll wb down. Maybe some flag missed ? Like "LikeWB" or something when screen created ?

I made a video to show how it all looks like, check this out:



You can see there that when i do "amiga+m" i fast switch between screens, which mean that opened screen is surely same as workbnech by size and depth (1920x1080x32). Just by some reassons i didn't see anything when scroll wb window down. Like, it have some flag set for screen which didn't show it for me.

Then, you also can see while os32 loads on pal (probabaly that expected, as p96 seems not added fully at this point), it did have white areas at left, right and small one at bottom. And when run demo, those white areas still there.

IMHO at this point need to deal with 2 moments: "not visibly data when scroll down wb screen" and "white areas around, which need to be black".

But that good stuff already :)

@kas1e

Makefiles where already pressent, you should not have run configure, if your compiling natively.

I edited makefile manually, not good with this fancy configure scripts.

On CFLAGS I added -lamiga -DPICASSO96_SUPPORTED and -D__use_inline__

by doing so you should not have all problems you had during compiling.

Window mode is where I have done most work, if you don’t select a screen mode, cancel the screen select window.

As for screen dragging, you might enter a different full-screen mode.
or maybe because I had to revert to older files. (Basically, screen dragging is disabled.)

@LiveForIt

Quote:

Without running ./configure it also didnt builds, i treid to run and from root, and from ./src , all the same:




Imho, if you need to delete whole configure, then need to delete all assoiated files with, and keep only ready to go Makefiles, but those makefiles then should support cross-compilers too, because many of us use them. Also for those new makefiles need to add options to be able to enalbe disable things just like it done now with configure : i.e. to disable/enable SDL, JIT, P96, and whatever else which for now handled by configure.

As it now, it will not builds correctly not with just "make", not with ./configure way (as need add 2 more files in).

I can alter configure scripts , so all will be ok. Or if we will go makefiles way, then can help with makefiles.

Quote:

At least libamiga.a present not on all setups too. And as for D__use_inline__, should't it be D__USE_INLINE__ ? At least on systems where big/small letter make difference that can act bad. When you run ./configure, -D__USE_INLINE__ added already.


Anyway, whole building process can be dealt with later imho, so i just rebuild everyhting with -DPICASSO96_SUPPORTED now, and it give issues on linking again , this time about this:

DX_Invalidate()
gfx_lock_picasso()
gfx_unlock_picasso()

etc.

That happens because you have right at top of the ami-win.c that:



But those functions are inside of the #ifdef PICASSO96 which you undef on the top.

At least that how it in your repo now. Maybe you forget to commit new stuff ? Or maybe you forget in the repo change some parts where was PICASSO96 on PICASSO96_SUPPORTED ?

Was there any reassons to introduce new flag btw ? I search whole .c and .h files on PICASSO96_SUPPORTED, and it only present in ami-win.c and picasso96.h , but then, in the same parts where old PICASSO96 define are, which you undefine, and then define PICASSO96_SUPPORTED. Why ?


The only way where i am able to compile working binary, is to use ./configure without PICASSO96_SUPPORTED define, then configure manually 2 new objects and link it all in binary.

Quote:

Same screenmode 100%. Because i always use 1920x1080x32, and choose the same as well when run uae binary. Ranger also confirm that this is 1920x1080x32 mode creates, just with some other flags, which probably need to be fixed to make scrollable wb to see what happens on uae screen.

@LifeForIT
Quote:

That didn't works. When i hit chancel, it says "Cannot open UAE window on public screen 'ask' ". What is that "ask" name from ?:)

Anyway, i think the code in repo not the full one , because it can't be build with PICASSO96_SUPPORT, as new functions seems missed or so. Or re-define of already defined PICASSO96 somewhere missing.

Try yourself to delete your local code, download from the GIT latest stuff, and build it (even with just "make").

@kas1e

PICASSO96 is defined in picasso96.h
and should not be defined any where else, I most likely made a mess.

Quote:

he he.. there some soft links, maybe these causing problems, maybe you must run configure. I guess I need to make changes in makefile.in instead of makefile or something.

@LiveForIt
I tried just to rebuild with both -DPICASSO96 and -DPICASSO96_SUPPORT, then i at least didn't have those undefs to DX_Invalidate() / gfx_lock_picasso() gfx_unlock_picasso() , but do have undefs to restore_p96() and to save_p96().

@LiveForIT
Quote:

Yep, it will surely easy for everyone. Later we can just ditch it all together, and create pure tiny small good looking makefiles.

@LiveForIt

Quote:

No, that's not it. It's when opening the screen and simply screen switching. It's likely using 800x600 while my WB is at 1920x1080. So when it changes screen the monitor blanks out. Even if the resolution is the same I've found a different depth will also set it off.

Simple test. Open a program with a different screen mode. Switch back to WB then switch back again. Your monitor should blank between mode changes. All mine do.

Quote:

Thought that would work better. I mean, when going from big to small, you don't see the "Doom chunky wall" effect. When going from small to big, which is what UAE would mostly need, you risk getting the pixelated chunky effect.
Quote:

Native modes are crap. I mean, all the P96 PAL modes were 640x480. That's not low res! So, this is an old problem.

Quote:

Shouldn't need NDA or any mode hacks. Just CompositeTagList() which should be in OS4 SDK.

Quote:

That's more reason why it should be stable. But it's likely because a different resolution is using different timings. So it blanks out to change. Perhaps would help if all timings matched. But don't know if all resolutions can be set to same timings and it won't automatically.

So it's not because of missing native modes. Just different screen modes. If you don't see this I don't know why. I've seen it with all my monitors and different screen modes. I thought everyone had it.

@kas1e

Quote:

Oh no. That will cause load on CPU and open up then close timer.device every time it's used. AmigaDOS isn't efficient that way.

Then again TimeDelay() is an amiga.lib function that does the same thing. Opening up and closing timer.device.

These are things that need cleaning up. There should be an Alarm() function in years. And should be a timer delay function that allocates resources only once and reuses them on each call.

@Hypex
Quote:

Yeah, i even don't have this TimeDelay() on me anymore. See there:
https://github.com/khval/e-uae-1-0-0/b ... ab17a/src/include/sleep.h

And yep, i go the DOS's Delay way and this is probabaly the same open/close timerdevice. Maybe nanosleep() way will be better ?

@LiveForIT
So in end of all, it should be both PICASSO96 and PICASSO96_SUPPORT enabled ? Or just PICASSO96_SUPPORT ?

Maybe it worth to just remove PICASSO96_SUPPORT switch and handle everything by an old PICASSO96 one ?

I just tried to build your latest code which you commit few minuts ago, with both -DPICASSO96 and -DPICASSO96_SUPPORTED" and on linking have undefs to restore_p96() and save_p96() which inside of PICASSO96 ifdef.


Then i tried to compile with only -DPICASSO96_SUPPORTED, without -DPICASSO96, then it even didn't compiles, and in ami-win.c says : "error: ‘bitdepth’ undeclared"

@kas1e

on AmigaOS4,
configure creates bad sysconfig.h with wrong sizeof_long_long, sizeof_short, etc... so I'm strugeling.

I suggest doing make clean, and make all again, if you have
problems, that worked for me.

And just make sure you include picasso96.h from uae,
not from os4 sdk.

Maybe the file should be renamed uae_picasso96.h, just to make sure.