Menus For Old Games? (Game Matrix Replacement)

[Tempest]

I'm not much of a programmer so I don't know if this is even possible, but one of the things that annoys me about older 2600 games is that you need the manual handy so you can check the Game Selection Matrix to see what each variation does. Towards the end of the 2600's life they started adding real menus to the title screen of each game, making selecting various options a lot easier. My question is, is it possible to graft such a title screen and menu onto older games to help select options? I know you can't put something like that into the games original kernel since there's not going to be any room, but could you make the menu a separate program that once all the options are selected starts the original game's kernel but automatically advances to the correct game variation?

 

For example, take something like Breakout. There are three options: Steerable, Catch, and Invisible. Could you make a menu that said:

 

Game Type: Breakout/Timed/Breakthru

Steerable: Yes/No

Catch: Yes/No

Invisible: Yes/No

 

Then say the person selected Game Type: Timed, Steerable: Yes, Catch: No, Invisible: No. Could you then start Breakout but automatically advance to variation number 6 which is the Timed Breakout game with a Steerable ball? This would make many of the older games much more playable for me since I never have the manual around when I need it. Just and idea, and like I said I have no idea how feasible something like this is.

[+Karl G]

Yes, this is certainly doable. In most cases, you would probably need to expand the ROM size to accommodate a title screen with these options, though.

 

Edit: I imaging that in most cases, such a project would probably become a full-fledged hack. It's hard to imagine digging into the guts of such a game, expanding the ROM size and adding a title screen without wanting to further tinker and add more options.

[Tempest]

Yes, this is certainly doable. In most cases, you would probably need to expand the ROM size to accommodate a title screen with these options, though.

 

Edit: I imaging that in most cases, such a project would probably become a full-fledged hack. It's hard to imagine digging into the guts of such a game, expanding the ROM size and adding a title screen without wanting to further tinker and add more options.

 

I was wondering if there could be a generic menu program that could call the other game when you're done and pass in the variable containing the variation number when it's done (sort of like a wrapper). That way you wouldn't have to tinker with the game's code, just set a variable in it. Like I said, I'm not really a programmer so I don't know how doable that would be.

[+GoldLeader]

It seems to me that this would be a great idea for a future Flashback release, though I doubt they'd go to the effort...

[NoLand]

 

I was wondering if there could be a generic menu program that could call the other game when you're done and pass in the variable containing the variation number when it's done (sort of like a wrapper). That way you wouldn't have to tinker with the game's code, just set a variable in it. Like I said, I'm not really a programmer so I don't know how doable that would be.

 

 

This would work as a helper to adjust static options, like by the BW and difficulty switches, but not for select, where the game has to keep track of the state as the users is cycling through options. (There is no API for options, programs are just checking the hardware to determine the state of the switches. E.g., the game starts with option 0 for select and then checks the state of the select switch every frame and increments an internal count, if the switch is active.)

[Tempest]

 

 

This would work as a helper to adjust static options, like by the BW and difficulty switches, but not for select, where the game has to keep track of the state as the users is cycling through options. (There is no API for options, programs are just checking the hardware to determine the state of the switches. E.g., the game starts with option 0 for select and then checks the state of the select switch every frame and increments an internal count, if the switch is active.)

But couldn't the menu program pass in a value for the variable that stores the select switch counter? I assume there's some variable that stores the current variation number.

[+SpiceWare]

usually there's a single byte that's used to hold the game variation, I talk about that in step 9 of my Collect Tutorial. That byte might also be used for other things, such as keeping track of whether or not the game or color cycling is active.

Process would be:

• expanding ROM size to make room for menu. Simple for older 2K games, anything larger will add or expand bankswitching.
• finding RAM used to hold game variation
• determining which RAM can be reused for the menu routine.
• add a menu tailored for this game
• cartridge init should now jump to menu
• starting a game will require a new init routine to reset RAM values that were reused by the menu.
• revise game-over logic to jump to menu

One thing to consider is how to show the score of the last game on the menu screen - the gamer will want to see that.

[Tempest]

I was just thinking about game variations, I never even thought about difficulty switches or high scores.

 

Like I said, I'm not a programmer and I know how even the simplest idea can be a nightmare to implement. But if someone wanted to look into building a nice menu like you did with MM (actually that was sort of inspiration for this idea) that could be easily modified to work with other early Atari games I'd be a very happy gamer. Of course I don't know how hard this sort of idea would be to implement with larger more complex games. Heck, I didn't even know if this was possible at all.

[+SpiceWare]

I don't think it'd be difficult, just time consuming. Menu wouldn't be that reusable either, options are quite different between games. Parts of the menu could be reusable, such as Yes/No options.

Wasn't worried about high score, that imposes additional RAM requirements which may not be feasible. Main concern is people would not be happy if the menu was shown as soon as their game ended and they had no idea what their final score was.

 

That said, I'll take a look at what would be involved to add a menu to Breakout after I finish Kaboom Deluxe!

[Tempest]

Menu wouldn't be that reusable either, options are quite different between games. Parts of the menu could be reusable, such as Yes/No options.

 

I was just hoping the main menu code could somewhat be reused for each game so that it wouldn't have to be coded from scratch each time. The options and number of menu items obviously varies greatly between games.

[+SpiceWare]

For example, take something like Breakout. There are three options: Steerable, Catch, and Invisible. Could you make a menu that said:

 

Game Type: Breakout/Timed/Breakthru

Steerable: Yes/No

Catch: Yes/No

Invisible: Yes/No

In reviewing the manual Steerable/Catch/Invisible are mutually exclusive. There's also an option for number of players, so the menu would be something like:

 

Game Type: Breakout/Timed/Breakthru

Option: None/Steerable/Catch/Invisible

Players: 1/2/3/4

 

 

But if someone wanted to look into building a nice menu like you did with MM (actually that was sort of inspiration for this idea) that could be easily modified to work with other early Atari games I'd be a very happy gamer.

MM's menu took 6K of space. Of course it has a very elaborate font, and lots of options that required additional logic to scroll the menu.

 

I was just hoping the main menu code could somewhat be reused for each game so that it wouldn't have to be coded from scratch each time. The options and number of menu items obviously varies greatly between games.

somewhat reused would be right.

[Tempest]

In reviewing the manual Steerable/Catch/Invisible are mutually exclusive. There's also an option for number of players, so the menu would be something like:

 

Game Type: Breakout/Timed/Breakthru

Option: None/Steerable/Catch/Invisible

Players: 1/2/3/4

 

Ah I wasn't even thinking about invalid combinations. Of course you an only have so much text on one line so maybe the Yes/No would still work but not allow invalid combos? Or maybe you could allow the player to cycle through game variations and update the options to reflect what each variation allows? That would be a bit clumsy though I think.

 

I wonder which game would have the largest number of combinations (ie. the worst case scenario)?

[SoundGammon]

Imagic had a menu in their store display system that listed various companies to able to pick a game.

 

Maybe it could be adapted for the UNO multi-cart.

 

Each different company could have an extension like .img for Imagic games, .ata for Atari games, .act for Activision and so forth.

[NoLand]

But couldn't the menu program pass in a value for the variable that stores the select switch counter? I assume there's some variable that stores the current variation number.

 

First, these really are just switches with just a bit of conventional meaning associated to them by the markings on the console. The program may "ask" the TIA chip for the state of the switches (as stored in one of the registers) and act to its liking, even the reset switch isn't hardwired in any way. (Nothing but convention hinders you from [mis]using the reset switch, say, as the fire button in your game.) And no, there's no way to preset the TIA register used for this, since it's read-only.

 

A game starts from a fixed address in the cartridge ROM, which will direct the game to its initialization routine. There, it will probably wipe the little RAM, there is, in order to start from a known state (so we already lost any information that might be in there). Then, it probably proceeds to the title screen, where it may read the switch register and adjust the value of a few RAM addresses based on the results. This is probably, where the select switch will be read with the game cycling through its options accordingly. Some switches will be even checked every frame during the game, like the reset switch or the difficulty switches (depending on the game). – So, each program will handle this differently on an individual basis and it will initialize the RAM on startup or just write directly to RAM to take note of the current state of a console switch.

 

Edit: The register for the switch states is, of course, in the RIOT chip (PLA).

Edited May 9, 2019 by NoLand

[Tempest]

 

First, these really are just switches with just a bit of conventional meaning associated to them by the markings on the console. The program may "ask" the TIA chip for the state of the switches (as stored in one of the registers) and act to its liking, even the reset switch isn't hardwired in any way. (Nothing but convention hinders you from [mis]using the reset switch, say, as the fire button in your game.) And no, there's no way to preset the TIA register used for this, since it's read-only.

 

A game starts from a fixed address in the cartridge ROM, which will direct the game to its initialization routine. There, it will probably wipe the little RAM, there is, in order to start from a known state (so we already lost any information that might be in there). Then, it probably proceeds to the title screen, where it may read the switch register and adjust the value of a few RAM addresses based on the results. This is probably, where the select switch will be read with the game cycling through its options accordingly. Some switches will be even checked every frame during the game, like the reset switch or the difficulty switches (depending on the game). – So, each program will handle this differently on an individual basis and it will initialize the RAM on startup or just write directly to RAM to take note of the current state of a console switch.

 

Sounds like the games themselves may need to be tweaked a bit to make something like this work. Hopefully SpiceWare can come up with something that works at least for the early 2K and 4K games.

[SoundGammon]

Here's the 2 Imagic Menus:

Imagic Selector.bin

Imagic Selector V2.bin

[Omegamatrix]

I'm not much of a programmer so I don't know if this is even possible, but one of the things that annoys me about older 2600 games is that you need the manual handy so you can check the Game Selection Matrix to see what each variation does. Towards the end of the 2600's life they started adding real menus to the title screen of each game, making selecting various options a lot easier. My question is, is it possible to graft such a title screen and menu onto older games to help select options? I know you can't put something like that into the games original kernel since there's not going to be any room, but could you make the menu a separate program that once all the options are selected starts the original game's kernel but automatically advances to the correct game variation?

 

For example, take something like Breakout. There are three options: Steerable, Catch, and Invisible. Could you make a menu that said:

 

Game Type: Breakout/Timed/Breakthru

Steerable: Yes/No

Catch: Yes/No

Invisible: Yes/No

 

Then say the person selected Game Type: Timed, Steerable: Yes, Catch: No, Invisible: No. Could you then start Breakout but automatically advance to variation number 6 which is the Timed Breakout game with a Steerable ball? This would make many of the older games much more playable for me since I never have the manual around when I need it. Just and idea, and like I said I have no idea how feasible something like this is.

This is a superb idea to breathe new life into these games. Truthfully, I never have a manual around, and I usually just play the default version.

 

Converting games that have a lot of variations is a huge improvement. Maybe I will look into Video Olympics because there are 50 variations. I'm pretty sure I have not tried a lot of them.

 

Paddle games are more involved to make a menu screen, but certainly workable. Standard joystick games though would be easier to bang out.

[SoundGammon]

Medieval Mayhem has a menu that uses a paddle!

[Omegamatrix]

Tomorrow. ?