Banner
Views: 794,080,366
Time:
22 users online: BootaNoBijuu, Brutapode89, Bryan Blackner, caiqueleo, Flippn'Fences,  FPzero, GbreezeSunset, Infinity, joshua_is_the_new_rick,  KevinM, LucasRCD,  Major Flare, MastaBuizness, Maxodex, MaxtheFox, N450,  poopsey, Ralshi02, Sancles,  Sayuri, StrikeForcer,  Tamaki - Guests: 66 - Bots: 219 Users: 41,441 (1,500 active)
Latest: Ricardo64
Tip: Remember to remove the original SMW events, both layer 2 and layer 1, when making a new overworld.Not logged in.
SA-1 Patch Released (Final version released)
Forum Index - SMW Hacking - Resource & Tool Releases - SA-1 Patch Released (Final version released)
Pages: « 1 2 3 »
Finally finished a version of my SA-1 Patch.

For those unaware: SA-1 is an expansion chip used in some games (like Super Mario RPG) in which a extra CPU is clocked at 10.74 MHz. With it, you can make complex coding and accomplish things that were not possible before with Super Mario World.

Besides the CPU, you can use additional things like HiROM that is mapped in banks $C0-$FF, bitmap functions that allows rotation and things appeared, bit-stream, new dma, etc.

The reason I'm releasing this is simple: To have more utility and support in the future. One day like that, the tools, sprites and other wear SA-1 and let future hackers with new possibilities.

Download
It also includes some examples in levelasm.

To run a code with the SA-1, is really simple:
1. Place the pointer (24-bit) on RAMs $3080-$3082.
2. JSL to FreeRAM.

Limitations:

- Not compatible with ZSNES.
- The third and fourth part of the ROM is mapped in banks $80-$BF, so many tools may be incompatible if they attempt to access this area, but Lunar Magic is compatible with it.

Anyway, that's it. Any question or comment related, post here.
A very interesting patch, I've used it and it's resources are very nice to use, the only problem is that some patches can't work properly like SRAM Expand because SA-1 Patch changes the way SRAM is used.

This can mean that some patches needs to be re-released as SA-1 friendly such as: Pause Menu, SRAM Expand and even VWF Dialogues.

It's very good to use a 10 MHz CPU but it's too bad that SMW Hacking community (neither it's tools or patches) are ready to use the full power of SA-1.
I haven't checked out this thing yet, but it'd be great if you replace levelASM with 1.5 with levelASM 1.4, as 1.5 is still unfinished and very buggy.

--------------------
My blog. I could post stuff now and then
Wha...buh...how...huh...how did you...WHAAAAATT?!! *hyperventilates*

*deep breath*

Wow. This was rather unexpected. Now I'll have to learn some SA-1 programming, I guess. (Maybe figure out how to use it to replace the speed gain of FastROM...) Are you planning to submit this to the patches section?

Also, I have a few questions, mainly about the RAM setup:
1) Is there any reason the flags couldn't all be combined into a single RAM address?
2) I take it we can use $3020-$307F for whatever we want? (Well, that is normally the definition of free RAM, but...)
3) What exactly is $30E0-$30FF used for anyway?
4) How would one have a ROM larger than 4 MB? I assume the SA-1 wouldn't be able to access anything past 4 MB since the four bank defines cover only that much, but...what do the possible values for those defines even correspond to? And would a >4MB ROM even still work in Lunar Magic?
5) From the definitions given, is it true that $3080-$3082 are for running a code with the SA-1 only while $3086-$3088 are for running one with both the SA-1 and SNES simultaneously? Or is it that a code using $3080-$3082 causes an interrupt while one with $3086-$3088 doesn't? Or am I completely misunderstanding them both?
6) Can you use $3080-$3083 to run code that requires an interrupt, such as VRAM uploading?
7) I'm not sure if this is the place to ask, but what does character conversion DMA do? What differentiates it from regular tilemap/character data upload via DMA?

In any case, this looks like an awesome patch, and I hope I'll be able to make use of it. Good work!
Originally posted by imamelia
4) How would one have a ROM larger than 4 MB? I assume the SA-1 wouldn't be able to access anything past 4 MB since the four bank defines cover only that much, but...what do the possible values for those defines even correspond to? And would a >4MB ROM even still work in Lunar Magic?



LM should support up to 8MB SA-1 ROMs (first 2MB at 00:8000-3F:FFFF, next 2MB at 80:8000-BF:FFFF, last 4MB at C0:0000-FF:FFFF). Theoretically, anyway. I added support for that map based on SA-1 docs sometime back in 1.8x I believe, but I didn't actually get around to testing any of it. I didn't even check to see which emulators even supported the SA-1's bank switching.
@Ersanio Although I had corrected the bug of the pause, I have replaced for the current levelasm.

@imamelia I could send it, but i plan to have more support now, also investigate for possible bugs and improve the patch.

1) No reason really, it's possible to combine everything into a single flag.

2) Yes, you can use for anything and also is cleared at reset.

3) It is used as scratch ram in background mode to not have some kind of conflict with the default stracth ram, but if you don't use in background mode, it is safe to use as FreeRAM.

4) Ayosuf explained basically how it works, but actually to access 4MB+, you need to put #$84, #$85, #$86 or #$87 in registers in $2220-$2223. I can not explain very well, but I'll give an example:

Do you want to access the seventh megabyte of ROM banks $A0-$BF, you would write #$06 in $2223. If banks were in $80-$9F, you put #$06 in $2222, #$06 in $2221 for $20-$3F. And so it goes.

5) $3080-$3082 is the normal mode, while $3086-$3088 is in the background. When the SA-1 is working in the background and receives an IRQ, it gives JSL for the pointer in $3080-$3082 and when it ends, back in the background. This background mode is always performed when the SA-1 is idle and runs at same time as the SNES CPU.

6) Although not tested, should work since SA-1 never disables IRQ.

7) Character Conversion DMA is basically one DMA that runs at the same time VRAM DMA, but it converts a raw bitmap (i.e 2BPP/4BPP Packed and 8BPP Linear) for planar format of the SNES. He is quite useful to be able to freely edit graphics like a paint.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
I see.

1) Okay.

2) I see.

3) Oh, that makes sense, having separate scratch RAM areas to prevent conflicts.

4) Well, p4plus2 helped me with this one further on IRC.

5) I don't think that really answered my question, since I'm still confused...

6) Actually, I guess most important things (such as VRAM and ARAM) can't be changed during IRQ anyway.

7) p4plus2 helped me with this one as well. I'll need to learn more about character conversion later, but it does sound rather useful because the linear format is so much easier to work with.

The problem is, it's hard to take advantage of the SA-1's speed bonus. You'd think to just find every routine that runs a lot of times in one frame or requires a lot of processing power and have the SA-1 run it instead, but every routine like that that would use the SNES's registers and RAM, which the SA-1 cannot access. I guess some remapping might work, but that could be very time-consuming. In any case, though, I can see a lot of practical applications of this for things like dynamic sprites. (Rotation and scaling without taking up 2 full ROM banks for graphics? Count me in.)

Oh, also, do you have any idea why only 128 KB of BW-RAM can be used with the patch rather than the full 256?
Yes, some of the problems is really that. Thinking about it, I had created an oam remap to allow access in SA-1:

http://bin.smwcentral.net/u/8251/oam.zip

What changes is simple: Instead of using the address $0200, is now used the address $6200 (BW-RAM). This patch change all addresses for that use, including $0420 ($6420). The only work required is to change the address in the patches and sprites, but that's another story. Besides the patch, it comes with a version of No More Sprite Tile Limits that uses SA-1.

-------------------------------
Also, I have updated the patch. It's a simple fix with Direct Page.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
I forgot all about adding coprocessors to SMW. We had SMW+superfx/sa-1 demos a long time ago but they never caught on for various reasons that aren't really issues anymore. If it does catch on this time, SA-1 is definitely the way to go. There's plenty of documentation, it's easy to use and it's the most flexible.

Some other nice-to-have things might be fast decompression/level building to cut load times. There's also the idea of vblank speedups by getting the sa-1 to generate the fastest possible code each frame by sharing any needed data with it, then just having the SNES jump to the code in RAM within NMI. It would mostly consist of a long stream of immediate loads and stores to DMA registers with direct page used for space/speed benefit. That can help raise the exanimation ceiling a fair bit.
Yeah, NMI often seems too short if you ask me, so it would be nice to run as much of it with the SA-1 as possible. And variable-length bit processing seems like it would be useful for compression. As far as ExAnimation goes, well, I'm still trying to convince FuSoYa to take the ExAnimation data out of bank 7E. (And if we can have 8 MB ROMs now, all the more reason not to use up the space in RAM.) I'd also really like to have a good algorithm for rotating and scaling sprite graphics, which I imagine would be easier with character conversion. What about sprite loading? I know firsthand how time-consuming it is to load sprites from the level data, and it seems like the routine could be sped up substantially even without the SA-1, but with it... All types of object interaction might benefit as well. And actually, smkdan, since you're here, what about your VRAM hacks? Couldn't then be SA-1-ified as well?
I think it's a little hard to do all this, but since ExAnimation is made out of SMW, can be easily converted to the SA-1.

About rotation, this transformation is done for each pixel:

x' = (x * cos(r)) - (y * sin(r))
y' = (x * sin(r)) + (y * cos(r))

SA-1 was doing well on this formula, as you can see in my videos that was good. But the problem would be to actually optimize as they would have to loop through width * height of bitmap.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
Originally posted by Vitor Vilela
About rotation, this transformation is done for each pixel:

x' = (x * cos(r)) - (y * sin(r))
y' = (x * sin(r)) + (y * cos(r))

SA-1 was doing well on this formula, as you can see in my videos that was good. But the problem would be to actually optimize as they would have to loop through width * height of bitmap.


Are you doing all that math for every pixel or has it been optimised arleady? It should be very fast at 10MHz with code that calculates start position once and then just adds deltax/deltay to the source pixel position.

Originally posted by imamelia
what about your VRAM hacks? Couldn't then be SA-1-ified as well?


It would work a lot better if the level data was on cart RAM but there's still plenty of potential speedup. There's a few ideas I have to make it run better if SA-1 ever gets popular. There's also another idea that can be done with just the SNES (but SA-1 assistance would also help) that might appear in later versions if Fusoya agrees to updating it.
@smkdan Yes, I was doing all this transformation, but had managed to optimize a bit. But anyway, thanks for the tip.

--------------------
Also, new update (and possibly the last):

http://bin.smwcentral.net/u/8251/sa1final.zip
http://bin.smwcentral.net/u/8251/sa1.zip

- Now is possible to interrupting the SNES and jump to a certain code specified by the SA-1.
- Reorganized I-RAM and reserved some space for character conversion DMA (I recommend take a look again in I-RAM map).
- Fixed a small bug with IRQ.
- Added example of using the parallel mode and interrupt the SNES. See levelasminit106.
- Also added a library.asm containing the functions of the patch.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
I'm trying to get the parallel mode to work, but I think I'm doing something wrong here.

INIT:
Code
levelinit106:
	LDA.b #SNESPOINTER
	STA $3086
	LDA.b #SNESPOINTER>>8
	STA $3087
	LDA.b #SNESPOINTER>>16
	STA $3088
	
	LDA #$01	;\ Start background mode
	STA $308B	;/

	RTS
	
SNESPOINTER:
	PHB
	PHK
	PLB

	LDA.b #SOMECODE
	STA $3083
	LDA.b #SOMECODE>>8
	STA $3084
	LDA.b #SOMECODE>>16
	STA $3085
	
	LDA #$81	; \ Send IRQ to SNES, Message:01 (jump code)
	STA $2209	; /
	
-	LDA $8A	;\ Wait SNES
	BEQ -	;/
	
	STZ $2209	; Required or your game will crash.
	
	PLB
	RTL		; Exit Parallel/Background Mode
	
SOMECODE:
	PHB
	PHK
	PLB
	LDA #$69
	STA $3000
	PLB
	RTL


MAIN:
Code
level106:
	LDA $3000
	STA $19
	RTS

I enter level 106 and Mario looks orange-ish and glitchy (it's supposed to be that way). I die in the level and re-enter it. Then the game freezes. Am I doing something wrong, or is this a bug in the patch?

I tried it in snes9x 1.53 by the way (and snes9x 1.51 debugger)

e: nevermind, I tried out the code in the library instead (above code was based off the example code in levelinit106), and it worked.


On the topic of SA-1, what does the IRQ and NMI in SA-1 do? I see that you didn't use the SA-1 NMI. Is it because it's useless, or you didn't know what it does?

Also, does the SA-1 IRQ execute whenever a message is sent from the SNES to the SA-1 or something?

--------------------
My blog. I could post stuff now and then
Originally posted by Ersanio
On the topic of SA-1, what does the IRQ and NMI in SA-1 do? I see that you didn't use the SA-1 NMI. Is it because it's useless, or you didn't know what it does?

Also, does the SA-1 IRQ execute whenever a message is sent from the SNES to the SA-1 or something?


SA-1 IRQ is basically the main door of communication and information. When you want the SA-1 to perform a specific code, an IRQ is sent to perform the operation. Also an IRQ is generated when a DMA is finished and H/V counters are fired (yes, SA-1 has a H/V counter). Now SA-1 NMI, I'm not sure what would be your proposal.

Yes, SA-1 IRQ performs a code depending on the message. To send an IRQ with a specific message, you use this code:

LDA #$8X
STA $2200

where x is the message being sent.

Since the patch does not use all messages, you can create some for use. I do not have much idea of ​​using interesting, but may serve to clear the OAM or to enable/disable something specific.

---------------------------
I have some news about supporting ZSNES. After several hours observing ZSNES debugger had a conclusion that the code WaitForHBlank in IRQ behaves very strangely. I tried to take this code and it worked perfectly. But as it is needed in emulators more accurate, I made ​​no change in the patch. As an idea, if it is possible to detect ZSNES and not run WaitForHBlank, SA-1 will work in ZSNES with some limitations, but works.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
Originally posted by Vitor Vilela
if it is possible to detect ZSNES

Yes, it's possible. I can do it in seven lines of code.
SED
LDA #$FF
CLC
ADC #$FF
CLD
CMP #$64
BEQ IsZsnes
Have fun.

--------------------
<blm> zsnes users are the flatearthers of emulation
Really useful, thanks Alcaro!

Now that I can detect ZSNES, I made a new update and this will be the last if no new bug:

http://bin.smwcentral.net/u/8251/sa1.zip

Changes:

- Now is compatible with ZSNES.
- Fixed infinite IRQ bug when SNES is interrupted.
- Fixed library code and example. Apparently I forgot to clean SNES Ready flag and so the code was failing on second interruption.
- Added example of enabling Character Conversion DMA #1 and disabling DMA from SNES.

----------------------------
Well, I think it is. Now with compatibility with ZSNES believe that SA-1 may gain more attention, although it still has some limitations.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
Originally posted by Vitor Vilela
Now SA-1 NMI, I'm not sure what would be your proposal.

I don't really get what you mean by this.

Basically I want to know what the SA-1 NMI does. When does it get run? What are its uses? etc.

I looked it up in the SNES dev manual and NOCASH's SNES documentation but I could not find anything about NMI's practical uses. I don't even know when it gets run.

Does it get run during SNES' NMI? In that case, is it possible to put SNES' NMI in SA-1 so the NMI runs faster?

e: Also that OAM patch of yours, it makes it so that SA-1 can access the OAM right? Sounds pretty cool, actually.

--------------------
My blog. I could post stuff now and then
I think that, SA-1 NMI is not activated at any time by default. But you can invoke it putting #$10 in $2200. If you invoke it in very beginning of NMI, you can do SNES NMI and SA-1 NMI stand running at the same time. Although SA-1 does not do any kind of upload to VRAM, the interesting thing is to SA-1 be an assistant for the SNES during NMI.

And yes, this patch OAM simply remaps it to be accessible by the SA-1. It's basically the same address, except it is +$6000. Since SA-1 can now access, you can combine with a DirectPage, thus leaving sprites graphics routine much faster.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
I want to know, how SA-1 will work with sprites?

It'll be very good if sprite works with SA-1, thus reducing slowdown also optimizing graphics routine plus sprites routine can even reduce slowdown a lot.
Pages: « 1 2 3 »
Forum Index - SMW Hacking - Resource & Tool Releases - SA-1 Patch Released (Final version released)

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2019 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 7

Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • SMBX Community
  • ROMhacking.net
  • MFGG