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:

Fixing timing, and new features

Post by uze6666 »

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: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

YAY - thats awesome
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, 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: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

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: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

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: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

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: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

Not sure if the elf file contains memory sections informations. What kind of use did you have in mind?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

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: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

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: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Fixing timing, and new features

Post by CunningFellow »

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