Norman Sword

I found the above (spoiler) fine in Opera, edge, Chrome,Firefox 100.0.2, opera Gx, Ccleaner browser And can also confirm the Captcha works for all of the above.

For consistancy of timing states and logic flow, it is probably better to manipulate the bits into the appropiate position. The code I listed is manipulating bits to provide an answer, but the direct route is just as quick, but varies in timing depending on the path taken. (as listed above) . L935E ld hl,rope_status bit 7,(hl) jr z,L93xx inc (hl) RES ropebit,(IX+rope0B) JR next_entity_draw L93xx BIT ropebit,(IX+rope0B) JR Z,next_entity_draw LD A,(willy_dir) BIT 1,A JR Z,next_entity_draw cpl ; in revision this is not needed rrca xor (ix+rope01) rlca ; in the revision the bit position is not shifted rlca AND #02 ; no need to isolate bit - a direct test is done DEC A ADD A,(HL) LD (HL),A NOP NOP NOP NOP NOP revised: L935E ld hl,rope_status bit 7,(hl) jr z,L93xx inc (hl) RES ropebit,(IX+rope0B) JR next_entity_draw L93xx BIT ropebit,(IX+rope0B) JR Z,next_entity_draw LD A,(willy_dir) BIT 1,A JR Z,next_entity_draw ; rrca ; move bit [0] to bit [7] xor (ix+rope01) ; bit [7] inc (hl) ; do a +1 change on rope_status bit 7,a ; check the bit[7] status jr z,skip_o ; branch if ok with +1 dec (hl) ; else revise the +1 to 0 dec (hl) ; and revise again to -1 skip_o: NOP NOP NOP NOP NOP NOP which removes the need to CPL the byte for testing and is also one byte shorter.

This is not something new. It is the above code written differently, and it still leaves those 2 bytes alone (the relative jump to the next byte - which is redundant code at #93b1) ;Now that the entire rope has been drawn, deal with Willy's movement along it. L935E ld hl,rope_status bit 7,(hl) ; ; Has Willy recently jumped off the rope or dropped off the bottom of it (A>=0xF0)? jr z,L93xx ; ; Jump if not inc (hl) ; ; Update the rope status indicator at L85D6 RES ropebit,(IX+rope0B) ; ; Signal: Willy is not on the rope JR next_entity_draw ; ;#93b3 Jump to consider the next entity L93xx BIT ropebit,(IX+rope0B) ; ; ropebit=0, Is Willy on the rope? JR Z,next_entity_draw ; ; #93b3 If not, jump to consider the next entity LD A,(willy_dir) ; ; Pick up Willy's direction and movement flags from L85D0 BIT 1,A ; ; Is Willy trying to move up or down the rope? JR Z,next_entity_draw ; ;#93b3 cpl ; ; invert the bits - only intetest is in bit [0] the direction Willy wants to move rrca ; ; shift bit [0] > bit [7] xor (ix+rope01) ; ; direction of swing in bit [7] rlca ; ; from [7] to [0] rlca ; ; from [0] to [1] AND #02 ; ; value is now 0 or 2 DEC A ; ; value is now -1 or 1 ADD A,(HL) ; ; add on the rope status LD (HL),A ; ; and save the new value nop ; ; a bit of space saved 5 bytes nop nop nop nop L938a:

JSW and MM - walking on a conveyor. Part 2:- Your past, influences your future Jsw and MM on the zx spectrum both use a lookup table for translating joystick/ keyboard actions into a new key press action. The predefined actions for every combination of key press is contained in those lookup tables. With some responses being the supposed quirks in game play. One action that might not be recognised is the response to an action when two horizontal actions are asked for. Normally the player only asks for a response for moving in one direction. Which is how most of the game is played. The player presses a direction key and Willy responds by moving in that direction. But suppose Willy is asked to walk both left and right at the same time? The action for that situation is contained in the keyboard translation / response table, and that action is to respond only on the previous key pressed, and ignore the new key. To see what this means walk to the right of the bathroom and press the key to move left. Whilst holding down left and walking left, press the right key. The movement lookup table will ignore the new key being introduced into his movement and Willy will continue walking left. Whilst walking left no matter how long or short the right key is pressed, its actions will be ignored, until the left key is released. Jumping and falling introduce more variables, but walking and holding a key down will continue on that walk until the key is released. Willy can of course walk over a conveyor whilst holding down the key. The conveyor will press the direction key for the conveyor, and the game engine via the lookup table will ignore any change in horizontal movement. Back to jumping onto conveyors. The most important point about the movement lookup table is that new horizontal actions are defined by the old actions. hence "Your past, influences your future" . The actions that a conveyor has is defined by the actions undertaken to arrive on the conveyor. If your previous action had a horizontal movement as a component of its action and that action is still being requested, then the movement table will oblige and continue with that horizontal movement. Which is why I tried to explain the consequence of falling onto a conveyor. Because when the horizontal movement of Willy is stopped (previous action) the new action (the conveyor) tries to takes over the horizontal movement of Willy. (see stopped on a conveyor :- at the end) In the situations of Willy landing with a horizontal movement component still being his last horizontal movement action. If requested to continue with the horizontal movement. (e.g. you are still pressing the key) then the conveyor action will be ignored. Stopped on a conveyor. The movement action table also explains why you can stop on a conveyor. If your previous horizontal action was no movement (e.g. a fall) then a request to move in the opposite direction of the conveyor. Will upon landing on that conveyor, result in no movement. This situation is a request to move horizontally both left and right, from a previous null horizontal movement.. That request is translated as a new null horizontal movement reponse. These actions are all defined in the movement lookup table.

JSW and MM - walking on a conveyor. Part 1:- When Willy is jumping he can have a forward movement component for the arc of travel.. Which is basically an automatic key press in the direction he is jumping. When the arc of the jump is finished, and he starts falling, the code kills his movement key and willy no longer has a horizontal movement component for his actions. This means at the point of landing on a conveyor from any fall, (note I say fall- and not jump) Willy can NOT have a horizontal movement component and this coupled with the automatic key press supplied by the conveyor results in the actions as seen. All other instances of landing on a conveyor that is level or above the start point have the horizontal component still intact from the start of the jump, and this is transfered to the point of landing. Nothing strange or convoluted in this coding of action.

Taking the actual code used to control Willy on the rope . It took me all of 1 second to change the logic. This original is deliberate and very logical in the manor of control. Walking up a stair you press against the stair, to move down a rope you press against the rope. Which to me is reverse logic, but still a consistant logic. To modify to play as you mentioned is the lazy way of coding the movement and not the other way around. Note the ease of modification Part of the rope swing LD A,(willy_dir) ; #9375 ;#85D0 Pick up Willy's direction and movement flags from #85D0 BIT 1,A ; #9378 ; Is Willy moving up or down the rope? JR Z,next_entity_draw ; #937A ;#93b3 If not, jump to consider the next entity ;CHANGE CODE FROM ; RRCA ; #937C ; XOR Willy's direction bit (0=facing right, 1=facing left) with the rope's direction bit ;; ;; ; (0=swinging right to left, 1=swinging left to right) ; XOR (IX+rope00) ; #937D ; ; RLCA ; #9380 ; ; RLCA ; #9381 ; Now A=1 if Willy is facing the same direction as the rope is swinging (he will move down the rope), ;; ;; ; or -1 otherwise (he will move up the rope) ; CHANGE CODE TO RLCA ; #937C NOP ; #937D NOP ; #937E NOP ; #937F NOP ; #9380 NOP ; #9381 ;>> back to the normal logic AND #02 ; 9382 ; DEC A ; 9384 ; included is a file with the rope swinging in such a way. NOTE this file is so close to the original --- it might still have the attic bug --- I can not remember. Addendum:- easier is to just zero out #937c, #937d, #937e, #937f, #9380. -- five 0(zero) pokes. jsw rope swing.tap

Correction on the misinformation about automatic room switching: JSW can switch rooms at around 4 frames per second. The graphics will appear on the screen. long enough, for the room to be recognised. Additionally you will be able to follow what willy does. This means the minimum time MUST be around 15 seconds, and that time is to just flash through 60 rooms. That time however does not allow much leeway for moving around the rooms.

The rope is very simple in operation. Matthews code does its best to obscure that simplicity. The rope data has offsets for x and y. - the data below is padded out to 256 bytes rope_table_X: DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H01,&H01,&H01,&H01,&H01,&H01,&H01,&H01 DATA &H01,&H01,&H01,&H01,&H02,&H02,&H02,&H02 DATA &H02,&H02,&H02,&H02,&H02,&H02,&H02,&H02 DATA &H02,&H02,&H02,&H02,&H02,&H02,&H02,&H02 DATA &H02,&H02,&H01,&H02,&H02,&H01,&H01,&H02 DATA &H01,&H01,&H02,&H02,&H03,&H02,&H03,&H02 DATA &H03,&H03,&H03,&H03,&H03,&H03 ;================== DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00 ' y-coordinate shift rope_table_Y: DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H06,&H06,&H06,&H06,&H06,&H06,&H06,&H06 DATA &H04,&H06,&H06,&H04,&H06,&H04,&H06,&H04 DATA &H06,&H04,&H04,&H04,&H06,&H04,&H04,&H04 DATA &H04,&H04,&H04,&H04,&H04,&H04,&H04,&H04 DATA &H04,&H04,&H04,&H04,&H04,&H04,&H04,&H04 DATA &H04,&H04,&H04,&H04,&H04,&H04 ;=========== DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00,&H00,&H00,&H00,&H00,&H00,&H00 DATA &H00,&H00 simple logic for animation A pointer is set as an offset into the data (as above) The pointer has two other variables - side and step The step is added to the offset. if the offset is now 0 then reverse the step and reverse the side - simply negate the side and step. if the offset is maximum the reverse the step- Simply negate the step The above is the core logic for animation -------------------------- To draw- start x=128; start y=0: loop draw point x,y Take the offset into the above data - find the x entry - delta x- and if side is 1 add delta x to x ; if side is -1 deduct delta x from x Take the offset into the above data : find the y entry and add to the y add 1 to the offset loop for the length of the rope the above will need adjustments, with the size of steps and length of rope etc =but will draw the rope.

Assuming you can draw the rope. Starting at the top we count the pixels drawn for the rope draw. If Not attached to the rope. Each cell drawn is tested for collision. if collision then willy is attached to the rope at that point. If attached to the rope. The cell that is assigned as the collision point (as above) is used as the x,y position to draw Willy - (slight shift adjustment needed in zx spectrum code) To move on the rope the point of collision is moved up or down the rope To detach from the rope. A timer is set and Willy is cell aligned and exits from the rope.

In zx spectrum JSw and JSW2 and JSW2+. When Willy is walking along he is always aligned to a character cell. When Willy is above a ramp/stair he is still aligned to a character cell, but is drawn with a displacement. When Willy appears to walk diagonally up or down a stair. He actually walks in steps of one char up and down the stairs. It is the displacement code the makes him appear to walk diagonally.

I will again state. It is possible to run Manic miner and return to basic. On returning to basic it will still be possible to poke the game and again enter MM ( and if needed keep on repeating the loop of running the game and returning to basic). All the basic that was in memory before running MM will still be there. Because certain members on here do not have the skill needed to do this does not preclude others from doing so. (e.g. I can if I wanted, do the modifications needed. But I have no intention of doing so. ) in the 30+ years since MM was written I have had no need to do so, and I still have no need to do so.

Clarification on those pokes The POKE to set the starting room to Room r is 34795,r. (is for JSW) POKE 33824,r is a useful runtime POKE to teleport to Room r. (is for JSW)

Whilst it is possible to run MM and return to basic it is not as simple as a few pokes.

A side track. The design of Nomen luni focuses on the crashed plane. Yet for some reason Matthew part obscured the design by flashing un needed graphics. So the next version of this screen I do, will be changed to this (picture below) which assigns nasty graphics to the un wanted flashing graphics on the right, and thus removes the flashing from those graphics. Which then forces the plane to take centre stage.

The room exists as a void room. The room is drawn with no graphics no sprites and all exits are set to go to the "off licence". The code checks (in cheat) for rooms 47/61/62 and 63 if found then the cheat code is ignored. If in playing the room 47/61/62 or 63 was entered, you would land either on the floor across the room at mid point or across the bottom. Nothing would be visible. On walking across the room you would enter the "off licence". So yes the room exists. But would be very difficult to edit by virtue of the data size being set to the smallest possible size. Looking at the data with a hex editor will not show much. The data and its structure are comparable to JSW2 in its layout. While JSW2 keeps all the rooms in continuous blocks of data . The room layouts all being together and the (sprite movement data ,the tile colours, the graphics and room name) being in another block. In ManicJetSetWilly the room graphics and the tile colours etc are mixed with no real indication of where one starts or finishes. In JSW2 the room names can be seen alongside the appropiate room data. Giving an easy to see reference point. In ManicJetSetWilly the data for room names and the room data are vastly seperated and room data just flows from one rooms data set to the next for the room data.

I basically redrew all the text. I started from scratch and drew all the text in a way that I would do. Then modified back some of the quirks from the original. Starting on MANIC The start of the Leading M is adjusted and cleaned up to a consitant 1 pixel wide The A has a narrower left side upright. The C has the upper flick removed On MINER The strange indent on the M was fixed. To me it looked wonky The Start curve on the M of Miner duplicates the start M on Manic The tail of the R duplicates the initial curl on the M's On STARRING The A and R are better kerned On MINER WILLY The L's in Miner Willy are made Narrower on PRESS ENTER TO START The E's all have a longer middle The N has its middle kink removed The A has the lower bar moved up a pixel The T and the A in START are better kerned Changed the keyboard layout and also changed the length of the black keys relative to the white portion below.

I wonder why the mapping picture of Manic 40 Miner uses the title screen picture from Manic Miner and not the title screen picture from Manic 40 Miner? The pictures are different enough that even the low res spoiler picture, is evidently the original Manic Miner. Can you spot all the changes?

The staggering count seems to be 130.5 Whilst mine is 0/20+

Thanks for the mention on jsw central. I must point out that when I wrote about cheat activation, I finished by adding:- You must wear a mask, and take all the necessary Covid precautions. Sterilise the keyboard before usage to stop program code bugs. Your socks must match, absence of socks or mismatch of socks will abort cheat. which I thought was sufficent to indicate, I was not being serious. Apart from the extra row of keys used. The cheat "type in" is accessed in the same way as the normal Jet Set Willy. Having odd socks is only a fashion statement. There being no restrictions in the Time/score/Clock time etc. Cheat is typed when standing on the lower floor in the "First Landing" The cheat is "heroJokerKilt" Cheat only works on legal Jet set willy room numbers Cheat will not work in Manic Miner Cheat will not work in any part of the toilet run sequence.

Well done. I recently posted I have not finished any version. Whilst I have done every room in every version I have written. I have not pushed myself to finish even one version. Yet on JSW Central. the list of completed games (by Jetsetdanny) must be extensive. I wonder how many versions?

Congratulations to all who have finished this. Whilst I have managed every screen multiple times. I would not attempt to play, for any more than half an hour in one go. Which means I am no where near completing either part. I will play as far as testing out a group of rooms or a cavern group, but my mind will wander to other things and this causes me to stop playing.

Rays and beams. The solar power room has a beam of light. The beam of light being in normal and real world applications made from a collection of photons of light. Rays are normally a single photon and can be plotted and drawn to show their path. In the world of Manic Miner the Beam of light can be treated as a ray of light because no part of the beam acts independently from any other part of the beam. (e.g. the beam/ray can not be split) The path of the beam is identical to the path of a ray of light. Which is why I swap terminologies freely within the context of Manic Miner.

I changed a version to show the status of the clock bit. The routine draws a line across the screen showing clearly the status as the game progresses from room to room. Normally just going back and forth aimlessly between two rooms will give an even spread of odd and even ( as expected). However I have just done a mad burst of counting the status and have just managed to do 53 room changes and in every one the clock was odd. The chances of repeating that feat should be 1 in 9,000,000,000,000,000 And continuing on, have managed a run of 23 even. i in 8,388,608 The ticker is not based on interrupts, which is what frames on a zx spectrum is based on. When an interrupt occurs then the frame counter is increased. Handy to implement counters and delays. One of the first instructions in most variants of JSW and MM is DI <Disable Interrupts> so interrupts are not a variable used whilst playing the game. Matthew used FRAMES for the cheat input code. Which is useless on an emulated machine. The result should be nearly fixed when dropping the file onto an emulated machine and running it. Or running a full memory dump "snapshot" which will have captured the FRAMES variable. The game ticker is counting the game loops. The duration for each loop is fixed by the amount of code executed.

Yes. The visual feedback for the change would be miniscule. But it would change how the room plays. (swapping from one state to the other)

Exactly as I predicted. The deflection is caused by the change in the game clock. Clock odd no deflection. Clock even beam deflects. No change via speed setting.