Basic Questions & Answers thread

I didn't notice his edit, or I would have added a quote to specify: the error, in question, is that the syntax used by AS is as I specify above, but fixed to this:

Code (Text):

1.     lea (XXX).w,aN  ; absolute short
2.     lea (XXX).l,aN  ; absolute long

but the syntax used in asm68k is this:

Code (Text):

1.     lea XXXX,aN

The two syntaxes are different, and AS will reject the latter form (I don't know if asm68k accepts the other or not).

If you mean also the differences between the ".w" and ".l" versions, it is this: the ".w" form is limited to addresses that are 16 bits in size; these addresses are sign-extended to 32-bits. Thus, it is either limited to ROM addresses in the first 32KB of ROM (if the sign bit is clear, a positive address) or to RAM addresses in the last 32KB of RAM (if the sign bit is set, a negative number). The ".l" version can use any address whatsoever, being 32 bits in size.

Note that "lea" means "load effective address" -- that is, the address register in the right side will be a pointer to the location you specify after the instruction executes, not the data at that location.

(the reason for the strikethroughs in in vladikcompiler's post and my own after that)

 

Actually, the said latter form is the most common one in 68k assembly programming, all the assemblers should support it.

lea Location,a0 represents a non-defined absolute addressing form.

The assembler will auto-convert the operand in the expression above into one of the following addressing modes:
(Location).w - absolute short
(Location).l - absolute long
Location(pc) - PC-relative addressing

If the optimizations enabled, the assembler will attempt to choose the most suitable one for you, usually saving you opcode size and even a bunch of execution cycles. Not to mention you save a real lot of time by not defining modes yourself, both on typing stuff and analyzing every operand to choose the most appropriate mode for it.

Pre-defining every single addressing mode is disassemblers' way of laying things down. This is necessary to make sure disassembled code can be re-assembled saving each opcode's original form. This is bad Sonic disassemblies are adapting people to using those pre-defined addressing forms, even in their own independent code. We're humans, not assemblers! A programmer doesn't have to deal with it at all -- let the assembler do its job. The only way you might need pre-defined absolute addressing modes are the rarest cases of byte-critical or dynamic code.

As for the fact AS rejects non-defined absolute addressing form, where did that information come form? I'm apologizing if I'm missed something and I'm also not pretending to know this assembler well (I'm mainly using ASM68K), but the fact is, I used it once or twice to create a synchronous 68k and z80 program, and I coded it in my usual manner, not defining any particular addressing modes on absolute locations. AS proved to support it like any normal 68k assembler does. Long, short and PC-relative modes were then auto-defined correctly. Perhaps, it's Sonic disassemblies under AS quirk I'm unaware of. But even so, it's quite a bad quirk in my opinion.

 

You are absolutely correct; after I looked over, you can specify addresses like this in AS. I was going by Caverns 4 comment, and it is actually incorrect; I have edited my previous post to mark the incorrect information as such.

 

Recently I've taken up attempting to port Marble Zone to Sonic 2, I've made a sizeable bit of progress, but hit a snag upon remembering how poorly my previous enemy ports had gone: Motobug and the HPZ bat, but I had significantly less experience back then. Willing to put myself to the test once again, I set to work trying to port Caterkiller. Surprisingly, it worked somewhat: it didn't crash the game and its head worked almost fully. Normally, if it had gone (what I consider to be) absolutely horribly, I'd have given up and saved the porting business for another time, but given how much functionality is there, I don't want to just abandon it; I feel that while I've made some large mistakes, I can't be that far off this time.

One of the main problems is that the body segments are constantly raising or falling, and when the Caterkiller's body breaks up, the segments that are glitching up don't hop away, they vanish. The Caterkiller also has trouble detecting walls to its left, often outright going straight through the things, and only turning when it reaches lava Turns out that was a bug with the original Sonic 1. On the first couple of frames after being spawned, the Caterkiller looks perfect, correct mapping, correct art, the head and body are in the right place, everything, it just all goes to hell in the code sometime after. I have everything rigged up correctly (PLCs, art, mapping, object definition) it appears to be a problem the Caterkiller's code itself, but looking through it, I can't see exactly where I went wrong, I mean, of course I've screwed up somewhere, but I can't make any progress if I can't identify the problem, which is why I'm now asking for help.

I have my Caterkiller code here:

Spoiler

Code (ASM):

1. ; ---------------------------------------------------------------------------
2. ; Object 78 - Caterkiller enemy (MZ, SBZ)
3. ; ---------------------------------------------------------------------------
4. Obj4D:
5.     moveq   #0,d0
6.     move.b  routine(a0),d0
7.     move.w  Obj4D_Index(pc,d0.w),d1
8.     jmp Obj4D_Index(pc,d1.w)
9. ; ===========================================================================
10. Obj4D_Index:    offsetTable
11.         offsetTableEntry.w Obj4D_Init       ;  0
12.         offsetTableEntry.w Obj4D_Head       ;  2
13.         offsetTableEntry.w Obj4D_BodySeg1   ;  4
14.         offsetTableEntry.w Obj4D_BodySeg2   ;  6
15.         offsetTableEntry.w Obj4D_BodySeg1   ;  8
16.         offsetTableEntry.w Obj4D_Delete     ; $A
17.         offsetTableEntry.w loc_16CC0        ; $C
18. ; ===========================================================================
19.  
20. locret_16950:
21.     rts
22. ; ===========================================================================
23.  
24. Obj4D_Init: ; routine 0
25.     move.b  #7,y_radius(a0)
26.     move.b  #8,x_radius(a0)
27.     jsr (ObjectMoveAndFall).l
28.     jsr (ObjCheckFloorDist).l
29.     tst.w   d1
30.     bpl.s   locret_16950
31.     add.w   d1,y_pos(a0)
32.     clr.w   y_vel(a0)
33.     addq.b  #2,routine(a0)
34.     move.l  #Mapunc_Caterkiller,mappings(a0)
35. ;   move.w  #make_art_tile(ArtTile_ArtNem_CaterkillerSBZ,1,0),art_tile(a0)
36. ;   cmpi.b  #id_SBZ,(Current_Zone).w ; if level is SBZ, branch
37. ;   beq.s   +
38.     move.w  #make_art_tile(ArtTile_ArtNem_Caterkiller,1,0),art_tile(a0) ; MZ specific code
39. ;   move.w  #$24FF,art_tile(a0) ; MZ specific code
40. ;+  ; Is Scrap Brain Zone
41.     andi.b  #3,render_flags(a0)
42.     ori.b   #4,render_flags(a0)
43.     move.b  render_flags(a0),status(a0)
44.     move.w  #$200,priority(a0)  ; S3K
45.     move.b  #8,width_pixels(a0)
46.     move.b  #$B,collision_flags(a0)
47.     move.w  x_pos(a0),d2
48.     moveq   #$C,d5
49.     btst    #0,status(a0)
50.     beq.s   +
51.     neg.w   d5
52. +   ; No flip
53.     move.b  #4,d6
54.     moveq   #0,d3
55.     moveq   #4,d4
56.     movea.l a0,a2
57.     moveq   #2,d1
58.  
59. Obj4D_Loop:
60.     jsr (SingleObjLoad).l
61.     bne.w   Obj4D_ChkGone
62.     move.b  #ObjID_Caterkiller,0(a1) ; load body segment object
63.     move.b  d6,routine(a1) ; goto Obj4D_BodySeg1 or Obj4D_BodySeg2 next
64.     addq.b  #2,d6   ; alternate between the two
65.     move.l  mappings(a0),mappings(a1)
66.     move.w  art_tile(a0),art_tile(a1)
67.     move.w  #$280,priority(a1)  ; S3K
68.     move.b  #8,width_pixels(a1)
69.     move.b  #$CB,collision_flags(a1)
70.     add.w   d5,d2
71.     move.w  d2,x_pos(a1)
72.     move.w  y_pos(a0),y_pos(a1)
73.     move.b  status(a0),status(a1)
74.     move.b  status(a0),render_flags(a1)
75.     move.b  #8,mapping_frame(a1)
76.     move.l  a2,objoff_3C(a1)
77.     move.b  d4,objoff_3C(a1)
78.     addq.b  #4,d4
79.     movea.l a1,a2
80.  
81.     dbf d1,Obj4D_Loop   ; repeat sequence 2 more times
82.  
83.     move.b  #7,objoff_29(a0)
84.     clr.b   objoff_3C(a0)
85.  
86. Obj4D_Head: ; routine 2
87.     tst.b   status(a0)
88.     bmi.w   loc_16C96
89.     moveq   #0,d0
90.     move.b  routine_secondary(a0),d0
91.     move.w  Obj4D_Index2(pc,d0.w),d1
92.     jsr Obj4D_Index2(pc,d1.w)
93.     move.b  objoff_2A(a0),d1
94.     bpl.s   Head_Display
95.     lea (Ani_Caterkiller).l,a1
96.     move.b  angle(a0),d0
97.     andi.w  #$7F,d0
98.     addq.b  #4,angle(a0)
99.     move.b  (a1,d0.w),d0
100.     bpl.s   Head_Animate
101.     bclr    #7,objoff_2A(a0)
102.     bra.s   Head_Display
103.  
104. Head_Animate:
105.     andi.b  #$10,d1
106.     add.b   d1,d0
107.     move.b  d0,mapping_frame(a0)
108.  
109. Head_Display:
110.     move.w  x_pos(a0),d0
111.     andi.w  #$FF80,d0
112.     sub.w   (Camera_X_pos_coarse).w,d0
113.     cmpi.w  #$280,d0
114.     bls.s   +
115. Obj4D_ChkGone:
116.     markObj_gone    ; S3K
117.     move.b  #$A,routine(a0) ; goto Obj4D_Delete next
118.     rts
119.  
120. +   jmp (DisplaySprite).l
121. ; ===========================================================================
122.  
123. Obj4D_Delete:   ; routine $A
124.     jmp (DeleteObject).l
125. ; ===========================================================================
126. Obj4D_Index2:   offsetTable
127.         offsetTableEntry.w Obj4D_Idle       ; 0
128.         offsetTableEntry.w loc_16B02        ; 2
129. ; ===========================================================================
130.  
131. Obj4D_Idle:
132.     subq.b  #1,objoff_29(a0)
133.     bmi.s   Obj4D_Move
134.     rts
135. ; ===========================================================================
136.  
137. Obj4D_Move:
138.     addq.b  #2,routine_secondary(a0)
139.     move.b  #$10,objoff_29(a0)  ; sets Caterkiller's state timer to $10
140.     move.w  #-$C0,x_vel(a0)     ; Caterkiller's initial speed
141.     move.w  #$40,inertia(a0)
142.     bchg    #4,objoff_2A(a0)    ; affects facial expression
143.     bne.s   loc_16AFC
144.     clr.w   x_vel(a0)
145.     neg.w   inertia(a0)
146.  
147. loc_16AFC:
148.     bset    #7,objoff_2A(a0)
149.  
150. loc_16B02:      ; XREF: Obj4D_Index2
151.     subq.b  #1,objoff_29(a0)
152.     bmi.s   loc_16B5E
153.     tst.w   x_vel(a0)
154.     beq.s   Obj4D_NotMoving
155.     move.l  x_pos(a0),d2
156.     move.l  d2,d3
157.     move.w  x_vel(a0),d0
158.     btst    #0,status(a0)
159.     beq.s   +   ; No flip
160.     neg.w   d0
161. +   ; No flip
162.     ext.l   d0
163.     asl.l   #8,d0
164.     add.l   d0,d2
165.     move.l  d2,x_pos(a0)
166.     swap    d3
167.     cmp.w   x_pos(a0),d3
168.     beq.s   Obj4D_NotMoving
169.     jsr (ObjCheckFloorDist).l
170.     cmpi.w  #$FFF8,d1
171.     blt.s   loc_16B70
172.     cmpi.w  #$C,d1
173.     bge.s   loc_16B70
174.     add.w   d1,y_pos(a0)
175.     moveq   #0,d0
176.     move.b  objoff_3C(a0),d0
177.     addq.b  #1,objoff_3C(a0)
178.     andi.b  #$F,objoff_3C(a0)
179.     move.b  d1,objoff_2B(a0,d0.w)
180.  
181. Obj4D_NotMoving:
182.     rts
183. ; ===========================================================================
184.  
185. loc_16B5E:
186.     subq.b  #2,routine_secondary(a0)
187.     move.b  #7,objoff_29(a0)
188.     clr.w   x_vel(a0)
189.     clr.w   inertia(a0)
190.     rts
191. ; ===========================================================================
192.  
193. loc_16B70:
194.     moveq   #0,d0
195.     move.b  objoff_3C(a0),d0
196.     move.b  #$80,objoff_2B(a0,d0)
197.     neg.w   x_pos+2(a0)
198.     beq.s   loc_1730A
199.     btst    #0,status(a0)
200.     beq.s   loc_1730A
201.     subq.w  #1,x_pos(a0)
202.     addq.b  #1,objoff_3C(a0)
203.     moveq   #0,d0
204.     move.b  objoff_3C(a0),d0
205.     clr.b   objoff_2B(a0,d0)
206. loc_1730A:
207.     bchg    #0,status(a0)
208.     move.b  status(a0),render_flags(a0)
209.     addq.b  #1,objoff_3C(a0)
210.     andi.b  #$F,objoff_3C(a0)
211.     rts
212. ; ===========================================================================
213.  
214. Obj4D_BodySeg2: ; routine 6
215.     movea.l objoff_3C(a0),a1
216.     move.b  objoff_2A(a1),objoff_2A(a0)
217.     bpl.s   Obj4D_BodySeg1
218.     lea (Ani_Caterkiller).l,a1
219.     move.b  angle(a0),d0
220.     andi.w  #$7F,d0
221.     addq.b  #4,angle(a0)
222.     tst.b   4(a1,d0.w)
223.     bpl.s   Obj4D_AniBody
224.     addq.b  #4,angle(a0)
225.  
226. Obj4D_AniBody:
227.     move.b  (a1,d0.w),d0
228.     addq.b  #8,d0
229.     move.b  d0,mapping_frame(a0)
230.  
231. Obj4D_BodySeg1: ; routine 4, 8
232.     movea.l objoff_3C(a0),a1
233.     tst.b   status(a0)
234.     bmi.w   loc_16C90
235.     move.b  objoff_2A(a1),objoff_2A(a0)
236.     move.b  routine_secondary(a1),routine_secondary(a0)
237.     beq.w   loc_16C64
238.     move.w  inertia(a1),inertia(a0)
239.     move.w  x_vel(a1),d0
240.     add.w   inertia(a0),d0
241.     move.w  d0,x_vel(a0)
242.     move.l  x_pos(a0),d2
243.     move.l  d2,d3
244.     move.w  x_vel(a0),d0
245.     btst    #0,status(a0)
246.     beq.s   loc_16C0C
247.     neg.w   d0
248.  
249. loc_16C0C:
250.     ext.l   d0
251.     asl.l   #8,d0
252.     add.l   d0,d2
253.     move.l  d2,x_pos(a0)
254.     swap    d3
255.     cmp.w   x_pos(a0),d3
256.     beq.s   loc_16C64
257.     moveq   #0,d0
258.     move.b  objoff_3C(a0),d0
259.     move.b  objoff_2B(a1,d0.w),d1
260.     cmpi.b  #$80,d1
261.     bne.s   loc_16C50
262.     move.b  d1,objoff_2B(a0,d0)
263.     neg.w   x_pos+2(a0)
264.     beq.s   +
265.     btst    #0,status(a0)
266.     beq.s   +
267.     cmpi.w  #-$C0,x_vel(a0)
268.     bne.s   +
269.     subq.w  #1,x_pos(a0)
270.     addq.b  #1,objoff_3C(a0)
271.     moveq   #0,d0
272.     move.b  objoff_3C(a0),d0
273.     clr.b   objoff_2B(a0,d0)
274. +
275.     bchg    #0,status(a0)
276.     move.b  status(a0),1(a0)
277.     addq.b  #1,objoff_3C(a0)
278.     andi.b  #$F,objoff_3C(a0)
279.     bra.s   loc_16C64
280. ; ===========================================================================
281.  
282. loc_16C50:
283.     ext.w   d1
284.     add.w   d1,y_pos(a0)
285.     addq.b  #1,objoff_3C(a0)
286.     andi.b  #$F,objoff_3C(a0)
287.     move.b  d1,objoff_2B(a0,d0.w)
288.  
289. loc_16C64:
290.     cmpi.b  #$C,routine(a1)
291.     beq.s   loc_16C90
292.     cmpi.b  #ObjID_Explosion,0(a1)
293.     beq.s   loc_16C7C
294.     cmpi.b  #$A,routine(a1)
295.     bne.s   loc_16C82
296.  
297. loc_16C7C:
298.     move.b  #$A,routine(a0)
299.  
300. loc_16C82:
301.     jmp (DisplaySprite).l
302.  
303. ; ===========================================================================
304. Obj4D_FragSpeed:
305.     dc.w  -$200
306.     dc.w  -$180
307.     dc.w   $180
308.     dc.w   $200
309. ; ===========================================================================
310.  
311. loc_16C90:
312.     bset    #7,status(a1)
313.  
314. loc_16C96:
315.     moveq   #0,d0
316.     move.b  routine(a0),d0
317.     move.w  Obj4D_FragSpeed-2(pc,d0.w),d0
318.     btst    #0,status(a0)
319.     beq.s   loc_16CAA
320.     neg.w   d0
321.  
322. loc_16CAA:
323.     move.w  d0,x_vel(a0)
324.     move.w  #-$400,y_vel(a0)
325.     move.b  #$C,routine(a0)
326.     andi.b  #$F8,mapping_frame(a0)
327.  
328. loc_16CC0:  ; routine $C
329.     jsr (ObjectMoveAndFall).l
330.     tst.w   y_vel(a0)
331.     bmi.s   loc_16CE0
332.     jsr (ObjCheckFloorDist).l
333.     tst.w   d1
334.     bpl.s   loc_16CE0
335.     add.w   d1,y_pos(a0)
336.     move.w  #-$400,y_vel(a0)
337.  
338. loc_16CE0:
339.     tst.b   render_flags(a0)
340.     bpl.w   Obj4D_ChkGone
341.     jmp (DisplaySprite).l
342.  
343.  
344. Mapunc_Caterkiller: BINCLUDE "mappings/sprite/obj4D.bin"
345.  
346. ; ---------------------------------------------------------------------------
347. ; Animation script - Caterkiller enemy (uses non-standard format)
348. ; ---------------------------------------------------------------------------
349. Ani_Caterkiller:
350.         dc.b 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1
351.         dc.b 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3
352.         dc.b 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6
353.         dc.b 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, $FF, 7, 7, $FF
354.         dc.b 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6
355.         dc.b 6, 6, 6, 6, 6, 6, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4
356.         dc.b 4, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1
357.         dc.b 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, $FF, 0, 0, $FF
358.         even

While porting, I encountered an error regarding this line:

Code (ASM):

1.     swap.w  d3

An invalid operand size. This line is involved in x_pos. In order to get past the error, I had the line changed to this:

Code (ASM):

1.     swap    d3

I assume the operand functions as a byteswap. This could be the cause of the problem, as an instance of swap without the suffix exists in the original code, along with the swap.w, does anyone have an equivalent? swap.l compiles, but .b, .w, and .s don't. Adding the .l or commenting out any of the two swaps does affect how wildly the body segments misalign themselves.

 

Righty, I need someone with Z80 knowledge here for a moment:

Code (Text):

1.         ld  a,(hl)
2.         inc hl
3.         add a,(hl) 
4.         ld  (hl),a 
5.         inc hl
6.         ld  a,(hl) 
7.         inc hl
8.         adc a,(hl) 
9.         ld  (hl),a 
10.         ld  e,a
11.         inc hl
12.         adc a,(hl) 
13.         sub e
14.         ld  (hl),a 
15.         inc hl
16.         ld  d,a
17.         ld  a,(de)

The above routine takes 1A machine cycles to process, I'm looking to reduce it by as much as possible. Please note, the final "inc hl" there is necessary as the same code is ran one after another, in order to avoid having to load a pointer into hl multiple times (ensuring it's only done once). If however a quicker solution exists that doesn't rely on the hl register containing the pointer initially, then that is equally fine, so long as it performs the same function.

 

Align your data and use INC L only.

 

Aha, thank you very much! That brings me a step closer.

 

Okay, there are some things that have been bugging me about the Sonic 2 HG disassembly. I just kind of decided at first, that that's the way it is, abd it's pretty much just naming and labeling issues in reality, but I finally reached a point where I felt like I had to say something when I found this:

Code (Text):

1. ArtUnc_HTZCliffs:   BINCLUDE    "art/nemesis/Dynamically reloaded cliffs in HTZ background.bin"

While it's stored with other uncompressed art so I'm inclined to believe that it's uncompressed, it's stored in the NEMESIS folder. That's just... Not right.

Edit: It's compressed... So why call it "ArtUnc"?

Similarly is the uncompressed art for the lava from Metropolis Zone - it's labeled as belonging to Metropolis Zone AND Hill Top Zone. Whoever named it that must not have ever played Hill Top Zone before; It uses completely different art.

Another thing thing is the naming scheme of certain things, for example, the collision data:

Code (Text):

1. CPZ and DEZ primary 16x16 collision index.bin

Is that really the best way it could be labeled? Why not simply CPZ_DEZ_ColP.bin or something? Or even just CPZ_ColP.bin since it's well known that CPZ and DEZ share assets?

These are all things I'd like to see changed, and while I would do it myself, I don't really know what the process for doing so is, or if others would like it (Though I'm assuming the general consensus would be to fix them, since some of them are longwinded, while others are flat out wrong).

Any opinions, suggestions, or advice on the appropriate way to approach having these bothersome issues fixed would be appreciated.

I do have one more thing, though it's strictly opinion, and in no way "wrong".
I prefer "SpeedToPos" and "ObjectFall" to "ObjectMove" and "ObjectMoveAndFall". Partly because ObjectMoveAndFall then contains the entire name of another routine inside it. There's no legitimate reason to have this changed, but it's just something else that is not consistant between disassemblies even though the function of the routine is identical.

 

First off, while perhaps a bit wordy, the name is not inaccurate. Secondly, any change in the file names makes things rather complicated for me as the sole maintainer of SonLVL's ini files. If I update the inis for the new version of the disassembly, anyone using an older version will be stuck with the old inis, or have to manually edit their ini set every time it's updated.

 

That one is indeed still accurate, but as you've stated already, is rather longwinded.

Well, at that point, why wouldn't we do like some disassemblies do and simply include SonLvl ini's with the disassembly? It's time consuming, but it's not hard work.
(And yes I am saying I'd be willing to do such work, if it were to come to that).

 

SonLVL INIs are included with the disassembly, but the problem is that unlike SonED2, SonLVL's object definitions are nowhere near complete, and even the API and structure of the ini files is subject to change at any time (in fact, this has happened several times).

 

I'm not trying to be funny, but I have the strangest cartridge of Sonic 1 and I want to hear what you'd make of it.

I've had it for as long as I can remember (being one of the first video games I've ever played and all) but I've noticed some downright weird discrepancies between what my cart is and what all documentation I've found says my cart should be. It's a European copy, which is all well and good, it certainly looks the part, to say the least, but it's REV01, not REV00. REV00 being, what everything says, the only revision to have made it to Europe. Not only that, but the box differs in a few ways.

I've considered that it may be a pirate copy, but it exhibits no typical pirate traits: the Sega logo, the copyrights, it's all there! The box and cart are certainly no poor imitations, if it is pirate produced then it's a hell of an accurate recreation, I've long lost the instruction manual, so I can't look at that. The cart shows no obvious signs of tampering. Such signs would indicate that it was opened some time in the past, possibly with the intention of board swapping, but as I said, I can't find any. The box has some potentially useful information: two old plain yellow shop price labels, "6703 (catalogue number?) PREOWNED £7.99", one on the front cover, obscuring the 'E' of (MEGA) "DRIVE", and another covering the barcode (which is intact, it's not blank or anything). The cart itself has an interesting trait too: A letter 'P' scrawled in black ball-point pen on the top left corner of the cart's frontal sticker. What it stands for, I can only guess. PAL? Pirate? I'd rather not jump to conclusions and see what you guys think.

Even stranger is that the cover art scan found on the info page differs from my box (I'm having a hard time finding additional scans to compare against, so please excuse my ignorance). Look at the back cover, underneath the image of SBZ, you can see a list of patents. My copy doesn't have those. Also, underneath that you can see a serial number(?), a line that reads "© 1991 SEGA ENTERPRISES LTD." and that specific copy's place of manufacture, which in the scan's case, is China. Mine has no serial number, (the copyright's there though) and, according to the box, mine was made in Japan.

EDIT: Ack, wrong section. This post was supposed to be a simple query on REV01 distribution. Guess I got carried away.

 

Sounds to me like the game is resold or copied version, it's hard to say. Definitely somethe perculiar at least.

I bought a copy of Sonic 1 fairly recently; Along with a model-1 "High Definition Graphics" version Genesis, and my Sonic 1 cartridge says "NOT FOR RESALE" on big red letters on the cartridge art. Not sure if this is unusual in any way, but it's at least funny because I bought it used (But in very good condition). lol resale.

Anyway, on something relevant, can anyone explain to me exactly how the CPZ vacuum tube work? I know they're object 1E, but I can't seem to figure out how they're supposed to work.

 

When you enter the pipe, it sends you along one of the paths in misc/obj1E_a.asm, which uses coordinates relative to the position of the object. Then, depending on the second you entered the tube and some array somewhere in there, it sends you through one of two paths in misc/obj1E_b.asm, which uses absolute coordinates. Once you finish that, it sends you through another path from the first file, and out the other side.

The MTZ tubes are a lot simpler.

 

Ok, So I am getting my girlfriend to mod Sonic 1. And I have come to a bump in the road. I was having her follow the very outdated tutorial for importing Spindash. When we got to the art section we downloaded SonMapED. Only to find that for some reason the mappings and DPLC files for Sonic won't load in the program. We are using the latest version of the disassembly. Help me please? =/

 

Settings -> Game Format -> Sonic 1?

Then try loading again.

 

Yeah, I did try that first thing. =P

Art loads up with the correct palette, just the mappings and dplcs won't seem to load. Fresh disasm and fresh copy of SonMapED.

Edit: The older Hivebrain files work just fine in the program, just not the newer ones from the mercurial. Am I the only one with this issue or is it something wrong with the current copy on the mercurial?

 

It's likely an issue with the extra stuff for the frame IDs. You can use the assembler to assemble it to a binary file, or MappingsConverter should be able to parse the asm and produce a SonMapEd-compatible ASM file, but in both cases you'll now be lacking those frame ID constants. The only option is to do the editing in a separate file, then add your new frames to the original when you're done.

 

I just wanted to point this out since we are on the same subject... I get the same issue for ANY mappings or DPLC's in the new Sonic 1 disassembly. SonMapEd also doesn't support MainMemory's new mappings macro ASM files. As he said above, just use his converter for that too.