Hacking EzFlash Omega Writing in PSRAM

[CodeBoy]

Dear All,

I have made an homebrew, it runs in PSRAM with an EZFlash Omega.
This homebrew would like to self modifying its code.
Is there any way to allow writing in PSRAM at address 0x08000000 + 32 MByte when running software in ezflash Game Mode ?

Regards

 

[FAST6191]

There was an option for this for the old EZ3 (one of the PCE/TG16 emulators used it to allow a measure of CD support. https://ezflash.sosuke.com/viewtopic.php?f=2&t=150 if you wanted the EZ3 SDK), for the EZ4 on DS (see Lick's RAM API and various things for the 3 in 1( https://wiki.gbatemp.net/wiki/3_in_1_Expansion_Pack_for_EZ-Flash_V#Third-Party ) but I am not sure what presently goes for the Omega.

The kernel source might have something you can pull a protocol from
https://github.com/ez-flash/omega-kernel

 

[EZ-Flash2]

We set the PSRAM to read-only after the game and homebrew launch, for the security reason.

You can send a PM to me, describe your homebrew and we'll see if there are other ways to solve it.

 

[CodeBoy]

I am sorry, i can not send PM for now, i am too new gbatemp user.

My homebrew is a GDB server used for debugging other homebrew running on the GBA.
I use the GBA link port to communicate with my PC hosting the GDB client.
My GDB server is started by EZflash, the code runs at the end of the PSRAM.
I can load software in GBA RAM and debug it.
I would like to load software using Rom address (i.e 0x08000000 to 0x08XXXXXX) then i also need to write at 0x08000000 to 0x08XXXXXX to set and remove breakpoint.

 

[patters]

Hi @EZ-Flash2,

I have noticed that the EZ3 version of PCEAdvance emulator does not enable the PSRAM when used on an EZ Flash IV device (miniSD model, firmware 2.05). This means that the emulator is unable to support PC Engine Super CD-ROM titles, which need an additional 192KB of RAM beyond the GBA system specs.

I have uploaded the PCEAdvance source code to GitHub here since the author's original website no longer exists. I had hoped that perhaps the method of addressing the PSRAM would be the same for EZ3 and EZ4, but that appears not to be the case. I notice that although the SDKs for the EZ3 and the Omega products were open sourced, there does not appear to be any source code for the EZ4 model.

Are you perhaps able to see if it's a simple change to get PSRAM addressing working in PCEAdvance, judging from this EZ3-commented code in the source file: cart.s? It would be great to be able to play some of the SuperCD games like Akumajou Dracula X - Chi No Rondo in particular. It would also be good to fix this on the Omega also.

Thanks!

 

[patters]

This problem is gnawing away at me. I think I might have found a clue.

In the PCEAdvance source file cart.s we can see where the EZ3 PSRAM is being enabled:

;----------------------------------------------------------------------------
EnableEZ3RAM
;----------------------------------------------------------------------------
    ldr r2,=0x9fe0000
    mov r0,#0xD200
    strh r0,[r2]            ;*(u16 *)0x9fe0000 = 0xD200;
    mov r4,#0x8000000
    mov r1,#0x1500
    strh r1,[r4]            ;*(u16 *)0x8000000 = 0x1500;
    add r4,r4,#0x20000
    strh r0,[r4]            ;*(u16 *)0x8020000 = 0xD200;
    add r4,r4,#0x20000
    strh r1,[r4]            ;*(u16 *)0x8040000 = 0x1500;
    ldr r4,=0x9C40000
    mov r0,#0xA500
    strh r0,[r4]            ;*(u16 *)0x9C40000 = 0xA500;        //This is the OpenWriteCommand
    sub r2,r2,#0x20000
    strh r1,[r2]            ;*(u16 *)0x9fc0000 = 0x1500;
;    bx lr

0xA500 seems to be the special command, judging from the comment.

The rest of the numbers are consistent with the numbers in the setRampage function for instance, in the ez3pda source code on GitHub.

Picking through the whole published source I can now see that it contains detections for the EZ4 hardware - in particular in hard.cpp. To my amateur eye I can't spot anything obviously relevant in the CheckEz4Card() function for instance. Most of it seems to be concerned with identifying the possible NOR flash chip parts, sizes, and base addresses.

However, by simply searching the whole ez3pda repo for mentions of "0xA500" I found this in the OpenRamWrite() function:

void  OpenRamWrite()
{
    *(vu16 *)0x9fe0000 = 0xd200;
    *(vu16 *)0x8000000 = 0x1500;
    *(vu16 *)0x8020000 = 0xd200;
    *(vu16 *)0x8040000 = 0x1500;
    if(g_EZ4CardType ==  EZ4_1Chip)
        *(vu16 *)0x9C40000 = 0x5A00;
    else
        *(vu16 *)0x9C40000 = 0xA500;
    *(vu16 *)0x9fc0000 = 0x1500;
}

Notice that if condition. So it looks to me like for EZ3 PSRAM OpenWrite you need 0xA500, but if you have an EZ4_1Chip (which I think I have, since it has only one PSRAM chip mounted despite BGA pads on the PCB for two) then you'd need to use 0x5A00 instead.

My guess is that I need to patch that single byte in PCEAdvance to get it working with EZ4 PSRAM. Next challenge - how to find it. I presume I will have to hand assemble the instructions either side of it until I have a unique search string to hunt down in the binary file...

 

[patters]

https://armconverter.com/?code=ldr r4,=0x9C40000 mov r0,#0xA500

So the Hex string I'm looking for is A50CA0E3 which is indeed present only once in the compiled binary. Now to test the patch to 5A0CA0E3...

EDIT. Well that didn't work unfortunately Tried with firmwares 1.720 and 2.050.

 

[patters]

Looking at the source for Lick's RAM API it looks like perhaps the EZ4 needs an unlock command first to use PSRAM, by setting 0x8400000 to 0x0.

That said, Lick's RAM API was for NDS and at that time was likely to have been intended for EZ5 (EDIT - actually it seems that EZ3, EZ4, and EZ5 were all supported). I tested this by trying my EZ4 in my DS running Quake2DS. This presents the same PSRAM compatibility choices as Lick's RAM API but doesn't work with EZ4 though. It works fine with my EZ5 slot 2 card.

Any ideas for getting EZ4 PSRAM working with PCEAdvance on GBA @EZ-Flash2 ?

 

[patters]

Google Translation of Chinese comment text in hard.h from ez3pda repo:

Classification of EZ4 cards
1. 128PSRAM, 256MNOR
1) 2 pieces of VZ064: 128MPSRAM, 4X64MNOR
2) 1 piece of VZ128: 128MPSRAM, 2X128MNOR
3) 1 piece H6H6H6: 128MPSRAM, 2X128MNOR

2), 3) The NOR structure is different from the NOR-only ID
2. 256MPSRAM, 512M NOR
1) 2 pieces of VZ128: 256MPSRAM, 4X128M NOR
2) 2 pieces of H6H6H6: 256MPSRAM, 4X128M NOR
The structure is the same, only the ID is different

 

[patters]

Well, I've figured it out
If at first you don't succeed try, try, and try again. "Gradius II - Gofer no Yabou (J) (SCD).iso" running nicely...

 

[patters]

The secret to getting it working is this function - OpenWrite()
https://github.com/ez-flash/ez3pda/blob/1d16559caf7a94dff6d8fdcf94f572bc09b36ae4/hard.cpp#L19

I found the part of the ez4 firmware ezfla_up.bin file which contained the same A50CA0E3 string from earlier in this thread. Then I disassembled the section surrounding that. I could see it was indeed the OpenRamWrite() function. I noticed, comparing it to the ez3pda source code, that in this binary the OpenWrite() function was called just prior to it. I also noticed that Lick's RAM API does similar - except it's called OpenNORWrite there.

So I injected an assembler version of this function into the PCEAdvance source and whatddyaknow it worked! Looks like it isn't needed for EZ3 but it is required for EZ4 PSRAM access. The only gap is that I haven't ported to assembler the EZ4 model detection code - so if it doesn't work for your EZ4 model (EZ4_1Chip, whatever that is) then I guess you just need to change from 0xA500 to 0x5A00 in the OpenRamWrite() function and compile my EZ4 branch of the PCEAdvance source code using ARM SDT 2.50.
Or you could hexedit the binary, replacing the single instance of "A50CA0E3" with "5A0CA0E3"

My changes to the source are here. If you clone the repo, make sure you're in the ez4 branch.

 

[patters]

OK, next challenge. Unfortunately this isn't working when booting the emulator off NOR flash - which you do need to do for the game Akumajou Dracula X - Chi No Rondo since it's larger than 16MB.

With some more testing I have determined that the OpenRAMWrite() function isn't needed at all, so it was probably for EZ3 only. OpenWrite() on its own does the job for EZ4.
This means I can make an EZ4 working binary by simply hex editing a single byte in the EZ3 binary - by finding "A50CA0E3" and replacing with "150CA0E3", which is in fact replacing

mov r0,#0xA500

with

mov r0,#0x1500

I have tried adding in the SetRompage (OS mode) command which Lick's RAM API uses prior to OpenWrite(). It didn't help with getting it working when launched from NOR.

So, to re-cap, I have got PSRAM working by making the following changes (in assembler, though I've written it in C here since it's clearer to understand):

Removed:

void  OpenRamWrite() //from ez3pda source
{
    *(vu16 *)0x9fe0000 = 0xd200;
    *(vu16 *)0x8000000 = 0x1500;
    *(vu16 *)0x8020000 = 0xd200;
    *(vu16 *)0x8040000 = 0x1500;
    *(vu16 *)0x9C40000 = 0xA500; //change only this line
    *(vu16 *)0x9fc0000 = 0x1500;
}

Replaced with:

void  OpenWrite() //from ez3pda source
{
    *(vu16 *)0x9fe0000 = 0xd200;
    *(vu16 *)0x8000000 = 0x1500;
    *(vu16 *)0x8020000 = 0xd200;
    *(vu16 *)0x8040000 = 0x1500;
    *(vu16 *)0x9C40000 = 0x1500; //to this
    *(vu16 *)0x9fc0000 = 0x1500;
}

This successfully enables the EZ4 PSRAM for the SCD emulation when the .gba file is launched directly into PSRAM from the SD card. It doesn't work however when the .gba file is booted from NOR. I'm so nearly there getting it fully working. Am I missing something simple @EZ-Flash2 ?

@FluBBa, did you have any such problem when implementing the EZ3 version? Is it even possible to run Akumajou Dracula X - Chi No Rondo intact, or do you have to truncate the file to 16MB-192KB? I saw in your old website's news feed you did screenshot this game working back in the day. Also, can you remember which Arcade Card game makes a good test case (are there any with the data track <16MB)? The few I have tried are huge.

 

[patters]

I have done a bit more scraping around for crumbs of info about this and I'm now convinced that PSRAM access could never have worked when loading a game from NOR on the EZ3, which one might think would be necessary in order to run titles like Dracula X which are larger than 16MB. I have concluded this by looking at various pieces of evidence, but the most compelling is in the form of the EZ-Flash Omega Document.

Other useful links:
https://www.problemkaputt.de/gbatek-ds-cart-expansion-ram.htm
https://github.com/Dartz150/EZFlash3in1/blob/main/dsCard.cpp
https://forum.gbadev.org/viewtopic.php?f=19&t=14595&hilit=psram
https://gbatemp.net/threads/unbrick...ded-but-successful-for-me.354784/post-4782190
https://mailman.dslinux.in-berlin.d...mit-dslinux.in-berlin.de/2007-May/002213.html
https://gbatemp.net/threads/ez-flash-omega-kernel-source-code-released.510332/post-8124061

In summary, the key point is that the GBA's cartridge port address space is only 32MB large. The EZ-Flash Omega design is stated to be an evolution of the EZ3 in that document, and it explains that the cart can be either in:

• OS mode [SetRomPage(0x8000)] - which maps the boot loader, the firmware, the SRAM, the SD card, buffers for SD I/O, an 8MB bank of PSRAM, and an 8MB bank of NOR (both of which need to be paged in and out to see more), or...
• Game mode - which maps either:
  • 16MB of PSRAM [SetRomPage(0x200)], or
  • 32MB of NOR [SetRomPage(0x0)], with offsets allowing several ROMs to be launched from the same NOR

So if the flashcart is in game mode with 32MB of NOR mapped to 0x8000000 then there would be no way to address any PSRAM. I guess it might be possible if say the last 30MB of NOR was mapped to 0x8000000 then there could be 2MB of PSRAM at the end of the address space, but to do that you would have to flash the game data 2MB offset into the NOR, which the EZ-Flash menu wouldn't do for you. In one of the threads I linked above, Kuwanger managed to brick his own EZ4 irreparably by tinkering with this kind of thing, so I don't want to risk it. Even testing my EZ4 in my Nintendo DS instead of my EZ5 3-in-1 results in the firmware being bricked by simply attempting to load a GBA game from my CycloDS. Luckily the EZ4 can be rescued with a re-flash by holding R on boot.

In addition, switching between OS and Game modes within the emulator to modify the paging on the fly would need the code to be running from RAM not NOR (since ROM addresses are remapped live) so the emulator would probably need substantial modifications. Clearly, it would also need to be contextually aware of whether it's running from PSRAM or from NOR, and there's no GetRomPage function in the EZ sources, and very little EZ3 code in PCEAdvance. This to my mind means the EZ3 build of PCEAdvance logically cannot have supported Super-CDROM games larger than 16MB-192KB, nor Arcade Card games larger than 14MB-192KB.

Now that I think harder about it, I do vaguely recall that one of those now lost Pocketheaven threads about Akumajou Dracula X from back in the day mentioned that you needed to trim the gba file, which stuck in my mind at the time because I remembered it being a pretty dirty way of getting the game to work. But work it does... at the expense of breaking the game at some later level I guess...

I will modify my PCEAdvance builder script to trim the .gba files down automatically to their respective maximum allowed PSRAM sizes if they're oversize and their ISO filenames contain "SCD" or "ACD". Oversized regular CD-ROM titles will be trimmed to 16MB (works fine for Ys).

Since the OpenWrite command I used to fix EZ4 PSRAM access seems to be fairly universal to the post-EZ3 cards, I decided to test on my Nintendo DS by launching from the CycloDS (Slot2) to the EZ-Flash V 3-in-1 (Slot1) and Super CD-ROM support worked fine

 

[patters]

Next challenge: I haven't been able to verify that Arcade Card support is working for EZ4.

The only Arcade card title I can find with a data track smaller than 16MB is Mad Stalker - Full Metal Force at 5.1MB. It crashes after displaying the publisher logo unfortunately. One of the only other titles that comes close in size terms (15.6MB), Ginga Fukei Densetsu Sapphire crashes on boot when trimmed to 14MB-192KB. Same with World Heroes 2 (17.7MB).

The PCEAdvance source code looks ok though. It simply deducts 0x200000 (2MB) from the memory address at the last 192KB of PSRAM that was used for Super CD-ROM support, and uses that as the Arcade Card base address.

I have found that when exiting back to the EZ4 menu after one SCD/ACD game and trying another will often crash - but work fine with a power cycle. Perhaps we need to invoke CloseWrite() on exit.

EDIT, I replaced the exit code in visoly.s with this code in my EZ4 branch and, although it exited properly, it didn't help this issue of problems with repeated SCD game loads failing but working fine on a cold start. I wonder whether it's because PSRAM isn't cleared. This phenomenon caused issues with Goomba's rom list parsing tainted PSRAM data as additional game ROMs.

 

[patters]

Holy crap! I've surprised myself by actually fixing that issue It was indeed the dirty PSRAM from the previous execution that was causing problems. By invoking the memset_ function to clear 0xC000 words (192KB) from address SCD_RAMp the problem is solved. And I know more about ARM assembly programming. Win win.

 

[ASSASSIN-Z]

Nice work! I noticed you referenced visoly.s in your coding. Is there a version of PCEAdvance that can play these games on an old Visoly Flash Advance Xtreme card?

Holy crap! I've surprised myself by actually fixing that issue It was indeed the dirty PSRAM from the previous execution that was causing problems. By invoking the memset_ function to clear 0xC000 words (192KB) from address SCD_RAMp the problem is solved. And I know more about ARM assembly programming. Win win.

 

[patters]

No I'm afraid not. That's just the name of the file for historic Pogoshell reasons I believe. The EZ3 was the first card to have onboard PSRAM I think. The older flash cards are just NAND I think.

I still can't seem to get any Arcade Card title working. They all seem too big. Although I've found a good place to conditionally clear the Super-CD RAM I can't seem to find a way to contextually clear the Arcade Card RAM. Because if you have PSRAM at all you will have the Arcade Card RAM available, but you would only want to clear it if you're trying to run an Arcade Card game, otherwise you're losing 2MB every time even when launching a Super CD game. In the case of say Akumajou Dracula X that would chop a whole 2MB more off the end of the compilation.

I think I'll leave it as is for now, especially since I can't even find a working Arcade Card title.

Modified source code for PCEAdvance 7.5
New PCEAdvance binary is attached to this post.
PCEAdvance Python 3 compilation builder script