Jump to content


Manic Miner in 48k with 40 rooms

48k 40 room editor

  • Please log in to reply
61 replies to this topic

#61 IRF


    Advanced Member

  • Contributor
  • 4,411 posts

Posted 14 April 2020 - 12:24 PM

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 table

LD DE,#5801   point DE at the second byte to be modified
LD BC,#007F   128 bytes will be modified
LDIR                 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.

#62 IRF


    Advanced Member

  • Contributor
  • 4,411 posts

Posted 14 April 2020 - 06:41 PM

Of course, the time-consuming bit would be working out all the datapoints for the table...

Also tagged with one or more of these keywords: 48k, 40 room, editor

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users