IRF

Further to the above, I've made a short recording (see attached) to demonstrate a 'proper toilet run' incorporating The Nightmare Room. Look at his little trotters go! As it turned out, no use of the 'P' key bug to pause* Willy in order to avoid guardians was actually necessary - though it was a close-run thing with the red Maria! That's just as well, because in the test file that I previously prepared to demonstrate the alternative toilet run - upon which I based the recording - I had 'fixed' the 'P' key bug so it no longer functions to pause the toilet run. (Incidentally, I also fixed the 'jagged finger' visual flaw identified by Norman Sword, since it was particularly prominent during the toilet dash what with the sprite moving so fast.) In the recording I also started off the toilet run in The Banyan Tree, to extend the run as much as possible, and as an added bonus I hit the Jump and Right keys just before applying the POKE to commence the sequence, so that it starts off with a nice 'Superjump' over the yellow saw guardian. B) (* 'P' for 'Pause'? Hmmm..... maybe it was a feature not a bug all along!?) Proper Toilet Run through Nightmare Room.rzx

UPDATE: It's just occurred to me that if you were to implement the above, and then instigate the toilet run in The Nightmare Room, the pig sprite would run with its little legs without flapping its wings! If you load up the 'Proper Toilet Run' test file which I attached four posts above this one, start the game & navigate to The Nightmare Room (preferably the left-hand side of that room to see the effect in full), and then apply Mickey's POKE 34271,2 then you can see what I mean. From that position, you should be able to complete the game too (possibly with some judicious use of the 'P' key to dodge the Nightmare Room guardians), as once you leave that room and revert back to the Willy sprite, there's just a straight run up the full length of the ramp in First Landing and on to The Bathroom!

P.S. If you wanted a pure tone of #40, then you would need to use a pair of pitch values #40 and #20. (I don't think it would matter in which order the two values are stored in the data, as long as one is half the value of t'other.) In terms of Andrew's original JSW->MM conversion, the upshot is that the pure tone version of 'Moonlight Sonata' plays the lower pitched half of each note (as if the doubling of pitch that you get in the JSW engine was applied immediately, instead of halfway through each note). Rather than only playing the higher pitched half of each note (which is what you get if you just NOP out the RL E command from #96BC in the JSW game engine).

Explanation for the above: say you had a set of three pitch values for a MM title tune note of #32 [the duration], #40 and #80 [pair of pitch values]. Those values are assigned to the C, D and E registers respectively. The inner note playing loop decrements D and E once for each pass through the loop, and when either of those reaches zero then an XOR #18 command is executed - meaning that the speaker state will be toggled at the start of the next pass through the inner loop - before D or E is reset back to its original value for this note. (The inner loop is controlled by the B register, which is set to #00 at the start, and that effectively means #100 iterations since B is decremented to #FF before a check for a zero value is made. The outer loop decrements C to repeat all of the above C times, meaning that the duration of the note is C x #100 iterations of the inner loop [#3200 iterations in the above example].) But if you have two pitch values which are exactly separated by a factor of 2, as in the above example, then the following happens: On the #40th iteration of the inner loop, D has reached zero so an XOR #18 activates the speaker. On the #80th iteration of the inner loop, D and E both reach zero so XOR #18 is executed twice; those operations cancel each other out*, so the speaker is not activated. On the #C0th iteration, D has reached zero again so XOR #18 activates the speaker. On the #100th iteration, D and E both reach zero so XOR #18 is executed twice; those operations cancel each other out, so the speaker is not activated. B has now reached zero which brings an end to the inner loop for now. Then C is decremented and the whole of the above is repeated, until C reaches zero, bringing the outer loop to an end. (Then there is a check for whether the ENTER key is being pressed to start the game - if not, then the next note will be played [next set of three note definition bytes will be considered].) If you look at the above pattern, you can see that - except for in the very first instance shortly after the start of the loop - the speaker diaphragm is only actually activated once every #80 passes through the inner loop. So the note that is played has a pitch of #80, corresponding to the lower of the two pitches represented by the note data (i.e. the numerically higher of the two pitch values, since a smaller number yields a higher pitch and vice versa). (* Applying XOR #18 to the A register, and then applying another XOR #18 to A, is effectively the same as applying XOR #00, which has no effect on the value in A.)

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

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'.)

Norman, am I right in thinking that the piano keys on the title screen now light up 'correctly'? i.e. they accurately represent the notes which are being played at the time, so that if you were to reproduce the visual pattern on a real piano then you would end up playing the tune faithfully? And assuming that is the case, then I have a follow-up query: are the appropriate attribute addresses on the screen worked out in your rewritten version of the title-tune routine, using a logarithmic calculation method (as opposed to the linear method in the original MM, which leads to incorrect keys being highlighted)? Or alternatively, does your rewritten routine use a look-up table to determine which piano keys (i.e. which attribute addresses on the screen) to highlight, based on what note (i.e. which pitch value) is being played?

EDIT: The files upon which the attached test files were based are Copyright of Broadsoft (2004). Many years ago, Dr Andrew Broad created a conversion of Jet Set Willy to the Manic Miner game engine, and conversely, a conversion of Manic Miner to the Jet Set Willy game engine. They were released as 'Easter eggs' in the 'Party Willy' box set. This topic concerns itself purely with the title-screen tunes in both conversions, which are 'remixes of the original tunes for the new game engine'. I have analysed the title tunes, and created updated versions of each conversion with the aim of finessing these 'remixes' - hopefully capturing the spirit of what Andrew was originally trying to achieve. And since Easter is upon us, and everyone presumably has lots of spare time on their hands at the moment, I thought I'd share them with you. :) ******** The MM->JSW conversion features a rendition of MM's title tune 'The Blue Danube', complete with the 'octave-shifting' modulation that you normally hear in the JSW theme tune. Thus Andrew managed to capture rather well the atmosphere of the JSW title screen in the MM->JSW conversion. :) However, I would say there are a couple of flaws in that rendition: (1) There were a few notes [directly taken from Matthew Smith's original score of the tune] which dropped below Middle C, causing erratic, very high-pitched notes to play. This happens because if you have a value higher than #80 and try to double the pitch (via the RL E command in the 'Play the theme tune' routine), then the highest bit drops off the end of the byte. This is a flaw in Matthew's title tune routine; it should really detect the Carry Flag being set in such circumstances and adjust the note-playing loop accordingly. So that's what I've done in the attached update of the MM->JSW conversion, by inserting a four-byte intervention into that routine. Now if the RL E command sets the Carry Flag, the value in E is simply overwritten with #00. (This is a fixed pitch value - corresponding with Bottom C - but it isn't too far off being an octave below the problematic notes in question, because they all happen to hold a pitch value of #88 - Middle B. However, the effectiveness of this crude patch would probably break down if you tried to play notes much lower down the scale.) (2) Andrew's JSW-style rendition of 'The Blue Danube' also seemed to finish rather hurriedly. In original MM, some of the notes towards the end of the tune are played for twice the duration of the rest of the tune's notes. However, it isn't possible to assign notes of differing lengths for the title tune in the JSW game engine. But since there were a few spare bytes available at the end of the score*, in the attached update to MM->JSW I have taken the opportunity to insert a couple of additional notes (so that there are two consecutive notes of identical pitch, where in MM there would be a single note of that pitch set to play for twice the duration), in order to keep the tune going at a constant pace until the end. [* Arising from the fact that JSW's Moonlight Sonata is 99 bytes long, whereas MM's Blue Danube is 95x3 bytes and so Andrew had inserted 95 pitch values into the regular 'JSW title tune' area of memory.] ******** Andrew's JSW->MM conversion plays a pure tone version of JSW's title tune 'Moonlight Sonata'. It achieves this by making each pair of notes consist of one value (x) followed by a note with exactly double the pitch value (2x). This seems to turn off** the 'dischordancy' feature of the tune that you normally hear. i.e. when 'The Blue Danube' is playing in the original MM. [** Incidentally, looking at the Manic Miner title tune-playing routine, I can see why that would have the effect of generating pure tones, although I can't recall this ever being discussed - either here or on the Yahoo! Group - as an available technique to employ when creating MM title-screen tunes?] However, I think an opportunity was missed there to have 'Moonlight Sonata' playing in a dischordant manner, in order to give a more 'Manic Miner'-like flavour to the title-screen tune of the JSW->MM conversion. Furthermore, Andrew's rendition of 'Moonlight Sonata' in the MM engine cuts off a few notes early, because the original MM title tune consists of 95 pairs of notes (i.e. 95 sets of three bytes, one determining length and two for pitch), whereas the JSW tune is 99 bytes long (each byte corresponding to a note which is played at a higher pitch for half of its duration, before the pitch is doubled for the second half of the note). So converting the JSW tune's score into a 99x3 byte tune wouldn't fit into the space in memory where the MM theme tune is stored. Finally, all the notes in Andrew's 'Moonlight Sonata Manic Miner Remix' are of exactly the same duration. This is consistent with the original title tune in JSW, where the length of each note is the same, but it does mean that another available feature of the MM game engine's tune-playing routine (the ability to play notes of different length) isn't taken advantage of. ...So, after reflecting on all of the above... Please find attached an updated version of JSW->MM [which, as per Andrew's original version, is in three parts, because there are 60 playable rooms in JSW and the MM game engine can only handle 20 caverns]. Hopefully you will agree that this is a much more 'Manic Miner-esque' rendition of 'Moonlight Sonata', befitting of this JSW->MM conversion! ;) I also took the opportunity of extending the title tune to its full, original length (99 notes, or rather 99 sets of three bytes now). That ate into the space in memory where the in-game tune is stored, and so in order to compensate for that, I replaced what was left of 'If I were a Rich Man' with Andrew Broad's 'remix' of 'Hall of the Mountain King'*** from the SE of his game 'Manic Miner 4'. That rendition repeats 32 identical sets of notes twice, so I tweaked a command in the tune-playing part of the Main Loop so that the in-game tune is just 32 bytes long. [*** I confess that it's not ideal not to have '...Rich Man' playing in a variant of JSW, but there is a history of '...Mountain King' being used instead in some releases of JSW (back in the day when it was thought that an 8-bit rendition of a tune from a West End Musical might constitute some outrageous breach of copyright!) And it was a quick and easy fix; I didn't want to carry out major code-shuffling to fit both the extended title tune and a 64-byte in-game tune into the available space, but nor did I want to leave a random half-tune playing once the game starts up.] One last point of interest is that the final, sustained note of 'Moonlight Sonata' in the attached file has a duration of #00 [i.e. the value of the first of the three bytes which define the parameters of the last note]. This is the longest possible duration of a note in the game engine - it is interpreted as a value of #100 (256 in decimal) to define the length of the note-playing loop, rather than a value of zero, because the register to which it is copied is decremented (to #FF / 255 in decimal) before a check is made of whether a zero value has been reached yet. The Blue Danube in JSW style.TAP Moonlight Sonata in MM style_1.TAP Moonlight Sonata in MM style_2.TAP Moonlight Sonata in MM style_3.TAP

Geoff, many years ago you laid down a gauntlet in the Readme file for your game 'Willy Takes a Trip': Well, I've taken up the challenge (nearly two decades later!) There were actually a few bum notes, and furthermore the final note seemed to go on a bit too long. Anyway, please listen to the attached file, in which I've 'fixed' the title tune. :) wtrip - bum notes on title tune fixed.tap

With regards to the above, I have tried all the methods I could think of to collect this item without (ultimately) losing a life, and failed - see the attached recording. Even with my suggestion of standing on the conveyor pressing the 'upstream' key after collecting the item, you don't last long because the horizontal 'picture frame' guardian will get you soon enough! (And if that doesn't, then an arrow will!) (N.B. To create the recording, I changed the game's starting position to directly underneath the item in question, so that if I collected the item but died in the process, I could press SHIFT+SPACE and try again without having to repeat the very tricky manoeuvres required to reach that position in the first place!) Danny, did you think of a way that I haven't tried in the recording? Headmistress Office Item.rzx

Hi Geoff, I thought you might be interested* to know about a bug in the Geoff Mode game engine which I discovered a while ago, along with the single-byte fix for it: http://jswmm.co.uk/topic/182-useful-links/?p=6726 (*Or you might not be interested! :lol: )

I think Danny gets most of the credit, I've only playtested one room!

In the attached recording, I managed to cross 'The Backyard - The School Wall' from left to right, collecting both items in the process, twice (once via the 'high route' and once via the 'low route'). At the end of the first half of the recording, you can see the problem with the white barrel guardian in 'A Bunch of Trees - Another Wall' crashing into a tree branch (killing Willy - or is it Jason?). I then reset the game using SHIFT+SPACE to restart. At the end of the second half of the recording, you can see another problem with the interface between those two rooms - if you exit 'Backyard' at a slightly higher level (two rows above the floor), then you enter into an Infinite Death Scenario in 'Bunch of Trees', because of the placement of a Fire cell near the left edge of the latter room. Roddenwald Backyard Left to Right x2.rzx

Yes. Both items after jumping over the bicycle guardian, and then restarted and collected both items after climbing up inside the tree trunk. RZX - later on tonight, when I get a chance. (Though I suspect you'll be tempted to beat me to it!)

Are they supposed to be shadows?

I just managed it by both methods (i.e. via the 'low route' and the 'high route'). Simples! B) The biggest problem I encountered was that the emulator crashed as soon as I loaded up the game file! (That was in QAOP - but I then managed to get it working in SPIN.)

The tree trunk is just made of Water cells (not Earth), so no difficulty passing through it, surely?

It looks like it's the other way round to me - passable from left to right, but NOT from right to left? The items look easily collectable as well?

Fabian, it seems that so far you have only commented on Danny's 'Playtest No 1', but not on his comments on 'Playtest No 2' from the bottom of this post: http://jswmm.co.uk/topic/532-jet-set-jason-in-rodd%C3%ABnwald-alpha/page-3?do=findComment&comment=11773 I wonder if you scrolled down as far as his comment: "End of Playtest No 1" (just after his comments on Room 080 'A School Wall? / Schoolgirls!'), and incorrectly assumed that that was the end of the post? If so, you may also have missed the comment about the lack of Playtest No 3 because Room 047 'A Bunch of Trees - Another Wall' is impassable? **** Anyway, I've just had a quick look at the guardians in Room 077 'Nothing here but debris...', which you invited us to comment on. I presume, given your previous comment about 'mascarons', that you are referring to the vertical guardians in that room? And I believe they are also inspired by architectural features, and they are supposed to be the tops of classical Greek columns (known as 'capitals')? Which would fit in with the 'debris' theme. :) I also notice that those particular guardians are also technically 'Skylabs'. i.e. vertical guardians which shift horizontal position after they have descended and crumbled to dust. However, my previously-expressed concern about the bug in the JSW64 game engine - arising from the use of the 'Droplets' patch - may not be a reality in the game. Because Room 042 'Laundry Chutes - Dirty Clothes' seems to be populated with true Skylabs, rather than Droplets as Danny suggested (though he wasn't certain on the terminology when he made the comment). The Skylabs in Room 042 probably seemed like Droplets to Danny, because each time they 'reincarnate' four cell-columns to the right, their previous trajectory (four columns to the left) is simultaneously filled with another Skylab that falls in sync! (Although if you look closely, each alternate Skylab uses a different sprite - shirts/trousers/shirts/trousers etc - which is how I could recognise that they weren't true Droplets.) So the bug which I reported probably won't affect the game after all - unless somewhere else in the layout, there is a genuine instance of Droplets (i.e. Skylabs which do not change their horizontal position between each iteration). EDIT: Actually, now that I think about it again, adding Droplets to a game isn't something that can be done via the drop-down menu for 'Guardian type' in JSWED's Graphical User Interface - you have to insert them manually via the hex code - so it's probably unlikely that you do have Droplets in the game.

But I got the impression, from skim-reading Danny's notes, that he had failed to access part of the layout because of a bug (a guardian crashing into a room tile, or something like that?) Which would suggest that he hadn't explored all of the layout just yet?

You forgot to mention: running out of time! (A real possibility in that game!)

Okay, but I would encourage you to have another think about it when you get a chance (and feel the inclination), because you're probably closer than you think to solving it...

I only mentioned it because the other day you stated that your three top priorities for JSW-related activities were: - Finishing and releasing MBCM 48K; - Playtesting Roddenwald; - Cracking the JSW128K cheat code; in that order. ;) (Or words to that effect.)

Danny wrote: Those "other things" include finishing off with cracking the JSW128 cheat code?...