czuhars wrote:
Quote:
The Uzebox is a retro console using an ATmega644 that does something similar, but because it runs at 28.6Mhz (8 times the NTSC color burst frequency), it can use software to generate the video signals, rather than external hardware.
This is exactly the kind of hint I’ve been looking for. I’m at a fork in my project, deciding between building my clock dividing, video address generating and character ROM circuits, ala Apple II and /// in hardware or in software within a micro controller of some sort. In order to do a micro controller, I’d need to have it also generate positive and inverse 14mhz, 7mhz, 3.5MHz and more signals. A stock 16mhz Arduino Mega won’t cut it, but something in the 28MHz range would be ideal (at least for timing generation).
Chris
No idea what sort of image you're after but a stock ATmega at 16Mhz is more than capable of video generation - even a '328 with 2KB internal RAM can generate character based 40x25 composite video. My own system has a ATmega 1284p @16Mhz and that does 320x240 monochrome pixel based composite video, but do lookup Daryl Rictoors stuff here and on his own website.
(And another stand-alone ATmega project that does video is the FigNation system - great if you like Forth, also search for the Arduino TVout libraries and projects, or read up on the Sinclair ZX80 for a home computer which bit-banged video via a 4Mhz Z80 and had just 1K of RAM)
The trick is to know that a scan line is 64µS - or in reality less than that as you can trigger the horizontal sync early giving you more time for your other code to run (if needed), so a 64µS interrupt is all you need to clock out the pixels for each line.
The hard part then is getting the data from the 6502 into the ATmega - my approach is a 256 byte shared RAM area, but others have used parallel buses or even serial.
-Gordon
_________________
--
Gordon Henderson.
See my
Ruby 6502 and 65816 SBC projects here:
https://projects.drogon.net/ruby/