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.)
About game sizes
Re: About game sizes
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).
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).
Re: About game sizes
So, basically the uzebox can be used only 10000 times until it won't let you load games?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).
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 .
Cheers - Flamore.
Flam0re wuz h3r3
Re: About game sizes
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.
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
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.
Re: About game sizes
Fortunately these aren't quote possible! (apart from some very elaborate hacking hijacking SPM in the Bootloader area)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.
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
Re: About game sizes
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.
Cheers - Flamore.
Cheers - Flamore.
Flam0re wuz h3r3