 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in SMW Hacking. |
| User | Post | ||||||||||||||||||||||||||||
| Goldensunboy Posts: 7/287 |
Although I already changed it so all the RTS's are now RTL's and the JMP at the start was removed, thank you for that bit of information, it could really be a help in the future.
I got the first phase of the code working properly, at least the timing (it has to wait FF frames), I haven't checked to make sure Layer 2 is working yet though, since I am focusing on getting my code to run smoothly without crashing. I got the first phase working, but it either does or doesn't freeze sometimes when it gets to phase 2. I am tired and will take a little break from it, as tomorrow I have to go to school early and try to finish my math book, then I am going to a friend's house for a birthday, then I'm out of town for a week. But thank you Hyper, Mikey, Sukasa and Cirvante (and any others I may have missed?) the code is working relatively smoothly, at least compared to not running at all. | ||||||||||||||||||||||||||||
| HyperHacker Posts: 2414/5072 |
You can't return with RTS or RTL from a JMP. You need to use JSR or JSL respectively. To put it simply:
JMP x: Go to x. JSR x/JSL x: Push the address of the next instruction (2 bytes for JSR, 3 for JSL) to the stack and go to x. RTS/RTL: Pop an address from the stack (2 bytes for RTS, 3 for RTL) and go to it. If you use JMP, you haven't pushed any address to the stack, so it just returns to some random place. | ||||||||||||||||||||||||||||
| Goldensunboy Posts: 6/287 |
Edit: I made a crucial mistake at the beginning of the code which would basically cause the code to do nothing by constantly writing $00 to 7EC100 then checking if it's zero. I updated it again.
All INC's, DEC's, LDA's, STA's, and anything that request or modify values above 7E1FFFF use long addressing now. I spent a while and redirected all the branches. I'm about to try the code in the rom, and I'll see what happens. If it crashes, I'll leave details up here. On a side note, I updated my notes, and I turned it into a .bin file. (download) As of now: I'm fixing the RTS's and changing them to RTL's. It seems to return to the wrong place when I have: . . . PALASM's jump to subroutine . . . JMP "MyCode" RTL MyCode . . . I have all my returns as RTS's, so I had it like that. I will change it soon. PS: SmwEdit, I am using the translucent layer 2 level mode. It didn't work, so I left it as it is. I tried many things, but none worked. I don't really want to discuss this much, though, because it's off-topic. smwedit |
Posts: 45/62 Originally posted by Goldensunboy I'm not exactly sure about this solution, but I think there is a level property option: "horizontal translucent layer 2 level" (one that makes layer 2 see-through a little bit) in the change properties in header window that you can use to make the black translucent, unless you are using a vertical level, that is. Goldensunboy |
Posts: 5/287 I changed all the INC's, DEC's, STZ's, etc. to "long mode", and I recalculated all the branches AGAIN, I have to go to bed now but I'm in the middle of checking for errors... I'll work on it tomorrow. The code looks more as if it'll work, I should get that tracer fired up by tomorrow night. | Sukasa |
Posts: 970/2068 Yeah. Oh, and RAM is only accessible by 16-bit addressing up to x1FFF. anythign after that, and you'd be accessing things like hardware and ROM and that. So, anythign over 7E:1FFF has to become long. | Goldensunboy |
Posts: 4/287 As many times as I tried to understand RATS, I think I'm getting a clue... If I wanted to protect, say, 8 bytes, it would be "STAR", little endian -1 would make it 0700 (?), and would the inverse mean "I = FFFF - (data size - 1)"? making the RATS tag "STAR 0700 F8FF"? I am a little confused, and I tried something like this before, but I had no way of knowing if the RATS was correct, and it got overwritten.
| Oh and Sukasa, I never used HDMA. It didn't make sense to me. The background-looking pillars are on layer 1, and the blackness is on Layer 2. I tried to update the CGADSUB with some value that would make the blackness slightly transparent, but it didn't work. As far as fixing the code, I have changed the LDA's and STA's that involve anything past $7E8000 to long, and I recalculated any branches that may have had their distance change because of this. Do the INC's, STZ's, DEC's, etc. that reference anything past $7E8000 have to somehow be changed to long, too? Sukasa |
Posts: 960/2068 INC long is basically
| PHA
And without the stack operations if you don't need them. EDIT: Looking at your first shot... Nice windowing with HDMA. Good effect  Cirvania |
Posts: 492/1181 All you need to know about RATS tags: | Originally posted by LevelASM readme: Appendix Goldensunboy |
Posts: 3/287 Long addressing? I'll try that. I am telling you what I do remember happened when my rom had this problem, recently the code I used disappeared, I think level data covered it. Another problem I have is that I don't understand the whole RATS thing, all I know is that it's RATS, then four bytes for length of data protection, then four more bytes that I don't understand. Plus, I wasn't sure how I put the data protection size in there. Is there some byte ordering issue? like instead of AB CD, is it CD AB? and one last thing, how do the last four bytes work? What do they do? I heard they are the inverse/inverted/something of the four bytes before them, and I was wondering about the byte ordering for them, too.
| As for that assembler, I just downloaded it, and as I only know a few things about ASM (but enough to code my own things manually), it was way over my head. I'll try to figure it out, though. If I can't, I'll just manually change the bytes in my notes to long addressing, and rewrite the code into the rom somewhere that it will (hopefully) not get overwritten until I understand RATS tags. Edit: Oh yes, MikeyK, it crashed early in the routine, I don't remember exactly where, though. I'm rewriting the code into the rom and changing it right now. Edit 2: What about INC? Because I don't see an increment long... mikeyk |
Posts: 27/89 I didn't check out the code before Cirvante's post, but that would be a definite problem. If using a RAM address >= 8000, you definitely need to use long addressing. | Cirvania |
Posts: 491/1181 Use long addressing modes for your loading and storing opcodes.
| Glyph had a problem with this as well, you may find this thread useful. Good luck, and happy hacking!
Oh, and we'd like to know how you made the light field around the chandeliers. Sukasa |
Posts: 959/2068 or just enough to cover one part of the lava tile, the rest could be handled by layers, just like what the moving pipe top sprite does already. Just move part of your sprite, and the other part can be handled by layer one, or three if you use few enough colours. | mikeyk |
Posts: 26/89 i like the creativity, and i will take at your code after i get a nap.
| when you say your code doesn't work, what exactly do you mean? does it crash the rom? does it make it to all the phases, but not act properly at a certain one? is it getting caught a certain phase and not progressing? tracing is your friend there, and any specifics would help someone who didn't write the code themself. this kind of thing would be much easier to debug if you have an idea of where it's breaking, and also if you're willing to share a rom with the code already inserted. for now i strongly recommend that you start working with an assembler (http://www.programmersheaven.com/zone8/cat715/13206.htm), for someone who understands, it should be a breeze to learn and it will make asm hacking a million times easier. not having to update every branch anytime you make a change will take away any reluctance you have to change things. Goldensunboy |
Posts: 2/287 MikeyK's working on a sprite tool? That's awesome, I never knew that since I was away for about 7 months... I don't think that would work, though, because it would have to be a very large sprite, like 10 by 40 8x8 tiles, it's unreal. plus, there has to be Wendy and her two dummies on the same screen, too. Anyway, When I just have it run, it crashes, and I can't quite figure out where, but I can't really run it properly since I think there may be something wrong with the RAM addresses I'm using (7EC100 - 7EC104). They seem to be automatically set to some number (not sure how, but in different levels its all a different number), and changing them didn't work, I tried using STZ on them in a separate code first but it didn't help, I'm just not sure why though.
| Edit: Fixed RAM addresses from 7F to 7E. Sukasa |
Posts: 957/2068  What part of it doesn't work, and where are you storing the GFX for the lava?
Anyways, consider waiting a bit for MikeyK's sprite tool to be released, then make the lava spout a sprite. that would likely work better than PalASM (Which rocks, BTW). Goldensunboy |
Posts: 1/287 Greetings, some of you may recognize me from the board before the restart, I was Dark Ludwig. For those of you who don't know me I know a fair amount of ASM. I have a lot of SMW hacking experience (although I have been pretty quiet about it ever since a few weeks before the board restarted), I have several programs I use to hack SMW, I make my own blocks, yada yada yada...
| Anyway, now for my problem. I am making a long level that has two minibosses and a tough(er?) boss at the end. Miniboss? What? Oh, it's just big boo. 
I also turned Lemmy into some cloud guy thingy that you have to fight. However, I had a novel idea for the last boss, Wendy: Why not have the lava under her active! I worked for several days on a custom code that will cause a nicely animated lava spout to rise up slowly under mario and make a rumbling noise until it can be seen above the lava pool, then shoot up and then recede. I am using PALASM (I haven't really installed LevelASM yet), so the code basically runs once each frame. The code doesn't work, though. I never could understand those assemblers, so I use notepad to make my notes on what OPcodes to make, I translate it manually with 65816REF.hlp, and I write it into the rom with XVI32. It's all manual, so I thought there'd be some problem with it, and there probably was. I used Geiger's SNES9X debugger to disassemble the code, and it turned out to be the same as my notes. I have an idea that there may be some problem with the RAM addresses I'm using, but it might not be that anyway. The code is basically supposed to cause this to happen: Note: the lava pool has layer priority over the lava spout, so it can't be seen when it's behind the lower lava. 
If some experienced ASM hackers could help me here, I would really appreciate it. Edit: Updated my notes. -Goldensunboy PS: If you have trouble viewing the pictures, right click them and click "show picture". If that doesn't work, go to it's properties and copy it's URL into your address bar. If it still doesn't work, IM me at Goldensunboy1. |
