A thought about cartridges that save high scores

[+fdr4prez]

With the advent of the carts that can save high scores, such as Match 5, would it be possible to implement a way to save the game progress and go back to that point later when the cart is re-inserted?

 

Or I think the best feature for something like that would be for Motocross where you design your own track and now you'd be able to save the custom track for future games.

 

I played a lot of Motocross back in the day, and if there was only a way to save the track that I designed, then I'd have been an even happier camper. Obviously there would need to be a way of deleting it so you can design another track.

 

If only there was someone outer there able to give Motocross a "Super Pro" upgrade where you can create, edit and save multiple tracks, along with some other improvements would be a great purchase.

 

I wasn't much of a fan of the how the two player mode functions where the leader gets held in suspended animation when the 2nd player falls too far behind, but I don't think a split screen would be very doable due to the low resolution of the system.

 

Well, lookie there, I get side tracked in my own thread....

 

So would being able to save the game state, or being able to save user created content (such as race tracks) be desirable on a cart?

[+intvsteve]

Presently, the JLP boards from LTO support this kind of thing -- so it's already productized! The Lost Caves of Kroz saves your game progress and other data, for example. (Elektronite uses boards produced by LTO.)

 

From what I understand, the JLP cartridge tech provides a general mechanism for the program to save data to some onboard flash. But, what that data means and is used for is completely defined by the program itself.

 

I think that IntyBASIC has recently been updated to support those features of JLP, too. Perhaps some of the gurus there could even build higher-level APIs to provide a framework like what you're proposing -- though in constraint resource systems like these, it may be challenging to get the right mix of easy-to-use and not-wasteful. But it would make using these capabilities more approachable.

 

There may be other hardware with such capabilities in the pipeline as well, but others more familiar with those projects will need to speak up.

[freewheel]

It's all doable, and fairly easy too. I haven't played with it but IntyBASIC has some kind of save support.

 

The LTO Flash! and JLP carts (and possibly others) have flashRAM on them. And (much) more storage than the Intellivision has memory. So in theory, you could save every possible bit of your game state to a cart. The game would have to have code to save all of that, and more importantly load it back later and do something meaningful with it (ie: restore your game, or your custom tracks, or whatever you're thinking of), but that's just a matter of code. And our modern carts have oodles of space for code.

 

The only limitation here is your imagination, really. And programmer time.

[+fdr4prez]

Thanks guys. I was aware from the LTO Flash thread and the interviews from the Intellivisionaries podcasts indicating that flash ram was available, but I've only heard about saving high scores, as in Match 5 that I mentioned, and not necessarily about saving game progress (unless it flew by me).

 

I've not paid much attention to Lost Caves of Kroz, and many recent releases, due to lack of funds lately, so I was not aware that it had game saving functionality.

 

That is good to hear. I think if programmers can take advantage of such features it opens up many possibilities. My programming skills haven't been touched since my high school and college days, some 25 years ago, so I am a bit rusty. I may peruse the IntyBASIC SDK

 

I also think I need to ask my wife to start working, so I can afford to splurge a bit on my collection

[+Lathe26]

Another option would be to use the ECS tape drive port. Just record or play back a WAV file of the data. Super NFL Football allows you save and restore team rosters and customized plays, IIRC.

 

On the upside, you can relive the retro way of how this was done back in the day. Unfortunately, that is its downside, too. Unlike the cart FLASH storage options, recording and playback is complicated by having to get the volume levels right. Also, modern tools make it easier to hack the data (ex: give yourself a high score of 1000000000000).

[+fdr4prez]

Yeah, I heard that recently about the ECS. Back in the day it was not something I would have known to try to do.

 

My ECS didn't get much action back then. I only had Mind Blaster, but didn't play it often. I think I was too young to appreciate it.

[freewheel]

Thanks guys. I was aware from the LTO Flash thread and the interviews from the Intellivisionaries podcasts indicating that flash ram was available, but I've only heard about saving high scores, as in Match 5 that I mentioned, and not necessarily about saving game progress (unless it flew by me).

 

 

From a programming/hardware perspective, it's really the same thing. You're just taking a value (or values) in RAM, and saving them. A score, a custom track, heck an entire game state are just a bunch of variable values in RAM. Because you only get what, 1500(?) bytes of RAM, any modern flash memory is WAY more than you'll ever need for this. So you can literally save the entire game state if you want.

 

A score is trivial to save and then load. A track or a game state can be much more complicated, but the exact same principle holds - at least in terms of the saving. Re-building your "world" or track or whatever, from RAM? You kinda have to write the game to do that. But that's just a matter of planning - and maybe a lot of code to set things up midway through a game. But it's very much doable

 

Think of how early save games like Zelda worked. All they were doing is saving a bunch of variables onto memory on the cart. And re-loading them back so that you had your character's level and inventory and progress already there, after you loaded.

 

And yes, it's amazing to think of what we can do with Intellivision homebrew and this. If I only had enough free time...

 

[Games For Your Intellivision]

Thanks guys. I was aware from the LTO Flash thread and the interviews from the Intellivisionaries podcasts indicating that flash ram was available, but I've only heard about saving high scores, as in Match 5 that I mentioned, and not necessarily about saving game progress (unless it flew by me).

 

I've not paid much attention to Lost Caves of Kroz, and many recent releases, due to lack of funds lately, so I was not aware that it had game saving functionality.

 

That is good to hear. I think if programmers can take advantage of such features it opens up many possibilities. My programming skills haven't been touched since my high school and college days, some 25 years ago, so I am a bit rusty. I may peruse the IntyBASIC SDK

 

I also think I need to ask my wife to start working, so I can afford to splurge a bit on my collection

 

Scott Nudds, the programmer of Boulder Dash for Intellivision, rewrote the flash ram save code for our game engine that allowed him to save game states (pause and save the game in progress). However, we were trying hard to make the deadline for the game's release and nixed the feature.

[intvnut]

BTW... the flash save area on a JLP board varies depending on the size of the game. Take the size of the game in bytes, subtract it from 240K, and you have an idea of how much space is left for saving a game. In all but the most "out-there" cases, it's waaaaaaay more than enough.

 

On the LTO Flash! board, each game can have a "JLP save area" up to 1MB. That's matched pretty well with the 1MB RAM on the board. So, you could even save really big LTO Flash-specific games. If folks end up needing more storage than that, we can always upgrade LTO Flash. This "limitation" is part of the firmware, and the firmware is field upgradable.

 

For all the games currently available for the Intellivision, neither board would break a sweat saving/restoring an entire game's state. The only state that would need to be handled specially is the Intellivoice, as it has hidden state that can't be saved and restored. If you'd have to wait for a clean boundary between spoken phrases.

Edited September 25, 2015 by intvnut

[+5-11under]

BTW... the flash save area on a JLP board varies depending on the size of the game. Take the size of the game in bytes, subtract it from 240K, and you have an idea of how much space is left for saving a game. In all but the most "out-there" cases, it's waaaaaaay more than enough.

 

On the LTO Flash! board, each game can have a "JLP save area" up to 1MB. That's matched pretty well with the 1MB RAM on the board. So, you could even save really big LTO Flash-specific games. If folks end up needing more storage than that, we can always upgrade LTO Flash. This "limitation" is part of the firmware, and the firmware is field upgradable.

 

For all the games currently available for the Intellivision, neither board would break a sweat saving/restoring an entire game's state. The only state that would need to be handled specially is the Intellivoice, as it has hidden state that can't be saved and restored. If you'd have to wait for a clean boundary between spoken phrases.

 

Have you ever had any concerns with using the same area of the chip for both "ROM" and essentially "nonvolatile RAM"?... or is it in a completely different memory map of the chip?

[intvnut]

 

Have you ever had any concerns with using the same area of the chip for both "ROM" and essentially "nonvolatile RAM"?... or is it in a completely different memory map of the chip?

 

Not really concerned—it is somewhat separated. The flash on the JLP boards is erasable in 1.5K byte chunks and programmable in 192 byte chunks, and permits 10,000 E/W cycles. The section of flash used for save-games is away from the area used for the game. The chip itself is designed to allow local erasure and rewriting w/out affecting other sectors.

 

Also, the reference code I provide performs wear leveling, so that you're not constantly erasing/writing the same bit. So even though a given cell only allows 10,000 erase-write cycles, for data that changes relatively often (say, high scores), those writes will be spread out over, say, 16 or 32 locations, with a corresponding multiplier on flash life.

 

The other thing to note: The flash save/restore is a discrete step the game must explicitly invoke. The non-volatile memory isn't memory-mapped; rather, I copy data between actual RAM and flash as a deliberate step. That way, there's no temptation to store volatile, quickly changing data in non-volatile memory, racking up the erase-write cycles. You have to decide what to save, pack it up into a contiguous record in memory, and then call the "copy to flash" API.

 

On LTO Flash, I provide the same interface for save and restore, but it goes through an extra level of indirection under the hood so that I can store it in the filesystem on the external flash alongside the game file. So there, even though the API is the same, the underlying mechanism is actually rather different. :-)

Edited September 25, 2015 by intvnut

[freewheel]

 

Scott Nudds, the programmer of Boulder Dash for Intellivision, rewrote the flash ram save code for our game engine that allowed him to save game states (pause and save the game in progress). However, we were trying hard to make the deadline for the game's release and nixed the feature.

Goddamn, that would have been very cool. BD has always been a hard game for me to complete in a single sitting. Having an ability to "go back" when I screw up is a lifesaver (gotta use emulator save states to do that currently).

[First Spear]

Only 320,000 writes? That sounds like a hard limit. I guess I'll have to buy 3 LTO Flash carts to future-proof my intense game saving.

 

 

 

[snip]

Also, the reference code I provide performs wear leveling, so that you're not constantly erasing/writing the same bit. So even though a given cell only allows 10,000 erase-write cycles, for data that changes relatively often (say, high scores), those writes will be spread out over, say, 16 or 32 locations, with a corresponding multiplier on flash life.

[snip]

 

[+nanochess]

The newest IntyBASIC release v1.2.3 (and soon v1.2.4) have support for the non-volatile memory of JLP cartridges via the FLASH statement.

 

Programmers are only at one step distance of making their games to save the current high-score or a small high-score table

 

This is only the top of the iceberg, big things could be made using all the available space.

[intvnut]

Only 320,000 writes? That sounds like a hard limit. I guess I'll have to buy 3 LTO Flash carts to future-proof my intense game saving.

 

No, no, no. That's on a single JLP board—ie. for standalone games. The original use case was high scores, and I have never seen a game on JLP get anywhere near the wear limit, as games only store a new high score when there's actually a new high score, for example. If you scored 1000 new high scores every day, it'd still last a year. If a particular game needs to update non-volatile memory more often, we can spread the load over more sectors very easily. 320,000 new high scores is a pretty large number. In Space Patrol, it's physically impossible to get more than 262,144 new high scores. (And that's a theoretical upper bound; the real bound is likely less than half that.) It requires ending the game on each new score that's 50 points higher than the previous high score, doing that in order, and doing that on all 8 courses. That just doesn't seem very likely. :-)

 

Even game saves... if you save 1000 times a day, it'll last you a year. Something tells me you don't save that intensely. :-) 8 hours of play, saving every 30 seconds gets you to 960 saves.

 

LTO Flash! has a much, much higher wear count. It uses an external flash chip with 100,000 E/W cycles per sector. Furthermore, LTO Flash! performs automatic wear leveling on a fairly large reserve pool (40 sectors). Therefore, if you have a completely full LTO Flash board, its wear leveling algorithm still guarantees 4,000,000 E/W cycles. Due to how JLP's non-volatile storage maps onto LTO Flash!—ie. using a JLP enabled game on your LTO Flash! unit—you actually get about a 8x increase over that (32,000,000 JLP game saves).

 

LTO Flash! actually transparently wear levels over all of the free sectors. So, if your LTO Flash! is not completely full, then the flash lifetime goes up from there. The stress-test board I left running for literally months of non-stop filesystem testing ended up racking up over 6,000,000 E/W cycles and never dropped a bit.

 

For now, I've put a wear level indicator in LTO Flash!, and the default computation is very conservative. It assumes the media is 100% full, and it assumes only 2.1M E/W cycles are allowed. This leaves well over a factor of 2 margin. Last I checked, with everyone thrashing their boards in the beta test, nobody's dropped below 100% flash life remaining—i.e. nobody's racked up enough wear to get that to click to 99%. And realistically, even when that wear indicator reaches 0%, you probably haven't even used half the device's flash lifetime due to how much margin I've built in.

 

If it turns out that folks really are beating on the flash harder than that, I can easily tune the wear leveling algorithm and stretch the lifetime even further, perhaps at a small decrease in capacity.

Edited September 26, 2015 by intvnut

[First Spear]

 

Alright playa, then I guess I'll buy 4.

 

 

 

No, no, no. That's on a single JLP boardie. for standalone games. The original use case was high scores, and I have never seen a game on JLP get anywhere near the wear limit, as games only store a new high score when there's actually a new high score, for example. If you scored 1000 new high scores every day, it'd still last a year. If a particular game needs to update non-volatile memory more often, we can spread the load over more sectors very easily. 320,000 new high scores is a pretty large number. In Space Patrol, it's physically impossible to get more than 262,144 new high scores. (And that's a theoretical upper bound; the real bound is likely less than half that.) It requires ending the game on each new score that's 50 points higher than the previous high score, doing that in order, and doing that on all 8 courses. That just doesn't seem very likely. :-)

 

Even game saves... if you save 1000 times a day, it'll last you a year. Something tells me you don't save that intensely. :-) 8 hours of play, saving every 30 seconds gets you to 960 saves.

 

LTO Flash! has a much, much higher wear count. It uses an external flash chip with 100,000 E/W cycles per sector. Furthermore, LTO Flash! performs automatic wear leveling on a fairly large reserve pool (40 sectors). Therefore, if you have a completely full LTO Flash board, its wear leveling algorithm still guarantees 4,000,000 E/W cycles. Due to how JLP's non-volatile storage maps onto LTO Flash!ie. using a JLP enabled game on your LTO Flash! unityou actually get about a 8x increase over that (32,000,000 JLP game saves).

 

LTO Flash! actually transparently wear levels over all of the free sectors. So, if your LTO Flash! is not completely full, then the flash lifetime goes up from there. The stress-test board I left running for literally months of non-stop filesystem testing ended up racking up over 6,000,000 E/W cycles and never dropped a bit.

 

For now, I've put a wear level indicator in LTO Flash!, and the default computation is very conservative. It assumes the media is 100% full, and it assumes only 2.1M E/W cycles are allowed. This leaves well over a factor of 2 margin. Last I checked, with everyone thrashing their boards in the beta test, nobody's dropped below 100% flash life remainingi.e. nobody's racked up enough wear to get that to click to 99%. And realistically, even when that wear indicator reaches 0%, you probably haven't even used half the device's flash lifetime due to how much margin I've built in.

 

If it turns out that folks really are beating on the flash harder than that, I can easily tune the wear leveling algorithm and stretch the lifetime even further, perhaps at a small decrease in capacity.

[freewheel]

Hmm. I'll be honest, something just occurred to me that never did before - automatic-ish game saving.

 

As I work towards my eventual goals (in a decade at this rate), I've been thinking of the old-school style of game saving - find a bed. Or typewriter. A savepoint of some sort. Because that's how we used to do it. Partly for technical reasons, partly for gameplay reasons, and partly due to lack of imagination.

 

320,000 write cycles, eh? Let's say you have a game that takes 10 hours to complete (very ambitious for the INTV). If you saved every 30 seconds, that's 1200 saves per run-through. You could play the game a coupla hundred times without fail. And that's just insane to imagine. Of course, saving takes cycles - and potentially "pauses" things; I haven't even begun to experiment to see how realistic real-time saving is. So let's say you save when something "important" happens - you defeat an enemy, or your character stats (score, hit points, whatever) change in some fashion. The kind of thing that naturally pauses the gameplay anyway (victory screen, or music, or whatever). Depending on the game that may only happen every few minutes.

 

Which basically means I can completely do away with the concept of savepoints as a game mechanic. Iiiiiiinteresting. Of course that has to be balanced with the player's choice - sometimes you don't WANT to save, what if you screw up or something, and want to "go back" to your previous save? Whoops, the game "helpfully" saved your progress for you! I *could* see doing something like 10 rolling saves, so you could always roll back a ways. With no RTC I'd have to come up with some ideas on how to identify each save so that the player has some clue what they're loading. But... hmmmmmmm. Me likey.

 

Even with 4 save slots (so your kid sister can have a go without ruining your progress), the possibilities are incredible.

[Games For Your Intellivision]

Goddamn, that would have been very cool. BD has always been a hard game for me to complete in a single sitting. Having an ability to "go back" when I screw up is a lifesaver (gotta use emulator save states to do that currently).

 

Would have been cool, but I highly doubt there will be a Boulder Dash II.

[intvnut]

320,000 write cycles, eh?

 

 

BTW, let's not get hung up on that 320,000 number. On JLP boards, each flash cell has 10,000 E/W cycles. You can "spread the load" however you like, though. If your game actually saves quite regularly, you could spread the load over a larger number of flash rows, to get a larger total number of E/W cycles. Also, if you are just storing small deltas of progress, I can easily add an API that allows finer grain incremental writes w/out triggering erasures as often, to really stretch it. (The LTO Flash! filesystem code already uses a lot of tricks here to keep the erase-count low.)

 

How far you can spread the write load depends on how much data you're saving, and how much flash is left after holding your game.

 

For example, if your game is 140K bytes, you'd have approx 100K bytes of flash remaining for save-game state on the current generation JLP boards. If the actual save state for your game fits in 192 bytes, then you could spread those writes over the full 100K bytes of flash. Sparing the math, that gives you about 5,200,000 "saves". If a save slot takes more than that, then your wear count goes down accordingly. For example, if your save state requires 4 rows (4 * 192 bytes = 768 bytes), then you get 1,300,000 saves in that scenario. This is all assuming you spread the writes out evenly, which is what I recommend.

 

 

Hmm. I'll be honest, something just occurred to me that never did before - automatic-ish game saving.

 

As I work towards my eventual goals (in a decade at this rate), I've been thinking of the old-school style of game saving - find a bed. Or typewriter. A savepoint of some sort. Because that's how we used to do it. Partly for technical reasons, partly for gameplay reasons, and partly due to lack of imagination.

 

320,000 write cycles, eh? Let's say you have a game that takes 10 hours to complete (very ambitious for the INTV). If you saved every 30 seconds, that's 1200 saves per run-through. You could play the game a coupla hundred times without fail. And that's just insane to imagine. Of course, saving takes cycles - and potentially "pauses" things; I haven't even begun to experiment to see how realistic real-time saving is. So let's say you save when something "important" happens - you defeat an enemy, or your character stats (score, hit points, whatever) change in some fashion. The kind of thing that naturally pauses the gameplay anyway (victory screen, or music, or whatever). Depending on the game that may only happen every few minutes.

 

Which basically means I can completely do away with the concept of savepoints as a game mechanic. Iiiiiiinteresting. Of course that has to be balanced with the player's choice - sometimes you don't WANT to save, what if you screw up or something, and want to "go back" to your previous save? Whoops, the game "helpfully" saved your progress for you! I *could* see doing something like 10 rolling saves, so you could always roll back a ways. With no RTC I'd have to come up with some ideas on how to identify each save so that the player has some clue what they're loading. But... hmmmmmmm. Me likey.

 

Even with 4 save slots (so your kid sister can have a go without ruining your progress), the possibilities are incredible.

 

BTW, The Lost Caves of Kroz already has a mechanic somewhat like this. Every time you complete a room, it automagically saves the fact that that room is complete in the currently active save slot.

 

It doesn't save your physical position in the top-level map; rather, you always start in the Crown Room. But given the structure of the game, there's no reason to save exactly where you're at in the top-level map. Each of the rooms is a short walk away from the Crown Room.

 

 

If your game goes further in the story-telling RPG direction (ie. Phantasy Star / Final Fantasy / Dragon Warrior), you probably want to keep an explicit save mechanic. But, you could also add some number of "autosave" slots.