About game sizes

Discuss general Uzebox topics here: features, wish list. nice to have, etc.
Post Reply
Flamore
Posts: 7
Joined: Wed Jan 16, 2019 4:46 pm

About game sizes

Post by Flamore »

So, i took a few looks on the roms. Their sizes, and the flash memory of the ATMEGA644. And from that i have thought
"Does the Flash capacitancy limit the game size?" I'm not sure about that, but if it does. The flash memory will be write locked pretty fast if it gets read written from every once and then. And wouldn't it be better to "bypass" the limits just by having the game to be read about 60 KB per time. Which could increase the rom sizes to maybe megabytes? (Excuse horrific english and nonsense, I'm in a hurry.)
Flam0re wuz h3r3
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: About game sizes

Post by Jubatian »

We did attempt some designs where the Bootloader could be asked to flash further parts of the game to allow for more than 60K as a multi-part game, however it is not encouraged: there are only about 10000 writes the AVRs internal flash can endure. However in the current Bootloader, the feature exists allowing you to ask it for loading a new ROM to transition to a different part.

See this funtion: https://github.com/Uzebox/uzebox/blob/m ... lib.h#L261

It is only available if you have Bootloader 5.x.x on the Uzebox (which has the red-brown interface, contrary to earlier bootloaders, which were mostly blue).
Flamore
Posts: 7
Joined: Wed Jan 16, 2019 4:46 pm

Re: About game sizes

Post by Flamore »

Jubatian wrote: Mon Aug 17, 2020 4:28 pm We did attempt some designs where the Bootloader could be asked to flash further parts of the game to allow for more than 60K as a multi-part game, however it is not encouraged: there are only about 10000 writes the AVRs internal flash can endure. However in the current Bootloader, the feature exists allowing you to ask it for loading a new ROM to transition to a different part.

See this funtion: https://github.com/Uzebox/uzebox/blob/m ... lib.h#L261

It is only available if you have Bootloader 5.x.x on the Uzebox (which has the red-brown interface, contrary to earlier bootloaders, which were mostly blue).
So, basically the uzebox can be used only 10000 times until it won't let you load games? :roll:
About the function though, does it decrease the lifetime of the uzebox?
And also, i don't have an uzebox yet, still looking for resellers in Poland :lol: .
Cheers - Flamore.
Flam0re wuz h3r3
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: About game sizes

Post by D3thAdd3r »

Flamore wrote: Mon Aug 17, 2020 5:12 pm So, basically the uzebox can be used only 10000 times until it won't let you load games?
Well, I think 10,000 is the *minimum* before the flash could start going bad. Also, you can play the same game as much as you want without rewriting; it does not wear out just reading the same data over and over. Changing games is the only time there is a rewrite. You could play Megatris 100,000,000 times in a row just fine if you wanted.
Flamore wrote: Mon Aug 17, 2020 5:12 pm About the function though, does it decrease the lifetime of the uzebox?
Yes, that function writes flash so it causes wear. I don't think anyone has managed to burn out an Uzebox just playing games or even doing development testing. You would have to flash 5 *different* games(requiring a rewrite), every single day, for 5 years to get around 10,000. I say any Uzebox getting that much love, could sit on the shelf burnt out as a badge of honor honestly :ugeek:

Now, when you start using programmatic techniques to flash various parts of memory you really need to be careful of bugs. An RPG might have some amazing graphics by using a separate rom for every screen and doing a flash each time the character moves to another screen. That would not be a realistic technique, and I doubt anyone would run that on hardware for an extended period of time. That said someone could write a "virus" which would destroy a 644 in a matter of seconds. I say just don't worry about any of it and have fun.
User avatar
Jubatian
Posts: 1563
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: About game sizes

Post by Jubatian »

D3thAdd3r wrote: Mon Aug 17, 2020 11:43 pmNow, when you start using programmatic techniques to flash various parts of memory you really need to be careful of bugs. An RPG might have some amazing graphics by using a separate rom for every screen and doing a flash each time the character moves to another screen. That would not be a realistic technique, and I doubt anyone would run that on hardware for an extended period of time. That said someone could write a "virus" which would destroy a 644 in a matter of seconds. I say just don't worry about any of it and have fun.
Fortunately these aren't quote possible! :) (apart from some very elaborate hacking hijacking SPM in the Bootloader area)

The AVR only permits executing the instruction writing the Flash (SPM) from the Bootloader area, so it is up to the Bootloader to enforce security against such threats. The function which the 5.x.x Bootloaders have is quite constrained, and it has a safety delay (5 seconds maybe, don't remember), while it takes over the display to show the normal Bootloader progress bar while it is loading. So when using the function, it will remain clear what is happening, and realized in such a manner that it wouldn't be able to burn out the ATmega even if the game using the feature was broken or attempting to be purposely malicious (at least ~5 seconds between each write).

So really, no worries! :) But still, better stick with the 60K limit ;)
Flamore
Posts: 7
Joined: Wed Jan 16, 2019 4:46 pm

Re: About game sizes

Post by Flamore »

Alright! I just got an idea of writing some sort of bytecode interpreter, kinda like CHIP-8 for the uzebox. Just as a way to execute larger programs from the sd card. Getting to work ASAP. :idea:
Cheers - Flamore.
Flam0re wuz h3r3
Post Reply