![]() In SNES you have banks that are 64KB large and going between them and having data between them must be accounted for and such. The reason it was not made for SNES is because hacking the SNES version of UMK3 would be much harder. Man if only they originally made this game for SNES. It wouldn't be compatible enough to run SSF2, but you could at least use the SSF2 mapper already in emulators and make original carts cheap. I wasn't really thinking when I wrote that, adding only one other 670 would only address 64M in 8 banks. With your SSF2 compatible mapper I take it you mean you could build your own SSF2 cartridge with it that would be capable of running SSF2 but not 100% compatible feature wise with what the SSF2 mapper was really capable of? It would be neat to build a cartridge for this hack. Well maybe Tommy or the hack author will tell us for sure if it's 80M with no bankswitching. All it takes is another 74670 (2x 670, 1x 139) to get a reduced feature SSF2 compatible mapper. I also came up with a simple mapper configuration which when combined with the decoder will allow you to stay within the cart area. This could be the case since there is exactly 80M if you add the cart area and entire reserved area together but I presume it'll conflict with the 32X.īuilding a cart like this would be easy, you just need a single 74139: Shouldn't it be possible to adapt the game to use it since the SSF2 mapper is probably even more flexible? It would have been ideal if the SSF2 mapper was used. That's why I assumed there was no bankswitching and just a huge chunk of ROM as I have been told that it's relatively easy to make a 64M Genesis cartridge so I figured perhaps 80M is possible. Apart from propriety I don't know why this hack doesn't use SSF2's mapper which can support at least 256M and since it's an 8 bank register file is a great deal more flexible. I think the emulator just implements some simple custom bankswitching (from the game size guessing one fixed 16M bank and a switchable 16M bank with 2 bits implemented). WOW, this is great news! Now if there was a flashcart big enough to make this work, that would be great! We really need a larger MD-PRO (like 128mb), or especially, larger Megacartĭoes the cartridge do it's own address decoding and just maps 80M of ROM starting at address 0? I've always wondered how that hacked ROM works since you need a special build of an emulator to play it. Posted: Fri 4:13 am Post subject: Re: 80M Big Size Genesis Ultimate Mortal Kombat Trilogy (it is not 100% stable yet, sometime it hang) It is very good game ! Posted: Thu 10:53 pm Post subject: 80M Big Size Genesis Ultimate Mortal Kombat TrilogyĪfter long time development, I run this game on real hardware. Profile Log in to check your private messages Log inĨ0M Big Size Genesis Ultimate Mortal Kombat Trilogy XDelta is good cause it takes into account moved data so it don't copy original :: View topic - 80M Big Size Genesis Ultimate Mortal Kombat TrilogyįAQ Search Memberlist Usergroups Register #Ultimate mortal kombat trilogy rom hack 18 PatchThe IPS patch is 3,81 MB zipped and the xdelta patch is 1.33 MB zipped. I wish it were complete so we could add it to the site.Įdit 3: You should consider switching to xdelta. ![]() Here's video proof:Įdit: Disregard, I thought this was a thread for Ultimate Mortal Kombat Trilogy.Įdit 2: Wow, great hack. ![]() Another reason this should be accepted is the game works on real hardware if a custom cart is made. I know the patch will be huge but I think the max of file size is 30 MB so it should be acceptable. PICODRIVE ENG version 1.35 (Symbian OS 9.1, 9.2 and 9.3 s60v3 smartphones) Gens version 2.12 (Hacked with support of roms over 4mb) ![]() Gens 2.11 (hacked with support of roms over 4mb) Here's a list of emulators I've heard are compatible with the hack. Now that there are more emulators that support this we should allow this hack on the main site. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |