Norman Sword

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.

I have not written or looked at any code yet. When I turned my computor off last night, one of the images shown on my screen was the solar ray and its interaction with the screen sprites. That particular room has four horizontal sprites and 3 vertical sprites. The beam is seen deflecting off one of the horizontal sprites and zapping around the cavern. The change from JSW to MM involves adding and removing sprite actions and tile interactions. I actually just added the new changes and left intact the old events. The game JSW has ramps that are not used in MM, rather than stop their action in MM the code is still run, but has little impact since ramps are not present. The tile count is increased to allow for collapsing floors, switches and extra nasties. The sprites have extra types added being Kong, Eugene and Skylabs. The actions of the sprites is also increased to allow for variable speed, immunity from collision, flashing and switching off completely. The original game clock is left running in both JSW and also in MM. In MM an air supply is also added to display his remaining air. Trivial other changes take place such as a change in Willies definition. These changes do not affect JSW as the data is not present in the JSW rooms. In a similar way to the ramps from JSW in MM In the solar power room the solar ray is switched on by the routine that also checks for the toilet in jsw and Maria guarding the bedroom. Those type of events being switched on and off, by the actual room number. So what is changing in the solar power room? As I stated at the start of this explanation I have not written any code or looked at any data. (yet) The image of the deflecting beam was enough to actually allow me to process through what is changing. The beam is deflected by a red "beam shover." (< a new name for the sprite) That sprite, I remember from when I wrote the code, is slightly different to the other 3 "beam shovers" In that it does not run at full velocity. The velocity is controlled by the clock. The clock is not reset between caverns in JSW or in MM and runs all the time. This does introduce a variable into the room that is changing from room entry to room entry. Since the clock ticks with each and every game loop, the status of the "beam shovers" movement is affected by what value the clock is. Conclusion. The entry into the Solar Power room is with a game clock that is changing as the rooms/caverns are being played. That change dictates what status the sprite movement is for slow moving sprites. This also means that any other room with slow moving sprites will also be affected. (Endorin forest, Attack of the mutant.., ore refinary etc) The change is down to the exact time that the cavern is entered and will only set in action one of two possible room playing states. Nothing to do with the overall speed set for the game, but it is a function of the time on entering the room. I have made a note of this feature and it could be removed (if needed) by a few lines of code. Which I could release sometime perhaps in December 2022. ======================================= Since I now know what is setting up the change in playing state, I have little reason to write the code to freeze the game at the exact moment of beam deflection. I will see if any enthusiasm exists to write the code when I eventually look at the code in my editor/assembler. .

When you posted the video's I went back to the code to see if it did interact with any other routine. Part explained else where, the speed routine is self contained, within the normal sound routine. Its only variable is the speed. That variable is only used to draw the speed bar and set the duration of the sound. (either on or off) speaker being driven back and forth or silence via not altering the speaker state. The only exception being the fastest posible state that just drops through without bothering to toggle the speaker at all. No other routine reacts to the speaker state and therefore the delay. Code wise it makes no change in the way a room or screen is updated (apart from the time between updates) Having said the above, I will look into what is happening. It should be possible to duplicate the beam as displayed at any speed (ignoring willy and his interaction with the beam). Not something I will do tonight, but I will write a routine to freeze the beam at the exact frame shown above, and see if the speed does have an impact. I will be suprised if it does. More likely a variable not being set to a fixed state. But until I confirm one way or another tomorrow, any real change is open to speculation.

Speed. The routine that changes the speed, is self contained. It has no interaction with any other routine. This means that the game plays in exactly the same way, no matter what speed is selected. (apart from the obvious change in speed) The Attic Bug. The DATA and all the code listed in the skoolkit dissassembly of JSW, will if reconstructed give the original game. Which has all the known bugs (as released by Software Projects). The starting point for Manic Jet Set Willy, was the listing I generated called RAW6JSW.asm (stored somewher on this site) Which can be assembled and create's the original game (with the attic bug etc) I edited this file and forgot that it had not been corrected to remove those bugs. And as my editing progressed I started to experience strange errors and crash's. I assumed that those crash's were caused by the new code I was adding. Oblivious to the already installed bugs from the original code. So I experienced the attic bug directly in my new code, caused by the original data. Once I realised the problem, it was easy enough to remove, along with the associated problems - invisible objects, multiple objects, uncollectable objects and the consrvatory death collecting objects. So the attic bug was consigned to the bin a long time ago (in this version). It is the primary reason that demo room flick throughs are written into the versions I write. Demo room flick through. Matthew has told me he did not write a room editor for JSW. So it is probable that the cheat code or the start room being changed was the primary means of testing out a new room. Unfortunately that, in the case of the attic does not alert the user to the bug that room creates. It allows you to see the room and play it, it allows the room to be jumped out of, and into. In the evolution of the JSW manor by Matthew it was just another room, drawn tested and forgotten about as the room count increased. The idea of the demo room flick through is that it plays and activates all of the main sprites in the game, and keeps on activating them for as long as the game is run. It also checks so many aspects of the code, that it worth doing. Remember I was switching between two games and having a routine that kept on switching between the two games, showed up every change that I did when altering the graphics, ,sprite compaction, sprite order, sprite action etc. For those checks it was worth the effort of writing the routine. The version that was left behind, has had the sprite animation routines in the demo removed. And replaced with an alternating screen redraw from right to left then left to right. So no attic bug waiting to happen in Manic Jet Set Willy

Re "the layout of the JSW caverns". A quick response. In one of the earlier posts I mentioned that I encountered the Attic Bug, the missing items and some other interesting features from the original game. I was using the original game data and that unfortunately for me, gave me the original bugs. (which when I encountered them, needed me to remove those bugs.) Apart from glaringingly obvious things that needed changing. I left as much code and data intact, as was possible. The code I focused on was the parts that just waste space through their design. e.g. the imposible triangle, attribute data, room layout data, sprite data, key data, rope data. Then when I needed to add extra routines onto JSW to allow the extra events in Manic MIner. (kong/eugene/skylab/collapsing floor) The code written tended to be much smaller than the originals. I left room layouts and even the interconnections between the rooms as laid out in the original data. Although I did change how the data was stored and used. Whilst I could change the room layouts, It was not what I was trying to do. I changed the layout data for the room that forced a death jump collecting the item. That change was trivial and would have been done by Matthew if it had been pointed out to him (before release of the game). I also changed the room layout for the banyan tree and also displayed or moved a few of the room collected items. Changing the basic game was not the plan. Easy to do, but it does start a path that can be travelled on for a very long time. Changing the room layout for:- Watchtower. --- Jump off the top Esmeralda --- jump off the top The elephant problem? --- jump off the top The restricted height climb ropes --- jump off the top Those kind of things were not the focus of my attention. Just squashing both games into 48k was all I wanted to do. Addendum: The rooms for JSW, now have the addition of collapsing floors, 2nd Nasty plus a switch. Plenty of extra tile graphics to redesign the top of the Elephant with a special case added into the code to handle the redesign. But where do changes stop?

How deadly is the solar beam? The play through enters the solar power room with a score of 46,456,230 and after completing the room has a score of 40,256,330. This means the solar beam zapped £6.2 million (approx) monies from Willy. Game wise the player would have had a higher score, if theyhad sacrificed all of their lives in the previous room. Or even completed the last kong room and obtained the kong bonus for each of their lives. Of course those higher score's do not complete the game. So avoiding contact with the solar beam, is a room playing need for completion if a higer score with all lives intact is wanted.