• 0

# YM2151 easy note conversion?

## Question

Hi all,

Today I found out by trial and error, that the YM2151 has a weird note encoding. I am talking about the semi tones within an octave. The YM2151 accepts a 4 bit value as semi tone ("NOTE"). Naturally, I would expect the note values to range from 0 to 11 to accommodate for all 12 semi tones. However, the 12 semi tones are spread across the 0...15 range, thus leaving note duplicates in between. (This seems really strange to me, but anyway, I have to deal with it).

One possible conversion rule (0...11) --> (0...15) that I found was multiplying X by 4/3 and then rounding down.

The conversion rule (0...15) --> (0...11) that I found is: take X and subtract from it the result of integer division X/4

Now, I am interested in a cheap way to get from the 0...11 range to the 0...15 range. I did it with a lookup table, but maybe there is another way that gets away with fewer bytes (12 bytes lookup table + 4 bytes code: TAX      LDA semitones_ym2151, X )

Any ideas? If not, I'll accept it as it is ... at least, looking up a value is nicely quick

Edited by kliepatsch
TAX is just 1 byte

## Recommended Posts

• 0

This is the fastest routine I can quickly think of:

LDA semitone ; not counting this as this has to happen no matter what alg is used
CMP #9 ; 2 cycles
BCS @add3  ; 2 | 3 cycles
CMP #6 ; 2
BCS @add2 ; 2 | 3
CMP #3 ; 2
BCS @add1 ; 2 | 3
INC ; 2
INC ; 2
INC ; 2
ORA octave ; 4 ; assume octave is stored pre-shifted into 4 msb
STA keycode ; same as LDA semitone

So the number of cycles is: 2 + (9|11|13|13) + 4 --> average of 17.5 cycles - so let's call it 18 cycles.
a lookup would be something more like:

LDX semitone
LDA kc_lut,X ; 4+
ORA octave ; 4
STA keycode

So twice as fast, requiring 12 bytes of RAM.

Given that this operation doesn't happen super-often (pretty much only up to 8 times per frame?) I'd call this "pitayta-pitatta" / "six in one hand, half a dozen in the other" / pick your idiom. In the end, 12 bytes of RAM ain't much to sacrifice, plus the code's a lot easier to read, too.

##### Share on other sites

• 0

Thanks for your effort at it! After posting the question I felt a little paranoid  I just see my codebase growing because of details like this, and at the same time, I'd like to keep the program as small and simple as possible ... But you are right, 12 bytes shouldn't be such a big deal, after all

##### Share on other sites

• 0

.org "RODATA"
kc_lut: .byte \$00, \$01, \$02, \$04, \$05, \$06, \$08, \$09, \$0A, \$0C, \$0D, \$0E

Yeah, that's pretty succinct.

## Join the conversation

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

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.