Ship Viewer (BINARY!)

[JetSetIlly]

TY both for the report. Unusual I didn't notice this via Gopher. I will investigate that later. Part of working with bleeding edge tools/systems. Meanwhile, here are fixed files that hopefully work!

I've made a quick change so that you are notified when undefined symbols have been resolved with the handler function. That gives you the freedom to develop the ROM but it also gives you the awareness that the ROM won't load on the Uno/PlusCart without corrections to the build process.

When/if I go back to Gopher2600 development properly I'll gussy the error message with more information and maybe add some options around strictness.

The changes are in the "maintenance_work" branch.

[DirtyHairy]

Stella has a developer option "Strict ARM emulation". Checking this option will validate correct linkeage, trap illegal memory accesses and enforce write protection for .text and .rodata.

Getting a useful error message from the cartridge loader would be nice, but imo undefined relocations really are a trivial coding error that should be flagged by the emulator during development and fixed by the developer. After all, if you were building a fully linked ELF executable then the linker would scream at you 

[JetSetIlly]

Stella has a developer option "Strict ARM emulation". Checking this option will validate correct linkeage, trap illegal memory accesses and enforce write protection for .text and .rodata.

I've been thinking about this over night and I'm going to change the behaviour of Gopher2600: If the developer mode is enabled (automatic in most cases) then the warning will show and you have the choice to continue. If the developer mode is not enabled then the linking will fail as it does on the hardware.

Getting a useful error message from the cartridge loader would be nice, but imo undefined relocations really are a trivial coding error that should be flagged by the emulator during development and fixed by the developer. After all, if you were building a fully linked ELF executable then the linker would scream at you 

Sure, but these are symbols in the SHN_UNDEF section and there's nothing wrong with replacing references to those symbols with a debugging/diagnostic handler.

In this case, it might be useful for the developer to know when the symbol is called and the state of the program at that time. Failing on load time doesn't tell the developer that.

As it is, Gopher2600 will run the program until the symbol is referenced. At that point the emulation switches to the debugger and the state of the program is shown.

In the case of a non-development context I agree that it is more useful to copy the behaviour of the hardware and simply fail to load (with a log message) and I will change that specific behaviour this weekend.