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: 6139
Author: andrewbroad
Date: 24/04/2007
Subject: How SPECSAISIE made the Special Edition of Party Willy
I have uploaded Beta 4 of SPECSAISIE, which updates MirrorJSW to the
version which generated _ylliW teS teJ_ for the Party Willy SE, and
also adds hex-support to many more functions.
I have also updated my web-pages on SPECSAISIE and Mirroring:
http://geocities.com/andrewbroad/spectrum/willy/
I thought it would be instructive to detail how helpful SPECSAISIE
was in creating the Special Edition of Party Willy - that is the
purpose of this message.
--------------------
Changes to PART1.TAP
--------------------
[49] "The Return of the Brothers Grimm": displaced the ramp one cell
to the left.
#F1DB: #C9 -> #C8
[54] "Esmerelda's Bedroom": added two Fire-cells...
#F66C: 0 -> #30
#F674: 0 -> #30
...and shifted the HGs' start-positions two cells to the right.
#F6FD: #F -> #11 (yellow monk)
#F6FF: #13 -> #15 (magenta Maria)
[Scrolly] removed ", JESTER INTERACTIVE 2001" and inserted "SPECIAL
EDITION 2007 . . "
To apply these changes without corrupting PART1.TAP required a
somewhat unorthodox solution. First I made a copy of PART1.TAP
(oldPART1.TAP), then edited PART1.TAP in JSWED - but saving it in
JSWED gets rid of my custom loader and customary Easter-egg. :-(
So I used SPECSAISIE via the following batch-file (makePart1.bat):
>>>java Split oldPART1.TAP 3
java Split PART1.TAP 2
java TAPtoBinary PART1_2.TAP PART1_2.BIN
java BinaryToTAP PART1_2.BIN PART1_2.TAP "Part1" 32768 32768
cat PART1-LOADER.TAP PART1_2.TAP oldPART1_3.TAP > PART1.TAP
del *.BIN *PART1_*.TAP
<<<
where PART1-LOADER.TAP is the new BASIC loader, saved using
RealSpectrum.
The use of TAPtoBinary followed by BinaryToTAP is simply to
rename "jsw.js2" back to "Part1". I should probably write a
SPECSAISIE RenameTAP function.
Note that makePart1.bat is idempotent: it won't result in a mangled
TAP-file if you accidently run it twice. This is because it simply
extracts the second Spectrum-file from PART1.TAP and puts it back in
the same place when PART1.TAP is reconstructed.
If makePart1.bat were /not/ idempotent, it would be advisable to keep
two copies of PART1.TAP: one to edit in JSWED (jswedPART1.TAP), and
the one that is generated by makepart1.bat (madePART1.TAP - so named
to help me remember not to edit it in JSWED, but this is the one I
ultimately renamed and released as PART1.TAP).
--------------------
Changes to PART2.TAP
--------------------
[30] "Where is Matthew Smith?": removed a Water-cell.
#DE3D: 4 -> 0
[Scrolly] removed ", JESTER INTERACTIVE 2001" and inserted "SPECIAL
EDITION 2007 . . "
The way I applied these changes is completely analogous to Part 1 -
literally just a matter of replacing "PART1" with "PART2",
and "Part1" with "Part2", throughout "makePart2.bat".
-----
PW128
-----
To apply both sets of changes to PW128.TAP, I:
1. made a copy of PW128.TAP: oldPW128.TAP;
2. renamed the copy I'm going to edit to jswedPW128.TAP (to avoid
confusion and possible loss of work later on);
3. used JSWED's hex-editor to apply the Part 1 pokes to the
corresponding addresses in Bank 3 [Rooms 64-127];
4. ditto re. Part 2, Bank 1 [Rooms 0-63];
5. edited the scrolly using JSWED;
6. saved jswedPW128.TAP;
7. used SPECSAISIE via the batch-file "makePW128.bat" to reconstruct
PW128.TAP so that the above changes are applied whilst retaining my
custom loader and tunes, and /without/ upgrading from JSW128
Hacklevel 8 to Hacklevel 9:
jswedPW128.TAP:
1. Program: JetSet.128
2. Bytes: hiload.js7
3. Bytes: rooms.js6
4. Bytes: rooms.js4
5. Bytes: rooms.js3 (containing changes to Part 2)
6. Bytes: rooms.js1 (containing changes to Part 1)
7. Bytes: title.js7 (containing changes to the scrolly)
8. Bytes: rtime.js2
9. Bytes: main.tun
10. Bytes: cheat.tun
11. Bytes: tune.bin
12. Bytes: title.tun
oldPW128.TAP:
1. Program: PW128 (needs updating)
2. Bytes: hiload.bin
3. Bytes: rooms.js3 (needs updating)
4. Bytes: rooms.js1 (needs updating)
5. Bytes: title.js7 (needs updating)
6. Bytes: rtime.js2
7. Bytes: wolf.tun
8. Bytes: bluebi.tun
9. Bytes: tune.bin
The mapping (madePW128.TAP - generated by makePW128.bat):
1. (PW128-LOADER.TAP) Program: PW128
2. (oldPW128.TAP) Bytes: hiload.bin
3. (jswedPW128.TAP:5) Bytes: rooms.js3
4. (jswedPW128.TAP:6) Bytes: rooms.js1
5. (jswedPW128.TAP:7) Bytes: title.js7
6. (oldPW128.TAP) Bytes: rtime.js2
7. (oldPW128.TAP) Bytes: wolf.tun
8. (oldPW128.TAP) Bytes: bluebi.tun
9. (oldPW128.TAP) Bytes: tune.bin
makePW128.bat:
>>>java Split oldPW128.TAP 2 9
java Split jswedPW128.TAP 5 7
cat PW128-LOADER.TAP oldPW128_2.TAP jswedPW128_5.TAP jswedPW128_6.TAP
jswedPW128_7.TAP > TEMP.TAP
cat TEMP.TAP oldPW128_6.TAP oldPW128_7.TAP oldPW128_8.TAP
oldPW128_9.TAP > madePW128.TAP
del *PW128_*.TAP TEMP.TAP
<<<
Note my naming-conventions here: jswedPW128.TAP and madePW128.TAP.
I do this to address the following concerns:
(a) If I used just one filename - PW128.TAP - then makePW128.bat
would not be idempotent. That is to say, if I accidently ran
makePW128.bat twice in a row, the result would be a mangled TAP-file
containing *two* copies of rtime.js2 and wolf.tun and *no* copies of
rooms.js3 and rooms.js1 - i.e. I'd have lost all my room-data!
(b) Having two filenames does present the danger that you'll edit the
wrong one in JSWED, and then lose your changes when you run
makePW128.bat again. So jswedPW128.TAP is the one I edited in JSWED,
and madePW128.TAP is the generated TAP-file that I ultimately
released (after renaming it back to PW128.TAP).
oldPW128.TAP serves two purposes:
(a) It's the source of the data that JSWED removes (in general terms,
this could include custom loaders, loading-screens, Easter-eggs,
unconventional filenames and an old version of the JSW128 game-
engine).
If madePW128.TAP changed any of these data (namely, I have edited the
custom loader), then it would become the next oldPW128.TAP should I
want to edit the game further.
(b) oldPW128.TAP can be compared with madePW128.TAP in order to check
that just the right changes have been applied.
I used the following batch-file to satisfy myself that the above
changes had been applied correctly:
>>>java Split oldPW128.TAP 2 9
java Split madePW128.TAP 2 9
java Compare -bh oldPW128_2.TAP madePW128_2.TAP
pause
java Compare -bhj oldPW128_3.TAP madePW128_3.TAP
pause
java Compare -bhj oldPW128_4.TAP madePW128_4.TAP
pause
java Compare -bh oldPW128_5.TAP madePW128_5.TAP
pause
java Compare -bh oldPW128_6.TAP madePW128_6.TAP
pause
java Compare -bh oldPW128_7.TAP madePW128_7.TAP
pause
java Compare -bh oldPW128_8.TAP madePW128_8.TAP
pause
java Compare -bh oldPW128_9.TAP madePW128_9.TAP
del *PW128_*.TAP
<<<
SPECSAISIE does not yet recognise 128K memory, let alone the file-
naming conventions used by JSW128 and JSW64 games. Given two TAP-
files, Compare works by loading each TAP-file into its own
representation of 48K memory, and then comparing them byte-by-byte at
corresponding addresses.
Whenever the current version of SPECSAISIE loads a TAP-file, it loads
each Spectrum-file on the TAP-file into memory one after another -
therefore when the addresses overlap, later files on the TAP will
overwrite earlier files. That's why it is sometimes necessary to
Split the TAP-files prior to comparison: to reveal differences that
would otherwise be hidden because their addresses are overwritten in
this way.
--
Dr. Andrew Broad
http://geocities.com/andrewbroad/
http://geocities.com/andrewbroad/spectrum/
http://geocities.com/andrewbroad/spectrum/willy/
http://geocities.com/andrewbroad/spectrum/download/
http://geocities.com/andrewbroad/spectrum/download/specsaisie.html
|
|
|