Basic Questions & Answers thread

Ah, that makes sense (this also explains why Sonic 1/3K doesn't have them, since they leave their data uncompressed AND only have one collision file).

Decided to experiment around with commenting out one of the "broken" palette indexes and then playing as Knuckles; it crashed without the alignment, but didn't with it, so... ¯\_(ツ)_/¯ (to be fair, the developers were probably never even intending on having this many palettes).

 

What's that looking like?

 

Game freezes to a black screen before the title card appears (although the audio still plays).

 

I meant the section where you put the alignment. Also can we please move this to Basic Q&A? This thread's getting clogged again.

 

Code (Text):

1. ; ===========================================================================
2. ;----------------------------------------------------------------------------
3. ; Palette pointers
4. ; (PALETTE DESCRIPTOR ARRAY)
5. ; This struct array defines the palette to use for each level.
6. ;----------------------------------------------------------------------------
7.  
8. palptr    macro    ptr,lineno
9.     dc.l ptr    ; Pointer to palette
10.     dc.w (Normal_palette+lineno*palette_line_size)&$FFFF    ; Location in ram to load palette into
11.     dc.w bytesToLcnt(ptr_End-ptr)    ; Size of palette in (bytes / 4)
12.     endm
13.         even
14.  
15. PalPointers:
16. PalPtr_SEGA:    palptr Pal_SEGA,  0
17. PalPtr_Title:    palptr Pal_Title, 1
18. PalPtr_BGND:    palptr Pal_BGND,  0
19. PalPtr_EHZ:    palptr Pal_EHZ,   1
20. PalPtr_EHZ2:    palptr Pal_EHZ2,  1
21. PalPtr_OWZ1:    palptr Pal_OWZ1,  1
22. PalPtr_OWZ2:    palptr Pal_OWZ2,  1
23. PalPtr_WZ:    palptr Pal_WZ,    1
24. PalPtr_SSZ1:    palptr Pal_SSZ1,  1
25. PalPtr_SSZ2:    palptr Pal_SSZ2,  1
26. PalPtr_MTZ:    palptr Pal_MTZ,   1
27. PalPtr_MTZ2:    palptr Pal_MTZ,   1
28. PalPtr_WFZ:    palptr Pal_WFZ,   1
29. PalPtr_HTZ:    palptr Pal_HTZ,   1
30. PalPtr_HPZ:    palptr Pal_HPZ,   1
31. PalPtr_RWZ:    palptr Pal_RWZ,   1
32. PalPtr_OOZ:    palptr Pal_OOZ,   1
33. PalPtr_MCZ:    palptr Pal_MCZ,   1
34. PalPtr_CNZ:    palptr Pal_CNZ,   1
35. PalPtr_CPZ:    palptr Pal_CPZ,   1
36. PalPtr_CPZ2:    palptr Pal_CPZ2,   1
37. PalPtr_DEZ:    palptr Pal_DEZ,   1
38. PalPtr_ARZ:    palptr Pal_ARZ,   1
39. PalPtr_ARZ2:    palptr Pal_ARZ2,   1
40.         ;palptr Pal_EHZ,   1    ; for some reason, this specific entry crashes the game...
41. PalPtr_SCZ:    palptr Pal_SCZ,   1
42. PalPtr_OWZ1_U:    palptr Pal_OWZ1_U, 1
43. PalPtr_HPZ_U:    palptr Pal_HPZ_U, 0
44. PalPtr_CPZ_U:    palptr Pal_CPZ_U, 0
45. PalPtr_SS:    palptr Pal_SS,    0
46. PalPtr_ARZ_U:    palptr Pal_ARZ_U, 0
47. PalPtr_ARZ2_U:    palptr Pal_ARZ2_U, 0
48. PalPtr_MCZ_B:    palptr Pal_MCZ_B, 1
49. PalPtr_CNZ_B:    palptr Pal_CNZ_B, 1
50. PalPtr_SS1:    palptr Pal_SS1,   3
51. PalPtr_SS2:    palptr Pal_SS2,   3
52. PalPtr_SS3:    palptr Pal_SS3,   3
53. PalPtr_SS4:    palptr Pal_SS4,   3
54. PalPtr_SS5:    palptr Pal_SS5,   3
55. PalPtr_SS6:    palptr Pal_SS6,   3
56. PalPtr_SS7:    palptr Pal_SS7,   3
57. PalPtr_SS1_2p:    palptr Pal_SS1_2p,3
58. PalPtr_SS2_2p:    palptr Pal_SS2_2p,3
59. PalPtr_SS3_2p:    palptr Pal_SS3_2p,3
60. PalPtr_OOZ_B:    palptr Pal_OOZ_B, 1
61. PalPtr_Result:    palptr Pal_Result,0
62. ;        palptr Pal_EHZ,   1    ; this too!
63. ;        palptr Pal_EHZ,   1    ; this too!
64. ;        palptr Pal_EHZ,   1    ; this too!
65. PalPtr_Knux:    palptr Pal_Knux,  0
66. PalPtr_CPZ_K_U:    palptr Pal_CPZ_K_U, 0
67. PalPtr_ARZ_K_U:    palptr Pal_ARZ_K_U, 0
68. PalPtr_SS_K:    palptr Pal_SS_K, 0
69. PalPtr_HPZ_K_U:    palptr Pal_HPZ_K_U, 0
70.  
71.     align $200
72. ; ----------------------------------------------------------------------------
73. ; This macro defines Pal_ABC and Pal_ABC_End, so palptr can compute the size of
74. ; the palette automatically
75. ; path2 is used for the Sonic and Tails palette, which has 2 palette lines
76. palette macro {INTLABEL},path,path2
77. __LABEL__ label *
78.     BINCLUDE "art/palettes/path"
79.     if "path2"<>""
80.     BINCLUDE "art/palettes/path2"
81.     endif
82. __LABEL___End label *
83.     endm
84.  
85. Pal_SEGA:  palette Sega screen.bin ; SEGA screen palette (Sonic and initial background)
86. Pal_Title: palette Title screen.bin ; Title screen Palette
87. Pal_BGND:  palette SonicAndTails.bin,SonicAndTails2.bin ; "Sonic and Miles" background palette (also usually the primary palette line)
88. Pal_EHZ:   palette EHZ.bin             ; Emerald Hill Zone Act 1 palette
89. Pal_EHZ2:  palette EHZ2.bin            ; Emerald Hill Zone Act 2 palette
90. Pal_OWZ1:  palette OWZ1.bin            ; Ocean Wind Zone Act 1 palette
91. Pal_OWZ1_U:  palette OWZ1 underwater.bin    ; Ocean Wind Zone Act 1 underwater palette
92. Pal_OWZ2:  palette OWZ2.bin            ; Ocean Wind Zone Act 2 palette
93. Pal_WZ:    palette Wood Zone.bin         ; Wood Zone palette
94. Pal_SSZ1:  palette SSZ1.bin             ; Sand Shower Zone Act 1 palette
95. Pal_SSZ2:  palette SSZ2.bin             ; Sand Shower Zone Act 2 palette
96. Pal_MTZ:   palette MTZ.bin             ; Metropolis Zone palette
97. Pal_WFZ:   palette WFZ.bin             ; Wing Fortress Zone palette
98. Pal_HTZ:   palette HTZ.bin             ; Hill Top Zone palette
99. Pal_HPZ:   palette HPZ.bin             ; Hidden Palace Zone palette
100. Pal_HPZ_U: palette HPZ underwater.bin         ; Hidden Palace Zone underwater palette
101. Pal_RWZ:   palette RWZ.bin             ; Rock World Zone palette
102. Pal_OOZ:   palette OOZ.bin             ; Oil Ocean Zone palette
103. Pal_MCZ:   palette MCZ.bin             ; Mystic Cave Zone palette
104. Pal_CNZ:   palette CNZ.bin             ; Casino Night Zone palette
105. Pal_CPZ:   palette CPZ.bin             ; Chemical Plant Zone Act 1 palette
106. Pal_CPZ2:  palette CPZ2.bin             ; Chemical Plant Zone Act 2 palette
107. Pal_CPZ_U: palette CPZ underwater.bin         ; Chemical Plant Zone underwater palette
108. Pal_DEZ:   palette DEZ.bin             ; Death Egg Zone palette
109. Pal_ARZ:   palette ARZ.bin             ; Aquatic Ruin Zone Act 1 palette
110. Pal_ARZ2:  palette ARZ2.bin            ; Aquatic Ruin Zone Act 2 palette
111. Pal_ARZ_U: palette ARZ underwater.bin         ; Aquatic Ruin Zone Act 1 underwater palette
112. Pal_ARZ2_U: palette ARZ2 underwater.bin     ; Aquatic Ruin Zone Act 1 underwater palette
113. Pal_SCZ:   palette SCZ.bin             ; Sky Chase Zone palette
114. Pal_MCZ_B: palette MCZ Boss.bin         ; Mystic Cave Zone boss palette
115. Pal_CNZ_B: palette CNZ Boss.bin         ; Casino Night Zone boss palette
116. Pal_OOZ_B: palette OOZ Boss.bin         ; Oil Ocean Zone boss palette
117. Pal_SS:    palette Special Stage Main.bin ; Special Stage palette
118. Pal_SS1:   palette Special Stage 1.bin ; Special Stage 1 palette
119. Pal_SS2:   palette Special Stage 2.bin ; Special Stage 2 palette
120. Pal_SS3:   palette Special Stage 3.bin ; Special Stage 3 palette
121. Pal_SS4:   palette Special Stage 4.bin ; Special Stage 4 palette
122. Pal_SS5:   palette Special Stage 5.bin ; Special Stage 5 palette
123. Pal_SS6:   palette Special Stage 6.bin ; Special Stage 6 palette
124. Pal_SS7:   palette Special Stage 7.bin ; Special Stage 7 palette
125. Pal_SS1_2p:palette Special Stage 1 2p.bin ; Special Stage 1 2p palette
126. Pal_SS2_2p:palette Special Stage 2 2p.bin ; Special Stage 2 2p palette
127. Pal_SS3_2p:palette Special Stage 3 2p.bin ; Special Stage 3 2p palette
128. Pal_Result:palette Special Stage Results Screen.bin ; Special Stage Results Screen palette
129. Pal_Knux:  palette Knuckles.bin,SonicAndTails2.bin ; "Sonic and Miles" background palette (also usually the primary palette line)
130. Pal_CPZ_K_U: palette CPZ Knux underwater.bin ; Chemical Plant Zone underwater palette
131. Pal_ARZ_K_U: palette ARZ Knux underwater.bin ; Aquatic Ruin Zone underwater palette
132. Pal_SS_K:    palette Special Stage Main (Knuckles).bin ; Special Stage palette (Knuckles)
133. Pal_HPZ_K_U: palette HPZ Knux underwater.bin ; Hidden Palace Zone underwater palette
134.  
135. Pal_SonicMenu:    palette menus/Sonic.bin     ; Sonic theme
136. Pal_TailsMenu:    palette menus/Tails.bin     ; Tails theme
137. Pal_KnuxMenu:    palette menus/Knuckles.bin     ; Knuckles theme
138. Pal_EggmanMenu:    palette menus/PISS DROPLETS.bin ; Eggman theme
139. Pal_RetroMenu:    palette menus/Retro.bin     ; Retro theme
140. Pal_Ending:    palette Ending.bin

Yes, I'll try to move it to Basic Q&A soon.

 

Alright, it's been figured out. It's not an issue with stock Sonic 2 or the disassembly. I would advise you to first post an issue you're hacking when making a hack in Basic Q&A to resolve it before coming in this thread claiming that a potential bug in stock Sonic 2 was found, if you're unsure of what's even going on. This thread is mainly for documenting confirmed bugs and fixing them, and other helpful tweaks.

 

Repeating a previously-asked question:

 

Ive been reading the programmer's user manual for 68000 assembly, and found that there are cases were there are 2 instructions that are represented differently but do the same thing.
For example,

Code (Text):

1. ADD.W #1234,D0

Would be represented as

Code (Text):

1. 1101000001111100 [16 bits immediate data]

However, the notes say that if you are trying to add an immediate to a data register, then the assembler should automatically convert `ADD` to `ADDI` (despite `ADD` seeming to support adding immediates to data registers as well)

But, the bit representation for

Code (Text):

1. ADDI.W #1234,D0

is

Code (Text):

1. 0000011001000000 [16 bits immediate data]

.

So, there seem to be 2 different totally equivalent instructions that both can add immediates to data registers. Is there one that is preferred? Is there any benefit to one over the other that I'm not seeing? This duplication is also seen instructions like `OR` vs `ORI`, among others.

 

The difference between those 2 is that "ADD" requires that one of the operands be a data register. Only 1 address mode can be encoded in the "ADD" opcode, and it uses a bit to determine if the source or destination is the register. If you were to set the direction bit to 1 in your "ADD" example, it'd be interpreted as

Code (Text):

1. ADD.W D0,#1234

Which is obviously very much not valid.

This also means something like

Code (Text):

1. ADD.W #1234,$FF0000

is not possible to assemble.

"ADDI" forces the source operand to be an immediate, which allows the destination to be anything (other than another immediate, of course). "ADDI" would allow you to use the operands from the example above.

"ADDA" also exists if one if the source operand is not an immediate, and the destination operand is an address register.

 

Yes, this distinction makes sense, but I am wondering in the case where I do just want to add an immediate to a data register, which operation should I use? (since both can do this).

Is there any benefit to using one over the other in the case when you want to add an immediate to a register? (assuming `ADDQ` is not applicable -- also, I do follow what you are saying about them being able to do different things, I'm just asking about this particular situation you actually can use either one for the same function).

 

No. "ADDI" exists to get around a limitation of "ADD". Otherwise, they take the same amount of space and same number of cycles to execute.

I personally just stick with "ADDI" for consistency. Some assemblers would just turn an "ADD" into an "ADDI" if the source operand in an immediate, anyways.

 

Hey, so I managed to hit a roadblock when porting the Sonic and Knuckles driver into Sonic 1, everything builds fine however I received this error:

It's telling me to increase the value of something I don't even have in my disassembly (that being AS GitHub Two Eight disassembly) nor the sound driver itself. I tried increasing Size_of_sounddriver and Size_of_sounddriver2 to see if something did change but to no avail.

Is there anything I'm supposed to specifically change from here or do I need to modify s1p2bin itself as the code is telling me to increase something that isn't defined?

 

If I recall, s1p2bin expects the Sonic 1 PCM driver. You might have to use s3p2bin instead.

 

Cheers for that; it works as intended. I might step it up by porting flamewing's SK driver over that.

EDIT: Got flamewing's SK driver installed successfully however I ran into an issue where a few channels would play the last note after resting the note. Here's a YouTube video comparing how it's played between S1's and S3K's drivers:

If you want to take a look at the song file in ASM, please let me know and I'll DM it to you if you know how to fix it.

 

Came up with three new symbolic constants for my Sonic 2 disassembly for code handling bounds checking (MarkObjGone and DeleteObject), but I'm not sure if my line of thinking with them is correct.
Are render_margin, render_width, and render_height correct with regards to how the VDP works internally in H40 mode, or am I off?

Code (Text):

1.  
2. screen_width:       equ 320
3. screen_height:       equ 224
4. render_margin:       equ 128                               ; space beyond edges of screen rendered by the VDP internally
5. screen_top:           equ render_margin                   ; VDP y coordinate of top edge of screen
6. screen_left:       equ render_margin                   ; VDP x coordinate of left edge of screen
7. screen_bottom:       equ screen_top+screen_height
8. screen_right:       equ screen_left+screen_width      
9. render_width:       equ screen_width+(render_margin*2)   ; 640, total width of VDP render
10. render_height:       equ screen_height(render_margin*2)   ; 480, total height of VDP render
11.  

 

The question is still up there in case anyone has missed it. I think it's probably due to how S3K handles note delays comparing to Sonic 1, so I should make a separate flag for that, right?

Also, I'm planning to include up to 60 songs with flamedriver in mind. Will the fit under the Z80 bank or do I need to remove certain aspects to make it possible?l And aso, what's the limit to DAC banks? Is it the same as Sonic 1's or MegaPCM?

Sorry if I'm being such a bother with these questions, but I'd rather ask now than later in case the driver doesn't support what I have and would be painful to revert everything to a 68k driver and make sure all songs work from there. If I know it's limitations now, then I should feel confident working with flamedriver from there on out.

 

Uhh, so in the Advanced Debug Handler installation guide, there is a step like this:

The build.bat file was removed in the Git disasm, so how do I do this in the new build.lua file?
Thanks in advance.

 

I actually figured out how to install Vladikcomper's error handler in the new Lua-based build system a few weeks ago, so might as well share it:

1. Follow the steps to install the debugger macros and error handler blob.

2. Place convsym.exe in build_tools/xxx, where xxx is your platform (e.g., Win32 if Windows).

3. In build.lua, find this line near the top:

Code (Lua):

1.  
2. local tools, platform_directory = common.find_tools("s2p2bin", "fixpointer", "saxman")
3.  

Change it to this:

Code (Lua):

1.  
2. local tools, platform_directory = common.find_tools("s2p2bin", "fixpointer", "saxman", "convsym")
3.  

4. Finally, find this near the end of build.lua:

Code (Lua):

1.  
2. -- Correct the ROM's header with a proper checksum and end-of-ROM value.
3. common.fix_header("s2built.bin")
4.  

Underneath that, insert this:

Code (Lua):

1.  
2. -- Run convsym to add the symbol table to the end of the ROM.
3. os.execute(tools.convsym .. " s2.lst s2built.bin -input as_lst -a")
4.  

That's pretty much all there is to it. :>