Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High Score Save Interface #55

Closed
technobly opened this issue Apr 21, 2020 · 6 comments
Closed

High Score Save Interface #55

technobly opened this issue Apr 21, 2020 · 6 comments
Labels
feature New feature request
Milestone

Comments

@technobly
Copy link
Owner

We'd like to have a way to save high scores for each game, in an easy to maintain sort of way. There are hooks for high score RAM location in the Vectrex BIOS that we can look at to see what the current high score is.

One way to attack this is to patch each game with the high score manager code, such that when the high score gets updated, the manager runs instead and allows for more custom things to be done. This is kind of tedious to maintain though, and is anyone really going to trust high scores from an Open Source Vectrex Multicart? :D haha...

So how about we make this simpler and just give the owner of the cart a nice simple way to store the High Scores like this:

  • Enable the High Score feature in the Options menu
  • Play whatever game you want
  • Assuming the high score has updated, press reset quickly (long reset returns to VEXTREME menu)
  • VEXTREME swaps the game with the High Score save interface, and associates your score with the game in a SAVES.txt file. Honor system here people!!
  • There should also be a way to view High Scores for all games, within the interface... which could also be pulled up from the Options menu.
@technobly technobly added the feature New feature request label Apr 21, 2020
@gtoal
Copy link

gtoal commented May 4, 2020

There are two ways to do this: 1) put a lot of work into finding where the high scores are held in each game; or 2) save the entire RAM and registers.. the latter would allow you to resume the game exactly where you left off. Since the registers are not visible to the ARM in the cartridge, this would have to be done by simulating an interrupt and executing some code on the 6809 supplied by the vextreme. Preferably in some spare address space and not the 48K supported by the cartridge (we do support 48K, yes, and not just 32K?) All the code has to do is push any remaining registers, then transfer all ram to the cartridge via a RPC. That ram dump would then be associated with that image, and restored when the image was loaded. A bit of complicated shuffling would be necessary but it could be done. And only has to be done once, rather than manually for every game.

@technobly
Copy link
Owner Author

Hi @gtoal thanks for the ideas! Did you see that @TylerBrymer has already implemented the first working version of this high score feature here #56 ? It only saves known High Score BIOS location scores, but works automatically.

We have been discussing a Game Genie sort of feature that you describe there with the save/restore state. That would definitely be interesting for a lot of reasons :D

VEXTREME supports up to 64KB with PB6 bank switching, and will eventually support 128KB bankswitching with /IRQ. See this feature request #25 Is there a weird 48KB middle ground support I don't know about?

@gtoal
Copy link

gtoal commented May 4, 2020

Yes, there is nothing at all magic about 32K The gap in the address space for eprom is 48K and I publicised this a couple of years ago, encouraging emulator writers to support it. I can give you a 48K rom to test with; also Malban's new game (with 4 banks of rom) are 4 banks of 48K I believe. Bloxorz may also be using 48K roms.

@technobly
Copy link
Owner Author

technobly commented May 4, 2020 via email

@gtoal
Copy link

gtoal commented May 5, 2020

Well, for a hardware solution, you have to properly decode the top bits of the address; for an emulator - just make sure the array is large enough. I posted a drawing when I wired up a cart once but can't immediately find it, probably quicker to re-engineer it from first principles.

@gtoal
Copy link

gtoal commented May 5, 2020

PS There's actually 50K available but it might be better to keep that odd 2K spare for virtual peripherals or a DMA area or something.

technobly added a commit that referenced this issue Jun 11, 2020
@technobly technobly added this to the v0.3 milestone Jun 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants