Jump to content


Member Since 11 Apr 2014
Offline Last Active Aug 20 2017 12:19 AM

Topics I've Started

Bug: Wrong Way

17 August 2017 - 12:57 PM

Well you could title it "Wrong way" or "Face the wall" , both seem suitable.


In Ore Refinery, Skylab Landing Bay and The Warehouse Miner Willy is facing the wrong way upon entry to the cavern, specifically in the first two he is facing right when he should be facing left and in the latter he's facing left when he should be facing right. Take a look at the these caverns as they are presented initially:


[attachment=4535:ore_refinery.png.png] [attachment=4536:skylabs.png] [attachment=4537:warehouse.png]


Confused ? Read on.


The fix is quite simple for this. It is the same for the Bug-Byte and Software Projects versions as well as the M.A.D and VentaMatic Re-releases (as these last two are based on the Software Projects version anyway)


Ore Refinery: POKE 57962 , 1  (#E26A , #01) The original value here was 00 (right) . Willy now faces left. (01)

Skylabs: POKE 58986 , 1 (#E66A , #01) Again, the original value here was 00 (right) . Willy now faces left. (01)

Warehouse: POKE 62058 , 0  (#F26A , #00) The original value here was 01 (left) . Willy now faces right. (00)


Now lets take a look at the 'fixed screenshots' of said caverns:


[attachment=4538:ore_refinery_fixed.png] [attachment=4539:skylabs_fixed.png] [attachment=4540:warehouse_fixed.png]


That looks much more as though it was intended. :) The value could be changed a bit to alter the animation frame too, but at least he is now initially facing the correct way...

Text bugs

03 August 2017 - 12:32 PM

Well if you would call them that. :)
First of all let us ignore room names that are not centred properly aka "Halfway up the East Wall" and "A bit of tree" amongst a few others are both too far leftwards. A few are too far rightwards too.
Of room names though:
1. Room 51 / #33 "Tool  Shed" has two spaces between the words instead of one.
2. Room 54 / #36 "West  Wing" has two spaces between the words instead of one.
When I looked again at the keypad 'bright vs not bright' issue (see here if needed) for something unrelated it brought my attention to the code wording itself. Lets take a closer look, ignore the fact the code is showing "--" this is simply so the same one is shown for each screenshot to keep it simple:
"Enter Code at grid location"
"Sorry, try code at location"
Notice "code" is capitalised on the first but not the second. I'm not 100% sure which is grammatically correct though.


Not shown in screenshots however to 'fix' this either way:


POKE 34193 , 99 (#8591#63) to change the "C" in the first message to a lower-case "c" or to go the other way instead POKE 34230 , 67 (#85B6 , #43) to change the "c" in the second message to an upper-case "C"

Also, look at the screenshots here, there is a potential spacing issue too. :) Note that the code entry ID requested has a space between itself and the end of the screen but the text is set to the far left. Either something like a colon needs adding...
[attachment=4517:key1_colon.png] [attachment=4520:key2_colon.png]
To do this: POKE 34214 , 58 (#85A6 , #3A) for the first message and POKE 34246 , 58 (#85C6 , #3A) for the second.
... perhaps a simpler, tidier fix is to just move the text along one character instead to make it sit 'neatly' instead. I think I prefer this method:
[attachment=4518:key1_moved.png] [attachment=4521:key2_moved.png]
To do this: POKE 34500 , 1 (#86C4 , #01)
This changes the LD DE, 18432 to LD DE, 18433 (#4800 to #4801) which the display file address to display the message, in Basic its "PRINT AT 8,0 vs PRINT AT 8,1"
In theory the length specified that follows that: LD C,32 (#20) reducing down to 31 (#1F) to prevent overspill onto the next line however this is not essential as its not 'seen' and the last few characters are blank in the message so you are only printing a blank character (ascii 32 / #20) onto a blank space aka: no effect. The length could be reduced by a few characters even with no other changes as the last character blocks on that line are overwritten by the code specified to input anyway.

Alernative "First Landing" thoughts

02 August 2017 - 03:48 PM

Well kind of...


I was looking earlier, and although the 'official fix' of moving said object to The Hall without a shape is OK it seems the more I think about it, a "quick fix" , as ideally a shape would of been in order too.


Thoughts then turned to simply moving it to the left and up a bit, so its sat at the top of the ramp, this way Willy cannot avoid an 'auto collect' moment no matter which side of Top Landing he falls from into First Landing. This way there's no need to give it a shape either as it won't be 'seen' normally.


I did try this quickly with success although manual pokes to 'DIY' it instead afterwards out of curiosity did not quite work for some reason, but I've not looked into that in any detail.


It would not be that different "in player mode" to the auto collect item in Swimming Pool even though that as we know is caused by the cell colours rather than its position. The collection is transparent (no pun intended!) to the player.


Just seems a little bit easier as this way its not possible to miss it, as can happen if Willy happens to be jumping over the guardian or arrow etc in The Hall and with bad luck he could in theory miss the object completely...



Adding a lift

01 August 2017 - 07:35 PM

I thought about this a while back, to be honest I've not examined every variant to see if it exists or not.


In theory you could use multiple teleporters to do it but if you stop and think how this is done in other platform games (for random examples: Tech Ted, Spellbound, Pyjamarama etc) , its relatively simple:


The 'exit ID' from the lift is simply set to a different level depending on what 'level' is chosen within. The problem here stems from some kind of patch vector to 'select' a floor as such.


There is only every one 'lift' room anyway merely (as above) the exit is set to match a floor level:


Any thoughts on this ? Its only a wild idea...

[File] JSW Keypad Trimmer

26 July 2017 - 04:53 PM

Posted Image


File Name: JSW Keypad Trimmer

File Submitter: Spider

File Submitted: 26 Jul 2017

File Category: Tools and Patches

System: Sinclair
Original Author(s): Andy Ford


A simple Basic program to remove the Keypad data completely from the JSW game code. Load in your game code, load the 'trimmer', run it and save the game code afterwards.


Two versions are provided:


1. The basic keypad only version. This replaces the long pointless startup routine with a much shorter (32 bytes vs 10 bytes) and removes the following:


The keypad messages "Enter code at grid location etc" - 64 bytes starting 34187
The keypad reading/display routines - 156 bytes starting 34463
The keypad graphics and attributes - 255 bytes starting 39680
The codes themselves - 178 bytes starting 40448


Note this does not remove (most) of the 'garbage data' sat in the sprite editing area as its not all stritcly keypad related. For that see (2) below...


2. The slightly extended version. This does not remove any 'unused routines' , it merely expands slightly on the above as some random data is present in the sprite area, this will remove it too. See the screenshot of the before/after for this. It is not recommended to use this one on a third party game before checking said areas have not already been recycled for sprite or other data however it is recommended to use this on a standard game before editing it. To clarify this, as well as the above the following are also emptied:


Source remnant - 64 bytes starting 39936
Data remnant - 333 bytes starting 40627
Data remnant - 1152 bytes starting 42624


Click here to download this file