Basic Questions & Answers thread

Boing-o-bot troubles again...

Code (Text):

1.  
2. ; for Boing-o-Bot
3. loc_3F9CE:
4.     sub.w    d0,d5
5.     cmpi.w    #$10,d5
6.     bhs.s    BranchTo_Touch_Enemy
7.     move.w    x_pos(a1),d0
8.     subq.w    #4,d0
9.     btst    #0,status(a1)
10.     beq.s    +
11.     subi.w    #$2,d0
12. +
13.     clr.w    d2
14.     move.b    width_pixels(a1),d2
15.     neg.w    d2
16.     subi.w    #$10,d2
17.     sub.w    d2,d0
18.     bcc.s    .check_hurt
19.     addi.w    #$18,d0
20.     subi.w    #$20,y_pos(a0)
21.     move.w    #-$A00,y_vel(a0)
22.     bset    #1,status(a0)
23.     bclr    #3,status(a0)
24.     clr.b    jumping(a0)
25.     cmpi.b    #ObjID_Tails,id(a0)
26.     bne.s    +
27.     move.b    #2,double_jump_flag(a0)
28. +
29.     move.b    #AniIDSonAni_Spring,anim(a0)
30.     move.b    #SndID_Spring,d0
31.     jmp    (PlaySound).l
32. .check_hurt:
33.     bra.s    BranchTo_Touch_Enemy
34.  

the object works mostly fine, except if you roll into it, it acts like you jumped on it and erroneously bounces you up.
is there some mistake I've made here?

 

I have a question: Has anyone ever dealt with Sonic 2's uncompressed animated art breaking out of a sudden? I just realized they've been static all this time and I don't know how to fix these.
I barely touch the source code since I'm an ASM noob so I don't really know what happened. The last alterations I've made were to split EHZ and ARZ's water palettes and changing some title cards. I also realized that the sound driver also broke whenever the 1-up sound played which forced me to use a very early backup and port those changes back to it. I was using the 2019 version of MM's Sonic 2's Sound Driver Plus disassembly.

PS: I've managed to find some very old versions of my source code on Discord and did a frankenstein to solve all of these problems, but if anyone still wants to explain on why does these level animations break, feel free to do so.

 

I'm trying to figure out how to change the "Sonic got through" text in Sonic 2. Started by looking at Object 3A, the end of level results object. The mappings for the object are in the main ASM file, so I copied the text into its own file to open in Flex 2. However, I get an error:

I don't understand why it's claiming that the symbols are undefined. As far as I can tell, these mappings look like the other mapping files in the disassembly. I'm using version 1.3.3 of Flex 2 which seems to be the latest version, and I have Sonic 2 selected for the game format.
These are the mappings I'm trying to load for reference, copied as is from the main s2.asm file.

Code (Text):

1. Obj3A_MapUnc_14CBC:    mappingsTable
2.     mappingsTableEntry.w    word_14CDA
3.     mappingsTableEntry.w    word_14D1C
4.     mappingsTableEntry.w    word_14D5E
5.     mappingsTableEntry.w    word_14DA0
6.     mappingsTableEntry.w    word_14DDA
7.     mappingsTableEntry.w    word_14BC8
8.     mappingsTableEntry.w    word_14BEA
9.     mappingsTableEntry.w    word_14BF4
10.     mappingsTableEntry.w    word_14BFE
11.     mappingsTableEntry.w    word_14DF4
12.     mappingsTableEntry.w    word_14E1E
13.     mappingsTableEntry.w    word_14E50
14.     mappingsTableEntry.w    word_14E82
15.     mappingsTableEntry.w    word_14E8C
16.     mappingsTableEntry.w    word_14E96
17.  
18. word_14CDA:    spriteHeader
19.     spritePiece    -$40, 0, 2, 2, $5D0, 0, 0, 0, 1
20.     spritePiece    -$30, 0, 2, 2, $588, 0, 0, 0, 1
21.     spritePiece    -$20, 0, 2, 2, $584, 0, 0, 0, 1
22.     spritePiece    -$10, 0, 1, 2, $5C0, 0, 0, 0, 1
23.     spritePiece    -8, 0, 2, 2, $5B4, 0, 0, 0, 1
24.     spritePiece    $10, 0, 2, 2, $5B8, 0, 0, 0, 1
25.     spritePiece    $20, 0, 2, 2, $588, 0, 0, 0, 1
26.     spritePiece    $2F, 0, 2, 2, $5D4, 0, 0, 0, 1
27. word_14CDA_End
28.  
29. word_14D1C:    spriteHeader
30.     spritePiece    -$44, 0, 3, 2, $5C6, 0, 0, 0, 1
31.     spritePiece    -$2C, 0, 1, 2, $5C0, 0, 0, 0, 1
32.     spritePiece    -$24, 0, 2, 2, $5C2, 0, 0, 0, 1
33.     spritePiece    -$14, 0, 2, 2, $580, 0, 0, 0, 1
34.     spritePiece    -4, 0, 2, 2, $5D0, 0, 0, 0, 1
35.     spritePiece    $14, 0, 2, 2, $5B8, 0, 0, 0, 1
36.     spritePiece    $24, 0, 2, 2, $588, 0, 0, 0, 1
37.     spritePiece    $33, 0, 2, 2, $5D4, 0, 0, 0, 1
38. word_14D1C_End
39.  
40. word_14D5E:    spriteHeader
41.     spritePiece    -$3D, 0, 2, 2, $5D4, 0, 0, 0, 1
42.     spritePiece    -$30, 0, 2, 2, $5B0, 0, 0, 0, 1
43.     spritePiece    -$20, 0, 1, 2, $5C0, 0, 0, 0, 1
44.     spritePiece    -$18, 0, 2, 2, $5C2, 0, 0, 0, 1
45.     spritePiece    -8, 0, 2, 2, $5D0, 0, 0, 0, 1
46.     spritePiece    $10, 0, 2, 2, $5B8, 0, 0, 0, 1
47.     spritePiece    $20, 0, 2, 2, $588, 0, 0, 0, 1
48.     spritePiece    $2F, 0, 2, 2, $5D4, 0, 0, 0, 1
49. word_14D5E_End
50.  
51. word_14DA0:    spriteHeader
52.     spritePiece    -$38, 0, 2, 2, $5D4, 0, 0, 0, 1
53.     spritePiece    -$28, 0, 2, 2, $5BC, 0, 0, 0, 1
54.     spritePiece    -$18, 0, 2, 2, $5CC, 0, 0, 0, 1
55.     spritePiece    -8, 0, 2, 2, $588, 0, 0, 0, 1
56.     spritePiece    8, 0, 2, 2, $5D8, 0, 0, 0, 1
57.     spritePiece    $18, 0, 2, 2, $5B8, 0, 0, 0, 1
58.     spritePiece    $28, 0, 2, 2, $5BC, 0, 0, 0, 1
59. word_14DA0_End
60.  
61. word_14DDA:    spriteHeader
62.     spritePiece    0, 0, 2, 2, $5B0, 0, 0, 0, 1
63.     spritePiece    $10, 0, 2, 2, $5B4, 0, 0, 0, 1
64.     spritePiece    $1F, 0, 2, 2, $5D4, 0, 0, 0, 1
65. word_14DDA_End
66.  
67. word_14DF4:    spriteHeader
68.     spritePiece    -$48, 0, 3, 2, $5E6, 0, 0, 1, 1
69.     spritePiece    -$30, 0, 2, 2, $5EC, 0, 0, 1, 1
70.     spritePiece    -$2C, 0, 2, 2, $5F0, 0, 0, 0, 1
71.     spritePiece    $38, 0, 4, 2, $520, 0, 0, 0, 1
72.     spritePiece    $58, 0, 1, 2, $6F0, 0, 0, 0, 1
73. word_14DF4_End
74.  
75. word_14E1E:    spriteHeader
76.     spritePiece    -$5C, 0, 4, 2, $6DA, 0, 0, 1, 1
77.     spritePiece    -$34, 0, 4, 2, $5DE, 0, 0, 1, 1
78.     spritePiece    -$14, 0, 1, 2, $6CA, 0, 0, 1, 1
79.     spritePiece    -$18, 0, 2, 2, $5F0, 0, 0, 0, 1
80.     spritePiece    $38, 0, 4, 2, $528, 0, 0, 0, 1
81.     spritePiece    $58, 0, 1, 2, $6F0, 0, 0, 0, 1
82. word_14E1E_End
83.  
84. word_14E50:    spriteHeader
85.     spritePiece    -$5C, 0, 4, 2, $6D2, 0, 0, 1, 1
86.     spritePiece    -$34, 0, 4, 2, $5DE, 0, 0, 1, 1
87.     spritePiece    -$14, 0, 1, 2, $6CA, 0, 0, 1, 1
88.     spritePiece    -$18, 0, 2, 2, $5F0, 0, 0, 0, 1
89.     spritePiece    $38, 0, 4, 2, $530, 0, 0, 0, 1
90.     spritePiece    $58, 0, 1, 2, $6F0, 0, 0, 0, 1
91. word_14E50_End
92.  
93. word_14E82:    spriteHeader
94.     spritePiece    0, 0, 2, 3, $5F4, 0, 0, 0, 1
95. word_14E82_End
96.  
97. word_14E8C:    spriteHeader
98.     spritePiece    0, 0, 2, 3, $5FA, 0, 0, 0, 1
99. word_14E8C_End
100.  
101. word_14E96:    spriteHeader
102.     spritePiece    -$68, 0, 4, 2, $540, 0, 0, 1, 1
103.     spritePiece    -$48, 0, 3, 2, $548, 0, 0, 1, 1
104.     spritePiece    -$28, 0, 4, 2, $5DE, 0, 0, 1, 1
105.     spritePiece    -8, 0, 1, 2, $6CA, 0, 0, 1, 1
106.     spritePiece    -$C, 0, 2, 2, $5F0, 0, 0, 0, 1
107.     spritePiece    $38, 0, 4, 2, $538, 0, 0, 0, 1
108.     spritePiece    $58, 0, 1, 2, $6F0, 0, 0, 0, 1
109. word_14E96_End
110.  
111.     even

Edit: Just realized the screenshot and the file are inconsistent in naming. Sorry. Tried changing labels to see if that would change anything (it didn't).

 

The results text takes mappings from the stage title card to get things like the act number, the actual data for those mappings is at Obj34_MapUnc_147BA. And that's why it's in the main file instead of split. So you have make a copy of the mapping data for the results text and change the pointer to the copies.

 

I am testing an enigma decompressorbive written, i need a block of enigma compressed data to test on. IIRC sonic 1 16x16 blocks are enigma compressed, but I cant find their rom offset location on the wiki. I could have sworn they were they before. Anybody got a rom map of sonic 1 with the offset to, say, ghz's 16x16 definitions?

 

Green Hill Zone's 16x16 blocks are at 0x3C19C - 0x3CB3C in revision 01. Why not use a disassembly though?

 

Because i want people to provide their own asserts via a rom that extracts information.

Got a list of all the memory locations? Blocks and chunks, preferably by zones. Sonic 2's hacking guide has per zone offsets, i swear there used to be a list like this for sonic 1, its how i rendered spring yard zone in the past l.

 

Well chunks in Sonic 1 are Kosinski/LZEXE compressed but rather than asking more questions I'll just hand you the list you're looking for:
GHZ 16x16: 0x3C19C - 0x3CB3C
GHZ 256x256: 0x3F544 - 0x41654
LZ 16x16: 0x41654 - 0x4197E
LZ 256x256: 0x434C6 - 0x45CB6
MZ 16x16: 0x45CB6 - 0x464C0
MZ 256x256: 0x48D04 - 0x4A4A4
SLZ 16x16: 0x4A4A4 - 0x4AC88
SLZ 256x256: 0x4E7DC - 0x50C0C
SYZ 16x16: 0x50C0C - 0x5157A
SYZ 256x256: 0x54CA6 - 0x57056
SBZ 16x16: 0x57056 - 0x57EF0
SBZ 256x256: 0x5A69C - 0x5D0FC
Again, all revision 01, just in case.

 

Much appreciated, where are you pulling these from? Just in case i need to find them again. Back around 2016 i had a list of all these offsets but googling them brings up nothing anymore.

Edit: enigma decompression routine appears to be working from my eyeball of the 16x16 mappings, thanks!

 

What I did was pull up the ROM in a hex editor, and then opened the disassembly files too, copied the first 24 or so bytes, used the find function, noted the starting ROM location, then go back to the disassembly file and copy the last few bytes and noted the end location. Probably not a very efficient way to do it, but it works.

 

Appreciate the effort. I just feel like im going crazy because i swear the offsets used to be in the schg but im looking through the revisions and cant find them. Nor can i find them in nemesis' old guide. Yet i know i 100% extracted them this way in the past, i worked on sonic 1 for a long while before moving to sonic 2. I have no idea where i got the offsets from originally and its bothering me lol. Should i add these offsets back into the schg? Sonic 2 has offsets in its guide.

 

Well they are on the wiki... Just on the pages for the actual zones rather than under the SCHG.

 

There we go! I was looking for exactly this, i googled for it all day yesterday. Thanks so much!

Edit: looks like that info is only there for ghz. Nothing for any of the other zones. Know if they happen to be somewhere else? I know specifically i got spring yard zone displaying correctly originally.

Edit: finally found them, they were in nems original guide:

https://info.sonicretro.org/SCHG:Nem_s1

 

I'm looking at the AS Macro assembler manual, specifically the Operators section:

http://john.ccac.rwth-aachen.de:8000/as/as_EN.html#sect_2_10_6_



Would anyone happen to know what the hell that means?

It requires two arguments, i.e: A >< B

The manual only seems to mentioned this once in that one spot, and never again. Online searches simply lead me to conversations involving the reversal of bit order, but this doesn't seem related (or else I'd expect only one argument required, the argument you intend to reverse).

EDIT: After a discussion in a Discord server, Sik managed to figure it out.

The first parameter (A) is the value to bit reverse, the second parameter (B) is 1 to 32 to specify how far up from LSB of A to reverse the bits.

So if A were 10010110, and B were 3, then the lowest three bits of A will be mirrored (110 to 011), so A becomes 10010011.

Mystery solved~

EDIT2: It's also actually described on that page too, I couldn't find it because I copied the quote "mirror of bits" and searched that, and it came up nothing, because the sentence below they typed "mirroring of bits", ugh...

 

Is there a way to read VDP registers? I know you can read the status register by moving the control port into a RAM or something. What I wanted to do was fetch the current tilemap size to be referenced in a LUT which contains the values needed to move to a new row when printing a tilemap.

 

No. If you want that sort of functionality, you'd need to copy the register values into work RAM alongside setting them in the VDP. What I prefer to do for plane sizes is to make a function with the size as a parameter, and then it'll set the appropriate VDP register, and also set certain values in RAM related to planes/tilemaps (i.e. tilemap data stride, VDP command stride, etc.). That way, I won't need to reference a LUT every time I do something plane related, only once when setting up the plane size.

 

You can however through clever deduction and reasoning through code, work out what certain registers contain. A few examples:

• You could work out what the increment register (8F) contains, by performing a data write to VRAM, and then reading data back out of VRAM, and piecing together where the data saved went.
• You might be able to work out where the sprite table is located, by writing data into various parts of VRAM, deliberately causing two sprites to overlap, and setting the sprite collision flag which can be read from the status register, this will eventually give away the sprite table's pattern name address.
  
• You could work out what the source/destination DMA registers may contain by triggering a DMA of specific known data, and then reading data back out of VRAM (same as 8F).
• You can work out if the H and V int bits of the VDP registers are set, by just letting the 68k eventually become interrupted.
• You might be able to work out the H interrupt line amount (8A) by reading the H/V counter during H-blank triggers.
• You might be able to work out if the SMS left column is enabled, or what resolution is chosen, if (and ONLY IF) the sprite overflow flag only occurs if the sprites are on-screen, if it occurs while they're off-screen or behind the left column, then this might not work (need to clarify this).
  
• These are a bit risky, but you can probably work out where the VDP was left in write or read mode to/from and the address, by writing/reading the data, as long as you don't perform the opposite of what it's expecting, you should be fine, at least in Sonic games, it's always in write mode.
• You can work out if DMA is disabled by performing a DMA transfer and then checking if the data is in VRAM/CRAM/VSRAM.

I was working on methods of obtaining register information like this when I made the Sonic Hacking Contest screen, I wanted to try and preserve and restore the registers so the original game would never be tampered with, this was the best I could theorise.

 

I am not aware of any window access delay, so, when I wrote those macros, I did not make them account for it. Is there any documentation for the delay that you could link me to?

 

Z80 accesses M68K bus by cycle stealing: it takes over M68K bus, effectively pausing it until the bus cycle is complete (similarly to how DMA halts the M68K when it gets the bus), but it also has to wait until current M68K instruction finishes its own bus cycle, which results in arbitrary delays. However, on large number of instructions, this can be somewhat reliably averaged as instructions have similar consistent timings and we can make assumptions about their mean execution time.

You can read more here: https://plutiedev.com/mirror/kabuto-hardware-notes#bus-system

I know a lot of emulators don't emulate cycle stealing at all, yet this sometimes can have noticeable effects on playback pitch in DAC drivers, especially on higher sample rates. That's why in Mega PCM 2, for instance, I had to implement self-calibration to support both inaccurate emulators and real hardware; the driver basically benchmarks access timings on Z80 RAM vs 68K ROM upon boot and calibrates all playback loops accordingly.