News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

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 8 9 10
I definitely plan on reworking the memory viewer and other stuff; almost all of the debugger GUI is unchanged from the original bsnes debugger, but I'll be working on improving it as time goes on. I mostly wanted to get the actual debugging features and useful stuff ready before anything else.

There's an option for it in the Tools menu (next to the "capture screenshot" option). You can also bind it to a keyboard key. It'll wait until the next time a note plays and then dump the SPC to the "exported data" directory (which is by default the same directory as the ROM).

Do you know if blargg's modified 7z code was ever updated since v073?

Oh dear god I'll be trying this out as soon as possible.

Edit: Oop.  Missing libgomp-1.dll on launch.

Fixed. I basically threw the snesfilter (and other) plugins in at the last minute without bothering to check their dependencies (compared to the program itself), but it should run now. Sorry about that

Edit 2: Are we allowed to make feature requests at all?  Probably an easier one, but could we allow any button on the keyboard be used as a button assignment?  I know you have to use Shift + something to allow the shift key, but it'd be preferable if we could just use 'Shift' as a button.  Same thing with Ctrl.  I know later bSNES version allowed that, not sure if that's really a 'bad' idea or not though.

Feature requests are definitely welcome. I plan to play around and make some changes to the frontend eventually and changing how inputs are setup might be part of that.

That was planned as a counterpart to UPS soft patching, which is already part of bsnes and is already optional.

Two new projects! Hooray! (They're both forks of byuu's programs so I'm putting them both in this thread. Why not?)

bsnes-plus (or bsnes+) is a fork of bsnes (based on bsnes-classic) intended to introduce some new features and improvements, mostly aimed at debugging.

Screenshots: 1 2 3 4 5

What's new
"Step over" and "step out" buttons in debugger
Improved debugger UI with register editing
Redesigned memory editor and breakpoint editor
Improved handling of address mirroring for breakpoints (extends to the entire address space, not just RAM)
Real-time code and data highlighting in memory editor, with fast searching for known code/data locations and unexplored regions
Cartridge ROM and RAM views in memory editor for mapper-agnostic analysis
Enhanced VRAM, sprite, and tilemap viewing
SA-1 disassembly and debugging
SA-1 bus and BW-RAM viewing and (partial) usage logging
Super FX disassembly and debugging
Super FX bus viewing and usage logging

Non-debugging features:

Satellaview / BS-X support
SPC file dumping
SPC output visualizer (keyboards & peak meters)
IPS and BPS soft patching
Multiple emulation improvements backported from bsnes/higan (mostly via bsnes-classic)

Coming soon
On-the-fly ROM saving and reloading from the memory editor for quick hacking and testing
More keyboard shortcuts for menus, etc.
Automatic saving/loading breakpoints between sessions
Similar addressing improvements for cheats

See the project on GitHub for more info and source.

bsnes-plus v073+3a (Windows, 64-bit accuracy & compatibility)
bsnes-plus v073+3a (Windows, 32-bit compatibility)

xkas-plus is my fork of the xkas v014 assembler. Among other changes, its biggest new features are:
Assembling directly to an IPS patch
Table file support
SNES ExLoROM / ExHiROM support
Ability to export defines and labels to a separate file (supports FCEUX and VICE debug symbols or regular assembly includes)
Additional architecture/platform support:
    MOS 6502 (NES, C64, etc)
    WDC 65C02 and CSG 65CE02 (untested)
    Hudson HuC6280 (TurboGrafx-16 / PC Engine, untested)
    Sony SPC700 (SNES sound chip, syntax subject to change before release)

See the project on GitHub for more info and source.

xkas-plus v14+1 (Windows)

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.

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

News Submissions / 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): (by me, a command-line utility; source available here) (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.

Pages: 1 2 3 4 [5] 6 7 8 9 10