nesdev.org

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

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.

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.

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.

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?

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.

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 ;-)

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: 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?

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.

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

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 : and here is your disassembled version :
why the sta REG_APUIO0 is not ok ?

Hope you will continue to improve your emulator

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

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.

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

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