greener wrote:
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.
No. The 6522's serial port is a high-speed (capable) serial port that is synchronous. The UART is an
asynchronous serial port.
The 6522's serial port consists of DATA and CLOCK. Since there is only one data pin that is used for input and for output, only half-duplex communications can occur. There is no need for a start or stop bit, as the CLOCK provides explicit clocking for the data. This is why it's a synchronous serial port.
The UART, on the other hand, is asynchronous. It has two data lines: one for transmit, and one for receive. Thus, it can transmit and receive at the same time. The downfall is that it requires a start and stop bit for proper synchronization, so that the other device(s) know when to start and stop reading the serial data. Also, since no clock is available (hence the term "asynchronous"), proper bit timing is
assumed by both parties.
This is why it's perfectly possible to hook up a 2400 bps modem to a 4800 bps serial port (and you'll get garbage on the screen as a result, because of the timing differences). Had the serial port been synchronous, it wouldn't have mattered.
Quote:
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.)
It really doesn't matter. Serial is just slower than a parallel interface, usually by a factor of 10 or so.
Quote:
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.)
Depends on whether there would be any significant benefit to it. If the same PIC is going to be decoding the separate addresses as a command for some things, and the contents of a "command register" for other things, that seems pretty wasteful to me. But, it depends on the precise timing requirements you need on the host processors, the graphics engine processor (which is the PIC in thiscase), etc.
Frankly, if I could, I'd map everything into RAM somehow. Bank switching may be necessary. For example, a technique that is substantially faster than the serial port idea is to treat the video device's frame buffer AND register set as a separate address space, which the 6502 has a, say, 256 byte window to. Let's assume that $D000-$D0FF is the window, and $D100 is a register which controls the visible window. This gives up to 64KB of "video I/O memory." (256 bytes immediately available to the CPU times 256 combinations in $D100 = 65536 total bytes.)
So, we can say that pages 0 through 127 map to video memory, pages 128 through 254 are unused, and 255 is the video controller's register set. This can give you 256 bytes of register space to play with.
Again, this is off-the-cuff, hand-waving design here.
Quote:
I've never dealt with sprites. Can someone give a quick description of just what a sprite is?
A sprite is a small bitmapped image which can be displayed
anywhere on the screen. It usually has a priority bit controlling whether it appears in front of, or behind, the playfield graphics. More sophisticated implementations even have hardware collision detection, to enable the host processor to know when a sprite collides with another sprite, or with some playfield data.
Quote:
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.)
All video hardware which does not support sprites must deal with this. For example, on the PC architecture, it is actually vastly faster to draw the entire screen in normal RAM first, making sure to draw the playfield first, then overlaying any sprite information,
then copy the whole screen into video RAM.
The Atari 7800 and the Amiga was a turning point in most game machine designs. Though the mechanism differed between these systems, it was recognized that layering graphics from the "bottom up" this way was actually superior, AND it supported variable-sized objects on the screen (as you can imagine, most hardware sprite implementations have limited bitmap sizes and color depths). The Amiga had it's blitter, which was used to overlay graphics at the framebuffer level, while the 7800 did it on a scan-line by scan-line basis using a sophisticated display list technology.
I love the 7800's approach to it, as it supported as many sprites as video memory bandwidth allowed, and didn't require any CPU intervention (except to build and manipulate the display lists). Something like that could actually be used to implement a windowing environment virtually entirely in hardware, where software allocated its own bitmap space in RAM, and the video chip did "scatter-gather DMA" to build the image, one line at a time. And it offered a totally seamless mixture of true character mode display and graphics. Good Lord, Atari should have pushed the 7800 harder, and definitely should have kept that concept for their Atari STs.
It was truely quite a beautiful piece of digital engineering artwork.