Language…
9 users online: 35TCB77, cletus_deletus, Danik2343, Hammerer, howardadam1126, KoJi,  MarioFanGamer, Oskise, pnaha - Guests: 224 - Bots: 384
Users: 64,795 (2,377 active)
Latest user: mathew

SA-1 Pack - v1.40 released

So, I actually really want to start using this again, but do we still need to use the Manual Custom Block Inserter to insert blocks? I can't seem to find an SA-1 version of GPS anywhere. Does any IRC dweller know if one is in the works? I don't want to port to a new ROM and use the manual inserter just to have an SA-1 GPS release later, forcing me to port again.

After this patch is oficially moderated, I'll give it another shot. I may not be able to use the SA-1's power in my own code, but faster loading is always nice, and it's even better now that it works on real hardware... This means SA-1 hacks can be accepted in the Hacks section, that's great! :3
Probably I'm gonna edit GPS myself and make a full SA-1 version working on next week. I'm tired of people not having a good option to insert blocks though SA-1 too.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
Probably I'm gonna edit GPS myself and make a full SA-1 version working on next week. I'm tired of people not having a good option to insert blocks though SA-1 too.

Cool, that'd be awesome. I'll start my ROM once you're done. No need to rush though, I'm busy af anyway, I won't have time for it for a while.

I also remembered that I once made a tutorial for SA-1. Once you're done with GPS, I'll update it with the new blocks-related info, including the SA-1 Convert Tool's ability to convert blocks. I'll also try to make the manual conversion section a bit clearer and more complete, with info about the multiplication/division registers that need to be converted. I'll also try to do a video tutorial for those who prefer them.

Quick poll: voiced or subbed video tut? Or both?
Originally posted by Vitor Vilela
Probably I'm gonna edit GPS myself and make a full SA-1 version working on next week. I'm tired of people not having a good option to insert blocks though SA-1 too.


Cool, right now I need the following to be converted in order to have my HP bar fully working (yes, I read the comments there and he said "No SA-1 support bane"):

-super status bar
-uberasm
-sram plus

Yellow = currently waiting to be moderated after I have submitted a sa-1 hybrid version.
Give thanks to RPG hacker for working on Asar.
I do have an alternative to SRAM Plus (I posted it here some time ago) I called it BW-RAM Plus. It works like SRAM Plus but it doesn't use DMA to save to BW-RAM.

I guess you can help me to test it. Download: http://bin.smwcentral.net/u/12344/bwram_plus.zip

Example of bwram_tables.asm: http://pastie.org/pastes/10614332/text
Bug report: the game crashes as soon you pick a file. I even tested it with a purely clean asm file and the same thing happened.
Give thanks to RPG hacker for working on Asar.
Not related to the thread, but close

I have an idea (might not work). Why don't people add the special code that checks if the ROM is an SA-1 ROM or not, like the patches, but on blocks as well? You guys know what I'm talking about, right?

Quote
if read1($00FFD5) == $23 ; Check, if the ROM uses SA-1
sa1rom
!SA1Address = #$6000
else
lorom
!SA1Address = #$0000
endif
Probably because no one uses the Manual Block Inserter in a non SA-1 ROM and GPS in a SA-1 one. Though if GPS gets converted to SA-1, this might be a good idea.
I will do that once I add SA-1 support to GPS.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by GreenHammerBro
Bug report: the game crashes as soon you pick a file. I even tested it with a purely clean asm file and the same thing happened.


Try putting something to save in bwram_tables.asm, it will crash if you don't save anything (probably it reads something invalid and crash if you have nothing to save).
Still freezing at a press of a button on loading a file. Here is the code:
Code
bw_ram_table:	
.end
	dl $41C7FC : dw $0004		
bw_ram_defaults:
	db $00,$01,$02,$03


Edit: nevermind, you place the disired ram and the amount of bytes between [bw_ram_table:] and [.end], like this:

Code
bw_ram_table:	
	dl $41C7FC : dw $0004
.end
		
bw_ram_defaults:
	db $00,$01,$02,$03


And it will work.
Give thanks to RPG hacker for working on Asar.
When should we expect the SA-1 GPS to drop by?
Hacks:
These patches should be converted as a lot of people use them, and are pretty helpful too.
Originally posted by Vitor Vilela
I will do that once I add SA-1 support to GPS.


Oh, that makes a lot more sense. I was wondering why my SA-1 ROM was constantly crashing every time I tried to use GPS on it.

It's good to see that you're in the progress of making GPS compatible with SA-1 rather than not knowing at all.

I'm guessing for the meantime, I'll be using BTSD and when GPS finally becomes compatible, I'll just reinsert it. :P
My YouTube Channel
Best SMW Hacks Compilation
I've now reached a point where I really need to know how the sa1rom mapper command in asar works. I'm constantly running into errors about autocleaning a label at the end of a freespace block, which I'm assuming means that all freespace in the original game area is taken up. There's tons of space left in my rom in just the 4MB area alone yet asar refuses to put anything there.

According to asar's manual:

Originally posted by manual.txt
- sa1rom: Implements the SA-1 mapper. To tell which banks are mapped in, use sa1rom 0,1,4,6 (maximum
is 7); the default is 0,1,2,3.


I have no clue what this means. So naturally I just tried messing around with the number combinations and all that ends up happening is either the patches end up beyond the 4MB area (which we also know means they won't function) or that the patches just crash the rom instead. Is this command supposed to tell asar which banks to use for freespace or am I misunderstanding it entirely? Am I using it wrong? If this command does indeed tell asar where to put patches I would really like to understand it instead of manually defining where the patches should go just to avoid that error.
So, about 6/8MB ROMs... Since they require special emulator builds to run, are they allowed in the Hacks section?

It'd be pretty hypocritical if they could, considering that any other emulator-restricting issue brings forth an instant rejection... But I'd be pretty disappointed if that feature were to be useless because of that. Forcing people to switch emulators to play your hack, isn't that what we've been actively trying to avoid with the whole music revolution thingy? Plus, MSU-1 is also an instant rejection.

'Cuz I'm currently initiating my ROM port and I was wondering whether or not I should expand this much. I'll also update my tutorial if you say that these large ROMs are banned.
Originally posted by mario90
I've now reached a point where I really need to know how the sa1rom mapper command in asar works. I'm constantly running into errors about autocleaning a label at the end of a freespace block, which I'm assuming means that all freespace in the original game area is taken up. There's tons of space left in my rom in just the 4MB area alone yet asar refuses to put anything there.

According to asar's manual:

Originally posted by manual.txt
- sa1rom: Implements the SA-1 mapper. To tell which banks are mapped in, use sa1rom 0,1,4,6 (maximum
is 7); the default is 0,1,2,3.


I have no clue what this means. So naturally I just tried messing around with the number combinations and all that ends up happening is either the patches end up beyond the 4MB area (which we also know means they won't function) or that the patches just crash the rom instead. Is this command supposed to tell asar which banks to use for freespace or am I misunderstanding it entirely? Am I using it wrong? If this command does indeed tell asar where to put patches I would really like to understand it instead of manually defining where the patches should go just to avoid that error.


It's an asar bug. I'm with the same issue in Touhou Mario 2 and the only workaround I know so far is temporally removing all custom sprites, making freespace in the banks that does not seem to trigger this bug. Unfortunately I can't do much on this, I tried to fix it several times, together with a few special versions made by Lui37 which fixed another SA-1 related bugs but none of them managed to fix this. Welp.

I hope in the future someone manages to fix it, but it's a shame that our official assembler does not work with a such important mapping for the contemporary SMW Hacking.

Originally posted by absentCrowned
So, about 6/8MB ROMs... Since they require special emulator builds to run, are they allowed in the Hacks section?

It'd be pretty hypocritical if they could, considering that any other emulator-restricting issue brings forth an instant rejection... But I'd be pretty disappointed if that feature were to be useless because of that. Forcing people to switch emulators to play your hack, isn't that what we've been actively trying to avoid with the whole music revolution thingy? Plus, MSU-1 is also an instant rejection.

'Cuz I'm currently initiating my ROM port and I was wondering whether or not I should expand this much. I'll also update my tutorial if you say that these large ROMs are banned.


They should be technically allowed. They work with bsnes and ZSNES (6MB), the only emulator which currently does not work is snes9x 1.53; however it's already fixed in 1.54, which will get released at... some day.

And it works in real hardware.

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

For who is wondering, probably I will get SA-1 GPS working around this week. Now that I have university and stuff my time is been a bit limited but I will see if I can come with this since it's a thing that people were been wanting for ages.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela

It's an asar bug. I'm with the same issue in Touhou Mario 2 and the only workaround I know so far is temporally removing all custom sprites, making freespace in the banks that does not seem to trigger this bug. Unfortunately I can't do much on this, I tried to fix it several times, together with a few special versions made by Lui37 which fixed another SA-1 related bugs but none of them managed to fix this. Welp.

I hope in the future someone manages to fix it, but it's a shame that our official assembler does not work with a such important mapping for the contemporary SMW Hacking.


Wow. Well this sucks. I won't insert patches before the sprites because if I decide to add to any of them I know it'll just give the error anyway which doesn't make it any better. So I guess I'll just have manually define where the space is which is incredibly ironic considering this is supposed to be one of the main draws of asar. Oh well.
Originally posted by Vitor Vilela
Originally posted by absentCrowned
So, about 6/8MB ROMs...

They should be technically allowed. They work with bsnes and ZSNES (6MB), the only emulator which currently does not work is snes9x 1.53; however it's already fixed in 1.54, which will get released at... some day.

And it works in real hardware.

Since 1.54 isn't released yet (and probably never will, from what I've gathered), are we allowed to consider FuSoYa's unofficial build as the most up-to-date one? Otherwise, sticking to the rules would mean rejecting 6/8MB hacks. An old, hypotethical update from dead devs hardly counts as the "up-to-date" version.

Originally posted by Vitor Vilela
For who is wondering, probably I will get SA-1 GPS working around this week. Now that I have university and stuff my time is been a bit limited but I will see if I can come with this since it's a thing that people were been wanting for ages.

No stress, don't do like me, focus on your studies.

EDIT: Need help converting the Minimalistic Status Bar (top version). I tried a bunch of things, but I can't get it to work. Of course, I don't understand either the SA-1 nor the status bar patch, so it's pretty hard for me.

I thought this part of the readme would be useful:

Code
Other enhancement chips may work like a slave, because the
SNES sends a command to the chip, which then sends back the
result. But with SA-1 is different story, since both chips
can have interrupts so there's no slave in this case!

How can this be useful? When you can't access something from SA-1 side,
of course. Using this method, you can make a quick access on something
from SNES side, then come back with the value. Example: SA-1 wants to
read from an APU port, but it can't access it. To make it accessible,
call the the SNES so you can read from the APU port and then send
the value to SA-1. See below:

LDA.B #.SNES				; \ Put the SNES pointer to run
STA $0183				; | in $0183-$0185.
LDA.B #.SNES/256			; |
STA $0184				; | (Remember that $0000-$07FF
LDA.B #.SNES/65536			; |  is same as $3000-$37FF).
STA $0185				; /
LDA #$D0				; \ Invoke/Call SNES
STA $2209				; /
.Wait					; \ Wait for SNES.
LDA $018A				; |
BEQ .Wait				; |
STZ $018A				; /
; Now APU value is at $0100-$0103, because:

.SNES					; SNES code
;PHB					; \ Set Bank (not really required to access RAM)
;PHK					; |
;PLB					; /
LDA $2140				; \ Read $2140-$2143
STA $3100				; | and save in $3100-$3103
LDA $2141				; | (Remember that $0000-$07FF is 
STA $3101				; | NOT same as $3000-$37FF in SNES!)
LDA $2142				; |
STA $3102				; |
LDA $2143				; |
STA $3103				; /
;PLB					; Restore Bank
RTL					; Return.
	
Using said method you can get rid of almost all SA-1
limitations, but remember that the SNES's speed is 2 MHz,
so if you call it too many times, you may waste some time. 

...But I've been blindly trying to comprehend and apply it and I'm having no success so far.

For example, I tried to change this:
Code
PreStatusBar:		;status bar
LDA $6D9B
BNE +
LDA #$00 : STA $2111	;static layer 3
LDA #$00 : STA $2111
LDA #$FF : STA $2112
LDA #$01 : STA $2112
LDA #$04 : STA $212C	;layer 3 on main+sub
STZ $212E
STZ $2130
STZ $2131
STZ $2121
LDA.b #!bgcolor : STA $2122
LDA.b #!bgcolor>>8 : STA $2122
LDA #$09 : STA $2105	;gfx mode 1 + layer 3 priority
JML $0082B0
+
STZ $2111
STZ $2111
STZ $2112
STZ $2112
JML $0082B0


...to this:

Code
PreStatusBar:		;status bar
	LDA.B #PreStatusBarCode			; \ Put the SNES pointer to run
	STA $0183				; | in $0183-$0185.
	LDA.B #PreStatusBarCode/256		; |
	STA $0184				; | (Remember that $0000-$07FF
	LDA.B #PreStatusBarCode/65536		; |  is same as $3000-$37FF).
	STA $0185				; /
	LDA #$D0				; \ Invoke/Call SNES
	STA $2209				; /
	.Wait					; \ Wait for SNES.
	LDA $018A				; |
	BEQ .Wait				; |
	STZ $018A				; /
	JML $0082B0
PreStatusBarCode:
	PHB
	PHK
	PLB
LDA $6D9B
BNE +
LDA #$00 : STA $2111	;static layer 3
LDA #$00 : STA $2111
LDA #$FF : STA $2112
LDA #$01 : STA $2112
LDA #$04 : STA $212C	;layer 3 on main+sub
STZ $212E
STZ $2130
STZ $2131
STZ $2121
LDA.b #!bgcolor : STA $2122
LDA.b #!bgcolor>>8 : STA $2122
LDA #$09 : STA $2105	;gfx mode 1 + layer 3 priority
	PLB
	RTL
;;JML $0082B0
+
STZ $2111
STZ $2111
STZ $2112
STZ $2112
	PLB
	RTL
;;JML $0082B0

...and applied the same kind of shit on every chunk of code that messes with these kind of $2XXX addresses, but the game flat out crashes.

...Yeah, I know you're laughing at my code right now. Continue, it's fine.

I know there's something I'm not getting here and that my code is wrong beyond repair, I simply wanted to show that I'm actually trying. But I can't do it until someone explains how the whole thing works.
http://www.smwcentral.net/?p=section&a=details&id=6700

yo.
requests section has been dead for almost half a decade so anyone cool enough to sa-1 this
much thanks