Finding freespace beyond on the end of the ROM only works if the value is 0

[Piranhaplant]

Finding freespace like freedata $00 will make asar automatically expand the ROM if there is not enough space currently available, but it does not work if any other value is used with the freespace command (for example freedata $ff)

[p4plus2]

This is an interesting issue since technically this is by design. When Asar allocates the ROM it allocates the full 16MB region and all unused regions are 00s. This happens before even a single line of ASM is parsed, so there isn't a way to control this from the ASM level.

There are two possible solutions here:

1. CLI flag for the uninitialized byte
2. When ROM expansion is handled use the pad byte to reset the memory between the current romlen and future romlen.

Option 1 will in general lead to consistent results, where option 2 allows for different expansion regions to have different padding bytes. Option 2 could lead to unexpected situations where freespace is "lost" due to unexpected padding and other tools having more rigid definitions of what free space is. Option 2 also has a side effect that org based writes will not update anything in between to the pad byte.

memset(const_cast<unsigned char*>(romdata)+romlen, 0x00, (size_t)(16*1024*1024-romlen));

Thats the source of the issue, this is called in openrom.

There isn't really a great work around for this in the meantime.

[Piranhaplant]

A command line option would work well for my use case. It could even use the same value as the default for when the freespace byte isn't specified in the command.

[randomdude999]

added a freespacebyte command, which is also used when expanding the rom.

[Piranhaplant]

Thank you!