On Fri, 21 Mar 1997, Chris Wilkson - MCD wrote:
Re: Banking
For ROM, I guess banking out the entire 4K isn't a big problem, but with
RAM, if you are using it to store constantly updated graphics, it would be
dangerous to bank out the entire 4K at once. That's why the Supercharger
memory management was designed the way it is. Of course, the cool thing
about the SC is that (I believe) it can address 6K at any one time without
banking. If you were to design a more linear style RPG, you'd be able to
do it with Supercharger multiloads, and frankly I don't understand why
there is so much reluctance to use the SC hardware when Dragonstomper has
been enough of a precedent as any that it's up to the task.
Most 8-bit RPGs aren't going to have a heck of a lot of graphics.
Dragonstomper's simple X/Y scrolling iconic display with the text status
screen at the bottom works well enough.
> needed, I can expand RAM and ROM upward with more design effort. But that
> can wait.
Hardware is the easy part, software is the hard part. I think a game of
such huge scope should be left for later when the programmers' skills have
matured more.
> o FLASH "save" space
> o battery backup
> o using FLASH to serve as ROM, RAM, and "save" space
> - affordable, more elegant, but nasty complex!
> - uses more processor cycles for operations
Why not Static RAM for everything? The only problem is you'd only have
room, likely, for only one player at a time.
If not...
If it were to be written as a Supercharger game, why not have the 2600
send out audio signals to encode the data (maybe it can do SC format
audio) and then load it back as a multiload to restore the data. If the
loader and saver routines are memory hogs, you could modularize them and
make loading and/or saving a two-step process where the rest of the game
routines are swapped out for the loader/saver and then reloaded at the
end. This kind of two-way I/O could be very useful in future Supercharger
games.
> I don't think this would be too bad. Simply store the font in ROM once.
> Store any text as ASCII or make up your own code, or whatever. Your display
You could probably go with using every 64-bits (a quarter of a byte) of
every byte to store the necessary ASCII data because all you really are
going to need are A-Z in caps, 0-9, and some special characters like
arrows and stuff. A whole byte would be a terrible waste of memory.
> I have however, thought it would be funny to do a Street Fighter "2600".
> (I think I saw a Street Fighter 2000, or Mortal Kombat 2000, or something)
I'd like to see more platformers. Pitfall isn't exactly a mature
platformer. I happen to love the arcade game Rastan, which has elements
of Pitfall/Jungle hunt as well as the hack n slash factor. I think this
would be doable with SC Multiload (although you'd drop the parallax
scrolling). Another Taito game was already mentioned (Bubble Bobble)
which could also use the multiload feature. Similarly, Jumpman and Lode
Runner games would be a snap.
--
Archives available at http://www.biglist.com/lists/stella/archives/
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
