IRF

I've found a six nine-byte saving in the 'Initialise the title screen' routine, by replacing the individual checks of various attribute values at #8844-#8870, inserting a couple of look-up tables and using two CPIR commands. I'll type up a disassembly when I find the time. :)

Norman did actually report it via an edit to post #21 (top of this page), but it's easily missed.

There's only one game file attached to post #1 now, so that'll be 'the one'!

POKES for JSW2-style jumping (with more dynamic turns): POKE #840C, #03 POKE #840E, #03 POKE #8411, #02 POKE #8413, #02

POKES for JSW2-style jumping (with more dynamic turns): POKE #8425, #03 POKE #8427, #03 POKE #842A, #02 POKE #842C, #02

Actually, I think that might've been a reference to the post [first post in this thread] having been updated with screenshots added for every room (prior to that point it only showed the new rooms, and it had omitted to show the new room 47).

By "the delay routine", are you referring to some other part of your modified version of the program, which uses (in part) the common subroutine to extract data in a similar manner? As well as the spare bit that you identify, I think the highest bit is also spare, since there are only 16 entries in the NOTE_SHIFT table (which therefore only requires 4 bits)?

I managed to prevent a piano key from lighting up during the pause in the tune, in an update to 'Manic Mixup' (available in the Downloads section here). I think my method was different to yours though.

Yes, it's the next room numerically after Tree Root. Actually, it was called "[". ("]" appears in JSW2!)

I've just noticed the screenshots of the new rooms (and several title screens) which have been added to the first post in this thread. Is there one missing? By my count, there are 67 new rooms shown, which when added to the original 60 gives 127.

Thanks for the explanation, Norman. Based on your most recent post, which tells us that Willy is drawn after the guardians, I believe that the visual change you refer to in the quote above is that: - Whereas in JSW, Willy's which INK can be partially overshadowed by a guardian's INK colour, when they come into close proximity with each other; - In JSW2, a (non-white) guardian will be partially overshadowed by Willy's white INK, when they come into close proximity with each other?

I was just perusing through the screenshots for 'Jet Set Mini' over on jswcentral.org (I was wondering how many of them might need updating at some point, to take account of the minor layout changes in the SE of the game - I think it's only four rooms that are affected ['The Mansion Security Guard', 'Back Door', 'Pool Party' and 'I'm not sure anyone believes it?' AKA Dr Jones], and the changes are so minor that I wouldn't consider it a priority - assuming that Danny would even be minded to update them in the first place?). Anyway, the main thing that I wanted to bring up is this - I noticed that in one of Danny's screenshots for the game, there is something unusual on display (a deliberate feature) that no-one has noticed yet (or at least, no-one has commented on so far)... See if you can spot it: https://jswcentral.org/jsw48-a-48_mini.html

Over on the ZX Spectrum Facebook page, someone was asking about games that had Vega support provided. I pointed them in our direction, and I have also created a keymap file for Jet Set Noseybonk (which is something that I forgot to do when I first uploaded the game). I've tested it on Andy's Vega unit (which I must get round to returning to you Andy!), and it all works fine. :)

I wonder if the format/arrangement of the code for Manic Scroller is similar to Matthew Smith's original game? I imagine that it would be an easier task for Norman (or someone other than Mark Woodmass) to attempt the changes, if routines are mostly in the same place as they are in the original. Or maybe if you forwarded a copy of Norman's suggestion to Mark (since I don't think he has a presence here?), he might take up the idea himself?

That (rev3a dancing) looks really cool! Do you mean the lyrics to the song? That's another great idea! The only drawback is that whoever wrote "Rich Man" just filled in half of the song with "diddle diddle dums", I'm not sure it would be worth going to the effort, for a song where the composer didn't make an effort to fill in all the words!

I think I read somewhere about using a XOR method for updating moving sprites (to erase the old one and add the new one), so that instead of having to copy the whole screen twice, you only had to update the parts that had changed since the last pass through the Main Loop, and that can help to speed things up?

Thanks for the explanation Norman! One other little thing that I noticed (if I recall correctly) is that when the game is running at its fastest speed (and possibly at other speeds), the dancing lives on the status bar no longer keep in time with the music? (Unless your latest amendment has had the additional effect of correcting that; I haven't had chance to check it out yet.)

The first note of the in-game tune is skipped when you first fire up the game. (i.e. The "If" of the line "If I were a rich man".) I suspect that this occurs because the music note index (initialised to zero during the Title Screen routine) is incremented within the Main Loop before the indexed note is played during that pass through the Main Loop. This also happens in the original JSW (and MM): http://skoolkid.github.io/jetsetwilly/reference/bugs.html#missedNote However, it is more noticeable here: - In the original games, each note is played twice (i.e. there are two 'blips' of the same pitch, and of a fixed length), and so skipping the 'first' note in reality just means skipping the first 'blip' of the first note; - Whereas in your rewrite, I gather that you have optimised the memory taken up by the tune data - by playing one note for a longer period, rather than having several consecutive notes of the same pitch? This has the effect that when the first note is skipped (presumably by the same process outlined in the Skoolkid link above), it is equivalent to skipping both 'blips' of the first note of the tune in the original JSW game engine. ** By the way, the increased speed at which your latest rewrite of the game runs is very impressive!

View File Jet Set Willy - The Mr Noseybonk Edition For this special version of Matthew Smith's classic ZX Spectrum game 'Jet Set Willy', the Retro Factor has been doubled by the introduction of Mr Noseybonk - a recurring* character from the early 1980's BBC children's TV show 'Jigsaw' - as the main protagonist. (* By 'recurring' I mean that he made regular appearances in the programme - but also that he formed the basis of recurring nightmares for a whole generation of British children!) The title screen music for the project is an adaptation of the theme tune from 'Jigsaw', whilst Noseybonk's theme ('A Hippo Called Hubert' by Joe Griffiths) is collectively represented by the in-game music and the coda that plays during the 'Game Over' sequence. My thanks go to Richard Hallas for inspiring the concept for this project during an email exchange last year, and for his 'A Miner Triad' document (http://hallas.net/Software/music.htm) with its very useful tone chart and general advice on scoring music for the 'Jet Set Willy' game engine. I would also like to thank Andy Ford (administrator of the host site jswmm.co.uk) for his assistance with compiling the BASIC loader, and Richard Dymond for his invaluable 'Jet Set Willy' disassembly (hexadecimal format available at http://skoolkid.gith...ly/index.html). Enjoy - and don't have nightmares!!! Ian Rushforth UPDATE: One week after first releasing this game as 'Jet Set Willy - The Mr Noseybonk Version', a bug came to light which caused corruption of the scrolling message on the Title Screen, and which also caused ropes to behave in strange ways during play. I have corrected this error (caused by a single errant byte), and reissued the game as 'Jet Set Willy - The Mr Noseybonk Edition' (to distinguish it from the first, erroneous release). I also took the opportunity to address a couple of bugs that were present in the original game, namely that the item in the Swimming Pool was automatically collected upon entry (so you never got the opportunity to see it), and one of the items in the Conservatory Roof couldn't be collected without sacrificing a life. It is now possible to complete the game without loss of life. FURTHER UPDATE: Sinclair ZX Vega support files added to the download folder. Submitter IRF Submitted 01/06/2019 Category Jet Set Willy [Remakes]  

I like the way that the portals animate - the top and bottom rows like conveyors, but the sides also 'rotate vertically', requiring a lot more than just the RL and RR commands. There is a flat note (or consecutive pair of notes) in the 'Rich Man' in-game tune - just after half way through, there is an A# [byte value #48 according to Richard Hallas's tone chart] which used to be a B [#44] in the original game.

Number 5 is aptly named!

A few posts back, I uploaded an experimental file ('File 0') in which the MM title tune routine and data had been modified, so that pairs of notes which were previously close in value (differing by 1) now play a pure tone, giving the tune a 'smoother' quality than in the original game. (This was achieved by replacing one of each near-matching notes with the value zero, and then hacking the title tune routine so that such 'zero notes' get bypassed instead of being played.) I then thought I would see what would happen if I experimented with the reverse approach. I have attached a selection of further test files to this post: For comparison, I have attached 'File 1' which is a copy of the original Manic Miner with no changes to the game file except that it has been renamed for consistency with the sequence that follows. The '1' refers to the fact that many of the pairs of notes are assigned pitch values which differ by #01. In 'File 2', those notes which previously differed by #01 are separated in pitch by a difference of #02. In 'File 3', the 'close note pairs' differ by a value of #04; 'File 4' by #08, and in 'File 5' the pairs of notes which originally almost matched each other in pitch now differ by #10 (16 in decimal). So the 'close notes' are spread apart by increasingly large amounts as you progress through the files - I hope that makes sense? For example, in 'File 5' the values stored at addresses #846F and #8470 (the first pair of notes in the title tune) are #80 and #90, instead of #80 and #81 at those same addresses in the original game. The net result is that the quality of the tune sounds increasingly harsher and more dischordant as you work your way through the files, which are thus named accordingly. Er, enjoy! MANIC Title Tune 1 Original.TAP MANIC Title Tune 2 Harsher.TAP MANIC Title Tune 3 Even Harsher.TAP MANIC Title Tune 4 Extremely Harsh.TAP MANIC Title Tune 5 Silly.TAP

In theory, on those occasions when two notes are played simultaneously, they are two notes in a harmonic series, so they aren't actually 'harsh' as such (compared with playing two notes which are slightly different in pitch to each other, which can sound quite disharmonic especially at higher pitches). EDIT: That's the theory anyway! All the pair of notes in the original definitely sound harsher than they do if you separate each half of the pair out and play them separately (by NOPping out one or other of the two XOR #18 commands from the title tune routine).

I've been playing around with the MM title tune routine, and I've managed fix the 'glitch' mentioned above. If the routine encounters a 'zero note', then that note is now bypassed. i.e. no piano key is highlighted, but also no corresponding note is played. This also allows you to have 'pure tones' in the title tune. (In the original MM, attempting to play a pair of notes with identical pitch values causes no note at all to be played for the allocated duration of that pair of notes. So when a 'single note' is played - as opposed to a chord of two notes of different pitch - this is achieved by assigning values to a pair of notes that differ by 1. e.g. #846F and #8470 hold #80 and #81 respectively. The slight difference in pitch gives a 'harpsichord' quality to such notes.) In the attached test file, there is a mixture of pure tones (where the original tune data held a pair of notes differing by 1, one of the note bytes now holds a zero value, whilst the other note is unchanged (e.g. the first note pair at #846F and #8470 hold values #80 and #00) and 'chords' (all pairs of notes in the original tune data that differed significantly from each other have been left with their original values. e.g. the last pair of notes in the tune #8589 and #858A hold values #80 and #CB, as per the original MM). And of course the 'silent note' near the end of the tune (#8541 and #8542 both hold zero values) no longer illuminates the left-most (or indeed any) of the piano keys. The resulting tune sounds smoother and less harsh. (Although admittedly the harshness in the original adds to the 'manic' quality, in keeping with the theme of the game: 'Manic Miner'. So this test file was created purely for experimental purposes, and to further my own knowledge of how this particular tune-playing routine operates.) MANIC Title Tune 0 Smoother.TAP