From my understanding, it's fairly simple in concept. The digital value is converted to analog. In this case, it would be a 4 bit value is used to scale the 0.7V R/G/B signals. So, %0000 = 0V, %1111 ~ 0.7V, %1000 ~ 0.35V. (Not sure of binary notation, so I made up my own where % = binary. )

Anyway, for those following my saga - I *think* I've gotten SRAM to function. See the video2 section for picture evidence.

In the UK,STV5730A £5.50 from Grandata Limited in Wembley.
No MOQ.
Sprow.

greener: for 256 colors you need palette register this is easy to do with 16 colors, as there are cheap cd40xx series ic for that job (dual port 4bit register file, and you need three of them) but for 256 colors you would need 256bytes x3 dual port regiester file which is not avial.. at least for me...
your options here is to use 24 bit rgb signal, limit number of colors to 16 from 4096 possible, or go into grayscale (with 256 shades)
24bit rgb is as simple as what you are using now, you need to add another 2 sram chips

I guess I don't understand. Each pixel has one byte assigned to it - that's 256 values. The values would run through a resistor ladder or through a DAC to generate the appropriate voltage levels.

However, an IC designed specifically for a color palette might be a good thing. Can you give me a specific IC number or a description? I couldn't find anything on Digi-Key.

Thanks for the input!

Although I don't recall where, I did see a separate RAMDAC chip which included a VGA-compatible 256-color palette and on-board DAC in the same chip. I know they're available.



Also, using a fixed-palette solution is equally viable. There are several homebrew computers that use this technique to achieve decent color selection and minimal memory consumption. http://jpb.forth.free.fr/Anglais/encadrement.html is the best example, and certainly the most complete, I can think of.

An example 8-bit fixed palette machine would have 3 bits for red, 3 bits for green, and 2 bits for blue (since blue is the least sensitive color for the human eye). This gives precisely half the entire palette of the Atari ST 520 and 1040 machines (IIRC, later models of STs had 4096 color palettes, but were rarely used). If the games available for the ST were any indication, 512 colors was quite adequate for moderate complexity on-screen graphics, and is more than sufficient for business applications.

I am considering adopting this solution for my own 65816-based homebrew computer efforts.

this is true
commodore 64 has only 16 colors, but this doesn't stop artist from creating (belive me or not) breath taking pictures - they use interlace, and few other techniques but still - this is only example of fixed pallette system

I can't agree more; the Commodore 64 produced an amazing display of colors, but I think that was largely the result of its higher resolutions. Atari 8-bit computers had superior color selections, which although it had somewhat lower resolutions (192x200 IIRC??), I think is worth more. You can often trick the eye into perceiving more resolution than there actually is by good color choices.

atari xl/xe is capable of producing 192x226 with 4 colors, and 384x226 with 2
interlaced modes are able to produce XXXx226 and number of colors is up to 120 of 256 on screen at one time. XXX because X resolution varies from line to line in those modes depending on what colors are used
examples of use such modes are jpeg viewer and TIP viewer (last one for 120 color pictures)
you may want to look at http://atariarea.histeria.pl for more details

FYI - I now have 255x120 video working.

Next step is chip integration. I've asked before, but I'd like to ask again... the most intuitive connection is one where the video solution has some address lines and data lines coming into the controller... writing to various addresses trigger an action. It also seems fairly simple to setup - if I had the pin count to do it!

That means serial - I have 5 spare pins. I think the PIC is a good choice, as it has some built-in support for I2C, SPI, and a UART. At this point, I have a lot of looking around to do... I think a 6551 was suggested and it appears to be a UART. Is 19.2Kbaud fast enough for graphics? I think I saw that I2C is somewhere above 100Kb/s (maybe 400) for max speeds.

The only reason I am somewhat concerned with speed is a recurring fantasy of running games off of my phantom hardware.

Regarding the I2C connection, one solution I thought of was to use a low-end PIC to interface to the address bus and data bus. That interface PIC would then use I2C to pass the commands on to the video PIC.

After that, I start thinking of redesigning so that I can just interface directly with the address bus and data bus.

I also need a few suggestions regarding what the command interface should look like. Supported commands would be setting foreground/background color, setting X/Y start/end point, plot a point, draw a vertical/horizontal line, plot a character at X,Y. Probably general line drawing at some point, drawing a "bitmap" image, maybe downloading small images to be drawn at will. (Fonts would be really cool, but I think that would add too much complexity, unfortunately.)

Thanks again. I think some of these have been discussed, so I'll be reviewing this particular topic. I also just picked up my copy of the Art of Electronics, and some exploratory reading was rather interesting. There is a lot I don't understand, but the projects are pretty cool.

... I really should have stuck with just using LEDs!!

> I think a 6551 was suggested and it appears to be a UART. Is
> 19.2Kbaud fast enough for graphics?

The 6551 can do about 130kbps if you use the 16x external clock input instead of the 1.8432MHz crystal input.

> I think I saw that I2C is somewhere above 100Kb/s (maybe 400) for
> max speeds.

Yes, 400kHz clock is generally the upper speed limit for I2C. The nice thing about I2C is that you can have a lot of devices on a single two-wire bus.

SPI can usually do at least a few MHz, and some SPI parts now can handle speeds in the 25-50MHz range.

The 65c22's serial port's max is one bit for every four phase-2 cycles. You can't use it for I2C, and even SPI would be a stretch; but it's nice for handling a chain of shift register ICs, or talking to another 65c22. I've even used it with an RC filter for a 9-level D/A converter to produce DTMF.

I'll leave the video command suggestions for those who have some video experience.

Garth

I know you're gonna hate me for this greener - but I would look for another PIC with more pins and keep it parallel rather then serial for graphics.

You need to be able to redraw the screen during a refresh period if you want no flicker, or at least a portion of the screen that is moving - at 19.2Kb you can't really do that - I'm not even sure if you could do it at 130Kb. I think it may be time to consider a little multiplexing, share the address lines and use a latch. Get some pins back or go for the PIC with >44 pins =)

at 255x120 (hopefully 320x240 later), that's 30,600 pixels, if each pixel has 8 bits, thats 244,800 bits. To draw the whole screen with 19.2Kb it would take nearly 13 seconds, even at 130Kb it would take like 1.88 seconds to do a complete draw, too slow for most games. even if you only draw small areas where movement occurs, multiple things moving at once with say 8x8 sprites or 16x16 sprites, you'd run out of bandwidth with serial too fast.

JMHO

It's exactly how the Amiga and Atari's video chips worked, too. Lots and lots of registers (at least in the Amiga) were write-only, while others were read-only. E.g., the Agnus and Alice chips in the Amiga didn't seem to bother with the R/W pin at all (or, if it did, very rarely) -- it just triggered all events off of the current address.



This depends on your resolution. Let's suppose you stick with 255x120 for the moment, at 1 byte per pixel. Depending on the style of game, it may be necessary to load the whole screen's framebuffer (e.g., when switching scenes, for example). This will require 30600 bytes to be transferred, not including serial line overhead (which is probably going to be small enough to ignore anyway). At 19.2Kbps, which transfers data at 1.92KBps, it'd take approximately 16 seconds to load the screen. Unless you're dealing with a pure adventure game, that won't cut it, I'm afraid.

An I2C bus would work slightly better. At 100kbps it transfers 12.2KBps -- a substantial improvement. This would fill the screen on a little under 3 seconds. But it's still not quite good enough for video game use. At the 400Kbps rate, the total screen fill time comes to 0.612 seconds -- now we're getting to the point where we can switch playfields fast enough to change scenes. But you're still not fast enough to do scrolling or other such things. But it is at least fast enough to support sprites, which might come in handy, since rendering the sprites is done by the PIC, not the host CPU.

I think if you bit-banged your own synchronous serial bus, you can get substantially faster throughputs. For example, the 6522 VIA's serial port can safely get up to 250kbps throughput (assuming when it's clocked at 1MHz, and accounting for its hardware bug), and consumes only two lines. With a 5MHz clock, you can basically get up to 1.25Mbps throughput. If you can interface with that, you can redraw the whole screen in 0.2 seconds. A massive improvement.

Obviously, updating subrectangles of the screen will consume proportionately less time.



Later on, you mention that supporting fonts would be too hard. Yet you have a "plot character at X,Y" command. To plot a character, you need a character font to do it with. You might as well design for it ahead of time.

Here's the command set I'd personally use if I were building something like this. It's inspired by the JPB homebrew computer's command set and the graphics.library API interface from AmigaOS:



The idea behind the "Draw N pixels" and "Draw 1 pixel" commands is to facilitate, as easily as possible, support for the run-slice line drawing algorithm (the host computes the slices, while the graphics engine draws them). I find that supporting a line mask and separate foreground/background colors can be extremely useful when rotating simple objects on the screen, or even for rendering characters on the screen via the host CPU. Of course, it's also quite useful to draw lines in various styles too, as with a CAD program.

I'm further assuming that sprites are a fixed bitmap size. If not, you can use the X, Y, width, and height registers to basically set their size when loading a new sprite image.

I think you might get the idea. Of course, this command set is not in any way refined or polished -- this is just something I came up with off the top of my head. If I were really doing this, I would put a lot more thought into bit patterns, whether or not I'd want a 16-bit wide line pattern register, etc. But it's food for thought at least.

This is what makes the internet community so cool!

Some lunch-time responses to some of the questions posed:



You're right. However, the PIC chips I have don't have that much RAM. What I've done is compile the font right in with the code, so the font is simply embedded for the time being.

This has sparked a thought... maybe there should be additional RAM reserved for this purpose. That could also accomodate pre-loaded images. I think that would be in my 4th rendition, however... I do need to actually get beyond video - although it has been very interesting!!



No I won't! My next generation design splits responsibilities between two PIC chips - one of which should be able to interface with the bus directly. I had a revelation a couple of weeks ago when I realized that I would probably need another support chip between my 65c02 and the PIC that handles the serial communication... plus I'm not familiar enough with any of the serial protocols to handle bit-banging. As an after-thought, having multiple sources of interrupts on one microcontroller could be confusing as well as mess up timing should that prove to be critical. Hopefully, by separating my interrupt sources (video from CPU interfacing), I don't have this issue anymore.



Now my lack of knowledge is showing... is the 65c22 serial output able to communicate with the PIC UART? (Hopefully this is as stupid a question as I think it is!) I do have a couple of WDC65C22S's in my possession... so this might be a quick solution.



Yeah, right! Looks like a bit more than "off the top of your head". It looks like a good start. Were you envisioning all of this running through a serial connection or through a single memory address? (Depending on the interface.) If possible, would you set aside some special registers that have thier own location? (Maybe current "cursor" X,Y position could be read and written by a fixed memory address while other pieces are fed in via writing to a command register.) I started surfing last night and came across this NES hardware description.



I've never dealt with sprites. Can someone give a quick description of just what a sprite is? I *think* sprites are bitmapped images that are managed by the graphics processor. I also think that they "sit on top of" the background image. If that is true, then I've got a problem. If they're simply pre-loaded graphic images which are written into video RAM, I may actually be able to do this. (If they sit on top of the image, then I need to do something to make the background not get wiped out when a sprite moves over it. The background wouldn't be visible on the monitor, but would need to be saved or preserved so that as the sprite moves away, the background can be restored.)

Thanks!

> plus I'm not familiar enough with any of the serial protocols to handle bit-banging.

They synchronous serial interfaces are very simple, especially since they don't have the timing requirements that a UART function has. I'm particularly thinking of I2C, SPI, and Microwire (which is very similar to SPI but a little simpler without the various modes), plus the dumb 74HCxx shift registers that allow loads and loads of bit expansion on a 6522. Other serial interfaces like SMBus (which is similar to I2C) and Dallas's 1-Wire do have some timing requirements so you can't just interrupt a transmit or receive routine just anywhere if you're bit-banging. I know that few things on a PIC are super quick to pick up partly because their port and bit names are so cryptic; but if you look at the interface info on a data sheet for a Microwire part for example, you'll see very quickly how to bit-bang it.

Bit-banging will always be slower than having hardware that takes care of it, but I wonder how much info you really have to transfer for your video purposes. If you tell the receiving end to draw a line from here to there of this color and width, that's very little info compared to transmitting the entire updated screen again. Similarly if you tell it to move a sprite to such-and-such coordinates, you're only transferring a few bytes. Even re-writing a whole sprite would be very little data compared to re-writing a whole screen.


> is the 65c22 serial output able to communicate with the PIC UART?

It's not very practical but I've done it, in mode 101. The frame length of the 6522's synchronous serial port is always 8 bits. (The exception is the 9th-bit-bug in a couple of the modes in the earliest NMOS 6522's. Rockwell had the bug in the versions before the -31 ending, and Synertek fixed theirs in the early 80's. None of the newer ones have this bug.) The last bit's state is left on the data line until the next byte begins. Since a frame is always 8 bits and the UART normally needs a start bit and stop bit (who uses parity?), you're down to six bits of data unless you put two frames back-to-back to get additional bits and pad the end with idle "marking" bits after the stop bit. The shorter frames are more forgiving of small speed inaccuracies though. Note that when the 6522's SR is shifting out under control of T2 in this mode, only the low byte of the T2 latch is used. Also T2 is not really "one-shot" in this mode like the book says-- IOW, you don't have to keep re-writing it after every bit (or even every byte). Just write the data byte into the SR and T2 will do its job, clocking out 8 bits each time and then stopping until the next byte is ready to go.

Maybe Samuel or someone can correct me if I'm wrong, but I think the restoration of the background when the sprite is moved is part of it (otherwise it wouldn't be much good).

The WDC 65134 and 65265 microcontrollers have one and four UARTs built in, respectively.

I actually don't have one. I'm borrowing a friends multimeter - and he needs it back.

I've come across a TPI 440 for $250 at Kiesub Electronics. It's a multimeter plus a digital oscilloscope. For a hobbyist, it seems pretty good.

I also figure you guys can correct me if this is a bad idea - or if I should hunt for a used oscilloscope... or if you have one you could mail me!!