Home Page
Posted By: byuu SNES: ST-0018 emulation research - 02/25/12 02:56 PM
It appears I was able to dump the ST-0018 program ROM:



... amusingly, through the controller port.

http://byuu.org/temp/st0018-20120225.tar.bz2

The ST-0018 is used by Hayazashi Nidan Morita Shougi 2.
It holds the distinction as the only coprocessor not yet emulated, and the only game not yet playable.
Completing this would give us 100% total compatibility.
And from there, all that is left are strange peripherals like keyboard controllers and horse-race-betting dial-up modems.

Cydrak looked at the file, and found ARM 32-bit instructions. The chip dates to 1994, so this would be pre-THUMB. Possibly ARMv6 or older.

Discussion thread is here:
http://board.byuu.org/viewtopic.php?p=56471#p56471

I'd humbly like to ask for anyone's assistance who is familiar with ARM and would like to help us get this emulated.

Finishing this one last chip will fulfill a 7.5+-year dream of mine; and I'll be eternally grateful to anyone who can assist.
Posted By: Haze Re: SNES: ST-0018 emulation research - 02/25/12 03:14 PM
Originally Posted By byuu
It appears I was able to dump the ST-0018 program ROM:



... amusingly, through the controller port.

http://byuu.org/temp/st0018-20120225.tar.bz2

The ST-0018 is used by Hayazashi Nidan Morita Shougi 2.
It holds the distinction as the only coprocessor not yet emulated, and the only game not yet playable.
Completing this would give us 100% total compatibility.
And from there, all that is left are strange peripherals like keyboard controllers and horse-race-betting dial-up modems.

Cydrak looked at the file, and found ARM 32-bit instructions. The chip dates to 1994, so this would be pre-THUMB. Possibly ARMv6 or older.

Discussion thread is here:
http://board.byuu.org/viewtopic.php?p=56471#p56471

I'd humbly like to ask for anyone's assistance who is familiar with ARM and would like to help us get this emulated.

Finishing this one last chip will fulfill a 7.5+-year dream of mine; and I'll be eternally grateful to anyone who can assist.


What have you tried? I imagine the MAME core would handle it. I'm assuming you already know how it communicates with the main system in order to have dumped it using this method? It sounds like it would just be a case of hooking up the CPU then connecting the various latches needed (although being a custom chip you can't discount additional timers / custom co-processor and the like)


Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 02/25/12 03:22 PM
Get us the ROM, sounds trivial to hook up since MAME speaks ARM up through ARM9
Posted By: etabeta78 Re: SNES: ST-0018 emulation research - 02/25/12 03:29 PM
I think the original post contains the link you need...

anyway, byuu, congrats!
Posted By: byuu Re: SNES: ST-0018 emulation research - 02/25/12 03:54 PM
Yes, the ROM is here:
http://byuu.org/temp/st0018-20120225.tar.bz2

It is 0xf3.bin.

From the SNES side, the register ports are:
$3800r data port from ST018 to SNES
$3802r data port from SNES to ST018
$3804w command register (results in $3800)
01 = unknown
aa = board upload
b2 = unknown
b3 = player lost test
b4 = player won test
b5 = check test
f1/f2 = test registers (returning $00 seems enough)
f3 = dump ROM
f4 = dump RAM(?)
$3804r status register
d7 = chip ready
d4 = write ready
d0 = read ready
... and that's it. Very small interface.

So for instance, you want to know if player 1 was checked.
You write $aa to $3804. Then you write the board into $3802 (9x9 grid + 16 bytes for promotion information.) Now write $b5 to $3804, wait a bit, read $3800. It will be 1 if checked, 0 if not checked.

I can jump on IRC/AIM if someone wants to try hooking it up to an ARM core in MESS. Right now, I'm not even sure where to begin execution when the chip powers on.
Posted By: Haze Re: SNES: ST-0018 emulation research - 02/25/12 04:13 PM
Originally Posted By byuu
Yes, the ROM is here:
I can jump on IRC/AIM if someone wants to try hooking it up to an ARM core in MESS. Right now, I'm not even sure where to begin execution when the chip powers on.


0

:-)

The MAME ARM core works pretty well, from a CPU side the main pitfall is if it has a custom co-processor (like the data east stuff does, IIRC our emulation is still hardcoded to that co-processor)
Posted By: Anna Wu Re: SNES: ST-0018 emulation research - 02/25/12 05:06 PM
Congratulation, byuu. smile
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 02/25/12 08:42 PM
Ok, that's a pretty funny looking dumping rig smile Nice work as always, though, byuu!

Related trivia: NCL (Nintendo Co Ltd, the Japanese guys) would use an oscilloscope on the controller ports to verify correct timing for games using non-standard controllers (e.g. the multi-tap or gun or mouse).

ETA: pulled it up in IDA Pro, it's definitely valid little-endian ARM, of a fairly old architecture vintage (I'd guess v3 or v4).
Posted By: byuu Re: SNES: ST-0018 emulation research - 02/26/12 12:26 AM
This is going to take me a lot longer, since I have to write my first ARM core. Happy that it's pre-THUMB, at least.

So far ...
Code:
00000000 b 0x000000b0
000000b0 mov r10,#0x4000002c
000000b4 mov r2,#0x00000002
000000b8 ldr r10,r2 (?) [I would have expected this to be a store ... weird)


Really hoping it doesn't have any custom vendor extension opcodes, or extra ROMs in there somewhere, or anything terrifying like that. Guess we'll find out soon enough.
Posted By: Lord Nightmare Re: SNES: ST-0018 emulation research - 02/26/12 01:13 AM
WOW! Congratulations!

LN
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 02/26/12 01:13 AM
Nothing custom, the program looks very straightforward.
Posted By: ReadOnly Re: SNES: ST-0018 emulation research - 02/26/12 01:30 AM
pretty clean for a boy's room
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 02/26/12 01:34 AM
Also,

Code:
ROM:000000B0                 MOV     R10, #0x4000002C
ROM:000000B4                 MOV     R2, #2
ROM:000000B8                 STR     R2, [R10]
ROM:000000BC                 MOV     R1, #0xD3 ; '+'
ROM:000000C0                 MSR     CPSR_cf, R1
ROM:000000C4                 LDR     SP, =0xE0004000
ROM:000000C8                 BL      sub_100
ROM:000000CC                 BL      sub_11C
ROM:000000D0                 LDRNE   PC, =0x60000000
ROM:000000D4
ROM:000000D4 loc_D4                                  ; CODE XREF: ROM:000000D8
ROM:000000D4                 BL      sub_14C
ROM:000000D8                 B       loc_D4

Posted By: byuu Re: SNES: ST-0018 emulation research - 02/26/12 03:40 AM
Originally Posted By MESSfan
pretty clean for a boy's room


Please. There's no such thing as a female emulator author :P


Quote:
Also,


What's at 14C? Cydrak marked it as the 'wait for command' function, so I'm kinda curious which of these addresses corresponds to the SNES $3800-3807 (eg is it the 60000000, e0004000, or something else?)
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 02/26/12 04:09 AM
It's a bit long to paste everything, so I'll just include the beginning. 60000000 is where it jumps if 11C returns "NE" flags (on ARM, the PC can be loaded to like any other register; because there's a bare-naked pipeline involved emulating it can be tricky). I assume that's some sort of debug hook.

Anyway, 11C is

Code:
ROM:0000011C sub_11C                                 ; CODE XREF: sub_24
ROM:0000011C                                         ; ROM:00000044 ...
ROM:0000011C                 LDR     R0, =0x40000020
ROM:00000120                 LDR     R0, [R0]
ROM:00000124                 TST     R0, #0x20
ROM:00000128                 RET


and 14C is
Code:
ROM:0000014C sub_14C                                 ; CODE XREF: ROM:loc_D4
ROM:0000014C                 STMFD   SP!, {R1,R2,R11,R12,LR}
ROM:00000150                 MOV     R12, #0xE0 ; 'a'
ROM:00000154                 B       loc_19C


19C is:
Code:
ROM:0000019C loc_19C                                 ; CODE XREF: sub_14C+8
ROM:0000019C                 MOV     R11, #0x40000000
ROM:000001A0                 LDRB    R0, [R11,#0x20]
ROM:000001A4                 TST     R0, #8
ROM:000001A8                 BEQ     loc_1F0
ROM:000001AC                 BL      sub_2B0
ROM:000001B0                 LDRB    R0, [R11,#0x20]
ROM:000001B4                 TST     R0, #8
ROM:000001B8                 BEQ     loc_1F0
ROM:000001BC                 BL      sub_2B0
ROM:000001C0                 LDRB    R0, [R11,#0x10]
ROM:000001C4                 BL      sub_2B0
ROM:000001C8                 LDR     R1, =(loc_23C - 0x1D4)
ROM:000001CC                 ADD     R1, PC, R1
ROM:000001D0
ROM:000001D0 loc_1D0                                 ; CODE XREF: sub_14C+98
ROM:000001D0                 LDRB    R2, [R1]
ROM:000001D4                 CMP     R2, R0
ROM:000001D8                 BEQ     loc_204
ROM:000001DC                 CMP     R2, #0xFF
ROM:000001E0                 ADDNE   R1, R1, #4
ROM:000001E4                 BNE     loc_1D0
ROM:000001E8                 MOV     R0, #0xEE ; 'e'
ROM:000001EC                 BL      sub_300
ROM:000001F0
ROM:000001F0 loc_1F0                                 ; CODE XREF: sub_14C+5C
ROM:000001F0                                         ; sub_14C+6C ...
ROM:000001F0                 CMP     R12, #0xE4 ; 'S'
ROM:000001F4                 BLNE    sub_100
ROM:000001F8                 LDR     R0, =0xE0000468
ROM:000001FC                 LDRB    R0, [R0]
ROM:00000200                 LDMFD   SP!, {R1,R2,R11,R12,PC}
ROM:00000204 ; ---------------------------------------------------------------------------
ROM:00000204
ROM:00000204 loc_204                                 ; CODE XREF: sub_14C+8C
ROM:00000204                 LDR     R1, [R1]
ROM:00000208                 TST     R1, #0xFF00
ROM:0000020C                 BEQ     loc_234
ROM:00000210                 TST     R1, #0x8000
ROM:00000214                 BNE     loc_22C
ROM:00000218                 MOV     R0, #0xE4 ; 'S'
ROM:0000021C                 CMP     R12, R0
ROM:00000220                 BNE     loc_22C
ROM:00000224                 BL      sub_300
ROM:00000228                 B       loc_1F0
ROM:0000022C ; ---------------------------------------------------------------------------
ROM:0000022C
ROM:0000022C loc_22C                                 ; CODE XREF: sub_14C+C8
ROM:0000022C                                         ; sub_14C+D4
ROM:0000022C                 MOV     R0, #0xE0 ; 'a'
ROM:00000230                 BL      sub_2F4
ROM:00000234
ROM:00000234 loc_234                                 ; CODE XREF: sub_14C+C0
ROM:00000234                 MOV     R1, R1,LSR#16
ROM:00000238                 ADD     PC, PC, R1
ROM:00000238 ; End of function sub_14C


400000xx looks like it's the SNES I/O.
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 02/26/12 04:18 AM
Oh, and the command table at 23c as 32-bit words. The last byte is the command number from the '816 to match, the rest is an offset that finally gets jumped to at 234.

Code:
ROM:0000023C dword_23C       DCD 0x3A400F1           ; DATA XREF: sub_14C+80
ROM:0000023C                                         ; ROM:off_8BC
ROM:00000240                 DCD 0x41800F2
ROM:00000244                 DCD 0x48800F3
ROM:00000248                 DCD 0x4A800F4
ROM:0000024C                 DCD 0x4B400F5
ROM:00000250                 DCD 0x4E800F6
ROM:00000254                 DCD 0x17480A0
ROM:00000258                 DCD 0x17880A1
ROM:0000025C                 DCD 0x18080A2
ROM:00000260                 DCD 0x19080A3
ROM:00000264                 DCD 0x1B080A4
ROM:00000268                 DCD 0x1CC80A5
ROM:0000026C                 DCD 0x1E852A8
ROM:00000270                 DCD 0x1F441A9
ROM:00000274                 DCD 0x2404EAA
ROM:00000278                 DCD 0x250C4AB
ROM:0000027C                 DCD 0x25CCFAC
ROM:00000280                 DCD 0x2684DAD
ROM:00000284                 DCD 0x27848AE
ROM:00000288                 DCD 0x2804FAF
ROM:0000028C                 DCD 0x2A455B0
ROM:00000290                 DCD 0x2EC53B1
ROM:00000294                 DCD 0x30445B2
ROM:00000298                 DCD 0x31C6BB3
ROM:0000029C                 DCD 0x3242EB4
ROM:000002A0                 DCD 0x3586BB5
ROM:000002A4                 DCD 0x3602EB6
ROM:000002A8                 DCD 0x39C20B7
ROM:000002AC                 DCD 0x485200FF
Posted By: etabeta78 Re: SNES: ST-0018 emulation research - 02/26/12 06:37 AM
@byuu: you might want to notice that MAME/MESS source allow to compile a nice tool "unidasm.exe" that, when you run

unidasm.exe 0xf3.bin -arch arm

disassembles for you the content of the ROM
Posted By: Vas Crabb Re: SNES: ST-0018 emulation research - 02/26/12 12:15 PM
Originally Posted By MESSfan
pretty clean for a boy's room

That's so hypocritical, considering you're the first to cry sexism when anyone makes a comment about women, even if it isn't insulting.
Posted By: byuu Re: SNES: ST-0018 emulation research - 02/28/12 02:15 AM
Well, I'm stumped. I have the ARMv3 core implemented enough that it never hits an invalid op.

Emulates F1 (test), F2 (test), AA (board upload), and F3 (checkmate test.) But F3 tells the game checkmate has occurred immediately when you start a new game. Making this the most powerful Shogi AI ever, I guess.

If there are any ARM experts here willing to go over the core and look for bugs, I'd *really* appreciate it, because I am stumped.

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

Known missing stuff:
* MUL/DIV
* SPSR stuff (I always actually use CPSR for flags, except the ops where it lets you pick one.)
* SWI

Partially implemented stuff:
* shifter carry out (*way* too damn complicated for me.)

To use this, you need:
* compiled binary from this source (ARM core in snes/chip/armdsp)
* ST0018 ROMs (byuu.org/temp/st0018-20120225.tar.bz2)
* Hayazashi Nidan Morita Shougi 2.sfc
Rename 0xf3.bin to st0018.rom, 0xf4.bin to st0018d.rom, put them in with the SFC file in the same folder.
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 02/28/12 04:14 AM
Alright, I'll try to hook it up in MESS after work tomorrow and see how it behaves.
Posted By: byuu Re: SNES: ST-0018 emulation research - 02/28/12 01:03 PM
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.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 02/28/12 01:33 PM
Originally Posted By byuu
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.


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.
Posted By: byuu Re: SNES: ST-0018 emulation research - 02/28/12 03:00 PM
> 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 laugh

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.
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 02/28/12 03:30 PM
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" smile
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/01/12 10:38 PM
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
Posted By: Lord Nightmare Re: SNES: ST-0018 emulation research - 03/01/12 11:00 PM
Does it have a co-coprocessor type deal or something on-die which can set d2?

LN
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/01/12 11:39 PM
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).
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/01/12 11:52 PM
Fuck it, I'm hooking it up in MESS as soon as I get home.
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/01/12 11:54 PM
Oh, also, if it's 26-bit v3 code running it in an ARM7 core will produce incorrect results.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/02/12 12:12 AM
> 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.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/02/12 05:18 AM
Welp, I've got everything hooked up, I just need to, erm, dump the ROMs off of my legally-owned cartridge and I'll be good to go.

EDIT: I'll bite, how the fuck do I regenerate the driver list in our godawful new build system?
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/02/12 05:53 AM
Hangs on "TRANSMIT WAIT":

Code:
Soft reset
Unknown ST0018 write from ARM: 4000002c = 00000002 (& ffffffff)
Unknown ST0018 write from ARM: 40000020 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000024 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000028 = 00000000 (& ffffffff)
ST0018: ARM state read
ST0018: ARM state read
Unknown ST0018 write from ARM: 40000020 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000024 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000028 = 00000000 (& ffffffff)
ST0018: ARM state read
Unknown ST0018 write from ARM: 40000020 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000024 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000028 = 00000000 (& ffffffff)
ST0018: ARM state read

...(repeats lots of times)...

ST0018: CPU status read
ST0018: CPU status read
ST0018: ARM state read
Unknown ST0018 write from ARM: 40000020 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000024 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000028 = 00000000 (& ffffffff)
ST0018: CPU status read
ST0018: CPU status read
ST0018: ARM state read
Unknown ST0018 write from ARM: 40000020 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000024 = 00000000 (& ffffffff)
ST0018: CPU status read
Unknown ST0018 write from ARM: 40000028 = 00000000 (& ffffffff)
ST0018: CPU status read
ST0018: ARM state read
ST0018: CPU status read
Unknown ST0018 write from ARM: 40000020 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000024 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000028 = 00000000 (& ffffffff)
ST0018: CPU status read
ST0018: ARM state read
ST0018: CPU status read
Unknown ST0018 write from ARM: 40000020 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000024 = 00000000 (& ffffffff)
Unknown ST0018 write from ARM: 40000028 = 00000000 (& ffffffff)


CPU never seems to write anything to the ARM, just read it. What do?
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/02/12 06:01 AM
At reset, you should see the CPU writing #$00, #$01, #$00 to $3804 to reset the ARM CPU. You can basically ignore that for all it's worth for now. $3804 needs to return d7 set.

You should then see it write #$f1 to $3802. If it's not doing that, then we are hitting a CPU emulation bug in MESS.

In which case ... how insane would it be to hook the MESS ARM core into bsnes? As I assume the bsnes CPU core into MESS would be even harder smirk

Apologies but I'm about to sleep for tonight, have to get up in a few hours for work, and I'll be on then.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/02/12 06:11 AM
Originally Posted By byuu
At reset, you should see the CPU writing #$00, #$01, #$00 to $3804 to reset the ARM CPU.


I don't - at least I don't think, and I can't check since I'm posting from bed, but I sincerely doubt an ARM issue would prevent the 65816 from *ever* issuing a write to the ARM. I'll take a look tomorrow evening.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/02/12 06:12 PM
As long as you have $3804 returning d7 set, you are correct. There doesn't even need to be an ARM CPU core there; the CPU will write #$f1 to $3802, which should set status bit d3 until the ARM reads it from 40000010.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/02/12 06:19 PM
Originally Posted By byuu
As long as you have $3804 returning d7 set, you are correct. There doesn't even need to be an ARM CPU core there; the CPU will write #$f1 to $3802, which should set status bit d3 until the ARM reads it from 40000010.


Why would $3804 return D7 set? I seem to recall D7 is bridge.ready or something. I don't recall seeing anywhere that you initialize bridge.ready, so I initialized it to false in my code. Are you somehow inadvertantly relying on an uninitted bool defaulting to true?
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/02/12 06:29 PM
It's more likely a mapping issue if writes aren't making it to the ST-0018.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/02/12 06:56 PM
Originally Posted By R. Belmont
It's more likely a mapping issue if writes aren't making it to the ST-0018.


I shouldn't have one because I'm redirecting all writes between address $3800 and $38FF inside the write handlers for the $00-$2F bank, the $30-$3F bank, and the $80-$BF bank.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/02/12 08:33 PM
Well, fuck:

http://board.byuu.org/viewtopic.php?p=57219#p57219

> Why would $3804 return D7 set?

d7 is the "ARM ready" flag. It is set in registers.hpp:Bridge::unsigned operator(). The flag is actually set to true inside ARM::enter(), after the reset phase completes.

If you set $3804.d0 to 1, it disables the ARM CPU. When you set it back to 0, the chip resets itself and then after it's done, will set the d7 flag to ready again. The chip is enabled at power-on, it does not need to be turned on manually.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/02/12 09:09 PM
That explains it. Thanks for the info! smile
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/06/12 05:58 AM
http://byuu.org/temp/bsnes_v086r16.tar.bz2



Credit goes to Cydrak for finding the bugs: carry flag on subtract was incorrect, and status.d2 is a timer set via 0x400000(20,24,28.)

Still working out the final details: we're not certain how the timer works, we don't know what 0x4000002c does, and there are almost certainly still logic errors in the ARM core, but the game is fully playable now.

So ... that does it. 100% compatibility with every official game. All of them have been tested. No (known) bugs and no hacks.

I wish the last game was more exciting, but what can you do?
Posted By: Robbbert Re: SNES: ST-0018 emulation research - 03/06/12 06:27 AM
Excellent work! smile
Posted By: etabeta78 Re: SNES: ST-0018 emulation research - 03/06/12 06:50 AM
Congrats, byuu!
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/06/12 01:47 PM
Originally Posted By byuu
Credit goes to Cydrak for finding the bugs: carry flag on subtract was incorrect, and status.d2 is a timer set via 0x400000(20,24,28.)


I suggested to you just the other night on AIM that you were missing some kind of periodic timer.

I'm considerably demotivated now. Someone else can spend their time adding ST-0018 support to the SNES driver in MESS. I'm going to spend the time I would have spent doing that catching up on Minecraft modding where people actually appreciate what I do.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/06/12 07:45 PM
You certainly did mention it before then.

Sorry, I was meaning that Cydrak hooked it up in such a way as to get the game running, not that he was the first to suggest it.

I greatly appreciate your help all the same on this chip.
By all means, please don't hesitate to ask if you have something you'd like me to look at. I'm fairly good at analyzing patterns, but not so good with higher-order math.

The most important part is that it works now laugh
Still plenty left to do, so we're going to keep researching.
Next step is to corrupt the stack to execute our own code.
Posted By: Stiletto Re: SNES: ST-0018 emulation research - 03/06/12 09:25 PM
Congratulations, byuu.
Posted By: Sune Re: SNES: ST-0018 emulation research - 03/06/12 10:00 PM
*Achievement unlocked: 100% compatibility*

Someone should come up with some kind of prize or award for this!

Congratulations byuu, and good on you for sticking to your principles.

I suppose the big question is, what are you going to do now? lol
Posted By: Stiletto Re: SNES: ST-0018 emulation research - 03/06/12 10:57 PM
Originally Posted By Sune
*Achievement unlocked: 100% compatibility*

Someone should come up with some kind of prize or award for this!


Eternal souls... and a tasty pudding snack.
http://www.overclocked.org/OCoffer.htm

- Stiletto
Posted By: mudlord Re: SNES: ST-0018 emulation research - 03/07/12 03:19 AM
Bravo, byuu, bravo. laugh
I read that you are looking at ARM stuff to work out the final bugs..
Have you tried Meteor? (the new GBA emulator which is FOSS)
Its core is a nice modular design which might suit your researching needs.

Originally Posted By Just Desserts
I'm going to spend the time I would have spent doing that catching up on Minecraft modding where people actually appreciate what I do.


Same here.
Kinda ironic that working in cryptography, and software RE has people with more common decency, than in emulation. Too much people whining about how things are done, and people's egos.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/07/12 06:33 AM
I told you he would stop by :P
Posted By: mudlord Re: SNES: ST-0018 emulation research - 03/07/12 10:31 AM
How amazing.
I tried to be civil and this?
Posted By: etabeta78 Re: SNES: ST-0018 emulation research - 03/07/12 10:44 AM
Originally Posted By mudlord
and this?


"this" what?
Posted By: mudlord Re: SNES: ST-0018 emulation research - 03/07/12 10:55 AM
I tried to be respectful to byuu, and as usually, he acts the same way he does over the past 7 years.

With complete disregard of what I said AND claiming that I came here to troll him. What BS. I came here mainly for MG's N64's work and for testing it. not for pestering some person which has wanted me dead for so long.

Heck, I made peace with MG, so all is well there. And now byuu refuses the same white flag?
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/07/12 01:03 PM
Unless byuu originally posted something else and then edited it I don't see him making any such claims.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/07/12 08:21 PM
Originally Posted By R. Belmont
Unless byuu originally posted something else and then edited it I don't see him making any such claims.


Originally Posted By byuu
I told you he would stop by :P


Apart from the credit thing I have no particular issue with byuu, but this does seem overly snarky in response to a genuinely helpful suggestion. Would, "Thanks for the suggestion, I'll take a look at the core and see if I can find any remaining ARM bugs in my core," have been too much to ask for?
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/07/12 08:30 PM
byuu suggested previously that mudlord would Google himself and come post here. mudlord did indeed put in an appearance. I fail to see how "I told you he would stop by" is a capitol offense in that context.

Please take this IRC-style pointless bickering over to IRC where it belongs.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/07/12 08:40 PM
We're finalizing some issues with the ARM core, and then I'll get a document up explaining the register interface.

But for now: it seems important to emulate unaligned byte read shifting in order for the AI threat detection to work properly. Cydrak's attempting to perform a stack corruption to execute custom code to determine how the timer works.
Posted By: Just Desserts Re: SNES: ST-0018 emulation research - 03/07/12 09:11 PM
Originally Posted By byuu
But for now: it seems important to emulate unaligned byte read shifting in order for the AI threat detection to work properly. Cydrak's attempting to perform a stack corruption to execute custom code to determine how the timer works.


Thanks for the information that we already knew about and emulate in our ARM core, I guess? Seriously, there's a reason why I keep vehemently urging you to stop re-inventing the wheel with ARM. It's a finicky CPU and ours is already well-debugged.

Edit: Put it this way, why are you so hell-bent on doing it yourself? Bereft of any better explanation, I'm going to guess it's because you're paranoid about inheriting other peoples' bugs and other peoples' inaccuracies, as if you're the first person to write an accurate CPU core, as if we're all just blithering idiots and MAME is able to self-emulate with our ARM9 core by pure happenstance. It's ridiculous and mildly insulting.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/07/12 09:15 PM
> Thanks for the information that we already knew about and emulate in our ARM core, I guess?

My understanding was the exact behavior differed between ARM revisions and implementations, so I thought it might prove pertinent to share that this game relies on it. Especially as the MESS cores look like a 26-bit variant, and a more modern ARMv4+ variant. (I am aware they are otherwise BC.)

Sorry, I'll stop bothering you then.

> Seriously, there's a reason why I keep vehemently urging you to stop re-inventing the wheel with ARM. It's a finicky CPU and ours is already well-debugged.

For the same reason you won't use my SNES emulation inside MESS (which I've offered), I can't just take MESS' core and plop it into my emulator. The coding style is fundamentally incompatible (I implement cycle granularity with cooperative threads, and not with state machines.) That's even discounting the GPL licensing issues involved.

> as if you're the first person to write an accurate CPU core, as if we're all just blithering idiots and MAME is able to self-emulate with our ARM9 core by pure happenstance

I could say the same when you don't use my CPU/PPU/SMP/DSP cores in MESS.

Nothing could be further from the truth. You are taking what I've said out of context into the absurd.

I write emulators because I want to personally learn how they work. Not because I like taking pre-made pieces and gluing them together. If I wanted to do that, I'd write a Genesis emulator :P

You really are being way too hostile. My only intent here is to share resources and help each other. I never meant any disrespect.
Posted By: Haze Re: SNES: ST-0018 emulation research - 03/07/12 10:06 PM
Considering the amount Byuu has *given* to emulation (we'd still be in the dark ages for SNES otherwise) I think he's entitled to write his own cores, post his own findings, and do whatever else he pleases.

His methods seem to work well, bSnes is lightyears ahead of *anything* in MAME or MESS, and as he says, and while people writing emulators for other platforms are choosing not to share their findings, or make their development process visible instead Byuu is showing his thought process and developing everything in a very public way.

The best way to fully understand anything is to do it yourself. The best thing you can do as you're working out how something works is to share your findings (and code) with others (even if they end up confirming what was already know) Byuu does both of these, which makes his work much more important and much more useful than a lot of work done in emulation.

I fail to see an issue.

As an added bonus, people also have a choice of cores to use, maybe somebody would want to use Bsnes as the basis of their own arcade emulator?
Posted By: netol Re: SNES: ST-0018 emulation research - 03/08/12 01:05 AM
Congratulations and big thanks byuu.
Posted By: mudlord Re: SNES: ST-0018 emulation research - 03/08/12 06:03 AM
Originally Posted By byuu
I write emulators because I want to personally learn how they work. Not because I like taking pre-made pieces and gluing them together. If I wanted to do that, I'd write a Genesis emulator :p


That is not what we meant at all. What I meant was, MESS and co have well developed cores and are quite stable, so I don't see the harm of looking at it for a guide/documentation.

We never suggested to use it outright.
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/08/12 01:09 PM
I'd also suggest that given nobody's worked out the exact timings of the Genesis that a byuu Genesis emulator would be interesting smile
Posted By: etabeta78 Re: SNES: ST-0018 emulation research - 03/08/12 01:16 PM
weren't there ongoing progresses at spritemind with Eke and friends?
Posted By: Haze Re: SNES: ST-0018 emulation research - 03/08/12 01:33 PM
not sure anything was ever concluded.. there were wacky edge-cases with dma during blanking periods causing less sprites to be displayed and crap like that (mickey mania) etc. too.

timings in the current code are very, very wrong, I don't even attempt to emulate DMA speeds correctly, and my sprite masking code is also very wrong based on current findings.

I don't think there are any open genesis emulators which do it properly and my current code is Zsnes level for the MD at best ;-)

What would be more interesting to me is if Byuu started working with MESS to bring his level of SNES accuracy into MESS, but with the good performance he has (yes I know some will laugh, but comparatively it is, the MESS driver is slow even in normal cases)
Posted By: etabeta78 Re: SNES: ST-0018 emulation research - 03/08/12 01:40 PM
we would need: 1. cothread to keep CPU sync'd as they need 2. pixel-based PPU code in place of current scanline-based code
while a few bugs in current MESS are due to me doing something subtly wrong with the scanlines (I still haven't managed to track down SMW bg corruption at the end of the first world), issue 1. is the source of at least half of current bugs we have (as fiddling with CPU speeds shows clearly)

byuu already offers his source as reference and he has helped a lot in the past for specific issues we had (as messnew.txt shows)
I'm not sure what he should do more than this
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/08/12 01:44 PM
bsnes gets the performance it does have[1] by being architecturally hardcoded for the SNES. You can't be super-accurate, perform well, and general to all hardware.

Anyway, this is now way off-topic.

[1] Whatever that is - the Linux version is about 15-20 FPS on my 4.7 GHz i7. I assume it's not that bad on Windows.
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/08/12 05:53 PM
> I'd also suggest that given nobody's worked out the exact timings of the Genesis that a byuu Genesis emulator would be interesting

While there are some great Genesis games, the overall Genesis scene is very unappealing to me.

It's not a secret: I'm not spectacular at reverse engineering. I succeed more as a project motivator. Find people who also want something done, and ask them to help. And importantly, do as much work as I can as well.

But in the Genesis scene, 4:5 emulators are closed source. The authors are all great people (Steve and Aamir are really cool people), but I don't want to have to ask every single question. I got into the SNES scene in part because it was totally open at the time.

> we would need: 1. cothread to keep CPU sync'd as they need 2.

To be fair, you have that now, right? If you're trying not to use them in the SNES CPU, I can promise it will be painful. You can be in the middle of an opcode, and break out in the middle of a cycle or the middle of a DMA sequence triggering in the middle of that, and in the middle of a synchronization event inside the DMA of that.

> [1] Whatever that is - the Linux version is about 15-20 FPS on my 4.7 GHz i7. I assume it's not that bad on Windows.

It's not that bad on Linux, either. I get about 100fps with a 4.4GHz i7 (200 with scanline rendering, 300-400 with the hacked up cores.) The absolute most demanding special chips drop me down to 60fps.

I'm guessing your card is reporting that it has a 30-bit texture available and is doing software conversion back to 24-bit. Try changing away from OpenGL to X-video.
I need to get an Xlib function ready to detect actual display depth.

...

As far as overall performance, it could be a lot better. Probably 3x faster at this point in its most optimized form. But I'm going for source readability over speed.

For one instance, if a register is ten bits, I use a uint10 type. Behind the scenes, that's a unsigned int that gets masked to ten bits on assignment operations. Most of the time you don't need to mask, so it does add extra overhead.

I use threads everywhere for consistency, but they don't make sense when you have two chips that share a huge piece of RAM. Idle loop skipping on DSPs would vastly increase their speed, too.

I've always been willing to help write a more efficiency focused emulator, but I won't do it alone. I don't have enough time for that.
Posted By: R. Belmont Re: SNES: ST-0018 emulation research - 03/08/12 06:03 PM
Yeah, my card does support 30-bit RGB. Can't bsnes just ignore that and use 24-bit? smile
Posted By: byuu Re: SNES: ST-0018 emulation research - 03/08/12 06:07 PM
Yes, it can. I will take care of this for the next release.
© Forums