Norman Sword

No idea if this has been mentioned before. When the game pauses and starts its colour cycling, there is an anomaly in the code that handles the colour cycle. For example when the game is paused in the "to the kitchens/main stairway" there is a conveyor in the middle of the screen that due to the nature of this anomaly starts to flash. This is because the code has made the assumption that adding (18 hex) (24 decimal) to its colour. will not overflow into the flash bit. (clearly wrong because it can be seen to flash) The code in question . 8AF3 LD A,(HL) ;get ATTribute 8AF4 ADD A,$03 ; cycle ink 8AF6 AND $07 ;force in bounds 8AF8 LD D,A ;ink colour to D 8AF9 LD A,(HL) ;get attribute ;*** AND 10111000b to stop overflow into flash 8AFA ADD A,$18 ;cycle PAPER ; THE next instruction makes the assumption that the colour can not overflow into the flash bit 8AFC AND $b8 ;10111000B 8AFE OR D ;Merge in the new INK colour Not all that noticeable, but this is an anomaly that was probably not intended. Easily fixed within the realms of an assembler. Probably not worth fixing in the context of the finnished game

inc l djnz exp ; repeat for the byte (4 cells) inc de jr nz,EXPANSION ; first 256 done be careful of any slight editing you might be tempted to do. The routine as shown was modified to use different data (the overall routine works). I have for example listed four instructions from the routine. Of note the first instruction sets the zero flag, the last instruction of the four acts on the zero flag set by the inc L. Note that the DJNZ and the INC DE do not change the zero flag.

The code as listed was not tested (otherwise the mistake would have been obvious on first run). Yes the RRCA should have been RLCA ....

The version I recently posted also has the car changed. But more importantly I fixed the very weird keyboard that Matthew drew. On the long list of changes that have been done to "FIX" JSW, you have left the erroneous square from the title screen unchanged. Inside the lower portion of the letter "S". Is a diagonal square that has the top part green and the lower part black. This should be - top part green lower part blue.

I have not finished the editing. This Forums interface reacts to certain combinations of keys on my keyboard. In most case the result is a few seconds delay In other cases it interprets the keystrokes as an intention to POST Since I was nowhere near finished with my comment I have deleted the lot. And this comment is the result of my inability to delete an unwanted POST

Invert could use the same logic e.g ytable equ 6000h ;;; set to where ever the ytable is org 8000h ld iy,ytable ld ix,ytable invert ld e,(ix) inc ixl ld d,(ix) res 5,d dec iyl ld h,(iy) dec iyl ld l,(iy) ld bc,32 ldir inc ixl jr nz,invert ;That is it ;-------------------------------------------------------------------------------------------------- : this now becomes more complex because the attributes need copying as well attrib equ somewhere (the copy screen) ld de,5800h ld hl,attrib+15*32 exx ld a,4 ; the value that decides when the atrrib is changed ld iy,ytable ld ix,ytable invert ld e,(ix) inc ixl ld d,(ix) res 5,d dec iyl ld h,(iy) dec iyl ld l,(iy) ld bc,32 ldir inc a and 7 jr nz,not_yet exx ld bc,32 ldir ld bc,-64 add hl,bc exx not_yet inc ixl jr nz,invert ;That is it

Quicker to just write afresh Nostalgia ; the attrib must have been cleared else this will look a mess ; which would be done once on room entry ytable equ 6000h ;;; set to where ever the ytable is org 8000h ;enter with a=screen offset ; 0 to 127 ;;; 128 to 255 act the same as 0 to 127 ; ld iy,ytable ; add a,a ; ld c,a ; ld b,0 ; add iy,bc ld iyh, high ytable add a,a ld iyl ,a ld ix,ytable roll ld e,(ix) inc ixl ld d,(ix) res 5,d ld l,(iy) inc iyl ld h,(iy) inc iyl ld bc,32 ldir inc ixl jr nz,roll ;That is it ;;;I was too quick to post . I think that is NOW it

Since this was a program in development that has had its source code deleted. (actually on a burned out hard drive) A number of problems are known about and might have been in the pipeline to be eradicated. All the screens that mention demolition or purchased by the state and several others. Had been earmarked to be changed. The game map was being changed often up until the source code demise. It was known that two screens where inaccessible. If either of theses contain objects then the game can not be completed as it is. This program was a test vehicle to see what could be done. All the elements where starting to be put in place for the room designs to begin. Just before the code was lost. New extended guardian types had been written. More planed known original types not in order Horizontal Guardian Vertical Guardian Arrow Rope To these had been added Logic seeking horizontal Full logic seeking. Moving vertically and horizontally within the screen Of these types only one in in this development game. The Logic seeking Horizontal. Used once in "pruned roses" The first of the full logic seeking sprites was in a redesigned "bought by the state 5" You will have to take my word for it. But this type of sprite did move around both horizontally and vertically, avoiding the rooms graphics and seeking out willy. They moved vertically slower than willy, and they could therefore be enticed into positions that they found difficult to escape from. To play against this type of sprite required the player to manoeuvre the guardian into a trap position. --- That is why the room "bought by the state 5" had the row of upturned box's along the bottom. They where to trap the guardian below whilst moving above them. The final room design for this room was different. And it contained very little of the graphics seen in this room. From the short viewing I saw (and played) the logic seeking sprite where a very good addition to the normal sprite... Rooms where designed and then stored on a different basis to the original. A rooms data starts with a code byte. this signifies if the room has vertical compression or not. If vertical compression a stream of bytes describe the vertical components. This removes stairs and vertical components of the room. after the stream of vertical components comes a stream of horizontal components. These define what is left Placed on top of the room description is the normal conveyor and stair. This convention allows multiple stairs (but all in the same direction) plus multiple conveyors. Of which one is animated (pretty standard convention) The bulk of the remaining room description, sprite/guardians/border colour etc was stripped of all wasteful data. and a flag added to indicate if extra graphics are need or extra events are needed All unused guardian slots were deleted. All guardian definitions were reduced from eight bytes to 7 bytes. The code to do this is small, but saves 128 bytes of data when all the guardians for a room have been extracted, the code looked at the flag byte and started extraction of extras to be over laid on top of the room graphic data. This entails expanding/contractng floors . collapsing floors, wall blockers etc the above explanation is to show that to change a single room block without the source code is very difficult. (with the source code a matter of minutes) without the source code <<quicker to rewrite the game>>

I modified the file that was the last version, to make it more in keeping with what is expected. E.g. start at the title screen and have the start room as the Bathroom. Plus removal of the start status of being in cheat mode. I assumed that the modification to the game file was ok. Well contrary to what I expected the floor in slum clearance area 3 is missing. Which is something I must have done. I will attempt to correct my error.... Assuming I can. The other possibility is to download the original version which starts in a different room, and has the cheats enabled by default. The cheatcode is needed to remove the default cheats. But first I will investigate why the floor is missing ?

First statement is that this program is still running in 48k. These are not changes due to having more memory. These changes are due to rewrites in logic to shrink the core code down. Plus extensive modifications to how the rooms are stored. In this version ropes can be specified for position and length. It will also be noted that the ropes do not pick up willy when they pass though an object. It is permissible for other sprites to cross the ropes path. It is also permissible for ropes to collide with each other. Objects are not collected by ropes or arrows passing over them. The number of guardians in this version is still fixed at 127, however each guardian is modified by a guardian sub class. This permits the guardian to have numerous clone types For example the arrows are sub classed to be movable and have their timing changed. Ropes are moveable and can have their length changed. The movement of sprites has been redefined to include a mid sprite turn (definable and switch-able on a sprite by sprite basis or a room basis) The solar beam is movable and switch-able. The ability to jump into certain wall blocks has been greatly reduced. the code is 100% symmetrical.

I have resurrected this file By Derrick.P.Rowson. Which was on a crashed hard drive. This is Not finished, and never will be due to a catastrophic failure of the hard drive. This is a few weeks work and alas there was no backup of the program. This version does not have any of the new logic playing sprites. E.g. sprites that followed willy around both vertically and horizontally, and were free roaming around the screen. The logic had enough sense to move the sprite wherever it needed. This version was a development towards having the full Manic Miner + Jet Set Willy in 48k This game has inbuilt options. (password protected) jsw1.tap

The air supply. Decrease_Air ;original code at 35388 ld hl,Game_Clock ;original reference 32957 ld a,(hl) sub 4 ld (hl),a ;; ld b,a ;>>>>delete this instruction jr nc,Display_air ex de,hl ;save hl ld hl,Remain_Air ;original reference 32956 ld a,(hl) cp 36 ;if this returns then is should leave the air at "0" jr nz,decrease_bar xor a ld (de),a ret decrease_bar dec (hl) ld a,(de) ;>>>>> change from >>ld a,b ;21 Display_air AND 11100000b ;224 This is the slight change. I do not know if this would sit in the original space. tiny change 1 byte shorter

Scope of the editing. Forget the notion I added patches, this is a source code rewrite from the first byte to the last. I do not think there is any byte from the start of manic miner up to #b000 that is in the same place. This was not a version written using patches, but a version rewritten from the ground up using Matthews code as the basis. For example a walk from the left wall in the central cavern to the right wall in the central cavern. In the original Bug-byte version this takes just under ten seconds (9.83s) this newer version takes abour 7.42s which is a speed increase of 2.41s. This is over 20% faster. Every instance of code that was deemed to be wasting time or memory was rewritten. trivial changes that can be seen/heard Object collection makes a noise the light beam makes a noise if it collides with willy collisions make a noise the skylabs landing make a noise. the skylabs do not colour in the landing platform. logic rewrite collapsing floors could have blank lines. logic rewrite conveyors move slower. Manic Miner screen Game completion screen Sprite Easter egg screen Manic miner easter egg screen credit screen Icons new cheat implementation method the list of changes is vast I will do a count of the number of code changes...... I gave up after passing 2,500 new opcode/instructions in the code. Then there is the matter of the additional data for the icons, sprite mask, explosions The explosions uses 4k of memory 256 bytes extra just to store the 2nd scrolling message there is a big data table that lists the changes data between the two versions Forget the notion I added patches, this is a source code rewrite from the first byte to the last. .

This is a modified version of Matthews Manic Miner. The core code has been edited extensively. All data was left intact from #b000 onwards, but is modified at run time to swap between the Bug-byte version and the Software projects version of Manic Miner. The list of changes is very long. Most of these changes are not evident, some are very evident. keys 1) change the style of jumping and movement after cheat invoke 4) Immortality 3) Platform rebuild - when invoked the "9" key rebuilds the platforms Holding down the "9" key and pressing 1) move back a cavern 2) move forward a cavern BB-SP.tap

The CPC Amstrad has extensive firmware jump blocks to control most of its operations. The firmware was left intact on manic miner for the 464. This was in the era when the CPC did not have Disc drives. One of the calls to the firmware jump block is the request to implement a user vectored interrupt. The firm ware has the ability to permit 6 interrupts per frame. Any of the 6 interrupts can be chosen. The interrupt SHOULD occur at the same place every time, and this was used to change the screen colours twice every frame loop. The Interrupt chosen changes the colours for the lower part of the screen, another interrupt puts he colours back for the playing area. Thus in a normal room there can be six colours. Four in the playing area. Four for the lower screen, and two which are common for both the upper and lower portions of the screen. Giving a room six colours in the mode 1 four colour mode. Every so often the CPC firmware gets the values wrong with the result of the colours being changed at the wrong moment. As far as I am aware this is a problem caused by the amstrads CPC firmware.

The code listed at the end of Jet set willy is the Tandy operating system. Used by the recent hard drive Matthew had bought. The hard drive overlays the top of ram for its operating system. The floppy disc uses another area of Ram. The method Matthew used to handshake the two computers has nothing to do with any of the code seen in that area. The handshaking was done using the parallel printer cable on the Tandy which was handshaked with a board build by Matthew that sat on the back of the spectrum. The board was built using wire wrap and multiple 74LS chips. The software used implemented a primitive source to destination block move. e.g. the source and the destinations address would be the same on both the Tandy and the Spectrum. The hard drive is the reason the extra four rooms, which would have sat at the top of memory, are missing from the game. Since Manic Miner has data in that area, it is apparent that Matthew bought the hard drive between development of Manic Miner and Jet set willy.

; THE GAME CLOCK ;original 35389 LD A,(32957) :GAME CLOCK 35391 SUB 4 35393 LD (32957),A 35396 CP -4 35398 JR NZ,35413 35400 LD A,(32956) ;AIR SUPPLY 35403 CP 36 35405 RET Z 35406 DEC A 35407 LD (32956),A 35410 LD A,(32957) 35413 AND 224 ;change to 35389 LD A,(32957) 35391 SUB 4 ; Now becomes possible to change (not recommended) 35393 LD (32957),A 35396 nop ;<<<< poke 35396,00 35397 nop ;<<<< poke 35397,00 35398 jr nc,35413 ;<<<< poke 35398,48 35400 LD A,(32956) 35403 CP 36 35405 RET Z 35406 DEC A 35407 LD (32956),A 35410 LD A,(32957) 35413 AND 224 ; this will remove the restriction on having the game clock ; fixed to 4,8,12,16,etc ; any value will now work ; as far as I can see no routine uses the bottom two bits ; horizontal guardians use the toggling of bit 2 - so unused bit 0-1 ; Eugene uses the value/4 for colour - so unused bit 0-1 ; Kong beast uses the value/32 - again unused bit 0-1 ; I can find no usage for the lower two bits ; for example if the value of SUB 4 is change to say sub 2 the game will still run ; the (slow) horizontal sprites will become jerky ; the value can be changed to SUB 1, the (slow) sprites will become even jerkier, but the game will still run ; this change (not recommended) also changes the decrease in air supply speed. ; SUB 1 gives you four times as long in a cavern, and big points when it is finished ; Of course this type of change also affects the animation of Kong and the colour change in Eugene, ;both of which are cosmetic ;--------------------------------- ; More on the value in game clock. ; The game uses two routines to draw the air supply ; the first routine (R1) draws the full bytes remaining, and is drawn on entry to a cavern ; ; The second routine (R2)(which is the one part listed at the top of this comment) ; is concerned with the drawing of the part byte (bits) at the end of the air supply ; this routine erases the air bar as it draws, and for most values that are multiples of 4 no ; problem will be encountered. ; ; However if on the first pass after initialisation, if it ecounters a "0" then this routine (R2) will ; immediatly move the air supply position left one byte. This will result in the initial drawing ; having a glitch, at the end of the air supply graphic. Due to the last portion being un-erased ; ; Any initial values that are not multiples of 4 will also hang the game on finishing a cavern ; Plus the air supply will remain cycling on the end of the air supply bar ; ; ; AFTER MODS-- ; ; first pass after initialisation (GAME CLOCK) ; This byte can now hold any value, that does not set the carry on the first pass after initialisation ; Since the carry will be set for values of 0,1,2 and 3 they should be avoided. ; This is because on the first pass, the routine (R2) will immediately move the whole byte counter left by one byte. ; This will leave the graphic at the end of the air supply un-deleted. (a cosmetic glitch) ; ; No other value should cause a problem, because the restriction of being a multiple of 4 will have been removed. ; In summary, modify with three pokes.. Any value bar (0,1,2,3) for the Game counter

Shifting the room base ld a,(room_num) or 0c0h ld h,a ld l,0 looking at #c0 in binary we have 11000000b, notice the lower six bits are free. The room number is between 0 and 63 or 00000000b and 00111111b, note the top two bits are not used when the two valued are or'd together the composite value is the addition of the two values. if you want to move the base value then add it ld a,(room_num) add a,#b5 ld h,a ld l,0

In Matthews game there exists lots of clear logic flaws. Something that is missed, Probably because you are so busy worrying about the spelling of some room name. I will let you get on with it... By the time you work out That ex hl,de is not an opcode you will be celebrating the groups 100th birthday

Another needless quote. You are clueless and still you quote.... Yes you have totally pissed me off

You are prattling again... You squash one byte from a routine and stand back amazed. I rewrite the routine and you start the needless quotes on he did this someone else did that. For what ultimate point You are fiddling whilst I am doing what is needed.

The version I have running has multiple title screens It has collapsing floors It has walls/floors that move It has multiple tunes It has as stated before 102 rooms This was achieved by multiple optimisations throughout the code All done in the space of four weeks.... This group has done what???? Apart from needless quotes, being obsessive over trivia. Not a lot

You are quoting thing just for the sake of quoting. It does not illustrate anything.

without quoting others who have posted posting on this topic JSW2:- General ignorance posted by this group concerning this game. JSW2 does not compress any of its code., and does not run with compressed code. On the other hand JSW runs with compressed data. the same as JSW2 Your scope of ignorance on this subject is why as a group you miss the bigger picture. You are spending so much time on trivia, so much time on conjecture. No one knows what Matthew might or meant to achieve. Because he defined graphics does not indicate he was definitely going to use them. Conjecture on your part.

My code permits me to re write Matthews game in as small a space as possible. I have running in 48k a version of his code with 102 rooms that runs faster. What has your byte by pedantic byte achieved?