80 replies to this topic

[Metalmickey]

Not tried them out on Spin yet, I'm using spectaculator for the moment just to apply the POK file to the game, yes i have found it to be a tad finicky, when loading the POK file it comes up with the cheat menu straight away but if you tick a box then close it and reopen it the tick disappears leaving you trying to remember which ones you ticked. My ultimate aim, inspired by the 2015 Bugfix Version, is to apply all of the changes necessary to eliminate  every known and highly suspected bug and create a 'As manufacturer intended' version, of course this is going to be something of a challenge when it comes to the missing rooms as we'll probably never really know for certain where the original rooms would be or what they would have looked like but other things like the end of time sequence, guardians facing the wrong way, pause bug in IF1 etc would all be corrected.

 

Feel free to move this to another thread if i'm digressing from the original subject by the way

Edited by Metalmickey, 05 December 2016 - 10:19 PM.

[Spider]

Yes it can be a bit odd. In theory the second large value in the pok file is the original value (if its unchecked apply that one, if its checked apply the first one) but it does not work properly unfortunately.

 

This is partly why my "walk through walls" JSW pok (let me know if you want it if its not within easy finding) works fine in Spectaculator but not in Spin. A closer look at the memory after applying shows in Spin it actually only applies the first of the list and ignores the rest. Its not the list size its the fact that the 'new value' is zero and it does not like that as a repeated pattern I guess.

 

I will probably split a few posts off this later to a new topic to keep this original one tidy yes.

[Metalmickey]

 

Leaving single POKE mode for a moment, here's my first attempt at fixing the bug that misdraws the conveyors in West of Kitchen, The Nightmare Room, The Wine Cellar, and Tool Shed:

 

POKE 36178,151

POKE 36181,9

POKE 36183,205

POKE 36184,38

POKE 36185,255

POKE 65318,9

POKE 65319,190

POKE 65322,75

POKE 65323,35

POKE 65324,201

 

That's ten (10!) POKEs in total, which is a disgustingly large amount. Does anyone know of a smaller set of POKEs that achieve the same result?

 

I recently discovered that when using these POKEs you may run into difficulties if you decide to edit the game to add more rooms. The last 5 POKEs here alter addresses in the final 256 bytes of memory where one of the rooms would have been before it became overwritten with the TRDOS code. I have an alternative solution, feel free to remove this if it's already been covered elsewhere..

 

The first three 

 

POKE 36178,151
POKE 36181,9
POKE 36183,205

 

can be left as is

 

but if we change the CALL instruction so it points to another unused area and use these POKEs instead

 

POKE 36184 145
POKE 36185 166

 

and add these 

 

POKE 42640,220
POKE 42641,9
POKE 42642,190
POKE 42643,32
POKE 42644,252
POKE 42645,75
POKE 42646,35
POKE 42647 201

 

as far as i have tested it seems to work well even when all 64 rooms have been fully built

 

I'm still learning but i think it works ok 

Edited by Metalmickey, 18 September 2017 - 10:16 AM.

[IRF]

I think you could do without this one (it doesn't appear to do anything; the destination of the earlier jump is 42641):

POKE 42640,220

 

Which would take it down to 12 POKES in total.

 

The reason SkoolKid was able to bring the number down to 10 POKES, is because he made use of an existing relative jump within the remnant TRDOS code, which happened to have the same destination (three bytes backwards) as the one that you've used above.

 

 

******

 

Also note that Stuart Brady (Zub)'s Cell Graphics Bug POKES achieve the same thing. i.e. they fix the same bug - which happens to only affect conveyors in original JSW, but the bug can in theory affect most cell types, so whilst Stuart's fix uses a greater number of POKES, his description: 'Cell Graphics Bug' is more generic and more informative than SkoolKid's: 'Corrupted Conveyors'.

 

Furthermore, the two bug fix methodologies are slightly different.  Mickey, I believe that you might have run into additional trouble in your 'As Manufacturer Intended...' project, by trying to implement both bug fixes at the same time?  (Perhaps because you hadn't appreciated the fact that the two were designed to fix the same problem.)  If that was the case, then one set of POKES (which work in the same area of the code) may have ended up partially overwriting the other - causing a crash!!

Edited by IRF, 02 January 2017 - 12:49 AM.

[Metalmickey]

I think you could do without this one (it doesn't appear to do anything; the destination of the earlier jump is 42641):

POKE 42640,220

 

Which would take it down to 12 POKES in total.

 

 

Well that was what i thought, but it appears that it is needed, i spent hours trying to work out why simply moving the routine to another unused address area wasn't working then i opened the debugger at address 65317 ($FF25) and noticed it was another CALL function but i thought it was ignored as the CALL routine points to 65318 but it seems not to be the case

 

originally the instruction here was used to call up a routine that seems to be stored in ROM rather than the game code. Skoolkid changed this to point to some code which resides at $BE09 .. i've no idea what it does but it seems to be essential for the game to function, I'm guessing the RET instruction at $BE27 takes us back to 65320 ($FF20) or 42643 ($A693) if you're using the new routine ... maybe i'm a bit off the mark with all this, i just applied the GOSUB and RETURN logic .. 

 

so when i modified 42640 it just started working...?

 

Could there be some other reason for this??

 

 

 

 

[IRF]

I'm not sure, but #BE09 is mid-way through the guardian graphics data, so I'm not sure what the purpose of Calling that address is?

[Spider]

I'm not sure, but #BE09 is mid-way through the guardian graphics data, so I'm not sure what the purpose of Calling that address is?

What's the code at #BE09 ?

 

Trying to execute what is non 'code' aka graphic data can have very odd effects, it may be safe depending on what instruction it tries to run though.

[Metalmickey]

 

******

 

Also note that Stuart Brady (Zub)'s Cell Graphics Bug POKES achieve the same thing. i.e. they fix the same bug - which happens to only affect conveyors in original JSW, but the bug can in theory affect most cell types, so whilst Stuart's fix uses a greater number of POKES, his description: 'Cell Graphics Bug' is more generic and more informative than SkoolKid's: 'Corrupted Conveyors'.

 

Furthermore, the two bug fix methodologies are slightly different.  Mickey, I believe that you might have run into additional trouble in your 'As Manufacturer Intended...' project, by trying to implement both bug fixes at the same time?  (Perhaps because you hadn't appreciated the fact that the two were designed to fix the same problem.)  If that was the case, then one set of POKES (which work in the same area of the code) may have ended up partially overwriting the other - causing a crash!!

Yes you're absolutely right, that's exactly what i did, whilst i knew exactly what the conveyor POKEs were supposed to do, i didn't have much of an understanding as what was meant by the 'cell graphics bug' but now having studied the game code i have a better understanding as to what went wrong...

Edited by Metalmickey, 03 January 2017 - 12:02 AM.

[Metalmickey]

What's the code at #BE09 ?

 

Trying to execute what is non 'code' aka graphic data can have very odd effects, it may be safe depending on what instruction it tries to run though.

Well now i'm really puzzled .. i applied the original bunch of POKEs and, out of curiosity i POKEd 65317,0 to remove the CALL function. The game works fine, i guess it doesn't use the instructions at $BE09 after all .. i guess that's no surprise to the experts.. just strikes me odd that when I use the alternative addresses it seems to rely on the additional modification of 46240 in order for the game to work properly

 

one day when i've learned a bit more about machine code i'll look back at this with a slap on the forehead and say 'of course'!

Until then, much head scratching to be done...

Edited by Metalmickey, 03 January 2017 - 12:05 AM.

[IRF]

Some thoughts - I hope they are of assistance...

Surely the values #09 and #BE only come into consideration, because they are the Z80 op-codes for two of the instructions that are inserted by SkoolKid's POKES?

Now, if you insert the POKES at the addresses which SkoolKid suggests, it just so happens that they overwrite the operand of an (unused) Call instruction - but I don't think that Call command (at 65317 / #FF25) is ever executed, and I don't believe that #BE09 [bear in mind here that low bytes come before high bytes in 'Little-endian logic'] was ever intended as a destination address!

Edited by IRF, 03 January 2017 - 12:30 AM.