OS4 compatible UAE expansion development status

[Toni Wilen]

I decided to forget about JIT and other stuff for now. It didn't seem to be worth the trouble.

UAE expansion stuff is feature complete now. I can't find any more ways to optimize it and there has not been much feedback or anything for few weeks now..

If there are problems, only way to get them fixed is to narrow down the problem to specific subsystem.

[Aegis]

Originally Posted by Toni Wilen

UAE expansion stuff is feature complete now. I can't find any more ways to optimize it and there has not been much feedback or anything for few weeks now..

Yes, I haven't had any major issues - waiting for beta 10 (RC1?) to give it some more testing

*doh!* just noticed you released b10 today on the other thread

[MickJT]

Originally Posted by Toni Wilen

If there are problems, only way to get them fixed is to narrow down the problem to specific subsystem.

Looks like my random freezing issue is to do with uaenet.device (or is at least part of the issue). If I use Realtek 8029, it's fine. Are there any command line arguments I can use that would help you out?

Edit: Oh, I see b10 has a stability fix. I will test this in just a moment.
Edit2: Seems ok so far on b10.
Edit3: Spoke too soon. Will do some more repeated testing with Realtek 8029 to double-check it definitely doesn't freeze with that.
Edit4: Would still seem to be an issue with uaenet. It's more stable than it was, however.

Sometimes I get dump files. Would this be on any help in this case, or are there certain arguments I should run WinUAE with?

Here's the latest .dmp (beta 10, 32bit). Sorry I didn't have full logging turned on at the same time. I'll enable that permanently in the config now.

Also, is this in the right thread now? Perhaps I need to set up an OS3 environment using uaenet and New UAE ROM indirect, and test there too.

[Toni Wilen]

Here's the latest .dmp (beta 10, 32bit). Sorry I didn't have full logging turned on at the same time. I'll enable that permanently in the config now.

Crash is in uaegfx code when copying data to/from Amiga-side. Not enough information to know why it happens except that some pointer is invalid.

-> disable uaegfx (use PicassoIV) and keep uaenet active. Still same problem? (Some trap doing bad things can break others too)

Log most likely won't help.

Also, is this in the right thread now? Perhaps I need to set up an OS3 environment using uaenet and New UAE ROM indirect, and test there too.

It would help debugging if it also happens under OS3.

[mritter0]

Is there any possibility on speeding up directory access (not HDF)? That is my biggest request.

[Toni Wilen]

Originally Posted by mritter0

Is there any possibility on speeding up directory access (not HDF)? That is my biggest request.

Details.. What operations? (Open, reads, writes, directory). Hard performance numbers required

[mritter0]

I used the wrong term: shared directories. Read/writes are much slower. Just as an example for times:

To compile the first 8 source files for my project:

Shared directories on same drive as WinUAE: 2min 4sec
VHD on same drive: 52sec

Shared directories on NAS box: 5min 06sec

[Toni Wilen]

I knew what you meant but I don't want to see some total time of random file operations, it won't tell anything useful. (except: "yes, it is slow")

Something like diskspeed result comparisons possibly helps, anything that times each basic file operation (open file, read file, delete file, read directory and so on)

[MickJT]

Originally Posted by Toni Wilen

Crash is in uaegfx code when copying data to/from Amiga-side. Not enough information to know why it happens except that some pointer is invalid.

-> disable uaegfx (use PicassoIV) and keep uaenet active. Still same problem? (Some trap doing bad things can break others too)

I think the info in that .dmp pointing to uaegfx may have been a byproduct of me attempting to reboot beforehand, before it totally froze up. I've tested with Picasso IV and the same issue happens. At first it doesn't freeze, it just fails to finish downloading a file, then I can try to reboot or continue on doing other things and it will freeze soon after, so the point at which it freezes is not the exact point where the problem started.

I've had uaenet.device disabled and using Realtek 8029 for a while now, and the freezing has drastically reduced (whether the remaining occasional freezing is OS4 or WinUAE is hard to tell).

Is Virtual Mouse Driver supposed to be fully working on OS4 at this stage? It works but I always see both mouse pointers.

Here are a couple of .dmp files. One was when after the networking froze, DOpus4 couldn't change directories or load files, but I could still move the mouse and switch screens. I pressed F12 then clicked Quit, and then the dump file was generated. The second one was when using the "curl" utility, and it straight up froze, then I used F12 and Quit.

[Toni Wilen]

Is Virtual Mouse Driver supposed to be fully working on OS4 at this stage? It works but I always see both mouse pointers.

It only works if uaegfx mode mouse pointer is hardware sprite. OS4 mouse pointer is software sprite.

Here are a couple of .dmp files. One was when after the networking froze, DOpus4 couldn't change directories or load files, but I could still move the mouse and switch screens. I pressed F12 then clicked Quit, and then the dump file was generated. The second one was when using the "curl" utility, and it straight up froze, then I used F12 and Quit.

Both crashes are "normal". Quit won't (yet) terminate trap threads and if there is any active thread, it will crash because all Amiga memory gets unmapped under it..

[mritter0]

Originally Posted by Toni Wilen

Something like diskspeed result comparisons possibly helps, anything that times each basic file operation (open file, read file, delete file, read directory and so on)

I looked around for some OS4 harddrive performance testers but couldn't find any. The OS3.x ones lock up or crash.

As a programmer who does all the editing on my PC side, then have to FTP it over to Amiga to compile it, any speed increase would be great if it would make up the time/steps difference.

[DarrenHD]

Is there any trick to getting GREX Support to work in AmigaOS 4.1 FE? I have read the AmigaOS 4.1 FAQ (I actually WROTE the FAQ So yes it is enabled, both on the kernel commandline and in WinUAE settings. I have the Realtek 8029 card also enabled in WinUAE but neither the phase-5 early startup nor OS4 see any cards. In fact OS4.1 doesn't detect the GREX at all.

Also, Ranger (part of OS4.1 Extras) crashes on Gfx Board tab when uaegfx is used.

I'm using WinUAE latest Beta 10.

Thanks

Darren

[Toni Wilen]

Originally Posted by mritter0

I looked around for some OS4 harddrive performance testers but couldn't find any. The OS3.x ones lock up or crash.

As a programmer who does all the editing on my PC side, then have to FTP it over to Amiga to compile it, any speed increase would be great if it would make up the time/steps difference.

Sorry, not going to happen with details.

Originally Posted by DarrenHD

Is there any trick to getting GREX Support to work in AmigaOS 4.1 FE? I have read the AmigaOS 4.1 FAQ (I actually WROTE the FAQ So yes it is enabled, both on the kernel commandline and in WinUAE settings. I have the Realtek 8029 card also enabled in WinUAE but neither the phase-5 early startup nor OS4 see any cards. In fact OS4.1 doesn't detect the GREX at all.

Most important data is missing: winuaelog.txt (tick the logging box in paths panel before starting emulation) and config.

Also, Ranger (part of OS4.1 Extras) crashes on Gfx Board tab when uaegfx is used.

It is known. Only Ranger developer can find out what is going on.

[DarrenHD]

Originally Posted by Toni Wilen

Sorry, not going to happen with details.



Most important data is missing: winuaelog.txt (tick the logging box in paths panel before starting emulation) and config.

Attached to the post now.

thnx

[Toni Wilen]

You have all PCI bridges enabled at the same time. Configuration system supports it but PCI emulation won't like it.

Switch off JIT if it still won't work and attach new log. (It makes no performance difference in PPC-only emulation)

[DarrenHD]

Originally Posted by Toni Wilen

You have all PCI bridges enabled at the same time. Configuration system supports it but PCI emulation won't like it.

Switch off JIT if it still won't work and attach new log. (It makes no performance difference in PPC-only emulation)

Ok, disabled prometheus and mediator. JIT still enabled: no change

then disabled JIT, no change.

Logs attached.

Also, I don't see the splash screen for OS4.1 anymore, it's just black while it boots. Is that because of uaegfx?

[Toni Wilen]

Originally Posted by DarrenHD

Ok, disabled prometheus and mediator. JIT still enabled: no change

At least log looks correct now. Sounds like you have too old CSPPC ROM, it needs to be 44.71, older versions don't have GREX support (=no PCI button in CSPPC menu)

Also, I don't see the splash screen for OS4.1 anymore, it's just black while it boots. Is that because of uaegfx?

My guess is that only some common boards have boot logo support. There is no uaegfx activity until WB opens.

[DarrenHD]

Originally Posted by Toni Wilen

At least log looks correct now. Sounds like you have too old CSPPC ROM, it needs to be 44.71, older versions don't have GREX support (=no PCI button in CSPPC menu)

The ROM is actually 44.71 and I see the PCI menu in the phase-5 menu (hold ESC right after starting emulation).

But my kernel is too old. GREX support wasn't added until kernel 53.64. I'm going to try with the latest. Reply in a bit.

[DarrenHD]

Originally Posted by DarrenHD

The ROM is actually 44.71 and I see the PCI menu in the phase-5 menu (hold ESC right after starting emulation).

But my kernel is too old. GREX support wasn't added until kernel 53.64. I'm going to try with the latest. Reply in a bit.

Ok, PCI cards showing up now with a newer kernel.

Thanks for helping out!

Darren

[MickJT]

Originally Posted by Toni Wilen

It only works if uaegfx mode mouse pointer is hardware sprite. OS4 mouse pointer is software sprite.

Both crashes are "normal". Quit won't (yet) terminate trap threads and if there is any active thread, it will crash because all Amiga memory gets unmapped under it..

Thanks for the info, and looking into those crash dumps. I guess the problem resolves itself with a faster CPU. For the time being I'll use Realtek.