JSW As Manufacturer (probably) intended .. kind of...

[Metalmickey]

Mickey, I've just spotted a minor bug in the JSW 'Game Over' routine - the 'AND #FA' at #8CAF should be replaced with 'AND #F8'.

 

This doesn't affect the original game, it's more of a 'game engine' fix, but it allows a full range of INK colour choices for the Barrel on the Game Over screen.  With the AND #FA in place, the choice of INK colour for the Foot/Willy can restrict the possible colours for the Barrel.

Interesting ... will implement that to the 'rebuild' i'm currently working on

[Metalmickey]

 

.... I note that 'break' does not work actually *during* the 'dash' either, another useful change. The original does (I just tried this, do not recall ever having tried that before)

I never noticed that, i have changed emulators now, i'm using SPIN since i am re-assembling the game at the mo .. can't think of anything i have altered but maybe i've incorrectly copied over an opcode or something..

[Metalmickey]

Slightly unrelated but I had an opposite issue actually as I wanted to restrict it but keep the sprites the correct colour, after some changes to the code it still would not play nice (in that case) until I changed AND to ADD ( ! ) then it did exactly what I needed. Idea to try that came from the 'moving room' data where ADD is needed to get it to work properly...

 

On topic, how are things going now Metalmickey with progress ? :)

painfully slow at present, still finishing rewriting the disassembly, not currently re-assembling properly, there's a load of typos to correct .. on the plus side i've now been able to make more detailed notes about all the potential free space in addition to what Skoolkid has documented

[IRF]

I note that 'break' does not work actually *during* the 'dash' either, another useful change. The original does (I just tried this, do not recall ever having tried that before)

 

Andy, by 'break' [brake?] in the above did you mean pressing the 'P' key to stop Willy from running towards the toilet?  (Something which I came up with a fix for, although I'm not sure if Mickey has implemented that fix yet or not?)  Or did you mean pressing SHIFT+SPACE to abandon the game during the toilet dash?

[Spider]

Andy, by 'break' [brake?] in the above did you mean pressing the 'P' key to stop Willy from running towards the toilet?  (Something which I came up with a fix for, although I'm not sure if Mickey has implemented that fix yet or not?)  Or did you mean pressing SHIFT+SPACE to abandon the game during the toilet dash?

Shift/Space aka "abandon" :)

[Metalmickey]

peculiar, i just re-did that RZX for my own purposes and yet i can now quit the game during Willy's toilet dash ... although i am using SPIN now i can't remember if i created the RZX with it or Spectaculator, i know Spectaculator can create a few odd effects when making RZX files...

[Metalmickey]

as previously mentioned, rather than attempting to finalise this project and assume it to be complete, i've decided to just leave it as an ongoing concern (if that's the right word), i think that as long as this website continues to attract interest then someone somewhere will at some point be discussing an issue, oddity, quirk, bug within the game or some other point of discussion that perhaps i can look into tackling and perhaps improving somehow, for me this is good practice as it is helping me to understand assembly language which i am (very) slowly but (not so) surely beginning to get to grips with, i'm a long way from where i started but still a million miles from considering myself in any way competent, my next step now is to add a big chunk of info to the blurb, this will include all of the address changes to the game code. I am also developing BASIC loader that will convert the original version to the new patched version at the press of a key, the challenge here is of course to make it small enough to squeeze into the system memory without going into the game area, there are quite a lot of changes now....

[Spider]

Regarding the 'loader space' , there are quite a few things you can do to save a few bytes, and these *do* add up quite well.

 

Let me provide some random examples, there are more but these may help, read them as 'before vs after'

 

PRINT AT 0,0 ; ... PRINT AT NOT PI, NOT PI;

 

LET A = 0 ... LET A = NOT PI

 

LET A = 1 ... LET A = SGN PI

 

CLEAR 28000 ... CLEAR VAL "28000" ...or... CLEAR 28E3

 

POKE 23659,2 ... POKE VAL "23659" , VAL "2"

 

FOR X = 0 TO 64 : PRINT " TEST " : NEXT X ... FOR X = NOT PI TO VAL "64" : PRINT " TEST " : NEXT X

 

GOTO 50 ... GOTO VAL "50" ...or... GOTO CODE "2" (use CHR$ value to figure this out, CHR$50 = Ascii "2") , obviously only works with some values but it can be a bit of a saver sometimes.

 

 

Variables seem a fraction faster in upper case, although I've yet to figure out why.

 

There are also some good ways of saving having to type border/paper/ink/bright/over/inverse/flash if you want to simply set the screen colours, it can be done in one or two pokes.

 

EDIT... Added a splash of colour. I'm happy to check out any bit of Basic (or part of) if you wanted me to suggest any 'space saving' , can always PM it or perhaps just copy/paste it rather than attach a tape file, either here or a PM if you only wanted a 'partial' thing.

 

Obviously you lose readability the more you do this and it can be annoying to try to debug issues too, but it does save quite a bit of space potentially. Try saving a tiny bit of Basic (then see how big it is) then save it again once you've 'adjusted' it. CLEAR recommended before save too.

Edited October 2, 2017 by Spider

[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

[IRF]

Thanks Norman. That one reared its head during the development of a couple of projects we worked on.

 

I came up with a simple workaround by using AND #38 at #8AFC, which helped Daniel Gromann to fix the problem in the SE of his game 'Willy's New Mansion'. (My fix has the disadvantage that it stops the likes of the cross in First Landing from flashing whilst the game is paused.)

 

Then Richard Dymond (SkoolKid) came up with the same solution as you (AND/ADD/AND). I used that method in 'Jet Set Mini' (to fix a problem with the flashing letters on the Title Screen), and I think Mickey has fixed it in that way in his project here?

Edited October 6, 2017 by IRF