New FS-UAE branches with updated emulation code from WinUAE

[FrodeSolheim]

Originally Posted by Retro-Nerd

What about lagless vsync (beam racing)? Do you get this working too at some point? Or is it problematic due to D3D/OpenGL differences?

I haven't seen a way to get beam position via OpenGL :-/

[Retro-Nerd]

Damn, i've expected that you would say that.

[BastyCDGS]

Hi Frode!

Originally Posted by FrodeSolheim

I haven't seen a way to get beam position via OpenGL :-/

I have found a quote in the deep web which might help. Another possibility would be to look into the wine code how it translates the beam racing code from DX to OpenGL.

https://discourse.libsdl.org/t/synci...etrace/19563/4

Scott_Percival
Apr '13
I could be wrong, but here’s my understanding from the OpenGL side of
things. WGL and GLX don’t have a method to poll for the refresh rate or the
vertical retrace status, instead they have an extension
(GLX_EXT_swap_control) to set the swap interval, exposed in SDL as
SDL_GL_SetSwapInterval and SDL_GL_GetSwapInterval.

A swap interval of 0 means buffers are swapped as fast as possible with no
regard for vsync, 1 means the buffer swap call will block by sleeping until
the vertical retrace finishes, 2 means the same but for every 2nd retrace,
and so forth. Therefore, in the 100Hz case a draw call made at 25ms would
sleep until it hits 30ms, then release.

Also there’s a further extension (GLX_EXT_swap_control_tear) for
"Xbox-style" vsync handling, where any errant draw call that misses the
retrace will trigger a buffer swap ASAP, then afterwards revert back to
vsync. But that doesn’t really help in this case.

The OpenGL platform APIs don’t support callbacks, so you’re probably out of
luck. If you really need vertical sync, you will most likely have to poll
your external devices from a separate thread, or perhaps change your
strategy (e.g. set the swap interval to 1, determine the refresh rate, set
the swap interval to 0, start polling and trigger buffer swaps by checking
a timer).

[jbl007]

4100 branch built successfully, seems to be the same like 4010 at the moment. Basic stuff works well, except for interlaced display. Yes, I call that basic stuff too.
Frames look really weird, like even/odd fields are rendered too early/too late with the default setting

gfx_linemode=double2

. Surprisingly double3 works well.
Does it even make sense to report issues at this kind of development state?

[FrodeSolheim]

Originally Posted by jbl007

4100 branch built successfully, seems to be the same like 4010 at the moment. Basic stuff works well, except for interlaced display. Yes, I call that basic stuff too.
Frames look really weird, like even/odd fields are rendered too early/too late with the default setting

gfx_linemode=double2

. Surprisingly double3 works well.
Does it even make sense to report issues at this kind of development state?

Yes, 4100b1 introduced changes which needed quite a few fixes to even compile. I try to avoid pushing things which breaks compilation, so I'll need to finish the "Fixes for 4100b1"-commit before pushing and continue merging. I was almost done with it last night, so will probably be able to push/continue this evening.


I don't think it makes much sense to report issues at this point. I expect lots of stuff to fail, and even more might fail as I merge more changes. The idea is to get the codebase synced with 4.2.0 and *then* start tackling issues, since issues fixed before then could become irrelevant.


So, I'm thinking:
- Get the codebase synced with 4.2.0
- And then start compiling a list of issues

[jbl007]

Ok, so...
Happy merging, Frode.

[FrodeSolheim]

https://github.com/FrodeSolheim/fs-uae/tree/winuae4200 - WinUAE 4.2.0 code merged. I have also ran a manual comparison on the diff between FS-UAE and WinUAE and verified that there isn't any code missing/different due to the merges.

But of course, as I said earlier, a lot has changed, there has been added a few stub functions which is not implemented (may not need to be either), some functionality is disabled on purpose for now (x86 emulation), and expect problems with expansions. In particular, UAE file system is still broken - won't boot (I haven't figured that one out yet). UAEGFX is probably broken too, haven't tested. UAE bsdsocket.library is explicitly disabled, needs fixes before it can be enabled again. Clipboard integration is also disabled.

There can also be issues with fastest-possible mode (not tested), and even vsync / non-vsync timing issues with plain A500 emulation due to changes in calls to target-specific render calls. So basically, we need to test everything ;-)

Let the fun begin

[jbl007]

Originally Posted by FrodeSolheim

[url]Let the fun begin

With pleasure, but where to start?
With the easiest-to-fix stuff or the most important stuff. For the most impotant stuff I'd vote for directory hard drives. ppl usually want whdload.

[FrodeSolheim]

I agree, after making sure A500/600/1200 emulation is working great for gaming (including non-vsync, vsync, and adaptive sync (g-sync) modes), directory hard drives is next up. Unfortunately, there is a tricky bug there. I have already spent many hours on that one, both recently, and also quite a while back (almost two years ago??). The problem started after merging indirect trap system support from WinUAE (https://github.com/tonioni/WinUAE/co...172cf183286045). The UAE filesys does not initialize properly, so the Amiga hangs on a white screen on boot.

[jbl007]

Interlaced is still broken, I uploaded interlace_test.adf to the zone, very good test case.

Looks like vsync works correct already. Don't know about g-sync, but freesync is pretty much automatic: disable vsnyc, go fullscreen and it just works.
The old strange bug is still there: if I start in windowed mode it detects 60Hz even if it's at 50. If I work around with

assume_refresh_rate=50

emulation is fully synced to refresh rate. Haven't tested low latency vsync yet.

good news: JIT compiler seems to work
bad news: no joy with .hdf files even with

hard_drive_x_controller=ide

-> "Not a dos disk" configured drive geometry looks ok to me and afaik it has nothing to do with uae boot rom, so it should theoretically work.

[Toni Wilen]

White screen after boot usually means: filesystem init routine didn't return or returned error.

Some debugging hints:
- does TO debugger command list the partition?
- handle_packet() get called?
- ROM_filesys_diagentry (=filesys_diagentry) called?
- does filesys_diagentry initialize everything needed? (including hardfile stuff because it finally calls filesys.asm)

[FrodeSolheim]

Thanks for the hints, will check the TO debugger command. handle_packet is not called, it stops before that. filesys_diagnetry is run.

The differences I see from the UAE side are (some additional logging added, red color is missing from the nonworking version):

...
Memory map after autoconfig:
00000000    2048K/4 =     512K Chip memory
00200000    8192K/0 =    8192K <none>
00A00000    2048K/0 =    2048K CIA
00C00000     512K/1 =     512K Slow memory
00C80000    1024K/0 =    1024K Custom chipset
00D80000     256K/0 =     256K <none>
00DC0000      64K/0 =      64K Battery backed up clock (MSM6242B)
00DD0000      64K/0 =      64K <none>
00DE0000     128K/0 =     128K Custom chipset
00E00000     512K/1 =     512K Kickstart ROM (F6290043)
00E80000      64K/0 =      64K <none>
00E90000      64K/0 =      64K Filesystem autoconfig
00E90000      64K/1 =      64K Filesystem autoconfig (64K/1 instead of 64K/0)
00EA0000     384K/0 =     384K <none>
00F00000      64K/1 =      64K UAE Boot ROM
00F10000     448K/0 =     448K <none>
00F80000     512K/1 =     512K Kickstart ROM (F6290043)
TRAP: filesys_diagentry
TRAP: mousehack_done
mousehack_done mode = 17
TRAP: mousehack_done
mousehack_done mode = 18
TRAP: mousehack_done
mousehack_done mode = 4
PAL mode V=50.0000Hz H=15625.0881Hz (227x312+1) IDX=10 (PAL) D=0 RTG=0/0
TRAP: exter_int_helper
TRAP: exter_int_helper
TRAP: exter_int_helper
Display Size: 640x400 Offset: 74x36
TRAP: filesys_dev_storeinfo
Mounting uaehf.device 0 (0):
FS: mounted virtual unit DH0 (./.)

So it looks like filesys.asm isn't triggering the exter_int_helper trap. Could be a problem with the setup there. Also, the missing mousehack_done mode = 17 (clipboard integration) is suspicious, but on the other hand, filesys.asm was also updated as part of the changes, so that might be normal. The next step might be for me to compile a special debug version of WinUAE (with the same features enabled as in FS-UAE), and try to run a detailed comparison of the boot process.

[jbl007]

Cycle exact stock A1200 emulation has some serious timing issues with some demos. Audio is playing too fast and samples are cut off. Non cycle exact is fine.

Examples:
8-Bit Jungle (Unstable Label)
Full Moon (Virtual Dreams/Fairlight)
Planet M. (Melon Dezign)

[FrodeSolheim]

A short progress report.. I've been silent for a couple if days while I've been working on the filesys problem. The good news is that I'm quite near figuring out what the problem is. Long story short, after adding code to do an instruction-level comparison between FS-UAE and WinUAE running the same setup, I've narrowed the problem down to the following events during the emulation of the 107th frame:

PC=00FC0EC0 OP=00004E73 D0=00000000 D1=00000000 D2=00000113 D3=00000024 D4=00FE5052 D5=00FE4FF6 D6=00FE4F5E D7=00000000 A0=00C00276 A1=00C02488 A2=00C02B24 A3=00C02B24 A4=00C80000 A5=00FC0240 A6=00C02460 XX=00C7FFFA 
XX-XXX [106 000-011]: PC <- 00FE4FBA (m68k_setpci_j)
XX-XXX [106 021-011]: PC <- 00FC0CE2 (m68k_setpc) <- This only happens in FS-UAE

For some reason, FS-UAE overwrites the program counter at this point, changing PC for a second time. Winuae continues here:

XX-XXX [106 004-011]: PC=00FE4FBA OP=00002C5F D0=00000000 D1=00000000 D2=00000113 D3=00000024 D4=00FE5052 D5=00FE4FF6 D6=00FE4F5E D7=00000000 A0=00C00276 A1=00C02488 A2=00C02B24 A3=00C02B24 A4=00C80000 A5=00FC0240 A6=00C02460 XX=00C01518

While FS-UAE continues here:

XX-XXX [106 026-011]: PC=00FC0CE2 OP=000048E7 D0=00000000 D1=00000000 D2=00000113 D3=00000024 D4=00FE5052 D5=00FE4FF6 D6=00FE4F5E D7=00000000 A0=00C00276 A1=00C02488 A2=00C02B24 A3=00C02B24 A4=00C80000 A5=00FC0240 A6=00C02460 XX=00C7FFFA

So, should be able to dig further and find the cause of this within a reasonable amount of time

Edit: The PC change is due to a interrupt (identical to an earlier interrupt which happens in both FS-UAE/WinUAE):

XX-XXX [106 004-011]: do_interrupt 2
XX-XXX [106 004-011]: Exception 26
XX-XXX [106 004-011]: Exception_ce000 26
XX-XXX [106 021-011]: PC <- 00FC0CE2 (m68k_setpc)

Next step is to find out why this fires again in (only) FS-UAE.

EDIT: I found the bug in FS-UAE causing filesys boot to fail Fix coming tomorrow, probably.

[jbl007]

Originally Posted by FrodeSolheim

Oh, and also, I found the bug in FS-UAE causing filesys boot to fail Fix coming tomorrow, probably.

Good news.

Regarding the A1200 cycle exact bug. It starts to fail at the winuae3610 branch, winuae3600 is working. I think the next step is to find the commit where is breaks exactly. This could take a while...

[FrodeSolheim]

Originally Posted by jbl007

Good news.

Regarding the A1200 cycle exact bug. It starts to fail at the winuae3610 branch, winuae3600 is working. I think the next step is to find the commit where is breaks exactly. This could take a while...

Use git bisect ;-)

[jbl007]

Got it already, today must be my lucky day. (and thanks to -O0 )

Must be something in between:

FAIL 336f8a853d13658df66664e2add5324558b39f82 Fixes for 3610b4
b8fc1ea5886ca5a99c6ac4296cb5b231618647ea 3610b4 [WinUAE 32563a1b]
b3c6340e25988a9ad7a4eff6831027b9d2eacf38 CL blitter bounds check fix. [WinUAE b48eb99d]
0b8b83291e0cedfd1b82dcea6c148f12efc764ae ATAPI weird behavior testing [WinUAE 2b287b7c]
2e148c6a0731028000ac1ee3c0f7505f76685ac3 Ignore weird hardware. [WinUAE c8ceb6ae]
791d8a4b7154b809bfc354a05f49221726a1ab41 Another attempt of fully thread safe interrupt activation [WinUAE f1df6c75]
WORKING 9010aae0ed485d41cbbf1d766da3cda293af6696 Remove debug mode warning. [WinUAE 3be99ea7]

Couldn't find the exact one (build fails).

[Foul]

Compiled Winuae4200 branch and

"WARNING: Z3 invalid map_banks(RTG RAM) start=10000000 size=00000000"

at start, how to corrects this ? thx

edit : found : related to graphics_card = uaegfx

can't use anymore uae_maprom and accelerator at same time..

[FrodeSolheim]

I've pushed the fix for UAE filesystem to the winuae4200 branch Turns out the problem what I had been too quick when porting

atomic_bit_test_and_reset

, and instead effectively implemented "atomic_bit_test_and_set" :-/

Fixed now

EDIT: Also continued merging 4.2.1 beta code, since 4.2.1 is going to be a minor bugfix release. Branch winuae4210

EDIT: Ported the fix "back in time" for the winuae4210 branch - and rewrote the git history - so that this corrected implementation is available when testing old winuae merge commits.

[jbl007]

Originally Posted by FrodeSolheim

Fixed now

Congrats, you nailed it!
One line of code to fix them all... Crazy rocket science.
Big respect to all who let the rockets fly.

Let the fun begin

Still having fun? What's up next?