Open GoogleCodeExporter opened 9 years ago
well I wrote it to work with other clocks but have not been able to test it.
The comment was targeted at that one render method and should actually work at
lower clock speeds.
That said what resolution are you running? try something very low to start with
say 56 pixels wide.
I have also never tried to get it working on the older devices (like your 32 or
the 8). If I can find time soon I will try getting it working at 20mhz assuming
it does then it will work at all other clock speeds as well(well fast enough
ones anyway).
Original comment by mdmetzle...@gmail.com
on 25 Feb 2011 at 10:52
Thanks for reply, good to know that it could work with other clock speed. I
already tried with other resolution but it doesn't work. I even can't see a big
diffrent when changing the resolution (I thought the flickering lines should be
bigger with lower resolution). I event tried to extend the assembler routine
but no luck :)
I'm not able to localize the problem, could be the video properties, an
assembler routine, sync, timer or other problem...
I'm trying this just for fun (and learning) because I have an atmega32! Not
important, so forget about it. If I have the time and make progress I will post
it here.
Thanks again
Original comment by r...@group.li
on 26 Feb 2011 at 8:12
Ok, some progress. I expected that the file hardware_setup.h is
correct/tested...
For atmega32 the sync Pin is wrong, it should be:
//sync
#define PORT_SYNC PORTD
#define DDR_SYNC DDRD
#define SYNC_PIN 5
As you can see in the attachment, it is working much better...
Original comment by r...@group.li
on 26 Feb 2011 at 9:33
Attachments:
Ok running at 120x96 @8mhz wont work now, the 3cycle output method is indeed
limited to 16mhz now. However all the other routines are not clock speed
dependent.
To sidestep this issue use a horizontal resolution of no more than 88. Then if
there are still issues with the image call TV.force_outstart(time) right after
TV.begin(...) is called. Selecting the correct value for time will require
some trial and error, the defualt value is 12 for NTSC and 12.5 for PAL, it
currently only takes integers however.
If you really want the higher resolions to work (up too 120 pixels @8mhz)
modify void render_line3c().
Remove:
"cpi %[hres],30\n\t" //615
"breq skip0\n\t"
"cpi %[hres],29\n\t"
"breq jumpto1\n\t"
"cpi %[hres],28\n\t"
"breq jumpto2\n\t"
"cpi %[hres],27\n\t"
"breq jumpto3\n\t"
"cpi %[hres],26\n\t"
"breq jumpto4\n\t"
"cpi %[hres],25\n\t"
"breq jumpto5\n\t"
"cpi %[hres],24\n\t"
"breq jumpto6\n\t"
"jumpto1:\n\t"
"rjmp skip1\n\t"
"jumpto2:\n\t"
"rjmp skip2\n\t"
"jumpto3:\n\t"
"rjmp skip3\n\t"
"jumpto4:\n\t"
"rjmp skip4\n\t"
"jumpto5:\n\t"
"rjmp skip5\n\t"
"jumpto6:\n\t"
"rjmp skip6\n\t"
"skip0:\n\t"
"byteshift\n\t" //1 \\643
"skip1:\n\t"
"byteshift\n\t" //2
"skip2:\n\t"
"byteshift\n\t" //3
"skip3:\n\t"
"byteshift\n\t" //4
"skip4:\n\t"
"byteshift\n\t" //5
"skip5:\n\t"
"byteshift\n\t" //6
"skip6:\n\t"
AND make sure there are only 16 calls byteshift macro calls. This will hard
limit this method to 120pixels but It "should" work at 8mhz.
Also I dont think set_hbi_hook will work at 8mhz just not enough time.
Original comment by mdmetzle...@gmail.com
on 26 Feb 2011 at 2:26
I can't get a higher resolution but figured out that since I changed the sync
port it is working with 48x48 pixel! See attached video
Original comment by r...@group.li
on 26 Feb 2011 at 4:09
Attachments:
Original issue reported on code.google.com by
r...@group.li
on 25 Feb 2011 at 8:10Attachments: