Reip's MAME WIP
13 / 09 / 2008
Trying to fix bugs in a game with lots of bugs: Blandia
Bug #1 fixed. Now tilemaps in Blandia can properly switch the 2 color modes: it can repeat every 16 colors to fill the 64 colors for the 6bpp gfx or it can use the first 64 colors of the palette regardless of the color code. This is needed because it has 6bpp graphics but it writes palette data for 4bpp graphics.
During the demo mode there're 2 levels which now have broken colors, but I think it's just an original game bug (one of thousands in this game), because the game doesn't write to the color switch register, instead it does it during normal gameplay.
I've seen that this register is used by the other games that have 6bpp graphics: gundhara, jjsquawk and zingzip, so if someone can test them, please report any color problem at MAMETesters.
Meanwhile, I've also found something interesting to fix
bug: I've seen that it activates a video register bit and that it
writes new palette data to a currently unused palette ram. Probably this new
palette values are used to generate a "fake" blending effect.
I hope to write about some other Blandia fixes soon, since there's also a missing rowscroll effect ;-)
Update (14/09): Our friend Stekka, sent me proofs that the aforementioned two color bugs are original bugs!
06 / 09 / 2008
"Don't underestimate the power of unemulated interrupts" [Dox]
With another great help from Dox and
after 5 years, we understood what was missing to properly emulate sprites in
What the game does is to copy, with an interrupt driven DMA, sprites data to an external videoram that will be accessed when sprites are drawn instead of using the data directly from sprites roms.
We still need to check sprites colors with the game pcb and there still are 2 unknown writes executed by game (maybe original bugs?)
Here are some results:
04 / 09 / 2008
Y-Offset table effects...
we implemented playfield 1 and playfield 2 y-offset table in m90 driver.
What it basically does is adding an extra offset to the y-scroll value for each playfield scanline.
This fixed, at least, the previously missing water effect in riskchal and the missing text fade effect in the matchit2 demo.
Match It 2 effect: matchit2.mng
Risky Challenge water effect:
01 / 09 / 2008
Shadow Force raster effect
I've implemented the raster effect used in the title screen. I don't know if there are other places that use it.
Take a look: shadfrce.mng
30 / 03 / 2008
Namco NA1 fixes (Part II)
I've found how tilemaps switch from 8bpp to 4bpp, so bug (d) is completely fixed and I found that sprites can switch to 4bpp mode as well. I implemented it but it didn't fix bug (e), it only fixed a little scroll effect in the high-score screen.
29 / 03 / 2008
Namco NA1 fixes
It's been a while since I've updated this little page, indeed I haven't had much time for MAME lately, but some days ago I noticed this bug at MAMETesters.
I decided to take a look at it, because it was probably a simple fix: a missing sprites wrap around. In fact I fixed it rewriting the sprites drawing function and simplifing it a bit.
While working on namcona1 driver I noticed that Emeraldia have some problems:
a) a hack to draw sprites with shadow bit set
b) a missing dolphin "speaking" in the demo
c) an unimplemented ROZ effect
I asked a couple of MAME-friends if they had a pcb. Luckily Stefan Lindberg has one and got a video of Emeraldia, showing all these problems plus two new ones:
d) the high-score text has wrong colors
e) text sprites in the game (the score for example) have wrong colors
f) the service mode has a lower screen resolution
I started to take a look at some of these bugs.
I got bug (a) fixed: the shadows have to be drawn only when sprites use the 16th color and not always...
...and bug (d) almost fixed: it was graphics color granularity problem, because the game can switch it (from what I can tell it can use 4bpp and 8bpp). I still have to find how to switch it and not hardcode it.
Bug (b): I know that the dolphin sprite is drawn... but it's under
the tilemaps so right now it's not visible. I don't know yet how to fix it. It
could be related to a priority issue.
Bug (c): don't know anything about it... there're registers to hook it up, but I don't know how easy or difficult it's to implement.
Bug (e): I think it could be something related to bug (d)
Bug (f): there are probably some video registers to dinamically change screen resolution at run-time.