Basic Questions & Answers thread

I don't like the look of this. Pretty certain there shouldn't be failing hunks - is this for an older -current than the one currently available on Alfred's website?

Spoiler

Code (Text):

1. [thomas@chansey asl-current]? patch --dry-run < ~/Downloads/asl_for_linux.diff
2. checking file a2k.c
3. checking file as.c
4. Hunk #1 succeeded at 77 (offset 9 lines).
5. Hunk #2 succeeded at 717 (offset 33 lines).
6. Hunk #3 FAILED at 1065.
7. Hunk #4 FAILED at 1287.
8. Hunk #5 succeeded at 1777 with fuzz 2 (offset 360 lines).
9. Hunk #6 FAILED at 1578.
10. Hunk #7 succeeded at 2134 (offset 234 lines).
11. Hunk #8 succeeded at 2239 (offset 234 lines).
12. Hunk #9 succeeded at 2423 (offset 234 lines).
13. Hunk #10 succeeded at 2441 (offset 234 lines).
14. Hunk #11 succeeded at 2465 (offset 234 lines).
15. Hunk #12 succeeded at 2500 (offset 234 lines).
16. Hunk #13 succeeded at 2513 (offset 234 lines).
17. Hunk #14 succeeded at 3093 (offset 234 lines).
18. Hunk #15 succeeded at 3492 (offset 234 lines).
19. Hunk #16 succeeded at 3503 (offset 234 lines).
20. Hunk #17 succeeded at 3843 (offset 235 lines).
21. Hunk #18 succeeded at 3853 (offset 235 lines).
22. Hunk #19 succeeded at 3861 (offset 235 lines).
23. Hunk #20 succeeded at 3896 (offset 235 lines).
24. 3 out of 20 hunks FAILED
25. checking file asmallg.c
26. checking file asmif.c
27. checking file asmpars.c
28. Hunk #1 succeeded at 43 with fuzz 2 (offset 3 lines).
29. Hunk #2 succeeded at 499 (offset 3 lines).
30. Hunk #3 succeeded at 520 (offset 3 lines).
31. Hunk #4 succeeded at 584 (offset 3 lines).
32. Hunk #5 succeeded at 1899 (offset 3 lines).
33. Hunk #6 succeeded at 4166 (offset 3 lines).
34. Hunk #7 succeeded at 4193 (offset 3 lines).
35. Hunk #8 succeeded at 4211 (offset 3 lines).
36. Hunk #9 succeeded at 4448 (offset 3 lines).
37. checking file asmsub.c
38. Hunk #1 succeeded at 42 (offset 3 lines).
39. Hunk #2 succeeded at 914 (offset 3 lines).
40. Hunk #3 succeeded at 1323 (offset 3 lines).
41. Hunk #4 succeeded at 1733 (offset 3 lines).
42. checking file bpemu.c
43. checking file changelog
44. checking file code166.c
45. checking file code17c4x.c
46. checking file code2650.c
47. Hunk #1 succeeded at 535 (offset 10 lines).
48. checking file code3203x.c
49. checking file code3206x.c
50. checking file code3254x.c
51. checking file code370.c
52. checking file code47c00.c
53. checking file code48.c
54. checking file code51.c
55. checking file code53c8xx.c
56. checking file code56k.c
57. checking file code601.c
58. checking file code65.c
59. checking file code6805.c
60. Hunk #1 succeeded at 132 (offset 3 lines).
61. Hunk #2 succeeded at 964 (offset 3 lines).
62. checking file code6809.c
63. Hunk #1 succeeded at 20 with fuzz 2 (offset 3 lines).
64. Hunk #2 succeeded at 1133 (offset 21 lines).
65. Hunk #3 succeeded at 1165 (offset 21 lines).
66. checking file code6812.c
67. checking file code68.c
68. checking file code68k.c
69. Hunk #1 succeeded at 43 with fuzz 2 (offset 3 lines).
70. Hunk #2 succeeded at 385 (offset 3 lines).
71. Hunk #3 succeeded at 700 (offset 3 lines).
72. Hunk #4 succeeded at 712 (offset 3 lines).
73. Hunk #5 succeeded at 765 (offset 3 lines).
74. Hunk #6 succeeded at 793 (offset 3 lines).
75. Hunk #7 succeeded at 1066 (offset 3 lines).
76. Hunk #8 succeeded at 1083 (offset 3 lines).
77. Hunk #9 succeeded at 1285 (offset 3 lines).
78. Hunk #10 succeeded at 1476 (offset 3 lines).
79. Hunk #11 succeeded at 2764 (offset 2 lines).
80. Hunk #12 succeeded at 2935 (offset 2 lines).
81. Hunk #13 succeeded at 3327 (offset 2 lines).
82. Hunk #14 succeeded at 3458 (offset 2 lines).
83. Hunk #15 succeeded at 3602 (offset 2 lines).
84. Hunk #16 succeeded at 4440 (offset 2 lines).
85. checking file code68rs08.c
86. Hunk #1 succeeded at 106 (offset 3 lines).
87. Hunk #2 succeeded at 824 (offset 3 lines).
88. checking file code7000.c
89. checking file code75k0.c
90. checking file code7700.c
91. checking file code7720.c
92. checking file code77230.c
93. checking file code78c10.c
94. checking file code78k0.c
95. checking file code8008.c
96. Hunk #1 succeeded at 267 (offset 6 lines).
97. Hunk #2 succeeded at 285 (offset 6 lines).
98. Hunk #3 succeeded at 303 (offset 6 lines).
99. checking file code807x.c
100. checking file code85.c
101. checking file code86.c
102. checking file code87c800.c
103. checking file code8x30x.c
104. checking file code90c141.c
105. checking file code960.c
106. checking file code96c141.c
107. checking file code97c241.c
108. checking file codeace.c
109. checking file codecop8.c
110. checking file codeh8_3.c
111. checking file codeh8_5.c
112. checking file codem16.c
113. checking file codem16c.c
114. checking file codescmp.c
115. Hunk #1 succeeded at 16 with fuzz 2 (offset 3 lines).
116. checking file codest7.c
117. checking file codest9.c
118. checking file codexa.c
119. checking file codexgate.c
120. checking file codez80.c
121. checking file codez8.c
122. Hunk #1 succeeded at 25 (offset 3 lines).
123. checking file findhyphen.c
124. checking file Makefile.def
125. checking file Makefile.dep
126. Hunk #1 succeeded at 230 (offset 4 lines).
127. checking file motpseudo.c
128. checking file natpseudo.c
129. checking file nls.c
130. checking file rescomp.c
131. checking file strutil.c
132. Hunk #1 succeeded at 24 with fuzz 2 (offset 9 lines).
133. Hunk #2 succeeded at 193 (offset 9 lines).
134. Hunk #3 succeeded at 650 (offset 49 lines).
135. Hunk #4 FAILED at 610.
136. Hunk #5 succeeded at 685 (offset 52 lines).
137. 1 out of 5 hunks FAILED
138. checking file strutil.h
139. checking file sysdefs.h
140. Hunk #1 succeeded at 1203 (offset 43 lines).
141. checking file tex2doc.c
142. checking file tex2html.c
143. patch unexpectedly ends in middle of line
144. Hunk #26 succeeded at 2625 with fuzz 1.

 

Try

Code (Text):

1. patch -p 1 < ~/Downloads/asl_for_linux.diff

instead.

​

 

The output is identical.

 

As was mentioned over in IRC: my version was for a slightly older version than the newest available. So here is the patch for the newest beta version of AS that can be downloaded from the official web site.

 

Okay everyone, I have a quesion that I thought I knew the answer too,

How can I remove the need for unk_EEC4 in Sonic 2? If I tr to just remove the line, the camera breaks on some levels.

Here is the original code, located in LevelSizeLoad:

Code (Text):

1.     move.l  (a0)+,d0
2.     move.l  d0,(Camera_Min_Y_pos).w
3.     move.l  d0,(unk_EEC4).w ; unused besides this one write...
4.     move.l  d0,(Tails_Min_Y_pos).w

I tried doing something like this, but it didn't really work:

Code (Text):

1.     move.l  (a0)+,d0
2.     move.l  d0,(Camera_Min_Y_pos).w
3.     move.w  (a0)+,d0
4.     move.w  d0,(Camera_Min_Y_pos).w
5.     ;move.l d0,(unk_EEC4).w ; unused besides this one write...
6.     move.l  d0,(Tails_Min_Y_pos).w

Any ideas?

 

unk_EEC4 is a single word; the long write to it also writes a word to Camera_Max_Y_pos, which is the word right below it. What you want is to replace that line by
[68k] move.w d0,(Camera_Max_Y_pos).w[/68k]
which will write the correct value to Camera_Max_Y_pos and allow you to get rid of unk_EEC4.

Edit: added quote due to page break.

 

That worked, thank you very much!

Edit: New question...

How does the charset for Off_TitleCardLetters work?

Mainly what I mean by that is, does it include E,N,O and Z, ore since those are loaded by default, are they excluded from the entire letter-picking process?

 

The charset doesn't do much; in fact, it would encode E, N, O and Z as B. The titleLetters macro is doing the work here. The used variable is initialized such that those letters will not be added to the data, and it is altered for each new letter to avoid adding the same letter twice.

 

Thanks for the help! I understand how it works now.

 

Sorry for the double post, but I have a new question, and figure this would be the best way to bring attention to it:

EDIT: Nevermind the question. I found the art for Bubbler's mother in the Nick Arcade Prototype. Suprising, since there was no mention of it existing there.

The Badnik pages in the Sonic Retro Wiki could stand to be updated to include such data, in whichever ROM's it exists. This is done for the badniks that are actually used in final versions, but unused ones, even that have existing assets, don't have any technical information.

Edit agian: Also, I have a question about Sonic 2.
Why does Sonic 2 use word or short branches to a routine like JmpTo2_SolidObject when going to a distanc subroutine, rather than just jsr SolidObject? Is it somehow faster to branch to a place and jump to another?

 

To answer your last question... IIRC (I don't have the S2 disassembly right in front of me... so this is my memory here...) this is due to needing to jump to a subroutine from a conditional branch.

Normal conditional branches consist of bcc, bcs, bge... etc. There are no such conditional jumps that exist. Sonic 1's disassembly has macro functions that allow this, however I personally advise against using them if you need a jump, because using multiple ones within proximity results in a multiple defined opcode error... or something, even when using different macro jump instructions together.

The way Sonic 2 does this, with the conditional branch leading to the subroutine containing the jump, is more of a proper way to get the same result... I advise anyone hacking the games, Sonic 1 in particular... to do conditional jumps this way... and not through the use of the macros seen in Sonic 1's code.

 

Okay, I understand why conditional branches use these then.
With that said, the things like bra.w JmpTo_Subrountine or bsr.w JumTo_Subroutine, would they be better just being direct jumps rather than a branch to a branch?

 

It depends on your definition of "better". The reason they had several branches leading to a main universal branch, was to save up on memory (at the expense of speed). If however, you are looking for speed, then a direct jump should be used (at the expense of memory).

However, if the routine start address you're jumping to is on the ROM between offset 000000 and 007FFE, then you can perform what is known as a sign-extended jump:

Code (Text):

1.         jmp Location.w

Where the .w reduces the size of the destination to a word size if it's between FFFF8000 - 00007FFF (negative to positive). And that'll take up the same size and same speed as a word branch.

Depending on the assembler of course, a simple:

Code (Text):

1.         jmp Location

May perform the sig-extention for you where available, depending on how well the assembler functions.

You're best bet, if possible, is to move the routine to near the beginning of the ROM as much as possible, and change any "branch to universal branch" instructions (or direct jump instructions) to the sign-extended jump method explained above.

 

That.. Is some very helpful information, thank you!

When you say "saving up on memory", are you referring to RAM or ROM space?


Also, completely unrelated, but to anyone who's familiar with Sonic 2 hacking, I'm having a problem when Chemical Plant Zone's Software scrolling routine:


I have looked over all the code, and it all matches up to the normal Sonic 2, the only exception being that I have cleaned up a LOT of RAM, and some variables have moved because of that. With that said, I know the problem has to do with shifting RAM (I even moved the camera RAM in Sonic 2 normally and got the same result). This tells me that somewhere, something is writing to a static memory address rather than a constant like everything else, but besides that, I don't know anything about where to look or what to change.

 

in reference to THIS

Normally, as Sonic walks along the floor, the floor sensor detecting the higher height value is what determines Sonic's y_position and current angle. Let's say that both of Sonic's floor sensors are detecting tiles of the same height value... Which one takes priority?

I'm looking at Sonic AnglePos.asm in the S1 disassembly, and am not ashamed to admit, I'm slightly stuck on this one.

 

Right, so even though my understanding of ASM is a bit better than it was a few years ago, I've run into a few minor issues with what I've been doing. I'm using the HG disassembly over the 2005 one (which I'm more familiar with, which is probably at least partially responsible for one of these issues)

I've added a Super Peel-Out move to Sonic 1, building it off the Spin-dash code in the SCHG guide.

Functionally, it works how I want it to, but visually, there are a few bugs. I feel kinda dumb 'cause looking at these, I'm sure there's a simple solution for each of these, but they completely elude me

First off - I've got it calling the spin-dash dust charge the same way as the spin-dash itself does (same address and everything). The dust appears fine when spin-dashing, but it doesn't appear when charging the peel-out. As much as I've tried, I can't work this one out. I'm assuming this is something to do with the dust code itself - if I disable the spin-dash subroutine or comment out the code making it load the dust, it still doesn't appear for the peel-out.

Second off, Sonic just walks in place, instead of using the running animation (it does actually point to $2, as opposed to the walk animation). I've looked at the Sonic_Animate routine to see how it works, but I'm a bit lost:

Code (Text):

1.  (from Sonic_Animate)
2.     @running:
3.         add.b   d0,d0
4.         move.b  d0,d3
5.         neg.w   d2
6.         addi.w  #$800,d2
7.         bpl.s   @belowmax
8.         moveq   #0,d2       ; max animation speed
9.         move.w  obInertia(a0),d4    ; get Sonic's speed
10.  
11.     @belowmax:
12.         lsr.w   #8,d2
13.         move.b  d2,obTimeFrame(a0) ; modify frame duration
14.         bsr.w   @loadframe
15.         add.b   d3,obFrame(a0)  ; modify frame number
16.         rts

I'm assuming I need to make Sonic's animation speed faster for this to work. If so, is obTimeFrame the animation speed? How would I go about setting it properly for the peel-out charging animation? I've tried doing what Sonic_Animate does, but it's not doing anything.

Last one, and this is something that I think is due to me being unfamiliar with the HG disassembly - I've added mappings, tiles, PLCs, and all that for the peel-out/figure-8 running animations. There's an entry in Sonic's animation file. Thing is, I can't figure out how to make the game use it - I'd like it to use this at above top speed (or while charging the peel-out) via speed-shoes, for instance, but I can't figure out how to make the walk/run animation routine load it as well. I seem to recall being able to figure this out in the 2005 disassembly.

 

Look at the code for the spin-dash dust object itself, specifically look under loc_1DDCC. The 5th and 6th lines should look like this:

[68k] tst.b $39(a2)
beq.s loc_1DE3E
[/68k]
Comment out or delete both of these. All these do is check to see if Sonic is currently charging a spin-dash, which is pointless since the dust functions properly without having to check for this. With those lines removed, the dust should appear properly for the peel-out if you have the call set up properly.

As for the animations, you'll have to set up new ones for both the charging and when Sonic is running at a specific speed. For the charge, you could use something like this:
[68k]SonAni_PeelOut: dc.b 0, $10, $10, $10, $10, $11, $11, $11, $11, $12, $12, $12, $13, $13, $13, $14
dc.b $14, $D, $D, $E, $E, $F, $F, $10, $11, $12, $13, $14, $D, $E, $2D, $2D
dc.b $2E, $2E, $2F, $2F, $30, $30, $2D, $2D, $2E, $2E, $2F, $30, $2D, $2E, $2F, $30
dc.b $2D, $2E, $2F, $30, $2D, $2E, $2F, $30, $D6, $D7, $D8, $D9, $FE, 4
[/68k]
Obviously you'll have to replace $2D, $2E, $2F, and $30 with the appropriate frame numbers for your peel-out sprites. The running animation is designed to animate faster depending on Sonic's inertia, so using it as a peel-out animation will only result in him walking in place since he isn't moving at all.

Finally, to have Sonic use the peel-out running sprites when he's at a certain speed, go to @nomodspeed: in Sonic Animate.asm and you'll see this:
[68k]@nomodspeed:
lea (SonAni_Run).l,a1 ; use running animation
cmpi.w #$600,d2 ; is Sonic at running speed?
bcc.s @running ; if yes, branch

lea (SonAni_Walk).l,a1 ; use walking animation
move.b d0,d1
lsr.b #1,d1
add.b d1,d0[/68k]
All you need to do is copy the 1st three lines, paste them above, replace SonAni_Run with the name of your peel-out running animation (which should be different from the charging animation above), and replace #$600 with the minimum amount of speed you want Sonic at whenever the animation is displayed.

 

Ah, that works perfectly! Thanks!

 

I've been using the SVN Sonic 1 disassembly, and have only made a few changes to the Special Stage. However, a problem occured. Whenever I collect a chaos emerald or hit a "GOAL" sphere, it takes longer to fade to white than it should. I'm curious as to what caused this.

P.S.: In case it helps, here are the changes I've made:
Faster rotation
No flickering in results screen

EDIT: Never mind, it was the increased speed.

 

So I think I've figured this out, but just to be on the safe side so I don't completely dick myself in the future...

Fixing an "Illegal value" build error for branches is done by increasing the length of the branch (bra.s to bra.w and such). That much, I understand.

For move commands - What I've done is create a subroutine with the commands inside it alongside an rts, then replaced the original line with a branch. Is this acceptable?

For reference, here's what I've done:

Code (Text):

1.     SetScr_WithinBottom:
2.         move.w  d0,(v_screenposy).w ; set vertical screen position
3.         bsr.w   BgScrollSpeed
4.         moveq   #0,d0
5.         move.b  (v_zone).w,d0
6.         lsl.b   #2,d0
7.         bsr.s   LoopTiles_Load
8.         rts
9. ; ===========================================================================
10. ; ---------------------------------------------------------------------------
11. ; Sonic start location array
12. ; ---------------------------------------------------------------------------
13. StartLocArray:  include "_inc\Start Location Array - Levels.asm"
14.  
15. ; ---------------------------------------------------------------------------
16. ; Which 256x256 tiles contain loops or roll-tunnels
17. ; ---------------------------------------------------------------------------
18. LoopTiles_Load:
19.         move.l  LoopTileNums(pc,d0.w),(v_256loop1).w
20.         move.l  LoopTileNums2(pc,d0.w),(v_256loop3).w
21.         rts

Yeah, I know that just copy-pasting the command then modifying it like that is lazy (or at least I assume it is). What I'm wondering is if this is generally "the way" to go about fixing these errors or if there's something much more efficient/stable I can do instead.