Donkey Kong Country - Sega Genesis - TECH DEMO

[tepples]

Another option if you're low on VRAM is to keep 512x256-pixel tilemaps and set the left half to one priority and the right half to opposite priority. Then alternate bit 8 from line to line in the hscroll table. Doing left half low and right half high can cause a seam at the X=0 and X=256; I don't know how visible/how annoying that would likely be. It should be possible to hide these sorts of seams by keeping them in the blank spaces between blobs.

[olddb]

Is this the same person who made the SNES Sonic demo?
Any idea how he gets to character physics and animations so close to the original in both cases?

[tokumaru]

For Sonic at least I think he copied the physics straight from the original game's disassembly. Basically no guesswork, just a direct reimplementation of the same logic. Can't find confirmation of this right now though, so take this with a grain of salt.

[turboxray]

For Sonic at least I think he copied the physics straight from the original game's disassembly. Basically no guesswork, just a direct reimplementation of the same logic. Can't find confirmation of this right now though, so take this with a grain of salt.

I remember him making some statements in regard to the Sonic disassembly, and the fast shift instructions on the 68k taking longer on the '816 for his project. It'd be weird if he didn't use the public disassembly.

[psycopathicteen]

Shifting instructions? Don't they take 6 cycles of overhead on the 68000?

[93143]

Yes, and I believe it's two cycles per bit shifted, same as the 65C816. So even with the faster clock, you have to shift by at least 3 bits for it to take less real time than the S-CPU in FastROM.

There are, of course, other things you can do to shift by large amounts, such as multiplication and byte swapping/masking. I'm not sure what exactly Sonic uses shifting for, so it's hard to say what the optimal approach would be.

[turboxray]

It's 2 cycles per shift on a 32bit register, after the initial setup. But that wasn't the issue from what I recall. It was that the value was shift amount by variable. As in, LSL.l D0, D1. Which is indeed slower to do on the '816. But my question was: how many possible shifts could you be doing per frame that it actually mattered? I never got an answer to that.

[TiagoSC]

My Sonic 1 port for SNES uses the SonicRetro disassembly as a base,
but I optimized it by also using code from Sonic 2 and Sonic 3, which are more optimized than Sonic 1.

I haven't yet reached 100% accuracy of the original physics, there's something out of place
that generates some instability in the player's movement.

My complaints were mostly about the dynamic variable shifts in the registers, i solved that using jump tables.

Another issue was the arithmetic right shifts in 32-bit variables,
before optimizing, I thought it was a speed problem because of using:

LDA T4
ASL
ROR T4
ROR T3

20 cycles per bit
to perform ASR.L #8 from the 68000 to the 65816, would take 160 cycles...
So, thanks to the 65816 being able to read even/odd addresses, I reduced that to a mere 4 cycles.

;----------------------------------------------------------------------------------------------------------------------
; increase or decrease speed on the ground
;----------------------------------------------------------------------------------------------------------------------
;68000 code ----------------------------
loc_12FEE:
move.b obAngle(a0), d0
jsr (CalcSine).l

muls.w obInertia(a0), d1
asr.l #8, d1
move.w d1, obVelX(a0)

muls.w obInertia(a0), d0
asr.l #8, d0
move.w d0, obVelY(a0)

;65816 code ---------------------------
loc_12FEE: ;AXY16
LDA obAngle, X
JSR CalcSine

STA mul_T1
LDA obInertia, X
STA mul_T2
JSR MUL_S16_T1T2 ;--------- T3T4 = (T1 * T2) (signed 16x16=32 multiply)
LDA mul_T3+1 ;--------- ASR 8 by load T3.upperbyte + T4.lowerbyte
STA obSpeedX, X

STY mul_T1
JSR MUL_S16_T1T2
LDA mul_T3+1
STA obSpeedY, X

But my main difficulty, which used to include the sound driver,
but now i find it easier to stream samples via HDMA + sequential music on the SPC700,
is the terrible sprite engine of the SNES...

It's frustrating how many limitations there are, yes 128 sprites is great
for making bullets in a shmup (that is until you see the rival exceeding 200 sprites via multiplexing...),
but the worst limitation is having only 2 sizes per screen, that's worse than the 512 tile limit...

For Sonic 1, I only see how to port it if you use sizes of 16/32 and change the tiles via DMA, and it needs to be a super optimized code to update the whole game. In my port, if I put Tails next to Sonic, the frame rate already drops to 30,
and I'm using fast-rom and currently hi-rom mapper.

Sure, using an SA-1 in the cartridge, the performance problems disappear instantly,
but the best thing is to use the console in stock form
The SNES is incredible when it comes to colors, backgrounds, and effects, but it lacks a 320x224 resolution mode and a decent sprite engine.
In that respect, the Genesis, and also the PC-Engine, blow the SNES out of the water.

[turboxray]

New demo video:
https://www.youtube.com/watch?v=1fW0EJUe3fk

Looks better than the last demo, and works pretty well here!

[olddb]

Any remarks regarding your accurate animations for the Mega Drive DKC demo? How do you get them so close?

But my main difficulty, which used to include the sound driver,
but now i find it easier to stream samples via HDMA + sequential music on the SPC700,

Isn't this method ill-suited regarding the limited ROM space?

[93143]

Streaming samples (whether instrument or sound effect samples) isn't nearly as bad as streaming prerecorded music.

[TiagoSC]

Any remarks regarding your accurate animations for the Mega Drive DKC demo? How do you get them so close?

But my main difficulty, which used to include the sound driver,
but now i find it easier to stream samples via HDMA + sequential music on the SPC700,

Isn't this method ill-suited regarding the limited ROM space?

The physics in DKC are simpler and more basic than in Sonic, many things are the same in various games.
I had to do the animation by observing the original sprites frame-by-frame, the conversion of the artwork to Genesis was done by my friend Gabriel Pyron, who is very skilled.

Regarding sample streaming, i use it for SFX and voices that wouldn't fit in the audio RAM, for example: the voices of the fighters in a fighting game can all be stored in the ROM and when needed, they can be streamed via HDMA.

Another advantage is saving audio RAM, as streaming only uses 2Kbytes for a ring buffer, thus freeing up more space for more and better instrument samples.

In addition to streaming, the driver plays sequential music in 8 channels + 8 channels for SFX (sfx interrupt the physical channels when necessary).

The sample size is only limited by the ROM size; I can stream an entire song if I want.

Using HDMA for streaming saves CPU cycles for better game performance.

[olddb]

Thank you for your reply and time.

Another advantage is saving audio RAM, as streaming only uses 2Kbytes for a ring buffer, thus freeing up more space for more and better instrument samples.

Can you point me in the right direction in order to achieve this?

[TiagoSC]

Thank you for your reply and time.

Another advantage is saving audio RAM, as streaming only uses 2Kbytes for a ring buffer, thus freeing up more space for more and better instrument samples.

Can you point me in the right direction in order to achieve this?

My code for HDMA streaming is based on an idea i read here on Nesdev, i don't remember if it was the member 93143 or Lidnariq, so most of the credit goes to them. I don't know if my method are the best, but for my uses it worked well:

Streaming to the audio RAM requires passing bytes via the SPC700 ports so it can write those bytes to the ringbuffer, which is only 1152 bytes.
A major problem is the sound driver synchronization, if you use the SPC700's internal timers, synchronization with the 65816 becomes complicated because there's no interrupt to indicate when to update the SPC700 ports.

My solution was to have the 65816 synchronize the sound driver via VBLANK, in each execution of VBL, the 65816 writes a command to the SPC700 port indicating that the sound driver can now update. This acts as the general timer and synchronization for the sound driver, also, in every VBL operation, the 65816 writes a list of commands when it needs to play an SFX, start a song, start/update a stream, etc.

With this synchronization working, streaming becomes easy, when a command to start streaming is sent (on VBL), the sound driver starts the next frame already waiting to read the HDMA data from the ports (in a loop reading the ports).
Two HDMA channels are used, channels 6 and 7.

I limited the samples to 7680Hz to avoid using too much ROM, with 72 bytes written in each frame (60 frames * 72), 4320 bytes per second.

36 scanlines are used to update the stream frame, in VBL, the 65816 increments the source position in 72-byte blocks.

HDMA channel 7 controls the scanline counter on port 2141 of the SPC700. It reads a table with the numbers 1 to 36 and a $FF token at the end to inform the sound driver that the streaming block in that frame has finished, after that, the sound driver can update the music and SFX for this same frame.

The HDMA channel 6 (indirect mode) writes 2 bytes, 1 to each port 2142/2143.

The sound driver, after confirming the current scanline, reads these 2 bytes and writes them to the ringbuffer in the sound RAM and updates the ringbuffer position.

The streaming is played on channel 7 of the sound DSP using the ringbuffer as source sample via doublebuffer, while one half of the ringbuffer is playing on the DSP, the other half is being written by the streaming.

Since the synchronization is now done via VBL, you have to create 2 versions, one NTSC(60) and another PAL(50), but this is not difficult to work around, even automatically via code.

[olddb]

This method is very clever.
So as I understand, the sound system becomes locked to the display, like on the NES.
Does anyone knows of any during-market game that uses something similar?

Downside of this I can think of (besides NTSC vs PAL) is that some tempos would be difficult to reproduce, right?

A major problem is the sound driver synchronization, if you use the SPC700's internal timers, synchronization with the 65816 becomes complicated because there's no interrupt to indicate when to update the SPC700 ports.

Wonder why Nintendo didn't implement a proper synchronization system for the SPC700.
Now I'm curious: The Mega Drive uses a z80 for sound, right? Is there a way to synchronize it properly with the main CPU?

Thanks for the reply.