Building a CPU and I want the propeller to be my GPU
super_tnt
Posts: 9
I'm starting to design and build a CPU (no I'm not crazy) and I want the propeller to be my GPU. The setup I want to have is the propeller connected to one port of a dual port sram so it can read the video ram and put it out as composite video. The other port will be connected to my CPU so it can read and write video ram. I want 8 bit video in the form of: 332 (RGB) and to let the CPU know it is ok to write to video ram to avoid artifacts maybe with Vsync. is this possible, if so what resolution can I expect?
Comments
What is the minimum resolution you would find acceptable, and what resolution do you really want?
I've not had a good luck at the SRAM but this one seems ok: CY7C130-55PC A little slow but it's in DIP package and that would make it very easy for me, otherwise I'd have to get some place to solder it for me. Obviously this is a little small so I may have to add a bunch of them and select from them when reading and writing.
Welcome to the forum by the way.
I didn't have any 74LS32s or 74HCT00 so I reached for a CPLD (9572). The CP/M project (Grant Searle) fired up ok ;-) (in its M$ basic mode) but only 1 day later the CPLD is sat there taking 250mA on its own :-(
and there are no pins to probe about on (where is that Dremel?)
I now have the previously mentioned OR gate assemblies so more ironing to follow.
Alan
for the display counters and the GPU access, but you need address counters anyway which can have #OE inputs
A trickier proposition is SDRAMs, although they greatly simplify driving a display with burst-mode reads, and they don't
have to be clocked at anything like 100MHz, but you do have to refresh them fast enough. The complexity is in sequencing
the opcodes to the SDRAM but it will drive a whole scanline by itself unattended. See my recent thread in Projects for more.
As to ram options, I thought dual port would be very easy although if single port isn't too difficult then I'll look into that. I'll look into SDRAM as well, is the a space difference as well (more or less space)?
8 bit? 16bit? maybe a hybrid?
Regular Von Neumann or something else?
Just curious.
Lots of folks have that "make a CPU" fantasy. I've had it on and off since the 80's, but a verilog simulation is about as close as I've been.
Why don't you start simple and just use the Propeller for the video memory and signal generation? Then make a more advanced version later.
Haven't gotten further than getting hold of breadboards(there was this thread about $1 breadboards a while ago), 'The TTL Cookbook' and a really, really big logic analyzer. (But that I also wanted for other work, too.)
Of curse, as I'm mad as a hatter, my design will probably be a 1'' thick layer of cabling stuck into a couple of dozen solderless breadboards and you'd have to strain to see the chips.
How long ago was that $1 breadboard thread, sure would be helpful.
also the closest I got to a CPU was a single 74181 I bought a while a go.
There have been some fairly amazing graphic Propeller demos.
Maybe potatohead or one of the other graphics folks can answer it better than me.
First I would urge you to take a careful look at Mark_T's thread at http://forums.parallax.com/showthread.php/150407-Video-graphics-controller-using-Propeller-to-control-SDRAM. He has done some ingenious work to generate video with a propeller and sdram.
If you decide to do something with SRAM asynchronous ram is the easiest to work with.
A 640 x 480 x 8 bit display would require 307200 bytes of memory for the display so the choices are either one 512KB (4Mbit), two 256KB or three 128KB chips.
If you were to drop the resolution to 512 x 384 the memory requirement would drop to 196608 bytes so a 256KB (2Mbit) chip would be all you need.
You would need to generate address bits (18 or 19) to scan the video ram and this could be done with external counters or possibly by using the propeller video generator, PASM code/counters, and propeller pins.
The prop hub ram is only 32KBytes so it can not do 512 x 384 x 8 bit color. That would require 196.608KBytes. It breaks the screen up into blocks (16 x 16 pixels IIRC) and allows you to display blocks of pixels on the screen. It is similar to a text display where you display one of several characters at a specific location on the screen. It displays one of several graphic blocks at each screen location.
A bit mapped display has one memory location for each pixel on the screen. The memory location could be any number of bits from 1 bit (on off) to as many as you want. Typically it would be 8, 16, 24, or 32 bits per pixel for 256, 65,536, 16,777,216 or 4,294,967,296 colors respectively, although 8 bits of the 32 bit pixel is not usually used for color.
If you want to use TTL (or the equivalent CMOS chips) take a look at the 74181 and 74172. They were the chips of choice for the ALU and registers of many early minicomputers. Even if you decide to take another route the 74181 data sheet will provide good information.
BTW, I would suggest using a second propeller and a few latches as the CPU to start with. You could have a 24 bit address and 16 bit data bus to address 16MB of ram, and emulate just about any 16 bit minicomputer ever made. Once you know what you want you can convert to TTL/CMOS/FPGA, or whatever.
http://forums.parallax.com/showthread.php/148473-Dollar-Solderless-Breadboards
It's the small 140 connector breadboards that came at that price, though. But the thread is full of other great buys.
First challenge is bandwidth. For composite NTSC TV video the Propeller will need to fetch from the RAM a line of pixel data every 63.5555usec. (The assumption is only the current line is stored in HUB RAM.) For 640 pixels per line and 8 bits per pixel, that works out to a bit over 10 million bytes per second. However, since the HUB RAM can only be written every 16 cycles that means the max WRBYTE speed is 5 million bytes per second (with an 80MHz clock). So your SRAM to HUB RAM code will need to pull 4 bytes from the SRAM and use WRLONG. Simply getting the pixels into the Propeller is going to be a challenge.
The Propeller's video generator outputs YC (luma + chroma phase) for composite TV, it uses 222 RGB for VGA. While you could try to have an RGB to YC look-up table, I'm not certain there would be enough cycles even if you dedicated a COG to the job. (PASM doesn't have an indexed addressing mode without self-modifying code or slow HUB access.) It would be better to start with having the data in the SRAM in Propeller YC color codes.