|
Joined: Mar 2001
Posts: 17,217 Likes: 234
Very Senior Member
|
OP
Very Senior Member
Joined: Mar 2001
Posts: 17,217 Likes: 234 |
The u1 ARM7 updates fix the graphics decompression in at least WarioWare (the original one), but it's not all that playable since it relies pretty heavily on the more advanced features of the graphics hardware.
|
|
|
|
Joined: Feb 2008
Posts: 107
Senior Member
|
Senior Member
Joined: Feb 2008
Posts: 107 |
Excerpts from ARM manuals:
ARM7vC: Register R15 holds the Program Counter (PC). When R15 is read, bits [1:0] are zero and bits [31:2] contain the PC.
ARM7TDMI (rev r4p1): Register r15 holds the PC. In ARM state, bits [1:0] of r15 are undefined and must be ignored. Bits [31:2] contain the PC. In Thumb state, bit [0] is undefined and must be ignored. Bits [31:1] contain the PC.
Now I remember why was my code clearing lower 2 bits of PC on write - that was (never finished) attempt to move the masking from reads to writes.
Usually it's clearly stated that any unaligned doubleword address will still set A[1:0] lines and those "might be interpreted" by external memory controller. STR is an exception and all the docs say is: "A word store (STR) should generate a word aligned address. The word presented to the data bus is not affected if the address is not word aligned. That is, bit 31 of the register being stored always appears on data bus output 31." Nothing about lowest two address bits... SWP by the way is said to operate as LDR followed by STR - and I now assume that means any unaligned read will rotate and store will be masked to be aligned (on DC at least).
In short, all transfers except LDR are implementation specific (unaligned memory access can be masked, or happen as it is). I'm aiming for my core to be DC compatible but that in turn might break other systems. It's up to MAME devs what to do with their ARMs, I'd split the core code by CPU generation and memory access handlers by system.
Here's another interesting difference, about R14 when branch link bit is set:
ARM7vC: Note that the CPSR is not saved with the PC.
ARM7TDMI (rev r4p1): Note that the CPSR is not saved with the PC and R14[1:0] are always cleared.
Why is R14 being sanitized if the code is executing in 32-bit (non-Thumb) mode? PC should be aligned then. Or does it mean lower PC bits are not undefined but in fact valid, and in that case (sooner or later) someone is going to write a piece of code relying on that 'feature'.
|
|
|
|
Joined: Dec 1969
Posts: 920 Likes: 3
Senior Member
|
Senior Member
Joined: Dec 1969
Posts: 920 Likes: 3 |
No, definitely not. It should sound like the MP3 only without the staticy part between the intro and the main theme and generally a bit higher quality all around. Do make sure the 16-bit samples are behaving though, those can add scratch if they're wrong-endian. Aargh. Second dumb mistake in one evening. The compiler hadn't picked up all the changed files.
|
|
|
|
Joined: Mar 2001
Posts: 17,217 Likes: 234
Very Senior Member
|
OP
Very Senior Member
Joined: Mar 2001
Posts: 17,217 Likes: 234 |
DK: there are GBA games that jump (deliberately as far as we can tell) to unaligned addresses in both ARM and Thumb modes and expect the CPU to magically save them.
|
|
|
|
Joined: Feb 2008
Posts: 107
Senior Member
|
Senior Member
Joined: Feb 2008
Posts: 107 |
This is proper interrupt handling. It suddenly starts to make more sense once you do remember to set F/I flags where appropriate. Duh, I guess.
diff -Nru old/arm7.c new/arm7.c
--- old/arm7.c 2008-02-15 19:47:10.000000000 +0100
+++ new/arm7.c 2008-02-15 19:47:24.000000000 +0100
@@ -136,13 +136,10 @@
// mode change could've enabled interrups, so we test for those and set
// appropriate flag for the instruction loop to catch
if (ARM7.fiq)
- if (!(sr & ARM7_CPSR_F) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_fiq))
- ARM7.flagi |= ARM7_FL_FIQ;
+ ARM7.flagi |= ARM7_FL_FIQ;
#ifndef ARM7_DREAMCAST
if (ARM7.irq)
- if (!(sr & ARM7_CPSR_I) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_irq) &&\
- (ARM7_CPSR_M (sr) != ARM7_CPSR_M_fiq))
- ARM7.flagi |= ARM7_FL_IRQ;
+ ARM7.flagi |= ARM7_FL_IRQ;
#endif
}
//--------------------------------------------------------------------------
@@ -198,10 +195,10 @@
// (FIQ can interrupt IRQ, but not the other way around)
if (ARM7.fiq)
{
- if (!(sr & ARM7_CPSR_F) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_fiq))
+ if (!(sr & ARM7_CPSR_F))
{
// FIQ
- ARM7_SetCPSR ((sr & 0xffffffc0) | ARM7_CPSR_M_fiq);
+ ARM7_SetCPSR (ARM7_CPSR_MX (sr, ARM7_CPSR_M_fiq) | ARM7_CPSR_F | ARM7_CPSR_I);
ARM7.Rx [ARM7_SPSR] = sr;
// set new PC (return from interrupt will subtract 4)
ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC] + 4;
@@ -211,11 +208,10 @@
#ifndef ARM7_DREAMCAST
if (ARM7.irq)
{
- if (!(sr & ARM7_CPSR_I) && (ARM7_CPSR_M (sr) != ARM7_CPSR_M_irq) &&\
- (ARM7_CPSR_M (sr) != ARM7_CPSR_M_irq))
+ if (!(sr & ARM7_CPSR_I))
{
// IRQ
- ARM7_SetCPSR ((sr & 0xffffffc0) | ARM7_CPSR_M_irq);
+ ARM7_SetCPSR (ARM7_CPSR_MX (sr, ARM7_CPSR_M_irq) | ARM7_CPSR_I);
ARM7.Rx [ARM7_SPSR] = sr;
// set new PC (return from interrupt will subtract 4)
ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC] + 4;
diff -Nru old/arm7.h new/arm7.h
--- old/arm7.h 2008-02-15 19:27:49.000000000 +0100
+++ new/arm7.h 2008-02-15 19:27:49.000000000 +0100
@@ -42,7 +42,8 @@
#define ARM7_CPSR_F (1 << 6)
#define ARM7_CPSR_T (1 << 5)
/** CPSR bit mask for current operating mode. */
-#define ARM7_CPSR_M(x) (x & 0x1f)
+#define ARM7_CPSR_M(x) ((x) & 0x1f)
+#define ARM7_CPSR_MX(sr,x) (((sr) & ~0x1f) | ((x) & 0x1f))
/** Bit combinations for each operating mode. */
#define ARM7_CPSR_M_usr 0x10
#define ARM7_CPSR_M_fiq 0x11
diff -Nru old/arm7i.c new/arm7i.c
--- old/arm7i.c 2008-02-15 19:27:49.000000000 +0100
+++ new/arm7i.c 2008-02-15 19:27:49.000000000 +0100
@@ -1364,7 +1364,7 @@
{
//EMU_BLAD (BLAD_WEWNETRZNY, "BDT: user transfer");
cpsr = ARM7.Rx [ARM7_CPSR];
- ARM7_SetCPSR ((cpsr & 0xffffffe0) | ARM7_CPSR_M_usr);
+ ARM7_SetCPSR (ARM7_CPSR_MX (cpsr, ARM7_CPSR_M_usr));
}
if (ARM7.kod & BIT_L)
@@ -1551,8 +1551,12 @@
logerror("ARM7: G111 / Coprocessor data operation\n"); */
}
else
- {
- ARM7_SetSWI();
- }
+ {
+ uint32_t sr = ARM7.Rx [ARM7_CPSR];
+ ARM7_SetCPSR (ARM7_CPSR_MX (sr, ARM7_CPSR_M_svc) | ARM7_CPSR_I);
+ ARM7.Rx [ARM7_SPSR] = sr;
+ ARM7.Rx [ARM7_LR] = ARM7.Rx [ARM7_PC];
+ ARM7.Rx [ARM7_PC] = 0x00000008;
+ }
}
//--------------------------------------------------------------------------
I've also simplified group 0 decoder for non-Thumb cores, since it's only swap, multiply or data processing/PSR transfer in that case. I can create AO comptabile patch if anyone's interested. EDIT: Oops, silly me. One change went into wrong file, corrected.
Last edited by Deunan Knute; 02/15/08 06:48 PM.
|
|
|
|
Joined: Nov 2003
Posts: 459
Senior Member
|
Senior Member
Joined: Nov 2003
Posts: 459 |
A friend of mine says that using the newest Winamp plugin (it's based on a5a) "most of the instruments sound too short". Noticable in just about every Skies of Arcadia track, especially SOA_369_04_01.minidsf Disregard this post if this is known (maybe it's just the missing DSP reverb stuff).
|
|
|
|
Joined: Mar 2001
Posts: 17,217 Likes: 234
Very Senior Member
|
OP
Very Senior Member
Joined: Mar 2001
Posts: 17,217 Likes: 234 |
Thanks. MAME just got that right recently too. I didn't realize SWI actually locked out hardware interrupts but it does make some sense. I'll take the decoder patch too.
|
|
|
|
Joined: Mar 2001
Posts: 17,217 Likes: 234
Very Senior Member
|
OP
Very Senior Member
Joined: Mar 2001
Posts: 17,217 Likes: 234 |
Knurek: compared to real hardware or to HE? And the DSP reverb is working fine.
|
|
|
|
Joined: Nov 2003
Posts: 459
Senior Member
|
Senior Member
Joined: Nov 2003
Posts: 459 |
I've been told that compared to the OST and playing the GC conversion. I can whip up some comparison samples if you want.
|
|
|
|
Joined: Mar 2001
Posts: 17,217 Likes: 234
Very Senior Member
|
OP
Very Senior Member
Joined: Mar 2001
Posts: 17,217 Likes: 234 |
Not necessary. I have the real game and a real Dreamcast. (Amusingly I can't try Makaron because I only have real GDROMs).
|
|
|
3 members (AJR, Olivier Galibert, 1 invisible),
364
guests, and
6
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,320
Posts121,944
Members5,074
|
Most Online1,283 Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|