IRF

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

To answer my own question from the previous post, there is actually a non-trivial example of where the Block Graphics Bug would manifest itself in Manic Miner - if there was a Type 1 Nasty placed in the layout of 'Ore Refinery', then its graphic would indeed be corrupted, because the attribute byte for Nasty 1 (#44) matches a graphical byte from another block type (halfway down the floor tile) that is listed earlier in the cavern definition. There is also the issue that both of the unused-but-defined nasty graphics in 'Skylab Landing Bay' would not get drawn if a nasty (of either type) was placed in the layout, because their attribute byte is set to zero, matching the first (and indeed all) graphic bytes for the background tiles. However, you wouldn't see the defined nasty graphics in that cavern anyway, even if the Block Graphics Bug was fixed, because 00 = black INK on black PAPER. Therefore I would categorise that as a trivial example of the 'Lurking Block Graphics Bug' (alongside a number of other even more trivial examples, arising from completely undefined cell types whose attribute and graphical bytes are all set to zero). ** All of which is to say that, if you were to pass the original Manic Miner through SPECSAISIE's 'Find the Block Graphics Bug' function, you would see quite a few 'BGB Flags' in the output (for various reasons). EDIT: Andrew Broad's 2008 Remix of Manic Miner has Fire 1 cells placed within the cavern 'Ore Refinery', and they are indeed corrupted by the Block Graphics Bug! And 'Skylab Landing Bay' in the 2008 Remix contains a black INK on black PAPER Fire cell, which is also blank apart from the bottom pixel-row, which has the following bitmap which flashes momentarily but visibly when Willy is killed: 01001100 That is equal to #4C, which is the attribute byte value for the first floor tile definition (which follows on from the background tile definition). So after the topmost pixel-row of the background (non-)graphic matches with the Fire attribute byte, the Fire cell is drawn using the background's remaining seven blank graphic bytes, then the floor tile attribute byte interpreted as a bitmap for the Fire cell's bottom pixel-row (normally not visible except at the point of Willy's demise).

I'm not sure whether SkoolKid's response above applies only to all the cavern elements that are actually present when you play Manic Miner, or whether he also analysed all the unused cavern elements in the game. i.e. where Matthew Smith defined graphics for a block type but didn't actually place any instances of those blocks within a particular cavern. (There are plenty of examples of unused block graphics in a cavern which replicate identical block graphics from other caverns - e.g. the 'poisonous pansy' static nasties from 'Central Cavern' are also defined for 'Abandoned Uranium Workings' but are unused in that cavern - and even one example of a cell graphic which Matthew created but which doesn't appear anywhere in the game - the Crumbly graphic in 'Skylab Landing Bay'.) So it's possible that the Block Graphics Bug could manifest itself if you modified the layout of Manic Miner (without changing the game engine)? An analogy (which I discovered and reported earlier in this thread) would be the static nasties in JSW's The Nightmare Room: they have a defined graphic but none are present in the original game; however if you insert one into that room then the graphic gets corrupted when you playtest it, because of the influence of the BGB.

You previously mentioned the trade-off between size versus speed when optimising code. The above quote highlights a third element to throw into the balance - flexibility (relocatability).

Isn't it ADD A, L (to facilitate the multiple use of the subroutine, which is also used for decompressing the tune data)?

I've got so used to thinking in hexadecimal that I thought at first you were colouring in the piano keys with yellow INK with that command! :lol:

https://www.youtube.com/watch?v=B7yqu5VPQX4

A most cunning rewrite, Norman! Especially the shared subroutine for decompressing the data and determining which piano key gets highlighted! I presume that this element (the bit in bold): is there to take into account the possibility that the 'time shift' and 'note shift' look-up tables might be in a position which straddles two pages of memory? That's a very useful technique; thanks for drawing my attention to it. Incidentally, I believe that the following would achieve the same thing (in the same number of bytes): ADD A, L LD L, A JR NC, grab_data INC H grab_data: LD A, (HL) ****** One subtle visual difference that your alternative code might produce - the pair of 'almost matching' notes at the start of the tune holds pitch values #80 and #81. With the original code, playing that pair of 'almost matching' notes only illuminates a single piano key (in cyan). With your version, I believe (without having tried it out yet) that two adjacent keys will be illuminated (one in red, one cyan). This is because the two notes end up on opposite sides of an 'octal boundary'. (Each piano key corresponds to an 'octet' of pitch values. i.e. for every increase in the pitch value of 8, we proceed from highlighting one piano key to the next). That discrepancy could be resolved by tweaking the data (so that the corresponding pitch values are #7F and #80, and a similar consideration could be given for other values that are close to an 'octal boundary'). I don't believe that the perceived difference in pitch would be audible. ** On the other hand, your code has the effect of fixing a little-known 'bug'* in the original game engine - namely that if you try to play a note of extremely high pitch (holding a value between #01 and #07), then the leftmost piano key gets highlighted, whereas you would expect the far right-hand piano key to be the one that is illuminated for such a high-pitched note. (*It's a 'theoretical bug', because of course no note of that pitch manifests itself in the title tune data.) The fix which I came up with for that is to replace the SUB A, #08 at #932B with a DEC A; I think your code will have the same effect in terms of determining when the transition from one highlighted key to another occurs. (Your previous comment about "design of the keyboard [looking] like it was constructed from several broken ones" is also relevant here!)

So you're saying that you compressed the data, as well as optimising the Z80 code?