search

tonioni / WinUAE

WinUAE Amiga emulator
http://www.winuae.net/
545 stars 87 forks source link

Small Quickstart and debugger fixes #224

Closed Waccoon closed 2 years ago

Waccoon commented 2 years ago

Quickstart was working fine for PAL, but NTSC flag wasn't set correctly before loading builtin settings. Debugger was drawing too many pixels resulting in doubled pixels on right edge in PAL mode, and wrong line lengths in NTSC mode when long lines are active.

tonioni commented 2 years ago

Quickstart is meant to be "one way" only. Quickstart to config only. Not the other way (not even PAL/NTSC setting). But what does this have to do with CIA TOD source? (Is this correct patch?)

Visual debugger fix seems to be a bit too complex, I'll think about something cleaner.

Waccoon commented 2 years ago

The issue is that the NTSC checkbox is checked after the built-in settings are loaded, not before, so if the quickstart NTSC checkbox is changed after WinUAE starts, it will always load the exact opposite settings specified by the checkbox. If you try to use quickstart in A1000 mode and tick the NTSC checkbox, you'll see that a 50Hz CIA TOD source is selected, rather than 60 Hz. I moved the call to built_in_prefs() and then it works fine.

Even though quickstart is "one-way", the GUI treats the quickstart NTSC and advanced chipset NTSC checkboxes as the same UI element, so the internal "quickstart_ntsc" flag can get out of sync. Thus, even if the checkbox is visibly ticked in the quickstart settings, the opposite built-in settings can be reloaded when selecting a new Amiga model. The GUI has quite a few issues and my workaround isn't ideal, but I'm not in a position to be rewriting large chunks of code.

Yeah, I was a bit surprised to see how the debugger sets the magnification, and didn't notice until recently that it was drawing all pixels twice, since "xplus" was being used as both a flag and a count. I love the visual debugger feature, and it's taught me a lot about how the Amiga works, but it does have a number of issues. Trying to draw it directly into the screen buffer at the end of each frame means that maxhpos is not accurate, and due to drawing optimizations, sometimes pixels don't get updated/cleared on the next frame. It would be better to draw the debugger into a temporary buffer on each scanline, and then paste it into the screen buffer at the end of the frame.

tonioni commented 2 years ago

Oops, I missed built_in_prefs () line changed. This is now fixed and also DMA debugger now fully supports variable scanline widths and counts. Separate buffer would be good idea but it requires support from rendering backends, maybe someday. (now that DirectDraw is gone and replaced with GDI, all 3 backends supports "hardware sprites" which can be used for this purpose)

Waccoon commented 2 years ago

Nice. The recent changes finishes off my list of small bugs, so I doubt I'll be submitting any more pull requests for a while. Thanks for all your hard work.

I'm looking into a few other things right now (notably, optimized fetch cycle estimation), but they are pretty harmless. When I figure out how to reproduce the issues reliably, I'll submit a proper report.