Timer Overflow 1
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Timer Overflow 1
Howdy,
I am working on a new video mode for Tempest.
I am having a bit of a problem. When I run the code in the AVR simulator it runs OK. In the emulator it seems that the timer overflow interrupt is not happening.
Does the AVR core in UzeEm not implement interrupts apart from OC1A, OC1B ?
I am working on a new video mode for Tempest.
I am having a bit of a problem. When I run the code in the AVR simulator it runs OK. In the emulator it seems that the timer overflow interrupt is not happening.
Does the AVR core in UzeEm not implement interrupts apart from OC1A, OC1B ?
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Timer Overflow 1
Well - I think I have answered my own question by looking at David Ethertons source code.
Looks like the timer overflow int is not there.
I think even a c-challenged halfwit like myself could probably work out how to add the function. However I only have one computer and I can't install Visual Studio on it without breaking things.
I might see if my little 1.3ghz laptop can cope with it. Else I will just have to fly blind.
Looks like the timer overflow int is not there.
I think even a c-challenged halfwit like myself could probably work out how to add the function. However I only have one computer and I can't install Visual Studio on it without breaking things.
I might see if my little 1.3ghz laptop can cope with it. Else I will just have to fly blind.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Timer Overflow 1
And I see there is newer source code on the google code bit.
It still does not have the overflow interrupt but seems better layed out and easier to fix up.
I am just downloading VS2005-express to try install on the old laptop. On my internet connection it should have downloaded the ISO in just a day or two.
It still does not have the overflow interrupt but seems better layed out and easier to fix up.
I am just downloading VS2005-express to try install on the old laptop. On my internet connection it should have downloaded the ISO in just a day or two.
Re: Timer Overflow 1
As you found out, the emulator implements just the bare minimum to emulate the Uzebox kernel requirements of the time. It's been cleaned up a few times, lately by myself to add timer1b interrupt. If you feel confortable to add the functionality, go for it! Btw, VC++ is not used anymore to maintain uzem but GCC.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Timer Overflow 1
OK - did the GCC thing and can compile it now
I am just not smart enough to work it out
I added into avr8::updatehardware
and
The #defines where already in place.
All that happens now is that I get a ticking sound when the code does not run.
I suspect it may be something to do with how the emulator works out video from the line not far below that says
I am just not smart enough to work it out
I added into avr8::updatehardware
Code: Select all
if (TCNT1 > (0xFFFF - cycles))
{
if (TIMSK1 & TOIE1)
TIFR1|=TOV1; //overflow
}
Code: Select all
}else if (TIFR1 & TOV1){
TIFR1&= ~TOV1; //clear TOV1 flag
trigger_interrupt(TIMER1_OVF);
}
All that happens now is that I get a ticking sound when the code does not run.
I suspect it may be something to do with how the emulator works out video from the line not far below that says
Code: Select all
if (scanline_count >= 0 && current_cycle < 1440)
Re: Timer Overflow 1
I'm looking into it...couple questions:
1)Sorry if I ask again, did you explain what's the trick with the overflow of timer1, could help me understand some things. Seeing the code could help too.
2)Do you have a HEX file that works that I can use to test?
3)Do you actually need to trigger the interrupt or just have the flag set?
4)Are you changing the operation mode of timer1 so it can count up to 0xffff?
1)Sorry if I ask again, did you explain what's the trick with the overflow of timer1, could help me understand some things. Seeing the code could help too.
2)Do you have a HEX file that works that I can use to test?
3)Do you actually need to trigger the interrupt or just have the flag set?
4)Are you changing the operation mode of timer1 so it can count up to 0xffff?
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Timer Overflow 1
I am using Timer1 to end the pixel loop. Because OC1A and OC1B interrupts are already in use I am using OVF1 as a pseudo timer interrupt.uze6666 wrote:1)Sorry if I ask again, did you explain what's the trick with the overflow of timer1, could help me understand some things. Seeing the code could help too.
This is the code just before "Render_Line" is called.
Code: Select all
ldi ZL, 0x01 ; turn of CTC mode
sts _SFR_MEM_ADDR(TCCR1B),ZL
ldi ZL, (1<<TOV1) ; clear any pending timer1_ovf int
sts _SFR_MEM_ADDR(TIFR1),ZL
ldi r16, 0xE5 ; load 0xFFFF - (32bytes * 8Pixels * 5clocks_per_pixel) - overhead
ldi r17, 0xFA
sts _SFR_MEM_ADDR(TCNT1H), r17 ; This will make TOVF1 trigger on the 3rd last instruction
sts _SFR_MEM_ADDR(TCNT1L), r16 ; of the render loop
lds r3, _SFR_MEM_ADDR(TIMSK1) ; save the state of the timer int mask register in R3
ldi ZL, (1<<TOIE1) ; enable the timer overflow interrupt
sts _SFR_MEM_ADDR(TIMSK1),ZL
sei ; global enable interrupts.
rjmp render_tile_line_hires ; JUMP to render_tile_line
Code: Select all
1:
ldi r17, 0x00 ; Pixel 0
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
nop
nop
ldi r17, 0xFF ; Pixel 1
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
nop
nop
ldi r17, 0x00 ; Pixel 2
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
nop
nop
ldi r17, 0xFF ; Pixel 3
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
nop
nop
ldi r17, 0x00 ; Pixel 4
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
nop
nop
ldi r17, 0xFF ; Pixel 5
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
nop
nop
ldi r17, 0x00 ; Pixel 6
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
nop
nop
ldi r17, 0xFF ; Pixel 7
mov r2,r17
out _SFR_IO_ADDR(DATA_PORT),r2
rjmp 1b ; Go back always - Timer OVF will end the loop when needed
herez1:
rjmp herez1
Code: Select all
TIMER1_OVF_vect:
clr r0
out _SFR_IO_ADDR(DATA_PORT),r0 ; output black colour after visable area
ldi r16, 0xEB ; restore TCNT to 0x06EB which is what
ldi r17, 0x06 ; it would have been at this spot if we
sts _SFR_MEM_ADDR(TCNT1H), r17 ; where a vanilla pixel loop
sts _SFR_MEM_ADDR(TCNT1L), r16
sts _SFR_MEM_ADDR(TIMSK1),r3 ; Restore TimerMask to what it was
ldi ZL, 0x09
sts _SFR_MEM_ADDR(TCCR1B),ZL ; Set Timer1 back to CTC_A mode
pop r19 ; Take the RETI return address of the
pop r19 ; stack (we dont want to return to there)
; cli
WAIT r19,129 ; Extra Cycles becuase 256 pixels
dec r10 ; Check to see if all lines rendered
breq text_frame_end
Not one I know works. I only have UzEm and the AVR simulator. No real hardware to test on.uze6666 wrote:2)Do you have a HEX file that works that I can use to test?
As shown above I actually trigger interrupt to end the pixel_loop. During the pixel loop TCNT is nothing like it would be on a normal pixel render loop and I think that might be what is breaking things.uze6666 wrote:3)Do you actually need to trigger the interrupt or just have the flag set?
Yes. And then changing it back to CTC mode afterwards.uze6666 wrote:4)Are you changing the operation mode of timer1 so it can count up to 0xffff?
I have included my project directory in the zip file. It seems to do what I expect it to in the AVR-Simulator in AVR-Studio. In UzEm it only produced the white stripes I expect if I put in the DEC/BRNE to end the loop.
- Attachments
-
- VectorDemo.zip
- (154.61 KiB) Downloaded 409 times
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Timer Overflow 1
Found my problem.
I have now updated the emulator to support Timer1_OVF
Full steam ahead now.
I have now updated the emulator to support Timer1_OVF
Full steam ahead now.
Re: Timer Overflow 1
Now I understand and its a very clever trick! Never thought about using interrupts to get out of loops. I can see a couple place were this could come in handy.
Btw, I commited the changes to SVN. New version of uzem is V1.16. I improved the logic to account for the fact that CTC and normal doesn't work the same and wont triggers interrupts under the same conditions. Should still be compatible with your code. Let me know if not.
Btw, I commited the changes to SVN. New version of uzem is V1.16. I improved the logic to account for the fact that CTC and normal doesn't work the same and wont triggers interrupts under the same conditions. Should still be compatible with your code. Let me know if not.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Timer Overflow 1
As long as you are already counting clock cycles and know if the interrupt is going to fall on a 1,2 or 3 clock instruction you don't need to "realign" for latency afterwards.
If you look in the tempest thread you will see the render loop there. You save a clock cycle or two by not having to keep count. When I have to get 8 x 5 colour pixels out in 40 clock cycles, every clock cycle counts.
If you look in the tempest thread you will see the render loop there. You save a clock cycle or two by not having to keep count. When I have to get 8 x 5 colour pixels out in 40 clock cycles, every clock cycle counts.