FB Alpha

WIP Blog


FB Alpha WIP (iq_132) - Raiden II

Posted by barry on 28 September 2014 at 18:31:43

iq_132 has also added a Raiden II driver to FB Alpha. This has been made possible due to recent improvements in MAME (in particular, some reverse enginerring of the COP device by kale, ogalibert and haze). This driver is still far from trivial and is an extremely impressive addition to FB Alpha. I'll let the following screenshots talk for themselves...

Click more for the screenshots.


FB Alpha WIP (iq_132 and dink) - NMK004

Posted by barry on 27 September 2014 at 20:13:50

iq_132 has ported the NMK004 improvements from MAME (trap15 and haze). After a lot of work from dink, working in the NMK16 driver (and fixing a bug in the TLCS90 CPU core) we now have full emulated sound in the NMK16 games. There have also been improvements in other aspects of the driver fixing minor issues with graphic layer offsets and similar issues.

This is a major improvement in the emulation of these games and massive thanks goes to trap15 who managed to dump the code, and haze who hooked it up in MAME.

The next version of FB Alpha should be a good one. iq_132 has been very busy with some really excellent additions which I'll cover soon...



Posted by barry on 26 September 2014 at 19:26:02

Just a quick service announcement that this server is up-to-date and not vulnerable to the Shellshock/bash vulnerability.


Previous Versions

Posted by barry on 31 August 2014 at 18:25:38

I have added a new page to make previous versions of FB Alpha available for download after receiving many requests for them. The page is available here.

There are quite a few missing files (particuarly older releases). If you can help fill the missing files please let me know.


FB Alpha Bug Reporting

Posted by barry on 27 August 2014 at 18:21:23

I have added a new bug reporting tracker to the site for FB Alpha.

You can access it on the FB Alpha Bug Reporting page.

The bug tracker is new and custom so if you find any issues with it please let me know.


FB Alpha Page Additions

Posted by barry on 27 July 2014 at 11:52:38

I have added some new translation templates to the FB Alpha page. Thanks to the contributors as usual (each file is credited individually). It still amazes me the translators are still around. Thanks guys.

I have also added two new galleries (in-game and title screenshots) to the page. These galleries allow filtering and use the packs from emu-france. The credits for these are listed on the left-hand side of the gallery pages.


Site Update

Posted by barry on 27 May 2014 at 19:44:54

I've updated the site software a bit to avoid the deprecated MySQL interface. I also created a new development server for me to make changes more easily in future.

I'm now planning on quickly knocking up a bug tracker for FB Alpha, and once complete I plan to roll-up a new FB Alpha to go with it. Stay tuned!


New Compile Guides

Posted by barry on 2 December 2012 at 20:30:57

I updated the compile guides and posted them in the FB Alpha section. The two new guides require the next version of FB Alpha which won't be too far behind!


CPS-2 Sound Tests

Posted by barry on 23 November 2012 at 19:33:37

Smitdogg dumped a single-board version of Marvel Vs. Capcom recently. He remarked that the case had a volume knob (as opposed to digital up and down buttons usually seen on CPS-2 games) and that the sound test screen was missing the volume slider. At first it was assumed that this was due to differing program roms, but the program is the same as the normal Japanese version (the roms are byteswapped). I decided to take a look at what else could cause the different sound test screen.

I also decided whilst I was looking at CPS-2 sound volume, that I should take a look at how the actual slider works. All CPS-2 emulators currently lock the slider to the top (0xe021). There are 40 possible levels for the volume and from analysing the screen, I have found the values that need to be returned at 0x804030 for each of the volume levels. These are (if you look carefully there is a pattern there);

UINT16 Cps2VolumeStates[40] = { 0xf010, 0xf008, 0xf004, 0xf002, 0xf001, 0xe810, 0xe808, 0xe804, 0xe802, 0xe801, 0xe410, 0xe408, 0xe404, 0xe402, 0xe401, 0xe210, 0xe208, 0xe204, 0xe202, 0xe201, 0xe110, 0xe108, 0xe104, 0xe102, 0xe101, 0xe090, 0xe088, 0xe084, 0xe082, 0xe081, 0xe050, 0xe048, 0xe044, 0xe042, 0xe041, 0xe030, 0xe028, 0xe024, 0xe022, 0xe021};

I have hooked these up and added volume up and down buttons to the driver and the sliders now work in all games where they are present. I also added support to change the actual Q-Sound output based on the volume selected.

I also found that returning any number in the 0xd000-0xdfff range will disable the volume slider in the sound test screens, and added a seperate init for the single board game to return this value.

Below are screenshots of the Marvel Vs. Capcom sound test screen (with and without the slider).

Marvel Vs. Capcom sound testMarvel Vs. Capcom single board sound test

Not exactly a significant find, but it helps to further understand the hardware.



Posted by barry on 12 May 2012 at 16:08:45

I looked at Street Fighter II: Magic Delta Turbo again. It had sprite glitches, and the scroll 2 layer was in the wrong place when row scroll was used. The game writes different row-scroll values than normal, and it wasn't just a case of applying an offset to line-up the layer.

Initially, I gave the game a different VBLANK IRQ, I found that using an IRQ of 4 the game started reading and writing in the 7xxxxx area. I hooked up inputs and dips for the reads at 708xxx. I then recognised the layer enable write and scroll register writes in the same 708xxx range. Hooking all these had the game working pretty well, albeit with sprite glitches and incorrect row scroll.

At times when sprites were on-screen, there were plenty of writes in the 0x7xxxxx area, with the tell-tale 0x8000 end of sprite list marker being written too. Sure enough, this is sprite RAM, in the same format as many of the other CPS-1 bootlegs. Hooking this up, the sprites work perfectly, the aforementioned glitches are gone.

For the row scroll, I noticed that the game wasn't writing the row scroll start register. This is usually the same as the y scroll value, so hooking up the scroll2 y write to this register seemed plausible (the game isn't writing it anywhere else). Doing this, aligned the scroll layers, but ended up with slightly "juddery" scrolling.

I also noticed, that the game wasn't alternating the row scroll table register. Usually, the game would alternate between four row scroll tables to achieve smooth scrolling. I found the alternating value in the game's work RAM, and hooking this up, gives the normal row scroll effect. I am not 100% sure if this is accurate or not, but it seems strange that the bootleggers would leave the game with the "juddery" scrolling. If anyone has access to a PCB, it would be nice to get confirmation about the scrolling. The Guile stage is particuarly good for checking, and helpfully, is first in the demo loop. A video would be perfect, if anyone has the capability.