Fixing timing, and new features

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Fixing timing, and new features

Post by uze6666 » Thu Aug 06, 2015 6:46 pm

I have started to work on the feature requested by CunningFellow to be able to indicate problems with HSYNC periods. This is of course to ease the pain of new video mode development. And since new video modes are also something I like to do from time to time ;) , I'm particularly interested in getting this done.

The big difficulty is that uzem is not a cycle perfect emulator and all kind of situations cause timing to drift from the real hardware, specially interrupts. So anyway, using the AVR Simulator2 and uzem in debug mode side-by-side, I started to fix those one by one starting at the reset vector and insuring clock cycles counters matches perfectly. So far I have reached the first push instruction in the kernel video interrupt routine and timing matches perfectly (cycle counter and TIMER1). Much more left to do, but getting there. :)

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow » Thu Aug 06, 2015 10:37 pm

YAY - thats awesome

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

Re: Fixing timing, and new features

Post by uze6666 » Thu Aug 06, 2015 11:59 pm

CunningFellow, question about the interrupt response time. The 644 datasheet says minimum 5 cycles response time...what exactly does that mean? The time from interrupt flag set to entering the routine? Tracing throught Atmel simulator 2, which is based upon the physical model of the chips I'm told, I observe 3 cycles to reach the JMP in the vector table. So from there taking the JMP would make it 6 cycles. Of course, one can also use a RJMP, so I guess that's where the 5 cycles in the datasheet is coming from. Did you empirically test those values?

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow » Fri Aug 07, 2015 12:31 am

The original AT90S2xxx chips when the datasheet was first written could only have an RJMP in the vectors. So it would be refering to that.

6 clocks would be if you use JMP rather than RJMP

Greater than 6 if the instruction that was interrupted is a multi word or multi clock instruction

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

Re: Fixing timing, and new features

Post by uze6666 » Fri Aug 07, 2015 7:00 pm

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.

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow » Fri Aug 07, 2015 9:28 pm

could you use output from the compiler (elf/lss file) to feed UZEM to work out what was kernel code and what was user code?

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

Re: Fixing timing, and new features

Post by uze6666 » Fri Aug 07, 2015 11:51 pm

Not sure if the elf file contains memory sections informations. What kind of use did you have in mind?

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow » Sat Aug 08, 2015 12:09 am

Was thinking that the you could work out from the compiler output what address kernel stuff like Syncs and Sounds occupied.

Then when you output to the port to start counting even if you ran into kernel interrupts - that UZEM could automatically subtract the non user clocks from the total.

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

Re: Fixing timing, and new features

Post by uze6666 » Sat Aug 08, 2015 6:15 am

Image
Uzem is now cycle-perfect!!! :mrgreen:

Btw, I got an idea while fixing the timing that may be quicker than the file logging: display as an overlay how much cycles are missing or in extra. Each cycles is displayed as a dot. Yellow means cycles are missing, red means too many cycles. 3 red dots: 3 cycles too many on the scanline. Look like this:
Image
So in this example, on each tile row edge, I have a bug with 6 extra cycles. And when I switch between the overlay and main section, I'm missing four cycles. It becomes a no brainer to fix timing issues now. :)

Oh, and I also added visual cues on lines that have problems. They will appear shifted a bit.

I have created a new branch (uzem140) on github you can pull from until I complete all fixes and cleanups.

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow » Sat Aug 08, 2015 8:33 am

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest