Home Page Forums Other Emulator Message Boards Audio Overload AO SDK release 1.0 available

Hmm. That modification doesn't seem to have any effect that I can notice - ARMWrestler still passes and everything that was broken before still is.

I don't really see anything odd in DP instructions. There are several other obscurities that don't look right, no sane compiler would make use of them but perhaps some hand-crafted assembly?
- Block transfer will always load the new value from memory over any base writeback. Easiest way to fix this is to modify lines 1638 & 1665 to check for presence of rb in bit mask. If it's there, the writeback should not happen.
- Block transfer store does indeed add +12 to stored R15. There's a log to catch that in the code but no actual addition takes place?
- Block transfer store with base writeback will store either unmodified base, if it's the very first register on the list, or fully modified in any other case. That by the way means you need to check the mask in correct order - and that is R0 first, R15 last. Decrementing transfers actually happen bottom to top beacuse of that.
- I'm quite puzzled as to how PSR Transfer is supposed to work. There are tons of variables in that procedure, named "newval", actualy holding the old value, then being refreshed, and then not used? Lines 1202 & 1205 - is this correct?

The problem we're going to have here is that I didn't write most of the ARM-mode code so I don't understand it either. ARM7 started as a fork of MAME's ARM6 core written for PinMAME. I adapted it to normal MAME/MESS and MG and I added the Thumb support and did a ton of bugfixing (we started off with 1 GBA game running and now almost the entire Good* set at least boots).

PSR Transfer is correct in all cases I've encountered it, but it's rarely used.

Block transfer store is not my code, but I see R15 getting +12 at line 1623. I don't quite understand the rest of what you're trying to say regarding the base writeback.

Right. There is +12/-12 pair in the function above... Again, not exactly my coding style.
PSR transfers are rare, true, and this is exactly why it needs to be re-checked. Any frequently used instruction being wrong would crash the emu right away. I'm browsing .122 sources w/o patches of any kind, and I have code that looks like this:

(...)

if (insn & 0x00010000)
{
newval = (newval & 0xffffff00) | (val & 0xff);
}
if (insn & 0x00020000)
{
newval = (newval & 0xffff00ff) | (val & 0xff00);
}


(...)

// force valid mode
newval |= 0x10;

//Update the Register
SET_REGISTER(reg, val);

//Switch to new mode if changed
if( (val & MODE_FLAG) != oldmode)
SwitchMode(GET_MODE);

I belive it's supposed to be newval in that SET_REGISTER, ane the line below.

As for base writebacks in block transfer - as I said, this doesn't look right but should not be happening in any sane code.
The problem is when you store the base register too and writeback is specified. If the base is on the list it needs to be stored already modified by writeback. Unless it's the first register on the list, then it's stored as-is.

Good catch on the PSR transfer, that was definitely wrong.

The two instances of "R15 -= 4; // SJE: I forget why I did this" looked suspect - I commented them out and Buffy for the GBA no longer reboots when you press START, but the Sega DSF sound driver goes berzerk and crashes so I guess there's a matching bug someplace else.

I don't suppose you could just send me your ARM emulator and I could hook it up and run parallel traces? I've used private source from a number of people for reference on various projects and not leaked or misused any of it.

Well... I suppose. How good is your Polish? Because I code for myself and I don't name variables, procedures or make comments in English unless the source is to be open from start And trust me, it's not very feasible to translate all that now.

Please also keep in mind this is my second attempt at ARM - the first one got so messed up I just started again clean with more DC and less general emulation in mind. In other words: I never got to implement opcodes that aren't part of DC programs. Not much point in doing so as it's better to catch missing/unemulated instruction than write a procedure and never get to test it.
In that aspect it will be quite a task to get my code working with anything MAME-related. It could be used as some point of reference but not much more I'm afraid.

Still interested?

EDIT: That -4 code probably makes up for prefetch offset on R15. You need to have it correct on both write and read. My code is constructed in a bit different way - I add +4 to PC the moment I fetch another opcode. All other code accounts for it. This is actually pretty elegant solution, almost like the hardware does it. I don't correct reads, rather my writes/jumps/interrupts transfer are all aware of the fact that R15 is ahead of the code.

I ported a large GUI app with comments entirely in Japanese once, so this oughta be easy. Also, it wouldn't be targetting MAME, I'd just want to hook it up in AO/AOSDK. And the lack of support for opcodes Sega doesn't use actually makes it simpler (less code to deal with).

Oh, and ZiNc has a fair amount of Polish variables and comments and I've handled it OK :-) PM me and we can set something up.

You didn't mention that you ported the god-awful code that is/was Audio Overload once too... though having said that, I never sent you the AO1.x code. Now that was truly something to behold.

AO's not as bad as you think. I've dealt with far worse :-)

Just so people know we haven't completely stalled out, I was able to successfully compile AO's DSF support using Makaron's ARM7 interpreter (Deunan writes gorgeous code, it was no trouble at all to work with even with Polish function names) and to probably nobody's surprise it's sending correct DISDL/DIPAN values to the AICA. So we'll see what we can see now :-)