Previous Thread
Next Thread
Print Thread
Page 10 of 55 1 2 8 9 10 11 12 54 55
Re: AO SDK release 1.3.2 available [Re: R. Belmont] #37989 02/01/08 10:42 PM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
My point is NOTHING about AICA is well (or at all) documented. It's not SH4 with beautiful doc from Hitach that basically delivers C-like emulator code for the core. Actually the bits of information that are available (including some SEGA manuals I happened to find) are often plain wrong or misleading. I've spent much of my free time doing reasearch on that - reading, coding and finally probing the hardware. So please think twice next time you want to say this is "doing stuff from manuals".

Having said that, I don't really know that much about DSFs. We all did our MOD-players at some point but this is where I stopped (touching a bit of Adlib FM on the way). I can't help you with that but if you have any AICA specific questions I might be of some assistance. To point out few things:

+#define ISEL(slot) ((slot->udata.data[0x20/2]>>0x4)&0x000F)
+#define IMXL(slot) ((slot->udata.data[0x20/2]>>0x0)&0x000F)

This is wrong, I mean the ISEL is bits 0:3 and IMXL is 4:7. At least that's how I have it.
Also after a few tests I've came to conclusion that you cannot re-start the channel to play by setting Key-on to one if it has not been set to zero earlier. Even if it stopped on it's own. Not much point in checking if the AEG is in release phase when turning it on. Slot's KON bit is NOT being reset to zero by hardware at any time. Never ever. All this AEG code needs some reworking, including the co-efficient calculations. But good news is it should still work as it is now - for the time being smile
DSFs will most likely not need it but there are feedback registers on AICA that tell you at what point given channel AE/FE generator is, what phase, and at what sample address. This is mostly used for looping long streams properly. If there is code that reads back AEG status - beware. It's very tricky, actually overflows over zero for long times (> ca. 7sec). Quite frankly there are TONS of those quirks all over AICA (like interrupt priorities) but fortunately no or very little code ever uses that stuff. You will need to sort some of those out for MESS though.

Re: AO SDK release 1.3.2 available [Re: Deunan Knute] #37990 02/01/08 11:04 PM
Joined: Mar 2001
Posts: 16,337
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,337
Well, the nice thing with DSFs is that they decode into a RAM image that you just boot on an ARM attached to an AICA and they play, no intervention necessary. I can post a decoded bin if you want to give it a shot in your own code smile

As far as feedback the manatee.drv reads every slot's LP bit all the time but it doesn't seem like it's used for the sequenced music in DSFs (I imagine that's more useful for streaming stuff off the disc into the AICA's RAM - the SCSP had a similar mechanism used for that reason).

BTW, if I may ask, the Dreamcast BIOS in MESS currently hits a SLEEP instruction almost right away, and I didn't notice any obvious interrupt sources being enabled before then. Is it crashing to indicate it's displeasure or am I just missing something? smile

Re: AO SDK release 1.3.2 available [Re: R. Belmont] #37992 02/02/08 12:24 AM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
If you get that, that is 10: SLEEP; 20: GOTO 10 stuff then most likely you've got some hardware registers wrong. There are several that keep magic values like HW revision - DC BIOS (except DEV maybe) will refuse to boot if it doesn't like what it sees. I can't go through MESS sources right now (but maybe during weekend?) so check if you have:

/** System bus revision number (R). */
#define HOLLY_SB_SBREV 0x005F689C
/** G2 bus version (R). */
#define HOLLY_SB_G2ID 0x005F7880
/** Device ID (R). */
#define HOLLY_ID 0x005F8000
/** Revision number (R). */
#define HOLLY_REVISION 0x005F8004

HOLLY_REJ (HOLLY_SB_SBREV) = 0x0000000b;
HOLLY_REJ (HOLLY_SB_G2ID) = 0x00000012;
HOLLY_REJ (HOLLY_ID) = 0x17fd11db;
HOLLY_REJ (HOLLY_REVISION) = 0x00000011;

All of these are read-only and if memory serves me right BIOS will (on purpose?) try to write to one of those - so make sure you don't let that happen. Those just say "Hello I'm HOLLY chip, rev. 2.42" - that's Dreamcast and newest DEV boxes.

This is not immediately required but since we are here, set:

/** System mode (R). */
#define HOLLY_SB_G1SYSM 0x005F74B0

HOLLY_REJ (HOLLY_SB_G1SYSM) = 0x00002000; // USA
HOLLY_REJ (HOLLY_SB_G1SYSM) = 0x00000800; // JP
HOLLY_REJ (HOLLY_SB_G1SYSM) = 0x00006000; // EU

Read-only as well, this is being latched from external HOLLY pins during power-on reset. Just pick one to match BIOS if you don't want game booting troubles in future.

/** TA FIFO remaining amount (R). */
#define HOLLY_SB_TFREM 0x005F6880

HOLLY_REJ (HOLLY_SB_TFREM) = 0x00000008;

Make it R/O and forget it exists as no code ever bothers to check that anyway - and it still works... smile

Now for connected video-cable - oh, this is fun. Part of the code below is kinda redundant as BIOS will read one (?) place and write the rest, but I can't quite remember the correct order so get all 3 places covered to be sure:

/** Sync pulse generator control. */
#define HOLLY_SPG_CONTROL 0x005F80D0

HOLLY_REJ (HOLLY_SPG_CONTROL) |= (g_kabel << 6); // video-cable code

Use 0 for VGA, 2 for RGB EURO/SCART, 3 for composite/UHF modulator (some docs say 1 is valid too, can't remember for what now).

// This is AICA-visible address space! Add 0x00700000 on SH4 side
#define AICA_AV_CTRL 0x00002c00

AICA_REJ (AICA_AV_CTRL) = (g_kabel << 8) | 0x0001; // same code as above

You'll also (and this I think is the most important place to get it right) need to set it up so that SH4 direct I/O ports will read the same video-cable code. Now this is... tricky. You can try to emulate the I/O and internal pullups and stuff or make a hack. Your choice.

Port A is 16-bits wide and BIOS expects to see ((g_kabel << 8) | 0x0003). Now the tricky part is the lowest 2 bits are some sort of cable connector being plugged detection (or something) and need to behave. BIOS will zero each bit then read back the port register - and expect both of them to be down. In other words, setting 3 - reads out as 3. Setting 1 or 2 (or 0 of course) reads out as zero. This took me day or so, here's my code for reading back (quick translation):

uint32_t w = 0;
(...)

// PDTRA:16
case 12:
// pull-ups not exactly supported
for (int i = 0; i < 16; i++)
{
// in/out bit (every 2nd bit)
if (SH4.PCTRA & (1 << (i << 1)))
w |= SH4.PDTRA & (1 << i);
else
w |= SH4.portA & (1 << i);
}
#ifdef SH4_DREAMCAST
if ((w & 0x0003) != 0x0003)
w &= ~0x0003;
#endif
break;

(...)
return w;

"SH4.portA" is a variable that pretends being Port A input. This is the thing I set with ((g_kabel << 8) | 0x0003).

That reminds me - there's a register SH4 has that is not covered in the manual (actually it seems there are more of those, but that's not important now). It's "Cache and TLB controller" region, register 12 (0xff000030). Add it, make it always return 0x00000080 and BIOS will skip some weird code trying to setup watchdog and some other stuff a retail console is not supposed to have. WEIRD. I strongly suggest you do this if BIOS gives you trouble.
More importantly BSC.RFCR _has_ to be either incremented per read or set to some big enough value (I increment it by 0x20). This is SDRAM refresh counter. Checked only during POST as far as I can tell. This is a must though.

This should get you past POST, though you might experience 10s or so delay if GD-ROM isn't detected (in our case - emulated). I think ARM might be broken but AICA timers must advance - and you will see the logo animation. Assuming you have TA+PVR2 covered, as BIOS uses 3D only (and heavily) and relies on the order-independant transparency much. Hopefully next thing to stop you will be time/date setup screen, which is "almost there" phase.

Re: AO SDK release 1.3.2 available [Re: Deunan Knute] #37993 02/02/08 12:59 AM
Joined: Mar 2001
Posts: 16,337
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,337
Awesome, thank you very very much! That will take a while to digest, but at least it gives me plenty to look at smile

Back in DSF-land the code from 14e4 to 1574 calculates the DISDL/DIPAN values (in manatee.drv 2.50, taken from kingshriek's full Skies of Arcadia rip). I don't see anything wrong ARM-emulation-wise there, but I'll have to see if I can rig it to use VBA's ARM or something instead so I can have comparison values smile

Last edited by R. Belmont; 02/02/08 01:03 AM.
Re: AO SDK release 1.3.2 available [Re: R. Belmont] #37997 02/02/08 10:44 AM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
Haven't looked into MAME ARM code recently but I remember it being somewhat... rough around the edges. Not that I blame anyone, the docs are really lacking. Also most (?) of the devices using that CPU actually have it Thumb-enabled and work mostly in that mode. AICA core has ARM7DI, not TDMI, and (possibly due to compiler?) I've never seen any DC code use Multiply Long instructions, halfwords (16-bit in ARM language) accesses, swaps, software interrupts, or BX jumps. Coprocessor is never used too but that's normal since there isn't one. There are special cases for block transfers where ARM would switch from priviledged mode to user mode but that's also never used (and this is probably still badly broken in MAME).

The rest, especially data processing, must be in top-shape though. Programs will expect correct R15/PC prefetch offsets being added when it's accessed and special cases of barrel shifter operation to be flawless. Be also sure you covered cases where ARM would read/modify/write a single byte in a 16-bit AICA register. In this case AICA will preserve the other byte intact.

Do you still have 16-bit samples wrong? I take it you upload them to SPU RAM by yourself, it's not SH4 doing that?

Re: AO SDK release 1.3.2 available [Re: Deunan Knute] #37998 02/02/08 03:32 PM
Joined: Mar 2001
Posts: 16,337
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,337
It's known that there are data processing gremlins somewhere in our ARM7 core because there are definite CPU-related cockups in some Game Boy Advance games in MESS (in several games it takes the form of the software-mixed sound channels being distorted, and a few actually crash). It's just been a matter of finding simple test cases.

The Sega sound driver points software interrupts to the same "crash/do nothing" routine as the various ARM faults, so clearly they aren't using them. They're BIOS calls on the GBA though and very very heavily used there so I'm sure we emulate them properly anyway.

I haven't looked into the 16-bit samples yet, but as I said earlier DSFs once decoded are simply an image of the 2MB of AICA RAM at 0x00000000. You boot the ARM and it automatically starts playing, so there's no possibility of CPU transfer problems.

Re: AO SDK release 1.3.2 available [Re: R. Belmont] #38003 02/02/08 05:55 PM
Joined: Oct 2002
Posts: 1,017
M
MooglyGuy Offline
Senior Member
Offline
Senior Member
M
Joined: Oct 2002
Posts: 1,017
Originally Posted By R. Belmont
It's known that there are data processing gremlins somewhere in our ARM7 core because there are definite CPU-related cockups in some Game Boy Advance games in MESS (in several games it takes the form of the software-mixed sound channels being distorted, and a few actually crash). It's just been a matter of finding simple test cases.


And in other games - in fact, most of them - it manifests itself in horrifically corrupted tile graphics.

Re: AO SDK release 1.3.2 available [Re: MooglyGuy] #38004 02/02/08 06:13 PM
Joined: Mar 2001
Posts: 16,337
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,337
I'm not convinced that isn't a graphics draw problem in some of the cases.

Re: AO SDK release 1.3.2 available [Re: R. Belmont] #38019 02/03/08 03:18 AM
Joined: Oct 2002
Posts: 1,017
M
MooglyGuy Offline
Senior Member
Offline
Senior Member
M
Joined: Oct 2002
Posts: 1,017
Originally Posted By R. Belmont
I'm not convinced that isn't a graphics draw problem in some of the cases.


Possibly.

In my opinion, someone at some point needs to bring MAME / MESS's cycle-counting for the ARM7TDMI and GBA driver in general in line with that of VBA's. It'd make comparing traces a lot easier.

Re: AO SDK release 1.3.2 available [Re: MooglyGuy] #38025 02/03/08 12:11 PM
Joined: Feb 2008
Posts: 107
D
Deunan Knute Offline
Senior Member
Offline
Senior Member
D
Joined: Feb 2008
Posts: 107
I peeked into arm7core.c but this coding style is so incompatible with me. I tried to look for several problematic cases I had problems with, alas those seem to be taken care of properly.

I do have few suggestions:
- As far as I know TST-class (TST,TEQ,CMP,CMN) instructions never write to Rd, so HandleALU doesn't need to have "else" clause for that. Doesn't matter if Rd is being coded as PC in that case.
- I'm not 100% convinced that the immediate operand shift (I bit = 1) produces new carry value as output. Modify line 1241 to be "sc = GET_CPSR & C_MASK;" and see what happens. This is how I have it, seems to work?

Page 10 of 55 1 2 8 9 10 11 12 54 55

Moderated by  R. Belmont, Richard Bannister 

Who's Online Now
2 registered members (belegdol, Edstrom), 32 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,693
Posts114,287
Members4,865
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3