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!
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.
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.
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.
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.)
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:
Code: Select all
00000000 - NOP
00000001 cccccccc - Set foreground color
00000010 cccccccc - Set background color
00000011 pppppppp - Set line drawing pattern (bitmask; 1=fg pen, 0=bg pen)
00000100 xxxxxxxx - Set X coordinate
00000101 yyyyyyyy - Set Y coordinate
00000110 000000mm - Set line pattern draw mode:
mm:
00: Nothing is drawn, ever (both foreground and background considered transparent)
01: '1' bits draw foreground color only; '0' bits are considered transparent
10: '1' bits are considered transparent; '0' bits draw background color only
11: Both '1' and '0' bits draw their respective colors.
00000111 wwwwwwww - Set width
00001000 hhhhhhhh - Set height
0001xxyy nnnnnnnn - Draw up to 'n' pixels. After each pixel update x or y accordingly to the setting of 'xx' and 'yy', as follows. Line pattern and colors are applied.
xx:
00 = no change
01 = x := x -1
10 = x := x + 1
11 = undefined
yy:
00 = no change
01 = y := y - 1
10 = y := y + 1
11 = undefined
0010xxyy - Draw precisely *one* pixel, updating x and y accordingly. Line pattern and colors are applied.
00110000 ...data follows... - Draw literal bitmap at X,Y, with width and height as last set.
00110001 - Read literal bitmap data, starting at X,Y, with width and height as last set.
0100ssss ...data follows... - Draw literal bitmap data into sprite S -- supports up to 16 sprite images.
0101ssss xxxxxxxx yyyyyyyy - Move sprite S to the indicated coordinates.
0110ssss - Turn sprite S on
0111ssss - Turn sprite S off
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.
)
