Experimentation with RAM

[sorucoder]

I know on the wiki it says that scripted cartridges are not intended to read or write memory outside of memory-mapped IO, but through experimenting, it seems to work regardless. My process was to create some variables, copy sprite and tile data from their memory-mapped IO buffers to various places (i.e. beyond the defined memory mapped IO, beyond 96k, and beyond 256k), copy it back, and sync it to the cartridge. I'm personally considering using this technique to have a copy of the clean tiles so that I can modify tiles on the fly. With that said, I have the following questions:

1. Should this be possible in scripted cartridges? The reason I ask is because it does seem to violate one of the mantras of TIC-80 (i.e. being a tool to make tiny retro games). If this is problematic to that ideal, should reading or writing to that memory overwrite the other banks, or even runtime variables?
2. What are the true address and size limitations, if any? I haven't experimented further than 272k, but I would imagine a segmentation fault may occur reading/writing to unreasonable addresses or sizes.

[joshgoebel]

This shouldn't be possible. Unless @nesbox changed things there is ony 96kb of MMIO RAM for scripting runtimes, with only the WASM runtime having access to a full 256kb. That memory is simply not allocated for the other runtimes.

Reading and writing past 96kb (or 256kb) is really a security issue and something we need to fix.

[joshgoebel]

Now I'm already on record as saying I think the full 256kb should be opened up for all runtimes (to allow copying RAM around to do advance things with graphics)... but time will tell...

[joshgoebel]

@sorucoder Can you provide your script here that you were using to access out of bounds RAM?

[joshgoebel]

Closing this issue until a reproducible example can be provided. More than happy to reopen when we have sample code to review/test.