The routine is still playing a linear keyboard. The only changes are the compression of the data, the redrawing of the keyboard, the full key light up and removal of the silent keyboard light ups.
Long time since I looked at the routine. A quick glance does indicate I could change to a key reference lookup quite easily. E.g. permit each note to designate a value for its true key position. Not something I would bother to do.
If there was space in memory for it, then the following code could be adapted for the purpose. (It's something which I came up with for Daniel Gromann's recent 48K conversion of Fabian Alvarez Lopez's 128K JSW game 'Madam Blavskja's Carnival Macabre'.)
At #C040 - #C05F, a lookup table of 'Pitch versus attributes' is stored. The first half of that table (#C040 - #C04F) contains pitch values used by the notes of the title-screen tune. The second half of the table (#C050 - #C05F) contains attribute values corresponding with each note, which will be used as the INK colour for the game's title printed at the top of the title screen.
The following subroutine is called from the 'Play the title tune' routine, immediately after the check for a #FF Terminator byte but before the note is actually played. Going into the subroutine, HL points at the pitch value of the note which is about to be played.
LD A,(HL) pick up the pitch value of the note which is about to be played, and store it in A
PUSH HL save HL (which points at the current note) onto the stack
LD HL,#C040 point HL at the start of the lookup table at #C040
LD BC,#0010 we will search through #10 pairs of entries (16 in decimal)
CPIR do the search – the CPIR loop stops when it reaches a value from the first half of the table which matches the pitch of the current note
LD BC,#000F then we need to consult the second half of the table to find the corresponding attribute value
ADD HL,BC adding #0F (15 in decimal) because the last iteration of the CPIR loop incremented HL once more after a match had been found
LD A,(HL) pick up the attribute value to be used to colour the game title, and store it in A
LD HL,#5800 point HL at the first character of the title screen to be coloured
LD (HL),A colour it using the attribute value picked up from the tableLD DE,#5801 point DE at the second byte to be modifiedLD BC,#007F 128 bytes will be modifiedLDIR modify them
POP HL restore the pitch value of the note which is about to be played to HL
RET return back to the main 'Play the title-screen/Came Completed screen tune' routine to play the note
In this case, the second half of the table wouldn't contain different attribute values for each note (rendering the same element of the screen in different colours according to the note being played), but instead would need to hold values for the low byte of the attribute address corresponding to the appropriate piano key for each note played (which would thus be coloured in with a fixed attribute value, and then reverted back to white after the note has finished being played).
Of course the table could be stored anywhere convenient in memory; it wouldn't have to be at #C040-5F. And the size of the table should be adjusted as appropriate to accommodate the number of different pitch values in the tune (with BC assigned a value equal to the number of different pitch values in the first instance, and then the number of different pitch values minus one in the second instance that BC is defined).
Edited by IRF, 14 April 2020 - 12:25 PM.