1

ROM Hacking Discussion / Re: Help with recompressing sprites with Lunar Compress?

« on: June 12, 2019, 01:28:03 am »

Sniff is a brute force tool, so the combo file it can create is mainly just for looking through to quickly find the graphics you want.  Once you find them, you look at the file offset they're at then check in the log file to get the starting address in the ROM for the compressed structure that had those tiles.

At that point, you'd normally use decomp to extract just that structure to a file, edit it, and then you can use recomp to put it back.  Although in your case, you may want to copy your already modified tiles into that file from the combo file with your tile editor.

You'll probably also want to compress it to a separate file first just to check if the compressed size is going to be the same size or smaller than the original. 

2

Personal Projects / Re: Secret of Mana: Relocalized

« on: January 27, 2019, 06:51:19 pm »

If anyone can point me in the right direction for getting in there and editing any/all of this, I would be happy to make new tiles. Possibly an entirely new logo out of them.

You can grab Lunar Compress from https://fusoya.eludevisibility.org/lc/, then to extract and reinsert on a ROM with a header you'd just use:

decomp.exe som.smc title.bin 1CEA00 6 0
recomp.exe title.bin som.smc 1CEA00 6 0

Though you might want to recompress to a separate file first just to compare the compressed size with the original (with unedited data you'll get the same compressed size as the original, but of course with edited data all bets are off... you can check with something like recomp.exe title.bin titleC.bin 0 6 0).  If it ends up bigger, you'll want to track down the pointer so you can move the data somewhere else.

3

ROM Hacking Discussion / Re: Kirby Super Star Rom Expansion?

« on: August 10, 2018, 08:39:34 pm »

Just to check in, what would 1MB be in a decimal?

0x100000 bytes in hex = 1048576 in decimal.

And I would need to only insert 1MB as the offset 00 or just 0, (BTW, I'm using Hex Workshop)?

Insert 1MB of bytes at offset 0x300000.  The value of the individual bytes doesn't actually matter and it'll probably treat 0 the same as 00, but you can enter 00 if you want.

Also would I need to just do that and change the value of $D1 to 04?

Yes.

Would "the original area being accessed already" mean that there is save data already stored?

It'd just mean the original game was already accessing ROM data from those banks.  With the original bank setup, there's 2 different addresses that could have been used by the game to read any particular byte.  For example, $00:8000 and $C0:0000 SNES access the exact same location in the ROM file (PC offset 0).  There are sometimes reasons a game will use one address instead of the other (which I won't get into), but this modification is betting on the chance that they didn't try to read from banks A0-BF as they can read the same data from F0-FF.  *If* that turns out to be true, it means you're free to permanently redirect those banks to new space.

When I would have to try again with expanding a different bank, would I still keep the edit to $D1? (Sorry for all the questions, I just have a few questions after my previous attempt at expanding the rom failed)

No, you'd have to do something a bit different for those.  I wouldn't even bother if this one fails, because if these banks were already being read from then chances are the lower ones are too.


I should probably mention that I already went and tried applying the expansion change for banks A0-BF to the ROM and the initial results looked promising.  The game ran and I played around a bit in the first level.  You're still going to want to playtest through the whole game though just to be absolutely sure that it's all going to be ok with this type of expansion.

4

ROM Hacking Discussion / Re: Kirby Super Star Rom Expansion?

« on: August 04, 2018, 10:04:20 pm »

By using an SNES tracer/debugger to look for writes to those registers I mentioned above.  Since I already did that bit for you, you can just use the PC offsets I listed to try making those edits using just about any hex editor.

5

ROM Hacking Discussion / Re: Kirby Super Star Rom Expansion?

« on: August 03, 2018, 03:36:14 am »

Games that use the SA-1 chip can technically go up to 8MB (64 mbit).  However, ROM access is controlled through the chip using registers $2220-$2223 to allow for bank switching.  The low bits set where to get banks C0-CF, D0-DF, E0-EF, F0-FF while the high bit lets you choose if banks 00-1F, 20-3F, 80-9F, A0-BF will mirror the same place that the first 4 areas do or just get fixed to the first 4MB of the ROM.

That means ROM expansion for an SA-1 game can sometimes get tricky.  Ideally you'd want to be able to access your expanded ROM data without messing with banks that the game is already reading ROM data from, but also without having to fall back on writing ASM to dynamically switch banks to access your data then switching back before the game needs it again.

So based on just a very quick glance with an SNES tracer, I can see ROM banks 00, 01, 07, CA, CB, D1, EF, F0 being accessed.  There's probably lots more, but it looks like there's a chance they may not of used many of the "LoROM" type banks.  So if I were you, I'd try the following:  at 0x300000 PC in the ROM (assuming it has no copier header), insert (NOT OVERWRITE!) 1MB of zeros.  Yes, that will move the last 1MB of the existing ROM to 0x400000 PC.  This is going to be an unusual expansion for an SNES game.

Next, we need to find where the game sets up the banks.  If you're lucky they just set it up once and leave it that way.  A quick trace gave me this:

$00/80C3 9C 20 22    STZ $2220  [$00:2220]   A:00A0 X:1FFF Y:0000 D:3700 DB:00 S:1FFF P:eNvMxdIzC
$00/80C6 A9 01       LDA #$01                A:00A0 X:1FFF Y:0000 D:3700 DB:00 S:1FFF P:eNvMxdIzC
$00/80C8 8D 21 22    STA $2221  [$00:2221]   A:0001 X:1FFF Y:0000 D:3700 DB:00 S:1FFF P:envMxdIzC
$00/80CB A9 02       LDA #$02                A:0001 X:1FFF Y:0000 D:3700 DB:00 S:1FFF P:envMxdIzC
$00/80CD 8D 22 22    STA $2222  [$00:2222]   A:0002 X:1FFF Y:0000 D:3700 DB:00 S:1FFF P:envMxdIzC
$00/80D0 A9 03       LDA #$03                A:0002 X:1FFF Y:0000 D:3700 DB:00 S:1FFF P:envMxdIzC
$00/80D2 8D 23 22    STA $2223  [$00:2223]   A:0003 X:1FFF Y:0000 D:3700 DB:00 S:1FFF P:envMxdIzC

Note that it seems there's also a LDA #$01 STA $2221 at $DBF0 SNES, which you might want to keep in mind if you play with things later.

Anyway, change the byte at 0xD1 PC (or $80D1 SNES, again assuming no copier header) from 03 to 04.  Then try playing through as much of the game as you can to see if any problems show up.  If everything seems fine, congrats!  You can access your new 1MB of space at $A0:8000-BF:FFFF SNES (32KB LoROM type banks).  You could possibly go up to 6 or 7MB this way by playing with 20-3F and 80-9F along with inserting space at the required locations while setting the right registers, depending on if the game accessed those areas already or not.

If it isn't fine, well...  the original game probably accessed that area after all.  You could try messing with one of 20-3F or 80-9F instead, but I doubt your chances would be any better.  You may just end up having to do dynamic switching with ASM in this case, though you'll have to know what you're doing.


For testing, just be careful which emulator and version you use.  I'd suggest Snes9x 1.54 or higher (older versions do not fully implement those SA-1 registers).

6

ROM Hacking Discussion / Re: How to edit WRAM data in the rom?

« on: April 05, 2017, 06:04:19 am »

Your mistake is in assuming the RAM is part of the ROM.  It's not.  WRAM is temporary storage that goes away when your SNES is turned off.  Lunar Address is assuming you know that, and is just giving you the ZSNES savestate location in case you want to play with it that way (hence the "ZSNES ZST" text description under the address).

Anyway, if you want to know where the value is coming from you'll want to use a SNES debugger/tracer.  You can either run a trace and search it for the RAM address in question to work out what ROM address the value was originally loaded from in the code, or set a breakpoint on the RAM address to pause code execution when it's modified and hopefully what you want is just a few bytes before that.

You may need to hunt a bit though, as the first few writes may be for something unrelated as the game might first clear the address, or use it for displaying a title screen, or whatever.  Reverse engineering skills and knowledge of 65816 ASM are a plus for something like this.

7

ROM Hacking Discussion / Re: Feasibility of a Lua based real time game editor

« on: October 21, 2016, 04:18:32 am »

Another possibility is just integrating the emulator with the editor.  Lunar Magic for example allows loading Snes9x or BSNES via Alcaro's LMSW dll to draw directly within LM's level editing window.  It monitors the level tile layout in LM to pass on to the emulator, effectively making it possible to edit a SMW level as you play it.

LMSW's source is out there if you want to take a look at how that can be done.  While it's more work and the feasibility depends on the game, it can be fun to play around with.

8

ROM Hacking Discussion / Re: Lufia-Patches by Artemis

« on: October 13, 2016, 05:24:29 am »

And a bug report for lunar compress 1.80 (headered rom):
decomp lufia2.sfc daos.broken.bin 20121D 8 0

Real data is 6660h bytes. Tool makes corrupted 6440h file.

Er, where did you get 6660 bytes from?  I tried plugging that address directly into the game's decompression routine, but it just spat out the exact same 6440 bytes that Lunar Compress does...

9

Newcomer's Board / Re: legalities are not the topic

« on: October 13, 2015, 05:56:35 am »

The best way that I see to get extended/custom stuff added in is to either FORK the original repository AND KEEP THE CODE OPENLY ACCESSIBLE AT ANY TIME (which is what GitHub and other source code respositories do pretty well) or to submit a PULL/MERGE request where you submit patches/updates to the original code for approval by the original authors of ZSNES/SNES9X.

Just so you guys are aware, restoration of Snes9x's 8MB ExLoROM support along with the fix for the SA-1's MMC register from my build were both added to the Snes9x repository a couple years ago.  So unless something changes, they'll be in the next official release of Snes9x (whenever that is).

I flagged that hack and the 'Best Hack Ever' for Super Mario World since both are emulator-specific hacks.

Demo World TLC for SMW does *NOT* use an emulator specific hack.  The 6MB ExHiROM map was already used in Tales of Phantasia.  DWTLC can and has been used on the real SNES.




As far as accuracy goes, it's already been explained that the real SNES has no concept of LoROM/HiROM/etc.  The console itself couldn't care less what kind of map you want to use so long as you stick to cart mappable addresses.  Which means there's really nothing stopping someone from adding support for a map like ExLoROM to a flash cart and playing it on their SNES.

The coprocessors have their own limits regarding ROM size, but that's already been touched on.

10

Programming / Re: SA-1 Chip Bank Swapping?

« on: March 02, 2015, 01:08:38 am »

Just remember there's a few things to watch out for with the SA-1 and current emulators if you're going to play with bank switching:

Snes9x 1.53 and lower ignores the high bit of the MMC registers ($2220-$2223)... it just pretends the bit is always on.  This means $00-$3F:8000-FFFF, $80-$BF:8000-FFFF will always be mapped to the same area of the ROM as $C0-$FF:0000-FFFF.  It doesn't really stop you from accessing all 8MB, but it does mean you can't do something nifty like having all 8MB mapped in at once (which is normally possible by setting the 4 MMC registers to 4,5,6,7).  I believe it's been fixed for the next version of Snes9x, whenever it comes out.

In ZSNES, the first 128KB past the 4MB mark of the ROM is being used internally by the emulator as the SA-1's RAM (and possibly some bits right at the 5MB mark if the game uses character conversion DMA, can't remember the specifics on it).  But as long as you don't bother using those areas of the ROM, you can expand up to 6MB.


Both issues were corrected in my 8MB builds of those emulators a couple years ago.

11

News Submissions / Re: Utilities: We got some new SNES emulators

« on: January 13, 2013, 03:52:15 pm »

There's a problem with this new SNES9x.

It now associates with .BIN file types, and now my PlayStation and PlayStation 2 ISOs, as well as my Genesis ROMs, all appear as SNES9x files. I have no knowledge of how to change this, either. It's quite upsetting.

It's apparently something from the official 1.53 build (see http://www.snes9x.com/phpbb3/viewtopic.php?f=8&t=5710).

I could either add the new code for OV2's icon fix to this build, or move it to a menu item as gocha did.  Although I'd be all for removing the .bin file extension from the file filters for both emulators anyway.  I never did like seeing .bin files everywhere when browsing for SNES ROMs.

12

News Submissions / Re: Utilities: We got some new SNES emulators

« on: January 10, 2013, 10:45:21 pm »

Just to clear up some confusion:  ExHiROM is sometimes called the "tales" map, as it's simply the 6MB ToP map extended to 8MB (minus a bit for SNES RAM banks).  Which is why if your emulator can run ToP, it can usually run SDW:TLC as well since they use the exact same map.


The official build of Snes9x already supports 8MB ExHiROM, 6MB ExLoROM (see note 1), 8MB SA-1 (see note 2), and 8 MB SDD-1.

The official build of ZSNES already supports 6MB ExHiROM, no ExLoROM, 4MB SA-1 (or 6MB with glitches, see note 3), and 6MB SDD-1.  It will outright refuse to load any ROM file larger than 6MB.

Note 1: Snes9x 1.39a and on already supported 8MB ExLoROM, but it dropped to 6MB in 1.5x (most likely by mistake when someone cleaned up the Map_JumboLoROMMap() function without realizing what it was for).
Note 2: Snes9x didn't fully implement the SA-1's bank switch registers, specifically the high bit.  If the bit is off, it's supposed to set the ROM map for 00-3F/80-BF to specific locations within the first 4MB of the ROM without affecting where you point C0-FF.  You can technically still access all 8MB without it, but it requires constant bank switching and could be bothersome depending on what you want to do with the map and the existing game you're working on.
Note 3: ZSNES allows 6MB with SA-1, but part of the array that holds the ROM was reused for the SA-1 RAM and some other work table.  So you lose the first 2 ROM banks past the 4MB mark, and potentially corrupt others if you use character conversion DMA.


The custom builds are to fix the above issues, and to make sure you get 8MB for all 4 ROM types in both emulators.

13

ROM Hacking Discussion / Re: A problem with using Lunar Magic...

« on: October 26, 2012, 01:16:36 am »

It's a bug in older versions of Wine (MDI windows not maximized the way they should).  They fixed it about 4 years ago.

14

News Submissions / Re: Utilities: NINJA 2.0 July 26 Beta

« on: August 02, 2006, 05:33:50 am »

*mulls the problem over for a while, then starts LA, minimizes it, closes it while minimized, and starts it again*

Ah... umm... guess I should have checked for negative coordinates after all.  Looks like a new version will have to be released.

15

News Submissions / Re: Utilities: NINJA 2.0 July 26 Beta

« on: August 02, 2006, 12:38:51 am »

Sorry, but I probably didn't get that email.  My old moon.co.jp address turned out to be somewhat unreliable, which is why I stopped using it. 

Anyway, I've never heard of that problem before, nor have I ever experienced it myself (and I've used the program quite frequently over the years...  I'm on my second machine and third version of windows).

If the program's X/Y screen coordinate settings from the registry were set outside your current desktop area, that could cause what you're describing.  Except there are already checks in the program for this, in case someone switches screen resolutions between program sessions.  Although it might not be checking for negative coordinates...

But if this happened pretty much every time you ran the program and you always had to delete the keys to get it to display again, I would suspect possible interference from any extra window management software you may have installed.  Deleting LA's X/Y registry keys will cause the program not to even try setting it's own position the next time it runs.

16

News Submissions / Re: Utilities: NINJA 2.0 July 26 Beta

« on: August 01, 2006, 04:39:28 pm »

Agreed. Number one on that list is LunarAddress. For some damn reason is constantly gets corrupt keys and fails to start. It's a nice utility, but I still brand it crap since it hardly works.

That's strange...  did you get any sort of error message from windows to indicate that it was a registry problem?

And would you mind using regedit to export the program's registry keys to a file and sending it to me (or just posting the contents)?  You can find the keys in [HKEY_CURRENT_USER\Software\LunarianConcepts\LunarAddress].