Recently a user asked for support after running into this error, in the middle of compiling the music module:
Traceback (most recent call last):
File "coilsnake\ui\gui.py", line 304, in _do_compile_help
File "coilsnake\ui\common.py", line 162, in compile_project
File "coilsnake\modules\eb\MusicModule.py", line 277, in write_to_rom
File "coilsnake\model\common\blocks.py", line 297, in allocate
coilsnake.exceptions.common.exceptions.NotEnoughUnallocatedSpaceError: NotEnoughUnallocatedSpaceError: Not enough free space left
They had added a very large sample to pack 00, pushing the total size of the pack beyond 64 KiB. EarthBound's code doesn't have good support for data crossing banks, so CoilSnake considers there to be nowhere in the ROM where a music pack that big could be stored, and simply displays a "no free space" error, assuming there could have been a possible location but it was used up.
This error message could be better. The size limit being breached could be checked in the MusicModule when the pack is being read from the filesystem:
|
# Size = (4 header bytes + length) for each block + 2 bytes for 00 00 at the end |
|
total_size = sum((4 + plen for _, plen, _ in self.parts)) + 2 |
|
ret_block = Block(total_size) |
Or, more fundamentally, a (SNES-specific...) upper limit on allocation size could be added to AllocatableBlock.allocate:
|
if size <= 0: |
|
raise InvalidArgumentError("Cannot allocate a range of size[%d]" % size) |
It might be useful to do either one or both of these. The music pack thing provides an opportunity to catch the problem faster, without reading every single pack's samples off the user's hard drive and resolving the addresses of all the sequence data, but the AllocatableBlock part may be theoretically useful as we start making more tables expandable.
Recently a user asked for support after running into this error, in the middle of compiling the music module:
They had added a very large sample to pack 00, pushing the total size of the pack beyond 64 KiB. EarthBound's code doesn't have good support for data crossing banks, so CoilSnake considers there to be nowhere in the ROM where a music pack that big could be stored, and simply displays a "no free space" error, assuming there could have been a possible location but it was used up.
This error message could be better. The size limit being breached could be checked in the MusicModule when the pack is being read from the filesystem:
CoilSnake/coilsnake/model/eb/musicpack.py
Lines 240 to 242 in e12aeae
Or, more fundamentally, a (SNES-specific...) upper limit on allocation size could be added to
AllocatableBlock.allocate:CoilSnake/coilsnake/model/common/blocks.py
Lines 280 to 281 in e12aeae
It might be useful to do either one or both of these. The music pack thing provides an opportunity to catch the problem faster, without reading every single pack's samples off the user's hard drive and resolving the addresses of all the sequence data, but the AllocatableBlock part may be theoretically useful as we start making more tables expandable.