[stella] VCS Hard Drive
Subject: [stella] VCS Hard Drive|
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Sat, 18 Jan 2003 21:56:34 -0800
At 10:56 PM 1/18/2003 -0600, you wrote:
I think this would be a great way to implement an RPG type game on the 2600.
You could store lots of room/monster/character/game-state information in the
If we are talking about random access read-only hard drive support for the
2600, I can think of one method that would definitely work--using the
Supercharger or Cuttle Cart.
The Supercharger is ALMOST there except that it requires human intervention
to start the next load.
Supercharger loads can overwrite any number of pages for all 6K of the
cart's RAM, leaving the rest persistent. It's a pretty flexible system
that can be used for modular programs and data that swap in and out.
Multiload games for the Supercharger have been linear to date, but they
COULD be more random-access. On a Cuttle Cart you could do it right now
because it visibly shows you the load number to load. On the Supercharger
you'd be running blind unless the game's own code told you what to load
before jumping to the Supercharger BIOS routine.
What you really want is a way for the 2600 to request its own load.
This should be possible to do by bit-banging on one of the controller
ports, sending signals to a client program on the PC via serial. The PC
would then feed the 2600 the required load.
Now of course, it might also be possible to have a RAM-on-cart solution
that either has its own interface on board or uses one of the controller
ports for both directions. It's just that we haven't seen that yet.
But using the Supercharger it should be possible to write RPGs where
various zones are stored in different loads and file pointers to other
loads exist in the exit points of the zones, and you can move from zone to
zone with complete freedom and the game would automatically load in the
proper data. If each load were around 4K and you used TURBO mode on
makewav then it should be snappy enough to not be that intrusive having to
wait for the loads to happen.
You could then have as many loads as you want as long as the PC knows how
to translate the raw load request into a filename to pull. The
Supercharger format assigns a load number to loads but there is no reason
you can't reuse load numbers. The load numbers were done so that if the
user tries to load the wrong load, it won't wipe out his game. But if the
loading is automated then there is no chance that the PC would send the
wrong file; you would just request it via some 2+byte sequence that would
have a greater maximum number of files.
At that point you could have infinite data capacity to the 2600, albeit not
all instantly accessible.
You could do some cool things with this, by the way. You could have the PC
modify/compile data on the fly, acting sort of like a coprocessor or
client/server sort of thing. The more the PC does besides just serve
static files the more it might seem overkill, though.
It might actually be faster and more direct to write a Supercharger program
that does all I/O across the board via serial on one of the controller
It's just that you'd have more overhead in your program for that, whereas
using the BIOS routines eats no RAM.
But since you'd already be taking the hit writing the code to send data to
the PC requesting the load, it might be better to do both directions in
serial. Don't know what the speed difference would be.
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/