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 ... 11
Front Page News / Re: Utilities: bsnes-plus v073+3 released
« on: December 04, 2016, 05:03:48 pm »
Not even the latest release of higan?

Higan's emulation of the actual Satellaview hardware is almost nonexistent, and its support for BS-X cartridges/memory packs is pretty minimal (and in some cases seems to be based on outdated/incorrect research). You can probably run some basic BS-X Memory Pack games with it (if you can even figure out how to load them), but they probably won't work much better than old bsnes versions, if at all.

Gaming Discussion / Re: DoomRL may be shut down by ZeniMax
« on: December 03, 2016, 07:45:55 pm »
I would say people doing fan games should just make their own assets/ideas/etc

Well you're in luck, because the developer in question is already doing that, which is probably the only reason why lawyers suddenly started caring about a small-time fan project from several years ago.

Gaming Discussion / Re: DoomRL may be shut down by ZeniMax
« on: December 03, 2016, 12:38:34 am »
It's probably worth pointing out that the notice from ZeniMax only involves the usage of their trademarks (i.e. names only, not content) on the game's website. The actual game and its content are literally never mentioned at all.

I think at worst, Kornel might end up changing the name of the game to something that doesn't explicitly reference their IP. It's certainly not on the same level as AM2R getting a DMCA takedown; some busybodies at ZeniMax's legal department probably just noticed the word "Doom" appearing on the author's current Kickstarter and decided to make themselves feel useful.

1. It's just my personal taste but everything in the debugger being in CAPS would be a lot easier to read.
I can add that to the debugger options later, no problem.

I was testing around with the few quick save states BSNES has currently and if you try using even one of the same key for load/save, it'll load and then save instead of loading or saving.

IE: Shift + F1 = Save Slot 1 but if you have F1 as the key to load that slot as well, it'll reload the save state and then save instead of just saving.  I think it needs to realize that Shift + F1 and F1 are completely separate key commands.
Yikes, I'll have to check that out.

I download the new version but when I opened, my antivirus blocked it.  :-[
Do you know which file specifically gets flagged?

Either way, I can guarantee it's a false positive and you should ignore it and/or switch to a better antivirus.

Over a year later, here's a new release, better than ever.

Windows 64-bit compatibility & accuracy
Windows 32-bit compatibility

Things of interest:
  • PPU tools! VRAM viewer, tilemap viewer, and an improved version of the existing sprite viewer.
  • True Satellaview/BS-X support! (1 2) As of this release, bsnes-sx2 is now officially deprecated.
  • MSU1 revision 2 support! Should now behave pretty much exactly the same as current sd2snes firmware.
Huge thanks to UnDisbeliever and LuigiBlood, respectively, for helping out with the first two of those things in the couple of weeks leading up to the release.

Hopefully it won't be another year before I release another one of these (yeah, that's what I said last time, isn't it?) I know there's still some stuff I probably said that I'd do (or that I want to do, anyway) that hasn't been done yet, but it'll happen. Thanks to everyone who motivated me to finally work on this again, especially recently.

Anyway, the rest of the boring changelog:

Code: [Select]
Added tilemap viewer, revamped VRAM viewer and improved OAM viewer [UnDisbeliever]
Added all BS-X/Satellaview support from bsnes-sx2 [LuigiBlood]
Added PPU breakpoint support to accuracy and performance builds [Revenant]
Added more comparison options to cheat search dialog [Grieverheart]
Added some command line debugger arguments (see `bsnes --help`) [UnDisbeliever]
Added debug window option to show H-count as either dots or clocks [Revenant]
Added option to use WDM instruction as a software breakpoint [Revenant]
Added "allow invalid input" and "allow modifier keys" to settings window [Revenant]
Updated MSU1 support to revision 2 (includes pause/resume support) [Revenant]
Improved handling of debug window GUI state when breaking/running/stepping [Revenant]
Expanded debug properties view for multiple chips on all 3 build profiles [Revenant]
Made power-on state (especially accuracy PPU) randomized the same way as higan [Revenant]
Memory viewer displays current address at bottom of window [Revenant]
Memory viewer now displays APU bus instead of just APU RAM [Revenant]
Memory viewer now displays (most) I/O registers as read-only values [Revenant]
Debug log files are now only opened if a game is actually open [Revenant]
Debugger switches between debug/main window depending on focus policy [Revenant]
Fixed flickering/blanking of game screen when changing/resizing windows [Revenant]
Fixed CPU bug w/ direct page wrapping in emulation mode [AWJ]
Fixed disassembly of PEA/PEI/PER instructions [AWJ]
Fixed some details of S-DD1 memory mapping [AWJ]
Fixed typing in native file dialogs triggering emulator hotkeys [Revenant]
Fixed debug events messing with emulation speed if turbo/slowdown keys were held [Revenant]
Fixed spurious debug events caused by dummy reads during SPC write instructions [Revenant]
Fixed file dialog path being cleared when cancelling a native file dialog [Revenant]
Fixed handling of $00Fx registers when dumping SPCs [Revenant]
Fixed "search next/prev" behavior when wrapping to beginning or end of memory [Revenant]

Programming / Re: Super Mario All-Stars FastROM Issue *SOLVED*
« on: October 31, 2016, 08:43:19 pm »
Like STARWIN said, with 16-bit writes you're touching $4203 twice which causes a second bogus multiplication.

But if you're multiplying by a constant value of 4, why not just ASL twice and avoid the slow multiplication registers entirely?

Just to prove that this project is still alive, here's a spiffy new overhaul of the VRAM viewer, much thanks to UnDisbeliver:

Very well timed, too, because I've been gearing up to work on some other new graphics-related features (tilemap viewer, etc.) Now that I'm focusing on actual features again, another release should finally be not too far off.

I thought that's how PAR1 work - every time ram address is read, it applies the code?? Maybe not though. :)

PAR1 (and the rest) use a RAM-resident interrupt hook to apply RAM cheats every frame.

I didn't know about the PAR2 firmware difference, that's interesting. My guess is that the reason the 1.x BIOS doesn't work correctly with HiROM games is that the PAR2 uses the xx6000-xx7FFF range for its own internal memory, which conflicts with how HiROM games ordinarily map their own SRAM, and only the later firmware is able to actually deal with that correctly.

edit: Are there any actual dumps of 2.x firmware floating around? No-Intro only has 1.0 and 1.1.

Gaming Discussion / Re: Will Nintendo target [b]here[/b] next?
« on: September 16, 2016, 12:09:41 am »
First: If it was because of copyright infringement, why did Nintendo wait for DocM64 to complete and release the game to C&D him then and not way before?

Maybe it just wasn't on the radar of Nintendo's legal department until dozens of gaming news sites started covering the actual release of the game.

Second: This is the link with the news on the ROM site raid: http://skirmishfrogs.com/2016/03/19/nintendo-tells-website-to-remove-2200-roms-including-hacks/

Okay, so a ROM site got busted for hosting thousands of ROMs. This isn't really news. If you're distributing full sets of unmodified Nintendo console games, you're helping people pirate games that Nintendo still makes money from. That's a pretty big reason for them to go after you.

Again, that's why Romhacking.net only deals in patches - distributing pre-patched hacks of a commercial game is, of course, equally illegal to distributing the original game.

Third: Correct me if I'm wrong, but aren't a huge load of the hacks hosted here centered around Nintendo games?

You're probably correct. But given that most of the downloads are patches that themselves contain very little or no copyrighted content, the chance of this actually presenting a major legal issue is still rather small.

Gaming Discussion / Re: Will Nintendo target [b]here[/b] next?
« on: September 15, 2016, 11:53:01 pm »
If Nintendo goes after a ROM site (what specific site are you even talking about?) that's because it was a ROM site, which is plainly illegal. Nintendo (and the ESA and other related organizations) have been going after ROM sites for something like 20 years now. Romhacking.net isn't a ROM site.

Nintendo shut down AM2R because it was blatant copyright infringement. The entire reason ROM hacking sites only distribute patches is to avoid copyright infringement as much as reasonably possible.

It's entirely plausible that Nintendo might try to issue DMCA takedowns against Romhacking.net for specific hacks, or send C&D notices to hack authors or something like that, but in the long run that's about as likely as it's always been - that is, not very.

There is virtually no chance of the entire site somehow getting shut down because of Nintendo. If it were that big of a legal issue, it probably would have come up already.

Front Page News / Re: ROM Hacks: And We're the Game Grumps!
« on: September 10, 2016, 12:46:58 pm »
You might as well just distribute an entire pre-patched ROM at that point.

Front Page News / Re: ROM Hacks: And We're the Game Grumps!
« on: September 10, 2016, 03:19:12 am »

Here's the patch by itself for people who want a smaller download.

A version of the hack for other regions of the game might also be nice, since this one only works on Kirby Bowl (Japanese region), according to the hack info.

There was a reason for that: the "All Courses" menu is an edit of the Japanese version's debug level select, and the Japanese version of the game had several unused courses that were used to accommodate more new stages. (Also, the English versions have no intro sequence!)

ROM Hacking Discussion / Re: Screenshots
« on: September 08, 2016, 06:43:01 pm »
Very impressive, Grimlock! Looking forward to whatever else might come of that.

Seems like a neat place ... but I see that one of the users has the title "Disgustingly Naive Smartass" ... What the actual fuck?

People with more than 500 posts are allowed to give themselves whatever title they want.

Yeah, the forum is unfortunately less active than it could be. People are still welcome to post their cool findings there though :)

Yeah, that site is officially dead in the water unfortunately.

We are? That's news to me...

From what I understand, or for what it looks like, from this bsnes fork version of yours, you look like you are turning the bsnes emulator into something like FCEUX (in which it has NES romhacking & debugging tools, and a built-in hex editor). Isn't that right, Mr. (or Mrs.) @Revenant?

Basically, yes. Well, the debugger was already there, but my goal is to make it more robust/usable (though unfortunately it's not quite as full-featured as the FCEUX debugger yet).

When a (R/W) breakpoint is hit, and I step, it just hits the breakpoint again, so I have to step again to actually step. Intended?

This can happen if a single instruction reads/writes two bytes that are both part of a single breakpoint's address range, or if a read+write breakpoint is triggered by a read-modify-write instruction (because the read and the write don't actually happen simultaneously). This is less "intentional" behavior and more just a side effect of how breakpoints were already implemented in bsnes.

Trace logs could show the opcodes+operands in addition to the mnemonics.

This is something I already wanted to add at some point, both to the debug/trace window and the disassembly window.

I don't know how to disassemble anything else than what it decides to show. This gives a claustrophobic feeling.

The disassembly window only shows stuff that has actually been marked as executed, within a certain distance around the current PC. This is another thing from the original bsnes debugger that I would like to improve eventually.

edit: In a LoROM game if I set a breakpoint at the mirror $80-$BF, it won't trigger if mirrored is accessed. Intentional? Geiger's does.

Right now, breakpoints only support address mirroring when specifying a single address, rather than a range of addresses, for performance reasons. (See this post for an explanation.) This is something I might try to revise eventually. Keep in mind that if you're only breaking on a single address, you can leave the end of the address range blank.

edit2: Memory editor could show the exact offset of the selected cell.

This is another change to the memory editor that is already going to be in the next release.

Programming / Re: Tracking Where to Write Tiles In VRAM
« on: July 12, 2016, 09:58:24 pm »
*(Technically it renders "1 pixel at a time" or even finer than that.  But given how all emulators -- even the super-strict Higan/BSNES -- emulate on a scanline-by-scanline basis and nobody really knows the details of what the SNES is doing during each individual scanline..... "1 scanline at a time" is close enough)

bsnes/higan actually does have a pixel-by-pixel renderer - that's one of the main draws of the "accuracy" profile. That's how it is able to emulate things like changing the background mode mid-scanline (that's mode 7 on the left and mode 1 on the right), and some of the visual effects in Air Strike Patrol, which is commonly cited as one of the games that made a per-pixel renderer necessary.

eh isn't it like a placeholder so people can put them there when they happen? oh this is for translations of homebrews? Yea I've never heard of any translations of homebrews. Do any even exist?

"Hebrew", not "homebrew".

Pages: [1] 2 3 4 5 6 ... 11