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 ... 11
Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« on: July 09, 2021, 07:38:10 pm »
Will the newer mod still use the I/O port for bankswitching larger amounts of VRAM?

I can update the implementation in bsnes-plus, just let me know how it should work.

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« on: October 14, 2019, 09:16:48 am »
No, I do not think that is correct. I think if bit 0 and 1 are not set for $4201 it will activate the second set

You are probably having problems with the multitap because $4201 is for the joypads and you are zeroing out all of the bits. 2 bits are used for the controllers and the other 6 are not used for anything. There are 8 pins on the cpu for each bit for the joypad I/O ports $4201. The last 2 pins I think bit 7 and 8 are connected to the controls and the other 6 are not connected to anything on the motherboard. When you do your testing I think you need to have 128kb vram activated when you activate 256kb. So try only using those 2 bits/I/O ports.

Right, I think we're both trying to say the same thing here, in other words:
  • If bit 0 is set, the mod is disabled (default on power on)
  • If bit 0 is cleared and bit 1 is set, the first/lower 128kb is used
  • If bits 0 and 1 are both cleared, the second/upper 128kb is used

This is what I'm currently emulating.

The problem is that if you're inverting bit 1 like this, games that write 0x80 or 0x00 to that I/O port (like Rushing Beat Shura and the dozens of other ones I listed, and probably more) will have problems if they were already loading stuff into the original 64kb of VRAM, since the entire 128kb will be swapped out when the game isn't expecting it to.

I think the best solution, rather than adding switches to the mod or anything, would be to just not invert pin 1 when connecting it to the highest address line on the RAM chips. As far as I can tell that would probably solve the issue, since writing zeroes to those bits like some games do would not actually change which block of VRAM is being used. (This would probably also not force people to have to patch games or anything - what if they want to play using their original cartridges?)

Is the vram viewer capable of displaying both 128kb sets of vram at the same time? If not, can you make it to where it does so I can run a few test?

Right now the VRAM viewer only displays whichever one is currently in use, but the generic memory viewer (hex editor) shows all of it at the same time. The VRAM viewer also shows the "full" VRAM addresses when using 256kb, i.e. if the second bank is selected it will show 0x20000-0x3FFFF as the addresses, etc.

Personal Projects / Re: slidelljohn (a.k.a.[J]) snes projects page
« on: October 10, 2019, 07:28:34 pm »

Just popping in to mention that the latest development build of bsnes-plus now fully supports the 128kb/256kb VRAM expansion (currently only in "accuracy" builds, though this may change later...) Both the emulator itself and the built-in debugging tools can view and use all available expanded VRAM.

October 12, 2019, 05:40:27 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Also, since I've still got my head in the VRAM expansion stuff, could you clarify something?

In the GitHub issue a while ago, you mentioned that you were inverting both of the CPU I/O pins that the expansion uses - am I correct in understanding that writing all zeroes to $4201 will select the second 128kb VRAM bank?

If so, then I'm unfortunately finding a lot of games that break with this behavior, especially ones that include support for multitaps and possibly other peripherals, since they write 0x80 and 0x00 to the I/O port and sometimes do so after it's already started loading stuff into the other VRAM bank, causing some pretty serious visual glitches.

Another good example is Nintendo's burn-in test carts, since those also write the same values while the screen and VRAM contents are already in use:

e: made a more detailed (but probably not complete) list of games that have obvious issues with my 256k VRAM emulation:

Most of the offending games seem to involve multitap support, some of them behave worse with the 5 player multitap plugged into port 2.

Programming / Re: Mega Man X3 FastRom Issues
« on: July 24, 2017, 09:18:53 pm »

(I saw your RHDN thread about this earlier, but I wasn't logged in at work so I didn't reply)

You can enable FastROM without modifying the mapping bits in the header, as long as you still set $420D and use addresses above $800000. The SNES doesn't actually know or care what the contents of the cartridge header are (unless you count the interrupt vectors as being part of the header).

The specific check for $20 when detecting the Cx4 is just a heuristic that bsnes (and possibly other emulators) use to make sure it doesn't get falsely detected for ROMs that don't actually use it. I could modify said check to support $30 as well, but trying that might make it inconsistent with other emulators. It's probably better to just play it safe and keep the values the same as the original games.


Here's a thing I decided to work on recently, a MMC5 mapper conversion for Kirby's Adventure. The goal was to use the MMC5's increased PRG ROM capacity to make managing free space less of a hassle when editing levels (I'm willing to wager that you could probably make every room in the game be as large as possible and still not run out of space).

This patch is for the US PRG0 version of the game, but I plan to adapt it to other versions later. Note that the patch is not compatible with current releases of the editor, but the next release will include it as an optional feature just like the "expanded level header" patch it currently has.

Aside from the increased space, everything in the game should be exactly the same as in the original MMC3 version. I'd appreciate some additional eyes to make sure everything works fine. (The parallax scrolling during the Nightmare Orb battle probably needs some tweaking, but it's already kinda flickery in the original game, so there's not a whole lot I can do about that.)

Along with this, I'm planning to include some other stuff that is probably overdue, like freehand drawing, etc. in the next version of the editor.

ROM Hacking Discussion / Re: Screenshots
« on: May 08, 2017, 12:10:32 am »
Yep. The idea was to use MMC5's larger ROM capacity to support ROM expansion in my editor, since managing free space is kind of a hassle otherwise. (The MMC5 version in that screenshot is using the full 1MB of PRG ROM)

I need to fix up the timing of screen splits a bit, but otherwise the conversion is working pretty well.

(FCEUX 2.2.2 also had a bug that was causing nametable corruption to occur only in the MMC5 version, which I spent hours trying to track down before I realized it wasn't my problem. Keep your emulators up to date, people!)

ROM Hacking Discussion / Re: Screenshots
« on: May 06, 2017, 11:25:38 pm »

A totally "invisible" hack, but hopefully the title bar says it all...

News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: January 15, 2017, 05:33:09 am »
Yay, a Kirby's Adventure hack.

News Submissions / Re: Translations: New Translations Added to the Database
« on: December 27, 2016, 04:32:18 am »
According to the BootlegGames Wiki, that's the title printed on the game's manual. Of course, that probably just raises a different question...

Here is a minor release which fixes a few bugs of varying importance. I plan to start doing these more often, maybe monthly. Download links are in the OP as usual.

(justin3009: hopefully the issue with hotkeys and modifier keys should be fixed)

Code: [Select]
Fixed low-res scanlines being horizontally resized too much when fast-forwarding
  while a high-res screen mode is active (compat/performance builds only) [Revenant]
Fixed potential issue with modifier keys triggering multiple wrong inputs [Revenant]
Fixed potential crashes when nonexistent cart RAM would be mapped by a manifest
  and/or certain coprocessors (such as the SA1) [Revenant]
Fixed potential crash when tracing SA1/SuperFX with trace mask enabled [Revenant]
Fixed trace mask being wrongly enabled when loading a cartridge [Revenant]

I'll start addressing more of your ideas and issues once the holidays are over. I wanted to get a few things taken care of before then, but hopefully I can start to keep up more frequent official releases.

Programming / Re: SNES SRAM mapping question
« on: December 16, 2016, 06:27:48 pm »
Most HiROM carts have SRAM mapped in banks 20 through 3F, but how they are mirrored depends on the actual amount of SRAM on the cartridge. If there's only 8kb of SRAM then it will appear in every bank; higher amounts will be split up into 8kb segments and repeated fewer times each. If 256kb is used, then each of the banks 20-3F will have a different 8kb segment mapped to them.

News Submissions / 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:

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 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.

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