Nick, a crystal can't directly produce the needed frequency for the AD725. The chip needs a strong (buffered) clock signal. The AD725 datasheet has a reference schematic for the oscillator, or you can simply use a crystal oscillator like I did, although they are more expensive and maybe harder to find.
Although if I wanted PAL output (which we use in Australia) I could simply clock the Atmega328 at 17.734475 MHz from the crystal, set the CLKOUT fuse, and connect that directly to the AD725. That way the main processor runs a bit faster than usual and I get the clock signal as well.
I remember sprites from the C64, my GPascal compiler had various supporting functions for them. You set up the bitmap, location, etc. and the chip did the rest. It also reported collisions, which I will be interested to see how you handled.
I am impressed by the fact that even though you say you can handle 3 sprites per scan line, the images you posted usually look "busier" than that. It's quite impressive how there can be a lot happening on the screen, with the minimal hardware you used.
Yes, there are a few tricks at play There can only be three sprites per scanline but I do multiplexing so that I have different set of three sprites per scanline. There can be virtually any number of sprites on the screen vertically. Also, collectable items like gold and hearts are technically background tiles. I just animate the tiles, i.e. swap their tile pointers in RAM. I divide the screen vertically to regions and scan one region each frame. If the tile is a heart or gold I update its pointer. This way updating the tiles is quite efficient.
The mistake you did, Nick, with your 17cycles and the 9th bit was not the hardware but not checking your software.A 16MHz AVR can do a heck of a lot more than displaying 20char/per line VGA.
(1/60) / 525 * 1e6 = 31.74 uS
((1/60) / 525 * 1e9) / 800 = 39.68 nS
125 / 39.68 = 3.15
The hardest part was getting sprites to work. I had to painfully cycle count the scanline routine so that it fetches tile data and masks sprites on top of the scanline while outputting a pixel every 6 cycles.
8 * 62.5 * 104 = 52000 nS
Does it render directly from tiles? (ie. no charmap...)
I've been trying to guess your timing figures, and from the quoted 104 horizontal resolution, and the NTSC standard of 51.5 µS for the visible portion of the line I am estimating that you have 8 clock cycles per pixel:Code: [Select] 8 * 62.5 * 104 = 52000 nSDoes that sound right? It can't, of course, because you said a pixel every 6 clock cycles, so where did I go wrong?
I thought I'd do quick search on the rgb / ntsc chip...http://belogic.com/uzebox/index.aspIt seems there's quite a lot going on!
Uzebox is an impressive feat indeed
So if you can demonstrate where my calculations are wrong, and you can send "a heck of a lot more" I would be pleased to hear it.