93238011 visitors

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Revenant

Pages: [1] 2 3 4 5 6 7
Personal Projects / Re: Kirby\\\'s Dream Course editor (version 1.13)
« on: March 22, 2015, 06:36:35 pm »
Hey, this has users now. Thanks, Game Grumps.

v1.13 [2015-03-22]
Much faster multithreaded saving
Added loading/saving of individual level files
Increased maximum tile height from 31 to 49 and max level width/length to 100
  (so you can waste more tile memory. Note that 2D and 3D map area limits are unchanged)
Some more build/deployment improvements for OS X (thanks ConnorRK)
Settings now saved in system-standard paths (%AppData%, etc.)
Fixed buggy repainting of 2D map when scrolling horizontally
Fixed possible bad graphics pointers when saving European ROMs

March 23, 2015, 06:23:07 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Just posted an OS X build as well (thanks ConnorRK). Let me know how it works, especially if you're a pre-10.9 user.

March 29, 2015, 04:27:28 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Updated again, this time with just a small fix for graphical problems that rarely occurred when placing some slopes next to raised-up slopes.

Programming / Re: Geiger's SNES9X Tracing Issue?
« on: March 21, 2015, 02:06:38 pm »
That's because Geiger's debugger is broken.

I think the only reason it won't display or break on $C01C97 is that the game is marked as being LoROM, so it completely ignores the lower half of banks $C0-FF, even though SA-1 games use a completely different address mapping.

Programming / Re: Geiger's SNES9X Tracing Issue?
« on: March 21, 2015, 02:08:40 am »
The correct address is $C01C97, not $C09C97. SA-1 games do not mirror the lower half of banks C0-FF the same way normal LoROM carts do; the "LoROM / HiROM" distinction is pretty much meaningless for SA-1 games because the SA-1 maps ROM in both 32k and 64k segments to different parts of the address space.

ROM Hacking Discussion / Re: Screenshots
« on: March 18, 2015, 07:28:47 pm »
By the way, your repo seems to be missing the out and obj directories, which are needed for build. Not a big deal, but a fresh checkout will fail to build unless the user creates them by hand.

Whoops, I thought I had fixed that a while ago but never actually added the dummy .gitignores to the repo. Should be okay now.

Personal Projects / Re: Can't find 3 SNES SA1 games.. Odd??
« on: March 17, 2015, 11:09:29 pm »
I have them as part of the No-Intro SNES set.

Shin Shougi Club (Japan).sfc
Shougi Saikyou (Japan).sfc
Shougi Saikyou II - Jissen Taikyoku Hen (Japan).sfc

ROM Hacking Discussion / Re: Screenshots
« on: March 17, 2015, 07:17:58 pm »
Hmm.. I found  pinout for the FX2 chip. Here the ROM address bus to 21 bits. It turns out that addressing the chip is 2 megabytes. If production use decoder/multiplexer, then you can come up with something for the real hardware. Emulator is not a problem to increase the bus. But on the console itself is already hard.

It's sad, I wanted to make a full DooM with all levels and textures :-[ :-[ :-[

What about your debugger, it's very cool!  :D
When it can be already downloaded, and that hard work with SFX tracer (many lines) >:(

Interesting. I re-checked the bsnes source and the FX address bus is indeed more limited. At least Fullsnes seems to show that the address mapping on the SNES side can still go higher, so it may be possible to get creative and go past the FX's limit somehow (like using the main CPU to buffer textures/etc. into the shared RAM area, depending on how much of it is used by the game already). Would be interesting to experiment with.

mziab, mind sending me a pull request here? Those definitely sound useful (and ROM saving/reloading was on my todo list already, so it'd help me with that too).

There's a lot I plan to do with the original debugger GUI to make it more useful once I get some free time for it. I'll start a project thread and start posting Windows builds once it matures a little bit.

Site Talk / Re: Utility gives an error when I try to access it.
« on: March 17, 2015, 04:03:21 am »
Windows' built-in zip file support isn't that great. I second the 7-zip recommendation.

ROM Hacking Discussion / Re: Screenshots
« on: March 17, 2015, 03:47:26 am »
Does anyone know what is the maximum size of the ROM with chip FX? Is it possible to increase up to 4 megabytes?

Most SNES cartridges have a maximum ROM size of 4 MB (32 megabits), including all SuperFX games.

Speaking of SuperFX, I tweaked my silly little debugger a bit more a while ago

Right now each step shows the registers involved in the current and previous instructions. It's kind of ugly and it's not really useful until I get around to adding register editing for all architectures (another thing the original bsnes debugger was sorely lacking...)

Fun fact: the "step out" and "step over" buttons are disabled for SuperFX because I couldn't actually come up with a good way to implement them. The FX has a link register for storing return addresses, but it doesn't actually have "call" or "return" instructions, or even a stack. It's an... interesting architecture.

Personal Projects / Re: Kirby\'s Dream Course editor (version 1.12)
« on: March 11, 2015, 06:04:08 am »
I did plan to at least add a palette editor at some point (or at least post info about the palette data somewhere, since it's currently buried in an old email thread from a year or more ago...) To be the most useful that'd probably require me to not be lazy and actually load graphics from the ROM instead of using premade ones, which is definitely doable (especially since they use the same compression that the editor already uses for basically everything else) but I dunno if it's a terribly high priority or not.

Also, as cool as a tileset editor would be, I really can't see it being very useful, just because of the massive amount of work it would take to do any substantial work with it; most of the terrain graphics consists of literally hundreds of nearly identical-looking 8x8 tiles representing more or less every possible terrain combination. (The editor actually has to turn the 2D course maps into 8x8 tilemaps itself, which was painstaking to set up, to say the least...)

The sprite depth issue sounds like something I may be able to fix; there's a hash table for each hole that the game uses to determine the Z-order of Kirby's sprite based on his position. I might have to tweak how the editor generates it somewhat if it's causing issues with other sprites, but hopefully it should be easy to do. If you can send me a course file where this happens easily, that should be helpful.

March 11, 2015, 06:30:56 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Also, hello to anyone who found out about this via Game Grumps, because that apparently happened (talk about a pleasant surprise...!)

ROM Hacking Discussion / Re: Screenshots
« on: March 05, 2015, 01:17:32 am »

i don't really know what i'm doing

Programming / Re: SA-1 Chip Bank Swapping?
« on: March 01, 2015, 02:58:39 pm »
From what I remember from using it, the memory view in Geiger's doesn't really handle banks $C0 and up correctly (if at all) for LoROM games (which SMRPG is), so I probably wouldn't completely trust it to tell you whether or not you're doing stuff correctly with the SA-1.

Anyway, if you write some test data at offset $400000 (i.e. right past the end of the normal ROM), try writing $84 to $2222 ($400000 >> 20 == 4, and set the high bit to enable bank selection for banks 80-9F). You should see it from the CPU at both $808000 and $E00000 after that (and so on).

I'll post up a current build of my debugger in a bit, but I'm going out for now and I don't think I have one available at the moment.

edit: I should mention (since I forgot about this earlier) that writing to $2220-2223 always selects banks at $C00000 and up whether or not the high bit is set, so writing $04 instead of $84 in the above example will still map that part of your expanded ROM to $E00000, but not $808000; this may be better depending on what the original game code needs to be able to access at the same time.

ROM Hacking Discussion / Re: Problem with Turaco Editor
« on: February 28, 2015, 09:08:43 pm »
Can you post the actual error message? "It won't load" doesn't really tell us anything.

Programming / Re: SA-1 Chip Bank Swapping?
« on: February 28, 2015, 09:03:20 pm »
Use $2224 if your code is running on the main CPU, or $2225 if it's running on the SA-1.

Note that both of those registers are for mapping RAM, not ROM; see the "Super MMC" register info here for ROM mapping registers, which is what it sounds like you're after if you want to expand the ROM.

The Super MMC registers are always written from the SNES side, but affect the address spaces of both CPUs. The lower 3 bits select a 1MB chunk of ROM to be mapped into one of the four mappable address ranges and the high bit enables/disables bank switching for that range (and basically just uses the default mapping if it's disabled).

I have no idea what the SA-1 support in Geiger's debugger is like (I suspect that address weirdness is its fault, not something the game's doing), other than that it doesn't support stepping through code running on the SA-1, which is a pain. I have a custom version of bsnes that has more useful SA-1 debugging features; the support for it isn't as complete as I'd like, and I haven't been developing it much lately, but I can put up a current build if you think it would be useful :P

Site Talk / Re: Add the Wii U Platform for submissions
« on: February 06, 2015, 08:43:41 pm »
Whoops, I thought "second dot" was referring to the second in the list of consoles (which happens to be the Wii U). Blame sleep deprivation  :P

Site Talk / Re: Add the Wii U Platform for submissions
« on: February 06, 2015, 08:26:00 pm »
Look here, under Consoles (second dot).

That specifically says utilities are still allowed, which is what crediar was trying to submit.

Front Page News / Re: Utilities: Compress Tools upgraded to version 3.0
« on: February 06, 2015, 01:49:03 am »
According to the SMW-Construction forums, Kirby Superstar (SNES/SFC) is difficult to ROM-hack because HAL used 7 layers of compression. Can your tool decompress those layers?

There are already at least two other tools that can (with 8/16-bit Kirby games specifically in mind):
http://www.romhacking.net/utilities/1004/ (by me, a command-line utility; source available here)
http://www.romhacking.net/utilities/600/ (by Sukasa, a VB.NET DLL)

It's also exactly the same as some compression that EarthBound uses (for graphics? I have no idea) which I assume has had some tool support for it for ages now. (It's also extremely similar to Pokemon G/S/C's compression, as a fun fact!)

"7 layers of compression" is also some real wacky bullshit (ahem), it's really just the usual RLE and LZ77 with a few bells and whistles, and it's been documented and supported by other stuff for a while by now. It shouldn't be too hard to create a plugin based on my implementation if someone wants to (but keep in mind it has a maximum input size of 64kb :P)

It's an initialization problem? I thought it was due to some byte in the Music Handler having the same identity & address as the intended target in another bank, thus validating the checksum and turning the entire soundtrack into the theme from Grey's Anatomy.

As far as I'm aware, the entire problem is that Mega Man's (as well as Mega Man 2 and possibly others) sound routine expects the pulse sweep registers (and possibly others) to be in a specific state on boot and the Game Genie putting them in a different state for its own audio. Your suggestion would only make sense if it were specific GG codes causing problems for a specific game, and not something that is common to several of Capcom's games both with and without any codes.

Wouldn't it make more sense to just make the game initialize the regular sound channels correctly instead?

ROM Hacking Discussion / Re: BS Shockman Help
« on: January 22, 2015, 11:10:28 pm »
Sounds like it might be due to the fact that Satellaview games map SRAM to different addresses than normal SNES carts do. How easy that'd be to fix depends on how the game is programmed, but it's certainly possible.

ROM Hacking Discussion / Re: BS Shockman Help
« on: January 22, 2015, 07:02:49 pm »
Go to $FFD0 in a hex editor and overwrite the first ten bytes there with these values:

00 00 00 00 00 31 00 0A 00 00

Pages: [1] 2 3 4 5 6 7