Home Page Forums MAME MAME SNES: ST-0018 emulation research

http://bsnes.googlecode.com/files/bsnes_v086r12.tar.bz2

Adds mul, clarifies that 0xf4.bin is actually a data ROM, and not RAM, fixes subtraction carry/overflow flags (hopefully?)

I can move a few times in-game, it freezes once the ARM starts doing heavy-lifting.

> Alright, I'll try to hook it up in MESS after work tomorrow and see how it behaves.

I was really hoping you (or someone) might look at my ARM CPU emulation for bugs ... I'm about one or two major CPU bugs away from this game being playable.

The emulation is as straight-forward as humanly possible. But there's most likely problems with the shifter carry out still.

Not to be a cock or anything, but did you help me debug any of my SNES work in MESS that was ported from your code? No, because we're all perfectly capable of debugging our own code. MAME and MESS both have an ARM core robust enough to run Android, Windows CE and MAME itself, and it would literally take 30 minutes to wire up the ST-0018 to the MESS SNES driver and plumb the I/O access, so why don't you make use of MESS's robust debugger to trace out the execution on MESS's ARM core and then compare against yours? It's almost too easy.

> Not to be a cock or anything

No, it's a fair criticism. I always ask for help, whereas few people ask for mine.

It never hurts to ask, though. You're certainly welcome to not help if you are busy or don't want to.

> did you help me debug any of my SNES work in MESS that was ported from your code

I helped etabeta with anything I was asked, as I do elsewhere, eg:
http://board.byuu.org/viewtopic.php?p=53986#p53986
I also followed the SNES WIPs topic and explained the causes of any bugs I recognized. I also did what I could when MAME merged in libco.

> No, because we're all perfectly capable of debugging our own code.

I've no doubt I can pull this off eventually. I'm excited because this is a major milestone, it's the very last coprocessor used in an actual game.

But I like cooperation. We can do it faster together. And I'll be sharing with you guys the details of the CPU<>ARM communications bridge for MESS (not to mention the ROMs.)
CPU cores are tricky. It's easy to overlook something for a really long time, so a second set of eyes help. It's not so easy to grep over the 1.4GB log file of instructions I have here looking for the first mistake. Especially when I really don't know ARM.

> MAME and MESS both have an ARM core

Hence why I'm asking, you guys know ARM a whole lot better than I do

I couldn't use your core directly even if I wanted, as non-commercial is not compatible with GPLv3 (note: I fully support non-commercial licenses.)

> why don't you make use of MESS's robust debugger to trace out the execution on MESS's ARM core and then compare against yours?

I've never compiled MESS. I don't know how the infrastructure works to hook it up and log instructions. To take on all of that would probably be harder than fixing the CPU bugs in the first place ...

But you raise a good point: I suppose R. Belmont hooking it up in MESS would be equally as wise as looking at my core. Perhaps even easier.

Yeah, my point in saying I'd hook it up wasn't that I'd get it running and announce victory, it was that you could then run mess -debug and "trace arm.txt"

I'll give an update here as well:

http://bsnes.googlecode.com/files/bsnes_v086r15.tar.bz2
http://byuu.org/temp/st018-20120301.tar.bz2

The ROM has checksum functionality that we used to verify both ROMs were dumped correctly. Miraculously, analysis shows that the data ROM is actually random numbers. I guess they had nothing better to do with it. I've decoded the entire 32-bit address bus for the ARM, and mapped out the mirroring for the CPU.

We've plugged in VBA's ARM core, and it gets stuck at the same point: move the bottom right piece and the AI responds that you have checkmated your opponent (in one move, talk about impressive.)

Although my ARM core is far from perfect, it's matching VBA's, so this isn't an ARM emulation issue at this point.

The problem is with the status register at $3804.
d0 = ARM wrote a byte; CPU can read it (reading clears bit)
d3 = CPU wrote a byte; ARM can read it (reading clears bit)
d7 = ready (0 = CPU is performing reset, or was turned off.)
However, the game tests d2 and does different things based on it.

We have watched all ARM writes, and all CPU reads, and nothing explains how d2 can ever be set.
I have run my own tests on the real cartridge (executing debug and board upload commands), I cannot manage to ever set d2 there, either.

I can run any test code on hardware, but I've run everything I could think of. It's stumped us all.

All of the progress and notes are here:
http://board.byuu.org/viewtopic.php?f=16&t=2502

Does it have a co-coprocessor type deal or something on-die which can set d2?

LN

I actually wouldn't necessarily trust VBA in ARM mode; GBA games run almost exclusively in Thumb because the cartridge data bus is 16 bits wide (so you'd take a wait state on every fetch running ARM code).

Fuck it, I'm hooking it up in MESS as soon as I get home.

Oh, also, if it's 26-bit v3 code running it in an ARM7 core will produce incorrect results.

> Does it have a co-coprocessor type deal or something on-die which can set d2?

Possible. The code makes reference to 6000:0000+, but this area returns 0x40404001 when read (rather than open bus like all other areas ... open bus in this case is the pipeline's next fetched opcode) (same value every 4 bytes until 7fff:ffff)

Resetting the CPU takes 65,536 cycles (~3ms.) So it is possible that there's a bootloader running before it, that disables itself when finished. But that seems ... unlikely.

Anyway, the tricky part is that there is no action on the ARM code's part that would tell it to set d2. So if there is special silicon that is doing it (there has to be), it's doing it by observing the bus transmissions back and forth (possibly analyzing the byte values written ... which is insane.)

> I actually wouldn't necessarily trust VBA in ARM mode; GBA games run almost exclusively in Thumb because the cartridge data bus is 16 bits wide (so you'd take a wait state on every fetch running ARM code).

Hmm, I suppose it's possible that VBA has the same CPU bug that I do.

> Fuck it, I'm hooking it up in MESS as soon as I get home.

Most awesome, thank you very much. Having a third verification can't hurt.
If you want to discuss how to hook up the SNES-side communications, PM me your contact info (I have IRC and AIM.)

> Oh, also, if it's 26-bit v3 code running it in an ARM7 core will produce incorrect results.

I'm almost certain that this is ARMv3 / ARM6 32-bit code.
It certainly makes references to memory addresses at 0xe0000000+.
And it also uses MSR to put data into CPSR at the start of the program.
This suggests that data is not stored inside r15/pc.
But certainly we can try hooking up the 26-bit MESS core and see what happens, I suppose.