[redquebec]

Varion Icaria, on 07 January 2015 - 01:39 PM, said:

Given if the S2 Sound driver's disassembly works like the S3K one in terms of compiling I can implement the PWM into the stock Sonic 2 driver and remove DAC. Though the S3K driver does allow for more customizations currently thanks to Flamewing. We restored FM6 not that long ago in that driver and I implemented PWM into my version [along side of DAC actually but that's a whole different story] Anyways it's relatively easy to setup once the Z80 driver is fully setup. just give me a shout on skype where I'm usually at and I can assist.

DO you think its possible technically to create something hybrid if we don't plan on using the 32x? DAC playing through 32x or FM6 depending on what we plan to build?

[saxman]

I'm curious too -- of the new features listed on the first post, what ones are your favorite? Let me know!

Clownacy, on 06 January 2015 - 09:01 AM, said:

By the way, I have a suggestion: There's the old mapping error where Knuckles moves forward when he looks up.

Your wish is my command. Fixed. It always bothered me when I was younger

Varion Icaria, on 07 January 2015 - 01:39 PM, said:

Given if the S2 Sound driver's disassembly works like the S3K one in terms of compiling I can implement the PWM into the stock Sonic 2 driver and remove DAC. Though the S3K driver does allow for more customizations currently thanks to Flamewing. We restored FM6 not that long ago in that driver and I implemented PWM into my version [along side of DAC actually but that's a whole different story] Anyways it's relatively easy to setup once the Z80 driver is fully setup. just give me a shout on skype where I'm usually at and I can assist.

My preferred design approach would be to "add" PWM rather than "replace" DAC. I like backward compatibility. I will be in touch with you to try and figure out what I need to do this.

This post has been edited by saxman: 11 January 2015 - 12:24 AM

[redquebec]

saxman, on 11 January 2015 - 12:23 AM, said:

My preferred design approach would be to "add" PWM rather than "replace" DAC. I like backward compatibility. I will be in touch with you to try and figure out what I need to do this.

Actually, can a best-of both worlds approach would work? Is that even feasible? Using FM6 when no 32X is present, but switch to PWM if it is? Theoricaly it seems ok, but can the Z80 driver handle that?

[MarkeyJester]

Any combination is possible with little to no difficulty. I suppose what you would define as "difficult" would depend on ones knowledge, but the Z80 will handle whatever it is programmed to handle provided the programmer has brains.

[saxman]

I'm making a good bit of headway with moving Sonic 1 over to the Sonic Boom base. GHZ is about 90% there. Here are a couple screenshots:


Sonic 1 style HUD. Here, we play with Sonic and Tails:


Sonic 2 style HUD. Because it's Sonic Boom, we can easily put Knuckles in Sonic 1:



The first release of Saxman's Sonic Boom engine was to fix a lot of bugs in Sonic 2 and enhance the underlying engine while still staying true to what made Sonic 2... well... Sonic 2!

The main point of the next release is to give hackers all assets from Sonic 1 and 2 without having to "port" anything. Using a series of configuration settings, you can decide what assets to use from each game. Mix and match what you want. Think of it as a mega-interoperable code base for Sonic 1, Sonic 2, Sonic 1+2, Sonic 1 with a Little 2, Sonic 2 with a Dash of 1, etc.

This is also a good opportunity to merge common code between the two games. And there's a LOT of it. Below is an example of Obj95 (the Sol badnik from HTZ). I merged it with Orbinaut, because the two are nearly the same object. For Sonic 1, it's Orbinaut. For Sonic 2, it's Sol. For complex, you control if it's Sol or Orbinaut by using the MSB of the subtype. And it works beautifully!

KEEP IN MIND: One of my goals for the next release is to improve labeling and the overall look of the code. The below code is not exempt from that effort, so be mindful that this will be improved. Anyway, here it is in its current form:

; ----------------------------------------------------------------------------
; Object 95 - Sol (fireball-throwing orbit badnik) from HTZ
;			  Orbinaut enemy (LZ, SLZ, SBZ)
; ----------------------------------------------------------------------------
; Sprite_370FE:
Obj95:
	moveq	#0,d0
	move.b	routine(a0),d0
	move.w	Orb_Index(pc,d0.w),d1
	jmp	Orb_Index(pc,d1.w)
; ===========================================================================
Orb_Index:
	dc.w Orb_Main-Orb_Index
	dc.w Orb_ChkSonic-Orb_Index; 1
	dc.w Orb_Display-Orb_Index; 2
	dc.w Orb_MoveOrb-Orb_Index; 3
	dc.w Orb_ChkDel2-Orb_Index; 4
	
orb_parent:	= $3C		; address of parent object
; ===========================================================================

Orb_Main:
	if INCLUDE_SONIC_1_LEVELS == TRUE
		if INCLUDE_SONIC_2_LEVELS == TRUE
			btst.b	#7,subtype(a0)
			beq.s	++
		endif
		
		move.l	#(ROM_Start+Map_Orb),mappings(a0)
		cmpi.b	#ZONE_ID_LZ,(Current_Zone).w
		bne.s	+
		move.w	#$530,art_tile(a0)	; LZ specific code
		bra.s	+++
+
		move.w	#$429,art_tile(a0)	; SLZ specific code
		
		if INCLUDE_SONIC_2_LEVELS == TRUE
			bra.s	++
		endif
+
	endif
	
	if INCLUDE_SONIC_2_LEVELS == TRUE
		move.l	#(ROM_Start+Obj95_MapUnc_372E6),mappings(a0)
		move.w	#0,art_tile(a0)		; HTZ specific code
	endif
+
	bsr.w	JmpTo64_Adjust2PArtPointer
	ori.b	#4,render_flags(a0)
	move.b	#4,priority(a0)
	move.b	#$B,collision_flags(a0)
	move.b	#$C,width_pixels(a0)
	
	if INCLUDE_SONIC_2_LEVELS == TRUE
		if INCLUDE_SONIC_1_LEVELS == TRUE
			btst.b	#7,subtype(a0)
			bne.s	+
		endif
		
		move.w	#-$40,x_vel(a0)
	endif
+
	moveq	#0,d2
	lea	objoff_37(a0),a2
	movea.l	a2,a3
	addq.w	#1,a2
	moveq	#3,d1

Orb_makesatellites:
	bsr.w	JmpTo25_SingleObjLoad2
	bne.s	Orb_fail
	addq.b	#1,(a3)
	move.w	a1,d5
	subi.w	#$B000,d5
	lsr.w	#6,d5
	andi.w	#$7F,d5
	move.b	d5,(a2)+
	move.b	0(a0),0(a1) ; load obj95
	move.b	#6,routine(a1) ; use Orb_MoveOrb routine
	move.l	mappings(a0),mappings(a1)
	move.w	art_tile(a0),art_tile(a1)
	ori.b	#4,render_flags(a1)
	move.b	#4,priority(a1)
	move.b	#8,width_pixels(a1)
	move.b	#3,mapping_frame(a1)
	move.b	#$98,collision_flags(a1)
	move.b	d2,angle(a1)
	
	if INCLUDE_SONIC_1_LEVELS == TRUE
		if INCLUDE_SONIC_2_LEVELS == TRUE
			move.b	subtype(a0),subtype(a1)
		endif
	endif
	
	addi.b	#$40,d2
	move.l	a0,objoff_3C(a1)
	dbf	d1,Orb_makesatellites ; repeat sequence 3 more times

Orb_fail:
	moveq	#1,d0
	btst	#0,status(a0)	; is orbinaut facing left?
	beq.s	Orb_noflip		; if not, branch
	neg.w	d0

Orb_noflip:
	move.b	d0,objoff_36(a0)
	move.b	subtype(a0),routine(a0) ; if type is 02, skip Orb_ChkSonic
	andi.b	#$E,routine(a0)
	addq.b	#2,routine(a0)
	move.w	#-$40,x_vel(a0) ; move orbinaut to the left
	btst	#0,status(a0)	; is orbinaut facing left?
	beq.s	Orb_noflip2		; if not, branch
	neg.w	x_vel(a0)		; move orbinaut	to the right

Orb_noflip2:
	rts
; ===========================================================================

Orb_ChkSonic:	; Routine 2
	move.w	(MainCharacter+x_pos).w,d0
	sub.w	x_pos(a0),d0	; is Sonic to the right of the orbinaut?
	bcc.s	Orb_isright		; if yes, branch
	neg.w	d0

Orb_isright:
	cmpi.w	#$A0,d0			; is Sonic within $A0 pixels of	orbinaut?
	bcc.s	Orb_animate		; if not, branch
	move.w	(MainCharacter+y_pos).w,d0
	sub.w	y_pos(a0),d0	; is Sonic above the orbinaut?
	bcc.s	Orb_isabove		; if yes, branch
	neg.w	d0

Orb_isabove:
	cmpi.w	#$50,d0
	bcc.s	Orb_animate
	tst.w	(Debug_placement_mode).w
	bne.s	Orb_animate
	move.b	#1,anim(a0)

Orb_animate:
	if INCLUDE_SONIC_2_LEVELS == TRUE
		if INCLUDE_SONIC_1_LEVELS == TRUE
			btst.b	#7,subtype(a0)
			bne.s	+
		endif
	
		bsr.w	JmpTo26_ObjectMove
		lea	(ROM_Start+Ani_Orb).l,a1
		bsr.w	JmpTo25_AnimateSprite
		andi.b	#3,mapping_frame(a0)
		bra.w	JmpTo39_MarkObjGone
	endif
+
	if INCLUDE_SONIC_1_LEVELS == TRUE
		lea	(ROM_Start+Ani_Orb).l,a1
		bsr.w	JmpTo25_AnimateSprite
		bra.w	Orb_ChkDel
	endif
; ===========================================================================

Orb_Display:	; Routine 4
	bsr.w	JmpTo26_ObjectMove
	
	if INCLUDE_SONIC_2_LEVELS == TRUE
		if INCLUDE_SONIC_1_LEVELS == TRUE
			btst.b	#7,subtype(a0)
			bne.s	+
		endif
		
		lea	(ROM_Start+off_372E0).l,a1
		bsr.w	JmpTo25_AnimateSprite
		andi.b	#3,mapping_frame(a0)
		bra.w	JmpTo39_MarkObjGone
+
	endif
	
	if INCLUDE_SONIC_1_LEVELS == TRUE
Orb_ChkDel:
		move.w	x_pos(a0),d0
		andi.w	#$FF80,d0
		sub.w	(Camera_X_pos_coarse).w,d0
		cmpi.w	#OBJECT_X_SCOPE,d0
		bhi.w	Orb_chkgone
		jmp	DisplaySprite

Orb_chkgone:
		lea	(Object_Respawn_Table).w,a2
		moveq	#0,d0
		move.b	respawn_index(a0),d0
		beq.s	loc_s1_11E34
		bclr	#7,2(a2,d0.w)

loc_s1_11E34:
		lea	$37(a0),a2
		moveq	#0,d2
		move.b	(a2)+,d2
		subq.w	#1,d2
		bcs.s	Orb_Delete

loc_s1_11E40:
		moveq	#0,d0
		move.b	(a2)+,d0
		lsl.w	#6,d0
		addi.l	#Object_RAM&$FFFFFF,d0
		movea.l	d0,a1
		jsr	DeleteObject2
		dbf	d2,loc_s1_11E40

Orb_Delete:
		jmp	DeleteObject
	endif ;if INCLUDE_SONIC_1_LEVELS == TRUE
; ===========================================================================

Orb_MoveOrb:	; Routine 6
	if INCLUDE_SONIC_2_LEVELS == TRUE
		if INCLUDE_SONIC_1_LEVELS
			btst.b	#7,subtype(a0)
			bne.s	+
		endif
		
		lea	(ROM_Start+off_372E0).l,a1
		bsr.w	JmpTo25_AnimateSprite
	endif
+
	movea.l	orb_parent(a0),a1 ; a1=object
	cmpi.b	#$95,0(a1)
	bne.w	JmpTo65_DeleteObject
	cmpi.b	#2,mapping_frame(a1)
	bne.s	Orb_circle
	cmpi.b	#$40,angle(a0)
	bne.s	Orb_circle
	addq.b	#2,routine(a0)
	
	if INCLUDE_SONIC_2_LEVELS == TRUE
		if INCLUDE_SONIC_1_LEVELS == TRUE
			btst.b	#7,subtype(a0)
			bne.s	+
		endif
		
		move.b	#0,anim(a0)
	endif
+
	subq.b	#1,objoff_37(a1)
	bne.s	Orb_fire
	addq.b	#2,routine(a1)

Orb_fire:
	move.w	#-$200,x_vel(a0)
	btst	#0,status(a1)
	beq.s	Orb_noflip3
	neg.w	x_vel(a0)

Orb_noflip3 
	bra.w	JmpTo45_DisplaySprite
; ===========================================================================

Orb_circle:
	move.b	angle(a0),d0
	jsr	(ROM_Start+CalcSine).l
	asr.w	#4,d1
	add.w	x_pos(a1),d1
	move.w	d1,x_pos(a0)
	asr.w	#4,d0
	add.w	y_pos(a1),d0
	move.w	d0,y_pos(a0)
	move.b	objoff_36(a1),d0
	add.b	d0,angle(a0)
	bra.w	JmpTo45_DisplaySprite
; ===========================================================================

Orb_ChkDel2:
	bsr.w	JmpTo26_ObjectMove
	tst.b	render_flags(a0)
	bpl.w	JmpTo65_DeleteObject
	
	if INCLUDE_SONIC_2_LEVELS == TRUE
		if INCLUDE_SONIC_1_LEVELS == TRUE
			btst.b	#7,subtype(a0)
			bne.s	+
		endif
		
		lea	(ROM_Start+off_372E0).l,a1
		bsr.w	JmpTo25_AnimateSprite
	endif
+
	bra.w	JmpTo45_DisplaySprite
; ===========================================================================
; animation script
	
Ani_Orb:
	dc.w Ani_Orb_normal-Ani_Orb
	dc.w Ani_Orb_angry-Ani_Orb; 1
Ani_Orb_normal:
	dc.b  $F,  0,$FF
Ani_Orb_angry:
	dc.b  $F,  1,  2,$FE,  1
	even
	
	if INCLUDE_SONIC_2_LEVELS == TRUE
; animation script
off_372E0:
	dc.w byte_372E2-off_372E0
byte_372E2:
	dc.b   5,  3,  4,$FF
	even
	
	endif
; ----------------------------------------------------------------------------
; sprite mappings
; ----------------------------------------------------------------------------
	if INCLUDE_SONIC_1_LEVELS == TRUE
Map_Orb:	BINCLUDE	"mappings/sprite/obj95_1.bin"
	even
	endif
	
	if INCLUDE_SONIC_2_LEVELS == TRUE
Obj95_MapUnc_372E6:	BINCLUDE "mappings/sprite/obj95_2.bin"
	endif

This post has been edited by saxman: 18 January 2015 - 10:20 PM

[Hitaxas]

I had been pretty much away for about 2 months, which put my project on ice. But now I am back and I come back to this? I'm excited. I had restarted my hack from scratch recently using the 2007 disassembly and was in the process of doing a few things already done in your Sonic Boom engine. So naturally I've decided to scrap what little I had done and move over to this engine (of course improving on some small things and fixing more bugs as I go). I fully support this project and any further work you will do with it.

Question though, even though your plans for the next release is to merge Sonic 1 and 2 into the same source/engine... might there be plans down the road sometime to do the same with Sonic 3/ Sonic & Knuckles?

[Clownacy]

Instead of outright denying the ability to place objects in debug mode while dead, how about adding a different workaround that allows the placement, without the crashing? Also, some other REV00 goodies, like Obj74 and Obj66 being visible in debug placement mode? Also, what of doing what REV02 did, and removing all of the JmpTos?

Speaking of, where'd that line about 'adda.w invincibility_time(a6),a1' come from? That's not there in REV02 or KiS2.

[saxman]

redquebec, on 07 January 2015 - 08:37 PM, said:

Varion Icaria, on 07 January 2015 - 01:39 PM, said:

Given if the S2 Sound driver's disassembly works like the S3K one in terms of compiling I can implement the PWM into the stock Sonic 2 driver and remove DAC. Though the S3K driver does allow for more customizations currently thanks to Flamewing. We restored FM6 not that long ago in that driver and I implemented PWM into my version [along side of DAC actually but that's a whole different story] Anyways it's relatively easy to setup once the Z80 driver is fully setup. just give me a shout on skype where I'm usually at and I can assist.

DO you think its possible technically to create something hybrid if we don't plan on using the 32x? DAC playing through 32x or FM6 depending on what we plan to build?

I meant to comment on this earlier. As it has been said, anything is technically possible. My plan would be to have the extra values and such available only in the 32X port. So it would be one code base with compiler checks to include/exclude certain things, much like I'm currently working on with the Sonic 1 and Sonic 2 stuff.

Hitaxas, on 19 January 2015 - 01:22 AM, said:

I had been pretty much away for about 2 months, which put my project on ice. But now I am back and I come back to this? I'm excited. I had restarted my hack from scratch recently using the 2007 disassembly and was in the process of doing a few things already done in your Sonic Boom engine. So naturally I've decided to scrap what little I had done and move over to this engine (of course improving on some small things and fixing more bugs as I go). I fully support this project and any further work you will do with it.

Question though, even though your plans for the next release is to merge Sonic 1 and 2 into the same source/engine... might there be plans down the road sometime to do the same with Sonic 3/ Sonic & Knuckles?

Great! Any bugs or problems you have specific to Sonic Boom, let me know.

I have given some thought to Sonic 3K. I'm open to the idea. I have also thought about Sonic CD and how it might be interesting to support it on the Genesis. Or, maybe allow Sonic Boom to compile for the Sega CD and do a more natural port of Sonic CD that way. There's a couple avenues to look at. But for certain, I don't want to stop after Sonic 1. Any preferences on this front?

Clownacy, on 19 January 2015 - 01:55 PM, said:

Instead of outright denying the ability to place objects in debug mode while dead, how about adding a different workaround that allows the placement, without the crashing? Also, some other REV00 goodies, like Obj74 and Obj66 being visible in debug placement mode? Also, what of doing what REV02 did, and removing all of the JmpTos?

Speaking of, where'd that line about 'adda.w invincibility_time(a6),a1' come from? That's not there in REV02 or KiS2.

That's interesting. I may just put that debug placement solution in the next major release, or maybe even slip it in a patch release for v1.00.

And yes, I definitely gave consideration to see the invisible objects (Obj03 is another good one). I wasn't sure quite how to do it though, so it got pushed to the back burner. I'd still like to do that though.

As for the line you referenced, I think what I meant to write is Rev01 rather than Rev02. In my head I know it's the second release of Sonic 2, and so I have a habbit of immediately thinking 'revision 02', even though that's obviously wrong. If I remember correctly, Knuckles in Sonic 2 changed that line, and I couldn't understand why. I went with speculative reasoning that if it was changed, it was probably to fix something. But because I wasn't 100% sure, I left the original line there in the comment. If you or anyone else knows what the purpose of the change might be, I'm interested in hearing about it.

This post has been edited by saxman: 20 January 2015 - 10:03 PM

[DigitalDuck]

saxman, on 20 January 2015 - 09:53 PM, said:

I have given some thought to Sonic 3K. I'm open to the idea. I have also thought about Sonic CD and how it might be interesting to support it on the Genesis. Or, maybe allow Sonic Boom to compile for the Sega CD and do a more natural port of Sonic CD that way. There's a couple avenues to look at. But for certain, I don't want to stop after Sonic 1. Any preferences on this front?

Personally, I'd stick with one at a time - make this as good as you can first before going on to something else.

Unless you're going to be able to cram S1/2/3K in one ROM with this, then I'd go for SMD support of Sonic CD first. It seems to be the natural next step.

[Sodaholic]

Saxman, this is really awesome and I love every aspect of this project from the concept to the execution. If my coding skills were up to snuff, I'd have tried the same thing; a unified, polished/bug-fixed yet faithful version of the disassemblies, for community use. The thing I like most about it is the attempt to establish some kind of base standard so that hackers can focus on what they want to/are good at without having to worry about handling the commonly expected bug-fix/extra feature checklist. It's a goddamn waste of time to redo what's already been done but better, so why not just have those expected assembly changes be accessible by default?

It probably has a lot to do with how the different companies themselves handle their properties, but I've always preferred the creative culture on the Doom side of things than the Sonic side of things. People in the Doom community are by default very friendly and willing to lend a hand up so that every person can shine in their area of skill. It's a communal effort, those that have skill in some areas help those that are stronger in others, and the result is a collective higher quality in projects. Here, though, the default seems to be a far more private, secretive "do it yourself noob" attitude, with attempted justification being some form of disdain for "plebians" doing "distasteful" things with advanced code features as if that was some kind of problem to express one's self creatively no matter the quality. No harm in sharing your code as long as its users give due credit.

I hope that this project shifts that attitude more toward an open-source, communal philosophy wherever that more 'elitist' mentality may exist. I haven't seen a whole lot of it at all lately, but I'm not really around here much these days. We're all 'thieves' anyway by having these disassemblies. People here help each other out anyway, I just wish that selfish "my code!" mentality didn't exist at all even in the past, given how hypocritical it is.

DigitalDuck, on 20 January 2015 - 10:12 PM, said:

Unless you're going to be able to cram S1/2/3K in one ROM with this, then I'd go for SMD support of Sonic CD first. It seems to be the natural next step.

Yes, CD seems a better next step than 3K given that it is mostly a souped-up S1, whereas 3K made fundamental changes to many, many things. I personally consider Sonic 3 Complete the definitive version of 3K, and I know there are reservations about sharing the source to respect the vast number of external contributors the project has seen, playing it safe to ensure that no one's contributions are shared without express permission. If 3K support is ever added to Boom, I think it should be based on S3C if negotiations can be worked out.

[Tiddles]

Most of the stuff that would be relevant to a project like this, I.e. tweaks and bugfixes, there shouldn't be any problem sharing - I'd have to scan through, but the vast majority of that category comes from either me or published tutorials.

I wouldn't really want to give over feature stuff like selectable modes, layouts, level reorder, added music etc. for public reuse, but I don't think any of that is relevant to a project like this in the first place, nor to an original project based on S3&K - in fact, trust me on this, a lot of user end options to maintain only make the thing harder to work with. (I'd actively encourage taking on multibutton super though, since I detest the way that works as standard with the S3 moveset!)

[ThomasSpeedrunner]

To be honest, I'm not sure how to feel about this whole engine in the first place.

Things I like:
+ It's based off of Sonic 2, which means automatic higher score since I love Sonic 2.
+ Several assembly options allow for a mix of different fixes and features.
+ Objects are merged together with unique ways of detecting what subtype of an object to load.

Things I personally have a problem with:
- Touching on the merging of objects, the code on the Sol/Orbinaut example is kinda messy in my opinion.
- May I ask why 32X support was ever necessary? This could probably work perfectly fine without it, and the problem of people with no 32X knowledge attempting to make hacks utilizing it is going to be a thing rather quickly should this gain mass popularity among newcomers...
- Why dost thou includeth Sonic 1?
- The name is Sonic Boom, which is also the name of a cartoon, a game, a song, a user, and a Sonic 2 hack. I would suggest being more original with the title...

I know this is all kinda long for my first post here, but I've known about this for a while and have been keeping tabs on it despite preferring Xenowhirl's S2 disasm from '07.

This post has been edited by ThomasSpeedrunner: 22 January 2015 - 04:57 PM

[GerbilSoft]

ThomasSpeedrunner, on 22 January 2015 - 04:56 PM, said:

- May I ask why 32X support was ever necessary? This could probably work perfectly fine without it, and the problem of people with no 32X knowledge attempting to make hacks utilizing it is going to be a thing rather quickly should this gain mass popularity among newcomers...

Not like this will ever be a problem. They'll be stuck on trying to get their 68000 code to run on the SH-2s.

This post has been edited by GerbilSoft: 22 January 2015 - 05:08 PM

[Clownacy]

Sonic 1 and 32x are both optional. The latter's already had its existence questioned. Also, people like Sonic 1. The Orbinaut/Sol looks like a space-saver, and the rest of the disasm is just as messy. The name came from what inspired the project. The wiki has info on that.

Anyway... Saxman, I can't find that line anywhere in the UPMEM disasm or my REV02 disasm. Not even a hex-search for the machine code had any results. Just where did you find that thing?

Also, another suggestion: In a similar manner to ReadySonic and my driver, could your changes be labelled, appended with a comment containing 'Boom Engine' or something?

This post has been edited by Clownacy: 23 January 2015 - 01:58 PM

[Hitaxas]

saxman, on 20 January 2015 - 09:53 PM, said:

Great! Any bugs or problems you have specific to Sonic Boom, let me know.

I have given some thought to Sonic 3K. I'm open to the idea. I have also thought about Sonic CD and how it might be interesting to support it on the Genesis. Or, maybe allow Sonic Boom to compile for the Sega CD and do a more natural port of Sonic CD that way. There's a couple avenues to look at. But for certain, I don't want to stop after Sonic 1. Any preferences on this front?

I would actually be more interested in having it build for Sega cd. Maybe both ideas could be good. But allowing it to build on Sega cd would allow people to modify Sonic 2 on a system they previously could not. So far I think most if not all hacks made for Sega cd are of Sonic 1. This would enable to ability to utilize red book audio and also allow the creator to access more data space, allowing them to create bigger and better things.

Tl;dr : The Sega cd option is the way to go imho.