1. Is there any way to set up a separate SonED file for just the 2p vs version of a level similar to the CNZ files? 2. Anyone know how to turn off the earthquake objects in Hill Top Zone? 3. I am curious to what the Path Swapper objects do specifically? When I take them out they don't seem to have any specific effect, however when played in split screen they actually seem to keep some objects from loading unless they're removed.
2 player uses its own set of objects I'm pretty sure, it's finicky. Earthquake is handled by level events, as well as the objects placed in the level. Path swappers do a lot, they switch you from plane A to B, as well as (I'm pretty sure, not positive) set your sprite priority(?). There's nothing worse than falling through or into something when you're not supposed to.
Pathswappers don't change your "plane", Plane A and Plane B are the foreground and background respectively, and obviously you're never walking on the BG. Whenever you cross over a path swapper, several things can happen depending on the bits in the subtype and the direction you crossed it. It can make Sonic switch from path 0 to path 1 (path 1 and 2 in SonLVL), and/or change his sprite priority so he appears on top of or underneath high priority foreground art. If you use the W and E keys to view solidity for paths 0 and 1, you'll see that most loops are not solid on the left side in path 0, and not solid on the right side in path 1. The pathswapper in the middle of the loop switches Sonic to path 0 if he's moving right, and path 1 if he's moving left. SonLVL also reveals that it only does this if Sonic's on the ground when he passes through the object, so you can't just jump through it and not do the whole loop. As for separate 2P object layouts, you'd have to change the game's object layout loading so it loads different files in 2P mode, then copy your soned2 project files and change the object file they load.
I meant paths...It's been a while since I've done any editing :v Apologies for brain derp. Actually, Hill Top's earthquake moves chunks of the BG to where the earthquake is. So you do essentially walk on BG tiles. But you don't need planes for this afaik.
Is there a chance someone well versed with Z80 could help me with porting the Sonic 3 driver to my 32X port of Sonic 1? I can port the driver to vanilla Sonic 1 just fine, however, when running on the 32X the ROM is mapped from $880000 instead of $0. Ordinarily, this wouldn't be an issue since the Z80 can access the entire 68k memory space, however, the Sonic 3 driver only stores bank pointers in a byte, meaning it cannot address higher than $7F8000. I understand I will have to modify the data tables to use words instead of bytes for the bank register, and also update the bank switch macros to use a 16-bit register, such as BC or DE instead of A. This would double the size of the pointer tables meaning they will no longer fit in Z80 ram. I am not very familiar with Z80 assembly, so I would like some help in relocating these tables to ROM to free up some space. If it means anything, I'm using the latest hg disassembly of Sonic 1, and the smps2asm supporting Sonic 3 driver. Any advice that may simplify this process would be great.
Having a bit of a strange issue here. Using this guide, I started the music index at 00 instead of 80, and moved all the game's vanilla songs to 01, 02, et cetera. I then changed every instance of every song being called by the game (ie move.w #$89,d0) to reflect their new pointers, and even edited muslist1.bin (muslist2.bin is never used by the game, so I didn't mess with it). But then I recently noticed that getting two 1ups at once, and then having any other sound play would cause a crash. I discovered there was a single instance of #$88 being checked on d7 instead of d0, so I changed it to #$08. Now, while the crash has been fixed, any time you get a 1up, the level music never comes back (until you get invincibility or start a new act or something similar). Anyone familiar with this issue? EDIT: Quoting this guy just because I posted at the same time as him and started a new page.
Looks like I posted for help too soon. I managed to clear a decent amount of space by removing the DAC pointer table completely. I modified the Bank switch macros to take BC as input rather than A, and extended the music and sfx pointer tables to word length. This will not cause future problems as the 32X will be using the Slave-SH2 for PWM completely replacing DAC. (The 68k reads the DAC channel from the Z80 RAM, forwards it to the 32X communication registers).
You're thinking too compilcated. You don't need larger bank registers and tables at all. Instead you need to modify all 4 bankswitch macros and force the banks to be $800000+. Just replace Code (ASM): xor a ; bank bit 23 will be 0 with Code (ASM): ld a, 1 ; bank bit 23 will be 1 That's like Chaotix does it IIRC. I discussed that problem recently with Caverns4, who had the same problem. It happens because of the hackish way the sound index extention works. The second 1-up is cancelled before the "use index 00-7F"-byte is reset and so when the next sound effect is played, it assumes that to be music and reads an invalid song pointer. 1. That check against #$88 checks if the song is the 1-up and makes a save state of the current music in this case. This index is the sound ID of the 1-up jingle and always 80+ btw, so by changing it to $08 you made it useless, so it will be handled like any other music. Change it back to ($80+Your1upMusicID) first. 2. In order to fix the actual bug, insert a clr.w command after under the loc_721B6 label (@locdblret in HG disasm) Code (ASM): L_locdblret: ;loc_721B6 clr.w ($FFFFFFFC).w ; fix "playing 1-up while 1-up is playing" addq.w #4,sp ; Tamper with return value to not return to caller rts and it should work.
I see... So that needs to remain $88... But that raises an interesting question: What if I eventually have something on $88? Wouldn't it play that instead? Not that I'll probably ever have anything there, what with having 134 free slots before that and 25 or whatever free slots in the upper extension, but IF I ever did have anything on $88... I guess the simple solution would just be to toss the 1up sound back in the 80s, so it doesn't complain. By the way, your fix worked just great. Thanks. Can't believe I spent all night and all day and all night again trying to come up with a fix, and the fix was literally a single line of code. I had even looked directly at loc_721B6, but I didn't know what to do with it if anything. EDIT: Sorry if I seem a bit noobish, I just want to understand how and why everything works. I always used to be a copy/paste coder, and I'm tired of not being able to come up with my own stuff, so I'm trying my best to actually learn now.
There's a difference between what it plays and what it thinks that it plays. With the current sound index extention, everything gets converted to 80-FF plus either FFFC or FFFD is set to 1 (or both are 0). Here's a quick table: Code (Text): IdxP IdxI FC FD 00-7F 80-FF 01 00 80-E4 80-E4 00 00 E5-FF 81-9B 00 01 IdxP - index passed to PlayMusic/Sound IdxI - internal index when jumping to the routine that actually starts the music (Sound_81to9F) FC/FD - value stored at RAM Offset FFFC/FFFD when jumping to Sound_81to9F So if you check for $88 without checking the value of FFFC/FFFD, too, it will assume that all songs with IdxI = $88 are 1-up songs and make a save state of the current song. The decision which song is really played is done later and independently from the 1-up song mode. If your 1-up song has ID $08 (IdxP), it is no problem to check for $88 (IdxI), but the check will be true for $88 and $EC (IdxP), too. It doesn't matter unless you put songs into these slots though. I had a look at the sound extention guide for the S2 Clone Driver recently (which has the same problem), so I knew the bug already. But I need to admit, it took me a while to figure out that it forgets to reset the FFFC/FFFD bytes after skipping a 1-up. (Finding the reason for a bug is more difficult than finding a fix for it most of the time.) No need to be sorry. Trying to learn is a very good attitude, IMO.
Oh, I see how it works now. That seems very hackish indeed. I had wondered, in the past, why putting songs on the 00 values and then calling for an 80+ value in the ASM would still call those songs. This answers that.
I'm planning on porting a custom BG for the (S1) special stage and it's a modified version of the Knuckles Chaotix bonus stage BG. It's gonna be animated, and it consists of 12 frames, meaning it might require palette cycling and making separate palettes for each BG. It consists of a six-shade circular gradient on a single layer with the primary BG color on the bottom plane. So how I would I break this down into chunks before loading? And where does mappings and animations come into play? And another thing, since I made one for each stage, how do I designate each BG and palette to the correct stage? EDIT: Previous question answered My S1 hack has seven special stages in it, and I am making separate palettes for each stage because even though each stage will use the same BG design, it's just gonna have different colors per stage. Is it possible where I can make each individual stage load its own palette? Like, I'm gonna have seven different "special" palette files, naming them "special1" and "special2" and so forth.
I'm trying to make it so a banner I've added to the Sonic 2 title screen doesn't appear till after Sonic (and thus his pallette) have appeared, since he's linked to everything in Obj0E, anyone know a specific branch to go about this?
okay, I've been having an odd bug that I don't really know how to explain. In Sonic 2, I've been trying to make an adjustment to the Buzzer's code, where it won't stop and shoot 1: if you're about it, and 2: when you're too far below (To avoid the obnoxious and sometimes unfair fireballs flying in unexpectedly from off-screen). Here's what I did them made them stop shooting when the player is above: Code (Text): Obj4B_ChkPlayers: tst.b Obj4B_shooting_flag(a0) bne.w return_2D232 ; branch, if shooting is disabled move.w x_pos(a0),d0 move.w y_pos(a0),d2 lea (MainCharacter).w,a1 ; a1=character btst #0,(Vint_runcount+3).w beq.s + ; target Sidekick on uneven frames lea (Sidekick).w,a1 ; a1=character + ;Do a check for the player's y position. sub.w y_pos(a1),d2 ;Subtract the players y position from the Buzzer's cmpi.w #$0,d2 ;Compare the result to $0 bgt.s return_2D232 This works great, even instinct told me it should've been ble.s... With that said, tried an addition check for if the player is too low, and it flat out doesn't work: Code (Text): cmpi.w #$70,d2 ;Now make sure the player isn't too far below. blo.s return_2D232 ;If they are, branch. What the heck is going on here?
Hello there! Two questions, actually. First, I was wondering, is there any good software (assemblers/compilers/etc.) dedicated to the Dreamcast VMU? I actually found an simple assembler, disassembler, and an emulator w/source code for it. Through some more digging I also found out about a high level assembler called LIME, but the DL link is deeeeeead. I don't suppose anyone has a copy anywhere. Secondly, is there any good documentation about the VMU firmware? Many thanks, it's very much appreciated! Edit: Wrong thread for this. Sorry about that!
Making the '$70' a '$-70' both fixed the bug and made the 'cmpi.w #$0,d2' and following branch redundant. I must be lucky or doing something horribly wrong. Allow me to provide my thought process: So, the code detecting if the player is above the Bomber literally means "Compare (Immediately) Main Character's y_pos to $0 (also 0 in decimal) (which is relative to Bomber, essentially making this Bomber's Y origin), branch if Main Character's y_pos is greater than $0 (Bomber's Y origin)." So, this should work, and it does. The code detecting if the player is a screen below reads "Compare (Immediately) Main Character's y_pos to $70 (but if this is the y-axis, shouldn't positive numbers mean higher on said axis, not lower, meaning that $70 is literally above $0, and therefore the Bomber?), branch if Main Character's y_pos is lower than $70 relative to Bomber." This, to my understanding, is wrong, spoken in the comments above; the coordinate that's intended to be below the Bomber is instead above. So, naturally, I correct what I perceive as an error, and following that, my logic both proves and contradicts itself: The check now works, better than expected even, because while the Bomber won't shoot if the player's a screen below it, the Bomber won't shoot if the player's above it either, even though the code for detecting that doesn't exist (I commented it out, yes, I'm sure I did it correctly). I have few ideas on why the above check now works without any code explicitly doing so; the one idea I do have is that the 'immediate' part of cmpi creates a trade off of range for speed, meaning that maybe cmpi can't check for numbers in the negative region (or in this case, as the compare begins in the negatives, maybe it can't check the positives)? Anyone with better know-how on these variables, please, do make this clear for us. EDIT: Tried cmp, no 'I' this time, same problem, I'm lost. EDIT2: Nevermind, I'm an idiot. Thanks Vladikcomper, for clearing up that the "I" doesn't mean "process immediately", it means "use immediate data".
CMPI actually stands for Compare Immediate, which refers to immediate data as one of the addressing modes that the Motorola 68000 processor provides. This addressing mode means the data is specified immediately in the instruction as opposed to addressing modes that tell the processor to fetch data from a memory address or a register. CMPI is forced anyways if you specify the source operand as immediate data, which means... Code (Text): cmp.w #$70,something ...will be converted to CMPI automatically during assembling. And as processor uses two's complement to represent numbers, there's absolutely no difference for arithmetical operations (CMP, ADD, SUB) whether the number is signed or unsigned (the exception is multiply and divide instructions, which are actually divided into two groups: DIVS, MULS for signed and DIVU, MULU for unsigned). In fact, the result they produce will be correct for either forms and it's up to you to decide if you want to treat it as signed or unsigned. In your particular example, it's branch what makes the difference between two forms. BGT is signed group of branches, used if you want to treat the result of an arithmetical operation in signed form.
Okay, I still haven't really resolved the issue with the Buzzer's, but more on that later assuming I don't figure it out. For some data reference and educational purposes, I threw a builder(the one from Sonic 1-two eight) into Esrael's disassembly of the Simon Wai prototype of Sonic 2.. However, for multiple reasons, it refused to build. I have gotten the Nick Arcade Prototype to build with minimal issue befor, but I can't get the Wai prototype to build... Does anyone know how I can fix this?
I was using Esrael Sonic Editor 2 to edit the 16x16 tiles, but it didn't save, even though I clicked save level when I finished. Am I doing something wrong?
Yes, you're using a ROM editor in this day and age. http://info.sonicret...g/Disassemblies Use one of these and Sonlvl (or Soned2, but I don't recommend it). You're really better off using a disassembly even for minor modifications, it's less subject to problems. Also, I'm having an issue that may require a little more personal help; I tried porting the first boss from Sonic 1(Into Sonic 2), and the boss works, but the wrecking ball doesn't: If anyone knows about working with objects on a higher level and is willing to help me figure out what's up, please let me know.
