etabeta's playground

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

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 (again) 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

Similarly, the new code allowed to say goodbye to this annoying messages

and made Pokémon Ruby / Emerald / Sapphire at last fully working

(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

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

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

(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)
  

• 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
  
  to a clock that is aligned with real time when the game is rebooted
  
  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