Metalmickey Posted December 5, 2016 Report Share Posted December 5, 2016 (edited) 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 December 5, 2016 by Metalmickey Spider 1 Quote Link to comment Share on other sites More sharing options...
Spider Posted December 8, 2016 Author Report Share Posted December 8, 2016 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 1 Quote Link to comment Share on other sites More sharing options...
Metalmickey Posted January 1, 2017 Report Share Posted January 1, 2017 (edited) 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 September 18, 2017 by Metalmickey jetsetdanny and IRF 2 Quote Link to comment Share on other sites More sharing options...
IRF Posted January 2, 2017 Report Share Posted January 2, 2017 (edited) 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 January 2, 2017 by IRF jetsetdanny 1 Quote Link to comment Share on other sites More sharing options...
Metalmickey Posted January 2, 2017 Report Share Posted January 2, 2017 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?? Quote Link to comment Share on other sites More sharing options...
IRF Posted January 2, 2017 Report Share Posted January 2, 2017 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? Quote Link to comment Share on other sites More sharing options...
Spider Posted January 2, 2017 Author Report Share Posted January 2, 2017 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. Quote Link to comment Share on other sites More sharing options...
Metalmickey Posted January 2, 2017 Report Share Posted January 2, 2017 (edited) ****** 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 January 3, 2017 by Metalmickey IRF and jetsetdanny 2 Quote Link to comment Share on other sites More sharing options...
Metalmickey Posted January 3, 2017 Report Share Posted January 3, 2017 (edited) 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 January 3, 2017 by Metalmickey Quote Link to comment Share on other sites More sharing options...
IRF Posted January 3, 2017 Report Share Posted January 3, 2017 (edited) 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 January 3, 2017 by IRF Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.