 
 | Immagini disponibili:: |
|
| Immagini disponibili:: |
| Descrizione | ||
|---|---|---|
|
Nome romset gtmr2a.zip Anno di produzione: 1995 Produttore: Kaneko Questo gioco è il clone di: Mille Miglia 2: Great 1000 Miles Rally (95/05/24) Genere del gioco: Guida Categoria: Guida / Corsa | ||
| Emulazione | ||
|---|---|---|
Questo gioco funziona correttamente in MAME  In MAME dalla versione: .060 Salvataggio state: Non supportato Stato dell'emulazione: Buono Emulazione colore: Buono Emulazione sonoro: Buono Emulazione grafica: Buono Il driver di questo gioco in MAME è: kaneko16.c - Leggi il codice |
||
| Dati tecnici | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Questo gioco usa un solo schermo: Tipo di grafica: Raster Orientamento schermo: Orizzontale Risoluzione del gioco 320 x 240 @ 60.000000 Numero di giocatori: 1P Controllato con: Joystick Numero di pulsanti: 8 La scheda di questo gioco usa 4 CHIP
| |||||||||||||||||
| Dati Scheda | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Il ROMset si compone di 14 ROM (10 del set parent, 4 del set clone) Riferito alla versione MAME: 0.154
 : Gioco Parent : Gioco Clone : BIOS |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Informazioni | ||
|---|---|---|
| HISTORY
Mille Miglia 2 - Great 1000 Miles Rally (c) 1995 Kaneko. Un gioco di corse automobilistiche da Kaneko. - DATI TECNICI - Processore Principale : 68000 (@ 16 Mhz) Chip Audio : (2x) OKI6295 (@ 12 Khz) Giocatori : 2 Controllo : manuale Pulsanti : 8 - CURIOSITA' - Pubblicato nell'Aprile 1995. Questo gioco negli Stati Uniti è conosciuto con il nome di "Great 1000 Miles Rally 2 USA". Basato su una corsa automobilistica che ebbe luogo in Italia da Brescia a Roma e ritorno ogni anno tra il 1927-1938 ed il 1945-1950 chiamata '1000 Miglia'. La schermata di selezione dell'auto/tracciato usa un campionamento dal tema della US Olympic TV. - SERIE - 1. Great 1000 Miles Rally (1994) 2. Mille Miglia 2 - Great 1000 Miles Rally (1995) - FONTI - Rom del gioco. Immagini del cabinato.
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.
|
||
| MAMEINFO.DAT | ||
|---|---|---|
| Informazioni su gtmr2 0.84u5 [David Haywood] 0.60 [Stephane Humbert, David Haywood] < Italy > WIP: - 0.126u5: Guru added README for Great 1000 Miles Rally 2. - 0.125u7: Minwah added 360degree wheel (dial) input to GTMR, which is available when the Controller dip is set to 'Wheel', and Controls dip is set to '1P Side'. Note when Controls dip is set to 'Both Sides', 270degree wheel (paddle) input is used. - 0.123u4: Changed the 2x OKI6295 clock speeds to 2MHz. - 0.122u8: Added dipswitches 'Linked Operation Board Number' and 'Optional Mode Of Pedal Function'. - 0.99u9: Removed gfx3 region. - 0.90u3: Added clone Great 1000 Miles Rally 2 USA (95/05/18). - 14th January 2005: Guru - Great 1000 Miles Rally 2 USA (Kaneko 1995) arrived, purchased on Ebay. - 17th December 2004: Dumping Project - Randy have won on eBay a 'Great 1000 Miles Rally 2' PCB for trojaning. - 0.84u5: David Haywood added 'Mille Miglia 2: Great 1000 Miles Rally (95/05/24)'. Changed parent to clone 'Mille Miglia 2: Great 1000 Miles Rally (95/04/04)'. Renamed (gtmr2) to (gtmr2a). - 0.61: Added new gfx1 rom ($0). - 2nd May 2002: Nicola Salmoria fixed the graphics in Great 100 Miles Rally 2. - 0.60: Stephane Humbert added 'Mille Miglia 2: Great 1000 Miles Rally' (Kaneko 1995). - 29th April 2002: Stephane Humbert added Great 1000 Miles Rally 2 to the Kaneko16 driver, but it's missing lots of graphics due to a missing or bad ROM. - 18th March 2002: Guru - From Smitdogg and Taucher we have Great 1000 Miles Rally 2 (Kaneko 1995) for a redump. Current dump is very incomplete. LEVELS: 8 Other Emulators: * FB Alpha Informazioni su kaneko16.c (Driver MAME) 0.36b15 [Luca Elia] TODO: - 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 NOTES: - 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) Bugs: - bonkadv, brapboys and clones: Missing Sprite on Flip Screen. Tafoid (ID 04936) - brapboys, bloodwar: Playback lose sync. Tafoid (ID 04209) WIP: - 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. |
||
| Strumenti | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Versione per la stampa Link diretto alla scheda del gioco
|
||||||||||