Mere Mortal Video on different frequencies
TransistorToaster
Posts: 149
Hi Bean,
I've been working to adapt the mere mortal video engine on different frequencies:4MHz and 64MHz to be exact. I got the 64MHz version running, but the 4MHz can't lock vertically neither on my TV or my oscilloscope. I'd like to ask you a feq questions:
1. In the meremortal code, what does the second frequency here mean? FREQ 20_000_000, 6_666_666
2. Is the PAUSEUS 14.1 supposed to give 14.1us? I measured 6us on a scope, which is closer to the NTSC spec. Also, how does SX Basic know how to scale it's delay for any given frequency. In "Exploring the SX" it says that the PAUSEUS only works for the 4MHz to 50MHz
3. It is written in the code
RETURNINT ' Repeat every 63.6uSeconds Prescaler = 1:8
I don't see the prescaler being set in a OPTION=. Please explain.
4. Please explain the parameter here. It looks as if you are telling the basic compiler to generate an interrupt at 15734Hz.
INTERRUPT 15734
I checked Chapter 7 in Exploring the SX and found no information on this. I suspect that the code is missing interrupts when I try a 4MHZ clock because I sometimes get a duration of 2 x 63us for the horizontal line timing.
5. In the video display code, I understand that I must add nops to get the correct 0.3us per pixel. So I guess there's no real question here. I did a few tricks to get 1 pixel per clock cycle at 4MHz and 2 pixels inter-tile spacing so far.
Frank
Post Edited By Moderator (Bean (Hitt Consulting)) : 8/22/2006 11:21:00 AM GMT
I've been working to adapt the mere mortal video engine on different frequencies:4MHz and 64MHz to be exact. I got the 64MHz version running, but the 4MHz can't lock vertically neither on my TV or my oscilloscope. I'd like to ask you a feq questions:
1. In the meremortal code, what does the second frequency here mean? FREQ 20_000_000, 6_666_666
2. Is the PAUSEUS 14.1 supposed to give 14.1us? I measured 6us on a scope, which is closer to the NTSC spec. Also, how does SX Basic know how to scale it's delay for any given frequency. In "Exploring the SX" it says that the PAUSEUS only works for the 4MHz to 50MHz
3. It is written in the code
RETURNINT ' Repeat every 63.6uSeconds Prescaler = 1:8
I don't see the prescaler being set in a OPTION=. Please explain.
4. Please explain the parameter here. It looks as if you are telling the basic compiler to generate an interrupt at 15734Hz.
INTERRUPT 15734
I checked Chapter 7 in Exploring the SX and found no information on this. I suspect that the code is missing interrupts when I try a 4MHZ clock because I sometimes get a duration of 2 x 63us for the horizontal line timing.
5. In the video display code, I understand that I must add nops to get the correct 0.3us per pixel. So I guess there's no real question here. I did a few tricks to get 1 pixel per clock cycle at 4MHz and 2 pixels inter-tile spacing so far.
Frank
Post Edited By Moderator (Bean (Hitt Consulting)) : 8/22/2006 11:21:00 AM GMT
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
csavage@parallax.com
PAUSEUS 14.1 should be a delay of 4.7uSec. because of the 2nd frequency (14.1 * 6_666_666 / 20_000_000).
The compiler calculates the loops required to delay the proper amount of time. If the frequency is below 4MHz the timing can get pretty bad because each loop is > 1 uSec.
You are correct, the value after INTERRUPT does indeed generate interrupts at 15734 Hz. The compiler handles the RETURNINT value and setting up the OPTION registers. The reason 4MHz won't work, is there is only 254 cycles between interrupts. If the interrupt code takes longer than 254 cycles, the interrupt won't happen at the proper time.
I'd love to see how you did that ! Can you post your code ?
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
"You're braver than you believe, stronger than you seem, and smarter than you think" Christopher Robin to Pooh
Post Edited (Bean (Hitt Consulting)) : 8/22/2006 11:17:59 AM GMT
Frank said...
>>5. In the video display code, I understand that I must add nops to get the correct 0.3us per pixel. So
>>I guess there's no real question here. I did a few tricks to get 1 pixel per clock cycle at 4MHz and 2 pixels
>>inter-tile spacing so far.
>I'd love to see how you did that ! Can you post your code ?
Sure I'll do that when I finalize. The goal of going 4MHz was to not use an external oscillator The main issue that I overcame was to do a little shaving to not exceed the available clock cycles in the 63us ISR period. I summarize what I did :
The main idea is to prepare the pixels to be displayed from tile lookup during the Hsync and black portion of the 63us line. All the prep work is stored in a brand new 16*8 bit array. At the active video part of the 63us line, I just copy one byte at a time from the prep array and do 7 rotates to shift out the bit pattern. Your code works on 0.3us (6cc) per pixel. At 4Mhz, one cc is 0.25us, so each rotate takes 1cc equivalent to one pixel.
Frank
That sound reasonable. Make sure you have enough cycles left outside the ISR for the game code to run though...
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
"You're braver than you believe, stronger than you seem, and smarter than you think" Christopher Robin to Pooh
·