Language…
13 users online:  Ahrion, crocodileman94,  Fernap, Foxy_9000_, Gamet2004, hoangng,  MarkAlarm, monkey03297, pnaha, Scags, sinseiga, Sweetdude, Tsquare07 - Guests: 257 - Bots: 268
Users: 64,795 (2,376 active)
Latest user: mathew

SA-1 Pack - v1.40 released

@Ladida: I tried your Top Black status bar patch and all I'm getting is a crashed game.
are you using snes9sux?

for whatever reason it crashes for me in that as well. try it in bsnes or zsnes.
The other 2 emulators don't work in my upgraded PC. Also, you should convert those 3 patches to xkas SA-1 compatible format. As I've teste, most of the asar SA-1 compatible patches just crash in my game.
Actually, dear loli, your top status bar patch looks rather weird.

Originally posted by statusbar.asm
!statusloc = $0EF9 ;do not change

Something tells me that should be $6EF9 instead. The followings should be |$6000'd as well:

Originally posted by statusbar.asm
LDA $0F31
STA !time100
LDA $0F32
STA !time10
LDA $0F33
STA !time1
[...]
LDX $0DC2
[...]
LDX $0DB3
LDA $0F48,x
[...]
LDX $0DB3
[...]
LDA $1422

Also, since those are asar patches, you should use sa1rom instead of lolrom.

Originally posted by Ripperon-X
Also, you should convert those 3 patches to xkas SA-1 compatible format. As I've teste, most of the asar SA-1 compatible patches just crash in my game.

Xkas conversion won't help at all if your rom is crashing, though.
Not true. the asar version of uberASM doesn't work, but the xkas version of it does.
You're probably using something broken where xkas hides the breakage. Probably a missing PHB PHK PLB.
<blm> zsnes users are the flatearthers of emulation
I guess it didn't work, because of this:
freecode/freedata will not work with Asar when you are
accessing the 4MB+ area, atleast until Alcaro adds "sa1rom full"
to Asar (if he hasn't implemented it already).
Now you're switching assemblers and patches faster than I can keep track of. UberASM doesn't mention SA-1, and even if it did, xkas can't use the last four megabytes either.
<blm> zsnes users are the flatearthers of emulation
All I'm hoping for at the moment, is an SA-1 friendly version of Status Bar Editor, and Status Effect as doing it in asm for some of the small status bar tweaking can be somewhat aggravating.
"Reluctance gets you nowhere, if you never ask for help you won't ever receive help. if you never try you may never fail but you'll never succeed either"
--Falkenheart
http://www.smwcentral.net/?p=post&do=reply&t=62550 finishing up my first patch any help is appreciated
I'm hoping for a possible next version to come as fast as possible(if possible).
Sorry, but I'm only able to send SA-1 Pack v1.05 in ~3 days. My computer is on a temporary place which is very harder to work with a tool or ASM code :/

Anyway, the next update fixes IRQ/NMI, fixes Reznor's brigde, works with dynamic sprites, increases the SA-1 clock a bit, removes a lot of unused features, add documentation for parallel mode and more fixes is coming too.

Not liken, but I plan on adding a NMI optimization, which will fix V-Blank overflow when map16 is changed (e.g yoshi coin, 32x32 icy blocks, coins, etc.)

Lunar Fix will be updated too. It fixes more LM ASM hacks, fixes Vertical levels, Layer 2 levels and Vertical Layer 2 levels and fixes a glitch with VRAM Patch and ExGFX revolution patch.

Don't worry, you don't have to port into a new ROM if you're using a older version of SA-1 Pack.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
Anyway, the next update fixes IRQ/NMI, fixes Reznor's brigde, works with dynamic sprites, increases the SA-1 clock a bit, removes a lot of unused features, add documentation for parallel mode and more fixes is coming too.

Nice, though what are these "unused features"?

Originally posted by Vitor Vilela
Not liken, but I plan on adding a NMI optimization, which will fix V-Blank overflow when map16 is changed (e.g yoshi coin, 32x32 icy blocks, coins, etc.)

Wait...V-blank overflows any time Map16 tiles are changed or just when too many of them (maybe more than 4 or so) are changed within a single frame?

Originally posted by Vitor Vilela
Lunar Fix will be updated too. It fixes more LM ASM hacks, fixes Vertical levels, Layer 2 levels and Vertical Layer 2 levels and fixes a glitch with VRAM Patch and ExGFX revolution patch.

We definitely need to convince FuSoYa to add this to Lunar Magic 2.20...

Also, I don't remember if I mentioned it already, but according to byuu, it's essentially impossible to fix the speed bug when you access the same address with both the SNES and SA-1 without having an insanely powerful processor.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
Originally posted by Vitor Vilela
Anyway, the next update fixes IRQ/NMI, fixes Reznor's brigde, works with dynamic sprites, increases the SA-1 clock a bit, removes a lot of unused features, add documentation for parallel mode and more fixes is coming too.

Nice, though what are these "unused features"?


FPS++, which increases the FPS on bsnes, but that wasn't helping much and it brings lot of hacks and wastes lot of RAM and performance.

Also there was "Intercalete" NMI, which makes only Character Conversion DMA or Dynamic Sprites run on NMI, which toggles every frame. But that feature just waste NMI time since the chance of Character Conversion DMA and Dynamic Sprites running at same time it's almost impossible.

Quote
Originally posted by Vitor Vilela
Not liken, but I plan on adding a NMI optimization, which will fix V-Blank overflow when map16 is changed (e.g yoshi coin, 32x32 icy blocks, coins, etc.)

Wait...V-blank overflows any time Map16 tiles are changed or just when too many of them (maybe more than 4 or so) are changed within a single frame?


I haven't tested much, but it seems to generate V-Blank overflow when you change 2+ Map16 tiles combinated with scrolling, ExAnimation or Character Conversion DMA/Dynamic Sprites.

And that's very weird, since 2 tiles is 4 bytes to transfer. So probably the code which handles this is pretty slow.

Quote
Also, I don't remember if I mentioned it already, but according to byuu, it's essentially impossible to fix the speed bug when you access the same address with both the SNES and SA-1 without having an insanely powerful processor.


Yes, I know. On BSNES, SA-1 always run at 10 MHz on ROM when SNES accesses ROM too. I don't worry much since the speed will only be affected on Parallel Mode, not the general core speed.
GitHub - Twitter - YouTube - SnesLab Discord
Well, it's at least good that removing those additional feature will save space. Anyway, will the new version be available by tomorrow?
Hi, I'm using SA-1 for a little project, but I'm kind of lost about the ROM/RAM mapping. In the readme, it says this:

$YY:0000-$YY:00FF to $XX:3000-$XX:30FF.
$YY:0100-$YY:1FFF to $XX:0100-$XX:1FFF.

But I'm pretty sure, by reading the rest, that the second line should be:

$YY:0100-$YY:1FFF to $XX:6100-$XX:7FFF.

Is it right?

As for the other addresses, I probably won't need them at all, seeing its purpose in the RAM Map

As for the ROM mapping, I have no idea what changed. What would $028663 become?
Yeah correct, the $0100-$1FFF area is remapped to $6100-$6FFF. The ROM addresses shouldn't really change anyway, you can keep using what's on the ROM map without worrying too much, just remember that you can't use FastROM addressing with SA-1.
Yeah, it's $0100-$1FFF to $6100-$7FFF. Sorry for my stupidness >:(

Anyway, I think I will be able to release tomorrow version 1.05, but without the NMI optimization.

Once I release this I will start converting some dynamic sprites -- this will be priority since they're the most awesome but slowest sprites.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Lui37
Yeah correct, the $0100-$1FFF area is remapped to $6100-$6FFF. The ROM addresses shouldn't really change anyway, you can keep using what's on the ROM map without worrying too much, just remember that you can't use FastROM addressing with SA-1.


so when it comes to hex editing with SA-1 the ROM addresses anything that starts out with 00:xxxxxx (i.e. 000100FB) would be unaffected but the values therein would need to be changed as those are RAM addresses such as 7E:0F31, would have to change to 7E:6F31 but 100FB would stay the same. if I am not mistaken
"Reluctance gets you nowhere, if you never ask for help you won't ever receive help. if you never try you may never fail but you'll never succeed either"
--Falkenheart
http://www.smwcentral.net/?p=post&do=reply&t=62550 finishing up my first patch any help is appreciated
Just to remember, you can't use bank $7E for that. $00:6F31 is valid in this case or $40:0F31.

Basically $7E:0100-$7E:1FFF is now at $40:0100-$40:1FFF. But the mirror of $40:0100-$40:1FFF isn't at $0100-$1FFF, but in $6100-$7FFF. This is confusing, but you will understand later.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
Yeah, it's $0100-$1FFF to $6100-$7FFF. Sorry for my stupidness >:(

Anyway, I think I will be able to release tomorrow version 1.05, but without the NMI optimization.

Once I release this I will start converting some dynamic sprites -- this will be priority since they're the most awesome but slowest sprites.

No NMI optimization? That's a bummer. Anyway, I think that's it.