Language…
16 users online: CroNo, DanMario24YT, Dennsen86, Hammerer, Inflagrandy, KaptainAhab,  MarioFanGamer, Metal-Yoshi94, mikeeeeee83, Nayfal, NewPointless,  Segment1Zone2, Serena, signature_steve, Sweetdude, TheXander - Guests: 301 - Bots: 415
Users: 64,795 (2,371 active)
Latest user: mathew

SuperFX Patch Released

Originally posted by metalgearhunter
Question, I haven't read through the thread due to time and all, but what does SuperFX do???


Well, I'll sum it up for you (and for everybody who are interested). ^^

This patch makes possible the use of Super FX in the SMW ROM, it changes the engine so it can work the proper way, like using Dummy Vectors and moving things to RAM (like IRQ and NMI) to prevent crashes when Super FX is running (since Super FX CAN'T run at the same time as the SNES CPU) and insert the codes needed so the user can access the Super FX.

A good example is the code I provided in the pack, it isn't an advanced effect but it's something to begin with.

As I've said before, people think that Super FX can process graphical effects only and this isn't truth at all, the chip can process custom code too, so it's a very powerful CPU when used correctly.

@zack30 - I think that's better to lose the fading effects, since you can use more colors for your OW GFX, although it is optional.

Also, try changing this address "x26D42" from D0 to 80 and see if it's okay.
Could you, please, link here some kind of SuperFX instruction set?
I'd like to use this chip, but for now, I can't do much except inserting your example code which does nothing visually.
Oakley Dokey!

I must tell ya this instruction list is from the SNES Dev Book 2 (since this book have details for the Super FX chip like Instructions and Opcodes).

I'll soon rewrite the instruction set and send it to the documents section (if applicable).
Also culd you explain how rotation/scaling works?
Originally posted by zack30
I Always though it was slowdown when it seemed to go faster at ZSNES's highest speed,
Well of course things will go faster when you increase the speed. >.>

It's also possible that the game deliberately creates "slowdown" (busy loops) to run the effect at the desired speed. A lot of games do this, and it's a perfectly valid technique when used on a console. (When used on a PC, on the other hand, it means 5 years from now your game will be unplayably fast on more powerful CPUs. <.<)

Another thing that can happen is that intense graphical effects or other hard-to-emulate things make the emulator itself slow down, rather than the game lagging due to CPU overburden.

Quote
But why use other emulators? SNES9x seems to be decent at both accuracy and speed (Sorta),
BSNES is too concerned about accuracy, and is the slowest emulator,
Randomly going below 60FPS on my computer. The only game I play in BSNES is Mario RPG,
BSNES seems like the only emulator to run Mario RPG without the random slowdowns of the other emulators.

Basically just don't use ZSnes because it's horribly inaccurate. Snes9x is good, bsnes is better. The less accurate the emulator, the more likely you run into strange bugs. It's even worse if you're using inaccurate emulators to test your hacks/codes - you might unknowingly be relying on those inaccuracies, making your game unusable on more accurate emulators (as well as real hardware!), including later versions that fix those bugs, meaning people have to dig up a specific old version of a specific emulator for it.

An emulator might look like it's working fine, but really be doing just enough to make games run, while being very sloppy about timings, implementing things completely wrong but without obvious side effects, and allowing things that they shouldn't (writing to VRAM at any time is a popular one), which won't usually break games written for a real console, because they won't attempt to do these things that aren't supposed to be allowed. (but you do get the occasional game that, usually by accident, relies on particular hardware quirks or precise timings, or writes junk into VRAM during rendering, which is harmless only because the console doesn't allow writing during that time.)

N64 emulators are a fantastic example: most games appear to work just fine, with maybe a few minor graphical issues. The actual emulation, however, is hideously imprecise - many emulators don't emulate the GPU and video system at all, but just translate the games' graphic commands into OpenGL commands. That means you can delete a huge number of graphic commands that are required on the real N64, and emulators won't notice any difference - and that in turn means hacks don't even put in those important commands, and don't work on a real N64 (or an accurate emulator) at all. (It also means games that do graphic rendering on the CPU, or render to texture, are often quite broken. This is why you can't see Zelda's crash screen, Mario Kart's jumbotron, etc in many of them.)

If all you're doing is playing hacks, ZSnes is usually good enough, but you'll encounter some bugs every now and then, so it's best to just avoid it.
Renamon is best pony.
I agree with Rena Kunisaki, but although ZSNES is a very inaccurate emulator, it does have some "accuracy" in emulating the Super FX chip but just in case, prefer the SNES9x or BSNES if applicable.

Anyway, a friend of mine gave me a IPS containing some Super FX code examples such Rotation and Scale, although it's just a IPS, hackers can disassembly it to learn the code and thus making a true use of Super FX patch.

FX Test

Enjoy.

Friendly Edit: In Yoshi's House, you must disable Layer 1, 2 and 3 in order to see the Super FX sprite correctly. The IPS is fine but I modified to include the Scaling and Rotation example that is on level 105.
SuperFX. An incredible patch that can be used to make fantastic effects, Yoshi's Island is the best example of it. But it's not so easy to work with and make codes with it, since they don't use simply ASM, is hard. Users here should stop giving all attention to SA-1 (that is good too) and start studying and working on SuperFX. Some hackers may prefer it in the future to make more complex stuff. There's no "Better patch" as many users here say, they were made for different uses.

My question: Do they ignore SuperFX because of laziness?
- 2 MB ROM size limit
- Completely different instruction set
- No Lunar Magic support, to my knowledge
- Could require even more remapping than the SA-1 would

The SuperFX patch is certainly worth considering, but at least for the time being, I'd say that it's awesome, but impractical, especially compared to the SA-1 patch, which would provide a boost to the ROM while being a lot easier to use and allowing ROM sizes up to 8 MB.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Yeap, it is hard to use because of its incompatibilities and the remaps that should be made, but with support it CAN be easier. Think of how nice it would be if people worked on codes and ways to make it compatible and usable.

Note to everybody:
Anyone who's trying to make a competition between SA-1 and SuperFX needs help. Both patches has different uses for different kinds of ROM and styles of game. Please don't think about patch 1 as better than patch 2 or vice-versa. Just think about Patch 1 different of Patch 2.

(Only one person cannot make the SuperFX 100% compatible with everything and code lots of sprites and gimmicks for it.)
Originally posted by imamelia
- 2 MB ROM size limit
- Completely different instruction set
- No Lunar Magic support, to my knowledge
- Could require even more remapping than the SA-1 would


- Although the 2 MB limit is a problem, I don't think that this can be a issue considering the tools that we've available today.
- About the instruction set, I don't even think that this is a issue, for example, I learned Genesis ASM and even though it was a bit hard to me first, I managed to learn it completely and I even working into a Sonic hack. The point is, if you want to do something good, you must learn it first, the hack won't fall from the sky as you would expect, it requires lots of hard work to do it.
- Lunar Magic actually does have a "half-support" the only problem I found is the ExGFX crash which I've explained pages ago.
- No, because you still uses the LoROM, you use the same mapping as before. $008000-$3FFFFF, $70-$71 (for SRAM and Super FX RAM) and $7E-$7F for the SNES RAM.

Originally posted by imamelia
The SuperFX patch is certainly worth considering, but at least for the time being, I'd say that it's awesome, but impractical, especially compared to the SA-1 patch, which would provide a boost to the ROM while being a lot easier to use and allowing ROM sizes up to 8 MB.


I don't think that is impractical, like I said above, if you want to do something good, you must learn it and work hard, the hack won't fall from the sky and besides, considering how SMW Hacking evolved back then, I think that we've enough skill to deal with Super FX.

Originally posted by Arctic Avenger
(Only one person cannot make the SuperFX 100% compatible with everything and code lots of sprites and gimmicks for it.)
Like I said, I'm not saying that it's not worthwhile. I think it's pretty cool that someone even managed to make a working implementation of the SuperFX chip in SMW in the first place. I'm just saying that to me, and probably to a lot of other users, the benefits don't seem worth the drawbacks, even before taking into account the fact our current tools don't support it. That said, if you tried to run the sprite engine through SuperFX or something, I and Vitor Vilela could try making Tessera 2.0 work with it as well.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
Like I said, I'm not saying that it's not worthwhile. I think it's pretty cool that someone even managed to make a working implementation of the SuperFX chip in SMW in the first place. I'm just saying that to me, and probably to a lot of other users, the benefits don't seem worth the drawbacks, even before taking into account the fact our current tools don't support it. That said, if you tried to run the sprite engine through SuperFX or something, I and Vitor Vilela could try making Tessera 2.0 work with it as well.


Well, for you and the "other users" the benefits doesn't worth the drawbacks because no one did even tried to at least do a thing to make this patch or the concept of using the Super FX chip "useful".

What I'm saying is that you guys seems to support SA-1 much more, not that this is a problem but no one else seems to actually TRY to use the patch nor TRY to learn how Super FX ASM and the chip works. The practical use isn't just about graphics, it's about custom codes too (A.k.a ASM).

tl;dr: What I'm saying is that just a SINGLE guy can't make such a big thing, it needs support, if the work is done by a single person, it isn't a surprise that no progress is done. If the support grows and the guys here start to become interested rather than search for drawbacks (A.k.a Learn the ASM and how the chip works and work together to make a better use of this chip), I'm sure that Super FX can be a very useful thing for the community.

By the way, I do appreciate if you could send the ASM of Tessera and see if I can do something. Even though it's better to work as a TEAM rather than myself...
Originally posted by DiscoMan
Well, for you and the "other users" the benefits doesn't worth the drawbacks because no one did even tried to at least do a thing to make this patch or the concept of using the Super FX chip "useful".

No, that's not why. I already stated my reasons. What does the SuperFX have over the SA-1? It has about twice the clock speed and probably some functions specifically related to graphics, and probably some other things that I'm not aware of. I just simply don't feel that the additiona benefits would be worth the cost. Learning a new assembly language I could do (SPC-700 isn't hard to pick up; I imagine SuperFX ASM couldn't be too bad), and I could get used to the remapping just as I could get used to using $6100-$7FFF instead of $0100-$1FFF...it's really the ROM size limitation that's the deal breaker for me. There is simply no way in heck that my hack could fit into a 2 MB ROM. Maybe if I used the MSU-1, used every last bit of freespace in banks 00-0F, carefully planned where everything would go in the ROM, and compressed the crap out of everything (or used MSU-1 for data storage, if I could figure out how), I might be able to get away with it...I'd like to think I'm at least a little more organized and concerned about layout than the average SMW hacker. But, you know, I might not. The SMWCP2 team had trouble even with a ROM twice that size. Even with that aside, though...well, see below.

Originally posted by DiscoMan
What I'm saying is that you guys seems to support SA-1 much more, not that this is a problem but no one else seems to actually TRY to use the patch nor TRY to learn how Super FX ASM and the chip works. The practical use isn't just about graphics, it's about custom codes too (A.k.a ASM).

Well, the SA-1 is easier to use and less limiting, or at least it would appear so, so it's natural that it would have more support. And yes, stuff would run about 8 times faster on the SuperFX chip than it would on just the SNES processor, but it already runs 4 times faster on the SA-1, which is still enough to make a huge difference.

Originally posted by DiscoMan
tl;dr: What I'm saying is that just a SINGLE guy can't make such a big thing, it needs support, if the work is done by a single person, it isn't a surprise that no progress is done. If the support grows and the guys here start to become interested rather than search for drawbacks (A.k.a Learn the ASM and how the chip works and work together to make a better use of this chip), I'm sure that Super FX can be a very useful thing for the community.

Indeed. There's no reason why we have to support one over the other in the first place. Let those who want to use the SA-1 use the SA-1 and those who want to use the SuperFX use the SuperFX. There's no need to argue about which one is better; it's up to the individual whether to use one, the other, or neither.

Originally posted by DiscoMan
By the way, I do appreciate if you could send the ASM of Tessera and see if I can do something. Even though it's better to work as a TEAM rather than myself...

You should get together with Vitor and me on IRC sometime soon (when I have time).


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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by DiscoMan

I'm not a professional on SuperFX, but why is it all glitched? Why this all just for using one sprite? Judging by the state of the entire ROM, I'd say SuperFX is kind of unstable... Sorry if I'm not right, like I said I'm not a professional in it or anything, I'm just wondering.

Also any particular reason that's a japanese ROM? You're not from Japan AFAIK.
It's easily the best thing I've done
So why the empty numb?
zack30 warned me about the ROM glitching, I don't know if the IPS is screwed I'll check that today.

Originally posted by Austin
Also any particular reason that's a japanese ROM? You're not from Japan AFAIK.


Originally posted by DiscoMan
Anyway, a friend of mine gave me a IPS containing some Super FX code examples such Rotation and Scale, although it's just a IPS, hackers can disassembly it to learn the code and thus making a true use of Super FX patch.


You didn't even read, right?

@imamelia: I don't have enough time to enter in IRC, I can only "work" if we use the PM system. Otherwise it'll be very difficult for me to communicate.
Few things.

1) The NMIPatch.asm included with your patch just JMLs straight into ROM, seemingly without moving ROM access to the SNES. If the SuperFX still has ROM access, and NMI hits, the 5A22 will crash.

2) You could avoid putting NMI.bin, IRQ.bin, and SuperFXExecuteCode.bin in .bin files using xkas's "base" feature.

3) I can't seem to find any source code for SuperFXExecuteCode.bin anywhere. Am I not looking hard enough or is it not included?
Originally posted by Extroble
Few things.

1) The NMIPatch.asm included with your patch just JMLs straight into ROM, seemingly without moving ROM access to the SNES. If the SuperFX still has ROM access, and NMI hits, the 5A22 will crash.

2) You could avoid putting NMI.bin, IRQ.bin, and SuperFXExecuteCode.bin in .bin files using xkas's "base" feature.

3) I can't seem to find any source code for SuperFXExecuteCode.bin anywhere. Am I not looking hard enough or is it not included?


Well:

1) I've used a strategy by using the lag RAM or RAM $7E:0010, when SuperFX access the ROM, NMI is "locked off" and when SuperFX stops acessing the ROM, NMI returns to normal. That's why Status Bar blinks.

2) I'll fix those things in the next version, thanks for the remind. ^^

3)
Code
ExecuteSuperFX:
        STY !PBR        ;\set superFX bank
        LDY #$3D        ; |give to superFX ROM and SRAM access
        STY !SCMR       ;/
        STA !R15        ;program counter
        LDA #$0020
        BIT !SFR
        BNE $FB
        LDY #$00
        STY !SCMR       ;/ give back ROM and SRAM access to the SNES
.end    RTS


The defines, you'll find them in the Readme located in the pack.
I have a question.
Don't mind, I didn't test the ips, so...
How did you manage to insert a sprite tilemap and rotate it? The sprite tool makes rom crash, so it seems like you used level ASM or something to upload tiles to OAM, right?
The Super FX doesn't support FastROM and since Sprite Tool always uses FastROM, it'll crash with Super FX. The solution is rebuiling the Sprite Tool. Also I guess the Addmusic will not work too.

The sprites puts the tilemap at SRAM and the Super FX CPU rotates it, then it gets uploaded by NMI. It works much like Dynamic Sprites, expect that is one or two frames only and Super FX rotates before it get uploaded on NMI.

The IPS glitches on Snes9X/BSNES, while in ZSNES it doesn't (much). I know that the IPS is from a Japanese Super FX patch which includes a few sprites that rotates. Since it was made in 2009, I guess this IPS doesn't work with accurate emulators and/or Lunar Magic 1.70+.
GitHub - Twitter - YouTube - SnesLab Discord