Hacking EZ-FLASH OMEGA white-screen PSRAM ROM

[Xilefian]

I have attached a custom ROM file (made by myself) that displays a white screen on the EZ Flash Omega flash-cart when clean booting via PSRAM.

The ROM works perfectly fine when booting from NOR flash, as well as via multi-boot and multiple GBA emulators on PC.

All other ROMs work perfectly fine on my devices, as do all my SD cards. This is the first instance where I've found a ROM that does not work on EZ Flash PSRAM.

The ROM is a mode 1 image demo, the EZ Flash Omega seems to dislike the 128 byte look-up-table being used for Sine calculations in this demo.

I'll have to test this on my EZ4 when I have a chance to, but the issue is very real on Omega.
If other Omega owners can confirm this with the ROM I would be most grateful.

EDIT: Forgot to say, this issue happens on kernel versions 5, 6 and 7 and I am using an original Gameboy Advance AGB001 console. I will try down-grading the kernel further to see if it occurs on older versions.

EDIT2: PSRAM test reports "OK" for both S71 and S98 chips.

 

[FAST6191]

Curious. I will have to have a look at this when I get back.

Is the lookup particularly latency sensitive? That is the main difference I might expect between NOR and PSRAM. That or maybe the NOR defaults to some kind of clean boot where the PSRAM mode does not/has a conflict with a patch setting, same thing for soft reset vs hard reset (needing to make a header and such). If it was the NOR on an original GBA I would ask about the batteries but presumably not that.

Anyway worked on my miniSD EZ4 on a DS lite.

Edit.
White screen regardless of normal boot options on Omega on DS lite. Worked on the NOR. I am using an older kernel at this point.

 

[Xilefian]

Is the lookup particularly latency sensitive? That is the main difference I might expect between NOR and PSRAM. That or maybe the NOR defaults to some kind of clean boot where the PSRAM mode does not/has a conflict with a patch setting, same thing for soft reset vs hard reset (needing to make a header and such).

It's not latency sensitive - it's a simple 16bit read from ROM. When I have a chance I'll try configuring the wait states a bit and see if there's any change.

I'm not even sure if the execution even gets as far as touching the LUT, but the issue happens when the LUT is being used. There's a few things I can try to attempt to narrow down the problem (access LUT delayed, see if touching it is the problem). Thing is, I don't even see the initial visual state. This is a mode 1, background 2 affine demo, so could be a completely broken matrix on EZ Omega due to the weird poison-VRAM EZO has with PSRAM - but that doesn't explain why it only happens with my compile-time LUT.

I'll try clearing memory before execution also.

Thank you for confirming that it works on miniSD EZ4, that helps narrow it down to an issue specifically in EZO.

EDIT: Clearing memory at start does nothing, still a white screen.
EDIT2: Thanks for confirming this happens with EZO on DS Lite, I suppose it isn't a problem with original AGB.

 

[FAST6191]

Had a little fiddle with GBATA, flash advance toolkit and a hex editor to create a header more akin to a normal game. No joy there either -- was thinking there might have been another homebrew without a header and special things done as a result.

 

[Xilefian]

Aha found the cause! mGBA debug print. It was running perfectly fine with the mGBA debug calls left in, but as soon as the LUT was added it breaks. Source of the issue found.

mGBA is not standard (writes within 0x4000400-0x4FFFFFF), so it is probably a non-issue.
Any developers who encounter this; remove mGBA debug calls when Omega is in use.

This definitely brings forward my plans to write an SD logger for EZO...

Not sure what the expected behaviour should be when touching this memory region. I don't remember seeing it documented as being any EZO system calls.

Mystery solved.

 

[kuwanger]

Wild guess? The only mention I see of the 0x40000000 range is in SRAM allocation on the s71 chip. Specifically, it mentions holding a 0x400 size copy of the IO registers. I presume this is for RTS. Perhaps it's doing out of bound read/writes when in PSRAM but not in NOR mode? Admittedly, that still doesn't really add up, but then guessing is fun.

 

[Jengo]

Xilefian is there anyway you can explain to me what the cause was? Lol I’m sorry I’m really new to all of this.