Jump to content


Photo

Playing around with the in-game tune in JSW


  • Please log in to reply
23 replies to this topic

#21 IRF

IRF

    Advanced Member

  • Contributor
  • 4,307 posts

Posted 04 March 2017 - 10:40 PM

Here's another quirky tune-related effect: to make the in-game tune play backwards, insert a CPL command immediately prior to the AND #7E command at #8B47 in the Main Loop.

 

This requires a bit of consolidation in order to insert the extra byte, but I've just noticed a one-byte efficiency that can be achieved in this part of the JSW code.  [Which would also be useful in implementing the effect of slowing the music down to half speed by inserting an extra RRCA instruction, as detailed in the second post in this thread.]  The efficiency is as follows:

 

At #8B4B, there is a LD D, #00 command, which takes up two bytes.  But at #8B3C, there is a single-byte XOR A command which sets A to zero.  So if a single-byte LD D, A command is inserted before the value of A gets altered from zero, then one byte can be saved overall - thereby allowing the above to be implemented.

 

You can test this out by making the following quick alterations to the hex code of Dr Andrew Broad's game ylliW teS teJ (a.k.a. MIRRORJSW):

 

- Clear the LD D, #00 from #8B4B-4C;

- Shift the code from #8B47-4A along by two bytes, to occupy #8B49-4C;

- At #8B48, insert a CPL instruction (opcode '2F');

- Shift the code from #8B40-46 along by one byte, to occupy #8B41-47;

- At #8B40, insert a LD D, A command (opcode '57').

 

In the unedited version of MirrorJSW, the in-game tune already plays backwards - but I believe that Andrew achieved this by manually physically inverting the positions of all the 'notes' in the range of addresses #865F-#869E. (i.e. the value '56' at #865F in the original JSW is located at #869E in MirrorJSW, whilst the value '40' at #869E in original JSW occupies #865F in MirrorJSW'; the value '60' which was originally at #8660 is shifted to #869D in the mirrored game, etc.)

 

By making the above changes to the Main Loop (which only require 14 POKES to achieve), you will find that the in-game tune gets reverted back to being played 'forwards' (with all the notes in the correct order) - thus proving the effectiveness of the solution which I have come up with for 'reversing' the tune.


Edited by IRF, 04 March 2017 - 11:09 PM.


#22 IRF

IRF

    Advanced Member

  • Contributor
  • 4,307 posts

Posted 04 March 2017 - 11:01 PM

P.S.  Reversing the order of the notes for the Title Screen tune can be achieved by just three POKES:

 

- At #88A9-AA, insert '5D 86', to point the 'Title Screen' routine to the final note in the first instance;

- At #96C6, replace the INC HL (opcode '23') with a DEC HL (opcode '2B') command, to make the 'Play the theme tune' subroutine select the notes in reverse order.

 

However, this means that there is no longer a terminating 'FF' byte at the end (formerly the beginning) of the tune, so the program plays random notes (code interpreted as data) for some time, until it eventually chances upon a value 'FF' and proceeds to the Scrolling Message.  (The WRITETYPER look-up table immediately precedes the Title Screen tune data in the code, so it isn't easy to insert the 'FF' marker here.)

 

Again, you can test out the above by applying it to Andrew Broad's 'ylliW teS teJ', in which the order of the Title Screen tune notes have all been manually reversed (actually, the process might have been done automatically via software; perhaps "physically reversed" would be a better turn of phrase?)  Applying the above code changes to the mirrored game file causes the notes to be played in the correct (original) order.

 

 

******

 

P.P.S.  It would be fun to edit the code which normally generates the 'falling pitch' sound effect during the Scrolling Message, in such a way that the sound rises in pitch instead as the message progresses!  I haven't investigated that in detail yet, but first thoughts are that a CPL or a NEG command could be inserted at or around #88DE, with some modification to the ADD A, #32 thereabouts (changing it to a SUB A and/or changing the value of the operand).

EDIT: It can be done by adding a CPL ('2F'), immediately prior to the ADD at #88DE, and then making the latter an ADD A, #52 ('C6 52').  One additional byte needs to be inserted, which can be achieved by replacing the CP #01 at #88EA-EB with a DEC A ('3D') and shuffling down the intervening 10 bytes (12 bytes if you include the ADD command).

It's quite a cool effect; strangely familiar yet quite different!!


Edited by IRF, 04 March 2017 - 11:39 PM.


#23 jetsetdanny

jetsetdanny

    Advanced Member

  • Contributor
  • 2,164 posts

Posted 06 March 2017 - 05:35 PM

Nice tricks, Ian!  :)

 

Such modifications can serve to enhance future projects, just to give them a familiar yet distinct flavour.


  • IRF likes this

#24 IRF

IRF

    Advanced Member

  • Contributor
  • 4,307 posts

Posted 06 March 2017 - 05:56 PM

Nice tricks, Ian!  :)

 

Such modifications can serve to enhance future projects, just to give them a familiar yet distinct flavour.

 

Or it could be implemented on a 'per room' basis - I think The Nightmare Room in 'WRN' might feature a backwards tune (to match Willy's backwards Flying Pig sprite)!






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users