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'm able to get the debugger to break at that address several times in a row when entering areas from the overworld or moving between maps (such as entering/leaving Mario's house). Make sure you have "SA-1 bus" selected as the breakpoint source and that it's set as an execute ("X") breakpoint.

HARVEST MOON SNES US smc with header


Moving from screen to screen. This address should fire when entering the farm during spring. The address show up as red in hex viewer. I've confirmed with Geiger's it does fire.

I don't ever see 80C520 being executed, but I can put a breakpoint on a similar-looking section of code right before that and it breaks as expected when entering the farm:

Would it be possible to get this to work more appropriately with Super Mario RPG as well?

There's a certain chunk(s?) that are clearly read but you cannot log them, trace them or anything.  It's like they don't exist even when it's clearly right in your face.  It's something to do with the SA-1 chip that causes the problem with emulators.  There's also a really awkward bit of forcing bank switching repeatedly instead of just flipping them all on to display all data. I'm not sure if that last one is really workable but the first part is EXTREMELY important as it makes debugging certain things impossible.

Can you be more specific?

Which ROM / what address / what were you doing to try to trip the breakpoint?

ROM Hacking Discussion / Re: [SNES] Tools
« on: July 31, 2015, 10:57:11 pm »
I'm also working on a newer bsnes-based debugger here:,19640.0.html

Hasn't been updated in a while, but I plan to continue working on it pretty soon.

Crossposting my reply from nesdev, because why not

Hopefully I'll be working on it soon now that things have been slowing down at work, which has been eating up most of my programming time lately; developing C++/Qt applications like this one (and my other main projects as of late) is also what I do for a living, and sadly I don't have an unlimited amount of time to put into the same general thing every single day :P

Gaming Discussion / Re: Strategy games for SNES
« on: July 01, 2015, 07:48:36 pm »
Both Majin Tensei games are really good

Gaming Discussion / Re: Need help identifying a golf game
« on: June 30, 2015, 01:01:54 am »
The game you're thinking of is "Nice de Shot" for the SFC.

The bad news is that that text isn't actually part of the game; a former co-admin and I were having some goofy discussion about the game's Engrishy title (and that of a different SFC golf game) and somehow it led to the creation of the two doctored screenshots you can still see in his signature at that link.

Gaming Discussion / Re: ZSNES has been comprimised.
« on: June 28, 2015, 09:28:49 pm »
By your logic, all Atari 2600 games should be totally bug-free, or the occurrence of bugs should be extremely unlikely.
How'd that work out in reality?

... Probably pretty well? Which bug-ridden 2600 games did you have in mind?

Using that as an example doesn't make a lot of sense to me, since "simple" is not at all how I'd describe programming for the 2600, no matter what the scope of the actual game is.

I've never really had any use for disabling individual channels, other than for fun (and it can still be done in most other emulators and SPC players anyway...)

I'm not really opposed to taking it out if there's not another practical solution that doesn't interfere with accurate DSP emulation.

Gaming Discussion / Re: ZSNES has been comprimised.
« on: June 24, 2015, 09:22:26 pm »
It's a bug in how ZSNES handles SA-1 emulation, and the exploit has likely been in place for as long as ZSNES' SA-1 support has (10-15 years?).

Here's a video of the exploit in action, and here's a recent SVN build with the bug (probably) fixed.

Note that the current SVN version of ZSNES is somewhat unusable, and a "proper" 1.52 release might not happen for a while.

I'd be very surprised to learn that any rippable SPC (i.e. excluding music engines that depend on 65816-side data streaming) from any game hasn't been long-since ripped by now

I've personally ripped either missing songs or entire soundtracks for dozens of NES and SNES games within the past few years that simply didn't have complete sets available, and there are still quite a few SNES games that, to my knowledge, don't have complete SPC sets available for one reason or another (and that's only including games for which dumping playable SPCs is actually possible). Even beyond that, there have been dozens of other games which have recently had new SPCs added to sets that were previously assumed to be complete, whether it was music that was outright unused or just obscure enough to be missed by the majority of listeners, but it's not an entirely obsolete feature, and it's one that I've made use of very many times in other emulators (especially in conjunction with a debugger such as Geiger's), so there it is.

I don't expect bsnes-plus to ever come anywhere close to the level of usage among "ignorant newbies" as ZSNES and Snes9x, both of which have had the same feature since approximately the stone age. Adding it to one more emulator, especially a relatively niche one like this, really isn't lowering the barrier to entry for would-be SPC dumpers in any significant way.


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.

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.

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