Sonic and Sega Retro Message Board: Basic Questions & Answers thread - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

Basic Questions & Answers thread NEWBIES: Start here!

#5071 User is offline RandomAvatarFan 

Posted 27 February 2014 - 02:43 PM

  • Sonic Slide and Punch!
  • Posts: 100
  • Joined: 27-June 08
  • Gender:Male
  • Project:Yozora
  • Wiki edits:15
Well, that was a stupid mistake on my part, and I'm embarrassed, thank you.

Now that I have all those changes within the programs, I still can't get it to worked.

After I applied all the fixes in the guide, it still doesn't build; the batch file is looking for the ASM68k application.


I tried transferring the ASM68k.exe program from the other build (this one: http://info.sonicret...xt_by_Hivebrain)_(ASM68K).zip) into the folder.
Still doesn't build, and I'm getting errors with all those include statements. (The statements the guide says to change
 ; include=<filename>.asm
into
 include "<filename>.asm" 


I tried doing the opposite. I unzipped the entire ASM68K folder and transferred the game info (my layouts, palletes, sonic1.asm, etc.) but I'm still getting the same errors. Was there something even more obvious that I should have been aware of?

#5072 User is offline FraGag 

Posted 27 February 2014 - 06:33 PM

  • Posts: 642
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
The correct form to use with ASM68K is

 include "<filename>.asm"


Make sure the included files are actually there. (Normally, they should be, since they are essentially the same between the SNASM68K and the ASM68K versions on the wiki.)

If it still doesn't work, can you post an example of an error? (You can add pause at the end of build.bat to leave the console window open after building.)

#5073 User is offline Clownacy 

Posted 27 February 2014 - 07:06 PM

  • Posts: 52
  • Joined: 06-July 13
  • Gender:Male
It just sounds like you're converting the SNASM68K-formatted includes to the ASM68K format incorrectly. Just open the sonic1.asm found in the ASM68K disassembly and compare how its includes are arranged to those in your disassembly and adjust yours to match. Though I can't understand how you'd have messed up while following the guide's method, where it was as easy as a pair of find-and-replace's.

The format should simply be the 'include' instruction followed by the path to the target file surrounded with quotation marks.

On a slightly different topic, the guide does expect you to provide the ASM68K.exe yourself.

Also, your "doing the opposite" didn't work because the problem lies within sonic1.asm whose includes are seemingly broken. You replaced the working sonic1.asm with your broken one, hence why even that one didn't build.

EDIT: Ninja'd, curses!
This post has been edited by Clownacy: 27 February 2014 - 07:06 PM

#5074 User is offline RandomAvatarFan 

Posted 27 February 2014 - 08:39 PM

  • Sonic Slide and Punch!
  • Posts: 100
  • Joined: 27-June 08
  • Gender:Male
  • Project:Yozora
  • Wiki edits:15
Yup, I had everything reading include "<filename>.asm"

I tried once again to start the conversion.

Without changing anything other than the .bat file and sonic1.asm, I get the error saying: " 'asm68k is not recognized as an internal or external commans, operable program or batch file."

I took the ASM68K program from the other disassembly and plopped it into my folder. The error it gives me then is "Bad size OP-Code".

The puzzling part about this is that the problem line here is:
move a6,usp 


This confuses me a lot because, I changed that line as the guide said:
move.l a6,usp


There is no line that reads "move a6,usp" anywhere in the code, because I changed it to move.l
This post has been edited by RandomAvatarFan: 27 February 2014 - 08:40 PM

#5075 User is offline FraGag 

Posted 28 February 2014 - 12:01 AM

  • Posts: 642
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
In build.bat, on the like that calls ASM68K, is it referring to sonic1.asm or to s1comb.asm? It should be sonic1.asm; s1comb.asm isn't necessary anymore, you should delete it.

#5076 User is offline flamewing 

Posted 28 February 2014 - 08:29 AM

  • Elite Hacker
  • Posts: 675
  • Joined: 11-October 10
  • Gender:Male
  • Location:Brasil
  • Project:Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
  • Wiki edits:12

View PostRandomAvatarFan, on 27 February 2014 - 08:39 PM, said:

Without changing anything other than the .bat file and sonic1.asm, I get the error saying: " 'asm68k is not recognized as an internal or external commans, operable program or batch file."

This is DOS/Windows' rather verbose and roundabout way of saying "asm68k was not found". Wherever you placed the exe, it was not in a place that the batch script is looking for it. Plus, what FraGag said.
This post has been edited by flamewing: 28 February 2014 - 08:30 AM

#5077 User is offline RandomAvatarFan 

Posted 28 February 2014 - 10:37 AM

  • Sonic Slide and Punch!
  • Posts: 100
  • Joined: 27-June 08
  • Gender:Male
  • Project:Yozora
  • Wiki edits:15

Quote

This is DOS/Windows' rather verbose and roundabout way of saying "asm68k was not found".

Yeah, I figured that, which is why the next step I took was this:

Quote

I took the ASM68K program from the other disassembly and plopped it into my folder. The error it gives me then is "Bad size OP-Code".



Quote

In build.bat, on the like that calls ASM68K, is it referring to sonic1.asm or to s1comb.asm? It should be sonic1.asm; s1comb.asm isn't necessary anymore, you should delete it.


It was like this:
asm68k /o op+ /o os+ /o ow+ /o oz+ /o oaq+ /o osq+ /o omq+ /p /o ae- s1comb.asm, s1built.bin


I changed it to:
asm68k /o op+ /o os+ /o ow+ /o oz+ /o oaq+ /o osq+ /o omq+ /p /o ae-  sonic1.asm, s1built.bin


And now I get more issues.

Op-code not recognised: include '<filename>.asm'

The lines in my actual sonic1.asm do have double quotes.

Thank you guys for putting up with me even this far.

#5078 User is offline FraGag 

Posted 28 February 2014 - 10:41 PM

  • Posts: 642
  • Joined: 09-January 08
  • Gender:Male
  • Location:Québec, Canada
  • Project:an assembler
  • Wiki edits:6
Is there at least one space or tab before include? If not, then include is being treated as a label and the string becomes an unrecognized opcode.
This post has been edited by FraGag: 28 February 2014 - 10:41 PM

#5079 User is offline RandomAvatarFan 

Posted 02 March 2014 - 12:18 AM

  • Sonic Slide and Punch!
  • Posts: 100
  • Joined: 27-June 08
  • Gender:Male
  • Project:Yozora
  • Wiki edits:15
Thank you guys so much for putting up with this. Indeed, it was a small mistake of not including any spacing. Just as FraGag suggested, I added spaces, and voilà. I definitely have to review the ASM guides again. Thanks a lot.

#5080 User is offline Qtheman 

Posted 03 March 2014 - 12:54 AM

  • Take a shot whenever I post in the Basic Q&A thread
  • Posts: 341
  • Joined: 11-November 09
  • Gender:Male
  • Location:Canada
  • Project:Learning ASM, School
  • Wiki edits:4
Aaaaalright, I'm back with more questions related to S2Final/S2Beta-to-S1 porting shenanigans.

So I've managed to port over a few of HPZ's objects and graphics (I'm still working on things, but I've got the glowing orb and waterfall objects ported, and have set up the bridge and floating platform objects to use HPZ-specific art). I've also taken a look at both S2Final and S2Beta's HPZ deformation code, and ported it over as well.

Having said that, I'm running into a few visual problems...

Posted Image
Posted Image

The further I move, the more HPZ's background starts to "overwrite" 16x16 blocks instead of just scrolling (I'm not sure how to describe this any better). The bigger problem is with the part of the background that's offscreen:

Posted Image

(ignore the palette, I hadn't ported HPZ's cycling palette at this point) It gets completely dishevelled like this. I've double-checked several times, and the ScrollBlock routines that the "main" routine calls are their S1 equivalents. I've even tried porting over the proto's versions of the ScrollBlock routines and using those (after correcting the RAM addresses of course), but they act even stranger (I assume I'm missing something in the main deform routine that's causing this). First question - What could be causing it to behave this way?

The other issue (which I'm hoping isn't too vague/general of a question to ask, my apologies if it is) is with the waterfall object. Once again, I've ported the object code over and converted all the addresses to their S1 equivalents, so - as far as I know - it's not reading unrelated data.

The graphics load fine, but I can't get them to appear in-game, except in only one spot (and even then, they aren't showing up correctly):

Posted Image
Posted Image

I know the original object code checks for the water level, but I've altered that check already (it uses the lower screen boundary). Having said that, I notice in the S2Final disassembly, it checks a variable called "Camera_x_pos_coarse" - Is this possibly related?

#5081 User is offline redhotsonic 

Posted 03 March 2014 - 07:29 AM

  • Also known as RHS
  • Posts: 1066
  • Joined: 31-January 05
  • Gender:Male
  • Location:United Kingdom
  • Project:Sonic 2 Recreation
  • Wiki edits:24
You've said you've ported the layer deformation over from S2Beta, but have you made sure that the index is actually pointing to it? I'm guessing you have, but thought I'd ask. You've made sure the RAM addresses all equal their equivalents but does the data/address registers also equal their equivalents? No doubt they changed it arounda bit from Sonic 1 to Sonic 2. I'm not sure on this so take this with a pinch of salt, but worth checking.

Camera_X_pos_coarse, just means it's checking how far away the object is from the camera sides. Most objects branch to a subroutine (MarkObjgone in Sonic 2), that checks every frame if the object is pretty much too far away and if so, delete itself, otherwise, display it.

	move.w	x_pos(a0),d0
	andi.w	#$FF80,d0
	sub.w	(Camera_X_pos_coarse).w,d0
	cmpi.w	#$280,d0			; Is it too far away from (or off) the screen?
	bhi.w	+				; If so, delete the object, no longer needed
	bra.w	DisplaySprite			; It's still close by; display it
+


I don't think that wil lexplain why your objects are displaying right though...

#5082 User is offline Qtheman 

Posted 03 March 2014 - 04:27 PM

  • Take a shot whenever I post in the Basic Q&A thread
  • Posts: 341
  • Joined: 11-November 09
  • Gender:Male
  • Location:Canada
  • Project:Learning ASM, School
  • Wiki edits:4
Yeah, the index is loading HPZ's deform data. Other than the blocks overwriting each other/whatever happens to the lower part of the background while it's offscreen, it does actually scroll the same way as it does in S2B. Looking at the routine again, I think the address registers might be responsible - Sonic 2 sets a whole bunch of addresses and such that Sonic 1 doesn't even have in some cases (as in 2-player stuff). I'm going to experiment with this a bit more and see if I can figure it out...

As for the waterfall, I've figured out what was wrong - The object subtype in debug was spawning what was effectively a "0-height" waterfall, so it was just creating the splash object. OOPS :specialed:

On that note though, question related to sprite priority - in Sonic 2, it's possible to have sprites appear over the level's high plane (as the HPZ waterfall does, for instance). Is there a way to do this in Sonic 1?

#5083 User is offline HCKTROX 

Posted 03 March 2014 - 08:27 PM

  • Meh
  • Posts: 13
  • Joined: 04-August 10
  • Gender:Female
  • Location:Chile
  • Project:Tails Into Dreams, Tails in Alphaomega
  • Wiki edits:4

View PostQtheman, on 03 March 2014 - 04:27 PM, said:

On that note though, question related to sprite priority - in Sonic 2, it's possible to have sprites appear over the level's high plane (as the HPZ waterfall does, for instance). Is there a way to do this in Sonic 1?


Bit $F from object art's VRAM location needs to be set.
If you have something like move.w #$3A0,2(a0), change it to move.w #$83A0,2(a0).

#5084 User is offline Qtheman 

Posted 03 March 2014 - 08:33 PM

  • Take a shot whenever I post in the Basic Q&A thread
  • Posts: 341
  • Joined: 11-November 09
  • Gender:Male
  • Location:Canada
  • Project:Learning ASM, School
  • Wiki edits:4
I was just about to post saying I'd figured it out, oops :v: Thanks though! :)

EDIT: Okay, I've been dicking about with the HPZ Deform routine to see if I can figure out what's going wrong in it, and I'm still not sure how to fix it. Having said that, I think I've figured out where the problem is - it's something to do with how Sonic 1 scrolls background tiles that are offscreen.

I'm not certain if that's all there is to it, because even when it's on-screen the upper part of the background has issues relating to overwriting tiles. Making progress, at any rate.
This post has been edited by Qtheman: 05 March 2014 - 12:42 AM

#5085 User is offline KingofHarts 

Posted 13 March 2014 - 05:58 AM

  • Amigo
  • Posts: 1208
  • Joined: 07-August 10
  • Gender:Male
  • Location:On the way back home to AMERICA!
  • Project:Sonic Triad Studio
  • Wiki edits:1
Got a quick question regarding monitors. I've been working on a mod for Sonic 1 REV C, that would allow me to have other characters without interfering with palettes and such... so far, it's been more or less a success. But I'm having an issue with the Monitor, more or less the Eggman monitor in particular. When the monitor is broken, we know that the powerup icon is given the first piece of the mapping as its sprite, which is its icon. HOWEVER, This doesn't work for me, as you can likely guess with my mappings for the Eggman monitor below:


@eggman:	spriteHeader
	spritePiece	-8, -$B, 1, 2, $3C, 0, 0, 0, 0 ; Overlay to preserve skin color
	spritePiece	0, -$B, 1, 2, $3C, 1, 0, 0, 0 ; Overlay to preserve skin color
	spritePiece	-8, -$B, 2, 2, $18, 0, 0, 1, 0
	spritePiece	-$10, -$11, 4, 4, 0, 0, 0, 1, 0
@eggman_End




The overlays are needed to help the monitor retain its proper color, as I have MOST of the monitor pieces using line 1, where the skin color is not present... instead of line 0. Now, using the normal code, when the Eggman monitor is broken, the sprite that appears is NOT the whole of the icon, rather it is half of the overlay (the first piece). I've tried to remedy this with the following modification:


		move.b	anim(a0),d0	; get subtype
		cmpi.b	#1,d0      ; is it the Eggman monitor?
		bne.s	@noteggman ; if not, branch
		move.l	#Map_EggIcon,mappings(a0) [size=2]; Add new mappings, to accomodate for overlay with Eggman monitor[/size]
		move.b	#0,mapping_frame(a0)
		rts
	@noteggman:
                addq.b	#2,d0
		move.b	d0,mapping_frame(a0)	; use correct frame
                movea.l	#Map_Monitor,a1
		add.b	d0,d0
		adda.w	(a1,d0.w),a1
		addq.w	#1,a1
		move.l	a1,mappings(a0)




The above snippet is at the start of the powerup icon code, and checks if it is the Eggman monitor, and if so, goes to new mappings specifically for the icon, which look like so:


Map_EggIcon:	mappingsTable
	mappingsTableEntry.w	@eggmanicon

@eggmanicon:	spriteHeader
	spritePiece	-8, -$B, 1, 2, $3C, 0, 0, 0, 0 ; Overlay
	spritePiece	0, -$B, 1, 2, $3C, 1, 0, 0, 0 ; Overlay
	spritePiece	-8, -$B, 2, 2, $18, 0, 0, 1, 0
@eggmanicon_End



Now, instead of getting my monitor icon, I get a garbled mess (ONLY for Eggman... other monitors are fine). I believe there is something wrong with how I implemented the code, itself... but I could be wrong. Other than the garbled icon mess, everything else behaves the exact same, with no issues. If screenshots are necessary, I'll post when I return.
This post has been edited by KingofHarts: 13 March 2014 - 05:59 AM

  • 342 Pages +
  • ◄ First
  • 337
  • 338
  • 339
  • 340
  • 341
  • Last ►
    Locked
    Locked Forum

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users