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

[Spider]

If I get any free time this weekend ( ! ) I'll try to take a look at the am/pm issue for you.

[IRF]

I guess since this is the only room where this happens and patching the bug would bring no benefit to any other room in the game i think i would need to question as to whether it's worth spending any significant amount of time worrying about it although i might just put it in since you've gone to the trouble of creating a patch  :)

 

As I said before, SkoolKid's patch is better than the one I came up with, but he only provides POKES in decimal.  I tend to think it's easier to understand how they operate in hexadecimal (although emulators such as SPIN don't allow you to enter POKES in hex, which is a pain).

 

To give you a hand, I've converted SkoolKid's POKES for this into hexadecimal, and I've also made the address for the 'remote' part of the patch more generic, so that you can slot it in wherever you know there's a space (only 6 contiguous bytes in this case) in the code.

 

#9634 Yy

#9635 Xy

 

That the operand of the conditional Jump command at #9633 (written in the usual 'Little-endian' format).

 

Then at the jump address #XxYy write:

 

CB 4C

CA B6 90

C9

 

(Assuming you decide you want to fix the bug after all!)

[IRF]

Of course the holy grail here is the patch for the am/pm bug

 

I'm happy to report that I've cracked this particular nut!  And I'm especially pleased with the method that I came up with to switch between am and pm, and back again (rather cunning, if I do say so myself!).

 

Please see the attached file.  For demonstration purposes, I've NOPped out the byte at #8A51 (previous value was #59), so that the clock is updated every time-frame (every 'tick' of the game's internal clock), rather than every 256 'ticks'.  If you load up the file, you'll see the clock racing through the numbers!  Obviously, that address should retain its proper value in a normal game file.

 

The substantial changes are at #8A81-#8A96, and at #9700-#9708 and #9710-#971E.  Mickey, you may have to find alternative locations for the stuff in the #97XX range if you've already used them for other purposes.

 

By the way, my initial attempt didn't include the extra code at #9710-#971E (which replicates #8A31-#8A3C).  When I ran the program to test it, everything worked fine at noon, and the game terminated at the right time (progressing to 'Game Over' as it should, not the Title Screen).

 

However, the clock display didn't update to '12:00am' (midnight) when the 'Game Over' screen kicked in.  I managed to fix that as well though.  I realised that, even though the value of the digital clock is updated internally before the jump to #8C4A, the Main Loop prints the digital clock display onto the screen before the digital clock is updated.  Thus I had to replicate the 'Print the current time' commands just before the jump to Game Over.  (There may be a more efficient way of doing this by inserting the 'Print the current time' code into a sub-routine, but it's probably more trouble than it's worth unless you've got a critical shortage of spare addresses.)

am to pm fixed.z80

Edited January 15, 2017 by IRF

[Spider]

There's space for the routine either in where they keypad routines lived or their codes, or if you'd rather leave these present (but unused) you can substantially shorten the startup code at 33792 which will release a few bytes although if it will be enough I've not checked.

 

The startup routine as default takes about 31 bytes (33792 to 33823) but it can be removed and replaced with just 7 bytes, and these could actually go elsewhere but that would then potentially cause issues if someone did not know where to USR to start the code.

 

Summary:

 

Original:

33792     DI ; Turn off interrupts

33793     LD HL,23551
33796     LD (HL),134
33798     DEC HL
33799     LD (HL),159 ; 34463 is now set as (134*256)+159 = 34463

33801     LD SP,23550 ; Set the stack pointer

33804     SUB A ; This bit is (imo) meant to cause confusion on purpose, but the end result is HL 34048
33805     LD L,A
33806     XOR 10
33808     LD B,A
33809     INC B
33810     LD H,B
33811     RRC H

33813     LD C,(HL) ; Redundant code (as per Richards disassembly) 
33814     LD A,L ; Speculation was it would of originally perhaps decoded the game code if it
33815     XOR C ; ever was encoded originally. Currently it does nothing
33816     XOR H
33817     LD (HL),C
33818     INC HL
33819     BIT 7,H
33821     JR NZ,33813

33823     RET ; when we get down here and hit this "return" we are now taken to 34463 (keypad entry) as that's whats been dropped onto the stack (see 33793 to 33800)

 

Replacement:

33792     DI ; Turn off interrupts

33793     LD SP,23550 ; Set the stack pointer

33796     JP 34762 ; Jump to the title screen

33799 to 33823 are now empty / free

That's it. It can be done with just those few bytes.

 

POKE 33792,243 (DI)

POKE 33793,49 : POKE 33794,254 : POKE 33795,91 (LD SP 23550)

POKE 33796,195 : POKE 33797,202 : POKE 33798,135 (JP 34762)

[Spider]

Actually once you've done that (if you do!) then aside from 'saving' the 24 bytes above the following would occur:

 

34463 to 34761 is free as this contained the keypad handling routines. 298 bytes free and available

39680 to 39999 is free as this contained the keypad 'graphics' and the its screen attributes. 319 bytes free and available

40448 to 40959 is free as this contained the keypad codes themselves. 511 bytes free and available

 

I do have a build with these already done (and NOP'ed) out but no other changes so the unused routines such as the 'flash' are still present.

 

There's a potential space available by removing the messages text for these dead routines too but its only 63 bytes (34187 to 34250)

[Metalmickey]

I'm happy to report that I've cracked this particular nut!  And I'm especially pleased with the method that I came up with to switch between am and pm, and back again (rather cunning, if I do say so myself!).

 

Please see the attached file.  For demonstration purposes, I've NOPped out the byte at #8A51 (previous value was #59), so that the clock is updated every time-frame (every 'tick' of the game's internal clock), rather than every 256 'ticks'.  If you load up the file, you'll see the clock racing through the numbers!  Obviously, that address should retain its proper value in a normal game file.

 

The substantial changes are at #8A81-#8A96, and at #9700-#9708 and #9710-#971E.  Mickey, you may have to find alternative locations for the stuff in the #97XX range if you've already used them for other purposes.

 

By the way, my initial attempt didn't include the extra code at #9710-#971E (which replicates #8A31-#8A3C).  When I ran the program to test it, everything worked fine at noon, and the game terminated at the right time (progressing to 'Game Over' as it should, not the Title Screen).

 

However, the clock display didn't update to '12:00am' (midnight) when the 'Game Over' screen kicked in.  I managed to fix that as well though.  I realised that, even though the value of the digital clock is updated internally before the jump to #8C4A, the Main Loop prints the digital clock display onto the screen before the digital clock is updated.  Thus I had to replicate the 'Print the current time' commands just before the jump to Game Over.  (There may be a more efficient way of doing this by inserting the 'Print the current time' code into a sub-routine, but it's probably more trouble than it's worth unless you've got a critical shortage of spare addresses.)

Thanks for this Ian, this should be the last major bug corrected .. i've now figured out how to create a slightly alternative ending (similar to Willy on a barrel) so this will come in handy

[IRF]

Have you ticked off all the entries on this list:?

 

http://skoolkid.github.io/jetsetwilly/reference/bugs.html

[Metalmickey]

Some really helpful stuff here guys, hoping to release my file for playtesting this week. I'm toying with one final issue: 

 

Some might say since i am to make the game truly as Matt intended then i ought to leave the code entry screen in as this was an intended feature of the game but of course nowadays it's pretty pointless .. i'm tempted to leave it in but just make the game run regardless of whether a correct code was entered, i've got my own fix in for that already!  :P

 

With reference to the short delay immediately after loading i think it's well worth implementing the fix here as i figured that if he looked into this and realised that it served no purpose then he would have just bypassed it anyway

[IRF]

You may as well insert the POKE that fixes the 'invalid grid location', even if you've hacked the code entry routine so that any code will do. It's only one POKE:

 

http://skoolkid.github.io/jetsetwilly/reference/bugs.html#invalidGridLocation

[Metalmickey]

Have you ticked off all the entries on this list:?

 

http://skoolkid.github.io/jetsetwilly/reference/bugs.html

pretty much, just the one which i'm not going to bother with and that's the one where grid location R9 is never asked for (poor R9 .. 33 years and never being asked) :(