Mesen-S - SNES Emulator

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Oziphantom
Posts: 825
Joined: Tue Feb 07, 2017 2:03 am

Re: Mesen-S - SNES Emulator

Post by Oziphantom » Mon Mar 02, 2020 10:00 pm

would it be possible to make a "ROM is RAM" mode for development?

Sour
Posts: 799
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Tue Mar 03, 2020 2:12 pm

Oziphantom wrote:
Mon Mar 02, 2020 10:00 pm
would it be possible to make a "ROM is RAM" mode for development?
I'm not entirely sure what you mean? From the debugger tools, the ROM is always like RAM. You can change any value in memory (via the hex editor or the recently added assembler tool) and save the changes as an IPS patch or a new rom file.

If you meant for the emulation core itself to allow writes to ROM as if it were RAM for the CPU, that seems a bit weird, even for dev purposes? It would have implications on rewinding, save states, etc., too.

Oziphantom
Posts: 825
Joined: Tue Feb 07, 2017 2:03 am

Re: Mesen-S - SNES Emulator

Post by Oziphantom » Wed Mar 04, 2020 1:22 am

yeah, so if you do STA $008745 the actual ROM gets changed.

Your LUA doesn't have any GUI that I can see. Bizhawk has GUI but the ROM is write only and apparently the cores will just crash if you remove the "ROM is ROM hack" in it.

So in order to make a tweaker you have to make your code copy data to RAM, then have the code run from RAM. Get the values, put them back in ROM, convert the code back to reading from ROM.

If ROM can be set as RAM in the emulator, then I can make a "SNES gui" as we did back in the old days, and get it to modify the "ROM". Then just write down the values into the ROM and carry on. Makes tweaking a lot faster.

Pokun
Posts: 1431
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Mesen-S - SNES Emulator

Post by Pokun » Tue Mar 31, 2020 4:34 am

Ice Man wrote:
Sun Mar 01, 2020 5:11 am
Why should it be? The game isn't booting in Mesen-S and it's a simple LoROM game.
Sorry it was just a joke referring to the quirky humour of this game series.

Ice Man
Posts: 526
Joined: Fri Jul 04, 2014 2:34 pm

Re: Mesen-S - SNES Emulator

Post by Ice Man » Tue Mar 31, 2020 9:17 am

Ah, no problem. I never actually played the game much to know about it. :P

Kismet
Posts: 60
Joined: Wed Nov 30, 2016 9:59 pm

Re: Mesen-S - SNES Emulator

Post by Kismet » Wed Apr 08, 2020 10:48 pm

Sour wrote:
Tue Mar 03, 2020 2:12 pm
Oziphantom wrote:
Mon Mar 02, 2020 10:00 pm
would it be possible to make a "ROM is RAM" mode for development?
I'm not entirely sure what you mean? From the debugger tools, the ROM is always like RAM. You can change any value in memory (via the hex editor or the recently added assembler tool) and save the changes as an IPS patch or a new rom file.

If you meant for the emulation core itself to allow writes to ROM as if it were RAM for the CPU, that seems a bit weird, even for dev purposes? It would have implications on rewinding, save states, etc., too.
I did find a strange use-case, going spelunking into a game rom with the active SNES palette. Unfortunately this effect, as-is can only be seen if you select the PRG, and presently maxes out at 40,000 bytes when the game is much larger. Find those sprites that were never seen in the game. Maybe just have "ROM" in that dropdown and scroll through it in 64K pages, and do the same 1bpp/2bpp/3bpp/3bpp/4bpp/8bpp/mode7 switch.
I come from the net. Through systems, peoples and cities to this place.

creaothceann
Posts: 222
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Mesen-S - SNES Emulator

Post by creaothceann » Thu Apr 09, 2020 11:27 am

Kismet wrote:
Wed Apr 08, 2020 10:48 pm
I did find a strange use-case, going spelunking into a game rom with the active SNES palette. Unfortunately this effect, as-is can only be seen if you select the PRG, and presently maxes out at 40,000 bytes when the game is much larger. Find those sprites that were never seen in the game. Maybe just have "ROM" in that dropdown and scroll through it in 64K pages, and do the same 1bpp/2bpp/3bpp/3bpp/4bpp/8bpp/mode7 switch.
You can do that by loading a savestate and the corresponding ROM in vSNES, then bringing up the scene viewer, the memory viewer and the palette viewer. Moving the mouse cursor over the BG/sprite layers will select that tile and its palette, and from there you can use that to scroll through the ROM. (Assuming the ROM has uncompressed graphics.)
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

Sour
Posts: 799
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Thu Apr 09, 2020 12:34 pm

Kismet wrote:
Wed Apr 08, 2020 10:48 pm
[...]
I did find a strange use-case, going spelunking into a game rom with the active SNES palette. Unfortunately this effect, as-is can only be seen if you select the PRG, and presently maxes out at 40,000 bytes when the game is much larger. Find those sprites that were never seen in the game. Maybe just have "ROM" in that dropdown and scroll through it in 64K pages, and do the same 1bpp/2bpp/3bpp/3bpp/4bpp/8bpp/mode7 switch.
I'm not sure I'm seeing the link between what you seem to be talking about, vs what Oziphantom was saying in their quote? They were talking about having the possibility to edit ROM memory from the game/program itself, rather than just through the debug tools.

You can see the all of PRG ROM via the tile viewer already - it maxes out the size to 256kb ($40000 bytes) per "page", but you click the up button on the address value to see the next 256kb, etc. (but I seem to have stumbled upon a bug that causes a crash when reopening the tile viewer after playing with these fields, will try to check and fix this later today)

Kismet
Posts: 60
Joined: Wed Nov 30, 2016 9:59 pm

Re: Mesen-S - SNES Emulator

Post by Kismet » Thu Apr 09, 2020 6:13 pm

Sour wrote:
Thu Apr 09, 2020 12:34 pm

You can see the all of PRG ROM via the tile viewer already - it maxes out the size to 256kb ($40000 bytes) per "page", but you click the up button on the address value to see the next 256kb, etc. (but I seem to have stumbled upon a bug that causes a crash when reopening the tile viewer after playing with these fields, will try to check and fix this later today)
I have a 4K screen, some of the UI widgets are very tiny. Like the arrows on those up and down buttons are barely perceptable. The palette picker is a bit tiny (I've seen other screen shots)

Also, I noticed you wrote a lua script to dump the palette for ACT, is there a way to set where LUA scripts write to by default? It seems like they default to the user profile. Maybe allow overriding where LUA writes to.

The kind of script I'm trying to write is one that can save the sprites as/where they're drawn (eg the OAM coordinates and palette.)

Any plans to make HDNes style options available? I know it's not nearly as trivial as the NES CHR rom, but the theory IMO would be to hash the sprite/tile with it's palette and swap it with something higher resolution. There would probably be a significant performance impact for that though.

I am rather impressed with this emulator. Mensen-S compiled, out of the box, no problem at all with VS2019.
I come from the net. Through systems, peoples and cities to this place.

Sour
Posts: 799
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Thu Apr 09, 2020 9:02 pm

Kismet wrote:
Thu Apr 09, 2020 6:13 pm
I have a 4K screen, some of the UI widgets are very tiny. Like the arrows on those up and down buttons are barely perceptable. The palette picker is a bit tiny (I've seen other screen shots)
That sounds like a bug - the arrows on the up/down buttons I thought would scale. I'll do some testing on my end and try to fix that - generally the UI should be working properly with DPI settings over 100%, but I admit I haven't tested this in a very long time.

Adding an option to select the default folder for Lua stuff is actually something that's been on my list of things to do on Mesen for a while. If your script is mostly meant for your own use, you can probably just use a full path (e.g C:\myfolder\myfile.txt) for the file name to bypass this limitation for now.

HD packs are possible - it's essentially the same as HD packs for CHR RAM games on the NES, except the palette can be either 2bpp, 4bpp or 8bpp. Though, I'm not sure there would be too much interest in creating packs for the SNES - the console itself is already flexible enough in terms of colors most of the time. Increasing the resolution would be possible, but on the NES so far most of the better HD packs that were done involved keeping the resolution as-is and just using the hd packs to increase the number of colors on the screen.

Adding support for them would probably add a slight performance penalty, even when they're not being used, too, so that's definitely a concern.
Kismet wrote:
Thu Apr 09, 2020 6:13 pm
I am rather impressed with this emulator. Mensen-S compiled, out of the box, no problem at all with VS2019.
Thanks! Keeping the build process simple is definitely something that I strive for - I've been put off from compiling too many projects in the past just because of how much effort they required :p

Kismet
Posts: 60
Joined: Wed Nov 30, 2016 9:59 pm

Re: Mesen-S - SNES Emulator

Post by Kismet » Tue Apr 14, 2020 2:12 pm

Sour wrote:
Thu Apr 09, 2020 9:02 pm
Kismet wrote:
Thu Apr 09, 2020 6:13 pm
I have a 4K screen, some of the UI widgets are very tiny. Like the arrows on those up and down buttons are barely perceptible. The palette picker is a bit tiny (I've seen other screen shots)
That sounds like a bug - the arrows on the up/down buttons I thought would scale. I'll do some testing on my end and try to fix that - generally the UI should be working properly with DPI settings over 100%, but I admit I haven't tested this in a very long time.
I've recompiled it to the git version available today and have noticed the improvements to the tile viewer.

The script editor has one 4K issue as well, the dropdown box can't be resized, so the auto-complete only shows 7 characters, and doesn't autocomplete if you click on it:
4k-script1.png
The Sprite Viewer columns also default to only showing 1 character in the columns.

While I'm at it, is there a (correct) way to retrieve the VRAM OAM1/2 base-address (eg from a script)? I know the Tile Viewer is tracking it as (ppu.OamBaseAddress) and ((ppu.OamBaseAddress + ppu.OamAddressOffset) & 0x7FFF).
I come from the net. Through systems, peoples and cities to this place.

Ice Man
Posts: 526
Joined: Fri Jul 04, 2014 2:34 pm

Re: Mesen-S - SNES Emulator

Post by Ice Man » Wed Apr 15, 2020 1:11 am

If possible, are you able keep the window size saved when maximized for both, Mesen and Mesen-S? It returns back to the current setting in the config file after every restart. :(

Sour
Posts: 799
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Wed Apr 15, 2020 6:54 pm

Kismet wrote:
Tue Apr 14, 2020 2:12 pm
The script editor has one 4K issue as well, the dropdown box can't be resized, so the auto-complete only shows 7 characters, and doesn't autocomplete if you click on it
This is a custom drawn control, and not my own code (the code editor itself is an open source component), so fixing it is a bit of a pain. If you're running at 200% DPI, you might be better served by just disabling DPI scaling for the application and letting Windows just scale up the window like if it was a picture (at 200%, I'd imagine there is little to no blur introduced by this.). You can try turning this on in the properties for the .exe file (Compatibility -> Change high DPI settings -> Override high DPI [...] -> pick "System" instead of "Application") - this should fix all layout issues, and might introduce some blur, but I don't think it'll be a problem on a 4k monitor at 200% DPI. The current DPI scaling in Mesen(-S) is mostly meant for the scenarios where Windows is set to 125-150% DPI which causes a lot of noticeable blur on a typical 1080/1440 display.
Kismet wrote:
Tue Apr 14, 2020 2:12 pm
While I'm at it, is there a (correct) way to retrieve the VRAM OAM1/2 base-address (eg from a script)? I know the Tile Viewer is tracking it as (ppu.OamBaseAddress) and ((ppu.OamBaseAddress + ppu.OamAddressOffset) & 0x7FFF).
Not at the moment - the Lua API was put together rather hastily based on Mesen's and doesn't include much in terms of information about the PPU. Technically this would be done with emu.getState(), but this currently only returns a few values: https://github.com/SourMesen/Mesen-S/bl ... i.cpp#L715
Adding more is fairly trivial though, I'll try to add everything that's part of the PpuState struct (https://github.com/SourMesen/Mesen-S/bl ... pes.h#L123) when I have a chance.
Ice Man wrote:
Wed Apr 15, 2020 1:11 am
If possible, are you able keep the window size saved when maximized for both, Mesen and Mesen-S?
This is something that's been requested before and is already on my list of things to get done - so it'll be fixed, eventually :p

Sour
Posts: 799
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen-S - SNES Emulator

Post by Sour » Fri Apr 24, 2020 7:14 pm

Kismet wrote:
Tue Apr 14, 2020 2:12 pm
While I'm at it, is there a (correct) way to retrieve the VRAM OAM1/2 base-address (eg from a script)? I know the Tile Viewer is tracking it as (ppu.OamBaseAddress) and ((ppu.OamBaseAddress + ppu.OamAddressOffset) & 0x7FFF).
This is possible now, I've just added most of the PPU's state to the emu.getState function, which should now return something like this:

Code: Select all

['masterClock'] = 1696008572,
['cpu'] = {
	['x'] = 16,
	['nmiFlag'] = false,
	['pc'] = 1383,
	['d'] = 0,
	['irqFlag'] = 0,
	['cycleCount'] = 211413940,
	['emulationMode'] = false,
	['db'] = 0,
	['a'] = 0,
	['y'] = 16,
	['k'] = 192,
	['sp'] = 5629,
	['status'] = 34
},
['ppu'] = {
	['windowMaskMainBg2'] = true,
	['ppu2OpenBus'] = 64,
	['ppu1OpenBus'] = 255,
	['windowMaskMainBg1'] = true,
	['enableOamPriority'] = false,
	['oamRamAddress'] = 0,
	['mode1Bg3Priority'] = true,
	['colorMathHalveResult'] = true,
	['screenBrightness'] = 0,
	['windowMaskLogicBg2'] = false,
	['windowMaskSubBg0'] = false,
	['fixedColor'] = 0,
	['windowMaskSubBg1'] = false,
	['frameCount'] = 4745,
	['vramIncrementValue'] = 1,
	['colorMathEnabled'] = 4,
	['colorMathAddSubscreen'] = true,
	['windowMaskMainBg3'] = false,
	['windowMaskLogicColor'] = false,
	['windowMaskLogicBg0'] = false,
	['colorMathClipMode'] = 0,
	['cycle'] = 340,
	['directColorMode'] = false,
	['mainScreenLayers'] = 23,
	['mosaicSize'] = 1,
	['windowMaskLogicSprites'] = false,
	['windowMaskSubSprites'] = false,
	['windowMaskSubBg2'] = false,
	['objInterlace'] = false,
	['screenInterlace'] = false,
	['windows'] = {
		[1] = {
			['invertedLayers'] = 32,
			['left'] = 0,
			['activeLayers'] = 32,
			['right'] = 255
		},
		[0] = {
			['invertedLayers'] = 55,
			['left'] = 8,
			['activeLayers'] = 55,
			['right'] = 247
		}
	},
	['colorMathPreventMode'] = 2,
	['cgramAddress'] = 0,
	['extBgEnabled'] = false,
	['windowMaskMainBg0'] = true,
	['hiResMode'] = false,
	['oamBaseAddress'] = 24576,
	['mosaicEnabled'] = 0,
	['cgramAddressLatch'] = false,
	['oamMode'] = 3,
	['cgramWriteBuffer'] = 227,
	['vramReadBuffer'] = 0,
	['mode7'] = {
		['largeMap'] = false,
		['vScroll'] = 0,
		['matrix'] = {
			[1] = 10,
			[2] = 10,
			[3] = 10,
			[0] = 10
		},
		['verticalMirroring'] = false,
		['hScroll'] = 168,
		['centerX'] = 0,
		['centerY'] = 0,
		['horizontalMirroring'] = false,
		['fillWithTile0'] = false,
		['valueLatch'] = 0
	},
	['vramAddrIncrementOnSecondReg'] = true,
	['windowMaskLogicBg3'] = false,
	['colorMathSubstractMode'] = false,
	['windowMaskLogicBg1'] = false,
	['scanline'] = 225,
	['vramAddress'] = 15680,
	['overscanMode'] = false,
	['bgMode'] = 1,
	['windowMaskSubBg3'] = false,
	['hClock'] = 1364,
	['oamAddressOffset'] = 4096,
	['vramAddressRemapping'] = 0,
	['layers'] = {
		[1] = {
			['hScroll'] = 128,
			['tilemapAddress'] = 20480,
			['vScroll'] = 12,
			['largeTiles'] = 0,
			['doubleWidth'] = 0,
			['doubleHeight'] = 0,
			['chrAddress'] = 0
		},
		[2] = {
			['hScroll'] = 168,
			['tilemapAddress'] = 22528,
			['vScroll'] = 0,
			['largeTiles'] = 0,
			['doubleWidth'] = 0,
			['doubleHeight'] = 0,
			['chrAddress'] = 12288
		},
		[3] = {
			['hScroll'] = 0,
			['tilemapAddress'] = 6144,
			['vScroll'] = 0,
			['largeTiles'] = 0,
			['doubleWidth'] = 1,
			['doubleHeight'] = 0,
			['chrAddress'] = 0
		},
		[0] = {
			['hScroll'] = 168,
			['tilemapAddress'] = 18432,
			['vScroll'] = 0,
			['largeTiles'] = 0,
			['doubleWidth'] = 0,
			['doubleHeight'] = 0,
			['chrAddress'] = 0
		}
	},
	['forcedVblank'] = true,
	['windowMaskMainSprites'] = true,
	['subScreenLayers'] = 19
},
['spc'] = {
	['x'] = 0,
	['sp'] = 253,
	['a'] = 0,
	['y'] = 0,
	['pc'] = 817,
	['status'] = 3
}	
So you should be able to do something like:

Code: Select all

state = emu.getState()
oamAddr1 = state.ppu.oamBaseAddress
oamAddr2 = (state.ppu.oamBaseAddress + state.ppu.oamAddressOffset) & 0x7FFF

User avatar
FitzRoy
Posts: 133
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: Mesen-S - SNES Emulator

Post by FitzRoy » Thu May 21, 2020 10:31 am

I have a lot of downtime at work and I'm about 1/3 done bugtesting your core against the library. The bugs I've found so far are here. I'll test your other cores eventually, too. It takes about 80 man hours to go through a 3000 game library, which I did twice for bsnes.

You might also be interested in a controller database I made for auto-hookup of special controllers. I'll attach the latest version here and just quote what I said on the higan github:
special_controller_db3.txt
(16.61 KiB) Downloaded 6 times
So I have a preliminary controller database here in line-per-entry CSV format. Each line has 4 fields. Field 2 identifies the game for db maintenance. Fields 1, 3, and 4 are intended to be used by the emulator. Field 1 is the game hash, field 3 tells the emulator what special controller is supported, and field 4 tells it whether it is optional or required. Note that the weird controllers (BatterUP, Barcode, TeeV Golf) are just here for posterity. I'm also missing checksums for NES games because I need to figure out how to isolate the data and not create checksums that are header-specific.

The emulator already knows port stuff behind the scenes (mouse = port 1, super scope = port 2). So that doesn't really need its own field.

The big win here should be that when the emulator detects a game that requires a special controller (Metal Combat, Lethal Enforcers, Mario Paint) it should just work using this system. The user will still have to use his capture mouse hotkey, but he won't have to manually hook and unhook controllers between games, or even know which games require which special controller.

For optional controllers, all we need is a boolean advanced setting that amounts to "Use mouse when supported". If a game optionally supported either the mouse or super scope, just go with the mouse.

There are a couple of games that did weird stuff like supporting a mouse in a supplementary fashion for minigames. We don't need to worry about that right now. But if it were to be supported in the future, it can be called "Supplementary" and require a modern pad (thumbsticks, dual triggers) to automap both port1 and port2 functions to the user pad.

Post Reply