Posted by barry on 10 December 2018 at 19:53:39
I have added Mortal Kombat II to the T-Unit driver. Everything appears to be working pretty well.
Dink has been busy adding sound to Mortal Kombat and tidying up the Wolf Unit driver as well.
So now we should have Mortal Kombat, Mortal Kombat II, Mortal Kombat 3 and Ultimate Mortal Kombat 3 in the next release.
Click more below for some more screenshots.
Posted by barry on 7 December 2018 at 19:41:51
This has probably been the most requested game to be added to FB Alpha out of all the ones that aren't supported.
The game is running, currently without sound, but that shouldn't be too difficult to get running. The latest code is as always on our github page.
Click more below for some more screenshots.
Posted by barry on 9 July 2015 at 20:37:01
Bonky0013 provided us with a dump of a bootleg board of Punisher. It was pretty easy to get going once I worked out the ROM loading and the format of the tile ROM data. It plays the same as the original - but interestingly uses sound data from Mercs.
The original Punisher PCB uses Q-Sound, and this bootleg uses the standard CPS-1 sound hardware (the game actually runs on a Mega Twins PCB). The actual mapping of the sound codes has been done quite well and the overall result is actually pretty good.
Overall, another interesting CPS-1 bootleg dumped and documented!
Posted by barry on 2 June 2015 at 18:57:48
About a year ago, Bonky0013 sent us a dump of a bootleg of Cadillacs & Dinosaurs. I didn't have much time to look at it when it was submitted, and I have only just remembered to revisit this!
This bootleg has the Q-Sound hardware replaced with MSM6295 samples (with a new Z80 program too), similar to the Dinosaur Hunter bootleg. An image of the board can be seen below;
The board also has a PIC16C57 chip on it (no dump of the program data due to protection though). We have seen this used to replace Q-Sound hardware before, but since we have a Z80 program ROM driving the MSM6295 samples, this is obviously not the case here.
The board also has the graphic ROMS scrambled in a different format than we have seen before. I had this descrambled last year though when I originally looked at this.
The program ROMS are also in a different format. Once I had these loading in the correct order I got the following error on-screen;
The game was writing a value of 0x04 to 0x5762b0, and then reading from 0x57a2b0, before crashing. This seems to be protection related (and maybe something that the previously mentioned PIC16C57 does?). I looked at a disassembly of the code;
Following this through, the game reads from 0x57a2b0, and stores the value in D0. It then checks the value in D0, to see if it is $404. Returning this value is enough to get the game to boot and work properly.
Posted by barry on 7 May 2015 at 18:18:23
Now we have the ability to edit and export localisation templates from the web site I thought it was time for FB Alpha to be able to download these too. I have added a dialog to FB Alpha that connects to the web site, pulls down the available templates and populates a combobox control. The user can then select a template and download it. Once it is downloaded, FB Alpha will activate it.
This saves the manual element of downloading it in your browser, and then pointing FB Alpha at your download!
A (unexciting) screenshot of the dialog is below;
Posted by barry on 15 November 2014 at 23:28:24
I have quickly updated the FB Alpha Galleries with the latest packs posted by JacKc. I have also updated them to use bigger thumbnails, bigger images (where screen space is availabe) and a title bar. They should be more useful now.
Posted by barry on 31 October 2014 at 23:37:26
The FB Alpha section of this site was due an overhaul. There is now a new section with more documentation, newer web technology, updated bug tracker, better galleries, and more.
Posted by barry on 21 October 2014 at 21:24:56
About a month ago Caius dumped a bootleg version of Varth. A had a quick look at the time but never got it going. I've had another look over the last couple of days and the game is now working.
Initially I didn't get very far, the game was halting when reading from the 68K address 0x100280. Initially I thought there was some simple protection, but didn't find anything that worked. I mapped some of the 68K program ROM into the space, and the game did do a little more, but never started.
At this point, I realised there were two more ROMs in the dump. These two ROMs matched data from the end of main 68K ROMs in the original set, but were much smaller. Mapping this data into the space at 0x100000 to 0x1fffff and the game boots and works fine. It looks like the bootleggers used a subset of the 68K ROM as protection data, or maybe they needed to be able to return the original data in the area where they added their code.
The game doesn't appear to write the scroll 3 RAM offset anywhere (the usual address is now the sound command), so I have hard-coded it on boot. However, the game does write the value at boot to 0x800188 (which is normally the PSound fade command). The game promptly overwrites this again though. Is it feasible that the first write to this address sets up the scroll 3 RAM offset, and subsequent writes are used as the fade command as usual?
This bootleg is taken from the 920612 etc version. I can't see any differences in-game but the following hardware differences are observed (as well as the previously mentioned 68K data, and scroll 3 RAM offset handling);
This is another CPS-1 bootleg emulated and documented. Look out for it in an FB Alpha release soon.
Posted by barry on 14 October 2014 at 21:40:12
Thanks to Robert we have some fills for some of the missing versions. Please let me know if you have any of the remaing missing versions.
Posted by barry on 1 October 2014 at 20:27:52
All working fine!Next