Fixing timing, and new features
Fixing timing, and new features
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.
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.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Fixing timing, and new features
YAY - thats awesome
Re: Fixing timing, and new features
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?
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Fixing timing, and new features
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
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
Re: Fixing timing, and new features
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.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Fixing timing, and new features
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?
Re: Fixing timing, and new features
Not sure if the elf file contains memory sections informations. What kind of use did you have in mind?
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Fixing timing, and new features
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.
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.
Re: Fixing timing, and new features
Uzem is now cycle-perfect!!!
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:
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.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Fixing timing, and new features
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.
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.