Hacking EZ-FLASH OMEGA white-screen PSRAM ROM

Xilefian

Member
OP
Newcomer
Joined
Nov 11, 2010
Messages
19
Trophies
0
XP
71
Country
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.
 

Attachments

  • ez_omega_test.zip
    83.6 KB · Views: 120
Last edited by Xilefian,
  • Like
Reactions: zfreeman

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
34,364
Trophies
2
Website
trastindustries.com
XP
23,484
Country
United Kingdom
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.
 
Last edited by FAST6191,

Xilefian

Member
OP
Newcomer
Joined
Nov 11, 2010
Messages
19
Trophies
0
XP
71
Country
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.
 
Last edited by Xilefian,

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
34,364
Trophies
2
Website
trastindustries.com
XP
23,484
Country
United Kingdom
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

Member
OP
Newcomer
Joined
Nov 11, 2010
Messages
19
Trophies
0
XP
71
Country
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

Well-Known Member
Member
Joined
Jul 26, 2006
Messages
1,510
Trophies
0
XP
1,780
Country
United States
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

New Member
Newbie
Joined
Sep 24, 2020
Messages
1
Trophies
0
Age
24
XP
22
Country
United States
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.
 
General chit-chat
Help Users
    KennieDaMeanie @ KennieDaMeanie: https://brobible.com/culture/article/burt-reynolds-pontiac-firebird-for-sale/?fr=operanews