Very nice!

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 

I very much think that the Uno should reject binaries that cannot be fully relocated. To me, this is a matter of validation --- it is much better to have a deterministic error on load instead of memory corruption at runtime.

Quote from: Bomberman94 on 21 Aug 2024, 05:28 PMThe last files (elite_ICC1 ... 3) don't run on my light sixer via PlusCart - only black screen.

That's because of the undefined symbol.

There is an undefined symbol in your ELF binary, _Z9initPlaneb. This is mangled for "initPlane(bool)".

R_ARM_REL32 is now implemented in Stella.

Quote from: JetSetIlly on 11 Aug 2024, 04:27 PMIt looks to me like the Stella ELF parser is just ignoring any relocation type it doesn't know about and letting the original value through.

Ouch, you're right. It was late and I didn't check the code --- I just tested the binary (and mixed it up in my head with R_ARM_TARGET1). Indeed, this is a bug, it should throw, and it does throw now.

Adding support for REL32 is trivial enough, but isn't very useful as long as the cartridge driver does not support it. However, as gcc seems to emit it as soon as a division by zero may be possible this makes a lot of sense to me. I'll ping Zack on the Stella ELF github issue.

Stella already supports R_ARM_REL32, and it the binary works fine there.

R_ARM_PREL31 is in the section .ARM.exidx which is not used anywhere. According to the wisdom of the web this section contains metadata which is used when unwinding the stack, i.e. during exception handling. I am not sure what to do with it (it is not PROGBITS, but a special section type), but it is not referenced anywhere in the binary, so there's no reason to solve that riddle right now 😏

If you send me the binary using FPRINT_DIV I can likely tell you what's wrong with it.

There still is a bit of cleanup to do, but it is working on my "ELF" Stella branch now.

@Andrew, it seems that you are dereferencing an array that points to zero somewhere (reading 8bit elements from there). That's where the vector table dwells on a real Cortex. I've added a temporary hack to stub those as zero (which probably should become a dev vs. player setting like other "strictness" settings), but you might want to to fix this

You have done an amazing job on Gopher2600, and it very much deservers the tag 1.0. I understand very well the amount of focus and energy required to develop something like this, and finding the right point to move back a few steps before burning out on it is hard and takes courage as well. Hats off to what you have achieved, and I'm confident that you'll come back to Gopher eventually!

Quote from: Thomas Jentzsch on 14 Jul 2024, 09:13 PM

Quote from: DirtyHairy on 14 Jul 2024, 06:35 PM

Quote from: Thomas Jentzsch on 14 Jul 2024, 06:19 AMMost likely impossible.

Remember this scheme can do bus stuffing, so you can do one write every 3 cycles. Also, the kernel is generated in C on the fly, so you don't need any branches or logic on the 6507 --- your kernel can be nothing but 25 TIA writes and a NOP 😛 In theory, anything is possible as long as it fits those constraints.

I thought it would be 5 cycles per store, no?

No, ELF can also do bus stuffing, so the 6507 gets a stream of "STA ZP", and the cartridge overrides the bus on write -- 3 cycles per stuff. On start, the cartridge briefly displays a test image to check which bits can be stuffed high, and which bits can be stuffed low, and this is used to load A and drive the bus correctly.

Quote from: Thomas Jentzsch on 14 Jul 2024, 06:19 AMMost likely impossible.

Remember this scheme can do bus stuffing, so you can do one write every 3 cycles. Also, the kernel is generated in C on the fly, so you don't need any branches or logic on the 6507 --- your kernel can be nothing but 25 TIA writes and a NOP 😛 In theory, anything is possible as long as it fits those constraints.

BTW, I agree with Thomas, this is very impressive, even considering the added firepower of the ARM. One suggestion: what about artificially limiting the high resolution bitmap from the top and bottom, too? This would turn it into a sharp area around the crosshair and might look more natural, like central vs. peripheral vision.