Thanks. I know my limit now. Good job I'm preferring good poses and spacing over simply adding millions of frames.
Hello. I am new here and I wish to ask a question. I am making a Sonic 1 hack at the moment and I wish to add different music from Sonic 2, Sonic 3 and Sonic&K to the game via SNASM68K but I am not sure how. I HAVE looked through the posts to see if anyone else has asked this and they have but they are just directed to tweaker's music guide which I have look through and I am just as confused as sin! I wish that there was a simple step by step way of doing this, is there any where there is an idiot's guide to do this please? Thanks
Why is he banned? It does say he looked at Tweaker's guide >_> (If he was banned for that post. Says he has two, one is probably validation and this is his second one?)
Hello again! The bubble ASM code is working correctly , only there is only one problem with it, I have the code below, but when Sonic gets the bubble monitor when the air timer music is on, Sonic does get the oxygen as usual, but the countdown music continues, then the music stops. But when Sonic get's an air bubble, the music behaves as usual.(Note: The monitor now gives a one use oxygen supply not infinite oxygen) Anyway here is my source code for it: Obj2E_ChkGoggles: cmpi.b #8,d0 ; does monitor contain Googles? bne.s Obj2E_ChkEnd ; if not, stop checking for different monitor types move.w #$1E,($FFFFFE14).w ; Add Oxygen to Sonic move.w #$AD,d0 ; move bubble collecting sound to d0 jmp (PlaySound).l ; play collecting bubble sound Obj2E_ChkEnd: rts Any assistance will be much appreciated. Thanks!
You forgot to add a branch to ResumeMusic. Code (ASM): Obj2E_ChkGoggles: cmpi.b #8,d0 ; does monitor contain Googles? bne.s Obj2E_ChkEnd ; if not, stop checking for different monitor types move.w #$1E,($FFFFFE14).w ; Add Oxygen to Sonic bsr.w ResumeMusic ; resumes music, change to jsr ResumeMusic if there's a build error move.w #$AD,d0 ; move bubble collecting sound to d0 jmp (PlaySound).l ; play collecting bubble sound Obj2E_ChkEnd: rts
Thanks SOTI, but the resultant code from build.bat is: SN 68k version 2.53 C:\USERS\ANTHONY HALL\DESKTOP\HACKING PROJECT\HIVEBRAIN\SONIC1.ASM(12672) : Erro r : Branch (40206 bytes) is out of range Assembly completed. 1 error(s) from 47606 lines in 0.18 seconds Lightning's ROM Padder Reported Size: 0 Reported Checksum: 0 Size applied: 7F Checksum Applied: 0 Press any key to continue . . . Thanks
Isn't that a bit far from the root drive? I've always had problems unless I have it in something like C:/sonhack.
Oh I thought that was a piece of code for some reason (Stupid me), but it DOES build now but the music still doesn't change back to normal.
No. Branch out of range means that the bsr to ResumeMusic is too far from that routine. A bsr.w can jump only from -32768 to +32767 bytes from your current position. So he has to change that to jsr, which can jump everywhere.
I wasn't talking about the error, I was just saying it seemed like they had thier disassembly a bit far, I just always had problems when it was on my desktop.
It takes less bytes in the ROM. A JSR uses absolute 32-bit addresses, so 4 bytes other than the ones used by the opcode itself. A bxx.b or bxx.s can jump from -128 to +127, so one byte other than the opcode, and a bxx.w can jump from -32768 to +32767, so two bytes other than the opcode. A long path can give errors, but not in this case. The ROM can't compile because of the branching error, which invalidates the whole file.
It does seem to bother me at all. Anyway I don't know what the problem is. ResumeMusic is: ResumeMusic: ; XREF: Obj64_Wobble; Sonic_Water; Obj0A_ReduceAir cmpi.w #$C,($FFFFFE14).w bhi.s loc_140AC move.w #$86,d0 ; play SBZ music cmpi.w #$103,($FFFFFE10).w ; check if level is 0103 (SBZ3) bne.s loc_140A6 move.w #$8D,d0 ; play FZ music (Yeah I know SBZ music does fit LZ, but when I will change it when I learn how to import some music from Castle of Illusion)
I have already done so. (Yes, I understand your annoyance, ASM hates me and forces me to ask a lot of questions and look )
hello there, I am having a few problems with reversing the timer in Sonic 1 using ASM I really could do with an experianced eye to tell me where I have gone wrong... this is what I got but its just sat at 9.59 Code (ASM): Hud_ChkTime: tst.b ($FFFFFE1E).w ; does the time need updating? beq.s Hud_ChkLives ; if not, branch tst.w ($FFFFF63A).w ; is the game paused? bne.s Hud_ChkLives ; if yes, branch lea ($FFFFFE22).w,a1 cmpi.l #$93B3B,(a1)+ ; is the time 9.59? beq.s TimeOver ; if yes, branch subq.b #1,-(a1) cmpi.b #59,(a1) bcs.s Hud_ChkLives move.b #0,(a1) ;speed subq.b #1,-(a1) ;how long to add by cmpi.b #0,(a1) ;when to change didgit bcs.s loc_1C734 move.b #59,(a1) ;0 subq.b #1,-(a1) cmpi.b #0,(a1) ;9 bcs.s loc_1C734 move.b #9,(a1) any help would be greatly apreciated
Actually, the limits are -32766 to +32769 from the starting address of the instruction. The reason for this is that the offset specified in the branch isn't added to the instruction start address, it's added to the instruction start address + 2. Additionally, branches also take less cycles than absolute jumps, and as noted above, -126 and +129, and -32766 and +32769.
The normal timer routine looks like this, which I've filled in comments for: Code (ASM): Hud_ChkTime: tst.b ($FFFFFE1E).w ; does the time need updating? beq.s Hud_ChkLives ; if not, branch tst.w ($FFFFF63A).w ; is the game paused? bne.s Hud_ChkLives ; if yes, branch lea ($FFFFFE22).w,a1 ; load the time into a1 cmpi.l #$93B3B,(a1)+ ; is the time 9.59? beq.s TimeOver ; if yes, branch addq.b #1,-(a1) ; add 1 to centiseconds cmpi.b #60,(a1) ; is centiseconds < 60? bcs.s Hud_ChkLives ; if yes, branch move.b #0,(a1) ; reset centiseconds to 0 addq.b #1,-(a1) ; add 1 to seconds cmpi.b #60,(a1) ; is seconds < 60? bcs.s loc_1C734 ; if yes, branch move.b #0,(a1) ; reset seconds to 0 addq.b #1,-(a1) ; add 1 to minutes cmpi.b #9,(a1) ; is minutes < 9? bcs.s loc_1C734 ; if yes, branch move.b #9,(a1) ; reset minutes to 9 Here's what I'd change it to: Code (ASM): Hud_ChkTime: tst.b ($FFFFFE1E).w ; does the time need updating? beq.s Hud_ChkLives ; if not, branch tst.w ($FFFFF63A).w ; is the game paused? bne.s Hud_ChkLives ; if yes, branch lea ($FFFFFE22).w,a1 ; load the time into a1 cmpi.l #[color="red"]0[/color],(a1)+ ; is the time [color="red"]0.00[/color]? beq.s TimeOver ; if yes, branch [color="red"]subq[/color].b #1,-(a1) ; [color="red"]subtract[/color] 1 from centiseconds cmpi.b #[color="red"]0[/color],(a1) ; is centiseconds [color="red"]>= 0[/color]? [color="red"]bge[/color].s Hud_ChkLives ; if yes, branch move.b #[color="red"]59[/color],(a1) ; reset centiseconds to [color="red"]59[/color] [color="red"]subq[/color].b #1,-(a1) ; [color="red"]subtract[/color] 1 from seconds cmpi.b #[color="red"]0[/color],(a1) ; is seconds [color="red"]>= 0[/color]? [color="red"]bge[/color].s loc_1C734 ; if yes, branch move.b #[color="red"]59[/color],(a1) ; reset seconds to [color="red"]59[/color] [color="red"]subq[/color].b #1,-(a1) ; [color="red"]subtract[/color] 1 from minutes cmpi.b #[color="red"]0[/color],(a1) ; is minutes [color="red"]>= 0[/color]? [color="red"]bge[/color].s loc_1C734 ; if yes, branch move.b #[color="red"]0[/color],(a1) ; reset minutes to [color="red"]0[/color] If you want you can change "cmpi.b #0" to "tst.b". The reason for your version not working is probably because you were still checking if the numbers were less than, not greater than. There are still a few fixes to make elsewhere to get this to work properly, which I'll leave for you to do. The timer will obviously need to start at something other than 0.00.00. When I tested this, the timer showed 0.00 for a second before updating - there are various ways you could fix that. You'll need to make the timer flash during minute 0 and not minute 9. And finally, the timer appears to give you a "bonus second" when it hits 0, because of the hidden centiseconds digits. If you prefer, you could make Time Over happen at 0.00.59. Hope that helps!