Subject: Re: [stella] 2600 rpg From: Glenn Saunders <krishna@xxxxxxxxxxxx> Date: Sat, 22 Mar 1997 12:10:18 -0800 (PST) |
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.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] 2600 rpg, Erik Mooney | Thread | Re: [stella] 2600 rpg, Nick S Bensema |
Re: [stella] 2600 rpg, Erik Mooney | Date | Re: [stella] Programming for Credit, Chris Pepin |
Month |