Quote:
I haven't seen a way to get beam position via OpenGL :-/ |
Damn, i've expected that you would say that. :sad
|
Hi Frode!
Quote:
https://discourse.libsdl.org/t/synci...etrace/19563/4 Quote:
|
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? |
Quote:
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 :) |
Ok, so...
Happy merging, Frode. :) |
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 :) |
Quote:
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. |
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.
|
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=50emulation 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. |
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) |
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): Code:
... 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. |
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) |
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:
Code:
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 Code:
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 Code:
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 Edit: The PC change is due to a interrupt (identical to an earlier interrupt which happens in both FS-UAE/WinUAE): Code:
XX-XXX [106 004-011]: do_interrupt 2 EDIT: I found the bug in FS-UAE causing filesys boot to fail :) Fix coming tomorrow, probably. |
Quote:
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... :sleep |
Quote:
Use git bisect ;-) |
Got it already, today must be my lucky day. (and thanks to -O0 :) )
Must be something in between: Code:
FAIL 336f8a853d13658df66664e2add5324558b39f82 Fixes for 3610b4 |
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.. :( |
I've pushed the fix for UAE filesystem to the winuae4200 branch :cool 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. |
Quote:
One line of code to fix them all... Crazy rocket science. Big respect to all who let the rockets fly. Quote:
|
All times are GMT +2. The time now is 02:17. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.