Odd, I'm sure I've registered here before in re xkas. Ah well.
The .nn releases are betas, and should only be used if you want cutting-edge, untested stuff. I've moved them to a more formal place, you can get them here:
v059.02 is current, and it adds the S-SMP and S-DSP register states to the properties viewer, which should complete that feature. Sprites still aren't actually rendered in the OAM viewer though.
Main advantages over Geiger's:
- VRAM / OAM / CGRAM viewers
- read/write breakpoints on VRAM/OAM/CGRAM/APURAM
- breakpoints by value (eg break when writing #$ff to $7e2000)
- memory analyzer (what addresses are opcodes, read from, written to)
- disassembler that works forward and backward from PC
- runs on OS X and Linux; not just Windows
- and most importantly, it's open source
The last one means you can add your own custom stuff easily.
It also lacks some stuff:
- 'squelching' of trace logs
- step over / proceed debug actions
- most importantly, it's a whole lot faster
I'm sure it has other advantages. I don't really use Windows nor closed source software, though.
As far as speed goes, unless you get like 20fps or less, it shouldn't matter much just for debugging. But for playability, it's understandably a non-starter for many. Hopefully will change when the P4s finally start dieing of old age.
The terminology wildly varies, there are three primary variants.
Step (into): execute next instruction
Step (over): skip the next instruction
Proceed: if the next opcode is a call, execute entire call
It would probably be useful to have one that converts conditional branches to be taken regardless of flags.
Oh byuu, would you like to ride with me? <3
I won't lie, Bahamut Lagoon was the original inspiration for the name and it's a game I continue to hold dear, but the meaning I imply with it is the on-yomi reading for "ayama.ru - to make a mistake"; whereas the name in Bahamut Lagoon is Engrish for "View", as in the main character are your eyes to the game. Many characters in the game have puns for names like this
That said, Sendak is an エロ爺さん (Catholic Priest) >_<
There's dozens of keyboard shortcuts. Go to Settings->Configuration->Input->User Interface. There's a States subsection that lets you do all kinds of neat things.
Decrement and Load State + Save and Increment State, for instance, is a neat way to implement a controllable rewind. And of course there's the standard automatic rewind as well.
Frame skipping is not there for a reason: there are a handful of games and tests that require RTO (sprite overflow) flags to be calculated. If you skip the frame, you can't calculate them, and these games will glitch. My personal feeling is that if someone can't get 60fps without frame-skipping, they'd just use a faster emulator instead.
And given you can now get 60fps on an Atom that sells for $3 per chip ... you should really upgrade if things are still too slow.
But if you have a compelling reason for me to add it, I will consider adding it to the performance core.
The last debugger was in v065. Haven't posted a new one because no features there have changed, and each profile adds another 1MB onto the download size. I may post v068-debugger separately though later on.
Decrement and load is so that it works like a chain. Map Save+Increment to + key, and Decrement+Load to - key. Now press + to make a new point, and you can keep hitting - to rewind. Alternatively, throw in more keys that only load, or only decrement, and you have full control. Was just an example, there's like 15 different hotkeys to do various things with save states
Except for quick states, I don't see any keys for those
Huh? We are only talking about quick states, right? I have keys for all types of quick state actions. Which specific hotkeys would you like to have that are missing? I'm open to adding more
How many savestates can you have, anyway?
Max quick states are ten, I don't go to a hundred because I think that defeats the purpose of QUICK states. Who here can really keep track of 100 different states with no names or descriptions?
Max state manager states are 32. These let you input descriptions and keep them sorted. It acts like a long-term state archive. Eg you could have a list like this:
01. Level 1-1
02. Level 1-2
03. Level 1-3 (boss)
04. Level 2-1
You can have infinite if you modify the source, I just wanted to keep the scrollbar reasonable.
For one thing, it doesn't remove the ROM header. Jeez, that's irritating.
You are directing your disdain in the wrong direction. It is FuSoYa who forces you to keep around ancient 1990's floppy disk based copier headers on your ROMs to use Lunar Magic that is the real problem.
Copier headers are worthless. They make IPS patches fail 50% of the time, less than 1% of people even own these old copiers, and even when they do ... there are over twenty copier header formats, so you have 5-10% odds that your copier can even use the header on a given ROM, and even THEN you still have to split it up for floppy disks anyway.
Wow... i can run this in accuracy mode... I never knew my laptop was a supercomputer cooled by LN2
That was a bit of humor, but it's pretty intense overall, and you'll rarely notice any difference. I definitely recommend testing ROM hacks on it, though.
Translation: Impossible on emulators, and you're not going to get it to work on hardware either unless you're a pro at electronical engineering.
If you really want to cheat, you could use MSU1: 4GB data storage, CD-quality streaming audio, and fullscreen video @ 30fps. It's quite likely real hardware will be available for it, too.
Well, I just think it might be nice to have ones that change the (non-quick) savestate number without saving or loading anything, kind of like the F3 key in ZSNES.
Ah I see, it has those. "Decrement (and Increment) Active Quick State Slot". It doesn't have a menu popup where you can pick which active slot you want, but it does have save and load to specific slot keys.
Hm...wait a minute...what about dumping SPCs?
I'm not a fan of SPC or SNSF file formats, myself. I have a superior idea where you take the SPC and log all $f4-f7 reads. Cut it off of games that don't need it. Now you can even play back the vocal intro to Tales of Phantasia, and it compresses to 20KB.
SPCs have accuracy problems with cycle-based cores, it requires a pretty ugly kludge hack to detect KON writes, and lastly I figure any dumpable SPC has already been dumped through ZSNES alraedy.
If you still want it, kode54 has posted a few builds with SPC dumping support.
How would your MSU thingy allow more powerful echo?
...Using the spc700 for sound effects only?
Yes, you would have almost all of the 64K APURAM for sound effect samples alone. Thus you could have a much larger echo buffer.
There's a backup RAM register assigned to it too (BRAMR), with the description:
"Data becomes 'protected' when the BRAM flag is reset (0) after saving to the Back-up RAM".
Any time I enabled this emulation, various games broke. Some even turned on the write protection and then expected to be able to write to it. Made no sense to me. So no, that feature isn't emulated. Same thing goes for the SA-1 equivalent functionality. It's a shame too because it's a trivial one line of code.
Anyway, I don't recall the SuperFX bus layout entirely. I was under the impression there was only one RAM chip on SFX carts, though.
Both "Open Source" and "Free Software" have been made into religions by Pope Bruce Perens and Saint Richard Stallman.
The terms in English are clear: "open source" = the source is viewable, "free software" = there is no charge for the software.
But thanks to cult status, people are desperately trying to redefine them to mean dozens of different things. I guess they can't make up new, unambiguous definitions.
If you call your project "free software" or "open source", legions of these guys will come after you and call your work proprietary and non-free. I've had some idiots tell me they'd rather source be closed than open but non-commercial. MAME and Snes9X are often called "proprietary" by these dumbasses, for instance.
Anyway, it's all well and good to release the source. But people will fork it whether you give them permission with the license or not. It's the internet, so it's unlikely you can sue some random screen name and actually get damages for it. And even if you could, talk about hassle.
To release source, you have to be okay with the prospect of your work being stolen. In other words, you have to be doing it for others, and not for your own pride and ego. That's a pretty uncommon trait for humanity, so it's no wonder so much code is closed source.
My pet peeve was probably with FuSoYa's SuperFX tracer. He added fopen()+fprintf() to Snes9X, but he never releases source code to anything. Whatever he did caused a bug in Doom that I was experiencing, and running "diff -ru" on his fork would have shown me exactly how to fix a bug, but instead I had to spend two days to track it down myself by hand. All because I guess it was too much to release your fprintf() call to the public :/
But it's the author's right to do whatever they want, so long as it complies with the original license, so what can you do. Because of things like that, I'd have to strongly recommend at least LGPL to any aspiring open source authors.
Yes, the MSU1 programming interface is only eight registers, six of which are simple address values. It would be trivial to add it to any SNES emulator, as all you need to be able to do is output sound and read from a file. It's less than 4KB of code in bsnes.
Unfortunately, the ZSNES and Snes9X devs seem wholly uninterested in any advancements I come up with (UPS, MSU1, XML mapping, serial support, enhanced cheats+database, etc.)
Hopefully awesome hacks such as this will encourage them to add the support. But if not, someone else will have to fork the code to do it.
Lastly, ikari_01's flash cart is coming along, which has native MSU1 audio support. So you could always wait for that and run this on the real thing
I don't think ikari has an official thread anywhere, it's usually just brought up in various semi-related threads. He does have audio working, so SMO can really run on the real thing, but only for one person so far, heh.
That should answer a previous question, but to reiterate: MSU1 does nothing real hardware could not. The SNES has audio mixing pins on the cartridge connector and expansion port. The Super Game Boy used this to play 2MHz (not a typo) audio from Game Boy games, and the BS-X Satellaview used this to stream orchestral music and live commentary into certain games. Even if you go back another generation, the Famicom had this support, and games like Moero Yakyuu Pro! used it to store raw PCM data for vocal sound effects.
The 4GB data is simple as well. Both the S-DD1 and SPC7110 cartridges have memory map controllers to address more ROM in less space. This is even simpler as it's just a streaming read-only port like $2180.
All of this is trivial on a real system, and was only avoided because ROM chips were very expensive back in the 90s. You can call it cheating and hate it if you like, to each their own. I'd rather have simple ASM hacks that offer awesome audiovisual improvements and are still very portable than have people port entire games to a Windows PC.
I'll try and look into MP3 support, but you'll still need to extract the games. Too much RAM required to load in a full archive of MP3s/WAVs. The XML file is needed because I did not want to make up a new header byte to identify the MSU1 chip, that is what tells the emulator to enable the chip.
Lastly, I made the WAVs external precisely so that you could swap out music with your own if you really wanted, no hacking knowledge required
Hadron, the extension is unimportant, the actual format is 100% identical.
.smc stands for Super Magicom, which was one of the earliest SNES copiers. The irony is that 90% of dumps come from SWC DX2s and GDSF7s.
.sfc stands for Super Famicom, which makes a whole heck of a lot more sense.
Unfortunately, the former caught on in the early days because the first dumps were distributed that way through piracy BBSes and such. It continues to exist because the most popular (and lowest quality) SNES organization tool still uses SMC.
I would ask that you guys use SFC, simply run "ren *.smc *.sfc" in your ROM folder, but I can't make people change.
If people wanted good quality music so badly, why not program games in C++ or something?
Please pardon me for ranting, but this really strikes a nerve. If you want better music, there are two options:
One: spend years porting an entire game from the SNES to the PC. Disassemble the entire game, figure out every last algorithm, every last random number generator, every last damage calculator, every last power-up generator, everything. Spend months getting the physics exactly right, spend months essentially cloning the SNES PPU to get effects like the ghost houses exactly right. Spend weeks ripping every last sprite and re-inserting it. And realize that no matter how much work you do, you will never recreate the original gameplay balancing, mechanics and physics 100% perfect.
Once you're done with all of that, now you get to port it to every system ever made. And now you get to spend another several months taking bug reports because JoeSixpack's Turtle Beach Santa Cruz and Hercules ISA graphics card have problems with their drivers. But the users blame you, so you get to work around it. And now you get to rewrite all your video, audio and input code for what the PSP uses, for what your cell phone uses, for what OS X users, for what Linux uses, for what FreeBSD uses, and of course for whatever API Windows uses this week (XAudio3D Pro 11?). And you'll have to keep porting it as new operating systems and hardware comes out, forever and ever.
And two years in when you realize how much work it is and want to stop, you'll have to make up an elaborate lie about how Company X's lawyers threatened to sue you if you don't discontinue the work prior to release.
OR, two: spend ten minutes overriding the game's "play music track #N" command with "is there an MSU1? Play PCM file #n. Otherwise, play music track #N". Ten minutes, and you have the game, 100% correct with all algorithms and levels and physics, etc.
You don't have to do any video/audio/input drivers, or any operating system ports. There are SNES emulators everywhere, and they will get fixed and ported for you. Your hack is every bit as portable as a real SNES game.
Note how I said to play audio above: by falling back on the old SPC code when you don't detect the MSU1, you'll even get full audio everywhere. You just have the option of some special enhancements, if you so choose, by using an MSU1-capable emulator.
Frankly, you're out of your mind if you recommend someone to go with option one.
That said, I totally understand the nostalgia factor of limiting yourself to just the S-SMP. By all means, I'm not asking everyone to use this in their hacks. It's just there if you want it.
the SNES doesn't seem to be capable of supporting that
The SNES, even without special chips, is perfectly capable of it. Take a look at this ROM:
(warning, it is a 64MB download)
That does not use MSU1 at all, it only uses the S-DD1 memory mapper. Listen to that sound quality. Not impressed because of the ROM size?
2.9MB, and this streams a true, CD-quality, 16-bit stereo, no ADPCM compression, song on stock SNES hardware. You can run that right now on your SNES.
The only reason this isn't possible in stock games is because of ROM size costs. So don't say it's about technical limitations, it's about cost limitations. If you don't like MSU1, then your hangup is that it would cost too much to make in the 90s.
if so it would be possible to insert dialogues with voices in a hack, no?
Yes. There is only one stream for MSU1, though. So you would have to do your music on the SMP, and your voice tracks on the MSU1. Or you would have to intermix the audio and voices and time everything.
I wanted to put the audio files into the MSU1 datafile bundle, but that would make it very difficult for non-ROM hackers to swap out songs, and would limit the lengths of songs if the ROM hack packed them together.
And the MSU1 4GB data ROM is separate so that the ROM hacks can still run in other emulators.
This won't ever get adopted by the ZSNES or Snes9X teams, so don't worry about it catching on and replacing all classic SMP music.
Overall, I don't want to convince everyone to use this. I would just prefer to let it be up to the hacker, let that person do whatever they want.
This is obviously something most veteral SMW hackers won't like, but that most end users will. Very similar to the N64 hi-res texture packs.
I never meant porting over the whole game to a modern system, I rather meant not using the game in the first place and rather using a game that is similiar to it and has been on this modern system to begin with.
Ah, I see. But the SNES has wholly unique games. What if you want to experience an enhanced Super Mario World or Chrono Trigger? I don't see any reason to tell someone, "no, you can't do that." just because it's less nostalgic.
The MSU1 shares the Super Game Boy sound mixing code.
It runs a separate coprocessor at exactly 44.1KHz, and mixes one audio file sample with the SNES sound output in real-time.
This allows for save states, fast forwarding, rewinding, and pausing to all work seamlessly. Something a standalone music player couldn't do.
And LuigiBlood, appreciate the support. I know the API and everything keeps changing, but we're getting close. The MMIO registers are 100% finalized, and the next release should have a finalized music format with looping support.
I am actually moving the audio format to a headerless WAV, or in other words a raw PCM file with a loop position value. There's just no universal way to do WAV looping that works everywhere, and all that flexibility in the header would just lead to balkanization between different implementations that implement MSU1 differently. The last thing I want is "use bsnes for this MSU1 patch", and "use FSNES for that MSU1 patch."
My "ultimate idea" is to have a cross-platform tool that takes a configuration file, some music files, and some video files (if you like), and spits out the appropriate MSU1 data.
So you would distribute this tiny utility along with your MP3s and AVIs, and the user would run the "setup.exe" prior to using it. All highly compressed.
The reason to use these lossless formats for the raw data is so that things like the real-life hardware implementation of MSU1, as well as other emulators, can implement MSU1 with a lot less code. You only need ~4KB of code to do it with lossless implementations.
Anyway, the configuration file is what will make the editor really nice. You'll get a nice GUI that has names for each audio track, and it will let you import or export them as you please.
That's the goal. I don't know the first thing about MP3 at the moment, and video playback is going to need some library code, so we'll see how it all goes.
Look, I don't want to convince anyone here to use this. You don't like it? That's cool, I understand.
I added it because I thought it'd be cool to play some of my favorite games with new music. You guys can use it or not. But don't go around telling other people what they can and cannot do, please.
File sizes will probably skyrocket with this new technique if many people adopt it
Most distributions will likely use MP3 and include a setup/conversion utility. Still going to be in the 20MB range. One could use MODs and drop it within the 4MB range.
Unless you made it so that it worked on an actual Genesis + Sega CD system. And the same thing applies to this MSU1 thing.
It does work on the actual SNES:
Data is stored on the SD card slot.
Here is a 1 hour debate me and some other users at #serioushax had about MSU-1 (there's some random stuff in there too but whatever).
Only skimmed it, but all I saw was "fan game fan game fan game". I'm not going to keep repeating myself: it's a lot easier to hack an existing game than make a new one. This arguments works on you guys, too. That's why this site exists in the first place. Was Lunar Magic around in 1990?
Also something about cheating, even though it doesn't modify the SNES in any way. If this is cheating, then Yoshi's Island, Starfox, Kirby's Dreamland 3, Kirby Super Star, DOOM, Super Mario Kart, Super Mario RPG, etc are all cheating as well.
If anything, those "only plays in ZSNES" echo buffer music files are what is really cheating; that's something an SNES could not do regardless of what's inside the cartridge.
If you're going to complain that physical copies of MSU1 weren't officially licensed by Nintendo and sold in the 90s, well neither were any of your hacks or music files. And that ExLoROM 6MB memory map that FuSoYa created certainly wasn't ever made in the US. I guess we're all cheating.
The BS-X Satellaview supported audio streaming as well, we just don't emulate it because nothing played over it was ever recorded. It could also download unlimited amounts of data. If I utilized that protocol, would anyone feel any differently? If you are going to say a file isn't a satellite dish, then a mouse isn't a light gun and a keyboard isn't a gamepad.
There's also a Japanese piano teaching game that uses the second controller port to manipulate a CD player over IR to provide lesson instructions. What if we were to emulate that controller?
It seems many are upset that their hard work making chip-tunes is somehow negated by this. Why would you let the existence of something else diminish your pride in your own work? That's absurd. If what you're meaning is your hacks may become less popular compared to something that sounds better, then you're doing this for the wrong reason. If I worked on bsnes for popularity, I would have killed myself years ago for being such a miserable failure.
not that many people use bSNES
You're definitely right about that.
Well, even if it was the best thing ever, I doubt we will ever get a full hack that uses it.
I already have a finished Der Langrisser hack that has the full orchestral CD inserted. If you're meaning just for SMW, it seems kind of rude to indirectly predict SMO 2.0's failure.
I'm planning making 2 versions of my hack: a version with the "classical" ports, all inserted into the ROM, and one version with the WAV musics.
You can make it one hack, just read out $2002-2007, if you get back "S-MSU1", silence the music and send MSU1 playback commands. Distribute the music files separately via megaupload or rapidshare.
Another fun test case, curious to hear what you guys think.
For about $20, it is possible to buy two cables, splice them together, and connect the second SNES controller port to a PC USB port.
Once this is done, the PC can talk with the SNES, sending and receiving unlimited amounts of data. This data can contain commands for the PC, such as "PC, please play track# N". Now if you have your PC and SNES outputting to the same speakers through mixing, the net effect is the same, although far more garish than MSU1.
This cable not only really exists, multiple people have them working right now, and all you have to do is twist a few wires. No special chips, no SNES hardware abuse, no console mod needed, works right on the real thing, right now.
Is this better or worse than MSU1, and why?
No it isn't. Or are you seriously claiming I could implement a gun system with 9 different guns onto SMW with about 10 minutes of work?
I was under the impression we were talking about adding WAV music to the game.
But yes, there is a threshold. The more you want to do, the easier it is to make a new game. What I am curious about is why adding ten assembly instructions to a game to play WAV music means you're better off making your own game; but spending months in Lunar Magic totally redoing a game is better off as a ROM hack.
Remember, the "cheating" argument works against Lunar Magic, 6MB ROMs, larger echo buffers, etc. I'm asking strictly in the sense of, "what exactly crosses the line for you to warrant porting an entire game instead of hacking it to do what you want?"
For me, that line is difficulty, and MSU1 is not difficult.
Being able to stream 4gb files has to have other uses than making your game sound cooler, but correct me if I'm wrong.
Near-infinite levels, no need for any decompression when you can DMA raw uncompressed graphics and text, and movie playback support. Probably lots of other things you could do, but the serial controller above would have a lot more possibilities.
So awful people can make awful hacks even more ... awful. Is anyone forcing you to play them? When used properly, MSU1 will only make the great hacks even more engaging. Music is a big deal, after all. And when used improperly, everyone can shun and ignore the work.
Or does someone here really think that because MSU1 is here, a really great hack will suddenly be destroyed because it will be packed full of gangster rap music? Even in that extreme case, the good news is it's now even easier to replace the bad music with good music.
Oh yeah, one more thing on file size. Any music format works, you could also distribute 64KB SPCs that turn into WAVs for MSU1. The size doesn't have to be massive for downloading. But it will be big on disk. Then again, 2TB HDDs go for $89 these days, so I'm not too worried about that.