no$sns - new SNES emulator

LuigiBlood · Post by **LuigiBlood** » Thu Mar 01, 2012 1:37 pm

So the website is down again, and this time...

The Satellaview Server for NO$SNS doesn't work anymore too.
I thought it was included in it. So it's the world's first online Satellaview Server in that case...

Hamtaro126 · Post by **Hamtaro126** » Thu Mar 01, 2012 1:42 pm

byuu wrote:
The problem is that the NES is hardly a simple 6502 based system... in fact emulating the 6502, even if you write your own core is a breeze. The PPU has a lot of tricks also, and probably one has to spend quite some time figuring it out fully... then you discover than your emulator can only execute a handful of games from the first era of the NES... then you start with the MMCs... and your life as you knew it is over :p
nocash was speaking of the SNES, which is 6502-derived.

Again though, as I've said, the NES is a walk in the park in comparison. I've done both, I should know. The NES PPU has eight registers, and full documentation on what every single cycle does. The SNES PPU has 64 registers that are all bit-packed with multiple functions, and defies attempts to be documented even at the scanline level.

Not saying you shouldn't be proud of an NES emulator. A PS1 emulator is way harder than SNES, PS2 way harder than PS1, and PS3 way harder than PS2. With progress comes added complexity.

Where does Gameboy-DS series, N64, Gamecube-Wii, etc come to the equasion?

NoCash: I really like your emulators, This one is the best of all, 'Nuff said.

Post by **tepples** » Thu Mar 01, 2012 6:24 pm

Correct me if I'm wrong, but as I understand it, consoles within a generation are comparable in complexity. GameCube is probably comparable to PS2, and a Wii is literally an overclocked GameCube with more RAM and a USB port hanging off an ARM-powered IOP on the northbridge. Game Boy is roughly equal to NES + MMC5 but with more tolerance for bad timing due to the reliable scanline counter. Game Boy Advance is comparable to Super NES without the coprocessors, and DS might be comparable to a Saturn, or a bit tougher than PS1 due to the multiple cores.

Near · Post by **Near** » Thu Mar 01, 2012 10:50 pm

You really just have to look at each system individually. The most striking contrast is probably the Dreamcast being far easier to emulate than the Saturn.

Nintendo's handhelds are always two generations behind their competitors.

> Game Boy is roughly equal to NES + MMC5 but with more tolerance for bad timing due to the reliable scanline counter.

Game Boy's main problem is the absolute horse shit we have for documentation. The best thing out there is basically Pan Docs. Which would be a bit like getting your NES info from Nesticle. sinamas is the only one with decent emulation sharing source code, but his programming style (it's very efficient) makes it very difficult to glean information from.

How does mid-scanline stuff work on the DMG? Who knows!! We can't even get basic questions answered like what happens when you write to LY. Eg does it only reset a dummy cycle counter, or does it reset the actual line counter position? If the latter, you could basically drive the top half of the display at 120hz, which would be psychotic.

Karatorian · Post by **Karatorian** » Fri Mar 02, 2012 9:36 pm

byuu wrote:How does mid-scanline stuff work on the DMG? Who knows!! We can't even get basic questions answered like what happens when you write to LY. Eg does it only reset a dummy cycle counter, or does it reset the actual line counter position? If the latter, you could basically drive the top half of the display at 120hz, which would be psychotic.

Is this the sort of thing one could figure out with a flash cart and a test ROM? Or would you need to break out the o'scope?

sinamas_ · Post by **sinamas_** » Sat Mar 03, 2012 4:22 am

From what I can remember, I did some testing of LY writes at some point (you can probably find the tests with expected output if you snoop around the gambatte repo), and concluded that LY write, in fact, does absolutely nothing.

gilligan · Post by **gilligan** » Sun Apr 08, 2012 4:49 am

A quick question on the debugger. There is something in the settings about displaying "Symbolic information (TAB)" but i can't seem to find any further information on this ? How does that work, does it work at all ? Do I have to provide some text file or poke it in the rom or is it something else than I think it is altogether ?

Having the debugger display names of labels/variables would be a welcome feature ;-)

nitro2k01 · Post by **nitro2k01** » Sun Apr 08, 2012 5:08 am

Gilligan, you should be able to load symbols by creating a file which has the same file name as the ROM, but with extension sym instead of sfc, smc, bin or whatever. The format should be something like:

Code: Select all

0000:0000 something

Where the first two digits are the bank or whatever (or 0 if not applicable) and the last two digits are the exact address. However, the exact format could vary depending on the convention for the SNES address space and ROM banking, which I'm not familiar with. I can't get no$sns to load a symbol file (always complains about broken lines). Either I don't understand the address format used for SNES/no$sns or this function is broken. Maybe Martin could clarify?

gilligan · Post by **gilligan** » Sun Apr 08, 2012 5:49 am

thanks for that info nitro. I tried everything but can't get it to work either. I would assume it expects the same format that no$gmb used for .sym files which is exactly what you suggested. I tried various stupid variations including DOS line endings and what not. Doesn't work.

If we were talking about bsnes or ssnes or some other F/OSS emu i had checked the sources long ago, but we are talking about no$snes which is a closed source emu written in x86asm .. alas .. :) Lets hope the author enlightens us sooner or later.

nocash · Post by **nocash** » Mon Apr 30, 2012 4:15 am

Uploaded a new no$sns version,
http://nocash.emubase.de/sns.htm
(if the server is down, please retry 1-2 days later)

For the .SYM files, format is "00123456 label_name". For an example, download the Magic Floor source code, and assemble it via no$sns utility menu. The feature still needs some polishing (like adding a way to define separate labels for the APU address space).

alekmaul · Post by **alekmaul** » Tue May 01, 2012 2:42 am

Hi nocash,
Yes, you website is down currently, will try to download it later

...

Except that, so happy to use your emulator, really great and easy like no$gba to use.
I noticed some few things that seems to not be in this emulator but that are on others like no$gba. Do what you want with them, just to inform you (I think it can improve no^sns but it's your choice

).
- PrintScreen to have a bmp screenshot will really be great.
- Help file compatible with windows 7
- an option to run the emulator with a file in command line environment (so i can add launch of .sfc/.smc file with emulator directly in makefile when doing some homebrews)
- running one frame option (like no$gba with / key)
- open a file without running it directly (to begin with step by step running)
- reset without run just after
- when i launch again a file, without exiting no$sns, it seems that some values are still in memory (like palette color values for example)
- buttons on debug screen like no$gba to trace/screenshot and an access to SNES Specs.

- I begin to add spc snesmod support in my PVSnesLib and notice this thing :
here is the source code :

Code: Select all

	sei	
-:	ldx	REG_APUIO0	; wait for 'ready signal from SPC
	cpx	#0BBAAh		;
	bne	-		;--------------------------------------
	stx	REG_APUIO1	; start transfer:
	ldx	#SPC_BOOT	; port1 = !0
	stx	REG_APUIO2	; port2,3 = transfer address
	lda	#0CCh		; port0 = 0CCh
	sta	REG_APUIO0	;--------------------------------------
-:	cmp	REG_APUIO0	; wait for SPC
	bne	-		;

and here is your disassembled version :

Code: Select all

0000:BF79þ78           sei
0000:BF7A AE 40 21     ldx 2140
0000:BF7D E0 AA BB     cpx #BBAA
0000:BF80 D0 F8        bne BF7A
0000:BF82 8E 41 21     stx 2141
0000:BF85 A2 00 04     ldx #0400
0000:BF88 8E 42 21     stx 2142
0000:BF8B A9 CC 8D     lda #8DCC
0000:BF8E 40           rti
0000:BF8F 21 CD        and (CD,x)
0000:BF91 40           rti
0000:BF92 21 D0        and (D0,x)
0000:BF94 FB           xce
0000:BF95 AF CF A9 00  lda 00A9CF
0000:BF99 EB           xba
0000:BF9A A9 00 A2     lda #A200
0000:BF9D 01 00        ora (00,x)
0000:BF9F 80 0D        bra BFAE

why the sta REG_APUIO0 is not ok ?

Hope you will continue to improve your emulator

nitro2k01 · Post by **nitro2k01** » Tue May 01, 2012 2:58 am

I know nothing about 65816 programming, but looking at the opcode chart, this instruction seems to be incorrect, and I would maybe blame the assembler.

Code: Select all

0000:BF8B A9 CC 8D     lda #8DCC

lda with an immediate argument should have a two byte argument (right?). Your assembler turns "lda #0CCh" into "A9 CC" (8D is the next sta opcode) where it should turn it into "A9 CC 00". Unless I suck completely.

mic_ · Post by **mic_** » Tue May 01, 2012 4:31 am

If P.m==1 (i.e. A is 8-bit, which the comments imply that it is) then A9 nn is correct. So the code is most likely right, it's just the disassembler that's confused.

nocash · Post by **nocash** » Tue May 01, 2012 5:40 am

> PrintScreen to have a bmp screenshot will really be great.
Yup... when I've time.

> Help file compatible with windows 7
Dito. And damn microsoft for no longer supporting their own file format.

> an option to run the emulator with a file in command line environment
commandline "no$sns c:\path\filename.ext" should be working.

> running one frame option (like no$gba with / key)
Yup, would be handy.

> open a file without running it directly
Disable the "autostart" checkbox in open file menu.

> some values are still in memory (like palette color values for example)
Yeah, might be cleaner when erasing that values. Though real hardware doesn't do that either.

Code: Select all

0000:BF8B A9 CC 8D     lda #8DCC 
0000:BF8E 40           rti

Disassembling 8bit "lda #CC" in 16bit mode obviously gives "lda #xxCC". Just one of the nastier aspects when dealing with 65C816 code. I guess I could improve that a little, but there's no perfect solution...
For debugging "new" programs, I could pick 8bit/16bit mode info from the .SYM file (if it is present).
And for disassembling "old" games... one could try to scan memory for sep/rep opcodes and "guess" the intended modes... chances to might be around 80-95% to guess the correct mode. Cases where it'd may go wrong would be opcodes mixed with data areas, or jumps, especially when using indirect jump-tables.

Post by **tepples** » Tue May 01, 2012 6:29 am

For disassembling old games, perhaps the right solution might rely on something similar to the code/data log (CDL) of FCEUX.