2016.06.06
Since I got stuck with porting my custom EEPROM implementation for
Genesis/MegaDrive towards the core one [*] and since updating software lists
with PCB info is valuable but not very exciting, I was searching for some not
too complex but still rewarding emulation task to occupy my weekend.
While going through my notes and partially developed implementations, I
stumbled upon a bunch of notes about the “General Purpose I/O port” of the
GBA, a bunch of pins connected to the ROM on the GBA cart PCBs which allow
the system to serially transfer bits through the cartslot. The main usage of
the port was the routing of the RTC in Pocket Monster games, the Rumble
feature of Drill Dozer and the Gyroscope sensor of Warioware Twisted. The
missing implementation of the RTC comms was also the reason why Sennen Kazoku
was stuck on the following screen
http://mamedev.emulab.it/etabeta/fast/files/0028.png
Since the port was quite well documented (mainly thanks to the great reverse
engineering job done by the nocash guy) and the RTC improvement was often
requested on the Bannister MESS board, I decided to take (agsain) a quick look
to see whether this time I could manage to make the RTC work.
It turned out that in my previous attempts on this, I had misread some of the
bits of info presented at GBATEK. After some work to add the correct GPIO
hookup into the driver, I was finally greeted by Sennen Kazoku getting in-game
http://mamedev.emulab.it/etabeta/fast/files/0011_1970131108.png
http://mamedev.emulab.it/etabeta/fast/files/0010_1751179555.png
Similarly, the new code allowed to say goodbye to this annoying messages
http://mamedev.emulab.it/etabeta/fast/files/0025_8521060235.png
http://mamedev.emulab.it/etabeta/fast/files/0026_1418304131.png
and made Pokémon Ruby / Emerald / Sapphire at last fully working
http://mamedev.emulab.it/etabeta/fast/files/0030.png
http://mamedev.emulab.it/etabeta/fast/files/0031_4378546895.png
and yes, I’m sort of cheating with the above screens, since the game could
be played even without the RTC, but some events would not have worked as
designed without it, so it is a *real* improvements :)
With the RTC implemented, I decided to look a bit to the other games using
the port and it turned out that RTC was probably the most complex of the
device exploiting the GPIO port… good for us!
In a few hours I was able to implement in MAME the Gyroscopic Sensor used by
Warioware Twisted, so that its minigames will be playable in next MAME release
http://mamedev.emulab.it/etabeta/fast/files/0034.png
http://mamedev.emulab.it/etabeta/fast/files/0037.png
http://mamedev.emulab.it/etabeta/fast/files/0041.png
http://mamedev.emulab.it/etabeta/fast/files/0043.png
Next it was the turn of Boktai’s luminosity/light sensor. Such a sensor was
used in the three games of the Boktai / Bokura no Taiyou series, and the lack
of support for it had a great playability impact in MAME: it not only made
almost impossible the gameplay in Boktai 2 / Zoku Bokura no Taiyou and in
Shin Bokura no Taiyou (the Jpn-only third chapter in the saga), since solar
light is needed to recharge the main character’s weapon, but even more
annoyingly it caused the following screen to show up and stop any play at the
very beginning of the first game
http://mamedev.emulab.it/etabeta/fast/files/0044.png
Luckily, the sensor implementation was not too difficult (in MAME you will be
able to choose the luminosity level from the “Machine Configuration” menu
entry of the internal interface… at least until we get some sort of webcam
support as input device in MAME, which would force users to play the game
outside in order to actually defeat vampires :/ and we now can play these
games (almost) as they were intended
http://mamedev.emulab.it/etabeta/fast/files/0045_4062439352.png
http://mamedev.emulab.it/etabeta/fast/files/0033.png
observe the luminosity bars which are not empty as they were in MAME/MESS so
far…)
To complete the picture, it remained to add the Rumble chip and that was very
easy to add, even if it is probably less interesting from the MAME-users’
point of view in its current state: as with other MAME outputs, with the new
code the emulator will now send out a "Rumble" output bit (0 for Rumble=OFF
and 1 for Rumble=ON) whenever the games try to access the Rumble component…
however, users will need a third party application to listen to the output
and redirect it to some hardware that can "rumble" in sync with the gameplay.
Is this all? Well, I thought so at first… but then I realized that there
were a few more low hanging fruits I could implement, and that is how we will
also get in next MAME:
‧emulation of the Tilt sensor used by Yoshi’s Universal Gravitation / Yoshi
Topsy-Turvy / Yoshi no Banyuuinryoku (and by Koro Koro Puzzle)
http://mamedev.emulab.it/etabeta/fast/files/0022_9383308943.png
http://mamedev.emulab.it/etabeta/fast/files/0024_2825789507.png
‧emulation of the Rumble chip used by MBC-5 Game Boy Color games (like Poké
mon Pinball and more), once again restricted to a "Rumble" output bit ready
to be intercepted by some external listener application
‧partial emulation of the RTC used by MBC-3 Game Boy Color games (like Poké
mon Gold / Silver / Crystal and many more), which allows to actually pass
from a stuck clock that never updates
http://mamedev.emulab.it/etabeta/fast/files/0008_2396278041.png
http://mamedev.emulab.it/etabeta/fast/files/0009_663029560.png
to a clock that is aligned with real time when the game is rebooted
http://mamedev.emulab.it/etabeta/fast/files/0006_560611449.png
http://mamedev.emulab.it/etabeta/fast/files/0007_9603631123.png
You might have noticed that I wrote partial emulation above, and the reason
is that the clock goes definitely too fast while in-game and thus the
support cannot be considered complete…
In the next few days, I plan to revisit a little bit the GPIO direction bit
handling, since it does not match perfectly the description at GBATEK and I
would like to understand where the difference comes from, and to search for
the issue which causes the RTC to go so fast in GBC games. Let’s see how it
does work out :-)
[*] I’ve done some progress but it’s pretty boring… and it always requires
me playing at least a NBA Jam match to test that both reading and writing to
EEPROM works fine, which usually does not fit well the short lunch breaks at
work, when I have the chance to make some hobbyist developments
來源 http://mamedev.emulab.it/etabeta/