Archive for the ‘Mame Wip’ Category

Second Round K.O.

Friday, November 22nd, 2013

Fixed a complement by two bug in the YJK table, fixes for good colors from the previous update (screenshot are for Puzzle Star and a bunch of MSX2+ games that uses the feature):

0041

0040

0007

0006

I’ve kludged Puzzle Star to work for now (couldn’t be bothered more) and marked it as working. Next up is adding horizontal scroll to V9958 (used by some MSX2+ games like Space Manbow).

Mode Twelve

Wednesday, November 20th, 2013

Added preliminary YJK and YAE modes (a.k.a. screen 10/11/12) to V9958 video chip, fixes (mostly) colors in Sexy Boom / Puzzle Star (and presumably for the bunch of MSX2+ games/applications that uses it too):

0001

0002

0004

0005

0006

0008

0001

0002

0005

Analogic nostalgia

Thursday, August 29th, 2013

Yesterday I’ve added a preliminary YUV420 converter to PowerVR2, this fixes FMV movie playback in several games for both Sega Naomi and Sega Dreamcast systems.

It still hangs badly on some games (examples: Naomi Death Crimson OX, DC Tetris 4D), guess that the FIFO needs to be timer-ized in some way.

Te lo dò io il Brasile

Thursday, February 14th, 2013

Cracked a protection check in the Sega ST-V game Tecmo World Cup ’98. After that it uploads the Tecmo logo the SH-2 code tries to read 8 dword RAMs from where the Tecmo logo buffer stands, if fails the game logic gets busted thanks to some clever writing to the file where the maths table stands.

I’ve also fixed SMPC intback commands in ST-V version by using the same logic as the one seen in Sega Saturn (former was a kludgy hack before). This fixes Zenkoku Seifuku Bishoujo Grand Prix Find Love inputs and makes it working:

The COP Diary #3

Monday, October 1st, 2012

#15 Advanced Hit Test

With this we tried to understand better the collision detection, by repeately poll the collision ports but it didn’t gave reasonable results. Amusingly, if you don’t clear the unused data of the collision table it will give complete garbage.

#16 Purple Laser Test

a.k.a. test for 0x6200 COP macro, used by various games to calculate angle direction according to a fixed function.  This is used by Raiden 2 purple laser, chopper (first enemies ) facing direction, SD Gundam homing weapon and 3rd level mid-boss direction (and probably others too). We now do know that the algo does some corrections to the result in particular circumstances, discovering what these are is the next goal.
#17 Ext Pin Test

In Legionnaire program code there’s a weird r/w access to an i/o port in range 0x700-0x7ff while polling bit 13 of the external port (0x470), then it puts the results of this weird read to some work RAM addresses that are never readed-back by the program itself. We tried to read the contents of this while doing the exact same thing as Legionnaire, but it just returned 0xffff. So it’s very likely to be a development left-over (either debugging device or a feature of the game that was discarded at some point).

#18 OBJ Y Test


This tested video register 0x644. The test confirmed that is a simple Y base register for sprites.

#19 0905/0904/0903/0902/0985/0984 Test

This checked the simplest macro (the 0x905, aka read to work RAM address X, add with RAM address Y, write the result to RAM address Z) and tried various combinations of it. 0x905 behaves normally, 0x904 (used in Zero Team and X Se Dae) definitely does a subtraction instead of an addition, 0x903/0x902 doesn’t do anything and 0x985/0x984 behaves like 0x905/0x904, respectively.
There’s a new theory, where the COP trigger is masked with a ~0x281 value when it executes commands at 0x50x, to define what COP macro should be executed (and also explains why Seibu Cup Soccer tries to execute 0xe18e, that isn’t in the uploaded table at all).

#20 DDE5 Test

This is used by the radar in Seibu Cup Soccer, but what we do know about it is completely wrong, so it doesn’t return any result in there. It doesn’t help that we still don’t have a proper way to access COP registers that are above 3 (see also test #13).

#21 DMA 14/15 Test

This checked if the DMA is really a burst one (-> halts main CPU and takes complete control over the system). The algo is:


enable both DMAs (14/15)
\-resync to v-blank
\-set the vblank flag to 1
\-increment a variable by one, and check if vblank goes to 0, if not rinse and repeat.
\-Put the variable buffer to screen
Disable DMA 14, enable 15
\-(do the above again)
Enable DMA 14, disable 15
\-(do the above again)
Disable both DMAs (14/15)
\-(do the above again)

Disregard the snapshot, timings with this algo are: 0xaa1/0xaa2 for first test, 0xafb for second, 0xac6 for third and 0b1f for fourth. So the test confirmed that the DMA is really a burst one, and also that the original PCB is slighlty slower than emulation in “idle” mode (either refresh rate or waitstates). Next step is to extract the exact timings out of the DMA.

#22 680 Test

This test tried to check out what’s the meaning of writing to port 0x680 (that is done at irq routine by all games). I’ve expected a full stop of the operations (so that is an irq ack) or a jumpy sprite movement (so that is a sprite buffer copy). It’s neither of those, fun.

#23 COP R/W Test/COP Read Test/Bogus R/W Test/Bogus RAM Test

This one tries to r/w the COP ports (0x100400-0x1005ff). System locks up if there’s an attempt to write at 0x100430 for whatever reason. Every other register prior to that seems to be read-backable.
With Bogus RAM test, it tries to check out RAM addresses 0x100000-0x1003ff. It’s a normal RAM.
With the Read tests instead, we tried to only do a read to these addresses, and we did two discoveries. A) default RAM pattern seems to be:

if((ram_addr & 0x20) == 0x20)
return 0x4141
else
return 0x0f0f

B) none of the 0x5** COP registers have default RAM values (returns either 0xffff or default state values), while all of the 0x4** all returns 0x4141 / 0x0f0f except to where I’ve did mods for the correct functioning of the system (so it returns back last value I’ve written in there).