IRF

I've just checked, and yes, in 'Pool Party' in 'Jet Set Mini', the rope starts off swinging leftwards if Willy enters the room in the left half of the room, and starts off swinging rightwards if Willy enters into the right half of the room. It is necessary to drop down from The Orangery on both sides of the rope, in order to collect two of the items in that game.

I guess that's because Kong changes from being alive to dead when you flick the switch! What about location (and bitmap) of the collectable items in the cavern that you're editing? Can that be done via your edit function, or does it have to be done by editing the global table?

Now that I think about it, getting the whole of a piano key to highlight would have been a trivial matter once you've established the highlighting of the lower part of each key (just subtract #20 from the attribute address that you've already dealt with, and colour that in as well). There's another improvement here, I think - am I right to observe that the piano keys which highlight seem to be more in keeping with the notes which are being played? And of course, with Matthew's odd arrangement of black keys having been fixed as well, I think I'm right in saying that if you were playing along on a real piano, and followed the keys which light up, then you would end up playing a faithful rendition of The Blue Danube in real life? This is the big novelty! Pressing '3' and '0' together takes you into a room editor! :thumbsup: So far I have managed to figure out the keys to change the attributes and bitmaps for each room cell, and the cavern layouts (i.e. which cell types go where). Can you edit graphics and placements for guardians, items and portals as well? (And movement parameters for guardians?)

Didn't we do this for the Swimming Pool in 'Jet Set Mini'?

You are right that the code which activates the extra Cheat Mode is not provided in John's disassembly of the rest of his code changes for the JSW128 game engine.

You still get the points for collecting that item if you drop onto it, even though you don't get to see it disappearing before the portal effect begins.

My replies in red:

Some nice new features there, Norman! :) The only thing I would query: the scrolly message refers to the "top 20 caverns by Ligan". This game being set in a mine, surely that should say "bottom [i.e. deepest] 20 caverns"? :P

Ah yes, I forgot to search on the separate tab labelled "Versions of MM."

For future reference, this is the code referred to above: ORG #C4B6 29 ADD HL,HL 29 ADD HL,HL 29 ADD HL,HL ED 4B DF 80 LD BC, (#80DF) 09 ADD HL,BC C9 RET The guardian table for the current room is stored in a pair of bytes in the room definition at offset #DF-#E0.

I just checked in an assortment of JSW64 engine games (N.B. I only checked in the TAP files; not the TZX where available). This is what I found: John Elliott's 'Jet Set Willy 64' (all six variants: V, W, X, Y, YY, Z) - #EB90 is NOPped out. John Elliott's 'Jet Set Willy 64: Manic Miner' (available in two variants of the game engine: W and Z) - #EB90 holds the correct [as per JSW128] value of #4B. Andrew Broad's 'Jet Set Willy 64: Manic Miner: James Bond' - #EB90 is NOPped out. Andrew Broad's 'Jet Set Willy 64: Flash Manic Miner' - #EB90 is NOPped out. Igor Makovski's 'Ultimate Manic Miner' - #EB90 is NOPped out. So it seems that most of the released JSW64 engine games were built from one of the variants of 'Jet Set Willy 64' as a base file, all of which display the small visual bug in the Invincibility icon. The only exception which I have found is John's 'Jet Set Willy 64: Manic Miner', which must have been developed separately at an earlier stage before the bug crept into the data. ** Slightly off-topic: Danny, in the course of researching the above, I noticed that you don't appear to have an entry at JSWCentral.org for Andrew Broad's 'Manic Miner: Matthew Smith 2008 Remix' (which was released as a bonus with Andrew's 'Flash Manic Miner', and which formed the starting point - along with 'reniM cinaM' - for the JSWMM release 'Manic Mixup')?

I don't know if JSW128 games are affected by the glitch, but you could check easily by checking the value at the address #EB90 and see whether it holds #4B or #00. It might just be a case where I accidentally erased the proper value from that address whilst I was playing around in the Hex Editor. I can't even recall which file it was where I noticed it. It's just something to look out for.

I think you have one too many bytes in the sequence below. Where I have highlighted four consecutive values of '1F', there are in fact only supposed to be three '1F's (at #C491-93).

Incidentally, I once noticed that there is a missing graphic byte from the icon for Invincibility Mode, in some variants of JSW64. #EB90 is NOPped out, whereas it should hold a value of '4B'. (Danny, once you have managed to figure out how to activate Invincibility, try it out in your JSW64 games - it would be interesting to see if this visual glitch made it into some of your releases!)

The "fast inter-room teleportation" refers to the feature which you have succeeded in working out: using Z-X-C-V to move straight into adjacent rooms. Invincibility and Antigravity features can each be toggled on/off by a combination of keypresses; you will know when you have managed to activate each one when another icon appears on the status bar. Keep digging into the code! The alt cheat mode code works differently to WRITETYPER in that it draws from more than two half-rows of keys (hence it picks up 'S', which I presume that you discovered by chance?). Have a think about the possible implications of that for the structure of the data... Using 6-8 as part of the WRITETYPER sequence works in an unexpected way. As John Elliott himself said: "The binary room number is given by the keys 67854321 rather than 654321, and the way the keyboard is wired makes this system somewhat inadequate. " That was taken from: http://www.seasip.info/Jsw/doc128.html Another enigmatic comment on that page hints at the location of the cheat code: Perhaps motivated by a desire to divert prying eyes from the cheat code, a short subroutine that is not part of the Cheat code, but which is contained within page #C4 (presumably for convenience), is missing from the page of JSW128 source code: Unfortunately, a disassembly for the subroutine at #C4B6 (which picks up the location of the guardian tables, there being more than one of those in the JSW128 game engine) is not provided at http://www.seasip.info/Jsw/jswdiffs.html I think I once wrote up a disassembly for that subroutine in a post on the Yahoo! Group, but that is sadly no longer with us!

Hi Geoff, and welcome! We've used your 'Patch Vector' concept in several games that we've released here at JSWMM!

POKE #96BD, #1B (POKE 38589, 27) swaps a RL E command for a RR E, which changes the routine that plays the Title Screen tune so that the modulation goes 'upwards' by an octave for each note, rather than 'downwards' by an octave.

I want to retract my comment anyway. Since I also got the final score of each game to print on the column of the plinth during the 'Game Over' sequence, logically if everything was laterally inverted then the digits of the final score should be printed backwards too! (Which would have been more trouble than it was worth!)

I've just realised that we forgot to laterally invert the boot (and Willy) on the Game Over screen in 'Manic Mixup'! (As we did in 'Jet Set Mini'.)

I just tried out the third file (maximum POKEage variant). Some very strange behaviour going on there! Although I found it slightly frustrating that Willy kept getting sent to The Off Licence (because the default exit setting from most of the rooms, where another room isn't meant to be adjacent is set to The Off Licence by default).

There are some quite supportive reviews in the comments zone here, as well as the positive commentary: https://www.youtube.com/watch?v=f8SBOL1iPdo

I think the answer is "both" - the toilet sprites have been physically relocated (from page #A6), but there is a net loss of two editable sprite pages in the editor's GUI (as well as two fewer rooms) to make way for the extended guardian table. I don't believe that two new pages of memory get 're-purposed' as editable sprite pages in Softricks?

P.S. A similar approach (picking up sequential values of a particular game variable, and printing them across a spare page of the code, for detailed scrutiny of the raw data) could have useful applications for other purposes.

Danny, you may be interested (or may not!) in a useful tool which I came up with earlier - see the attached file. It's a test file based on your 'MC guardian - quite good' file, with a minor modification. What it does is, at the start of every pass through the Main Loop, it prints the current value of the second byte of the guardian definition (for the single guardian in the only populated/accessible room in the test file that you created), across a range of addresses starting at #9C00. After printing a value (in the first instance at the address #9C00), it increments the IY index register (which is used to keep track - chosen because the IY register isn't used in the JSW game engine [except when drawing ropes, but there are no ropes present in this game file]). So during the second pass through the Main Loop, the next value for the guardian's second byte is printed at #9C01, etc. By running this program in an emulator for a while, then saving a snapshot after you've observed a good number of cycles of the guardian's colour changes, and then opening up the game file in JSWED and observing the addresses from #9C00 onwards in the Hex Editor, it enables you to study the sequence of values for the 'pseudo-rope guardian's second byte (which are generated as values for the rope animation index by the 'Move the guardians' routine, but then interpreted as a guardian colour attribute by the 'Draw the guardians' routine). The lower nybble* of each stored value correlates with the BRIGHTness [bit 3] and the INK colour [bits 0-2] of the guardian at each point in time. * (i.e. the 'units digit' if we were talking in terms of decimal numbers. If you see a number like #F3, then the lower nibble is 3; the upper nibble is F.) You can then play around with the definition bytes for the guardian (stored at #A000-#A007), as we were doing earlier yesterday, and then by running the file and saving snapshots, you can see a numerical interpretation of the different colour schemes on display. (And then for added 'fun', study the routine at #90C0 and see how the commands determining how a rope is moved are reflected in the pattern of colours that you can see.) N.B. If you leave the attached game file running for more than a minute or so (in real world time!), then the sequence of values being recorded internally by the program will reach the point where they start to overwrite the guardian's graphic bytes (which are stored at the top of page #9E, as you know), causing visible corruption of the guardian! MC guardian - animation index test.tap

No worries! I might use the 'initially different' one myself at some point. ? Yes, the JSW128 cycling is indeed regular, you're right about that. I look forward to your 'big Saddam's regarding your current project! EDIT: Hah! That was supposed to say "big reveal"!