Resource centre for ZX Spectrum games
using Manic Miner and Jet Set Willy game engines
Archive of the
Manic Miner & Jet Set Willy Yahoo! Group
messages
|
|
|
|
|
Message: 6651
Author: andrewbroad
Date: 24/03/2010
Subject: Re: JSW64 Variant questions
Roger wrote:
>JSWED does not currently support such a mechanism (apart from exporting them as sprites as dm_boozefreek mentioned, which has the drawbacks that the start-addresses and lengths have to be multiples of 32, not all pages can be accessed in Sprites, and you have to remember to reclassify the page in Memory after importing).
> 2 questions about JSWED and 64 variants please.
>
> 1.
> I'm experimenting with patches at the moment and wondered if there
> is any mechanism to save the area of memory containing a patch
> typed in with the hex editor to a file.
> I would like to then be able to import this into a different
> variant, if possible to a different target area of memory. This
> could work exactly like the room import/export function I would
> think. It would save a lot of re-typing in the hex editor!
An alternative would be to load the game in an emulator, save a raw binary file of the exact start-address and length, and load that file at the start-address you require. Then you could save a snapshot in the emulator and load the snapshot into JSWED (personally I'm too fastidious to do it this way, because I mind that it could change the data in the runtime buffers, but it shouldn't corrupt any vital data).
(SPECSAISIE has functions to convert between TAP-files, SNA-files and arbitrary binary files, but TAPtoBinary cannot yet save a specified range of addresses from a TAP-file to a binary file, nor can BinaryToTAP graft a binary-file onto an existing TAP-file at a specified address. These things are on the SPECSAISIE to-do list.)
I document all my patches by writing the hex to a text-file using SPECSAISIE Peek. Since each patch is only a few lines long, I prefer to type them into JSWED from the text-files rather than faffing about with binary files.
> 2.According to the Memory screen in the original JSW64 (all 6 variants), #C600CFFF are free. Looking at them in the hex-editor, they appear to contain room-data from the original 48K JSW, so they should be safe to overwrite.
> I've been using the area starting at #c500 for patches, chosen
> because this is where the clock tower patch was safely put in all
> variants, but with several patches in serial here I have now gone
> beyond #c600.
>
> My question is how much of this area is safe to use in all
> variants? The JSWED manual doesn't seem to cover this in the 64
> memory map section. The memory beyond #c600 appears to contain
> data, but is this just random remains?
This is what I consider when I'm looking for free space for patches in JSW64:
* #96F49717 (#24 bytes) contain unused code.
* Free space in #9800F6FF (Bank 0) varies from game to game, and it's up to the author to keep an accurate record of this using JSWED's Memory screen (it can also be useful to consult the Sprites screen, and even the Hex-editor, to get a more precise idea of which addresses are unused).
* #9B009BFF (#100 bytes) contain the sprites and colour-attributes or the colour-code screen, which is always bypassed.
* The unused space in rooms can be used for local patch-vectors, since the room-definition gets copied to the current-room buffer starting at #8000 but it cannot be used for global patches, since the rooms reside in memory-banks that are usually paged out.
--
Dr. Andrew Broad
|
|
|