nesdev.org

nitro2k01 wrote:Which service pack?

WinXP Pro, Version 2002, Service Pack 3

CCleaner says: "Windows XP Service Pack 3", Install Date "2011-03-04", Version "20080414.031514"

If you are running Windows Vista or newer, you may download the relevant version of the WinHlp viewer from this Knowledge Base article.

I'm curious about this:

creaothceann wrote:For comparison, time to complete the CT intro:
- 00:38 (492.11%) ZSNES 1.51
- 01:18 (239.74%) SNES9x 1.53
- 01:42 (183.00%) no$sns 1.0
- 03:07 (100.00%) realtime
(FD: mine runs at 30% speed :P)

That's on a P4 1.7GHz ... how can this run fullspeed on a 200MHz system? Perhaps he is doing something wrong?
I would like to suggest this as an alternative to ZSNES, and if it can indeed work at 200MHz with no frame skipping, it would be a great one.

nitro2k01 wrote:So have I. Now it will be interesting to see if byuu will approve my post.

That is a rather insulting insinuation :P

The e-mail address in the spam-shielded box is incorrect. The second r is missing.

Thanks! Should be fixed now (unless I got something else wrong).

The help files that are created by no$*** are incompatible with modern versions of Windows (XP with later service packs and later.)

Thanks for the info. Nasty... The thing that I liked about the .hlp stuff has been that it showed only one chapter at a time.
Moment, for now, here's a copy of the no$sns related chapters:
http://nocash.emubase.de/snsnotes.txt
(yes, I know, using pkunzip is retro)
the remaining chapters are just same as
http://nocash.emubase.de/fullsnes.htm
the downside there is that one can get lost when viewing all chapters in a single window. So, using the html version in the debugger wouldn't be my first choice.
Maybe I'll brew up my own .rtf viewer (currently I am translating my "source" text to .rtf format, and then compiling the .rtf to .hlp format). I guess I could drop the .hlp stuff and use the rtf-pages directly, main difference would be that I'd need to handle hyperlinks on my own, and need to add some search/print functions.

how can this run fullspeed on a 200MHz system?

Haven't really checked myself... I tried to run it on my old 200MHz computer last week, but it reported HDD not found, and after a few minutes it blew the fuse of the power supply... so, actually, I am able to confirm that it DOESN'T WORK on my 200MHz computer.
For the info on the webpage, the specs for my 1GHz computer should be are correct (runs 5-10 times faster than real SNES, with frameskip, of course), so well... I was in hurry, wanted to get emulator released, didn't have time to repair the old PC, and just divided 1GHz by 5, without recursing caches, bus speed and such important details.

I was playing SMW using the debugger, everything looked to be working fine, except that no tiles were shown at all in the 2bpp,4bpp, or 8bpp tabs. Don't know if it's a glitch or I'm an idiot, just thought I'd let you know. Very nice job though, if I do SNES development, I'll be using this a lot.

In the Vram Viewer window? Yes, that's missing. I simply wasn't able to display "so many" tiles (ie. I didn't got around to add a scrollbar, and instead, the current version doesn't display anything at all in that tabs).

Oh my! A NTT Data Pad? Now that has me curious... does NTT JRA PAT even remotely have sound... or maybe some music?

Other than that, I have to run your emulator under DOS (which is missing) in order to try it out...

byuu wrote:

nitro2k01 wrote:So have I. Now it will be interesting to see if byuu will approve my post.

That is a rather insulting insinuation

Backgound: I registered a year ago and was almost sure I posted something back then. Approving the first post makes sense, but if you need manual approval for more than one post, you're likely trying very concerned about what people are saying. In other words, what I said was based on an incorrect assumption.

For comparison, Wikipedia needs approval for the first ten edits to semi-protected articles.

Tell me: how hard is to write a super nes emulator? I see the specs and just say "wow".

A really bad NES emulator can be done in a day.
A really bad SNES emulator can be done in 2-3 weeks.

Perfecting an SNES emulator, however, takes many years.
In the NES scene, MMC5 is the ethereal nightmare. On the SNES, we have at least five coprocessors that put it to shame. Two of them by orders of magnitude.

Things are easier as of late. One uPD96050 DSP core can handle seven coprocessors that used to each require ~100+KB of trig code to HLE. Cx4 HLE was also a clusterfuck mix of ported-x86 ASM, floating point code, and fixed point code.

Overall, it's absolutely nothing compared to a next-gen system. If you can do NES, and are willing to patiently work on it, you can do SNES.

For an old "6502-based" system, it was more complicated than expected. I started in 2006, but gave up after a few months. And then resurrected the project in late 2010, alltogether, I worked around 20 months on it (lots of the time being blown up on the obscure add-ons though).

Perfecting an SNES emulator, however, takes many years.

True for all emulators, and their todo-lists are tendencially growing, making it quite impossible to get finished.

nocash wrote:For an old "6502-based" system, it was more complicated than expected. I started in 2006, but gave up after a few months. And then resurrected the project in late 2010, alltogether, I worked around 20 months on it (lots of the time being blown up on the obscure add-ons though).

Perfecting an SNES emulator, however, takes many years.

True for all emulators, and their todo-lists are tendencially growing, making it quite impossible to get finished.

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

When you compare that with the SNES and all of the extra chips it supports in its games... it's quite a challenge indeed.

PS: I've sent you an MP and a email, have you got any of them?

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.

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.

I misread him... however by comparison, if a NES emulator gets though when implementing mappers that pale in comparison to the most common of the chips the SNES uses in-cartrige... it's obvious that trying to write an emulator (not to mention if you want a precise one) is several orders of magnitude more complex than a NES one.

As you say, just the PPU which on a NES emu is the first rough bone you bite... well, the SNES with all the modes, backgrounds, etc supported. It's a great endeavor to tackle this and if nocash is applying the same thoroughly research he usually does, it's going to be one of the better and accurate SNES emus pretty soon.