Hi, I've just released a new SNES emulator/debugger,
http://nocash.emubase.de/sns.htm
the thing should be quite accurate, support most coprocessors, and work with almost all games. But well, it's the first release, so I may have missed a lot of bugs...
Looking for some feedback if it does really work!
cu, Martin
There seems to be some bugs with the SPC initialization and/or emulation of the communication ports.
I tested some of my own stuff (like
this) and only got a black screen. Looking in the debugger, the 5A22 seems to be stuck waiting for the SPC.
Same thing happens with World Cup Soccer 2 - Striker (E).
Thanks! It's a problem with my APU Boot-ROM BIOS clone (it works when you have the original 64-byte BIOS ROM-image, file APU.BIN in BIOS folder).
The clone is breaking the original code into 5 sections: Part 1 reproduces the orignal opcodes at FFC0-FFCE, Part 2 those at FFCF-FFD5, and so on.
So, the FFC9 entrypoint value that you are using isn't working. I've read somewhere that it is "possible" to jump to that address (and was wondering if any programs are actually doing that). Well, now I know it... will be working in next update. Thanks again.
PS. I hope the sound output as such is okay.
Congratulations! I'm always excited to see new SNES emulators.
I noticed this in your documentation:
Quote:
F3 Debug (receive 128Kbytes from 0000:0000..0001:FFFF, for HEX-DUMP display)
F4 Debug (receive 32Kbytes from A000:0000..A000:7FFF, for HEX-DUMP display)
With the Debug commands, it'd might exceptionally easy to dump the on-chip BIOS ROM (without needing to decap the chip), but so far nobody seems to have done/tried to do so (???)
I must have missed the F3/F4 commands when I was researching this game. This was a big help, thank you.
Since I used your research, I wanted to make sure I gave you credit for it. As my setup is capable of handling this:
Here are the extracted 128K and 32K files:
http://byuu.org/temp/st0018-20120225.tar.bz2
They appear to be valid, I see "Copyright 1994 RAHDOMHOUSE" in the 128K file.
I wasn't having much luck with A3 {32-bit addr} {read 128-bytes}; but I can also dump the full 4GB range if you can elaborate on how that command works. I'd also love to know how you obtained this info if you don't mind, as anything will be helpful to me.
I hope this will be of use to you. If we make any progress on these, I'll pass the information along.
Lastly, I am also writing an SNES emulator. You may be interested in looking at its source for further information.
You can download that here if you like:
http://code.google.com/p/bsnes/downloads/list
I also have a forum with several years of research notes at
http://board.byuu.org/
Please don't hesitate to reach out to me any time if you have questions or want to team up on a tough new problem, I'd be glad to help.
I'd also love to hear about any new research from your end, too!
This blows all the other SNES debuggers away!
Edit: looks like it doesn't quite have all the debugging features in there though...
Two unexpected things at once
Tried to contact you years ago but you completely managed to disappear so it's nice to see you seem to be still alive and kicking
Now if only your page would be working... I could have a look at this probably new masterpiece again. But someone shouldn't be so much in a hurry
-koj
I really want to try it out, and check the documentation, but since this is down for now...
Yeah, I've somehow disappeared for some years (left the planet and silently worked on some obscure emulation projects, now that I am back on earth, I've planned to release 1-2 new emus, and a bunch of updates for older emus).
But if something can wrong... then it happen just at the the wrong moment, sorry. The emubase server has been offline for some hours last week, too (don't know why). I hope it'll be back online tomorrow, or else I'll upload a copy somewhere else. Thanks that you mentioned the problem!
I know NO$GBA has a severe CPU bug in it, pushes and pops to the stack are broken if sp is one of the registers that gets pushed or popped. Really bad now that GCC is actually using that instruction a lot now.
At the moment,
http://nocash.emubase.de/sns.htm is back online.
Please post something here if it happens to disappear again!
Long time no exist, I'm tempted to say. If you want (hopefully more stable) hosting, I can help you with that. I have a good hosting package and could spare some space and traffic.
The e-mail address in the spam-shielded box is incorrect. The second r is missing. (Confirmed against the hex.)
Just for fun I thought I'd as you, do you have a DOS build of no$sns? I still have a P100 and I want to see how it compares to ZSNES in speed on such an old machine.
I could also spare some space/traffic on my hosting as well.
Another thing. The help files that are created by no$*** are incompatible with modern versions of Windows (XP with later service packs and later.) There are third party software that can read the files to some degree, but I would suggest distributing help files as HTML files. Maybe it's anti nocash in spirit, but it would help all of us with modern computers with "hundreds of megahertz".
If you feel like it and you dare use IRC, drop by #gbdev on EFNet.
Hi! I've posted my comments
here.
nitro2k01 wrote:
The help files that are created by no$*** are incompatible with modern versions of Windows (XP with later service packs and later.)
I can read them fine on XP, haven't tested on 7 yet.
creaothceann wrote:
Hi! I've posted my comments
here.
So have I. Now it will be interesting to see if byuu will approve my post.
creaothceann wrote:
I can read them fine on XP, haven't tested on 7 yet.
Which service pack? I think support .hlp files was removed in SP3 or so for vague security reasons.
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
Quote:
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).
Quote:
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.htmthe 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.
Quote:
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).
Quote:
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).
Quote:
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?
Quote:
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:
Quote:
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.
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:
Quote:
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:
Code:
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?
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 :
Code:
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:
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
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:
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.
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.
Code:
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.
For disassembling old games, perhaps the right solution might rely on something similar to the code/data log (CDL) of FCEUX.
Quote:
perhaps the right solution might rely on something similar to the code/data log (CDL) of FCEUX.
Code/data logger sounds like a pretty cool feature. Thanks for the idea!
When using it for disassembling purposes, the downside would be that one would first need to play the whole game. And even then it may still miss some hidden or unused code/data areas.
That hasn't stopped its usefulness in FCEUX. If you add this feature to No$SNS that would be awesome. Something else that would help that was not added to NES but might be easier on SNES, is an address label logger, to help log address labels if someone intends to move code/data around it could help cut down the manual work a bit.
nocash, I've got at least one example where debuggers might have trouble... and believe me, this one I didn't need a debugger. ^_^
You're not going to find Mega Man's Soccer's hidden ending using any old debugger...
That's actually something that I found via good 'ole hex editing. I used my hex magic to find the ending through musical references to two ending tunes (yes, they were confirmed to be ending tunes by me), and then that lead to a whole bunch of other discoveries. I actually collaborated with JLukas to complete the package for the original ending, and I found a second ending.
The address label feature isn't a bad idea. Some of my music modifiers do use pointers (which means they require safe-cracking), and if you relocate that data, the music modifier is null and void until you modify your pointers. Sometimes, through common start and endpoint hex values in the data (or even ROM text), I can get away with finding unused music that pointer data alone won't reveal.
Also, another option that can help for debugging : can have a debug console to display debug message like with no$gba.
By the way, just donate to have the last 1.2 version (your site is now online again ), thanks for your great job.
Quote:
debug console to display debug message like with no$gba.
Yes, that would be neat, I've been wondering about (how) to add it, too.
At the moment I'd vote for a CHAR output function (unlike the STRING output in no$gba). And that... by writing the character to an unused I/O address...
Are there already SNES emulators having that feature (so I could use the same I/O address)? Or real SNES hardware having that feature (like an RS232 port used to output characters to a terminal screen or log file)?
KungFuFurby wrote:
nocash, I've got at least one example where debuggers might have trouble... and believe me, this one I didn't need a debugger. ^_^
Why would you expect a debugger to help you find alternate game endings?
If each ending uses a game's script system, and there's a table of scripts, then a debugger could help find the table.
For example, the ending of Thwaite assumes that at least one missile landed, and one of the characters investigates the wreckage and discovers who was the culprit. Stepping through the script system's setup (or, in the case of a freely licensed game like Thwaite, reading through the source code) would reveal a table that points to something else. (Spoiler:
There's a hidden set of scripts for a no-damage run, which has a bunch of bad puns on "TAS". This leads to an ending where nobody discovers what really happened, and then it breaks the fourth wall and a developer thanks the player for having the dedication to make a tool-assisted speedrun.) This "something else" is
not canon.
I've donated to get access to v 1.2. I'm noticing that assigning buttons on an external game controller now works. However, the default values created a confusing problem for me.
I have a SNES controller adapter with two ports. For whatever reason, I had the controller plugged into port 2. After assigning the buttons, I noticed (in for example Super Mario World, and later the SNES test program) that pressing one key on the pad pressed two different keys. The problem was that player 2's control were enabled and mapped to buttons 1-8 port 2. This is true even when "game controllers" is set to "one joypad". I think a safer bet for default values is to not assign any buttons, since they most likely won't end up on the button you want.
If a button is unassigned, it's saved as 00 in the config string. It's then loaded as "button 89" and consequently saved as hex 59 in the config string. I guess this doesn't hurt, but is a bit ugly.
I would suggest making the pad fully reassignable, including direction keys. You may want to to do this for various reasons.
The VRAM viewers tile views (and sometimes BG4?) are showing complete junk data.
The "stretching mode" setting does absolutely no difference in the two modes that I'm able to test, software and StretchDIBits. For example, software mode uses the blocky stretch mode, always, except in 50% zoom, where it uses resample mode, always.
The stretch type (which is a bad name for the setting) DirectDraw doesn't work here. I'm guessing some piece of Win9x voodoo stopped working in newer operating systems. I suggest also supporting Direct3D, which works better for various reasons on hypermodern operating systems (Vista, 7).
And finally, any chance of a DOS build of no$sns?
Quote:
any chance of a DOS build of no$sns?
wtf? People still run DOS?
I want to have it for fun. I want to try it on a P100 laptop I have. no$sns Win performance is worse than ZSNES DOS performance, and even that is almost useless on that computer. But maybe Martin's asm+DOS can do wonders for this machine. On the other hand, ZSNES is written in asm, too...
nitro2k01 wrote:
[...] ZSNES DOS performance [...] is almost useless on that computer.
Really? I could have sworn I remembered running ZSNES 0.400 at full speed on a 486/66. (albeit without the pseudo-transparency mode.)
1) That was that version and not the latest 2) I'm getting maybe 20-30 FPS here Super Mario World. (Don't remember since the last time I turned that computer on.) Might vary depending on the game as well, of course.
Just uploaded no$sns v1.3,
http://nocash.emubase.de/sns.htmNew features are Nintendo Super System (Arcade Cabinet) emulation, and support for some more controllers/add-ons: Barcode Battler (EAN-13 format only, the formats for EAN-8 and UPC-A are still unknown), Four Twin Taps (for 8 player quiz game), and the Pachinko dial (for utmost stupidity). All that bizarre features are available to people donating some money to the nocash project; money will be blown up on making more such strange stuff. Or, without donating, everybody can now download no$sns v1.2 for free - with equally bizarre features like SFC-Box emulation.
For the game pad configuration - I've added a feature in no$sns v1.3 that prevents assigning the same PC gamepad to two different SNES joypads - I hope that will avoid problems/confusion in future.
DOS version would be nice. But... the modern multisync monitors are so damn slow on switching from text to graphics mode - I think it would be a pain to use (and make/test) it. And not too sure if it'd be much faster than the windows version - the overall emulation speed should be same no matter of the OS - at its best, things like video output might be slightly faster.
> I've added a feature in no$sns v1.3 that prevents assigning the same PC gamepad to two different SNES joypads
Meh, I love mapping player 2 the same as player 1, sans swapping left+right around. Makes for fun 'clone' fighting in Street Fighter games.
nothing new regarding improvments, bugs posted in this thread ?
May I ask if fullscreen would be too much to add? A mode that runs fullscreen at 512x448 (2x blocky scaled) would be wonderful and I would donate happily for it.
Quote:
nothing new regarding improvments, bugs posted in this thread ?
No still no screenshots and such things. For the bugs - I've somehow lost track about what is still wrong. The "donate for update" idea has been rather contraproductive for getting bug reports :-/ the good news is that bug reports for v1.2 will still apply for v1.3 so everybody can see what is wrong with this emu.
Quote:
May I ask if fullscreen would be too much to add? A mode that runs fullscreen at 512x448 (2x blocky scaled) would be wonderful
Yeah, isn't my personal priority, but should be a must-have feature... it is somewhere on my todo list. Programming it isn't really difficult - but somehow uncomfortable (a bunch of small details to be recursed).
The normal way to go would be somehow scaling the image to the current screen resolution, like 1280x1024 or whatever you have, eventually recursing the SNES aspect ratio. Doing that scaling by software would be endless slow, and my attempts to use hardware accellerated scaling via OpenGL and DirectDraw have been rather disappointing.
The other way would be switching to 640x480 pixel mode, scaling would be faster in that case, but the mode switching would be 2-3 seconds (on my computer at least... maybe better monitors/drivers can be doing it faster... or even slower?) - if you want to frequently switch from one window to another then it'd be useless annoying. Though if you want to play continously for next some hours then a few 2-3 second delays might be acceptable?
On "wide" screens, I think 640x480 pixels would work, but the pixels would become horizontally stretched to non-square ratio, right? In case of the SNES, that might be a "desired dirt effect".
Is the Character Viewers (2bpp, 3bpp, 4bpp, 8bpp) and a few other VRAM viewer stuff fixed yet (1.4)?
SPC needs to be fixed a bit too, but in a lower priority...
nocash wrote:
The other way would be switching to 640x480 pixel mode, scaling would be faster in that case, but the mode switching would be 2-3 seconds (on my computer at least... maybe better monitors/drivers can be doing it faster... or even slower?) - if you want to frequently switch from one window to another then it'd be useless annoying. Though if you want to play continously for next some hours then a few 2-3 second delays might be acceptable?
Correct. If I'm going to be playing for 15 seconds at a time, then I'm either debugging or taking screenshots, and in either case, I want window mode.
Quote:
On "wide" screens, I think 640x480 pixels would work, but the pixels would become horizontally stretched to non-square ratio, right? In case of the SNES, that might be a "desired dirt effect".
A lot of NTSC VDPs have a 5.37 MHz dot clock, such as ColecoVision, NES, SMS, and Super NES. The pixel aspect ratio (PAR) for these is 1.143:1, or exactly 8:7 if Rec. 601 is to be believed. The PAR of a 640x480 video mode on a 16:9 screen is 1.333:1. The ideal mode for a perfect PAR is 560x480 for a 4:3 screen or 746x480 for a 16:9 screen.
And how do you translate from the Super NES's RGB space to the monitor's RGB space? I know the TurboGrafx-16's RGB space isn't a direct mapping due to cost cutting on the encoder (and quite off in several places, I've read), but I haven't investigated that of the Super NES. Do you simulate the encoder and decoder?
tepples wrote:
nocash wrote:
The other way would be switching to 640x480 pixel mode, scaling would be faster in that case, but the mode switching would be 2-3 seconds (on my computer at least... maybe better monitors/drivers can be doing it faster... or even slower?) - if you want to frequently switch from one window to another then it'd be useless annoying. Though if you want to play continously for next some hours then a few 2-3 second delays might be acceptable?
Correct. If I'm going to be playing for 15 seconds at a time, then I'm either debugging or taking screenshots, and in either case, I want window mode.
Quote:
On "wide" screens, I think 640x480 pixels would work, but the pixels would become horizontally stretched to non-square ratio, right? In case of the SNES, that might be a "desired dirt effect".
A lot of NTSC VDPs have a 5.37 MHz dot clock, such as ColecoVision, NES, SMS, and Super NES. The pixel aspect ratio (PAR) for these is 1.143:1, or exactly 8:7 if Rec. 601 is to be believed. The PAR of a 640x480 video mode on a 16:9 screen is 1.333:1. The ideal mode for a perfect PAR is 560x480 for a 4:3 screen or 746x480 for a 16:9 screen.
And how do you translate from the Super NES's RGB space to the monitor's RGB space? I know the TurboGrafx-16's RGB space isn't a direct mapping due to cost cutting on the encoder (and quite off in several places, I've read), but I haven't investigated that of the Super NES. Do you simulate the encoder and decoder?
The option to preserve pixel aspect ratio correctness VS pixel-to-pixel crispness would ideally be open to the end-user of the emulator.
Got the debug message window implemented in no$sns. Now I need an I/O port where I can write the ASCII characters to (so they will be shown in the new window). I could just pick Port 21FFh, which shouldn't be used for other purposes.
But if possible, I would stick with existing "standards". How are other SNES emulators doing character output? What I/O address(es) are they using? Which emulator(s) do support character output? Are there any?
PS. same question also for the NES (in case anybody here knows anything about NES char output).
Just released no$sns v1.4 -
http://nocash.emubase.de/sns.htm (it's currently completely freeware, all versions available with and without donations; I am totally broke so it doesn't matter if I don't get money or not).
The debug message character output via port 21FCh is now working. There's also a new 21MHz timer mapped to reading port 21FCh. And the VRAM viewer is now supporting the Tile View pages (with scrollbars to view the whole 64Kbytes of VRAM).
The NSS arcade cabinet emulation is now looking much nicer & does now works with all existing 12 games - with thanks to DogP for datasheet, font-dump, and prom-tests.
And finally - the one thing that everybody has waited for: The Exertainment Bicycle is now emulated - so you can now do all the hot exercising at home (by just pushing your analog gamepad forward) - with thanks to byuu for identifying the exertainment's rs232 chipset.
Quote:
And finally - the one thing that everybody has waited for: The Exertainment Bicycle is now emulated
Pssh. You know damn well that we've all been dieing to play JRA PAT with an emulated NTT Modem network.
I want to bet on my Japanese horse races, dammit!
Anyway, congrats on the bike support. Did you ever figure out what's stored in the base unit's SRAM chip?
The modem? I thought you wanted
http://board.byuu.org/viewtopic.php?p=70939#p70939 the bicycle.
Well, then the modem one, okay. Ah, but that's difficult - english translation of JRA PAT would be very helpful!
At the moment I've no clue if it's using a specific horse-related transfer protocol, or if it's some standard mailbox/terminal protocol.
The other thing I still had in mind would be the Lasabirdie golf club. Does anybody have that thing? Or know where to contact such people? Photo of the interiors would be neat to get an idea how it works.
It uses HBTP, Horse Bet Transfer Protocol.
> The other thing I still had in mind would be the Lasabirdie golf club. Does anybody have that thing?
It's obscenely expensive, like $400 USD+.
> Photo of the interiors would be neat to get an idea how it works.
If I'm thinking of the right one, it's just a motion sensor. Or maybe that was the baseball bat. Meh.
Then one just needs to add OpenNetworkConnection('hbtp://www.jra-pat.com/') to the emulators init function!
Pretty lame that it wasn't emulated yet ;-)
The Lasabirdie has a yellow laser symbol on the golf club, and thus (probably) a series of light sensors in the golf mat.
Rare as it is, I am not hoping for much more tech info than photos. If somebody shows up owning that thing, I could maybe spend a day on making test program that displays the bunch of numbers that it's transferring to the SNES.
byuu wrote:
Or maybe that was the baseball bat. Meh.
Speaking of the baseball bat, I have one of those around here somewhere. If you're interested, I could see about a teardown...
Yeah, baseball bat would be also interesting. Though it seems to be quite dumb - just simulating a normal joypad.
As far as I understand, there aren't any direction/position sensors, and reportedly not even speed/strength sensors, and swinging the thing just "pushes" a joypad button. Or are there more features in there?
The biggest secret that I am aware of are the four DIP switches, I would assume that they just allow to map the swing sensor to A,B,X,Y joypad buttons (?)
The TeeV golf club is bit more intelligent - I don't really know how it works - but it seems to be able to sense speed/strenght, and probably also if you've missed the ball, and it appears to generate game-specific joypad signals (via it's game-specific "bios" cartridge).
The Lasebirdie golf club is pretty different: it doesn't simulate joypad signals, and instead it's transferring some special analog stuff, probably with hit/miss, speed/strenth, and maybe even direction information.
I wonder if the time the button is held is proportional to strength. Otherwise it might just be timing of the swing, like baseball in Wii Sports.
Hi nocash,
Don't want to stress you but do you have some news about a new version of no$sns ? some times ago, i posted some features (and bug reports ...) that should be great for no$sns (such as good vram & ram init and snapshot capability).
Continue your great job regarding emulators and as usual, i wil donate for your new update (i did it this day for your new no$gba version, thanks for that
)/
New post, sorry about debug function.
I tried to add debug function to my liv (PVSnesLib) with such code :
Code:
.equ REG_DEBUG $21FC
.section ".consoles_text" superfree
;---------------------------------------------------------------------------
; void consoleNocashMessage(const char *message);
consoleNocashMessage:
php
rep #$20
phy
ldy #$0
; Let tcc__r2 point to the message
lda 7,s
sta tcc__r2
lda 9,s
sta tcc__r2h
sep #$20
-: lda [tcc__r2],y
beq +
iny
sta.l REG_DEBUG
bra -
+: ply
plp
rtl
.ends
And i try it with, for example :
consoleNocashMessage("hello world\r\n");The code works fine in no$sns, i can see it with 'step by step' running, message pointer is ok and i send each character to $21fc address. But nothing appears in debug windows
, any idea ?
*EDIT 05/09/2013 , stupid i was, need to activate debugmessage in OPtions/Debug. Works fine now. Thanks a lot for this option nocash ! *
hello, can anybody help read a multicart with Lorom/hirom mixed games? We trying to upgrade the menu on the multicart, after we did, the Hirom game (Nwarp Daisakusen) freezes at intro screen, but if you reset and open skip and friends, then reset and open Nwarp Daisakusen it works.
We are trying to get that bug fixed. We can offer donation for time's worth.
I know that No$SNS is the only emulator that supports multicart bankswitching.
Quote:
I know that No$SNS is the only emulator that supports multicart bankswitching.
I support it on official hardware, eg the SNES-EVENT competition boards (Campus Challenge '92 and Powerfest '94), but I don't emulate bootleg / pirate cart / third-party pay-to-play systems.
May as well answer your NA PM here: afraid I don't have free time at the moment to help you with your issue, sorry about that. Hope someone else here can help you.
No problem man, thanks for the reply!