Language…
13 users online: 1337doom, AbuseFreakHacker,  BeeKaay, ben15420, Gorry, Green, LadiesMan217, OrangeBronzeDaisy, playagmes169, Rykon-V73, ShoopDaWhoop, signature_steve,  YouFailMe - Guests: 281 - Bots: 523
Users: 64,795 (2,369 active)
Latest user: mathew

EXTREME FastROM v1.1.0 (dl 1st post)

Alright guys, I've got a reply from FuSoYa telling me he's interested. But in order to test this patch adequately we'll have to run it in BSNES or something.

I'll give it a shot to see if there are any screwups/bugs and timing issues.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Triple posting but it's an important update

I've fixed an issue with yet another misplaced JSL which overwrote the yellow winged koopa jumping routine in a bad way. It resulted in a game crash so yeah. I've fixed that. Roy found out the original location of where the JSL belonged to so I'm thankful to him.

Download version 1.0.3.

edit: I've seen no timing issues and stuff so far though.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
I guess someone should write a little program to scan all of the org locations and check if you get the result you expect before patching. I hope if this gets integrated in LM, LM does this it's self. Also, it would help find mistakes in the patch.

I think a utility that checked the location, checked if it were a JSL or JML and if so set the high bit on the next byte (except for ram of course) but may work better in general, but the reset and pointer stuff would still need to be patched anyway, so eh.

Interestingly the old fastrom patch looked like it deals with pointers by hijacking the pointer calling routine to automatically convert to a fastrom address, which may work better if there are lots of discontinuous tables and exceptions like .stim images seem to have.

Anyway, I don't want to move to a clean rom right now but I probably will when all the kinks of the patch are worked out. I really should make a simple "table extractor" utility to help with moving things like the player tilemaps and sprite's tweaker settings but I still don't have a good simple language compiler/interpreter for command line stuffs outside of simple .bat files. I may use perl since I already am using the VWF tool. But perl is... well... perl.
Your layout has been removed.
Well from what I've understand of his email, FuSoYa is going to find a way to implement the patch so that it can be used on non-clean ROMs.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
I figured he would :P I was just giving my idea as to how.
Your layout has been removed.
Well I applied the patch to what the Clean ROM Verifier (the program) says is a clean ROM and well once I got to Vanilla secret 2:


I'm just going to move around this smal area:

dots!

?

??

???

Does anyone else get this or is it just me, I'm using bsnes if you want to know.
There is no information printed on this signature
Ah, someone who helps me out too :D

I'll get to it right away! How did it trigger the crash? On it's own or did you do something?


Edit: apparently the bob-omb explosion routine screwed up. I'll go fix it. However, I've never had that weird dots issue.
Edit2: I've also realized I'm still missing a few JSLs. I mean, I think I've accidentally completely skipped bank 3 without being aware of it.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
New update! I've fixed the bob-omb explosion glitch.

download v1.1.0

I've also added hundreds of missing JSLs, and about a dozen of missing executeptrlong tables.

WingedYoshi: I wasn't able to reproduce the dots glitch.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
So how did you make this anyway? By looking through all.log?
Your layout has been removed.
Originally posted by -------------readme-------------
This patch is actually an automated process of a tool I've coded.
I've coded an all.log scanner which dumped all the long jumps into a file.
Then I took the file and ran it through a 'patch-transformation' tool I've coded too.
It turned all the offsets and long jumps into this patch.

My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
I see. Sorry I didn't read the readme, I assumed it just had the same info this thread had on how to patch and stuff. :P

So what causes the patch to incorrectly place things? Did you not search for all the addressing modes? I would have been tempted to just replace the bank byte of the address rather then the whole thing but that probably is much harder to read.
Your layout has been removed.
Well it's pretty simple. There are for example labels named "Yoshi:" which contains a JSL. My patch-tool takes the CODE_xxxxxx as the offset and seeing that Yoshi: doesn't have any information regarding it's offset, I have to change that manually.

However, mistakes do happen and I end up with misplaced ORGs sometimes due to wrong "offset-filling".

That's pretty much it.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Why not search for a hex string of xx xx 22? Or something similar.
I own a community of TF2 servers!

ASMT - A new revolutionary ASM system, aka 65c816 ASseMbly Thing
SMWCP - SMW Central Presents a Product- tion long name

frog

http://esolangs.org/wiki/MarioLANG
That's too risky since the script would be including tables.

My method seems to be the safest way unless someone can come up with a impossible-but-genius algorithm to search for JSLs and JMLs and long jump tables.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Silly question time!

I have downloaded version 1.1.0 from the patches section and followed the instructions in the readme.txt, but one of two things will always happen.

1) LM will give me the warning about bad checksum, but then not allow the FastROM addressing option to be used at all.
2) Using a different expansion option, LM will give me the warning and allow me to use the FastROM addressing, but the ROM won't play at all in ZSNES.

My steps were to expand the ROM to 32 Mbit in Lunar Expand, change the free space pointer in the .asm to $128000 and save, apply the patch with Xkas GUI, and then open LM to enable the FastROM addressing. The ROM was verified clean before expansion.

If I'm missing something stupidly obvious, I'm sorry for posting in the Advanced section.
Well what I always prefer is grabbing a clean ROM. Then patch the ROM with freespace set around bank $13. Since that bank doesn't exist in 512kb xkas will just try to expand the ROM in some way. Anyway, after all of this I open the ROM in LM. I get a checksum alert but it doesn't matter you just click OK. Then you go to Option and enable fastrom addressing mode. Then, and only THEN you save the ROM for the first time.

Then everything should work just fine.

edit: if we manage to do test this completely already I can send this to FuSoYa; he knows a workaround to patch this on a non-clean ROM and will implement it in LM.

edit2: I assume that I didn't miss any more JSL. and I guess we can start trying out tools or something on patched ROMs now seeing that I didn't encounter any more crashes.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Originally posted by Ersanio
Well it's pretty simple. There are for example labels named "Yoshi:" which contains a JSL. My patch-tool takes the CODE_xxxxxx as the offset and seeing that Yoshi: doesn't have any information regarding it's offset, I have to change that manually.

However, mistakes do happen and I end up with misplaced ORGs sometimes due to wrong "offset-filling".

That's pretty much it.


Ah yes. I HATE it when all.log does that. It should have given both named labels and CODE_* lables. :P

kinda like:

Yoshi:
CODE_*: ect

Effectively though, you can read the last label and could the bytes, though would be tricky in a program, but not imposable :P Probably not worth it now though.
Your layout has been removed.
Having to use $138000 instead of $128000 is weird. Does that mean the patch must be applied to a space originally outside the ROM?

I just played through almost 100% of SMW, and I haven't seen anything wrong except a disappearing Rip Van Fish in a water level. The game is visibly faster even without the CPU meter. I'll try messing with patches now and report results.
Actually 128000 is outside the ROM too. But I know that Lunar Magic installs ASM hacks around bank 10, 11, and 1F and the rest remains all free. Seeing that it has to be applied to a clean ROM (for now) there should be no problems.

By the way, FuSoYa told me that I don't need to rush things so I'll go test the patch more thoroughly the next 2 weeks or so.

Where did the Rip Van Fish disappear? Which level and which screen? I have to know this. I need to know about any oddities in a patched ROM.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Originally posted by Ersanio
Where did the Rip Van Fish disappear? Which level and which screen? I have to know this. I need to know about any oddities in a patched ROM.


Screen 0C of level 120. There were about five fish on the game screen at the time of the disappearance.

The overworld editor just reminded me that I totally forgot to test the special levels! brb1min

Edit: No problems in the special levels, so that's it. Also, I patched dsx.asm with no problems as well.