Free space and code optimisation in "JSW"

[IRF]

I'm probably missing the point here but why not just compress the entire code? I know people here are not a big fan of compression as it makes the code harder to read like with JSW2 for example but is that not because there is no decompressor available making editing a lot harder?

 

but what if you was the one doing all the compressing? might it be easier to edit the code then compress and decompress at will .. imagine the extra rooms and nasties you could cram in using the original JSW engine...

 

just a thought that's all

I suppose that's one option.

 

However, I've considered it a nice challenge to find 'efficiencies' in the existing code and therefore try and pack as much into the available space as possible, without compression.

 

And if nothing else, taking on the task has helped me get my head around how the Z80 machine code works. (I was clueless just a few months ago!!) :wacko:

Edited August 4, 2016 by IRF

[Spider]

The issue with compression is when its unpacked it takes the same size as the original did, unless I'm missing something ? :)

 

I can compress JSW down to about 18K in some cases ( ! ) but it won't run in that state. :D

[IRF]

If the instruction at #8985 (setting the Rope Status Indicator to 0) was relocated to immediately before #894A, then it would benefit from A having been decremented to zero in the preceding loop, and therefore the single-byte XOR A command at #8984 would become unnecessary and could be recycled.

[Metalmickey]

The issue with compression is when its unpacked it takes the same size as the original did, unless I'm missing something ? :)

 

but the end user wouldn't need to unpack it, JSW 2 seems relatively bug-free running in it's compressed state ... when developing it you could just save it in stages or just emulate bigger memory ... if that's in any way possible.

 

 

[Metalmickey]

 

I can compress JSW down to about 18K in some cases ( ! ) but it won't run in that state. :D

Any idea why? 

Edited August 7, 2016 by Metalmickey

[Metalmickey]

I suppose that's one option.

 

However, I've considered it a nice challenge to find 'efficiencies' in the existing code and therefore try and pack as much into the available space as possible, without compression.

 

And if nothing else, taking on the task has helped me get my head around how the Z80 machine code works. (I was clueless just a few months ago!!) :wacko:

Yes i'm trying to learn assembly language but my aging brain isn't quite able to take it in, i need to see if i can find something on YouTube or somewhere as i can't learn from reading books, i can see your point about making the existing code more efficient, from the info here it would seem that Matty really had to rush the game through .. i've always wondered what those missing 4 rooms would have looked like and where they would have been

[Spider]

but the end user wouldn't need to unpack it, JSW 2 seems relatively bug-free running in it's compressed state ... when developing it you could just save it in stages or just emulate bigger memory ... if that's in any way possible.

 

Well I guess that's true. But you'd need some kind of 'on the fly' decompression to 'test' it as you'd not really be able to reliably edit a compressed file. Think of this as trying to edit say a .zip file "directly" with a hex editor. At least that's how I see it, I could be completely wrong. :)

 

Any idea why? 

 

This saves quite a bit of loading time on a 'real' machine or emulated for 'tape emulation freaks' (such as me!)

 

Yes i'm trying to learn assembly language but my aging brain isn't quite able to take it in, i need to see if i can find something on YouTube or somewhere as i can't learn from reading books, i can see your point about making the existing code more efficient, from the info here it would seem that Matty really had to rush the game through .. i've always wondered what those missing 4 rooms would have looked like and where they would have been

 

From various bits of research ( ! ) they were going to be part of the MegaTree. There was something he said once (well, so I read) along the lines of the fact the tree was meant to be a lot bigger, so I'd assume that is where at least two if not more of them would of been.

[Metalmickey]

any idea why when compressed down to 18K you couldn't get it to work?

[IRF]

I thought I'd copy the following two suggestions here (from a PM) for the 'wider readership'.  (And rather cunning they are too, if I do say so myself!):

 

The program will only reach #88A3 if the A register is set to zero (because it is immediately preceded by a JR NZ command).  Therefore A can be set to a value of 1 (in order to feed that value into the Kempston Joystick Indicator) by replacing the LD A, $01 command with an INC A, saving one byte.

 

And:

 

1 byte can be achieved as follows:

Replace the XOR A command at #88B1 with a LD A, $20, and to compensate, alter #88C8 from LD IX, $8454 to LD IX, $8434.  Those two changes cancel each other out, so that the temporary variable (#85E4) which keeps track of where the scrolling message is up to, starts off pointing at #8454.

 

"But wait a minute," you may be thinking, "doesn't that require one extra byte, rather than save a byte?"  Well, here's the cunning bit!...

You now want the scrolling message counter to stop when #85E4 is incremented to zero, rather than to a value of $E0.  So you can delete the two bytes at #88F2-88F3 ('CP $E0'), and the message will end at exactly the same point as it did before (when the JR NZ at #88F7 stops being triggered), but you get a net saving of one byte!

Edited August 10, 2016 by IRF

[Spider]

any idea why when compressed down to 18K you couldn't get it to work?

This is JSW1. It does work. But you have to uncompress it before running the code. The compression in this case is just to reduce the 'saved' file size down. :)