(edited: )

I recently started doing deep dives into all versions of the games, initially focusing on differences, but my goal is to gain a complete understanding of RNG across all versions.

I'll try to update this thread with information as I confirm more.
Information will also be posted here.

Currently I'm working on: Mapping initial Tarot RNG
DONE - Preliminary search for time counters.
DONE - Found Tarot locations in Memory for ALL versions.
DONE - Find Leader Name Memory locations.
NEXT - Scripting a bot to play through and find all possible card sets per version:

Beta version here:
See it in action here:

2. DONE - Nintendo Power SNES - still being tested - Beta coming.
3. NEXT - PS1 - nearly finished.
4. NEXT - Saturn - not started

Both versions use a 256 counter for initial card RNG. @DragondarchDragondarch 's RNG manipulations for the name "!" will work well on all original versions of SNES. The documented card sets may be off by a single digit compared to hardware perhaps due to recent accuracy improvements in emulation or issues with the BSNES core in recent bizhawk versions that make replicating accurate to hardware results impossible, but in practice it doesn't change how anything works. I'll probably need to test with save states on real hardware to figure what the discrepancy really is with the SD2SNES, assuming I can get save states working on my older model.

Time Counter stored at WRAM:

Secondary Time Counter stored at WRAM:

Tarot Cards stored at WRAM:
0xDBE - 0xDCC

Leader name stored at WRAM:
0x7A4 - 0x7AB
0x87B - 0x882

Nintendo Power Kiosk version
Nintendo Power SNES ROM uses a 256 counter for initial card RNG but has a vastly different algorithm that seems very similar to the PSX version. Current Manipulations for "!" do not work. 0x52 is a secondary time counter that resets to 0 once it gets to FF (255). 256 x 256 = a 32bit counter (65,536) and this timer seems to have involvement with the cards, so it may be the exact same system used for PS1 and Saturn.

Hopefully scripting the card RNG will illuminate just how close it is - 3600 iterations and counting!

Time Counter stored at WRAM:

Secondary Time Counter stored at WRAM:

Tarot Cards stored at WRAM:
0xDBE - 0xDCC

Leader name stored at WRAM:
0x7A4 - 0x7AB
0x87B - 0x882

Seem to have RNG based on program start - there is a main counter that counts up indefinitely and initial card RNG seems entirely based on it. That appears to be a full 32bit counter and does reset to 0 once it reaches the limit. There are semi frequent areas of lag frames on PS1. This essentially means that there are small 2 to 4 frame windows where it's very likely you will get a specific set of cards, but the card sets are based solely on the timer and algorithm and the periods of lag being inconsistent can make things tricky. There is also a 0 to 64 counter I'm aware of that doesn't seem involved in card RNG, but may have a role in other types of RNG.

Tarot Cards stored at PSX MainRAM:
1C6B85 - 1C6B93

Leader name stored at PSX MainRAM:
1C6C14 - 1C6C1B

Time Counters stored at PSX MainRAM:



Other counters:

Unknow why there's so many on slightly different offsets/starting positions.

Seems to have RNG based on program start - there is a main counter that counts up indefinitely and initial card RNG seems entirely based on it. That appears to be a full 32bit counter and could take over a year to figure out if there's any interesting effects if it maxes out. Tarot cards are stored odd/even in the address range - only version that does this.

Time Counter stored at SAT work ram high:

Secondary Time Counter stored at SAT work ram high:

Another time counter (Realtime) stored at SAT work ram high:

Tarot Cards stored at SAT work ram high:
0CD46C - 0CD479

Slot 01 = 0CD46D
Slot 02 = 0CD46C
Slot 03 = 0CD46F
Slot 04 = 0CD46E
Slot 05 = 0CD471
Slot 06 = 0CD470
Slot 07 = 0CD473
Slot 08 = 0CD472
Slot 09 = 0CD475
Slot 10 = 0CD474
Slot 11 = 0CD477
Slot 12 = 0CD476
Slot 13 = 0CD479
Slot 14 = 0CD478

No idea why Saturn does this. Cards are reordered shortly after final pick too.

Leader Name stored at SAT work ram high:
0F9674 - 0F967B

Same odd/even storage pattern.

These games are incredibly different under the hood though - that much is clear.

NewSchoolBoxerNewSchoolBoxer and SheexSheex like this. 

One of the big things I'd be interested in is how the RNG affects (Joker) card pulls after loading a save file. With what research I was able to do way back when, I know it's similar to how the initial set is determined, in that it uses the frame counter to set a "seed," but beyond that loading different save files produced different results, despite loading on the same frame. It really felt like it was using something from the save file itself to mix things up.

NewSchoolBoxerNewSchoolBoxer and KrayzarKrayzar like this. 

Jokers, items from towns, and items from units are all on my list to figure out! And if you (or anyone) have any other ideas of things for me to test, please feel free to mention!

I'm having some fun relearning lua. Used to use it and vbs all the time 15 years ago, but I'm more than a little rusty.

I'm growing increasingly suspicious that - at least in the original - the leader name + save slot is a large part of the RNG.

There may be other factors, but basically to fit the game into the cart, it looks like they made some serious compromises compared to the Nintendo power version. It's relatively clear they meant to use Timer 2, which exists in the original, to provide more variability, but so far it doesn't seem to have a role in anything I've tested.

NewSchoolBoxerNewSchoolBoxer likes this. 

Good work here and comparing against the different releases! I think rather than bot to mine all the tarot possibilities for various name entries, we could construct the actual algorithms the game uses and instead use botting for optimal routes and timing windows. I've never used Lua, might be a good time to start learning...

Your thread's high page views took me by surprise. Even if only 3 or so people are actively speedrunning this game, I'm glad that the interest in figuring out Ogre Battle's rather cryptic game mechanics remains.

I spent a few hours catching up to speed on assembly and debugging and made some progress:

Nothing exciting to report but I'm fairly confident the solutions can be found. I hope it's helpful to anyone with microprocessor or low level (C or C++) programming experience.

KrayzarKrayzar likes this. 

Yeah, I should clarify that the scripts are mostly just to be able to quickly compare, test, or prove any findings from the algorithm.

That and I figure they might be useful for folks who don't want to dive in the depths of the theoretical. Goal is to lower the barrier to entry for folks finding their own strats, and bots are an accessible way to do that.


I was curious so I decided to test out the loading RNG. From my findings it looks like its only the frame you select the save file on that determines the RNG seed.

What I did was create two save files with different names, stages complete, armies, etc. Powered on the game, went to the save load screen, paused emulation. At this point I manually set the global frame counter to a known value, I choose 0x40. Held down the A button and frame advanced to start the loading. Used a joker and got a World card. I then repeated this process for the second save file and was able to pull a World card.

Things that could still be tested: If a game was significantly further into the game and had more data. I don't believe it'd push it into another frame tick but its possible.

Latest News
View all
No news
Recent Threads
View all
Thread Author
RNG Research
Last post
5 replies
Side by Side recordings of PSX Ogre Battle being faster than SNES
Last post
13 replies
Devil % Category?
Last post
3 replies
PSX Save Hacking / Visualization
Last post
3 replies
Getting Started.
Last post
6 replies