|Immagini disponibili:: |
Nome romset brapboys.zip |
Anno di produzione: 1992
Questo gioco ha i seguenti cloni:
B.Rap Boys Special (Japan)
B.Rap Boys Special (US)
Genere del gioco: Picchiaduro
Categoria: Picchiaduro / 2.5D
Questo gioco funziona correttamente in MAME
In MAME dalla versione: .116u4
Salvataggio state: Non supportato
Stato dell'emulazione: Buono
Emulazione colore: Buono
Emulazione sonoro: Buono
Emulazione grafica: Buono
Dimensione palette: 2048
Il driver di questo gioco in MAME è: kaneko16.c - Leggi il codice
Questo gioco usa un solo schermo: |
Tipo di grafica: Raster
Orientamento schermo: Orizzontale
Risoluzione del gioco 256 x 224 @ 59.185400
Numero di giocatori: 3P simultanei
Numero di pulsanti: 2
La scheda di questo gioco usa 12 CHIP
Il ROMset si compone di 17 ROM
Le dimensioni del file brapboys.zip sono 5.14 Mbytes (compresso)
Riferito alla versione MAME: 0.151
: Gioco Parent
: Gioco Clone
La scheda del gioco ha 7 opzioni configurabili via dipswitch
In grossetto i valori predefiniti
B.Rap Boys (c) 1992 Kaneko.
Un picchiaduro a scorrimento orizzontale. 3 personaggi, uno su uno skateboard, uno su una bicicletta e uno sui pattini a rotelle, combattono vari nemici. Caratterizzato da un grande numero di voci campionate e da numerose canzoni rap.
- DATI TECNICI -
Main PCB # : ZO1DK-002
ROM PCB # : ZO1DK-EXROM
Processore Principale : 68000 (@ 12 Mhz)
Chip Audio : (2x) OKI6295 (@ 12 Khz)
Giocatori : 2
Controllo : Joystick a 8 direzioni
Pulsanti : 2
- CURIOSITA' -
Pubblicato nel Giugno 1992 in Giappone.
- SERIE -
1. DJ Boy (1989)
2. B.Rap Boys (1992)
- FONTI -
Rom del gioco.
Immagini del cabinato.
64th. Street - A Detective Story (World)
Avengers (US set 1)
Bad Dudes vs. Dragonninja (US)
Big Fight - Big Trouble In The Atlantic Ocean
Black Touch '96
Burning Fight (NGM-018)(NGH-018)
Captain Commando (World 911202)
Crude Buster (World FX version)
Crime Fighters (US 4 players)
The Combatribes (US)
D. D. Crew (World, 3 Players, FD1094 317-0190)
Double Dragon (Japan)
Double Dragon II - The Revenge (World)
Double Dragon 3 - The Rosetta Stone (US)
Ghost Chaser Densei (SNES bootleg)
Cadillacs and Dinosaurs (World 930201)
Double Dragon (Neo-Geo)
DownTown / Mokugeki (set 1)
Final Fight (World, set 1)
Final Fight 2 (SNES bootleg)
Ginga NinkyouDen (set 1)
Guardians of the 'Hood
Iron (SNES bootleg)
Karate Blazers (World)
Knuckle Bash 2 (bootleg)
Knuckle Joe (set 1)
Shinobi III (Mega Play)
Streets of Rage II (Mega Play)
Last Battle (Mega-Tech)
The Revenge of Shinobi (Mega-Tech)
Shadow Dancer (Mega-Tech)
Shinobi (Mega-Tech, SMS based)
Streets of Rage (Mega-Tech)
My Hero (US, not encrypted)
Ninja Baseball Bat Man (World)
Double Dragon (PlayChoice-10)
Ninja Gaiden Episode II: The Dark Sword of Chaos (PlayChoice-10)
Ninja Gaiden Episode III: The Ancient Ship of Doom (PlayChoice-10)
Ninja Gaiden (PlayChoice-10)
The Punisher (World 930422)
Riot City (Japan)
Pretty Soldier Sailor Moon (Ver. 95/03/22B, Europe)
Sonic Blast Man 2 Special Turbo (SNES bootleg)
Shadow Warriors (World, set 1)
Shadow Dancer (World)
Shinobi / FZ-2006 (Korean System 16 bootleg) (ISG Selection Master Type 2006)
Shinobi (set 6, System 16A, unprotected)
Silent Dragon (World)
Thunder Hoop (Ver. 1)
TH Strikes Back
Trojan (US set 1)
Tough Turf (set 2, Japan, 8751 317-0104)
Undercover Cops (World)
Vamf x1/2 (Europe)
Vendetta (World 4 Players ver. T)
Vigilante (World, set 1)
Violent Storm (ver EAC)
Zero Team USA (set 1, US, Fabtek license)
720 Degrees (rev 4)
DJ Boy (set 1)
Riding Fight (Ver 1.0O)
Skater (DECO Cassette, Japan)
Top Skater (Export, Revision A)
Attenzione: I dati di history.dat potrebbero essere diversi da quelli riportati nel resto della scheda (tratti da MAME), in quanto provenienti da fonti diverse.
|Informazioni su brapboys
0.116u4 [Hammad, Brian Troha]
- brapboysj: [possible] You can see a big comma in black and something else written in black i cant read properly. hammad (ID 04459)
- 0.146u5: Changed region cpu1 to calc3_rom.
- 0.144u5: hap fixed B.Rap Boys loops on CRC check.
- 0.144u1: vintagevideogames.com and Lord Nightmare added clone B.Rap Boys Special (US). Mirror gfx1 rom ($400000 to 480000) in B.Rap Boys. Fixed rom names.
- 0.143u9: Fixed rom names.
- 0.135: David Haywood changed sound banking on B.Rap Boys to use an OKIM6295 address map and banks. Changed region samples to oki1.
- 0.134u1: Kitsune Sniper, hap, Haze and Guru fixed music samples looping incorrectly / ending too soon in B.Rap Boys and clone. Changed clock speeds of the 2x OKI6295 to 2MHz and VSync to 59.185400 Hz.
- 0.133u5: David Haywood temporarily added a hack to the collision function to only use the B.Rap Boys code if the game is B.Rap Boys until we have a single function that works with both.
- 0.133u4: David Haywood, Tomasz Slanina and Luca Elia fixed - Game now playable. Phil Bennett fixed B.Rap Boys sound banking. David Haywood and Tomasz Slanina decoded all protection data for B.Rap Boys. Tomasz Slanina improved protection simulation logic w/regards to writeback addresses, allowing B.Rap Boys to boot and added hitbox simulation based on suprnova / game requirements. Guru redumped GFX Roms. David Haywood cleaned up decryption function for B.Rap Boys external Rom, improved video emulation for B.Rap Boys, marked several GFX roms as bad on B.Rap Boys, converted MCU writes to use write_byte, added kludge to reset MCU data write address to prevent game from running out of ram and crashing, added DSWs, added EEPROM support to the B.Rap Boys protection simulation and changed to priorities to fix some visibility problems. Added new gfx1 roms ($0, 100000, 200000, 300000). Changed visible area to 256x224. Added dipswitches 'Switch Test', 'Coin Slots', 'Players', 'Difficulty' and 'Unused'.
- 0.133u3: David Haywood decrypted several tables from the B.Rap Boys rom.
- 0.133u1: Calc 3 MCU update [David Haywood]: Shuffled a few things around based on new findings. Added an extra decryption table used for the Brap Boys startup code (still doesn't do anything interesting). Noted that one of the unknown parameters for the MCU Init command is where it reads / writes EEPROM data from. Noted that an additional parameter in the MCU commands may cause further displacement of the writeback address, as BRap Boys seems to rely on this (needs further testing) - added a hack for now so that BRap Boys places the writeback address of the initial table somewhere that causes it to get executed. Renamed (brapboyj) to (brapboysj).
- 0.132u5: Changed description of clone 'B.Rap Boys (Japan)' to 'B.Rap Boys Special (Japan)'. Added button 4. Changed visible area to 256x240.
- 0.132u2: David Haywood improved protection simulation for B.Rap Boys, eliminating the hardcoded table with the initial program snippet in, getting it from the rom instead, and generally cleaning things up.
- 0.132u1: David Haywood improved protection simulation and documentation for B.Rap Boys.
- 0.128u1: Guru added redumped B.Rap Boys sample ROMs.
- 0.116u4: Hammad and Brian Troha added B.Rap Boys (World). Renamed (brapboys) to (brapboyj).
- 28th June 2007: Hammad dumped B.Rap Boys (World). Only socketed EPROMs have been dumped, the rest are soldered MASKROMs.
- 0.112u3: Changed description to 'B.Rap Boys (Japan)'.
- 0.74u2: Added B.Rap Boys (Kaneko 1992)
- 0.61: Added B.Rap Boys (Testdriver).
- 26th August 2001: Guru - Dumped B.Rap Boys (Kaneko 1992). Thanks to Felicien for the donation.
- 18th August 2001: Guru - A 'B. Rap Boys' PCB has arrived, however Australian Customs has grabbed it and is holding me to ransom. I'm working on that, and hopefully I'll get it next week.
Informazioni su kaneko16.c (Driver MAME)
0.36b15 [Luca Elia]
- Interrupt timing/behaviour.
- Replace sample bank copying with new ADDRESS MAP system for OKI and do banking like CPUs.
- gtmr: Stage 4: The layers' scrolling is very jerky for a couple of seconds in the middle of this level (probably interrupt related). The layers' colours are not initialised when showing the self test screen and the very first screen (with the Kaneko logo in the middle). They're probably supposed to be disabled in those occasions, but the relevant registers aren't changed throughout the game (?)
- gtmr2: Finish the Inputs (different wheels and pedals) and find infos about the communication stuff (even if it won't be supported).
- brapboys / shogwarr: Verify collision protection on real hardware (appears to be a function of the system/memory controller, NOT the MCU). Currently B.Rap Boys has it's own special case, it should work with the same code as Blood Warriors / Shogun Warriors (and probably SuperNova). Figure out how MCU resets writeback address (currently hacked). Find relationship between Key tables and final datablock. Clean up debug code file writes etc. (when above are done only!). Interrupt timing? (some sprites flicker). Some sprite flicker exists in youtube videos too, so probably not a bug. Sprite buffering (1-2 frames?, or related to above). Some bg objects with sprite parts break up in shogun
- gtmr manual shows "Compatible with AX Kaneko System Board".
- Bakuretsu Breaker: Incomplete dump (gfx+sfx missing)
- Sand Scorpion (by Face): MCU protection (collision detection etc.)
- Shogun Warriors: MCU protection (68k code snippets, NOT WORKING)
- B.Rap Boys: MCU protection (not working, game can be run on a shoggwar board ok)
- bonkadv, brapboys and clones: Missing Sprite on Flip Screen. Tafoid (ID 04936)
- brapboys, bloodwar: Playback lose sync. Tafoid (ID 04209)
- 0.148: Removed calc3_t in machine\kaneko_calc3.c (the compiler didn't crucify me for this?) [David Haywood].
- 0.147: Sandro Ronco fixed Kaneko16 driver regressions.
- 0.146u5: Removed machine\kaneko16.c/h. Added machine\kaneko_calc3.c/h, machine\kaneko_hit.c/h, machine\kaneko_toybox.c/h and video\kaneko_tmap.c/h. Started the process of converting some Kaneko games to use devices. Kaneko sprites are now a device. This should facilitate cleaning up video related files as well (sprites and tilemaps) [David Haywood].
- 0.146u1: Kaneko16 regression fix (kaneko16_ay2_YM2149_r) for berlwall, bakubrkr and mgcrystl [Miodrag Milanovic].
- 0.144u3: Changed region gtmr to maincpu.
- 0.142u1: Atari Ace converted Kaneko16 driver to driver_device.
- 0.141u3: Aaron Giles removed public nvram_open() and fixed Kaneko16 driver to stop directly saving NVRAM.
- 0.139u3: Aaron Giles fixed "16-bit EEPROM set with 8-bit data" in Kaneko16 driver.
- 0.135u2: Fabio Priuli converted the Kaneko16 driver to use EEPROM device.
- 0.133u5: David Haywood simplified Kaneko16 decryption functions by working out what each of the bits does and removing game specific references. Re-based the decryption tables as a result. End result is verified to be the same. Fixed a small bug with Kaneko16 graphic decoding and removed old comment about bad sound banking. Temporarily added a hack to the collision function to only use the B.Rap Boys code if the game is B.Rap Boys until we have a single function that works with both.
- 30th August 2009: David Haywood - Shogun (almost) Working: This needs 2 graphic roms redumping (various character poses, and almost the entire character sets for 'Geisya' and 'Sumo' are missing) and the sound banking hooking up (and possibly the sound roms verifying) but otherwise it seems playable. This again was a lot of work to get running. Dox had to extrac another 20 tables from the PCB, which I then had to type and use to decode the data. Each character uses 2 tables, one which gives pointers to the tiles needed by that character, and another (I believe) relating to the moveset for the character. Anyway, that's all done, and the game works. Now hopefully Andreas can find a relationship between the decryption tables and the MCU data rom, which would help significantly clean up the implementation. This game also shows that the B.Rap Boys and Blood Warriors collisions systems should be the same, even if they currently each require their own implementations in MAME. Work to be done there!
- 29th August 2009: David Haywood - We've managed to extract some more tables from Shogun. This allows the first two characters to show. For some unknown reason it still hangs after the fade tho. Ok.. that was a silly bug. The attract mode works for these 2 characters. Just need to get the data for the others then.
- 26th August 2009: David Haywood - Guru redumped the 4 Mask roms from his B.Rap Boys PCB. This fixes all of the missing graphics. Collisions are still broken (you can attack what's to your right now, but any attack to the left by either yourself of an enemy kills anything on the screen). The collision hit system looks similar to Kaneko Superr Nova, but doesn't work. The game uses '3d' collisions, so it's possible this codepath was never tested in suprnova or is different. All the Suprnova games are pure 2d, not 2.5d. Dox is looking into it.
- 25th August 2009: David Haywood - I fixed a few issues with the graphic emulation (some remain), figured out the correct rom loading, and confirmed that at least 4 of the graphic ROMs currently dumped are half size (which is why there are a lot of missing graphics). Sadly the maths unit doesn't seem to be the same as Blood Warrior, so additional work will be needed there. I also need to work out properly how it resets the protection device so that it doesn't crash after a few levels. For some reason test mode doesn't work. We've also asked Andreas if he can look for a relationship between the extracted decryption keys and the table in the MCU rom, which, if he can find one, will help with Shogun.
- 24th August 2009: David Haywood - Dox managed to figure out an important detail about the protection and the way the writeback logic works. As a result B.Rap Boys now boots and gets into gameplay. The bad news is that all the sprite roms appear to be half size (lots of missing / bad graphics). It also seems to use some flip modes our video doesn't support yet (looking into it). There is also likely some 'maths' protection, as the game currently has no collisions. I'm hoping this turns out to be the same as Blood Warrior etc. Otherwise, it boots and runs attract mode, at least for a while. I'll look at some of the remaining emulation issues tomorrow. Dox has told Guru to double check the graphic roms.
- 23rd August 2009: David Haywood - Raprogressing: Dox and myself have made significant progress on B.Rap Boys over the last couple of days, although there is currently very little to show for it. Basically the protection devices supplies 29 tables to the game, decrypting them from it's external ROM. Dox has been running custom code on the PCB to dump these tables to the screen. He took photos of them (nearly 1000 photos..) and I've been analysing them, and working out how they're decrypted from the external ROM. A couple of minutes ago I completed decrypting the final one, and while the code is still very ugly it does now successfully decrypt all the tables used by B.Rap Boys (Shogun Warriors is additional work, because it uses some different encryption keys). Unfortunately this doesn't actually get us very far yet. B.Rap Boys currently only requests 2 tables, then dies. There is obviously something else we're not understanding about the protection, but it isn't quite clear what yet. Some tests on the hardware have revealed a couple of things we don't handle, but the results are confusing as they don't actually solve the problem we're seeing. The main code is sitting in a loop waiting for an address to change to a pointer to some code. The protection device writes back pointers into RAM after copying the data, and the write address can be offset when the MCU command is sent. However, the writeback address isn't set to an address the game code is actually checking and therefore nothing happens. If I force it to write it to an address where the game code looks then the game executes the code from the 1st table, requests a 2nd one, then a 3rd one, then dies. Getting the actual writeback addresses correct appears to be very important. The good news is that I'm now 99.99% sure we have all the actual data we need from the board, and actually getting B.Rap Boys working from this point is just a case of understanding the finer details of the protection device. Not easy, but several magnitudes more workable than it was before (another dev could now quite easily pick up what we have, with no hardware access and work it out given enough time and understanding).
- 0.133u1: Calc 3 MCU update [David Haywood]: Shuffled a few things around based on new findings. Added an extra decryption table used for the Brap Boys startup code (still doesn't do anything interesting). Noted that one of the unknown parameters for the MCU Init command is where it reads / writes EEPROM data from. Noted that an additional parameter in the MCU commands may cause further displacement of the writeback address, as BRap Boys seems to rely on this (needs further testing) - added a hack for now so that BRap Boys places the writeback address of the initial table somewhere that causes it to get executed.
- 10th July 2009: David Haywood - Dox hooked a memory viewer into the already modified code, and tested it on the real hardware. It's interactive, and can be told to display whichever part of memory we're interested in. The protection device works by writing blocks of data to RAM, and then writing a pointer to the start of that block of data to a given address. Here we see the memory where one of the pointers is written. We've also verified that the data at this address (and various other addresses) is valid, but the camera batteries died (typical). 207fe0 is actually the first address set by the game for the data uploads, what's interesting about this is that the memory being shown is not that of the first upload, but a later one, for the IRQ code. The same address is reused. Further study of the placement of the tables would seem to indicate that they're uploaded after the previous one, and that there is a special command (with 0 length table) which resets the write address back to the initial value. Some of the other data (not shown due to camera issue) also confirms that in addition to the known 0x40 byte decode tables on each block, there are also some bitswaps. The next challenge will be charging the camera batteries. The challenge after that will be comparing the data with the tables in the data rom, and figuring out the various bitswaps for the blocks of data we can see. After that, we can try requesting different blocks, and doing the same. Each game has around 30 blocks of data that will need decoding, as stated before, the first target is Shogun Warriors, Brapboys will follow if that works. Update: Using screenshots from the memory viewer I managed to decode some of the blocks (and hardcode the one I couldn't fully understand the scrambling on). This has allowed Shogun Warriors to progress further into the game. There are still MANY tables to extract tho.
- 7th July 2009: David Haywood - Alien Code: The first step to running tests on any PCB is to be able to get your own code running on the PCB. Some PCBs have active prevention against this (the MCUs / protection devices performing full rom checks, preventing modification for example). The good news is that the Kaneko board appears to have no such protection. As I mentioned before, Shogun Warriors looks like an easier first case to emulate, and understand the CALC3 device with, so that's where work will be focused. Of course, Dox didn't have a Shogun Warriors board, only a B. Rap Boys one, and the alphanumeric sprite tiles are in a different place on both games. For this reason, it was necessary to modify the Shogun Warriors ROMs to work with the B.Rap Boys alphanumeric sprites and run that modified ROM on real hardware. Getting such a modified ROM to run on real hardware, in a stable state, was always going to be an important step in being able to test and understand this, so I was very glad when Dox sent me the following screenshot this afternoon. It's not much, but this is a slightly modified version of the Shogun Warriors program roms running on a B Rap Boys PCB, displaying the test menus using the graphics from the B Rap Boys ROMs. You can actually boot / run Shogun Warriors, but with the B.Rap Boys graphic roms it isn't much to look at, but, it's reassuring to know, as one of the possible avenues of investigation will be to put debug hooks in the code at various points. Dox will be throwing together a quick memory viewer application to run on the board, after which we'll view some addresses and I'll attempt to interpret some of the data returned. I can't give an estimated time on this, but this is positive progress so far.
- 27th June 2009: David Haywood - There is (hopefully) a B. Rap Boys PCB on it's way to Dox as we speak. Assuming this arrives in good working condition, I've prepared an initial piece of test code which will convert it to use the Shogun Warriors main program and MCU data rom and BRapBoys graphic roms for the test mode screens. I'm doing this because Shogun Warriors looks to be an easier test case, and does more right now. Mask ROMs can't be reprogrammed / replaced as easily, so reworking the Shogun Warriors code to look in the correct place for the fonts in the BRap Boys graphics was the easiest (although still rather convoluted) way of doing things. Assuming that test works, I'll modify that code to display a few useful pieces of information on the screen, and hopefully be able to produce a piece of rom code which still calls the protection routines going into Shogun Warriors test mode, but does not depend on the resulting code. From that point, I'll be able to modify it to send different commands, and look at the results, and probably put the B-Rap Boys MCU data rom on the board, and do the same for that. This will enable me to figure out how the data is fully decoded (and hopefully where it gets put) and maybe one or two other details about the chip. After that, I'll take a look at the maths / collision box side of things, but I have a feeling that will be the same as Blood Warriors anyway. The 'Calc' test B Rap Boys does at startup doesn't appear to be maths related, it's just waiting for the required status flag from the MCU to say that the initial block of code has been decrypted. Until it has been, the game won't progress past that point. Assuming everything works, the first thing you're likely to see here is progress on Shogun Warriors, with B Rap Boys following slightly later.
- 9th June 2009: David Haywood - Shogun Warriors / B Rap Boys: Due to a request from an actual friend (and the fact that any progress on these will benefit more than just MAME) I decided to take another look at the protection issues with these games. The MCU is on the decapping list, so, eventually (assuming success) it will be decapped, and emulated properly, however, the type of CPU is a completely unemulated one, so even with decap results the process could be quite long, and a previous decap attempt failed to reveal anything useful. With that in mind, knowing roughly how the protection works beforehand will no doubt help in interpreting the results at the very least. One of the biggest mysteries with them was the format of the external MCU data rom. It has been known for a long time that the games can be romswapped, so everything specific to each game must be in the external roms (including the protection data) but, unlike the later Kaneko games (Gals Panic 3, Jackie Chan, Bonk's Adventure, Blood Warrior etc.) the format of the MCU data rom was unknown, it was even speculated that it might simple be the entire (encrypted) external program rom for the MCU after the original decap results didn't turn up what was expected (as it turns out, it's not, there is definitely internal rom, this is purely data). The newer Kaneko titles had a simple encryption across the entire MCU data rom, a 0x100 byte encryption table of values to subtract, that looped over the rom. The games would then request the MCU copy blocks of data from the decrypted ROM into the game RAM. Once it was understood (aside from not knowing where 4 tables on Bonk's Adventure really come from) it was pretty simple. Despite being earlier, the protection on Shogun Warriors and B Rap Boys is more advanced. (I can only speculate that they dropped it due to it being more complex to program) It still works in a similar way, sending commands to copy tables, and it also still appears to have the math unit (can be used for hit box detection, random number generation etc.) but there are some subtle but important differences when it comes to how the tables get copied, and how the external data rom is processed. Unlike the later games you can't simply apply a 0x100 byte table to the entire rom. The rom was very mysterious because parts of it didn't even look encrypted, and there were clearly variations on an encryption schemes across the entire ROM with no logical start / end points for each block. Andreas had already established that some _very_ old code that had been trojaned out a Shogun Warriors board (in a failed old attempt) could be found in the external rom by applying a 0x40 sized table to a very specific block of data, but beyond that nothing was clear. We were even unable to determine how the location of that block in the rom related in any way to the commands the game was writing. After a significant amount of work (and a long time after... I first looked at this when the Jackie Chan progres was on my blog here) I noticed a few additional patterns in the rom, and started testing a few things. Based on a some observations I cam up with a theory that the external rom was structured as a kind of 'linked list'. The first byte in the rom is the number of tables it contains, followed by some information about that table, and an offset to the start of the next table. In testing this theory it appeared to be mostly correct, however, I encountered a few hurdles. Some of the blocks appeared to be in a different 'mode'. The location of the length of the block (and thus the offset to the next block) wasn't stored in the expected location. It turned out that this 'length' parameter can also be offset by another parameter, which is also used to specify the length of an alternate 'inline' encryption table. I put together some code, tested it with both games, and found that I could now split the MCU roms into logical tables, with parameters for each table. In both cases there was an additional 0x1000 sized block at the end, not specified in the table list, and the same on both games. I don't know what it's for, and can only speculate that it might be related to the actual encryption tables used somehow. From this point it became much clearer what the game was requesting. Shogun Warriors made a request to the protection device for command '0x19'. With the proper processing of the table it was obvious that this meant table 0x19, which was indeed that initial startup code that Andreas had managed to find before. It also became very obvious that our current communication with the MCU was wrong, and that it could specify multiple transfers in one command. Unfortunately this is where progress, for now, stops. The problem being that every single one of the blocks of data encoded can have it's own 0x40 byte decryption table (and additionally some bitswaps?) and for very small blocks, working out an encryption table that's only 2-3 times smaller than the table being decrypted is nearly impossible without reference data. The 'key' specified in the header of each block is simply 1 byte, the decryption tables are 0x40 bytes, and I can't see any relationship between them nor the previously mentioned 0x1000 sized block at the end. It's progress, good progress even, with access to a working board trojaning and simulating the rest of the protection will be _much_ easier with this newfound knowledge, it should also help immensely for processing the decap results. I don't know which will happen first. B Rap Boys shows nothing new because the initial block isn't decoded, and it might be doing some check on the maths unit too.
- 0.131u2: MooglyGuy merged memory maps and cleaned up some comments in Kaneko16 driver.
- 0.128u4: Kaneko changes [David Haywood, Andreas Naive]: Added Simulation of Toybox external data rom decryption. Converted Blood Warrior, Bonk's Adventure, Great 1000 Miles Rally 1+2 to use the new code.
- 0.127u6: DITraI4D0 added new tilemap scroll position function to video\kaneko16.c (is it different for expro02 and better to fix current one?).
- 0.122u8: RansAckeR improved dipswitches according to manuals in Kaneko16 driver.
- 0.113u1: Sebastien Volpe improvements to the Kaneko16 driver. All the protection data should be correct now.
- 0.106u3: Massive dipswitch update to the Kaneko16 driver [Brian Troha, Guru, Yasuhiro Ogawa].
- 0.105u1: Removed machine\kaneko16.h.
- 0.102u1: Several fixes for the Kaneko16 driver [Pierpaolo Prazzoli]: Fixed tilemap priorities. Fixed some sprites priorities. Added some missing coin counters. Added right palette filling for games using sprite type 1. Swapped berlwall and berlwalt sets as per SebV notes in the source code.
- 0.97u4: Aaron Giles fixed OKI6295 sound banking in the Kaneko16 driver.
- 0.91: Sebastien Volpe fixed kaneko16.c which was broken in 0.90u4.
- 0.90u4: Kaneko update in preparation for data from Blood Warrior [Sebastien Volpe].
- 0.88u2: Added machine\kanekotb.h.
- 0.86u4: Added machine\kaneko16.c/h. Sebastien Volpe reorganised and cleaned up the Kaneko16 driver and related drivers splitting protection related code into a separate file (machine\kaneko16.c).
- 20th October 2002: Brian Troha added information about Great 1000 Miles Rally to the Kaneko16 driver.
- 0.56: Luca Elia fixed rowscroll in Kaneko16 games.
- 22nd September 2001: Luca Elia added correct linescroll emulation to the Kaneko16 driver.
- 0.53: Added includes\kaneko16.h.
- 0.36b15: Added kaneko16.c driver and vidhrdw\kaneko16.c.
|Versione per la stampa
Link diretto alla scheda del gioco