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.
User avatar
SusiKette
Posts: 118
Joined: Fri Mar 16, 2018 1:52 pm
Location: Finland

Re: Mesen-S - SNES Emulator

Post by SusiKette » Sun Oct 04, 2020 2:12 am

I was looking through Super Metroid's code and I came across BRK #$9C. To my understanding BRK shouldn't have an operand, so is this a disassembly error in the debugger or is there another reason why it is displayed this way?

Also, would it be possible to add options in the debugger to hide RAM and mirror areas to make the overall length of the disassembly window shorter. If I remember correctly on LoROM simply hiding mirrors would already shorten the length almost 50% shorter since the $80:0000 - $FF:FFFF region mostly is mirrored to $00:0000 - $7F:FFFF, the only exception might be the work RAM and SRAM since they don't mirror (probably). I'm not sure if the entire $00:0000 - $FF:FFFF is displayed on the debugger, but also hiding areas that aren't mapped to anything could shorten the list a good amount as well.

EDIT: By the way, does Mesen-S have a display for how much of the ROM is logged as code, data, graphics, etc. ? I'm pretty sure Mesen did have that feature on the debugger.

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

Re: Mesen-S - SNES Emulator

Post by Oziphantom » Sun Oct 04, 2020 3:53 am

BRK has an param and adds 2 to the return address. Thus brk can be used to skip a byte if needed and you have an RTI BRK handler. It does nothing with said byte and it won't read it, so its a 1 byte instruction with an immediate param ;)

User avatar
SusiKette
Posts: 118
Joined: Fri Mar 16, 2018 1:52 pm
Location: Finland

Re: Mesen-S - SNES Emulator

Post by SusiKette » Sun Oct 04, 2020 7:02 am

I don't really get the point, but it can still cause incorrectly displayed code if the "BRK operand" is actually the next opcode. In this case a branch jumps over the BRK instruction. The BRK code itself is a JML instruction pointing to itself. I guess the debugger needs a check to see if the byte after BRK is executed an use that to judge how the code should be displayed.

aj7596
Posts: 2
Joined: Sat Aug 22, 2020 12:02 pm

Re: Mesen-S - SNES Emulator

Post by aj7596 » Sun Oct 04, 2020 4:07 pm

Mesen-S github repository is now archived.
https://github.com/SourMesen

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

Re: Mesen-S - SNES Emulator

Post by creaothceann » Sun Oct 04, 2020 5:07 pm

SusiKette wrote:
Sun Oct 04, 2020 7:02 am
I don't really get the point
6502 was designed to do as much as possible with a very limited transistor count. As a result it sometimes appears inefficient or confusing.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10

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

Re: Mesen-S - SNES Emulator

Post by Oziphantom » Sun Oct 04, 2020 9:22 pm

No this time BRK is very intentionally doing it, I'm fairly convinced.

If you have a EPROM that starts set and is programmed "lo" this allows you to patch about a byte or instruction by re programming all bits to 0. Saving lots of time and money back when it really mattered. In 2020 yeah pointless, 1975 quality of life feature through a through.

also software interuppts are a common paradigm for sys calls. i.e the IBM BIOS has INT 10h and INT 21h etc to do graphics, allocate memory, load files etc so if you want to use that system on a 6502 you can do

BRK #$21

and then you read the byte after BRK by doing a stack lookup and then fetch the byte. Some Assemblers back in the day added "software opcode" and extensions that used BRK Dispatch.

However 99% of the time you would disassemble it as a single byte. And the BRK #XX feature was "replaced" with the COP #XX on the 65816.

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

Re: Mesen-S - SNES Emulator

Post by FitzRoy » Sun Oct 18, 2020 11:42 am

It's a real shame that the quitting happened so suddenly and we didn't get a final 0.5.0 release. There were a lot of fixes since 0.4.0, and the latest dev build has a rather nasty regression that affects a lot of titles including SMW, Super Metroid, and Chrono Trigger.

User avatar
NovaSquirrel
Posts: 413
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Mesen-S - SNES Emulator

Post by NovaSquirrel » Sun Oct 18, 2020 7:01 pm

FitzRoy wrote:
Sun Oct 18, 2020 11:42 am
It's a real shame that the quitting happened so suddenly and we didn't get a final 0.5.0 release. There were a lot of fixes since 0.4.0, and the latest dev build has a rather nasty regression that affects a lot of titles including SMW, Super Metroid, and Chrono Trigger.
Sour mentioned on Reddit that he could still end up doing a "final" release that packages up the dev build fixes. He also mentioned on Discord that I could get my own improvements into the final release as well.

Post Reply