GBA

[XProger]

GBA alpha (GYM, LEVEL1, LEVEL2)

• [x] new engine architecture
• [x] new data formats and converter
• [x] ARM software rasterizer
• [x] draw rooms, objects and sprites
• [x] vanilla underwater effects
• [x] Laras states, physics and collision
• [x] triggers
• [x] camera
• [x] weapons (all)
• [x] navigation
• [x] enemies logic (Bat, Wolf, Bear)
• [x] inventory
• [x] main menu
• [x] save game
• [x] gameflow
• [x] ADPCM tracks

GBA beta (all levels)

• [x] Ez-Flash IV support
• [ ] GameCube Player rumble support
• [ ] flip rooms
• [ ] static sounds
• [ ] water flow
• [ ] earthquake
• [x] cutscenes
• [ ] multi-pickups
• [ ] full set of objects (spikes, moving blocks, scion pickup, boulder etc.)
• [ ] full set of enemies
• [ ] data converter (PC+PSX->GBA)
• [ ] ROM data size optimization
• [ ] ADPCM sounds
• [ ] FMVs (?)

GBA release

• [ ] bugfixing
• [ ] perf optimizations

[sukoshi1507]

I just wanted to mentioned that the gba port is not running on a 3DS through open_agb_firm it works perfectly on a MiSTer FPGA using the latest GBA core :)

[profi200]

The reason it's not running on 3DS hardware is you are using too fast ROM wait cycles here: https://github.com/XProger/OpenLara/blob/master/src/platform/gba/main.cpp#L796

Should be WS_ROM0_N3 which is the fastest retail games use. I don't know why the hardware does not support it. They probably didn't care about implementing faster access than retail games use.

If you don't want to recompile throw the latest release in a hex editor and go to offset 0x1A39C and patch 1840 to 1440. It will work fine with this patch.

[sukoshi1507]

Thanks for the explanation.

Le lun. 17 janv. 2022 à 17:50, profi200 @.***> a écrit :

The reason it's not running on 3DS hardware is you are using too fast ROM wait cycles here:

https://github.com/XProger/OpenLara/blob/master/src/platform/gba/main.cpp#L796

Should be WS_ROM0_N3 which is the fastest retail games use. I don't know why the hardware does not support it. They probably didn't care about implementing faster access than retail games use.

— Reply to this email directly, view it on GitHub https://github.com/XProger/OpenLara/issues/368#issuecomment-1014730451, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDYDWXWB5VNWGB7SINWEO3UWRCDZANCNFSM5AKIVGYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[naxeras]

It is possible play with ezflash IV?

Regards.

[ketsuban]

boostEWRAM will cause the game to lock up on the Game Boy Micro, since it has the undocumented register at 0x04000800 (unlike the DS) and doesn't support 1-waitstate EWRAM.

[XProger]

@ketsuban it's checking code for EWRAM and works perfectly on Game Boy Micro.

@naxeras some IV's plays, some are one not.

@profi200 Looks like not all carts supports N2/S1 wait states for ROM. The checkROM code should determine the minimum latency, but after the latest tests it returns false positives, so it's not ready yet.

[profi200]

Older flashcarts will struggle with these settings, yes. The N timing which causes most of the issues is the non-sequential timing. This means you need to test random ROM reads to find out if it's stable.

You probably already know about it but WAITCNT is documented here: https://problemkaputt.de/gbatek-gba-system-control.htm

I tested a bit and downgrading to N3 speed costs about 1 frame per second. Not sure if ROM prefetch has any impact but it doesn't cause any issues. Also not sure what impact the EWRAM overclocking has. This is also not supported on 3DS since the GBA hardware is identical to the one found on a DS/DS lite which lacks the undocumented register. That reminds me you are trying to restore this register if your test fails. This is not necessary because if the undocumented register doesn't exist it's just open bus.

[ezfragz]

How will the ROM Data size optimization work? I've tried numerous guesses and I just can't get to stand one.

[XProger]

@ezfragz TR levels are sort of WADs, they store sound samples, animations, geometry and textures that are used for other levels too. So splitting data and removing duplicates is the way for size reduction.

[ezfragz]

@ezfragz TR levels are sort of WADs, they store sound samples, animations, geometry and textures that are used for other levels too. So splitting data and removing duplicates is the way for size reduction.

Ah, that's really smart!

[Kroc]

You might already know this / be doing it, but you can use the GBA's ARM superviser modes as a set of free shadow registers; Randy Linden used this trick for his Quake GBA port. This video demonstrates the port and explains the trick:

https://www.youtube.com/watch?v=R43k-p9XdIk

[XProger]

@Kroc hi, thanks, I'm already using it e821f236a27231830c5fd5f4ec0cb0a47b2ec1e1