Free space and code optimisation in "JSW"

[Spider]

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. :)

 

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

 

To expand on this a bit, this is 'compressed' Manic Miner (Software Projects version simply as I had that to hand) no cheats or anything else applied:

 

 

Tape Structure:

 

Basic:

 

Notes:

 

10 Setup colours etc

20 Load the pic code. This is not a direct attribute load its a code file that will LDIR (move) the blocks into the correct place. Its a bit smaller that fully screen (768) or the middle (256) bytes. This also means it instantly appears rather than being 'drawn'

30 Call that 'code' to display the loading pic

40 Load the compressed game code

50 Call the game code at a certain place to uncompress (expand) it to where it should be and its proper size

60 Obvious :)

70 Call the game

 

I thought about a high baud rate to reduce it a lot (say 3500 compared to 1500) but that would be a step too far maybe.

 

Anyway the game code is now 15KB in size instead of 32KB , a substantial loading time saving.

[Spider]

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

I wanted to expand (no pun intended!) on this for you once I had a bit of time to do 'something' ;)

 

With a new turboloader and compression, I've achieved the following using the standard Software Projects release of Manic Miner. Some quick specs:

 

Standard MM:

Total Loading Time: 3 min 9 seconds

Tape length: 3 min 35 sec

 

Compressed + Turboload MM:

Total Loading Time: 0 min 56 sec

Tape Length: 0 min 58 sec

 

Yes, under a minute all in.  :D  It can go higher but this (4500 baud) is about the top limit for a 'real' tape and you'd need a decent one to do this I think.

 

Manic Miner Compressed Fast Load.tzx

 

Basic Loader:

 

 

10,20,30,40 : Just some basic (no pun intended) details

50 : Black screen and set Ramtop (CLEAR)

60 : Load the 'pic and loader' code in at 65102 and its 435 bytes in total. Call it (651E2 = 65100)

70,80,90 : Put your pokes if required here

100 : Tiny pause then start the game

 

 

Here is the actual 'pic data' , as you can see its about the minimal number of blocks I could save to get it to work. Note its not animated in this so the starting and ending of the letters is the start/end:

 

 

 

Tape structure:

 

 

 

Details of the 'combi' screen and loader:

 

 

65102 starts here:

 

LD HL, 65122         ;    Setup to move 219 bytes from 65122 to 22818

LD DE, 22818         ;    22818 is most of the middle screen attributes

LD BC, 219         ;    to 'draw' the loading graphic blocks

LDIR             ;    Move them!

NOP             ;    Do nothing

CALL 65343         ;    Call the loader

RET             ;    Drop back out to Basic

 

** The 'code' between these two is not really 'code' as such it is actually just data: The 'graphic blocks' to move **

 

 

65343 (almost as there's a half a dozen bytes before this but they are not relevant to this)

 

LD IX, 32768         ;    Tell the turboloader that we are loading at 32768

LD DE, 16296         ;    and its an expected length of 16296 bytes long

CALL 65359         ;    Call the turboloader now, when its finished it returns here (CALL = GOSUB)

JP 32768         ;    Call the uncompressor

 

** The 'code' following this is the turbo loader itself ** No point posting that.

 

Without calling the uncompressor, we'd return to Basic with the 'compressed' code still (32768,16296) which would not be too helpful to use, so it makes sense to 'uncompress' it before returning.

 

We could go a stage further and change the RET at 65117 to JP 33792 to 'call' the game code which would mean there was never a return to Basic but the idea of this is not to attempt any form of protection it is merely a fast load of a compressed block.

 

Doing this though there is a little risk of the code being 'uncompressed' over itself (when it was looking for the next instruction after calling the decompressor code) which could result in a crash. There are easy ways around this should it be needded though.  The quick and easy way is to simply stick those few 'call the decompressor' bytes into the screen out of the way and run it from there.

[jetsetdanny]

Congratulations on bringing the loading time down to under one minute, Andy  :) . That's quite an achievement!

[Spider]

Congratulations on bringing the loading time down to under one minute, Andy  :) . That's quite an achievement!

 

:) Thank you.

[Metalmickey]

Apologies if i am missing something but the nagging question that keeps prevailing here is how does JSW2 manage to run?

 

Correct me if i am wrong but my understanding is that it was originally written for a 64K machine, then compressed so it could be shoehorned into a 48k Speccy yet the speccy seems quite happy not only to run it in it's compressed state but also to function with very few (if any) bugs 

 

 It seems from what you're saying with JSW1 that you take the code, compress it to make it smaller but to make it run it has to be decompressed

 

My original question about compressing the code was with the intention that we could have JSW1 playable in a compressed state so that a few more features could be added, the point of this being that if needed to be edited then it would just be a matter of decompressing it to edit, making the changes then re-compressing it when finished

 

I guess if i was to answer my own question i would say that the entire code would have to be completely rewritten to make this possible thus defeating the idea of editing the original code.

 

Thoughts?

[Spider]

In a nutshell, your last main sentence was correct, it would need rewriting to do this. :)

 

The compression I use simply compresses it as much as possible.

 

To do what you're asking you'd need the decompressor present all the time (not a problem) then 'uncompress' bits of code into say a designated area of memory. When a 'new' bit was required you'd simply decompress some other part into this 'designated area' :)

[Dasse]

Great work! :D

[IRF]

Two bytes (#8EB4-5) can be freed up in the 'Move Willy(1)' routine by inserting a relative jump forward by four bytes at #8EB2 (destination #8EB8).

 

Replace four bytes at #8D67-8D6A with three bytes:

RET Z

JR #8D4D

EDIT: That's no more efficient in terms of total bytes used than replacing the absolute JP with a relative JR (an alternative which doesn't require the RET to be moved).

 

Replace the LD A, (HL) at #943E with LD A, D and then NOP out #943F (frees up one byte).

(Credit goes to J G Harston for that one.)

Edited May 8, 2017 by IRF

[IRF]

There's a two-byte CP #00 at #8FE2, where a one-byte OR A command would achieve the same thing.  (I can't believe we haven't spotted that one before, or have we?)

Edited January 30, 2017 by IRF

[jetsetdanny]

Well spotted, Ian!

 

It hasn't been optimised in "WNM SE". Having said that, there was no need for it, because a one-byte saving in that particular location in the code wouldn't have been too useful anyway.