Fixing timing, and new features

The Uzebox now have a fully functional emulator! Download and discuss it here.
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:Woo Hoo.

That is almost exactly what I asked for

http://uzebox.org/forums/viewtopic.php? ... ync#p15059

But even better because you did it on the screen.
You are right, my subconscious took time to register! :D It's the best way to go and I think I does the job quite well right now. Use the new -z flag to activate the hsync "help". And then add or remove cycles until the yellow/red bar goes away.

After that, so many functions can be added, I afraid it will slow down uzem unless we make a special build dedicated to that kind of debugging.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

Just think of how many hours this could have saved you making all the previous video modes :)
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

uze6666 wrote:Just got an idea for another feature. Uzem could profile code. Profiling would be triggered by writing to a reserved ports. One would count all cpu cycles elapsed. An another port could count only cycles elapsed while the global interrupt flag is enabled or, in other words, time only the user code. Another port could count only kernel cycles.
OK- my problem with the

Global Interrupt Enabled = User Code
Global Interrupt Disabled = Kernel code

Is that video modes now use interrupts to end the scan line (OR worse in my new one)

If it is too hard to look at the LSS/ELF file to work out what is kernel and what is user - what other ideas are usable to distinguish kernel from user ?

Could you stop couting when Timer1_Capt and Timer1_CompA trigger and resume counting when IRET happens ?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Fixing timing, and new features

Post by D3thAdd3r »

What a great way to do this :idea:
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:
uze6666 wrote:Just got an idea for another feature. Uzem could profile code. Profiling would be triggered by writing to a reserved ports. One would count all cpu cycles elapsed. An another port could count only cycles elapsed while the global interrupt flag is enabled or, in other words, time only the user code. Another port could count only kernel cycles.
OK- my problem with the

Global Interrupt Enabled = User Code
Global Interrupt Disabled = Kernel code

Is that video modes now use interrupts to end the scan line (OR worse in my new one)

If it is too hard to look at the LSS/ELF file to work out what is kernel and what is user - what other ideas are usable to distinguish kernel from user ?

Could you stop couting when Timer1_Capt and Timer1_CompA trigger and resume counting when IRET happens ?
Ah yes... We use interrupts in those modes. I will look at the elf file format.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

If the emulator sees INT13 trigger and stops the user timer and takes note of the SP

Then counts time as "kernel" time till there is a RETI at that SP

Does that acheive the goal ? (Im not sure if kernel uses anything else)
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 »

Technically that should work yes. :)
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 »

How many here uses Eclipse to develop? With the Uzem update, I'll move away from AVRStudiom to Eclipse, because now we can debug on uzem, have precise cycle counting and also access to all IOs conveniently. And contrary to the AVR Simulator, all hardware is emulated. GDB reads the .elf file and allow to step through your code either in C or assembler and monitor all variables. That allows to also monitor special memory location that would map to uzem variable like the HSYNC counter. For example, if you put a breakpoint on a line and run twice, it can display the elapsed cycles.

In other words, you guys would be crazy not to use it. The annoyance is the setup is a bit tedious for new projet, but this is something that could/should be handled by a Uzebox eclipse plugin. Uzebox Studio anyone? ;)

Anyhow, my point was about using eclipe+uzem more. That would avoid polluting and slowing the uzem code with all kind of tracing code. I already have a tutorial on the wiki. I may write something about debugging.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Fixing timing, and new features

Post by D3thAdd3r »

I use it out of habit and convenience. I never use the debugger on my C programs, and rarely mess around with cycle counting. If you've concluded it's better though I trust that judgement. It might be best if most people steered that way then, so that advice and tutorials are more general purpose. A plugin would go a long way towards that, as some of use have no attention span when it comes to researching and setting up tool details...
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

I have been using Eclipse since the start and only used AVRStudio to count cycles in the video mode for Asteroids. As soon as the Tempest/Tornado video mode started it was back to spreadsheets.

Now the HSync counter happens with the red/yellow dots is on the Uzem screen is happening - there seems no need for AVR studio there even.

I would still like to see an elapsed time counter that takes into account kernel code. Just counting elapsed clocks from start to finish in GDB could only time small functions that take less than a scanline.
Post Reply