Language…
13 users online: anonimzwx, Dennsen86,  Donut, ForthRightMC, Fozymandias, hhuxy, oliver1, playagmes169, RichardDS90,  Segment1Zone2, steelsburg, tOaO, zAce08xZ - Guests: 291 - Bots: 302
Users: 64,795 (2,375 active)
Latest user: mathew

SA-1 Pack - v1.40 released

I apologize for necro-posting in this thread, but I CANNOT for the life of me get this blasted thing to work. I've tried using several different approaches, including using a ROM that was actually stated to be "clean", but still to no avail.

Why is this patch adamantly REFUSING to work, no matter what ROM I use, and no matter what size I expand it to?

I've tried expanding to 2 MB, 4 MB and 6 MB, using Lunar Magic, Lunar Expander and even Asar itself. Still the sa1.asm patch refuses to work.

What do I have to do in order to force it to work?

(settles in for the inevitable months-long waaaaait for a reply to this post)
The meaning of life is 42 because potato.

I don't feed trolls. I feed THEM to Cthulhu. He finds them DELICIOUS.
There's a specific order in doing it. Did you expand the ROM to 4MB first, then apply the patch with Asar?

Also in this menu #lm{owspr} you need to set the level mode to 10 in every normal sublevel for it to actually work, otherwise it'll act weird.
Thanks for your post. You probably just posted that, too--right when I was independently discovering the method for making it work (which is NOT mentioned in any tutorial or readme)--you have to copypaste the actual FOLDERS containing the remap, boost and more_sprites asm files into the same folder as Asar, the sa1 patch and your ROM of choice.

That link should also help those also having issues with this, as it's not exactly intuitive that you need those other folders along with the sa1.asm file (it's not mentioned in the readme, quick guide or even in the "Beginner's Guide to SA-1" thread).

The thing is, I'm trying to apply the SA-1 patch so I can try that new VLDC9 hack featuring 152 exits. Do I still have to do the level-mode-10 thing to it? And do I apply the level mode edits before or after I apply that patch?
The meaning of life is 42 because potato.

I don't feed trolls. I feed THEM to Cthulhu. He finds them DELICIOUS.
Originally posted by SA-1's quick guide
3. Place asar.exe and your ROM on same folder as you extracted SA-1 Pack.

It says extracted SA-1 Pack, not only sa1.asm file. Extracting everything from a zip file is a good practice and there's a reason that these folders actually exist and have these names.

And no, if all you want to do is playing VLDC9, you only patch the .bps to a completely clean ROM (no SA-1 applied). The .bps already contains the SA-1 Pack inside, you only have to play it in Snes9x or Higan.
Apologies for the confusion you had while setting up the patch. I will slight modify the readme and quick guide to make it more friendly to understand in the next version release.

Oh and by the way, you don't need to expand the ROM before applying the patch. Asar auto-expands to 1 MB.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by Vitor Vilela
Asar auto-expands to 1 MB.


That's news to me. Is it mentioned in its manual or is a completely hidden feature?
I'm sure it's mentioned in the readme? It's the auto-expand feature. If asar don't find freespace, it will automatically expand the ROM to something larger (probably 1 then 2 and last 4 MB, only Alcaro can confirm this).
GitHub - Twitter - YouTube - SnesLab Discord
It does 1, 2 and 4. I don't remember if it does 3, check the source code.
<blm> zsnes users are the flatearthers of emulation
BUG REPORT!!!

Sprite 34 Boss Fireball Have messed up GFX.





And when I put 3 of them, random puff of smokes appear on screen




Have you tested if the same happen in an original, without SA-1, SMW ROM?
GitHub - Twitter - YouTube - SnesLab Discord
In original it works fine.


Sorry to replay to this little old tread but if i use lm 2.52 and asar i get this message on asar label SPR_SPR_INTERACT_SET not found.
My layout has recently been updated, but you still have the old stylesheet cached and things might therefore not look as intended, as such, it’s recommended to reload the page.
As the readme.txt file says, we’re supposed to notify you when the converted patches site link has expired, which it has now. To permanently resolve issues with Dropbox expiring, I would suggest hosting the files in a GitHub Pages project site, this way, the links won’t keep expiring from Dropbox.
Is this still being worked on? I was just reminded of a bug I reported a while ago that apparently still occurs with version 1.26.

This is arguably nothing urgent, since a) it's just a visual bug, b) it's ZSNES-only so it's debatable if it's even worth fixing, and c) you've already put so much work into the whole SA-1 system and probably got a lot more important things to do in real life and I don't want to place another burden on you.

That being said, I'd like to at least bring it to your attention once again. (Maybe it's an easy fix, I don't know.) If you're no longer involved, too busy right now or don't care about this bug in particular, let me know.



So, brief summary: calling $00BEB0 (the Map16 updating routine) glitches parallax scrolling for a split second. It only happens in ZSNES, and it's not caused by any other patch.

Originally posted by WhiteYoshiEgg
Here's how to reproduce it [2018 version]:
  1. Get a clean ROM and expand it to 2MB with LM.
  2. Apply the SA-1 patch (version 1.26).
  3. Get uberASM.
  4. In level_code.asm, copy&paste this code to level105.
  5. Apply uberASM.
  6. Open the ROM in ZSNES and enter level 105.
  7. Do something that calls $00BEB0 (collect a coin, hit a question block, get the midway point).
  8. Notice a brief flicker in the background during that action.
  9. Disable $00BEB0 (PAR 00BEB06B) and verify the problem is gone (though obviously tiles no longer disappear when collected).

Testcase (BPS)


 


 
Feels so good to see a brazilian doing this dude, amazing work.
Hello world!
Thank you Zack! Most importantly, it should be an inspiration for anyone who is interested in producing new things regardless from where you came. I didn't have any ASM nor programming knowledge, for example, when I joined this board but thankfully for my curiosity and motivation everything was made it possible.

As for the others unreplied answers: sorry for my long hiatus, but a new version of the patch is being worked on. If anyone have any known bug, let me know so I can add the TO DO list.
GitHub - Twitter - YouTube - SnesLab Discord
SA-1 Pack is now on GitHub!
There you can view, clone, edit, compare, etc., the code and download any version of the patch. Also you can look how the patch is progressing, ask for features, report bugs, monitor, etc., all cool features that git allows you to.
GitHub - Twitter - YouTube - SnesLab Discord
SA-1 Pack v1.27 Released!
After a long time without updates, it's time for the 1.27 release. This version fixes Snes9x 1.56 crashing the game at startup if no Addmusic is installed, works with Asar 1.60, fixes a major Character Conversion DMA bug and formalizes the GitHub migration.

The plan is to make some more frequent updates but at the same time investigate more calmly unknown and strange misbehavior, such as ZSNES not behaving properly with certain SA-1 -> SNES IRQs. Also eventually add more update and polish better the docs.

As always, you can safely apply this version over the old one. Make sure to run Sprite Tool again as soon as possible because of the more sprites patch.

Feel free to ask for feature requests and bug reports, either here or though Git.
GitHub - Twitter - YouTube - SnesLab Discord
Originally posted by WhiteYoshiEgg
Is this still being worked on? I was just reminded of a bug I reported a while ago that apparently still occurs with version 1.26.

This is arguably nothing urgent, since a) it's just a visual bug, b) it's ZSNES-only so it's debatable if it's even worth fixing, and c) you've already put so much work into the whole SA-1 system and probably got a lot more important things to do in real life and I don't want to place another burden on you.

That being said, I'd like to at least bring it to your attention once again. (Maybe it's an easy fix, I don't know.) If you're no longer involved, too busy right now or don't care about this bug in particular, let me know.



So, brief summary: calling $00BEB0 (the Map16 updating routine) glitches parallax scrolling for a split second. It only happens in ZSNES, and it's not caused by any other patch.

Originally posted by WhiteYoshiEgg
Here's how to reproduce it [2018 version]:
  1. Get a clean ROM and expand it to 2MB with LM.
  2. Apply the SA-1 patch (version 1.26).
  3. Get uberASM.
  4. In level_code.asm, copy&paste this code to level105.
  5. Apply uberASM.
  6. Open the ROM in ZSNES and enter level 105.
  7. Do something that calls $00BEB0 (collect a coin, hit a question block, get the midway point).
  8. Notice a brief flicker in the background during that action.
  9. Disable $00BEB0 (PAR 00BEB06B) and verify the problem is gone (though obviously tiles no longer disappear when collected).

Testcase (BPS)


 


So far this week I have dedicated entirely at figuring out this bug and apparently there is no way to fix it.

As you might know, SA-1 and SNES communicates though IRQs and when the SA-1 CPU needs to do a certain operation such as storing to WRAM ($7E-$7F), communicating to PPU or any other SNES-side thing, the chip needs to send an IRQ request to SNES and then the S-CPU does what the SA-1 asked for. It's the best method for fast communicating with the both CPUs and warrants full code compatibility between them because if there is something that the S-CPU or SA-1 CPU can't do, it gently asks one of them to do the task though IRQs.

IRQs are also used to communicate between the S-CPU and S-PPU. S-PPU, for example, sends an NMI (which is a non-interruptable IRQ) to the SNES at end of each frame. There's also the V-IRQ, H-IRQ and HV-IRQ whcih are IRQs generated when a certain position of the H-/V- counters reach a certain value. The most classic example is the Status Bar IRQ, that the S-CPU receives at around V-Count = 36 and then the S-CPU does mid-scanline writes (yes, exactly) to change the layer 3 x/y positions, current mode, some cgadsub addresses and a little more, depending if it's a mode 7 fight or not.

ZSNES thought it was a good idea to implement all IRQs in the same way. As well H-DMA and H-Blanks. Looking at the ZSNES source code, on the SA-1 part (sa1proc.asm, sa1regs.asm), when the CPU generates an IRQ simply a flag is set and nothing else. What makes the IRQ actually occur is on the file execute.asm and there you can see a huge fuzz x86 mess code which checks for every single possible IRQ and starts generating them depending on the occasion. However, when a certain interrupt request is received, ZSNES just sets it and leaves the routine. So it literally forgets everything else. Because of that, when SA-1 sends an IRQ to the SNES CPU, if it's triggered nearby H-blank, all HDMAs are automatically cancelled because ZSNES just "forgets" to execute them. And on the next scanline the HDMA is executed normally, except that everything will be shifted down by one scanline now.

For the next version of SA-1 Pack I'm currently working, I'm completely rewriting the IRQ and NMI routines. And I have attempted to make my IRQs give absolute priority to the PPU IRQs and only later check for SA-1 IRQs. So the risks of eventual scanline glitching would be avoided, which includes real hardware. Especially when there's HDMA involved.

However, ZSNES simply didn't work with the new IRQ controller. Once an IRQ is called, ZSNES does not clear the IRQ flags correctly and there is no way to know when an IRQ was generated by the PPU. Only by the SA-1. Because of that I had to write a custom IRQ controller just for ZSNES and still with all ZSNES-related-hacks that certainly would break other real hardware, it still keeps with that particular glitching. So sadly, I think I have done the maximum possible and the only way to avoid that is simply removing all SA-1 IRQs from the patch and reallocate some of the routines back to the SNES CPU just for better ZSNES compatibility. I might do that as well for the next version.

But don't get surprised: many games like to flicker on the ZSNES. Yoshi's Island Mode 2 levels are a nice example. VLDC9 overworld also has a lot of flickering on ZSNES, for the same reason (poor IRQ implementation).

And oh uh, quadruple post already? ... maybe people are not turned in the forums as it used to be in the past.
GitHub - Twitter - YouTube - SnesLab Discord