Norman Sword

Software Project screens.

The Bug Byte pictures.

I took up the challenge. Apart from the full size main screen pictures, I have changed every single screen. The auto play in only one cavern is different. (Amoebatrons' Revenge.) LASTv2.tap

New data for Amoebatron's Revenge let's Willy progress through that cavern in the SP version so thanks crem. The data in the Skylab is one byte different (or more exactly, has one bit difference) I am inclined to believe the data is wrong, but until I see the Skylab in detail on a full SP version, I can not be certain. Your edit of the above was whilst I wrote this. So I will assume the bit in question is corrupted data.

The change in sprite data between Software projects and Bug Byte does throw up a problem in Amoebatrons' Revenge. Unless another route is listed, then the present data gets Willy killed fairly early on. ( e.g. the return journey along the lowest level platforms.Willy is killed by the first sprite when doing his shuffle back and forth, to do the 2nd jump) I also looked at my data that was extracted for the version of Manic Miner that plays both versions. Either the data is wrong or the data changes by one pixel between the bug byte and the software project game. (Skylab landing bay) This change came to light when I was checking what data actually changes between the two versions. If I could find a picture of the skylab screen from the software projects game, then I can confirm change. Just at the moment I have more pressing things to do elsewhere.

Been writing z80 since 1982 and I have witnessed many changes. Originally nearly all hex was 01234h, but the format used would be forced upon you by whatever assembler you used. The assemblers did not all use the same syntax. At present I use whatever comes to hand, and yes I will use every notation 1235h,#1234,$1234,0x1234 and my present assembler is happy with all of them After writing a lot of code it becomes easier to use #123a for no other reason than it becomes tedious when editing a lot of hex data to remember to make sure that any hex data is preceded by a non hex digit. eg whilst 1fffh is valid d000h is not and needs changing to 0d000h. When a lot of data is being manually edited and the assembler keeps throwing out the data. It becomes easier to use a format that always complies with the syntax so changing #8000 to #c000 will always assemble whilst the edit of 8000h to c000h is a syntax error.

This is an edit of version 4. The file I have done all the Major edits on is around version 9d. The only problem with going to the latest version, which looks and feels better, is the fact that it is 100% a playable game. This version named here as LASTv.tap is a backward edit of version 9d. I lifted the data from that version and inserted it into version 4, I then edited it to include the Warehouse data from the Software Projects version of the game. This Version has only one purpose and that is to display the game being auto played. (e.g. for research) the game has been edited to remove the parts that enable playing. Which makes key selection awkward. On the title screen press {K} to bring up a sub menu. In the sub menu:- Press {ENTER} to play - This version is unplayable Press {L} to auto play the cavern Press{Z} and {X} to select a cavern to begin playing from Press {V} to change the version. The version played will only use the graphics from the Bug Byte game. In the warehouse the vertical sprite graphic will be changed to the sprite graphic from the software projects game. The middle of the lower line will display the version being played (in game mode) , or in the sub menu, the graphic next to the portal will indicate the version selected. The harvester blade for Bug Byte and the Penrose triangle for software projects. [And before you check, yes it will change the playing room graphics, if {V} is pressed while displaying the warehouse in the sub menu.] ----------------------------------------------------------- About the auto play data The auto play data has in some instances been replaced with mostly data I generated. Their was no difference in score between the auto generated data and my data. Since my data looks less frantic, I used that data where i had it. IRF edited the Warehouse data for the Bug byte version of auto move, so that is used. He also edited the data for another room, which turned out to be pretty close to the data I already had. ------------------------------------------------------------ To rapid auto play is press {K} on the title screen followed by {L} - the game will auto play one complete cycle back to the central cavern. LASTv.tap <<< the auto play game file Auto Play score for Bug byte version is 39,530 Auto play score for Software Projects version is 39,531

Patch mode vector using jp (hl) Taken from the source code of JSW2. So it is JSW2 mode

When I added the original change the beam to red its purpose was to enhance the point of contact with the light beam. I also added sound in some versions. I changed the code as shown above to enhance a technical point, and that change of code seems to be what you are copying. The change was and still is just a change for technical analysis, at game speed it presents just a slight flicker of Willy and does nothing to enhance playing the game. I will not be changing any version I write to feature a clinical analysis feature instead of what I already use. The beam will stay red.

The LDIR instruction was written to enable interrupts to occur whilst the instruction takes place. Because the Z80 system uses interrupts for a host of external devices as well as synchronisation and housekeeping tasks. Enabling interrupts while an LDIR is taking place was important and that is why the LDIR is so slow. After every move of one byte the program counter moves back and reloads the LDIR instruction and repeats the one byte move. JSW does not use the interrupts and therefore any external block move sequence that can be used in place of LDIR will have absolutely no impact on what the game does. So if you externally move the block in place of the LDIR doing it. The game will take no notice and just carry on. I don't think it even cares about T-states - used mainly for the refresh register and again not used.

You can speed up the Copy routines by 25% by changing to inline LDI - But that necessitates knowing z80 and the writing the code. You can also delete #89ad (3 bytes) animate willy along the bottom(graphics) #89ef (3 bytes) animate conveyors(graphics) #8a3a (3 bytes) print the time(text) #8a46 (3 bytes) print items(text) #944e (3bytes) animates graphic item/object #8e20 (2bytes) and #8e23(2bytes) remove the jumping/falling sfx Plus make sure the tune is turned off. When doing the most basic operation a few million times needlessly, It all starts to add up to hours.

The code for the skylab:- If the test for the cavern was done at the entry for vertical sprites #8ef1, then the skylab mess around in code disappears. E.g. call the vertical sprites #8ef1 and test for the skylab cavern. If in the skylab then branch to the skylab code. Skylab does a normal return, and the Kill willy detection does the same jump as in all the other sprite routines 8777 LD A,($8407) Pick up the number of the current cavern from 8407 877A CP $0D Are we in Skylab Landing Bay? 877C JP Z,$8E75 If so, move and draw the Skylabs 877F LD A,($8407)Pick up the number of the current cavern from 8407 8782 CP $08Are we in Wacky Amoebatrons or beyond? 8784 CALL NC,$8EF1 If so, move and draw the vertical guardians ========================================. 8EF1 cp $0d process verticals but is this the skylab jp z,$8e75 go instead to the skylab routine - carry on as normal - but the above five bytes has no place to sit in the fixed Matthew code layout. - but would have been simple for Matthew to have done. And the code would have been smaller.

This routine I have used several times in various ways. The beam of light is yellow until the point of contact with Willy, then it turns red. The beam once red, stays red until the end of the beams passage across the screen. So in the picture the red is indicating the point of contact and the path in red from that point onwards. Having just tested just the point of contact in red as a routine, I can say it looses the visual impact of leaving the beam red from the point of contact onwards.

Across the screen walk for me:- Chrome 8 sec C Cleaner browser 8 sec Edge 8 sec Opera 8 sec Opera GX 8 sec Brave 8 sec Firefox 8 sec I did have timeouts loading in Opera, Opera Gx, Edge. But all eventually loaded.

Manic Miner contains a feature that vertical guardians do not adjust their attributes to within the minimum area needed. It is evident Matthew was aware of this and adjusted the sprites accordingly. By the time we get to the skylab and other screens the attribute bleed into un needed squares becomes noticeable. But not in need of a re write (this is NOT a bug) I have edited the routine to enable me to play either with the normal style routine or the routine that checks for the extra square when needed. The result in the solar power room is - With 3 attributes coloured in by the sprites - and deflecting the solar beam - 1137 points- Bottom With checking and varying between 2 and 3 attributes deflecting the beam - 1129 points. - top pic

The IRF data stream for the processing plant does not work (close, but no cigar) I have corrected the data stream (as below) Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q . . . . . . . R R R R RM . . . . . . . . . . . . . . . . . . . . R R R R R RM . . . . . . . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R QM . . . . . . . . . . . . . . . . . . Q Q Q Q Q Q Q Q QM . . . . . . . . . . . . . . . . . . QM . . . . . . . . . . . . . . . . . . Q . . . . . . . M . . . . . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . . . . . . . R R R R R R R R R R R R R R R R R R R R RM . . . . . . . . . . . . RM . . . . . . . . . . . . . . . RM . . . . . . . . . . . . . . . . . . Q Q Q Q QM . . . . . . . . . . . . RM . . . . . . . . . . . . R R RM . . . . . . . . . . . . Q QM . . . . . . . . . . . . . . . R R RM . . . . . . . . . . . .

The latest auto High score 39530 mms5.tap

Investigating how I can clean up the keyboard data as presented. Not as simple as I originally thought. The data for the keyboard presents a stream of key presses. Which I show in the demo game. The problem presented to me, when I try to modify the visual text stream is what can and can not be modified. If Willy starts a jump the visual data stream switches off (no keys needed while travelling in an arc across the screen). The visual data just shows a series of nulls "." indicating no key pressed. The game however might be moving Willy or Willy might be static, in a vertical jump. There is no indication of when the jump lands and no indication in the stream of keyboard data inputs of what is happening. It becomes difficult to correlate the data with movement. The amount of horizontal movement is directly related to the amount of time Willy is in flight. The Data steam will give no indication of flight termination. e.g. when or where willy lands on a platform In order to tie the data with movement you have to watch the game being played. It does still leave big gaps in the movement when jumping and possible just standing still static play. It also loses the X position of willy because willy can move in the x direction when jumping and the data will give no indication as to when the x-movement stops. and possible stationary play begins. In order to tie flight movement and no keyboard activity, with static no keyboard activity I have taken the step of recording the game status of willy as regards to platforms. This status is surprisingly not recorded in the game with any meaningful variables. So I have added my own. (This problem will also be evident in JSW- the platform status is not recorded) No idea how far I will go with looking at this, already getting pretty complicated for what could be little reward in progress towards cleaning the data up.

Out of the 20 caverns, several have been changed from the listed automated version. My calculated routes using data streams - are less frantic than the automated routes, So those are used Central Cavern - The Cold Room - The Vat - All use my data stream route Eugene's Lair - I altered the end part to remove the back and forth turn and now IRF the Warehouse. It might be easier for me to auto remove the parts that are just frantic for no real reason. Amoebatrons' Revenge is one such room. I will look at the original data.

mms5.tapCleaner less jerky route for the Warehouse as listed above, by IRF

Misuse of terminology. The data held for each room does not contain a vector (jump address) it contains an index number. The index number is used to index into a jump block and from there an address is extracted. The usage of jump blocks to store a list of address's for routines is used in several operating systems and is nothing new. However in the context of JSW the usage of using an index number to index into a jump block was used 36 years ago in JSW2. Here an index number was obtained from the room data (event data) and that number was used to index into two tables . The first table was a list of initialisation routines for the event. The second table was a list of Main Loop runtime routines for the event. So you are using a primitive version of JSW2 event processing

Further to the topic of orientation of Willy upon game start. This automatically causes an auto play problem. If willy needs to turn around at game start, you have wasted a whole frame. The start orientation if collecting the bath tap first has a change of one frame between the differences in direction. For playing the whole game one frame will not be detectable unless playing to 1/100 sec style timings. Once the initial room has been played then Willies state from that room onwards is set. However that initial one state change can/could cause problems. That's #85d0 The value in #85d2 the animation frame adds another problem This does pose the question. Do you force the initial state as being the state that is in operation when the game is loaded. -------------------------------------------------------------------- Stairs I glanced at your questions and do wonder why you are concerned about the pixel shift of Willy when on a stair. When on a stair the game treats him as standing on a platform. If you remove the code for stair displacement. Willy walks up the stairs as a series of steps. He is treated as being on character/tile boundaries and NEVER treated as being displaced from the Character/tile boundary. (jumping is another story). On a stair he is visually drawn shifted to appear as in he is moving diagonally. The game code whilst on a stair treats Willy as stepping up the stairs one character at a time. In a nutshell. If willy is on a platform- The code checks the direction of the stairs For each direction of stair we check the block directly below his feet. For a stair going from left to right upwards / we check the block beneath his right foot for a stair tile. For a stair going the other way we check the block under his left foot for the stair tile. If the stair tile/block is present we displace Willy from the vertical (only on the drawing of Willy and this displacement is not saved anywhere) For stairs / we use the animation frame and add a displacement of 6/4/2/0 (pixels) for each animation stage for stairs sloping the other way we add 0/2/4/6(pixels) for each animation stage. As stated Willy never code wise moves from the fixed character/tile boundaries- the displacement is an optical trick to make him look like he walks up and down the stairs. ========================================================================================================== Addendum the pixel offset is doubled for the YTABLE offset - to move willy down the screen 2 pixels we add 4 to his YTABLE position, since each entry in the YTABLE is 2 bytes.

Trying room 17 new play as listed above...In the BUG BYTE version. Willy does not manage the first jump over the rotating Harvester

The simplest modification I can come up with is just add a 3 byte modification such as:- In decimal 37314 LD A,(IX+0) Pick up the first byte of the current entity's buffer 37317 CP 255 Have we already dealt with every entity? 37319 RET Z Return if so 37320 AND 7 Keep only bits 0-2 (which determine the type of entity) 37322 JP Z,37811 Jump to consider the next entity buffer if this one is not being used 37325 CP 3 Is this a rope? 37327 JP Z,37540 Jump if so 37330 CP 4 Is this an arrow? <<<<<<<<<<<<<<< mod to JP 37811 37332 JR Z,37431 Jump if so In hex 91C2 LD A,(IX+$00) Pick up the first byte of the current entity's buffer 91C5 CP $FF Have we already dealt with every entity? 91C7 RET Z Return if so 91C8 AND $07 Keep only bits 0-2 (which determine the type of entity) 91CA JP Z,$93B3 Jump to consider the next entity buffer if this one is not being used 91CD CP $03 Is this a rope? 91CF JP Z,$92A4 Jump if so 91D2 CP $04 Is this an arrow? <<<<<<<<<<<<<<< mod to JP $93B3 91D4 JR Z,$9237 Jump if so This kills all the sprites but leaves the ropes alone. So you can wander ALL the rooms including Esmeralda

Technical problem of turning off the sprites. Turning of the sprites turns off the ropes. The consequence of having no ropes are what happens to rooms that at present have ropes. 1) the beach can no longer be traversed. This stops access to the Yacht and the Bow. 2)On the roof can not be traversed. This stops access to Up on batt/We must per/ Watch Tower/I'm sure /on top of the house.