Previous Thread
Next Thread
Print Thread
Page 51 of 55 1 2 49 50 51 52 53 54 55
Re: AO SDK release 1.4.8 available [Re: Knurek] #48481 03/02/09 10:50 PM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
Today's Saturn haul:

Real Mahjong Adventure - Umi he Summer Waltz (1998)(Seta)
Rox (1998)(Altron)
Tenant Wars (1998)(KID)
Tokimeki Mahjong Graffiti - Toshishita no Tenshi-tachi (1996)(Sonnet)
Virtual Mahjong (1998)(Micronet)
Yoshimura Shougi (1998)(Konami)

Re: AO SDK release 1.4.8 available [Re: Knurek] #48482 03/03/09 04:54 AM
Joined: Sep 2007
Posts: 56
K
kingshriek Offline
Member
Offline
Member
K
Joined: Sep 2007
Posts: 56
Originally Posted By Knurek

Shining Wisdom (1995)(Sonic! Software Planning)(Sega) minissf repack (shaves 4 MB smile ).

kingshriek, the tracks still pop at beginning, even when using the latest ssfmake.py. Another bug in DSP RAM zeroing or something non related?

http://ssf.hcs64.com/


Turns out to be a legitimate bug in the driver when it initializes DSP RAM. I noticed something was amiss when I logged DSP reads from DSP RAM:
Code:
DSP->READ : SCSPRAM[54418]=0006
DSP->READ : SCSPRAM[5441A]=6000
DSP->READ : SCSPRAM[5F218]=0006
DSP->READ : SCSPRAM[5F21A]=6000
DSP->READ : SCSPRAM[56ACA]=6000
...


These should all be 0x6000 if the driver is initializing DSP RAM properly.

Next, I logged CPU writes to DSP RAM to see what exactly was being written here:

Code:
CPU->WRITE @ 02B20: SCSPRAM[50000]=66000
CPU->WRITE @ 02B22: SCSPRAM[50004]=66000
CPU->WRITE @ 02B24: SCSPRAM[50008]=66000
CPU->WRITE @ 02B26: SCSPRAM[5000C]=66000
CPU->WRITE @ 02B20: SCSPRAM[50010]=66000
...


And here we see values of 0x66000 being written in 32-bit chunks which agrees with the DSP seeing 0x0006 occasionally since it reads in 16-bit chunks. I logged the program counter so now it was time to disassemble the problematic code:

Code:
0x00002B0A: 0x303C 0x6000                       MOVE.W   #0x6000,D0
0x00002B0E: 0x2603                              MOVE.L   D3,D3
0x00002B10: 0x6718                              BEQ.S    *+0x1A [0x2B2A]
0x00002B12: 0x2445                              MOVEA.L  D5,A2
0x00002B14: 0xE88B                              LSR.L    #4,D3
0x00002B16: 0x6712                              BEQ.S    *+0x14 [0x2B2A]
0x00002B18: 0x5343                              SUBQ.W   #1,D3
0x00002B1A: 0x3603                              MOVE.W   D3,D3
0x00002B1C: 0x670C                              BEQ.S    *+0xE [0x2B2A]
0x00002B1E: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B20: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B22: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B24: 0x24C0                              MOVE.L   D0,(A2)+
0x00002B26: 0x51CB 0xFFF6                       DBF      D3,*-0x8 [0x2B1E]
...


A quick glance at the disassembly shows that the DSP RAM init value is in register D0 (0x6000 is the DSP's floating point representation of zero) and the DSP RAM address is in A2. The values are written 32-bits at a time in a somewhat unrolled loop with D3 as the loop counter. The problem is clear - the init value in D0 is set with a MOVE.W instruction which only writes the 16 lower order bits of the register. The upper 16 bits is uninitialized data that just happens to have the value 0x0006 at runtime.

Fixing the code isn't hard. We just need to replace the MOVE.L instructions in the init loop with MOVE.W's so the DSP RAM is initialized in 16-bit (where we have a known value) chunks instead. The loop counter will need to be increased by a factor of 2 so the same amount of data is written.

Code:
0x00002B0A: 0x303C 0x6000                       MOVE.W   #0x6000,D0
0x00002B0E: 0x2603                              MOVE.L   D3,D3
0x00002B10: 0x6718                              BEQ.S    *+0x1A [0x2B2A]
0x00002B12: 0x2445                              MOVEA.L  D5,A2
0x00002B14: 0xE68B                              LSR.L    #3,D3
0x00002B16: 0x6712                              BEQ.S    *+0x14 [0x2B2A]
0x00002B18: 0x5343                              SUBQ.W   #1,D3
0x00002B1A: 0x3603                              MOVE.W   D3,D3
0x00002B1C: 0x670C                              BEQ.S    *+0xE [0x2B2A]
0x00002B1E: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B20: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B22: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B24: 0x34C0                              MOVE.W   D0,(A2)+
0x00002B26: 0x51CB 0xFFF6                       DBF      D3,*-0x8 [0x2B1E]
...


Shorthand binary patch:
Code:
2B14: E88B --> E68B
2B1E: 24C0 --> 34C0 (x4)


Updated sw.ssflib:
http://h1.ripway.com/kingshriek/sw.ssflib

BTW, the tracks pop in the beginning in the actual game itself (tested out on a real Saturn) so the SSF set is technically more accurate as is.

Re: AO SDK release 1.4.8 available [Re: kingshriek] #48509 03/04/09 05:03 PM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
Thank you for looking at the stuff. Finally they play okay. smile

new Saturn rips:

Mezase Idol Star!! Natsuiro Memories - Mahjong-hen (1996)(Shar Rock)
Virtual Mahjong II - My Fair Lady (1998)(Micronet)
Shining Wisdom (1995)(Sonic! Software Planning)(Sega) - driver patched by kingshriek, finally no pops at track start

http://ssf.hcs64.com/

Re: AO SDK release 1.4.8 available [Re: Knurek] #48510 03/05/09 12:15 AM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
Mysterious plugin guy, if you're reading this somehow, this 2SF file crashes the latest version of vio2sf:

http://www.sendspace.com/file/mxs9fr

Works fine in No$GBA and other emulators.

Re: AO SDK release 1.4.8 available [Re: Knurek] #48512 03/05/09 06:36 AM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
Thank you, everything works now wonderfully. smile

BTW, RB, do check that track and see how many Namco games you can spot being referenced. :P

Also, dsf.hcs64.com was updated today, pretty much everything's streamed except for Nightmare Creatures II (2000)(Kalisto)(Konami). Just wait till you see what format it uses though. :P

Re: AO SDK release 1.4.8 available [Re: Knurek] #48524 03/05/09 09:43 PM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
Oh, one more thing, Mysterious plugin guy: NTR-ANOJ-JPN-0000.mini2sf from Trace Memory [Another Code - Futatsu no Kioku] is not playable by current plugin.

Song has about 5-6 seconds of silence at the beginning, and the current code skips to the next song after only 3 or even less. Any chance to fix that one?

Re: AO SDK release 1.4.8 available [Re: Knurek] #48525 03/05/09 09:55 PM
Joined: Mar 2001
Posts: 16,377
R
R. Belmont Offline OP
Very Senior Member
OP Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,377
XM makes sense if there's also a Sony version - SCE Europe (of course) offers licensed developers an official XM player for I think all of their systems.

Re: AO SDK release 1.4.8 available [Re: R. Belmont] #48561 03/07/09 02:06 AM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
New Saturn rips:

Baroque (1998)(Sting)
Jissen Mahjong (1995)(-)(Imagineer)
Kaitou Saint Tail (1997)(Access)(Tomy)
Mahjong Gakuensai (1997)(Make)
Mahjong Gakuensai DX Zenjitsu ni Matsuwaru Funsenki (1998)(Make)
Mahjong Hyper Reaction R (1996)(-)(Sammy)
Mahjong Kaigan Monogatari - Mahjong-kyou Jidai Sexy Idol-hen (1995)(Micronet)
Mahjong Tenshi Angel Lips (1996)(-)(Syscom)

http://ssf.hcs64.com/

Re: AO SDK release 1.4.8 available [Re: Knurek] #48732 03/13/09 05:41 AM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
Mysterious plugin guy: vio2sf doesn't support _lib tags according to PSF specification:

#CaitSith2:

"I tried similar _lib / _lib2, and it does not seem to be implemented properly, according to the standards.

Proper procedure of _lib loading.

_lib = Main rom with everything required.
mini2sf = patch rom that changes the song. Usually one or two bytes patched.
_lib2, _lib3, etc.. = patch rom that changes other bytes, or loads in other data in place of existing data.

So basically, _lib is loaded first right into ram.
_lib2 is then patched into the memory that _lib takes up. If this would exceed boundaries that _lib took, reallocate the size of _lib.

Then mini2sf is applied on top of _lib, same procedures.

This really should have been implementted into the player even if it wasn't used at the moment. If you need some help, look at the source code of highly advanced. It is implemented there."

Also, vio2sf 0.18 has a severe bug in _lib loading, which makes every set unplayable:

"There's a bug in the xsflib loading code, the default behaviour loads mini2sf first and then overlays the 2sflib on to that.

Since mini2sf have the song select code, and the driver 2sflib has only a constant value for that, what you will get is song 0x00 playing for *all* files.

Adding _vio2sf_loader_type=1 tag to all mini2sf files will fix the situation, but isn't obviously the intended solution."

Re: AO SDK release 1.4.8 available [Re: Knurek] #48970 03/25/09 06:43 PM
Joined: Nov 2003
Posts: 459
K
Knurek Offline
Senior Member
Offline
Senior Member
K
Joined: Nov 2003
Posts: 459
Two new SSF rips, to relieve boredom from all the 2SF reripping:

Tactical Fighter (1997)(TamTam)(Media Rings)
Takuramakan - Tonkoudenki (1996)(Interserv)(Alfa System)(Patra)

http://ssf.hcs64.com/

Page 51 of 55 1 2 49 50 51 52 53 54 55

Moderated by  R. Belmont, Richard Bannister 

Who's Online Now
1 registered members (judge), 207 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,714
Posts114,532
Members4,869
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3