Basic Questions and Answers Thread

Yep, unfortunately that code OuricoDoido is presenting a tutorial on is lifted straight from Megamix. He condensed it to make it look like he coded it himself, but quite a few people have confirmed that it is indeed stolen. If you see anything related to ASMtoSegaGenesis, it's definitely something you should run away from really fast.

If you're looking to code it for yourself, Markey's conceptual information is probably the best guide to start off of. If I were you, I'd check out the game's code to see how calcsine and calcangle are used in context. I created a homing attack of my own a while back and did so after looking into how calcsine and calcangle worked, figuring out how to load a given object in object RAM to a register and figuring out how to determine information about that particular object. 

 

Alright, so I've been working quite some time today on porting Tails' Tails to Sonic 1, and I have a problem. I've been trying to fix the code up and polish it to an atleast playable state so I can see how I'm doing, but I'm running into a problem. When I try to build the ROM, I get tons of errors claiming to have "Illegal Values", but when I change them and they look fine, I still get the same errors! What do you think I'm doing wrong?

(NOTE: The "Illegal Values" are all essentially labels, although some are the names of the animations at the end of the Object.)

 

Do you mind giving a few examples of those errors you love so much? I think I know how to solve your issue.

 

Sure thing.

F:TAILS THINGSONIC1.ASM<25272> : Error : Illegal value <87582>

This is the first among about 13. :

 

That is likely a branching error. What that is basically saying, is that the code in sonic.asm on line 25272 cannot reach the specified routine/ label as it is. Luckily, these are mostly easy to fix; if there is a "bsr" or a "bra" command on said line, change it to a jsr (jump) command, which can move much further distances than normal branches. However, since there are no conditional jump commands, commands like beq and bne need to branch to routines that jump to where it needs to go. A while back, Selbi made a Basic Error Fixing Guide, that goes into much greater detail on this.


Edit: I forgot to add, that any command with a .s address (i.e. bne.s) can also be changed to .w, to allow it to move further.

 

EDIT: Nevermind. Thank you TheInvisibleSun!

 

Try changing the dc.w command to dc.l so it's using a longword address.


Are all of those errors pointing commands like that?

 

No, sorry. I have it fixed now.

Well, sort of. You see, the ROM finally builds! Yay! But, well, as always, there's something wrong. When I load up a level and try to preform any action, I recieve this screen:



Anyone mind explaining what this exactly means? And possibly, what the heck I'm doing wrong?

 

Can you send me the code for Tails so I can see what's wrong? I'll compare it to Sonic's code to see differences and such. Might as well send me Tails' tails code, just in case.

 

I've sent it to you, so good luck.

 

Thanks. I PM'd you the problem and solution. The problem is that you are using things from Sonic 2 that aren't in Sonic 1, thus making the game 'confused' and it crashes. I also fixed the loading of the tails for you too.

 

I've been going through several topics trying to figure out the (I guess not so basic) answer to the question: How do I find free VRAM space to load art into? The VDP questions topic and documentation is kinda hard to wrap my head around fully, but I think it'll start to make more sense down the line if I keep looking at it while going between various topics and advice like the music editing guides did.

So, for the time being, just to work with Tails' tails and move on, I've commented out the location for the art that makes the points display when you kill an enemy since that's the least graphically intrusive.

But I do have a couple of other questions.

First question (this one has been bugging me for a while): In LoadSonicDynPLC:


LoadSonicDynPLC: ; XREF: Obj01_Control; et al
moveq #0,d0
move.b $1A(a0),d0 ; load frame number
cmp.b ($FFFFF766).w,d0
beq.s locret_13C96
move.b d0,($FFFFF766).w
lea (SonicDynPLC).l,a2
add.w d0,d0
adda.w (a2,d0.w),a2
moveq #0,d1
move.b (a2)+,d1 ; read "number of entries" value
subq.b #1,d1
bmi.s locret_13C96
lea ($FFFFC800).w,a3
move.b #1,($FFFFF767).w

What is "$FFFFF766" and "$FFFFF767" exactly? It's in both his Sonic 1 and Sonic 2 DPLC section and nowhere else. Tails and his (Obj05) Tails use "$FFFFF7DE" and "$FFFFF7DF" respectively in their DPLC for Sonic 2 and S2 Nick Arcade, but that doesn't work in Sonic 1... I have to use the addresses for Sonic but I don't actually know why.

I thought it was just free RAM space at first since it's there's no description of it in the RAM editing table for Sonic 1, but when I tried to use a different "free" address space (like $FC80-$FCFF for example) the art won't show up in the game. So If I wanted both characters in there at the same time (like in Sonic 2) there would be conflict. Now I don't if that's just impossible in Sonic 1, but for the sake of understanding, why do I seemingly have to use $F766 (or I guess anything between $F766-$F76B)?

Second question: I borrowed code from the 3rd spindash tutorial, since it's the only other thing I saw that loads in a another object with a character that I could understand (it could come back and bite me later since neither character has a spindash implemented yet OR I could just be like fuck spindashes) and I have Tails' tails mostly working as of tonight except for the animations when he's pushing something or skidding and I'm not sure what's missing.

Initially the animation for his directional tails (while he's curled up into a ball) wasn't displaying either until I included the code from Sonic 2 that references it (labeled TAnim_Push for some reason... that doesn't make sense).

Now, in the Obj05AniSelection section, when I change either of those two to something else (like changing from 8 or 9 to 7 for the Obj05Ani_spindash tails animation), it'll display that animation while he's pushing or skidding but not when it's set to what it's supposed to display. Any idea on how to correct this? The code for those two animations does seem to be correct as far as I can tell btw:

Code:

Obj05Ani_Skidding:	dc.b   2,$87,$88,$89,$8A,$FF
Obj05Ani_Pushing:	dc.b   9,$87,$88,$89,$8A,$FF

 

There is no direct way of finding free VRAM, but I can offer a method. At "loc_37B6:" you'll find:

move #$2700,srDirectly after that line, put this in:

Code:

		lea	($C00004).l,a6				; load VDP address port to a6
		moveq	#$01,d5					; prepare value to check for DMA finish
		move.l	#$8F019780,(a6)				; set increment mode & DMA source
		move.l	#$94FF93DF,(a6)				; set DMA size
		move.l	#$40200080,(a6)				; set DMA destination
		move.w	#$FFFF,-$04(a6)				; fill location with FF

Level_WipeVRAMWait:
		move.w	(a6),d0					; load Data
		btst	d5,d0					; has it fully cleared yet?
		bne	Level_WipeVRAMWait			; if not, loop
		move.w	#$8F02,(a6)				; set increment mode to normal
		moveq	#$00,d0					; set to reload the HUD/Ring patterns
		bsr.w	LoadPLC2				; ''

Level_WaitPLC:
		move.b	#$04,($FFFFF62A).w			; set v-blank routine
		bsr.w	DelayProgram				; wait for v-blank
		bsr.w	RunPLC_RAM				; allow PLC to function
		tst.l	($FFFFF680).w				; are there any PLC items to load?
		bne.s	Level_WaitPLC				; if so, loop until finished

What this will do is fill the entire VRAM space from 0020 to FFFF with the value F. Then, any level/object graphics will load into VRAM overwriting the F's. Any free space in VRAM will be left filled as F.
Certain emulators allow you to dump VRAM to a file, or even view VRAM. If neither is possible for you, then another option is making a gsx savestate and erasing the first 00012478 bytes. That'll leave you with the VRAM data, and then you can open that with a tile editor/viewer.

What you'll be looking for (if using Sonic's Sonic 1 palette), is pure yellow tiles. Those yellow tiles will be the F values, i.e. your free RAM space.

As for your first question:

F766 is a frame ID storage space. It'll save the current frame ID Sonic is displaying to that RAM space, and load his art. Then, the next time it comes into that routine, it'll compare Sonic's frame ID with the ID stored in that RAM space. If they match, then Sonic's frame hasn't changed, so there's no need to load his art as it's already loaded. If they don't, Sonic's new frame ID is saved, and the new frame of art is loaded. It's designed to prevent loading the same frame of art if it's already loaded (saving you processing time).

F767 is the transfer flag. When that RAM space is not 00, it'll transfer the art from RAM to VRAM for display:

Code:

		tst.b	($FFFFF767).w
		beq.s	loc_D50
		lea	($C00004).l,a5
		move.l	#$94019370,(a5)
		move.l	#$96E49500,(a5)
		move.w	#$977F,(a5)
		move.w	#$7000,(a5)
		move.w	#$83,($FFFFF640).w
		move.w	($FFFFF640).w,(a5)
		move.b	#0,($FFFFF767).w

Again, same thing, if the RAM space is 00, then the software knows not to transfer and update the art.

 

I have a question.
 
Ok, I have this problem in Labyrinth Zone with the title card. It glitches up like this:



I have no idea what I did wrong. Every other title card does fine, but the one for Labyrinth doesn't!

 

Alright, now that I've been approved to be a member, guess who needs help!

Except, well, this is a continuation of an earlier question. This question to be exact:

Well, Ralakimus helped me out through PM and fixed the parts in the code where I had referenced to Sonic 2. I understand, and honestly, feel like an idiot. -.-

But, now that it's fixed...

The exact same thing happens, as shown above. It just crashes, and gives me the same Illegal Instruction error.

I've been looking over this code over and over, but I can't figure this one out.

So, any thoughts?

(And, I'm sorry if I'm being annoying here. I just have many questions.)

 

Send me a copy of your ROM, and I'll debug it.

Put this in directly after the code in my previous post:

Code:

move	#$2700,sr				; disable interrupts

"DelayProgram" enables the interrupts to allow the art for the PLC to be transfered. When it came out and went to load the title card art, the interrupts were still enabled, so v/h-blank would have interrupted the art decompression and changed the VDP mode/address.

 

Thanks! The title card is fine! But there's another problem similar to it, though.

Whenever I go into Spring Yard Zone Act 2 or Scrap Brain Zone Act 3, there is an object the loads the art with the yellow tiles, but after 1 second after the screen fades, the correct art loads correctly:



It appears that the button and springs are yellow tiles. But then one second later:

 

It's all fine! What's going on?

 

OK. The reason why the game crashes, is because the game is trying to load invalid objects that are loaded into the object RAM. Such as object BB for example. After looking in RAM, I can see the object RAM flooded with a load of B's, C's, D's, E's and F's, which appear to look like pattern data (i.e. sprite art).

It just so happens that this sprite art is Tails' sprite art (including his tails). What's happening is, because Tails (and his tails) art is together pretty big. It cannot fit into the small RAM buffer space provided at C800 - CBFF, so it spills out of that space and into CC00+ where the scroll buffer is, and even further into D000+ where the object RAM is. Sonic's art could fit, but it seems that some of Tails' frames (and his tails) are too big for that buffer space.

Sonic 1's method of loading the art from ROM to RAM, and then transferring from RAM to VRAM isn't suitable for large sprites. So, you'll need to look into another method of loading his sprite art into VRAM. Everyone would by now probably recommend you to use Sonic 2's method of transferring the art across, and I'd agree.

 

That's because the PLC system takes time to load the spring and button art. If you play the original Sonic 1 game and go into those levels from the level select (in a fresh game), and go frame by frame while the level is loading, you'll see the spring and buttons are not loaded yet. But, you just don't notice it. The yellow art is more noticeable than the transparent art. There's nothing you can do except possibly moving the spring art closer to the top of the PLC list, or into a list that loads sooner.

That routine is there for debugging purposes only, not for in-game functioning. When you're ready to release your project, simply remove the code or comment the routine out.

 

Oooohhh, OK. I see it now. I'll see into fixing that if I can. Thanks!

EDIT: All fixed! Thanks!