Building a framebuffer from simple electronics.. ideas?


skeezix

Internal Development
Joined
Mar 11, 2003
Messages
8,063
Website
www.codejedi.com
hey guys,

As you may know, I'm a pretty competant software guy; electronics wise, I've learned enough to know about basic housewiring and basic digital electronics, mostly from the repair side .. not the design side. Something goes wrong in my car or house, I can pull out a multimeter and have a chance at it. From repairing arcade pcboards years ago, I picked up a logic probe and chip puller and so on, and have a pretty good chance at figuring out whats going wrong in a board and fixing it. So, not completely worthless. Just mostly :)

But designing wise.. I took some courses in highschool (yeah, my school was cool, it had an electronics shop, wood shop, welding shop, auto shop, etc; when I was 16, I was cutting steel bars with an arc welder.. good times :) -- anyway, so I know Ohms law and some basics, but am essentially clueless :)

So I thought it would be cool to make a rudimentary early 80s computer from scratch; I mean, you can pick up an Arduino pr r-pi or XBoard for next to nothing and you're done; you can pick up an SoC chip and it takes almost nothing to get it working.. quit amazing really. But thats cheating. And I'm not too interested in learning the software side, since I've done that, even on low level to the metal stuff.

I've written emus, and you have to understand whats going on to a point, but my emus capped out around the early 16bit era; things started to get complex there. Multi-processor 8bit early 16bit, that was as far as I got. And you don't have to really know the electroncis down to each component to get that to work.. you need to see the schematics or board, and see every other chip and make conclusions .... a different process.

So my first cut was getting a 6502 and some pacman RAM and trying to get something going; I got a part of the way, but I've since ordered an oscilliscipe, as theres only so much you can do from guessing; an o-scope is printf for electronics, you know? Anyway, I had 3-4 breadboards going a couple weeks back.. one for power supply, one for rom and ram, another for cpu and stuff.. it just got out of control; all those data lines, big freaking mess :) Anyway, I got lazy, figured that might be taking it a bit far. I'd soon be etching boards in my bathtub (been there, done that :eek: ), no time for that right now. So back to a basic, but not quite entirely basic chip, just ot reduce the number of wires I needed hopping around.

So I went back to a basic PIC that has a bit of flash rom and a bit of RAM (like, 8k of flash and a few hundred b of RAM.. good times ;) ; wiring up a basic power supply for that, and some I/O lines so I can flash it, and its good to go; you can get going with a crystal+PIC+power, and its alive and ticking . I figurdd if I can get vic-20/C64 level of system going on (minus support chips and floppy drives and so on ;) , that'd be pretty instructional. (Goal here of course is to write a shitty Space Invaders game, on my own hardware, and call it a day.)

Now, most people go off and start with LEDs and stepper motors and such, easy stuff. I've worked on basic robots with guys before, from the software side. Well, most people use arduino and the built in functions nowadays - way too easy when you can buy a Robot Kit on ebay! - but I'm not using any OS, firmware, libraries, nothing, of course. (Well, most people go to the pub or something, sure, but I'm brain damaged, right? :)

ANYWAY, what I've been working on is trying to figure out NTSC composite output, right from the chip; stepper motors and stuff.. pfft, easy sauce. Making a little R/C car into your robot slave, not too bad. But writing output to a display, not just a serial or LED bar... I hadn't realized NTSC was such a total whore to do, but okay, I sort of get it now. This is what I wanted to learn.. low level really fiddly stuff, from the electronics side. You can get TV chips, or an SoC that has VGA out, etc, right easy, but I'm doing it with nothing, just a PIC + some short code. (Really, I shoudl figure out VGA, maybe its easier than NTSC? certainly a lot more useful/available now.. how many composite TVs have you seen in the last few years? But I've got a C64 monitor here that I didn't cook yet :)

.. and it sort of works! I can draw a line on there (white on black or the reverse, woowoo), and I've sort of got a handle on drawing some basic colour (which is a right bitch I tell you, at NTSC speeds.) Can't wait for my scope to arrive so I can see the waveform going on, get the timing right.. But some folks have documented this before, so I'll figure it out.

Anyway, fine, I'll bang on this a couple more weeks, in time here or there, see if I can get it going right. I should add a joystick/gamepad port and see if I can move the line back and forth, and keep it straight (harder than you think ;) . The old school joysticxks use a REALYL trivial interface.. take you like 5 I/O lines to wire up an Atari port and use your old Amiga joystick, piece of cake.

Essentially what I've got going is a homegrown Atari 2600, minus some features like player/missile sprites; theres no framebuffer, so I have to render to the TV display at exactly the right frequency, or it all goes to shit; I have to render every pixel just-right, with a couple of cycles in between for doing any other stuff. On the up side, I can change the resolution to whatever I like, and do colour and such ... now, I coudl go pick up a really fast crystal and PIC .. you can get PICs that run at 100mhz or more, and have lots of cycles between each NTSC pulse set, but thats cheating (and the o-scope I ordered only has 20mhz bandwidth.. so ideally I Shoudl run at 5mhz or less, so the o-scope can have a chance at monitoring the CPU. Cause how awesome is that, to watch the individual CPU ticks going by?) (sure, in emulation, I've done it to death, but thats beside the point; watching the actual electrical pulses on a scope is pretty awesome. And back in the day, the big analog desk-scopes, they're sexy beasts. Probably 30 pounds for a 4" scope display.. oh man :eek: )

So, all that said, I'm thinking one of the next steps would be adding a framebuffer or the like; or go back to a basic chip and try to figure out how to pull SD card into RAM with some basic bootloader or something, but that might be going too far ;)

I've never really thought about it at this low level; do I run the clock at 'double' what I'd like, and then somehow filter the oscilator signal so that every other tick goes to the PIC, and every other... other tick goes to another PIC, and have them both read a single outboard RAM chip? ie: PIC-A writing to the RAM chip, and PIC-B reading from it and managing the TV signal? That woudl more or less fake a framebuffer..

(Most systems have framebuffer in RAM, but if I'm working on the assumption that my display is bitmapped and in RAM, well, little PICs I'm aimign to sue don't have the RAM for that; and writing multi-hreading code to interleave the framebuffer render and the framebuffer population, and audio and such, is a pita when you're rolling it 100% yourself.)

Anyone have any ideas on how that (framebuffer) would work, in primitive electronics, with no cheating?

Eventually I'm going to switch over to a 16bit chip with some outboard RAM and flash/SD, so I can move from Atari 2600 level to more less-than-Genesis level, and then I can give up :)

jeff
 
I think your dual PIC might be the best if your not willing to user a faster PIC. Depending on how smart the memory chips is you might need to build a MUX to control which PIC has access to the RAM.

Edit: by the way my PIC project was just displaying to a simple text LED display ;-) I could display text and but after that I didnt really know what to do with it.
 
Last edited by a moderator:
yeah, getting serial out is not too bad .. getting VGA or NTSC or something, right bitch :)

I'm half tempted to cheat, be so much easier, but thats defeating the purpose :)

edit: yeah a MUX has been on the mind; I've not looked into that too much yet..  like, if you have tow chips reading one RAM, and you just drive them into a MUX, and then need some signal to tell the MUX which request to pass through.. but I'm not sure how the whole timing of that stuff works, so need ot read up a bit.

The 7400 ICs have an 8bit and 16bit MUX, that sort of thing..

jeff

edit again (screaming kid, can't think straight) .. faster chip wouldn't make it that much easier; nomatter what, interleaving code with rendering is really annoying, and on a low end 8bit chip, trying to do multi-tasking or whatever.. right pita too; given my goal at least is some hw learning on breadboards, then a hw solution seems more interesting :)
 
Last edited by a moderator:
I'd say a dual-ported (S)RAM and some hw counter stuff should make it a bit easier on the software - eg. A dual ported ram + the address generated my some incrementing system and compared to a stop register and on compare reset to zero. Control signals (whatever you need, vsync etc) would also be in the RAM output data and you need to have every bit of the video output including blanking regions in the RAM so it is a bit wasteful... Alternatively, without a dual-ported ram some latches for the control signals and a switching system to override the address when you access the RAM would allow you to update the display during blanking ...
 
Buddy of mine had an interesting idea; have the second microcontroller running its communication code, with an interupt timed to land for every pixel generation requirement; as long as each interupt finishes short enough time to not lose a pixel, that would at least let the 'framebuffer cpu' do its screen generation; the rest of the time, when not in interupt, it can be talking to the main PIC; set up (say) 4b 'index' lines and 4bit 'colour lines', say, or whatever, and store a bitmap in memory on the framebuffer chip.
 
I bought this book to try something similar (build my own console). However, I've not had chance to read it much, but it covers a lot of stuff and it was highly recommended when I was looking around for information on such projects

http://www.amazon.co.uk/Black-Video-Game-Console-Design/dp/0672328208

Edit:

When I was trying to design mine, I was going to have a seperate chip and a RAM chip. The main would push my "bitmap" to the RAM, and the 2nd chip would read line by line and generate a video signal. If you generate a C64 style border, it means you won't need to access the RAM chip in those operations, giving the game chip time to update the screen :)

There was a project I saw where a guy used two PICs for generating a game with graphics and sound effects, but the link seems dead (http://www.ugrad.physics.mcgill.ca/~beek/alienslaughter/, in case it's cached somewhere)
 
Last edited by a moderator:
yeah, the chip to chip push was more or less what I was thinking; I wasn't aware of DPRAM urjaman pointed out above, so maybe can get a chip like that, for nearly simultaneous read/write ... but with an external SRAM chip and basic chips like 6502, it seems a fair amount of trouble (at least on a few breadboards with a spaghetti of wiring :) -- ie: you have to be careful about the RAM's "wait" signal, since the microcontroller is faster than the RAMs read/write ability, especially if you have two controllers going after it..

I'm going to see if I can get colour NTSC working out of the controller first (real PITA!), and then worry about breaking off as a separate framebuffer. Or maybe try to work out how a VGA signal is constructed, since more monitors/TVs can do that I bet than composite NTSC nowadays (at least in my home office :eek: ), and it may even be easier..

jeff

yeah, I've heard good things about La Mothe books, going to check one out soon :)
 
Last edited by a moderator:
VGA is ridiciously simple compared to NTSC (or, even worse, PAL.)

All you need is a timing/address generator (like a Motorola 68B45, or you could make it out of counters and some discrete logic to trigger hsync and vsync), some RAM, and a DAC (resistor DAC works fine)

EDIT: And you can then get some other chip to convert analog RGB to a TV signal. In a project I'm working on, I'll use a motorola 1377, but there's also more modern chips that are easier to deal with (no transformers etc..)
 
Last edited by a moderator:
FWIW the BBC micro ran with the system RAM running at twice the clock of either the GPU or the display controller.  I'd guess that's fairly easy to set up if you can get the RAM to trigger on both peak and trough, with the CPU ticking on peak and the display controller running on trough.  Competing systems had the display controller blocking the CPU when they needed to access the RAM - no idea how that works on an electronic level.

The display controller is pretty much idle during flyback though, so it's not such a big deal to block the CPU when reading display data, if you can do it.  The way I used to write games, you did all the slow rendering between frames anyway.  Having full access during display only lets you take a little longer in rendering if you're careful to finish the stuff at the top of frame first - because if you're drawing when the beam passes over you, you get screen tearing - but I never optimised my games that hard, so if it did happen that way for me it was only by accident.
 
Have you looked at that website : http://www.rickard.gunee.com/projects/video/sx/gamesys.php

The guy made a basic gaming console, he is not using a PIC but a similar µC.

Even if you don't want to make a clone of his console, he found a way to make a NTCS/PAL out with 5 outputs, a resistor ladder and some code.
 
Last edited by a moderator:
Well damn, that guy did nearly the same thing I'm working on; same chips, too :)

He's got colour working nicely looks like.. I'll have to take a look in those schematics :)

I'm doing the NTSC output purely in code; you _can_ use chips to make your life easier, but you can also do it entirely in code; if your chip is fast enough and your'e really tight with your timings, its all jumps bumps in voltage fed at the right time, and mhz precision; you screw your timing up just one tiny bit and it all goes to hell. The dedicated chips make it a piece of cke.. but I'm being an idiot, and opting to do it all in code. Same sort of circuit he has.. resister ladder etc.

jeff
 
Last edited by a moderator:
Have you looked at that website : http://www.rickard.gunee.com/projects/video/sx/gamesys.php

The guy made a basic gaming console, he is not using a PIC but a similar µC.

Even if you don't want to make a clone of his console, he found a way to make a NTCS/PAL out with 5 outputs, a resistor ladder and some code.
lol, I edited this link into my post - then removed it when I re-read Jeff talking about framebuffers :) The Alien Slaughter, which I found from that site, used two PIC chips in sync to make a much fuller console :)
 
Last edited by a moderator:
This guy doesn't do any framebuffer either, I think; it would make the code a lot easier to do, and of course is still early 80s tech so I figured to look into it. If I move to a 16bit PICm, then it just has to be done :)
 
I once did something like this using an 80-pin 128 macrocell FPGA to generate a NTSC signal. It was a setup with counters similar to what was suggested above except all the logic and counters were programed into the FPGA.

The pixel data was read from RAM at the same time the output pixels were generated, so that could be done with only some combinatorial logic. Same thing with the address line for the RAM, which was built with carefully selected bits from the counters so that the output lied in the center of the TV. The Hsync and Vsync signals were also generated in similar fashion. I only managed black and white output at first, but later managed to hack in 4-bit grayscale via using PWM (one pulse per pixel, with a filter to smooth it out).

Probably not the best solution but it served well as a project for both the VHDL and Television courses I was taking at the time. =P
 
Last edited by a moderator:
I'm steering clear of FPGAs right now; whole different topic, and tryign to keep the scope small so that i) I have a chance at getting it without popping a lot of chips :) , and ii) in doing it in small time frame; I have very limited free tike :(

VHDL another day :eek:

Getting b/w is not too hard, straight out of the chip; its all just a timing problem. Colour.. now colour is a right bitch!

jeff
 
Maybe using a phase locked loop (PLL) could make generating the color signal a bit easier. PLL chips are quite cheap/simple.

When the PLL is locked onto the color reference signal then adding a DC offset to the oscilator input would change the phase of the output with respect to the reference signal. This would allow control over the hue of the color signal output. Controlling he saturation is easier, just need to change the amplitude of the output square wave.

The result signal can then be combined with the luminance signal generated by the chip with just some capacitors and resistors.
 
Last edited by a moderator:
Back
Top