you will eat all but the clock ticks during HSYNC just like the origanal Uzebox...
Well to be fair, I believe only some kernel sound asm is done during the short HSYNC while user code is executed during the vertical retrace period(which can be cheated on Uzebox for lots of extra cycles) like many console back in the day did it.
I think I'm gonna use a Atmega32 tied to 64k SRAM ( my VRAM ) and just have a three chip design.
That's a nice chunk of ram you can probably do something with that. I could see bitmapping out the display and having double buffers, then you wouldn't be a slave to vsync anymore could chug down to 15 frames a second instead of crashing. Then of course you'd be doing lots of communications between main and vid cpus depending on how you do it, so that might be an issue. Another thing I could see, if the 'mega32 can clock to 28 mhz, just put mode 3 as is on the chip. Then whenever the user sets a sprite or tile on the main cpu interrupt the video cpu and feed it coordinates, tile index, etc. Really mode 3 would shine with lots of ram and a dedicated cpu that has all of vblank to do ram tiles, would just need to calculate sprite details early in the game logic to take advantage of it. Not sure how you'd do tiles, you'd probably have to reflash the vid chip with the tile data or have enough ram to hold all the tiles plus ram tiles(but then addressing above 64k would need a bank switch screwing the mode 3 timing?). I like the idea, probably a lot more crash resistant than the current Uzebox when time runs low.
That's the idea, a 240x224x8bit memory area that is the VRAM so the program can ether write individual pixels or use a mode 3 like video API.
Another thing I could see, if the 'mega32 can clock to 28 mhz, just put mode 3 as is on the chip.
That's the plan, but the 'mega32 like the 'mega644 has way to many extra pins to be a dedicated video chip, I'm looking for something that can do 28Mhz and has about 20 pins.
I'm looking for something that can do 28Mhz and has about 20 pins.
Hmm, I don't see how you can easily address 64k or memory with such a small pin count though. You'll need 16+8 pins for parallel addr/data bus. Are you talking about some kind of serial ram then? On the resolution (240x224)/1024 = 52.5 k so there's not enough space for 2 buffers. The problem would be then you can't display one while you're working on the other so you are still tied to vertical blank(or suffer bad flicker), and still doing all your drawing in vblank it since the vram's bus will have to be tied up when it's outputting to the tv. Unless you are talking about 1 cpu for blitting and 1 for drawing to the screen with shared memory, but how would it work without 2 vrams?
I think it sounds like GLneo wants all the video processing to be done by the main CPU, and all he wants the second CPU to do is take in information and output the data in proper time. In which case all it needs to do is have a burst receive (burst transmit from the CPU) during some of the blanking periods, and send all the data to the CPU which will output it at the slow speed. He could even do this on a line-by-line basis. I think that you're right though that he'll need more pins (probably 28 minimum). Currently it looks like he has the transfer being accomplished using a SPI bus, which will take about 0.43 seconds (assuming a 1Mbit transfer speed) to send a full 240x224 frame with 8bits per pixel (430,080 bits). Each line would take something like 2ms (way too slow, no?), though this is something which could easily be done by a DMA with no respect for timing. I don't know how fast you can get the SPI bus to run. I can't really think of a trivial interface which isn't too slow for something like this.
I think that you're probably right though that he'll need some sort of parallel protocol to make it work, and for that, he'll need more pins, and he'll probably want a CPU which can read in at least 16 bits at a time...
Ok I didn't know we were talking DMA here, I thought he was planning 644 for work mcu. Well there's definitely a lot of stuff you can do with that kind of stuff and I wont pretend I know much about that. Yeah it's a lot of bits to write to ram if you were to do the line by line, not really saving time. A lot less if you only have to write x,y,index for sprites, then let vid blit it to ram and wait for sync. Other thing maybe, have an inverted/alternative clock setup for one of the mcus(not sure how hard that is). Both would have to be the same freq. of course and run on every opposite tick, seen it somewhere IIRC. The ram should probably be asynchronous then and/or be able to latch at 16xNTSC freq, then at least you wouldn't have to take turns and could even write to it as the scanline is drawing like nothing else is connected. Well, at least above where the scanline is to avoid flicker. I think all 3 of us are talking about 3 entirely different machines though
Okay, so I did get the idea right. In that case: yes, you will need something fast, and I2C on the ATMega644 looks like it's limited to 400kHz, the SPI looks like it may be able to do as fast as (oscillator speed)/2
Either way, you'll need to make sure that both chips in the system, support an outrageously fast speed (in excess of 1MHz) if you want to use a serial protocol. A parallel system would likely be faster, but it would mean that both CPUs would need a lot of pins. You also have to remember that if you use a parallel protocol, you'll be limited by the fact that an 8bit MCU can only read in 8 bits at a time, so you'd have to plan around that when reading in banks worth of information.
Ok so if I send my video info to the Video CPU where will it store it? What kinda SRAM do they sell? and how do you interface and atmega with external SRAM?
GLneo wrote:Ok so if I send my video info to the Video CPU where will it store it? What kinda SRAM do they sell? and how do you interface and atmega with external SRAM?
Well... I was thinking that you were probably going to send this line by line. That way you didn't have to have nearly as much RAM. That being said these are all questions you should investigate the answers to! What fun is it if we do all the design work for you??
, well back to figuring things out!