Jsw2 Loader Differences

[Spider]

There are three official releases of JSW2. I'm not counting the 'JSW2-128' version here as far as I'm aware this was not in any way 'official' as it incorporates a built in cheat mode. Feedback on this point is appreciated. To quote the readme:

With that said the official versions are:
 
1. The Software Projects release
2. The DroSoft Re-Release
3. The Ricochet Re-Release
 
The loading screen is the same for all versions so one pic will suffice:
 

 
Software Projects
 
This is the only release that has some protection on it. A small piece of basic containing assembly to headerless load the game code (47416 bytes) and the keypad routine as per JSW1 albeit this one has seven pages instead of one.
 

 


To make life easier for myself after examining the basic itself I then decided to simply use a fake header to load the 'basic' at a higher address, and then examined the loader section, ie all code after the section of
My understanding of Z80 is not good (to say the least) so any thoughts / suggestions on my comments to the code are appreciated along with any errors I've made. :)
 
The code is thus and starts at 23832

org 23832    ; Loader code appears to start here, seen by using a fake header on the basic.

di        ; Kill interrupts.

xor a        ; Ensure that A is going to be black.
out (254), a    ; Set the border to A aka black.
ld hl, 22528    ; Setup the requirements for an LDIR so that we can blackout the screen with
ld de, 22529    ; black paper and ink. We actually seem to be copying the contents of 22528 into
ld bc, 800    ; 22529 to 23329 (800 bytes) which extends into the basic and variables area a
ld (hl), a    ; little bit. Assume this was done to prevent easy tampering with the loader itself.

ldir        ; Do it!

ld sp, 63796    ; Put stack pointer somewhere up top.

dec a        ; Decrease A before we swap them (protection maybe?)

scf        ; Set carry flag before calling loader.    
ex af, af'    ; Swap reg contents.
ld ix, 16384    ; Start address of data to load.
ld de, 47416    ; Length of the data to load.

call 1378    ; Call the rom loader so we can load in this big headerless block.

jp nc, 0    ; Reset on error or tampering ?
jp 36864    ; Exec the game code :)

 
 
Drosoft and Ricochet These are identical loading-wise so I'm counting them together as one. The keypad routine is not called.
 
The loader is unprotected apart from an attribute change to 'hide' the master saver routine, shown 'as is' when first listed and 'exposed'
 

 

 
The game code is loaded at 25007 and appears to be 40528 bytes in length. After that 2kb piece of code loads to 18432 then the game is started with a call to 20140. I expect this is to simply bypass the keypad routine. Turns out (thanks Jon Elliott) that it appears to be a snapshot loader so we'd guess then that the 'snapshot' was simply taken after the keypad code was accepted.
 

[leespoons]

I only ever had JSW2 on the 6-Pak compilation - it's distribution denied so I can't check, but I'm pretty sure it had the Software Projects headerless loader but without the keypad protection, it just jumps straight to the game.

[Spider]

I only ever had JSW2 on the 6-Pak compilation - it's distribution denied so I can't check, but I'm pretty sure it had the Software Projects headerless loader but without the keypad protection, it just jumps straight to the game.

 

You must have a slightly different one then. :) I can't check that obviously I expect its denied because of the inclusion of '1942' in the compilation. Shame we can't get a .tzx minus that but with the rest of the compo.

 

It sounds like the original (I did have this once upon a time) but with keypad check awol then, another variant.

[leespoons]

Well I just found a tzx of 6-Pak on a dark corner of the intertubes and it's the same standard loader as the Ricochet re-release, so perhaps I just remembered it wrong...

[Spider]

Well I just found a tzx of 6-Pak on a dark corner of the intertubes and it's the same standard loader as the Ricochet re-release, so perhaps I just remembered it wrong...

 

I guess. :)

[aerworuld]

i always liked the loader from the  Acorn Electron version by Tynesoft:

 

 

hope i've done that right, this is my first post ;-)

[Spider]

That's fine (thanks for uploading as we know it will 'stay' now unless you decided to remove it) rather than linking it. :)

 

I do have the variations of the B version to hand and they are on my 'todo' list, as there's a variation with the tape/disk versions of JSW2 iirc. The disk version is about the same (loads sections as you play) the tape version is a cut down one I seem to recall.

 

I'd not thought a great deal about the Electron version although I do have it floating somewhere ( I'm on the stardot /stairway forums too btw as AndyF )

 

Unless you wanted to do the Electron version and / or just the loaders ? :)

 

EDIT... Forgot my manners :blush: Welcome!

[Norman Sword]

One observation from the loader routine. The stack is situated at 63796: the program loads from 16384 (#4000) and loads in 47416 bytes.  This means all data in memory from 16384 to 63800 is overwritten....This has two consequences..

 

1) the code you are reading is overwritten by the loader. Thus the lines

  

 jp nc, 0    
 jp 36864  

 

will not exist when the program is loaded 

 

2) the return address from the loader is pushed onto the stack. The stack is overwritten so after the program has loaded, it will not return to the routine that called it. The return address is written by the code that is loaded.

 

The above proved enough protection, that further duplication (MASTER TAPE) resorted to a snapshot loader

Edited March 29, 2017 by Norman Sword

[Spider]

That does make sense, thank you Norman. :)

 

My knowledge has improved a bit since I initially wrote that, (thankfully!) , the Call would probably work as  JP actually (to the loader) given its got "never to return" as such. I have seen this in other loading schemes were there's no CALL just a JP which made me think.

 

Inserting a b.p at either the end of the memory or using Zero (which allows decent b.p's for things like memory read/write) would be possible to insert one into the rom loader so when it finished it would stop at the RET point and you could examine the SP and other data to see what was really going on.

 

I do agree I see why the re-releases were snaps though as such. The same with my 'immunity' as the codeblock was compressed a bit so I could directly alter the bytes I needed. The exception being the 'any key keypad' as that part thankfully was intact when I searched the tape file binary directly for sequences of bytes.