What is happening in this algorithm scaling an 8-bit 0-99 value to full-range 16-bit?

Question

Can anyone help me understand what is happening inside this algorithm scaling an 8-bit value to 16-bit?

PATCH_LOAD_QUANTISE_VALUE:
 ASLA
 LDAB    #165
 MUL
 ASLB
 ROLA
 RTS

https://github.com/ajxs/yamaha_dx7_rom_disassembly/blob/master/yamaha_dx7_rom_v1.8.asm#L7378

A while ago I completed a project reverse-engineering some 8-bit synthesizer firmware. One commonly used function in the firmware converted a value serialised in the range 0-99, to its internal 16-bit representation in the range 0-65535.

I don't have much experience with programming for retro systems, so I've never encountered this kind of algorithm before. I suspect there's some common method for deriving the magic number 165 in the subroutine.

Any help understanding what I'm looking at would be appreciated. Thank you!

Answer 1

Technically, this is just scaling, as quantization means a completely different process.

That's simply a multiplication, done with an algorithm which exploits the range of used numbers and avoids the limitations of the HD6303 MCU to calculate result quickly with one MUL instruction and avoiding use of temporary RAM variables for intermediate results.

To scale range of 0..99 to 0..65535, you would need to multiply 99 by approximately 662.

The HD6303 can only multiply two 8-bit values together, from registers A and B, and the 16-bit output result will be in 8-bit registers A and B, collecively called the 16-bit register D.

So as 662 does not fit into 8-bit register, the operation must be split up. Generally how this would be done is to do it in software and use the MUL opcode several times to be able to perform a 16x8 multiplication and use memory for storing intermediate results. Sort of same thing when you do multi-digit multiplication with pen and paper.

So while this could be done by implementing a general subroutine for multiplication of two larger numbers, it would be somewhat slower.

By exploiting the range of input numbers and sacrificing precision only slightly, it can be done extemely quickly with a single MUL operation and without using any memory for intermediate storage so the values are kept in registers.

The original multiplier is 662. It won't fit into 8 bits. Dividing it by 4 gives 165 which does fit into 8 bits.

The original input value is up to 99. It fits into 8 bits.

So the 99 could be multiplied with 165, and the result would fit to 16 bit register D. However it would still need multiplication by 4, which would equal to two rounds of shift/rotate.

Pre-multiplying the 99 by 2 by shifting left once also fits into 8 bits and can be multiplied. Therefore the result in D only needs to be multiplied by 2 by one round of shift/rotate to get the correct range.

So in pseudocode, it's just

D=660*A

but calculated as

D = (((A*2) * 165) *2)

Answer 2

The algorithm is called "multiplication".

The code appears to compute A×2×165×2, which simplifies to A×660. This linearly maps the range 0–99 into 0–65,340.

I don't know the 6303, but presumably the code does it this way because loading an 8-bit constant (165) and shifting twice is faster than loading a 16-bit constant (660).

Answer 3

If you look at what's happening step for step, you can see where the 165 is coming from:

• A is multiplied by 2 (ASLA)
• A*2 is now multipled by "magic" value 165 (LDAB #165, MUL)
• Result (HI part in A, LO part in B) is multiplied by 2 as 16-bit quantity (ASLB, ROLA)

So if A is 99 (full scale), 99*2 = 198, 198*165 = 32670, 32670*2 = 65340 - in other words, the magic constant is just the scaling factor of 65340/99/4 = 165

The approach of multiplying (((A by 2) by 165) by 2) to achieve a multiplication by 660 is likely done as an architecture specific optimization and to be able to use MUL with 8-bit quantities (knowing A by 2 will always fit in 8 bits).