Whee! as soon as my money is transferd to my paypal account I will recive a Super Wild Card DX2 64M PAL machine and Disk Dual for it. :D
Then I'm going for some serious SNES developing (if nothing comes in my way) :)

sorry for misspellings

go for it, snes could do with some new stuth
p.s. you don't have to transfer money to paypal it can do direct bank transfer

I've been trying to code some on it last summer.. but as usual I quit after a while cuz it's so damn boring to just test the things on emulators.. the other reason was that there isn't any information on how the sound chip work.. like I wanted to just make a "beep" from the snes but no one knew how.. so thats one thing I'm going to experiment with now I think.

sorry for misspellings

Groovy, you have any plans on what to make?

Be glad you'll have a parallel port interface to use. I had to use CD-RWs and floppy disks for testing my NSF player, which got really annoying once the program became larger than 8 Mbit, heheh.

If I had time to do it, I'd like to make an XM player or an NES emulator for SNES. That would be pretty nifty.

Yeah. A XM player would really be groovy :D

sorry for misspellings

Darn right. I first abandoned the SNES in favor of other platforms (eventually the GBA) simply because I couldn't get the SNES sound chip to do anything. Does there exist some generic, fully-commented SNES sound driver, along with fully-commented 65c816-side loader code?

well the best info I've ever found gotta be the MMSdemo2 (http://filebox.vt.edu/users/rogrubb3/SNESDev/CodeLib/MSSDEMO2.ZIP) it includes code to play a mms file and other nice stuff :D

sorry for misspellings

You can examine the infinity source that comes with sndoc230.lzh / sndoc230.zip.

The audio code was taken from something minus (author of x816) ripped or whatever. I've heard the song in some other game before. I personally have never done SPC-700 stuff -- too overzealous -- but as far as getting the sound chip to do anything, it's a pretty minimal bunch of code that's included in infinity.

-- jdc

> well the best info I've ever found gotta be the MMSdemo2
> (http://filebox.vt.edu/users/rogrubb3/SNESDev/CodeLib/MSSDEMO2.ZIP) it
> includes code to play a mms file and other nice stuff :D

Don't get too excited. I believe they did all their work on emulators, because several things don't quite work right. (And the music player is one of them... unless they fixed it, but they haven't updated in a LONG time. So I doubt it.)

As long as you have a copy of the SPC BootStrap code (64 byte program that is ran after a reset), and explanations of the APU (SPC700 and DSP) ... you should be fine. Since so much functionality is coded into the DSP BIOS (DSP code can't be changed), it's actually not that hard to make some sounds come out of the speakers. (And now that there are some good WAV -> BRR converters freely available, the sounds can actually be intelligible on first try.) Lack of good info and a BRR converter is usually what kept people from working on the SNES sound. Since both are available now, a good chunk of work that would go into making a set of tools is already done for you!)

Don't get me wrong though. It's a lot of work to make a good set of music/sound tools. Especially music playing, since it basically requires making a music converter (to a succinct music language) and an interpretter running on the SPC700 to read what you converted it to. But in truth, the SPC700 is much nicer to program than the SNES's main processor in many ways.

----

If you're still looking for more SNES info, just let me know and I'll point out some good docs (the truth is, you need to be very careful ... there are a lot of bad docs out there. And even the good ones have a few really annoying mistakes... which I admit, even after people figure out, we just make note to ourselves ... and never fix. Sorry about that. But people have been doing it for years, and I am among the guilty. So, I can't stress enough, definitely ask around if something is giving you trouble.

Good luck,
-neviksti

P.S. I don't know how much of a beginner you are, but it might be useful to check out my "SNES Starter kit". I think you may even be able to get a copy of it from the main page of this site. I've been meaning to add some of my music/sound library/tools in there, but it's a bit too specialized towards my needs at the moment (ie. not easy to use; requires too much hand tweaking, and therefore not exactly something that would be useful for beginners in a starter kit).

I thanks for the good information. :)
So you don't think that the mssdemo code would work on a real snes? =(
And.. I would be more then happy of all docs you could point out :D

Btw. I got my Super Wildcard DX2 today :D
unfortanly I haven't test it yet cuz I don't got any 9V~12V DC Adaptor at home.. need to buy one =/
And also.. if anyone else is intrested in buying a wildcard or any backup unit, heres the adress where to get one:
http://www.robwebb.clara.co.uk/shop/copiers/copiers.htm

I gonna put up some pics on my wildcard when my stupid digital cameras battery is recharged.


sorry for misspellings

>So you don't think that the mssdemo code would work on a real snes? =(

I'm pretty sure I know what the problem is, but since I never tried to fix it, I can't be positive.
The way the KeyOn/KeyOff sound registers are described in the docs is misleading. I believe he misinterpretted them as I originally did (and basically everyone did I think, since the emulators had it wrong as well). It wasn't until I tried writing a music player that I ran across the difficulties. I shared the info with the emu authors and it's been fixed for some time now (I believe).

It's really weird that a mistake in the emulators will not really affect a lot of games, but will drastically affect hombrew code. One common example (besides the one above), is that emulators used to (I believe some still do) allow you to write to the video registers whenever you want. Many coders have made mistakes by writing to a reg whenever was convenient. Unfortunately, on the real SNES, you can only write to it at certain times. Since comercial game writers knew this, all their code wrote to it only at the correct times. As for the homebrew authors, the bug is really hard to track down since it works on the emulators. (Translations that have glitches on the real SNES, but not on the emulator are quite often due to mistakes like this.)

Basically, when starting out coding, don't be surprised if you see lots of cases where: the emulators run a feature correctly for games, and will run your code fine (which uses that feature), but on the SNES your code won't work.
Since the games work fine, the emu authors think the feature is implemented correctly. You can't really blame them, but it just goes to show that homebrew authors are approaching the whole thing from a different angle ... and so end up learning a lot that was not noticed before.

The emulators are getting a lot better ... and are useful tools (great for debugging) ... just don't forget their limitations (and if you run across some, and know what feature is implemented wrong, by all means share the info! It's how we are constantly learning new tidbits about the SNES).


> And.. I would be more then happy of all docs you could point out :D

Like I said, many of the docs are outdated now (more errors than they are worth).
I'd start with the docs included in the "SNES starter kit" as they cover pretty much everything. Once you feel fairly comfortable with that, there's a huge pile of info at zophar's .... but it's real hard to find the good stuff amongst all the junk. Hmm... apparently there is no way to get to it from the main page, let me find the link.

Here it is: http://www.zophar.net/SuperNintendoDev/TechnicalInformation.html
Like I said though, most documents there are faulty and some are just blatently worthless (all wrong). But you need to realize good info wasn't always available, so people traded ideas and well as facts. I'd suggest you stick to the starter kit docs until you feel comfortable in trying to make the distinction yourself.

Actually, even then it's not really worth it. If you want to know something that you can't find in the starter kit docs (or are having trouble with) ... just ask around. Much easier (and most likely, more reliable).

Good luck on your projects!

thanks :D
I will start reading them as soon as I have some spare time (like tomorrow)
And you can count on that I will ask questions ;D
And if I would make a revolutianary discovery about the SNES (which I don't think I will...) I promise to post it :)

sorry for misspellings

>The emulators are getting a lot better ... and are useful tools (great for debugging)

Just out of curiosity, what emulator(s) do you conisder to be good for debugging? In my quest for a decent snesdevving emulator, I found the current crop absolutely horrid in terms of debugging capabilities. In one case, I actually had to resort to using Super Pasofami (!!!) to do what I needed.

>Just out of curiosity, what emulator(s) do you conisder to be good for debugging?

Post got really long (sorry), so here's quick summary:
- ZSNES for step by step debugging (and whenever I can because I prefer ZSNES)
- Snes9x "logger version" - for when step by step isn't feasible
- SPX - starting to look really good

-----------------------------

Really, it depends on what you are doing.
If you are totally clueless as to what is causing the problem... (and it does happen to all of us at one time or another) ... then it's really hard to use the conventional emulators for debugging. I've eventually found most of these errors (with my coding style) to be caused by incorrect variable/system initialization, or stupid little errors in interrupts with kind of the equivalent of "sharing violations". So now when I'm totally lost at least I know what I probably should dig through. It takes time, but everyone eventually learns where their personal "what the #$@%?" errors come from.

But in general, when I refer to "debugging" I usually mean little stuff. It's annoying to transfer every code set over to the SNES while fixing up all the quick little errors after a big code addition or change. That's when the emulation is the most useful, and pretty much any decently compatible emlulator is good for this.

Now when the problem isn't quickly obvious, I usually know what function it is... I just don't understand why. ZSNES is good for this. I just look up the routine address in the symbol output file (you need to request this when you compile with WLA DX), run zsnes in debug mode, and tell it to run until it hits that address ... then I can see on a instruction by instruction level what the registers are doing, and see where my mistakes were.

In some cases, the error occurs only during a specific input sequence or certain scenario during the game ... unfortunately zsnes won't let you do input while debugging, and even if it did, you'd have to be careful to catch the correct frame where the error occurs. For annoying "in game" stuff like this, if possible I try to keep breaking at the routine address until the "error" comes around. This is really annoying though since if you guess when the error will occur and it takes 1/2 sec of game time longer ... that's about 30 breaks. Really annoying and I usually miss it.

If I fail to find it, or the game input requirements won't allow me to get into debug mode quick enough, I usually use an emulator that can log the emulation step by step to a file. Then search the file for my routine's address. These are definitely a nuisance.

(Sometimes the input is simple ... like pressing A "jump" causes a jitter then a crash. In this case, I go into debug mode, "fake" the input by changing a variable in memory ... then break on the routine where I suspect the problem.)

If I don't know where the error is at all, I usally add something to the program that will display some info on the screen or something (a quick nice way to narrow down where errors occur).


In reality, my answers above were of little help to you. Each person has different coding styles as well as errors they run into ... as well as how they prefer to seek them out.

Anyway, to better answer your question, I usually prefer zsnes because I liked their step by step debugger. Even though old habits die hard, I've been really looking at this new emulator (I'm not sure if I'm supposed to be releasing this info, as I kind of got a prerelease) http://users.tpg.com.au/trauma/spx/

It has fairly nice step by step debugging (I like zsnes's better still at the moment). It has logging to file support which is okay (I always had problems with some of the Snes9x's logger support, but Snes9x's is better if you can get it to work correctly). But what makes it really nice is that you can view almost anything about the SNES's internals. Once he adds the breakpoint and watchpoint features ... Woohoo! It will be really nice to work with.

I know he has newer versions than what is on the website, but we'll have to wait and see. He's still actively involved in SNES projects, so I doubt he set it down... so he may have a lot more done than I know about.

Where'd you find it? And do they have any NTSC ones left?

NTSC vs. PAL on those units is just a jumper inside. :-)

-- jdc

well.. I don't know if he got any left.. but heres the adress:
http://www.robwebb.clara.co.uk/shop/copiers/copiers.htm

sorry for misspellings