Sonic and Sega Retro Message Board: vladikcomper - Viewing Profile - Sonic and Sega Retro Message Board

E-122-Psi, sorry, I have no time to explain everything in detail now, but I believe, you'll quickly get the idea, as it's fairly simple.

Sonic_Hover:
	tst.b	($FFFFFFAA).w		; is Sonic in hovering state?
	bne.s	@Hover_Process		; if yes, branch

	; This code branch works if Sonic isn't in hovering state yet
	move.b	($FFFFF602).w,d0	; move the curently held buttons into d0
	andi.b	#$30,d0			; B/C being held?
	beq.s	@Hover_Return		; if not, branch
	move.b	#1,($FFFFFFAA).w	; set hover flag to $01
	move.b	#$21,$1C(a0)		; play hovering animation
	clr.w	$12(a0)			; clear Y-velocity
	moveq	#$FFFFFFB7,d0
	jsr	PlaySound_Special	; play SFX

	; This code branch works if Sonic is in the hovering state
@Hover_Process:
	move.b	($FFFFF602).w,d0	; move the curently held buttons into d0
	andi.b	#$30,d0			; B/C being held?
	bne.s	@Hover_Return		; if yes, branch
	move.b	#$1F,$1C(a0)		; reset animation
	move.b	#0,($FFFFFFAA).w	; set hover flag to $00 (I suppose, you need it)

@Hover_Return:
	rts

Quote

He was speaking about Z80 drivers in general. Many of them actually use YM timers for timing, which is certainly more beneficial than tying to a Vertical Interrupt.

Unfortunately, the YM2612 cannot generate interrupts on Sega Genesis (which many people consider a design failure, since the chip has the corresponding pin to generate interrupts; it simply wasn't implemented), so a programmer has to check if timers are expired manually in a continuous loop. The later means the processor cannot do anything besides checking for interrupts in its main loop. The MC68000C obviously can't be occupied with that sort of job, since it has to process game logic during the main loop, it is only possible with a Z80 driver.

Using YM timers allows for much more flexible timing. You can update music faster than every 1/60th of second (1/50th on PAL machines). Tempo becomes much easier to handle programming-wise: you can adjust it by only adjusting timer period on the YM2612; no need in tempo managing routines like when static timing is used. But the main benefit is that there will be no tempo change between PAL and NTSC machines. Unlike Vertical Interrupts that have different time periods depending on the region to match PAL and NTSC television standards, YM timers work the same on either machine. Of course, there are certain workarounds for the tempo change issue that some sound drivers used back in the day. One workaround was calling update sound code twice every 6th frame on PAL machines, while works, this may have some side effects at times: since the sound driver code is run twice, this may overload processor, causing lag at times, and the fact sound is updated two times in a row without a proper delay will distort note durations.

But like always, all the benefits described above are achieved at the cost of putting certain limitations. Like it was said earlier, the processor has to check for timers expiration in a continuous loop. That means, when YM timers are used, Z80 cannot process DAC playback at all, since the main loop is occupied. Which is why all Z80 drivers that aim to handle DAC samples playback, including Sonic & Knuckles' driver, never rely on YM timers.

Speaking of the engine. Here's a quote from the man who did massive research in Ristar years ago, figured out many RAM addresses and how they worked with the engine, as well as game formats, including objects. The post quoted is from the exact same thread that Rika Chou linked above.

JoseTB, on 21 March 2008 - 10:41 PM, said:

For those who are interested, Ristar's memory map and objects format are documented in the first post of that thread.

Quote

I wouldn't say Sonic 1 is not a suitable engine to start out a game like Ristar. Frankly, I don't get your point there. What's particularly bad in using older game's software, especially when the software in the question runs on the exact same console? Were there any changes to Sega Genesis hardware which would make Sonic 1 software outdated and incapable in 1994? There were not. It's the exact same piece of hardware as it was back in 1991 and as long as the original engine is designed well enough and easy expandable, there's no reason not to re-use it.

Out of all Sonic games, Sonic 1's engine would suit the best to create any different platform game out of it. The engine was quite more 'basic' compared to later games, mainly because of being the first game in the series, suggesting somewhat new gaming formula and various unique concepts, it was more than innovative back in the time. Without a doubt, Sonic Team was setting experiments all the way through the development process, just check out early prototype shots from 1990 - it was the whole different game taking place in a different universe. Thus, their engine was trying to be generic to handle quickly changing concepts and formulas. Which is why Sonic 1 is the most expandable engine. In later games their went with optimizing that engine to that Sonic formula established by the first game in the series. Hence, later engines are overloaded with Sonic-specific features, they implemented rings manager, the whole game logic was tweaked to handle sidekick etc.

Personally, I can't tell for sure whether Ristar was using Sonic 1's basic engine or not. I can only share my thoughts why it is considered so. Ristar's level layouts use 256x256 chunk system, just like Sonic 1 did. Later Sonic games migrated to 128x128 chunks, since the level became less linear, larger and featured swapping pathes. The other thing is that Ristar uses SMPS 68k, again, just like Sonic 1. Later Sonic games changed it to SMPS Z80 with slightly different music format (pointers and coordinate flags worked differently), while Ristar's sound driver, apart from some improvements, is nearly identical to Sonic 1's.

That's all I can tell you.

All compressors provided by flamewing are command-line tools, which means they only work from a command prompt, where you should pass 3 or 2 arguments to the compressor.

To use them, open Command Prompt, set the current path to where compressors' executable files are, like so:

cd D:\Sega\Dev\Tools\KENS_FL\

Now you can run any executable file from that folder just by typing its name (even without extension). For example, if you want to execute Comper's compressor (compcmp.exe), simply type in: compcmp. However, this won't get you anywhere, because, in order to make it to work, you should pass arguments to the compressor first. Executing it without them simply leads you to a short help message - the one that popped up for a split second when you launched it right from Windows Explorer.

Now, as for the arguments.
If you want compress file A.bin to Comper format, execute the following command in command prompt:

compcmp A.bin A.bin.comper

The output will be A.bin.comper (obviously). You may choose any name you like. I prefer extra extensions to identify compression format more easily.

If you want decompress B.bin.comper, do this:

compcmp -x B.bin.comper B.bin

If you don't like dealing with command prompt, you may check out my own original compressor tools (the compcmp.exe from the recent KENS was written by flamewing himself): https://dl.dropboxus...20Compressor.7z
It works simple: just drag&drop the file you want to compress onto executable. The output will be a file of the same name, but with extra .comper extension. This compressor, however, works slowly due to debug output, it also was compiled with MinGW and may not work on some machines if GCC dynamic link library is absent -- this can be easily fixed by finding and placing the said dll-file into compressors folder (the name will be displayed in the error message).