Jump to content

New demo uploaded: Off The Floor (music demo)


kliepatsch
 Share

Recommended Posts

Off The Floor (music demo)

View File

A simple 8-bar loop song bringing you some dance floor vibes.

To reduce jitter and audio dropouts, run the demo locally.

It uses all 16 PSG voices and a couple of FM voices.

Would you like to code some graphics to be accommodated by this song? Send me a PM 🙂


 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

A lot more of this uses the YM than I expected. It sounds great.

I just tried patching it in MON to run on R39 so I could watch the PSG / YM2151 monitor overlays in Box16 while it plays.

Of course the song is out-of-tune as the YM runs at a lower clock speed on R39... I'd have transposed that too, but finding the note data is much harder than finding "STA $9FE0" though.

 

  • Like 1
Link to comment
Share on other sites

Th PSG is mostly occupied with generating the supersaw sound. Three oscillators per voice isn't much for a supersaw 😄 Most of the other things are FM sounds.

I am surprised that you got it running in R39, apparently. Concerto uses r0 to communicate. And in R38, r0 is the same as the bank switches in R39, so in R39, Concerto would randomly switch banks 😄

Edited by kliepatsch
Link to comment
Share on other sites

On 11/15/2021 at 9:44 AM, kliepatsch said:

And in R38, r0 is the same as the bank switches in R39, so in R39, Concerto would randomly switch banks

Well, if your program doesn't actually use banked memory, it doesn't really matter which bank is currently in the window. The bank latch still functions as normal memory would, since it's readable.

The Kernal doesn't assume "the correct bank is already there" whenever it runs, so it banks in 0 and then restores whatever bank was there when it started. So if you're outside the kernal, you never see it change because Kernal only does this during an IRQ or direct calls to its functions (which also fix any bank changes they may perform).

@desertfish - this isn't a MOD (digital samples) - this is pure synth.

Link to comment
Share on other sites

On 11/15/2021 at 4:05 PM, ZeroByte said:

Of course the song is out-of-tune as the YM runs at a lower clock speed on R39... I'd have transposed that too, but finding the note data is much harder than finding "STA $9FE0" though.

At $2B5C, there should be a command SBC #3, which is responsible for transposing the notes sent to the YM2151. If you find it, you might mess with that. Of course, it won't fix that the envelopes were programmed for a faster clock speed, but at least it won't sound utterly horrible 😉

Link to comment
Share on other sites

SBC #3 seems odd to me - the YM is off by one whole step from what I can tell, not 3 semitones. I just tried patching that with SBC #0 and it didn't fix the transposition.

Just changed it to SBC #1 and that works properly. It's neat watching all the sliders dancing around in the debug overlays in Box16 🙂

Here it is patched for R39 in case anyone's interested in checking it out on Box16:

OFFTFLR39.PRG

Edited by ZeroByte
  • Like 1
Link to comment
Share on other sites

Wow, the audio debugger views are indeed awesome in Box16!

And it's healthy to know that Concerto doesn't work properly with -ymstrict enabled. Even though I have put much thought into how to limit communication with the YM2151, it might require more work to fix it.

Edit: found the issue. I have attached another patch that works in Box16 even with -ymstrict enabled (i.e., the real behavior of the YM2151 being "busy" after writing a byte is emulated).

OFFTFL392.PRG

Edited by kliepatsch
-ymstrict mode fixed.
Link to comment
Share on other sites

On 11/15/2021 at 2:03 PM, kliepatsch said:

And it's healthy to know that Concerto doesn't work properly with -ymstrict enabled. Even though I have put much thought into how to limit communication with the YM2151, it might require more work to fix it.

I figured it wouldn't when I was patching your program. Firstly, I didn't read back far enough to see whether you were checking the busy flag or not, but I didn't notice any reads from $9FE1. Reading this address (or $9F41 on R39) returns the status byte, which contains the IRQ status flags (the two least-significant bits) and the busy flag (most significant bit.) If the MSB is high, then the chip is busy and will drop any data you attempt to write to it.

My typical code looks like this:
: bit YM_data
bmi :-
sta YM_addr
nop
stx YM_data

The NOP is because the YM needs a moment to re-settle the latch after having it pointed at a new internal register. Just one seems to be enough.
 

Edited by ZeroByte
Link to comment
Share on other sites

On 11/15/2021 at 7:55 PM, ZeroByte said:

SBC #3 seems odd to me - the YM is off by one whole step from what I can tell, not 3 semitones.

Found the reason behind this: for some reason, the YM starts an octave with C#, not C (see Fig. 2.4 in the manual of the YM). That explains why I have to subtract not 2 but 3 to get from the MIDI note to the YM's note value (and then after that still do this weird 0...11 to 0...15 range conversion)

Edited by kliepatsch
Link to comment
Share on other sites

On 11/22/2021 at 4:29 AM, kliepatsch said:

for some reason, the YM starts an octave with C#, not C

Yeah, and why that oddball spacing instead of simply note=0x00..0x0C ?

There are lots of head-scratchers in the design of YM2151 that I'm sure would make more sense if you knew what specific hardware design issues were being addressed.

Others that confound me:

Why aren't AMD and PMD two different registers? For those who don't know - Register 0x19 = AMD/PMD. If you write a value 00-7F, that sets the AMD. If you write a value 80-FF, that sets the PMD. Yet, register 0x1A is unused - why not just make 0x19=AMD, and 0x20=PMD?

Why are the per-operator ADSR gate bits in the KeyUP/DN register not shifted by one more bit to make them nybble aligned? It'd be so much more obvious that $F2 = key dn for on all 4 operators on voice 2. Nope. It's $7A to do that.

Link to comment
Share on other sites

On 11/15/2021 at 4:51 PM, Scott Robison said:

Sounds similar to trying to use the VDC on the C128.

After watching your video, I agree it's quite similar. You need to set the data port to point at a particular internal address, then write a value into that slot, and then wait for the chip to chew and swallow. 🙂

VERA, on the other hand is like a frat boy funneling beer. Once you have your data port configured, you can hit it with the fire hose.

Edited by ZeroByte
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use