Mesen-S - SNES Emulator
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Mesen-S - SNES Emulator
would it be possible to make a "ROM is RAM" mode for development?
Re: Mesen-S - SNES Emulator
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.Oziphantom wrote: ↑Mon Mar 02, 2020 10:00 pm would it be possible to make a "ROM is RAM" mode for development?
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.
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Mesen-S - SNES Emulator
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.
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.
Re: Mesen-S - SNES Emulator
Ah, no problem. I never actually played the game much to know about it.
Re: Mesen-S - SNES Emulator
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.Sour wrote: ↑Tue Mar 03, 2020 2:12 pmI'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.Oziphantom wrote: ↑Mon Mar 02, 2020 10:00 pm would it be possible to make a "ROM is RAM" mode for development?
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 come from the net. Through systems, peoples and cities to this place.
-
- Posts: 610
- Joined: Mon Jan 23, 2006 7:47 am
- Location: Germany
- Contact:
Re: Mesen-S - SNES Emulator
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.)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.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Re: Mesen-S - SNES Emulator
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.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 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)
Re: Mesen-S - SNES Emulator
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)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)
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.
Re: Mesen-S - SNES Emulator
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.
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
Re: Mesen-S - SNES Emulator
I've recompiled it to the git version available today and have noticed the improvements to the tile viewer.Sour wrote: ↑Thu Apr 09, 2020 9:02 pmThat 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.
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: 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.
Re: Mesen-S - SNES Emulator
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.
Re: Mesen-S - SNES Emulator
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.
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.
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
Re: Mesen-S - SNES Emulator
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
}
Code: Select all
state = emu.getState()
oamAddr1 = state.ppu.oamBaseAddress
oamAddr2 = (state.ppu.oamBaseAddress + state.ppu.oamAddressOffset) & 0x7FFF
Re: Mesen-S - SNES Emulator
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:
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:
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.