 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,519,115 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
05-03-24 05:19 AM |
|
| Guest: Register | Login | |||
| Main - Posts by krzy |
| krzy |
| ||
|
Newcomer Level: 4 Posts: 1/3 EXP: 247 Next: 32 Since: 02-22-18 Last post: 109 days Last view: 99 days |
Hello,
I succesfully make hardware version of Zelda Legend of the Link & Super Mario All Stars. Fortunatelly, they use only very small subset of MMC5 so can be made on cheap FPGA, without need of canibalizing any existing carts.          
However, there is some pain in the ass with both of the games - while it is no problem to have 1MB, 2MB, 4MB or even 8MB PRG-ROM, having more that 512 kB of CHR-ROM (which is in fact CHR-RAM) is annoying. 1. SMB All Stars - SMB3 & SMB2 USA uses MMC5 extended attribute table (different banks for sprites & background). I found that accidently after long time of trying to make graphics display correctly. I also found a small bug in this game - it was not present in the version from`5-4-17` but is in the newest one `10-15-17` -> the game uses one of the bit from EXRAM to determine if the intro with curtain should be displayed or not. Unfrotunatelly, if EXRAM is battery backed (and it is), intro will be displayed only first time the cartridge is put into console or if battery i removed. 2. Zelda Legend Of The Link - this game writes to CHR-ROM at $0000-$1fff, so if it is CHR-RAM without write protection, title screen and most of the tiles will be garbaged. |
| krzy |
| ||
|
Newcomer Level: 4 Posts: 2/3 EXP: 247 Next: 32 Since: 02-22-18 Last post: 109 days Last view: 99 days |
Well, so then MMC5 must not battery backup EXRAM if the curtain is shown every power up, because the game uses value at $5EFB to determine if curtain should be shown or nor.
My FPGA uses external RAM (battery backed) to simulate EXRAM so I had to patch the game to ignore value at 5EFB to shown the curtain. Also the iNES header of SMB All Stars claims that this game uses 64 kB of RAM but as I detected, only 32 kB is used. --- Well, I prefer to use CHR-RAM in place of CHR-ROM because I made an universal cartridge which can simulate almost any mapper (some of them can use CHR-ROM, some CHR-RAM or even both at once). The > 512 kB CHR is only hardware problem because there are no 1 MB RAM memories (or at least not in reasonable availabiliy/price). I succesfully patched SMB All Stars to only use 512 kB of CHR (after selecting game, it fills the CHR-RAM with the portion of RAM that is used by the game). It worked because every of the games in this pack does not use more than 512 kB. However, with Zelda it won't work as it needs access to the whole 1 MB at all time. So I ended in soldering two 512 KB memories one on top of the other ;D |
| krzy |
| ||
|
Newcomer Level: 4 Posts: 3/3 EXP: 247 Next: 32 Since: 02-22-18 Last post: 109 days Last view: 99 days |
There is a serious bug in this hack, that I am amazed that nobody has pointed out before: this game crashes instantly, when burned into real cartridge.
This does not only affect this particular hack but all other SMB3 hacks (with battery save feature added), based on this patch. I was trying to figure out what is going on and reproduce this behavior on emulator, and when WRAM at $6000-$7fff is initialized to all zeros, all FFs or some semi-random values, the game also hangs on emu. The direct cause of hang is this loop
that is never exit because neither NMI nor IRQ changes RAM[$010] to anything. On emu (and probably flashcarts), when the game is first RUN, there is no savestate file, so the WRAM at $6000-$7fff is probably initialized to: $6000-$60ff = $60 $6100-$61ff = $61 ... $7f00-$7fff = $$7f to mimic the open-bus bevaviour, which satisfies the game. Though on physical cart with battery, initial WRAM content is unpredictable. Even if you first initialize the RAM to the above values with some external cartridge-programmer (like kazzo), when user decides to remove the battery, we still have problem. I did not analyze the logic of this patch, so I don't know how to fix it. You probably should have some CRC of the WRAM to determine if contains good data and if not - clear it.  |
| Main - Posts by krzy |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 42, rows: 57/57, time: 0.218 seconds. |