Does this make any sense to you hardware guys? :-)
Since the 2600 has no interrupts, and no input buffer, it's hard to do truly
reliable general purpose I/O.
I think you'd be better off building a MIDI interface on the cartridge
itself and maybe having a chip on the cart automatically write to a RAM area
(it can be read-only to the VCS, but read-write to the chip on the
cartridge). That way the RAM area can act as a FIFO buffer and you can
process the MIDI data that accumulates during VBLANK.
You'd have to have a hot address the 2600 can hit to indicate that it's
processing the buffer (so that any new data gets put in a secondary area if
necessary) and another hot address that tells the chip to clear the ram and
copy the secondary buffer data back to the main buffer.
Along the line, the chip in the cartridge could possibly do some
pre-processing of the MIDI data so that it is presented to the 2600 in an
easy-to-digest fashion. For instance, you could pre-quantize the 7-bit MIDI
volume data to the 4-bit 2600 volume setting. You could also interpret
channel/voice data and convert that into direct distortion settings in the
bytestream.
If you wanted to simplify things further, rather than an expensive to design
chip, you could have some kind of MIDI interface software for the PC that
performs the preprocessing in real-time before sending the signal down the
pipe.
While it may be too much data for the 2600 to handle during screentime, but
it shouldn't be possible to send so much data to the 2600 via this buffer
that the VBLANK time would be incapable of processing it completely.
According to my rough calculations, at MIDI speed, assuming that you are
totally maxing out the MIDI bandwith just for the 2600, you'd have 64 bytes
per 60th of a second to process. I don't see how that would ever happen in
the real world, though, when controlling a device that only has 2 sound
channels.
Now that I've opened up a can of worms here---
If you made this interface cartridge generic enough, and made it read-write
(ala Starpath RAM) then you might also be able to make the transfers
bidirectional. Allocate a page of data for writing to the outside world and
a page of data for reading incoming data. This would possibly allow for
multiplayer games as the heavy-lifting of the data transfer would be handled
by the cartridge, so as long as not too much data accumulates in the buffers
to be processed during a single VBLANK, it should be possible to maintain a
full display at the same time as receiving and sending data.
Basically it would work similar to a modem with an onboard UART with
hardware handshaking, but would only work in a NULL-modem capacity and would
not go over the phone lines but hook up to a PC which could then bridge the
data over TCP/IP!
The networking layer on the PCs could be peer-2-peer and handle all the
connection issues for the 2600.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
