Free space and code optimisation in "JSW"

[Metalmickey]

just something a little off-topic here, correct me if i am wrong but from what i can make out the original JSW occupies precisely 32K of system memory. Could other areas of RAM be used for routines for the purpose of say for example additional rooms or routines that might somehow further optomise the game somehow?

[Spider]

just something a little off-topic here, correct me if i am wrong but from what i can make out the original JSW occupies precisely 32K of system memory. Could other areas of RAM be used for routines for the purpose of say for example additional rooms or routines that might somehow further optomise the game somehow?

The lower memory area (below 32767) is used during the game for various variables and storage such as the screen buffer and various counters.

 

You can save a complete JSW by doing 33088,65536-33088 as the needed code for starting afresh starts at 33088***

 

*** It will go higher but there is a much needed 255 byte at 33088 in JSW. Alternatives are to insert that after but you only really 'gain' a few bytes shaved off the loader block. The issue with this is JSWED can be confused by a block shorter than 32768 bytes however. 'Released' games I do tend to just save "what is in use" though rather than the whole lot.

 

You can easily gain space however, if you exclude the last few 'dead' rooms and the ] room, you have the following easy to use spaces, depending on preferences. I realise there are more :) but these are easy to use (you may of seen these recently mentioned elsewhere)

 

1. If willing to completely remove the keypad entry (and edit the startup routine to just those three instructions posted a few pages back) then the entire code from 34463 to 34761 is 'available' , these are the three keypad routines themselves

 

2. Same as (1) if willing to do that then you can also release 39680 to 39999, this contained the keypad graphics and the attributes for that screen.

 

3. Again (sorry) if doing 1+2 you can then release 40448 to 40959 as this contains the codes and finally the keypad messages which free's up 34187 to 34250

 

 

Other spaces:

 

38622 to 38911

 

39936 to 39999

 

40627 to 40959

 

42624 to 43775

 

:)

[Metalmickey]

not including the unused TR DOS code which should have contained room data there's 2035 bytes of unused space plus redundant code ie keycode entry routine and codes etc.. how feasible would it be to move the 2  buffers at 23552 and 24064 which, from what i can work out are 256 bytes each into some of this spare space?

[IRF]

How would that free up space?  You'd still need to have those buffers somewhere, so you'd just be 'robbing Peter to pay Paul' wouldn't you?  :wacko:

[Metalmickey]

it's an eggs and omelettes thing, i'm thinking that it might be useful somehow as part of a bigger plan, the overall memory 'footprint' would be reduced, granted this in itself would not free up any memory but by having a single large chunk of bytes at one end of the system memory would in turn surely make it easier to shift code about, i'm thinking about all of the alterations that i made which involved a fair few CALL instructions which of course need their corresponding RET, each pair taking up 4 bytes (correct me if i am wrong).. hell i'm just an amateur at this game .. apologies if i'm talking garbage here but it's just my meandering thoughts...  :blink:

Edited April 17, 2017 by Metalmickey

[IRF]

The buffers are located in 'contended memory' (everything from #4000 to #7FFF, from what I gather).  I'm not sure what the implications are of that - Andy may be able to elaborate further? - but I believe that you shouldn't put things such as routines or data bytes within that range.  Hence the buffers are located there (#5C00-#7FFF), I think?

[Spider]

You can use contended memory for storage as long as its not time critical. :) It just means those memory 'read/write' have to "wait their turn" as the ULA will have priority over the processor.

 

This mainly why things like high-speed loaders and screen 'effects' (special effects not LDIR'ing colour changes etc) usually live at an address > 32767

 

This is why things like the 'main loop' are not in contended memory. But you could use it for anything else really like object counters or routines. It may be worth trying the effects of it at

 

Random note: Spin allows you to disable this, if 'testing' ensure its enabled so it behaves like a real machine. Tools > Options > Hardware > Emulation > 'Memory Contention' , I do not see this option in Spectaculator but I did not search too closely.

 

The effects can differ I think between a 48K (or 16K!) machine and one of the 128's too, but I'm not 100% sure on this fact.

[IRF]

If the two chunks of code, that print the current time (#8A31-#8A3C) and the number of items (#8A3D-#8A48) respectively, are swapped around, then IX will only need to be defined once at this point in the Main Loop (saving four bytes).  Also, D will only have to be defined once for both functions, and so the second instance of LD DE, #0000 can be replaced with a LD E, #00 (saving another single byte).

 

(N.B. The above efficiency would mean that if a game file has the 'Print the Time' code placed after the 'Update the Time' code - as is the case in Willy's New Mansion SE in order to make sure that the clock's colour is changed at precisely the right moment - then it would also need to have the 'Print the Number of Items Collected' code placed after the 'Update the Clock' code.)

[IRF]

I can't see any real reason why the 'Print the Remaining Lives' code in JSW is placed in a subroutine, and then CALLed from the start of the Main Loop. In Manic Miner, it forms the initial part of the Main Loop. Ditto with JSW Geoff Mode.

 

If you remove the JP at #8988, the RET at #89AC and the CALL at #89AD, and then replace the RET Z at #8992 with a JR Z to the start of the rest of the Main Loop at #89B0, then you can achieve a net saving of six bytes. (Or five bytes if you've already implemented the one-byte optimisation of replacing the JP at #8988 with a JR.)

[Spider]

Mentioning lives although this is slightly different (but I was thinking about something else earlier) what would the potential saving likely be if the 'draw the lives and / or animate them if the tune is playing' section was completely chopped out and replaced with a simple "Lives: X" numerical counter :unsure: