Fixing timing, and new features

The Uzebox now have a fully functional emulator! Download and discuss it here.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Fixing timing, and new features

Post by uberlinuxguy »

Actually, I just did a clean

Code: Select all

git clone


Then I did a

Code: Select all

git checkout -b uzem140
and then a

Code: Select all

git apply --check 0001-Update-to-kernel-and-Uzem-to-support-SPI-RAM.patch
and much to my surprise, it was clean so I did a

Code: Select all

git apply 0001-Update-to-kernel-and-Uzem-to-support-SPI-RAM.patch
And it looks like it is all there and ok. Uzem compiled just fine. Need to check the kernel build with the SPIRAMDemo I am building, but I'm going to guess that works too since the git apply didn't give any bad errors.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Fixing timing, and new features

Post by uberlinuxguy »

Actually after I ran it it looked like it still was doing the wrong version or branch. Some of the code changes that were put in your branch didn't seem to be working correctly. I guess I have to look at it a little more.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

uberlinuxguy wrote:Actually after I ran it it looked like it still was doing the wrong version or branch. Some of the code changes that were put in your branch didn't seem to be working correctly. I guess I have to look at it a little more.
Ok, let me know when you're done. If you could send me a pull request that would be even better.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Fixing timing, and new features

Post by uberlinuxguy »

I ran back into some odd problems with the SD code that I know I fixed when I applied it to the master branch, but for some reason, are popping up again after I applied to the uzem140 branch. It's going to take me a bit to figure out where that broke. I've also had issues with things not compiled with the new kernel mods not working, which is really confusing because the SD Kernel code is the same (with a minor tweak to the initialization routine) and the emulator should handle it the same. I'll definitely have to get back to you.... :?

I will also submit a pull request, though I'm not 100% sure what that does, time to RTFM. :)
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

CunningFellow wrote:Is this feature still in Uzem140 ?

http://uzebox.org/forums/viewtopic.php? ... 256#p15647
It disappeared! Seems Artfox or Jubatian removed it while doing all the optimizations. Was it because it would not work with the way the rendering is done? I'd like it back too fir sure, neatly put in some function.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Fixing timing, and new features

Post by Artcfox »

uze6666 wrote:
CunningFellow wrote:Is this feature still in Uzem140 ?

http://uzebox.org/forums/viewtopic.php? ... 256#p15647
It disappeared! Seems Artfox or Jubatian removed it while doing all the optimizations. Was it because it would not work with the way the rendering is done? I'd like it back too fir sure, neatly put in some function.
As far as I can tell, it was initially in there, but commented out. When we both made improvements, the commented out code did not get improved/refactored by either of us (to me it looked like abandoned code) and in Jubatian's linebuffer branch he removed bits and pieces of commented out code (what looked like cruft), and the unused variables that went with it. When I combined part of his linebuffer branch with some other tricks we came up with, I merged the bits that removed those lines because I believed it was abandoned code as well. It's easy enough to put back though, but it will need to be freshened up in order to fit within the new framework.

This commit is the one that removed that chunk of commented out code shown below:

Code: Select all

					if(hsyncHelp){
						if(prev_scanline!=NULL && elapsedCycles > HSYNC_PERIOD){
							for(u8 x=0;x<(elapsedCycles-HSYNC_PERIOD);x++){
								prev_scanline[(x*5)+5] = hsync_more_col;
								prev_scanline[(x*5)+6] = hsync_more_col;
								prev_scanline[(x*5)+7] = hsync_more_col;
								prev_scanline[(x*5)+8] = 0;
								prev_scanline[(x*5)+9] = 0;
								prev_scanline[(x*5)+5+(screen->pitch>>2)] = hsync_more_col;
								prev_scanline[(x*5)+6+(screen->pitch>>2)] = hsync_more_col;
								prev_scanline[(x*5)+7+(screen->pitch>>2)] = hsync_more_col;
								prev_scanline[(x*5)+8+(screen->pitch>>2)] = 0;
								prev_scanline[(x*5)+9+(screen->pitch>>2)] = 0;
							}
						}else if(prev_scanline!=NULL && elapsedCycles < HSYNC_PERIOD){
							for(u8 x=0;x<(HSYNC_PERIOD-elapsedCycles);x++){
								prev_scanline[(x*5)+5] = hsync_less_col;
								prev_scanline[(x*5)+6] = hsync_less_col;
								prev_scanline[(x*5)+7] = hsync_less_col;
								prev_scanline[(x*5)+8] = 0;
								prev_scanline[(x*5)+9] = 0;
								prev_scanline[(x*5)+5+(screen->pitch>>2)] = hsync_less_col;
								prev_scanline[(x*5)+6+(screen->pitch>>2)] = hsync_less_col;
								prev_scanline[(x*5)+7+(screen->pitch>>2)] = hsync_less_col;
								prev_scanline[(x*5)+8+(screen->pitch>>2)] = 0;
								prev_scanline[(x*5)+9+(screen->pitch>>2)] = 0;
							}
						}
						current_cycle += (elapsedCycles - HSYNC_PERIOD); //to simulate line offsync
					}
Is that the thing you're talking about?

But I don't understand what it's trying to do with the HSYNC_PERIOD, nor do I understand why the current code has this in there:

Code: Select all

if (scanline_count == -999 && elapsedCycles >= HSYNC_HALF_PERIOD -10 && elapsedCycles <= HSYNC_HALF_PERIOD + 10)
Uze, could you explain why there is such a big window for the elapsedCycles?

I'm thinking instead of commenting stuff out for debugging, to give it a proper #ifdef that you can set in the Makefile. Then we would know that it's not cruft or abandoned code. For a future change I'm planning on allowing all of the gdb stuff to be excluded from being compiled by setting a compile flag in the Makefile. I made a test build like that and it ran significantly faster without any of the gdb stuff compiled in, because even if it's disabled, it still has multiple conditionals that get hit every simulated clock cycle.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Fixing timing, and new features

Post by Jubatian »

I removed that chunk of commented out code since it seemed to be something abandoned, and there was no documentation by it how to use it, what it does, and whether it relies on anything else, so I figured it might not even work already. It should have been made a feature accessible by a command line switch. I only removed it when introducing the linebuffer, which certainly broke it the way it was implemented, so I figured even as a hint left behind by someone, it became rather dangerous than useful.

Right now I use a modded emulator for graphics mode design which prints the count of cycles used for each line not having 1820 cycles on the console along with line numbers. Of course it also prints vsync lines, but I found that useful too to see the mode's behavior in overall (and whether I accidentally did something which would upset the kernel out of the display region).
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

My bad for not commenting that code. It was for determining which scan lines are not 1820 cycles on a graphical manner. This was very experimental and I was still trying things when all the optimizations rush happened. I had a command line switch for that 'z' but cant remember why I commented it out...I think I was still thinking where I should put such code.

What I liked about the graphical way (you can see a screen shot a couple posts higher) is its easier too see where the issue occurs, like on the first row of a tile, etc.

But a console way is good too if you found a good way to display it. May I suggest you then add your code in your branch and enable it via the 'z' switch? Me and CunningFellow also need such functionality when working
on video modes.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Fixing timing, and new features

Post by Artcfox »

uze6666 wrote:My bad for not commenting that code. It was for determining which scan lines are not 1820 cycles on a graphical manner. This was very experimental and I was still trying things when all the optimizations rush happened. I had a command line switch for that 'z' but cant remember why I commented it out...I think I was still thinking where I should put such code.

What I liked about the graphical way (you can see a screen shot a couple posts higher) is its easier too see where the issue occurs, like on the first row of a tile, etc.

But a console way is good too if you found a good way to display it. May I suggest you then add your code in your branch and enable it via the 'z' switch? Me and CunningFellow also need such functionality when working
on video modes.
Uze, if you'd like, I can put the graphical way back in (commented out), and then I can let you fix that up?
Post Reply