Timing issues in uzem140

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Timing issues in uzem140

Post by Jubatian »

I pushed a commit to my uzem140-hacks branch attempting to generalize cycle perfection problems, hopefully opening possibilities for fixing further issues (such as EEPROM timing which I see being left in a quite unfinished state).

Basically I split up the update_hardware() function into a cycle precise part which mostly operates the timer and produces pixel output, and another for the rest. The cycle precise part became responsible for the emulator's overall cycle budget, making it possible to call update_hardware() just about anywhere to progress emulation a cycle forth.

The body of this new update_hardware() tries to merge all the cycle perfection related experiences so far in a clean manner. If it works proper for the known test cases, I expect it being also more consistent for further cases, or at least providing intuitive locations for adding further changes towards cycle perfection as needed.

Damn, I think I give up for now at least until weather cleans up somewhat here... It is frustrating when you see reconnect scripts spinning, smashing the bloody commit command like crazy, yet it can't get through the air for half an hour.

By the way the performance seems to be the same as before. It is not as trivial to tell since the original code missed cycles here and there (the return of avr8::exec wasn't necessarily consistent with the count of cycles actually emulated).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Timing issues in uzem140

Post by Artcfox »

It looks like you only handle pixel formats that have the A portion in their MSB. Did you see the function: SDL_ConvertSurfaceFormat which lets you do an arbitrary conversion?
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Timing issues in uzem140

Post by Jubatian »

I wrote that function faster than I could load that page of the SDL documentation ... And still on the pages I could already load during this day, I only see SDL_ConvertSurface which as I remember allocated a new surface, so was unsuitable for the purpose (but I already closed the damn page some hours ago). It should be able to handle other 32 bit surface formats fine on the last else if you refer to the rendersupp_convsurf function. Anyway, it is OFFtopic here (belongs to the linebuffer topic, in this one I build over Uze's master branch, so there is nothing from that here).
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Timing issues in uzem140

Post by Jubatian »

https://github.com/Jubatian/uzebox/tree ... tools/uzem

Any opinion on this branch, huh? For me so far it seems functional, nothing broken. Does it seem achieving its goal? (Cleaning up cycle perfection related problems obviously while correctly implementing cases experienced so far).

By the way wouldn't it be possible to assemble some list of the known problematic cases (with an explanation of what is the incorrect behavior) with Uzebox code (and probably binaries) to download and test? Uze: Like the case you mentioned, the Mode 13 demo: where it is? I can't find it among the branches I have here checked out. Artcfox: Which is that T2K, and how it behaves incorrectly on affected versions?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Timing issues in uzem140

Post by uze6666 »

I didn't have time to look at it, but doing it today. Does it include the recent fixes Artfox make to the uzem140 branch?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Timing issues in uzem140

Post by uze6666 »

Sorry, I'm getting confused with all the branches out there. I thought this one was the branch with the reorganization of of the code, but it doesn't seem to be. Is it possible for you and Artfox to organise both your change in the same branch so I can merge just one thing without risking loosing something?
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Timing issues in uzem140

Post by Artcfox »

I believe the latest T2K .hex and .lvl file (the .lvl file is inside the .zip, because the .lvl file itself is over 400MB) can be found here, but CunningFellow can tell you for sure, since it's his game.

The bug that caused it not to work was fixed in the uzem140 branch with this commit. The symptom was SD errors and not drawing the web.

Uze, by "my recent fixes" you mean the ones integrated into your uzem140 branch right? You aren't talking about the ones I just suggested you test, because those haven't been merged into the upstream uzem140 yet.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Timing issues in uzem140

Post by Artcfox »

uze6666 wrote:Sorry, I'm getting confused with all the branches out there. I thought this one was the branch with the reorganization of of the code, but it doesn't seem to be. Is it possible for you and Artfox to organise both your change in the same branch so I can merge just one thing without risking loosing something?
These are independent changes that should be able to be applied independently, and I would like to keep them separate because CunningFellow is already building something based off my branch. Ideally each feature should be developed on a topic branch, so it can have its own pull request, which allows for easy reverts that can only revert certain changes, rather than a huge group of unrelated changes.

Edit: I created a PR for my changes. CunningFellow is developing stuff based off this branch, so we can't really do anything that would change the commit ids, otherwise it could create a mess for him.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Timing issues in uzem140

Post by Jubatian »

Uh, I see topics again messed up a bit. Please wait a little, when I get home, and if with some luck my net works, I will do a cautious clean merge then and tell about it when done. My branch contains a few radical changes to how the core operates, so with this now I will rather trust myself in integrating it proper.

Yes, it may be a little bit slower if the particular game uses lots of multi-cycle instructions (like ld and st on RAM), since in this one update_hardware only emulates a single cycle (so is called repeatedely then). This is however faster for single cycle instructions, which is a worthy trade-off to achieve a more consistent performance (and some changes in the branch would have been more complicated anyway with multi-cycle update_hardware, so performance would have suffered more if it was left that way, and also the single cycle update_hardware is a lot cleaner, easier to maintain). Using a branch with it which has simpler pixel output code (no maze of ifs) may help it even more than the original code.

After integrating it I think the TODO notes relating cycle accuracy problems should be verified and fixed. There are such stuff in there (coming from a few minor bugs in the original code of which I only fixed things which were in the way) which are likely easier to solve in a clean and proper way in this new layout.

Also note that the way how cycle counts are reported changed, so looking at that doesn't necessary tell the true relation in performance between the original and this branch. The original due to some bugs here and there misses some cycles from the output (avr8::exec's return value), while this returns the correct value (except for bugs still left over noted with TODO comments).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Timing issues in uzem140

Post by Artcfox »

Jubatian wrote:Uh, I see topics again messed up a bit. Please wait a little, when I get home, and if with some luck my net works, I will do a cautious clean merge then and tell about it when done. My branch contains a few radical changes to how the core operates, so with this now I will rather trust myself in integrating it proper.

Yes, it may be a little bit slower if the particular game uses lots of multi-cycle instructions (like ld and st on RAM), since in this one update_hardware only emulates a single cycle (so is called repeatedely then). This is however faster for single cycle instructions, which is a worthy trade-off to achieve a more consistent performance (and some changes in the branch would have been more complicated anyway with multi-cycle update_hardware, so performance would have suffered more if it was left that way, and also the single cycle update_hardware is a lot cleaner, easier to maintain). Using a branch with it which has simpler pixel output code (no maze of ifs) may help it even more than the original code.

After integrating it I think the TODO notes relating cycle accuracy problems should be verified and fixed. There are such stuff in there (coming from a few minor bugs in the original code of which I only fixed things which were in the way) which are likely easier to solve in a clean and proper way in this new layout.

Also note that the way how cycle counts are reported changed, so looking at that doesn't necessary tell the true relation in performance between the original and this branch. The original due to some bugs here and there misses some cycles from the output (avr8::exec's return value), while this returns the correct value (except for bugs still left over noted with TODO comments).
Take a look at my reply in the other thread. I gave you a link to the merge that I made, and you can verify it.
Post Reply