Norman Sword

10 PLOT INK RND*7 ; RND*255 , RND*175: GOTO 10 Explode.tap is just a bit more complicated. The backdrop has 128 stars that are being tracked. E.g. Every so often a star in the backdrop is moved. The explosions move 160 points. The maximum number of explosions is 8. so the explode routine tracks and moves 1280 points - giving the total of 1408 points the program is tracking and moving. The whilst the above is happening it changes the attributes of differing squares. -----------------------

This is basically a re write of the routine I added to Manic Miner (dual - Software Projects and Bug Byte). Major difference being it is not constrained to a game playing area, and the backdrop. explode.tap

Balloon Popping. The solar ray is controlled by the vertical sprites. The skylab sprites step sideways. Either left or right with a programmable defined step. (each sprite has its own step) Due to the start positions being anywhere, that stepping could move the sprite over a wall and/or the graphic depiction of the remaining air/oxygen. Whenever this instance happens, the sprite is moved again. Whenever the double move condition is done, the solar ray is switched on and off. The magenta skylab comes down 3 times before stepping onto the edge. It switches on/off the solar ray and is moved to the left of the screen to repeat. + the yellow Balloon moving left

The last sprite in Particle Collision Chamber has a horizontal component of movement. I did try most of them having a horizontal component and concluded -<NO>- In Particle Collision Chamber when played in TORCH mode. The balls have a high vertical velocity which when coupled to a horizontal component made their paths seem erratic when they could not be seen. Your response (above) was while I typed this. In Balloon Popping -- The solar ray is only switched on in EXPERT, ACE and TORCH modes.

The room/cavern count was set as (you will not know, until you try) Technically their are 7 caverns in this code. It was just as hard for me to delete the rooms/caverns as it was to add new ones. Having now changed the code to now allow room deletions I can alter room count with greater ease. Caverns included. That are changed. 1) Smelly Genes, 2)Yellow stones, 3)Balloon Popping, 4)Virus attack, 5)Particle Collision Chamber Left as a game terminator - Control one. Particle Collision chamber is different from the final version. In Balloon popping -- When playing the room, the direction of deflection of the solar ray is set to the side of the room that Willy is in relative to the beams start point. In other words the beams will deflect left or right depending on where Willy is.

Very similar - written in assembler - I took the visual idea of above and wrote the code in assembler. twirl.tap the 2nd version, is the progression in complexity twirl2.tap the 3rd version plays with speed as well twirl3.tap The very last version - which changes the checker pattern The real purpose of writing this was to show the size difference between C and assembler. twirl4.tap Footnote. Each of these tap files contains a header and a basic loader. All the running code data is contained within the assembled file. The size of each version is 121 bytes less than the files size. E.g. Twirl tap has 367 bytes of code and data. -- Twirl2.tap has 387 bytes of code and data -- etc..

I decided when I was writing Manic Panic to make the screens as easy as possible - To celebrate nearly 600 downloads (on this website) (it is 598 at the moment) , I will show how four of the screens started off and where then changed to be easier. Only 4 screens here. mp_4rrm.tap

I looked at the code from the above - it was not quite what I wanted - This is more how I wanted it to look. The struggle between areas of colour, for domination. ======================================== The routine fills the screen with colour. Then it selects a (random) position and checks to see what colour is dominant in that area. The dominant colour, then fills the local area. The selection of areas continues for 10,000 loops. Then the whole process is repeated. Shape2.tap

I write in assembler. This is called shape. Surprisingly it is running flat out with no delays. Shape.tap

The full list of alternate (shorter) opcodes using either RRCA for RRC A and RLCA for RLC A in JSW. The two sets of opcodes are not exactly the same in operation regarding flags. But in their context within JSW swapping to the shorter version has no impact on the code. Besides the value at #8f14, all the other uses are in the conveyor routine. RLC A at #9514 and #9516 RRC A at #9527 and #9529

I will leave you to get on with it then. Addendum Meaning :- I will not bother myself any further on your behalf.

Turning off the music does not interfere with movement. E.g. You can turn the music on/off whilst playing the game. So the music can be turned off on the 2nd frame - when played automatically.

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.