IRF

Yes, you have to be very careful to 'follow the rules' when it comes to flags. I came a cropper a while back when I (falsely) assumed that a DEC A [or DEC L] command would set the Carry flag when A is decremented from #00 to #FF.

Thanks for confirmation. I was going to test it out as is, just to see how it messes with some familiar layouts - I still might, just for fun...

If I may be so bold, I feel that I must query something from one of Norman Sword's earlier posts. The two RRCA instructions, highlighted in bold in the quote below, should actually be two RLCA instructions? (Assuming that the room layout data is stored in the same way that it is in original JSW. i.e. with Bits 6 and 7 of each compressed room layout byte corresponding to the leftmost of the four room cells that are defined by that particular layout byte, Bits 4/5 relating to the next room cell along, then Bits 2/3, and finally Bits 0 and 1 corresponding to the rightmost room cell in that group of four cells.) Two RLCA operations would rotate two bits of the Accumulator into Bits 0 and 1, ready for selection by the subsequent AND #03 gate, in the correct order to consider the four cells from left to right in turn (before moving on to consider the next cluster of four room cells to the right). http://jswmm.co.uk/topic/185-free-space-and-code-optimisation-in-jsw/?p=6101 Otherwise, it's an excellent bit of optimisation.

Ah yes, the black keys on Matthew's title screen are wrong. Well spotted! (They should alternate between a pair of two black keys, and a group of three, as you move along the keyboard. But in Matthew's graphic, there are two adjacent pairs of black keys under the word 'ENTER'.) Also in the title screen of Norman's 'Software Projects + Bug Byte' version of Manic Miner, I've just noticed the Software Projects triangle rotating on the grassy area, the filling in of the blacked out areas (where parts of the layout of 'Final Barrier' would go), and the initials D.P.R. in the band of yellow and green 'scrub' (in character-row 7)...

Note that my original attempt at this just had an Earth cell platform in row 2. (Earth being chosen so that Willy couldn't collect the item by jumping up from below, i.e. so that his head passes through the platform and collects the item.) However, that didn't work - Willy jumped off the top of the room, without landing on the platform. I think that is because the effect of the POKE will only work if it detects a 'standonable' cell underneath Willy. But he is prevented him from moving into the same cell-column as the Earth cells, until he has ascended past them (into rows 0 and 1). And then during a jump, the 'Move Willy' routine checks whether Willy has gone past the top of the room before it moves him sideways to a position where he is above the end cell of the platform. Catch 22! So in the layout of the 'item reachable' attached file (the one with the POKE enabled), the platform starts off as Water (so that Willy can 'step' up onto it, and then walk along it), but it changes along its length to comprise of Earth at the point where the item is located on it (so that the item can't be collected by jumping up from below).

That's already been brought to my attention by Richard Hallas. :-) POKE #98D2, #0C fixes it.

Sorry, that last post wasn't aimed at you particularly/personally, Andy. I meant in general terms, people who use decimal numbers when coding. Everything seems so much more logical to me, once you get your head around thinking in hexadecimal. Especially things like lookup tables where the addresses have a proportional relationship with the values stored in them. Sometimes I think life would be so much easier if we had sixteen fingers, so that our whole system of counting had evolved differently! :P

I honestly don't know how you cope with working in decimal! Probably the only time I use it is when inserting POKES into SPIN (and even then, I wish it had a 'POKE in hexadecimal' function!)

No I didn't read the spoiler first - I just spotted the difference! Try POKE #A63D, #04. B)

There's a pixel missing at the driver's side of the car! I never noticed the white (chalk?) cliff-face before. I guess Willy may have lived near Dover before he moved to Surbiton...

I also suspect, from looking at the 'Move Willy (3)' routine, that the last of the seven POKES will have the following side effect: If Willy is in a room in which the Earth attribute is set to zero, then Willy will be unable to move rightwards across a cell boundary, not even through Air or Water blocks. EDIT: By the above, I mean even if the Air attribute is not set to the same value of zero (which would mean that all Air blocks would have combined Air-Earth properties, so he wouldn't be able to move either left or right through the Air). Scrap that, I was wrong. The SBC HL,DE command at #90A5 means that the Zero Flag is NOT set when the RET Z command at #90A8 is reached.

I mentioned in the past that I found the above didn't work properly when Willy attempted to climb up the left-hand wall of 'Halfway up the West Wall' (having walked into that room from 'The Bathroom'). Willy could jump up the wall but got stopped halfway up (appropriately enough for that room!) Now I have figured out why that happened. The first two POKES NOP out the CP (HL) commands in the checks for Earth blocks in the 'Move Willy (1)' routine. Ordinarily, that means that the subsequent JP Z, #8EBC (jump to the code that deals with Willy hitting his head on an Earth block whilst jumping) doesn't come into effect. However, if Willy jumps up into the top-left cell of either the upper half or the lower half of the screen, then the L register will hold the value zero (HL holds Willy's attribute coordinates), and so the Zero Flag will have been set by the CALL to #8E9C from #8DF4 (the OR L command at #8EAA is the precise culprit). As a result, the jump to #8EBC is executed when Willy is located at coordinates (0,0) or (8,0), and Willy is prevented from jumping any higher by the Earth cells. EDIT: Indeed, I believe (although I haven't tried this out yet) that the above POKES will prevent Willy from jumping straight upwards in the left-most cell-column beyond the top of the screen, or beyond the boundary between the upper and lower halves of the screen, in any circumstances - even if there is no Earth cell present to block him!

By way of explanation, the above POKE means that a jump is terminated whenever a standonable block lies beneath Willy's sprite and he is cell-row-aligned. A normal jump only comes to a premature end when the above circumstances hold true and Willy is in the descent phase of the jump. With the above POKE in place, a jump can be terminated during the ascent phase, if a solid platform lies beneath Willy's sprite. ****** The above POKE also allows Willy to access a platform in cell-row 2 via a jump from below. (i.e. a platform which has two cell-rows of air between it and the top of the room.) Normally, Willy couldn't jump up onto such a platform, because the jump would cause him to breach past the top of the room and into the room above. He could only access such a platform via another means (such as walking up a ramp or dropping onto it from the room above). This quirky manoeuvre could form the basis of an interesting room design. e.g. an item which can only be collected in the manner described above. Please see the two attached test files; the only difference between the two is that one has the above POKE implemented, the other one doesn't. Try to collect the item in 'Ballroom East' in the 'Item unreachable' file first. Then try to do the same in 'Item reachable'. (Note also the interesting 'climbing the ladder' effect of the POKE in the latter file.) Item unreachable.z80 Item reachable.z80

Andy, by 'break' [brake?] in the above did you mean pressing the 'P' key to stop Willy from running towards the toilet? (Something which I came up with a fix for, although I'm not sure if Mickey has implemented that fix yet or not?) Or did you mean pressing SHIFT+SPACE to abandon the game during the toilet dash?

Mickey, I've just spotted a minor bug in the JSW 'Game Over' routine - the 'AND #FA' at #8CAF should be replaced with 'AND #F8'. This doesn't affect the original game, it's more of a 'game engine' fix, but it allows a full range of INK colour choices for the Barrel on the Game Over screen. With the AND #FA in place, the choice of INK colour for the Foot/Willy can restrict the possible colours for the Barrel.

Looking at the 'Game Over' routine, I believe that the problem we once encountered in implementing certain INK colours for the Barrel (some choices for which were influenced by the chosen INK colour for the Foot/Willy) could be eliminated by simply replacing the value '#FA' at #8CB0 with '#F8'. i.e. the AND gate at #8CAF should only select the Barrel's PAPER/BRIGHT/FLASH bits (3-7), leaving the OR gate at #8CB1 to fully control the Barrel's INK bits (0-2).

I believe that you can save two bytes at #8DD7, one byte each at #8EDA and #8FA5, and two bytes at #8FC6. This can be achieved by deleting the BIT 7, A instructions, and then changing the conditionality of the subsequent jumps/returns, from JP Z/JR Z/RET Z to JP P/RET P. EDIT: In the case of #8FA5, it needs to be a JP M. ****** I can't see any reason why the RLC A at #8F14 couldn't be a RLCA instead, saving one byte.

The number of posts on this forum overtook those on the Yahoo group yesterday, I believe. Let's hope that a bit of healthy competition sparks a revival in the latter...

We could call such sprites 'Homing Guardians', since they 'home in' on Willy...

Are you sure you aren't thinking of Jet Set Willy, David? The original Manic Miner code doesn't contain an item-collection noise.

This is controlled by the code at #8A00 to #8A0A. I think I played around with that part of the code when I was attempting to laterally-invert the toilet dash for 'Jet Set Mini'. If I recall correctly, I managed to get the code to use the other two of Willy's frames (legs together and legs wide apart), but then he wouldn't progress past a cell-column boundary so he got stuck on the spot! I haven't tried this, but I believe the way to get this to work would be to relocate #8A00-#8A0A to sit in between the commands at #89D6 and #89D9 in the Main Loop. i.e. after Willy has been moved, but before he is drawn. (Of course, that wouldn't fit in situ within the available space unless you did a lot of code-shifting, so you would have to CALL a subroutine, probably by displacing the three-byte command at #89D9, and then reinstating the command from #89D9 at the end of the subroutine, just before the RET. And of course, NOP out the existing code from #8A00-#8A0A.)

Danny's right, the protagonist is still only drawn using two of the four available sprite-frames if he is running for the toilet whilst in The Nightmare Room, although those two sprite-frames look more distinctive than the two Willy ones that are normally used during that stage in the game (which are identical except for being horizontally shifted).

It contrast to the previous oddity, this is the 'official' Superjump POKE, which redirects the JP command at #8E33 (although note that here I've corrected the destination address to point at the start of the jump key handling code, whereas the previous version - POKE 36404,44 - landed flow of execution too early, at #8F2C, which is in the middle of the left-right movement key handling code): POKE 36404,109 (or write #6D to the address #8E34 in the hex editor)

Try this for a quirky manoeuvre: - Open up a JSW file in a hex editor; - Change the value of #8E2F to #18 (or do POKE 36399, 24); - Place Willy at the bottom of the 'ladder' in Ballroom East; - Hit jump. Try both short stabs at the jump key, and long presses. EDIT: Then place Willy at the bottom of a long ramp (such as First Landing, or Back Stairway/West Wing/etc), on the 'outside' of the ramp, and keep both jump and the sideways movement key depressed - watch Willy shoot up the ramp!

'The Off Licence' is a 'special case', the room number is of course zero. You might think that is a very low number and expect almost no noise at all (compare 'At the Foot of the MegaTree', Room 3, where there's barely a blip). But Room 0 is effectively treated as Room #100 (256 in decimal) by the DJNZ loop that controls the pitch (via the B register) - B is decremented before a check is made for a zero value, so it goes 'all the way round' before the routine detects a value of B which is detected as zero. Hence the lengthy 'horn' sound! EDIT: I've modified the test file slightly so that Willy has to 'fall into' one teleporter, and 'fall out of' another. However, care must be taken when a teleporter isn't cell-aligned, because if Willy jumps into one, he can emerge in the destination room mid-jump, which can lead to him 'falling through' solid platforms!