Hi all, I hope this is the right place for this, apologies if not. I’ve recently acquired an Everdrive X5, and I’m interested in homebrew VGM music. There’s a whole scene out there and I’m looking for a way to use the Everdrive to play these files on the console directly. I’ve done some research and there are some sort of players available but I’ve read mixed to negative things about a few as they don’t convert samples or are just poor quality. Some of the stuff I have seen comes pre-loaded with hundreds of game tracks as a package but I’m not interested, I simply want to know how to play individual VGM’s of my choice through the Everdrive. I know this might be a bit picky from someone not technically minded in this field, but if anyone does have any recommendations on this I’d greatly appreciate the help.
Some questions: Are these two subroutine in the title functionally the same except one is for sonic 1 and the other is for sonic 2? I know they deal with respawning objects that need to be remembered. Can someone explain the overall function? Why does ObjectManager_Init ( Part of ObjectManager) look to the left of the camera one chunk two times . Each time looking for objects that are to the left of this position and need to be remembered. Why does it subtract a chunk left of the camera TWICE? It appears the first subtraction of d6 by $80 deals and the following label - deals with objects going right and the second subtracting $80 and proceeding - label deals with objects going to the left… that confused me Left and right of what? Both labels are bls.s branches so how is one checking right of something and one checking left ? Code (Text): + ; initialize each object load address with the first object in the layout move.l a0,(Obj_load_addr_right).w move.l a0,(Obj_load_addr_left).w lea (Object_Respawn_Table).w,a3 move.w (Camera_X_pos).w,d6 subi.w #$80,d6 ; look one chunk to the left bcc.s + ; if the result was negative, moveq #0,d6 ; cap at zero + andi.w #$FF80,d6 ; limit to increments of $80 (width of a chunk) movea.l (Obj_load_addr_right).w,a0 ; get first object in layout - ; at the beginning of a level this gives respawn table entries to any object that is one chunk ; behind the left edge of the screen that needs to remember its state (Monitors, Badniks, etc.) cmp.w (a0),d6 ; is object's x position >= d6? bls.s + ; if yes, branch addq.w #6,a0 ; next object addq.w #1,a3 ; respawn index of next object going right bra.s - ; --------------------------------------------------------------------------- + move.l a0,(Obj_load_addr_right).w ; remember rightmost object that has been processed, so far (we still need to look forward) move.w a3,(Obj_respawn_index_right).w ; and its respawn table index lea (Object_Respawn_Table).w,a3 ; reset a3 movea.l (Obj_load_addr_left).w,a0 ; reset a0 subi.w #$80,d6 ; look even farther left (any object behind this is out of range) bcs.s + ; branch, if camera position would be behind level's left boundary - ; count how many objects are behind the screen that are not in range and need to remember their state cmp.w (a0),d6 ; is object's x position >= d6? bls.s + ; if yes, branch addq.w #6,a0 addq.w #1,a3 ; respawn index of next object going left bra.s - ; continue with next object ; ---------------------------------------------------------------------------
There's a couple of things you need to know before the game's object spawning makes sense. We've got our data structure that we're iterating over, the object layout; we've got the respawn table and the indexes/address into its entries to maintain; and we need to know which objects to spawn at a given time. Let's start with the last one. As you move through the level, the objects manager spawns objects that are within a certain distance to the screen, horizontally. Let's call this the spawn area. Relative to the current camera position, snapped to chunk coordinates (that's why we and the camera position with $FF80), the spawn area stretches from one chunk to the left of the camera's position to five chunks to its right. With this, the visible play area is surrounded by a spawn area roughly twice its width. The camera's y-position is completely irrelevant, which makes the spawn area infinitely tall. Next, let's look at the object layout. It is a one-dimensional sequence of object definitions, sorted by x-position. That last part is important. The spawn area is a horizontal range that represents the part of the level that we could consider active. In other words, this is the part of the level where we want to have objects spawned. Think of it as a window into the object layout. Every object whose x-position is between the left and right edges of the spawn area need to be spawned. Sorting the objects along the x-axis allows us to scan the object layout until we've found the objects closest to the spawn area's left and right edges. That's what the loops with the bls exit conditions do. Obj_load_addr_left and Obj_load_addr_right are pointers to the objects that we found by doing this. Note that the left object address is inclusive, while the right one is exclusive. That means the object pointed to by Obj_load_addr_left points to the first object that is inside the spawn area, while Obj_load_addr_right points to the first object that's beyond the spawn area. Now, every time the spawn area moves by at least one chunk width, we use those left or right object pointers to determine which objects to spawn. Assuming we moved right, that means we'll calculate the new right edge of the spawn area, and start iterating through the object layout starting at the right object pointer, and spawn everything that's within the spawn area's new position. After we're done, the right object pointer will again be on the first object beyond the spawn area. We then need to adjust the left object pointer iteratively, until it's pointing to the first object that's inside the new spawn area. Going left it's basically the same thing, except in the opposite direction. What I've explained here isn't shown in your code snippet, but it's important in understanding what the Init routine is doing. See, the Init routine is doing some prep-work, setting up the object pointers and last frame's camera position (Camera_X_pos_last) so that Main will then spawn everything inside the spawn area all at once. It sets up the right address to point the first object on the left that needs to be spawned, and the left address to something before that. It also sets Camera_X_pos_last to -1 (not shown in the code above) so that it will always look like the spawn area moved right. This means it will start with the right object pointer, which is currently pointing the the leftmost object inside the spawn area, and spawn objects until it goes past the spawn area's right edge. Meanwhile, the left object pointer gets adjusted to where it actually belongs. And there you have it. Obj_load_addr_left and Obj_load_addr_right are pointers that represent the objects on the left and right edges of the spawn area, or where to start spawning from once the camera moves far enough. Every time the spawn area moves, new objects are spawned and the pointers moved until they are on the edges of the spawn area again. I'm going to skip the respawn table and index/address for now since this has gone on long enough. If you've understood everything else I've explained here, then figuring out how that part works should be easy. Hope this helps.
Hi everybody! I have the question: How i can insert/port Sonic 2 SW beta music to Sonic 2 final? I need to port sound driver, or something? Thanks in advance
I've been experimenting around with the idea of an 'Original Mode' patch for The Return of Dr. Eggman that essentially makes the game near-identical to vanilla Sonic 2 (but containing the bug fixes and improvements from TRoDE), and I want feedback on whether I should go ahead with it. Below is a .zip file containing the ROM; ThumbsUp for 'yes' and Wrench for 'no'.
So.... I port the Sonic 2 Clone Driver, but now- music plays without FM-channels and DAC samples. Only PSG. Has anyone ever had this? Can anyone help me? File at bottom- example for music at this moment
I am often looking as the assembly code for Genesis Sonic games in an emulator. I'm looking for a way to bring back the lost symbols labels, expanded macros, etc during the assembly process. I can think of several possible ways. I will simplify it and focus on just he ASW assembler used for the Sonic3k Github and The Sonic 2 Dissasembly. Is there Emulators that can map things using the list file? Exodus? Is there extensions for emualtors that allow this. Could Ghidra let you use a list file to generate something that lets you active assembly and the labels? If above is impossible ( viewing live assembly with labels ), alternatively, could I just trace the part of code I am interested in. And then use a tool ( does it exist ) that uses the list and trace file to put the list files line of code beneath each raw trace line? For Example if your trace file was 1B5A0 70 00 MOVEQ #$00,D0 1B5A2 10 38 MOVE.B ($F76C),D0 1B5A6 4E FB JMP $02(PC,D0) It would use the trace file and list file to generate: 1B5A0 70 00 MOVEQ #$00,D0 36773/ 1B5A0 : 36774/ 1B5A0 : ; =============== S U B R O U T I N E ======================================= 36775/ 1B5A0 : 36776/ 1B5A0 : 36777/ 1B5A0 : Load_Sprites: 36778/ 1B5A0 : 7000 moveq #0,d0 1B5A2 10 38 MOVE.B ($F76C),D0 36779/ 1B5A2 : 1038 F76C move.b (Object_load_routine).w,d0 1B5A6 4E FB JMP $02(PC,D0) 36780/ 1B5A6 : 4EFB 0002 jmp loc_1B69A(pc,d0.w) Is there other methods? I know MDStudio.
I need some help, how can I remove the 2P mode from the GitHub disassembly of Sonic 2? The only modification I did so far is to add the S3K rings manager.
Quick question: I've noticed a strange bug where the camera gets delayed when going too fast in Sonic 1. Now I'm aware it's possible to fix it by setting the lower y-boundary x-axis in the resize subroutines but I've had little to no luck in getting them fixed after inserting that code. Does anyone know what occurs? If I do sound a bit blunt and you want me to provide some code, please let me know.
The camera in Sonic games scroll slower vertically when you're on ground (probably to make the camera smoother during loops and such), I don't have the code on hand but it sounds like you want to increase that speed (or remove the on-ground check entirely).
I managed to fix the bug myself upon further inspection. Unfortunately, since I shifted SSTs to port the S3K object manager, I forgot to change FFFFD014 to FFFFD020. This is the player's RAM plus the inertia after the shift.
Hello, my code isn't compiling. I added a advanced error handler and ported the S3 sound driver. What did I do wrong? I did everything as said in the page. The s2.log file is below. Code (Text): // LDebugger is from https://sonicresearch.org/community/index.php?threads/advanced-error-handler-and-debugger.4442/#post-78456 > > > LDebugger.asm(2) Console(24): warning: address is not properly aligned > > > move.w sr, -(sp) > > > LDebugger.asm(2) Console(25) __FSTRING_GenerateArgumentsCode(60) WHILE 1/32__FSTRING_PushArgument(51): warning: address is not properly aligned > > > move.w {__operand},-(sp) > > > LDebugger.asm(2) Console(25) __FSTRING_GenerateArgumentsCode(60) WHILE 2/32__FSTRING_PushArgument(51): warning: address is not properly aligned > > > move.w {__operand},-(sp) > > > LDebugger.asm(2) Console(26): warning: address is not properly aligned > > > movem.l a0-a2/d7, -(sp) > > > LDebugger.asm(2) Console(27): warning: address is not properly aligned > > > lea 4*4(sp), a2 > > > LDebugger.asm(2) Console(28): warning: address is not properly aligned > > > lea __data(pc), a1 > > > LDebugger.asm(2) Console(29): warning: address is not properly aligned > > > jsr ErrorHandler___global__console_writeline_formatted > > > LDebugger.asm(2) Console(30): warning: address is not properly aligned > > > movem.l (sp)+, a0-a2/d7 > > > LDebugger.asm(2) Console(34): warning: address is not properly aligned > > > addq.w #__sp, sp > > > LDebugger.asm(2) Console(36): warning: address is not properly aligned > > > move.w (sp)+, sr > > > LDebugger.asm(2) Console(37): warning: address is not properly aligned > > > bra.w __leave > > > s2.asm(799):1: error: symbol undefined > > > sndDriverInput > > > jsr (sndDriverInput).l > > > > > > s2.asm(11278):8: error: symbol undefined > > > Pal_FadeTo > > > bsr.w Pal_FadeTo > > > ~~~~~~~~~~ > > > s2.asm(12063):1: error: symbol undefined > > > Night_mode_flag > > > lea (Night_mode_flag).l,a1 > > > > > > s2.asm(85864) plreq(1):17: error: symbol undefined > > > ArtNem_Waterfall > > > dc.l ArtNem_Waterfall > > > ~~~~~~~~~~~~~~~~ > > > s2.asm(85865) plreq(1):17: error: symbol undefined > > > ArtNem_EHZ_Bridge > > > dc.l ArtNem_EHZ_Bridge > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(85866) plreq(1):17: error: symbol undefined > > > ArtNem_HtzFireball1 > > > dc.l ArtNem_HtzFireball1 > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85914) plreq(1):17: error: symbol undefined > > > ArtNem_MtzWheel > > > dc.l ArtNem_MtzWheel > > > ~~~~~~~~~~~~~~~ > > > s2.asm(85915) plreq(1):17: error: symbol undefined > > > ArtNem_MtzWheelIndent > > > dc.l ArtNem_MtzWheelIndent > > > ~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85916) plreq(1):17: error: symbol undefined > > > ArtNem_LavaCup > > > dc.l ArtNem_LavaCup > > > ~~~~~~~~~~~~~~ > > > s2.asm(85917) plreq(1):17: error: symbol undefined > > > ArtNem_BoltEnd_Rope > > > dc.l ArtNem_BoltEnd_Rope > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85918) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSteam > > > dc.l ArtNem_MtzSteam > > > ~~~~~~~~~~~~~~~ > > > s2.asm(85919) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSpikeBlock > > > dc.l ArtNem_MtzSpikeBlock > > > ~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85920) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSpike > > > dc.l ArtNem_MtzSpike > > > ~~~~~~~~~~~~~~~ > > > s2.asm(85934) plreq(1):17: error: symbol undefined > > > ArtNem_MtzAsstBlocks > > > dc.l ArtNem_MtzAsstBlocks > > > ~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85935) plreq(1):17: error: symbol undefined > > > ArtNem_MtzLavaBubble > > > dc.l ArtNem_MtzLavaBubble > > > ~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85936) plreq(1):17: error: symbol undefined > > > ArtNem_MtzCog > > > dc.l ArtNem_MtzCog > > > ~~~~~~~~~~~~~ > > > s2.asm(85937) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSpinTubeFlash > > > dc.l ArtNem_MtzSpinTubeFlash > > > ~~~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85981) plreq(1):17: error: symbol undefined > > > ArtNem_HtzFireball1 > > > dc.l ArtNem_HtzFireball1 > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85982) plreq(1):17: error: symbol undefined > > > ArtNem_HtzRock > > > dc.l ArtNem_HtzRock > > > ~~~~~~~~~~~~~~ > > > s2.asm(85983) plreq(1):17: error: symbol undefined > > > ArtNem_HtzSeeSaw > > > dc.l ArtNem_HtzSeeSaw > > > ~~~~~~~~~~~~~~~~ > > > s2.asm(85984) plreq(1):17: error: symbol undefined > > > ArtNem_Sol > > > dc.l ArtNem_Sol > > > ~~~~~~~~~~ > > > s2.asm(85997) plreq(1):17: error: symbol undefined > > > ArtNem_HtzZipline > > > dc.l ArtNem_HtzZipline > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(85998) plreq(1):17: error: symbol undefined > > > ArtNem_HtzFireball2 > > > dc.l ArtNem_HtzFireball2 > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85999) plreq(1):17: error: symbol undefined > > > ArtNem_HtzValveBarrier > > > dc.l ArtNem_HtzValveBarrier > > > ~~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(86052) plreq(1):17: error: symbol undefined > > > ArtNem_Crate > > > dc.l ArtNem_Crate > > > ~~~~~~~~~~~~ > > > s2.asm(86053) plreq(1):17: error: symbol undefined > > > ArtNem_MCZCollapsePlat > > > dc.l ArtNem_MCZCollapsePlat > > > ~~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(86054) plreq(1):17: error: symbol undefined > > > ArtNem_VineSwitch > > > dc.l ArtNem_VineSwitch > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(86055) plreq(1):17: error: symbol undefined > > > ArtNem_VinePulley > > > dc.l ArtNem_VinePulley > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(86066) plreq(1):17: error: symbol undefined > > > ArtNem_MCZGateLog > > > dc.l ArtNem_MCZGateLog > > > ~~~~~~~~~~~~~~~~~ > > > LDebugger.asm(2) Console(24): warning: address is not properly aligned > > > move.w sr, -(sp) > > > LDebugger.asm(2) Console(25) __FSTRING_GenerateArgumentsCode(60) WHILE 1/32__FSTRING_PushArgument(51): warning: address is not properly aligned > > > move.w {__operand},-(sp) > > > LDebugger.asm(2) Console(25) __FSTRING_GenerateArgumentsCode(60) WHILE 2/32__FSTRING_PushArgument(51): warning: address is not properly aligned > > > move.w {__operand},-(sp) > > > LDebugger.asm(2) Console(26): warning: address is not properly aligned > > > movem.l a0-a2/d7, -(sp) > > > LDebugger.asm(2) Console(27): warning: address is not properly aligned > > > lea 4*4(sp), a2 > > > LDebugger.asm(2) Console(28): warning: address is not properly aligned > > > lea __data(pc), a1 > > > LDebugger.asm(2) Console(29): warning: address is not properly aligned > > > jsr ErrorHandler___global__console_writeline_formatted > > > LDebugger.asm(2) Console(30): warning: address is not properly aligned > > > movem.l (sp)+, a0-a2/d7 > > > LDebugger.asm(2) Console(34): warning: address is not properly aligned > > > addq.w #__sp, sp > > > LDebugger.asm(2) Console(36): warning: address is not properly aligned > > > move.w (sp)+, sr > > > LDebugger.asm(2) Console(37): warning: address is not properly aligned > > > bra.w __leave > > > s2.asm(90083):66: error: symbol undefined > > > movewZ80CompSize > > > shared word_728C_user,Obj5F_MapUnc_7240,off_3A294,MapRUnc_Sonic,movewZ80CompSize > > > ~~~~~~~~~~~~~~~~ Help would be appreciated. Thanks!
Code (Text): warning: address is not properly aligned I think the advanced error handler is included in the ROM right after the Sonic 3 sound driver stuff. Put this line in right before the include of the error handler: Code (Text): even The 68k cannot process instructions (or any data) that are on an odd address. Normally instructions are always aligned to even addresses, and the instructions themselves are a multiple of 2 bytes in size, ensuring all instructions one after another always start on an even address. However, I assume installing the Sonic 3 sound driver either has a load of binary includes or dc.b's and they are ending on an odd address, and so the instructions of the debugger are starting on an odd address. The "even" directive will insert an extra byte if the address is odd, forcing the instructions to an even address for you, and resolving both the warning message and the potential address error of the CPU.
Thanks @MarkeyJester ! I did what you said and now there are only the symbol undefined errors. How can I fix those? I think while installing the sound driver, some art data got left or something? I don't know how to fix it though, I'm really new to ASM stuff. Here's the s2.log now: Code (Text): > > > s2.asm(799):1: error: symbol undefined > > > sndDriverInput > > > jsr (sndDriverInput).l > > > > > > s2.asm(11278):8: error: symbol undefined > > > Pal_FadeTo > > > bsr.w Pal_FadeTo > > > ~~~~~~~~~~ > > > s2.asm(12063):1: error: symbol undefined > > > Night_mode_flag > > > lea (Night_mode_flag).l,a1 > > > > > > s2.asm(85864) plreq(1):17: error: symbol undefined > > > ArtNem_Waterfall > > > dc.l ArtNem_Waterfall > > > ~~~~~~~~~~~~~~~~ > > > s2.asm(85865) plreq(1):17: error: symbol undefined > > > ArtNem_EHZ_Bridge > > > dc.l ArtNem_EHZ_Bridge > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(85866) plreq(1):17: error: symbol undefined > > > ArtNem_HtzFireball1 > > > dc.l ArtNem_HtzFireball1 > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85914) plreq(1):17: error: symbol undefined > > > ArtNem_MtzWheel > > > dc.l ArtNem_MtzWheel > > > ~~~~~~~~~~~~~~~ > > > s2.asm(85915) plreq(1):17: error: symbol undefined > > > ArtNem_MtzWheelIndent > > > dc.l ArtNem_MtzWheelIndent > > > ~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85916) plreq(1):17: error: symbol undefined > > > ArtNem_LavaCup > > > dc.l ArtNem_LavaCup > > > ~~~~~~~~~~~~~~ > > > s2.asm(85917) plreq(1):17: error: symbol undefined > > > ArtNem_BoltEnd_Rope > > > dc.l ArtNem_BoltEnd_Rope > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85918) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSteam > > > dc.l ArtNem_MtzSteam > > > ~~~~~~~~~~~~~~~ > > > s2.asm(85919) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSpikeBlock > > > dc.l ArtNem_MtzSpikeBlock > > > ~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85920) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSpike > > > dc.l ArtNem_MtzSpike > > > ~~~~~~~~~~~~~~~ > > > s2.asm(85934) plreq(1):17: error: symbol undefined > > > ArtNem_MtzAsstBlocks > > > dc.l ArtNem_MtzAsstBlocks > > > ~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85935) plreq(1):17: error: symbol undefined > > > ArtNem_MtzLavaBubble > > > dc.l ArtNem_MtzLavaBubble > > > ~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85936) plreq(1):17: error: symbol undefined > > > ArtNem_MtzCog > > > dc.l ArtNem_MtzCog > > > ~~~~~~~~~~~~~ > > > s2.asm(85937) plreq(1):17: error: symbol undefined > > > ArtNem_MtzSpinTubeFlash > > > dc.l ArtNem_MtzSpinTubeFlash > > > ~~~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85981) plreq(1):17: error: symbol undefined > > > ArtNem_HtzFireball1 > > > dc.l ArtNem_HtzFireball1 > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85982) plreq(1):17: error: symbol undefined > > > ArtNem_HtzRock > > > dc.l ArtNem_HtzRock > > > ~~~~~~~~~~~~~~ > > > s2.asm(85983) plreq(1):17: error: symbol undefined > > > ArtNem_HtzSeeSaw > > > dc.l ArtNem_HtzSeeSaw > > > ~~~~~~~~~~~~~~~~ > > > s2.asm(85984) plreq(1):17: error: symbol undefined > > > ArtNem_Sol > > > dc.l ArtNem_Sol > > > ~~~~~~~~~~ > > > s2.asm(85997) plreq(1):17: error: symbol undefined > > > ArtNem_HtzZipline > > > dc.l ArtNem_HtzZipline > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(85998) plreq(1):17: error: symbol undefined > > > ArtNem_HtzFireball2 > > > dc.l ArtNem_HtzFireball2 > > > ~~~~~~~~~~~~~~~~~~~ > > > s2.asm(85999) plreq(1):17: error: symbol undefined > > > ArtNem_HtzValveBarrier > > > dc.l ArtNem_HtzValveBarrier > > > ~~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(86052) plreq(1):17: error: symbol undefined > > > ArtNem_Crate > > > dc.l ArtNem_Crate > > > ~~~~~~~~~~~~ > > > s2.asm(86053) plreq(1):17: error: symbol undefined > > > ArtNem_MCZCollapsePlat > > > dc.l ArtNem_MCZCollapsePlat > > > ~~~~~~~~~~~~~~~~~~~~~~ > > > s2.asm(86054) plreq(1):17: error: symbol undefined > > > ArtNem_VineSwitch > > > dc.l ArtNem_VineSwitch > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(86055) plreq(1):17: error: symbol undefined > > > ArtNem_VinePulley > > > dc.l ArtNem_VinePulley > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(86066) plreq(1):17: error: symbol undefined > > > ArtNem_MCZGateLog > > > dc.l ArtNem_MCZGateLog > > > ~~~~~~~~~~~~~~~~~ > > > s2.asm(90083):66: error: symbol undefined > > > movewZ80CompSize > > > shared word_728C_user,Obj5F_MapUnc_7240,off_3A294,MapRUnc_Sonic,movewZ80CompSize > > > ~~~~~~~~~~~~~~~~ I'll also link the S2.asm, just in case. https://www.mediafire.com/file/dz4tvoib7078zwl/s2.asm/file
According to the SCHG I believe you've been following, the guide says you need to remove all calls/references to "sndDriverInput", and included a list of labels to go to: VintSub0 Loc_54A Vint0_noWater (only touch the " bsr.w sndDriverInput ; give input to the sound driver" line) loc_748 (only touch the " bsr.w sndDriverInput ; give input to the sound driver" line) Vint10_specialStage (only touch the " jsr (sndDriverInput).l) loc_92A+++++ (only touch the " jsr (sndDriverInput).l) - - - - - - - - - - - - THIS ONE HERE loc_BD6 (only touch the " jsr (sndDriverInput).l) VintSub18 (only touch the " bsr.w sndDriverInput) VintSub16 (only touch the " bsr.w sndDriverInput) Loc_EFE (only touch the " bsr.w sndDriverInput) It looks like you've missed one, according to your s2.log, it's on line 799, remove it. The Pal_FadeTo is a very old label, if you try to search it in the source code you'll find: Code (Text): ; --------------------------------------------------------------------------- ; Subroutine to fade in from black ; --------------------------------------------------------------------------- ; ||||||||||||||| S U B R O U T I N E ||||||||||||||||||||||||||||||||||||||| ; sub_23C6: Pal_FadeTo: Pal_FadeFromBlack: The labels "sub_23C6" and "Pal_FadeTo" have been commented out with ";", these are the old labels for this subroutine. The actual label name is "Pal_FadeFromBlack". Change "Pal_FadeTo" to "Pal_FadeFromBlack" on the instruction "bsr.w Pal_FadeTo". The Night_mode_flag again I would assume is an old label, the newer label will be called something different now.... ...it seems to me the SCHG guide you're using is also using older labels, so it's not compatible with the disassembly you're using. You're going to have to look up what all of the old labels are and swap them. As for the art labels, it seems you've deleted all of the includes for all of the art files, I don't quite know how that's happened, either you've accidentally done it by mistake, or (most likely) the guide is outdated enough.
@MarkeyJester Also, yep, it was the SCHG. Code (Text): + move.w d0,(Sound_test_sound).w andi.w #button_B_mask|button_C_mask,d1 beq.s + ; rts move.w (Sound_test_sound).w,d0 ;addi.w #$80,d0 ;<-- remove this line bsr.w JmpTo_PlayMusic lea (debug_cheat).l,a0 lea (super_sonic_cheat).l,a2 lea (Night_mode_flag).w,a1 <-------- there it is moveq #1,d2 ; flag to tell the routine to enable the Super Sonic cheat bsr.w CheckCheats + I sometimes see things like "Fixed by x" after the "Guide by x". How do people edit the pages? I am sorry for the ping by the way...
You're welcome. Information about editing the wiki can be found here, you'll have to carefully read through though and make sure you know the rules, etiquette, etc...