96290370 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

Didn't have the time or motivation to work on useful debugging stuff lately, so I spent a couple of hours banging this out instead.

I'll be rewriting the memory and breakpoint editors soon, and will probably release again after that. In the meantime, EmuCR has daily snapshots now (which I haven't tested at all, so try them and see, I guess).

The crash still happens with the latest git revision. I'll take a look later and see what's going on, thanks for pointing it out.

Fixed (see this commit + comments).

Here's an up-to-date build.

Are you aware of bsnes mercury? It includes Super FX over clocking.

I'm familiar with it, though I haven't used it before. Personally I'm not sure if SuperFX overclocking is the sort of thing I'm interested in adding to an accuracy-oriented emulator though.

The crash still happens with the latest git revision. I'll take a look later and see what's going on, thanks for pointing it out.

Site Talk / Tools mistakenly listed as DOS programs?
« on: May 17, 2015, 02:41:10 pm »

How many of the utilities currently listed as being for MS-DOS are actually command-line programs for Windows? I recall correcting this for xkas (or some other one of byuu's programs) a while ago but it seems like almost all of his other command-line stuff still has the incorrect OS listed, and it seems like dozens of other Windows command-line tools added in recent years were subject to the same mistake.

I feel like it's kind of important to get the distinction correct for two reasons - mostly because people searching the "Windows" category could potentially miss out on some very useful tools (particularly assemblers, data extractors/inserters and the like), and also because if someone were looking for programs to use in an actual DOS environment (which is unlikely, mind) they'd have to sift through who-knows-how-many programs that don't actually work as advertised because they're mislabeled Windows software.

Still slowly working on bsnes-plus in my spare time, but I also (finally) touched up xkas-plus a bit and added a link to binaries in the OP. Check it out!

Fun fact: KALE uses xkas-plus to generate limit-removing patches (in IPS format) that can be applied from the editor, as an example of how I've extended it to be useful for systems other than the SNES.

Nice! Missed this one. But about data: still we could have a diversification about read and read-written?

The usage stats actually do track reads and writes separately, it's only the memory viewer that (currently) uses the same color for both.

On a related note, I was recently discussing reworking the usage tracking, including adding more specific usage contexts (see this github issue for specifics). It'll most likely be an upstream change in bsnes-classic whenever that happens, but aside from that, I've also considered adding a way to customize the colors (including separate read/write colors if it'd be useful).

As for labels, I did plan to add support for those later on as well (probably similar to the way they are handled by the FCEUX debugger).

The debug does not show the address to the FX-BUS?

Right now, the SuperFX debugger only shows all the registers that are relevant to the current and previous instructions. I did this before writing the actual register editor, which makes it slightly redundant, and I might reduce it to showing the current instruction's registers to make room for other relevant info (like ROM/RAM access locations, such as in your example).

While this looks great and everything appears to be adequately made, there is one problem that irks me though, I write my code in Hex, not in ASM. So I prefer to write A90A or C905 rather than LDA 0A or CMP 05 for instance. The issue with this is that you cannot continue writing after one byte, sure you can press left after filling in one byte but that seems needlessly mundane and a step backwards to what is provided by Geiger's SNES9X. Also if you do use that method and you go to the end of the line instead of cycling back to the next bit of hex as you'd imagine the writing cursor is within the address line, which is just sort of silly. Another issues I have is with pasting, when you go to paste it doesn't even write to code... it doesn't write to anything really.

All in all it is a great looking emulator with good compatibility but some of the more crucial debugging aspects are still a bit finnicky and need some work. A great effort though.

The hex editor is entirely a remnant of the original bsnes debugger. I'm rewriting it, don't worry.

I plan to change it to refresh once per frame once I start reworking parts of the original bsnes debugger GUI, so hopefully that should be fast enough.

Having done some romhacking back in the day I can say quite confidently that I hate soft patching. I've had quite a few problems with it and I remember a lot of people who also did. I think it's important to remember adding features for the sake of having them can also add layers of complexity and bugs that you might not want.

As I pointed out earlier in the thread, bsnes already supported soft patching long before I ever modified it; I'm just updating it to include a format that is still in common use. It always was and still will be a completely optional feature.

Look: Konami delists itself from New York Stock Exchange
Maybe they are not making too much money anymore?

I feel the need to point out that the company that was delisted from the NYSE was Konami Gaming, Inc., which deals in slot machines and other casino-related products, and not Konami Digital Entertainment, which deals in video games.

Aside from that, it is not at all uncommon for foreign companies to stop trading on other countries' markets for any number of reasons, many of which have nothing to do with the financial status of the parent company. I doubt this had very much to do with the Silent Hills fiasco aside from timing.

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

What's new
"Step over" and "step out" buttons in debugger
Improved debugger UI with register editing
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
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
SPC file dumping
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.
IPS soft patching

See the project on GitHub for more info and source.

bsnes-plus v073+1 (Windows)

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.

Pages: [1] 2 3 4 5 6 7