Robiza's MAME & David Haywood's MAME(tm) WIP - 模擬器

1.

http://mamedev.emulab.it/robiza/?p=163

Io e Kale abbiamo notato che la palette veniva scritta 2 volte quasi
consecutivamente; dato che durante la prima copia un bit di un registro era a
zero e durante la seconda copia lo stesso bit era a 1 abbiamo presunto che
fosse una sortas di protezione; quindi scartati i valori del bit a 0 abbiamo
ottenuto colori che sembrano corretti (valido per tutto il gioco compresi gli
intro)

finalmente fixato? comunque qualche test sull’hw sarebbe opportuno farlo


2.

http://mamedev.emulab.it/haze/2010/08/21/getting-your-priorities-right/

Getting Your Priorities Right
The Toaplan 2 driver (games using the GP9001 VDP) has always been a bit of a
MESS in MAME, especially the priority system in the driver. A couple of
releases back I decided to start something of a rewrite of the driver,
cleaning up many of the hacks that were present. I’d actually started this
rewrite a long time ago, but didn’t submit it at the time because there were
two games I was unable to get working properly with my new cleaner code, the
dual VDP ones, namely Batsugun and Dogyuun.

The problem was the old code was rendering all the layers in multiple passes
(calling sprite draw functions once for each priority and such) which broke
basic things like sprite-sprite priority. Each game was rendering different
layers in arbitrary order depending on the specific needs of that game to
compensate for this.

In cleaning up the code I managed to reduce all the single VDP cases to a
single call to draw all the graphics in the correct order, this however broke
Batsugun and Dogyuun because the self-contained rendering function broke the
hacks which were interleaving the output from each of the VDPs. Batsugun had
never worked properly anyway (and had various priority glitches on certain
levels and the ending), but with the new code it was completely unplayable in
some levels.

I originally wanted to fix this before submitting it, and it was left sitting
for a while. Eventually somebody else took a hand at ‘fixing’ the Toaplan2
driver, however the fixes submitted were nothing but further hacks to the
driver (checking which level was currently running and further hacking the
priority of each layer based on that). The code submitted was gross to say
the least, so I decided to submit my code, and demote Batsugun and Dogyuun to
Non-working status instead, pending proper fixes which weren’t hacks. My new
code was a lot cleaner for every other game in the driver, and I knew it
would form the basis of a correct solution eventually, so this was a
worthwhile step even if it meant the games were unplayable for several
versions.

I tried various things to get the mixing correct with very little luck, and
the driver remained in the broken state for quite a few releases. In the
meantime I did some further cleanups to the VDP rendering code, and converted
it all to use the new C++ devices Aaron had been adding support for in the
core. With the GP9001 extracted to its own file, as a proper device, I
decided to take another look at the priority mixing, strongly believing that
there must be some kind of PAL on the board to mix the output of the two
VDPs, because it didn’t seem entirely logical.

One of the big problems was I didn’t know exactly what each VDP output
externally. By displaying the output of each VDP on separate screens it was
clear the the individual mixing of each VDP was correct, as expected (the
mixing code for single VDPs worked fine) However, I didn’t know if the VDPs
output any kind of priority data externally to mix with, or just the colour
data. A few more attempts later, and I was still getting nowhere with the
dual mixing, and almost ready to give up.

At that point Quench came forward with some information that proved to be
very useful in the end. He’d managed to reverse the equations of a Pal which
sat between the two VDPs on a Batsugun board. From his equations it was clear
that the VDPs didn’t output any kind of priority information externally, and
the mixing had to be entirely based on the palette index.

I implemented his equations directly, which in theory should have worked, but
the results were disappointing, the output was a mess, pixels were showing
through where pixels shouldn’t have shown through, and I didn’t know why. I
took a break for a week to try and figure out why this might have been, then
tried re-implementing it in a slightly different way. Same result.

All was not lost at this point however, because despite the equation not
working directly it had provided me with some useful information. I now knew
exactly which bits were being fed into the pal, and thus which bits could
potentially be used to determine the mixing order, even if the given equation
wasn’t working.

Rearranging things a bit I came up with my own solution, making use of the
same bits that Quench had figured out were being input into the PAL. The
first attempt left some random black dots in the level, quickly realising
that where those dots appeared should actually be showing the other VDP I
amended my code and had something which worked. Testing the game from start
to end showed that all the problematic test cases I’d documented were now
correct. Finally.

The other benefit of this mixing was that the tile number hack, which was
being used to hide some garbage on the first level of Batsugun could be
removed, as it happens the palette index of the garbage is set so that it
appears behind the background anyway.

Dogyuun was still an issue, it didn’t work with the new code, however, a bit
of testing later, and I’m pretty sure that just uses a simple mixing system,
with the output of one VDP appearing above the other, nothing complex.

The net result of this is that for the first time Batsugun can be rendered
without hacks, and looks correct on all levels. There is still room for
optimization in the code (I’d made it as verbose as possible when debugging,
rather than optimized, but it’s correct)

The next step for Batsugun will be adding the missing opcodes and features to
the V30 core so that all the V35+ features it needs are supported (register
banking etc.) Currently AWJ is meant to be working on this, but I haven’t
heard any progress recently. That will allow for full sound emulation in the
game.

I may add more technical details to this post later, but for now I have to go
out ;-)


兩個Wip都是很有名的stg
一個是"飛虎隊"一個是移植過SS的"瘋狂槍手"

又有得爽了科科


--