This is my new patching system.

To apply a patch to an unpatched rom file:

   vpatch file.bin file.patch

The contents of a patch file are standard Vectrex/6809 assembly code, with
four extra optional directives:

   basename "output_name"
   patch    "patch_name"
   length  <input_length>
   crc32   $input_file_crc32_code

<basename> is used to write the output file under a consistent name everywhere.

<length> is used to check the input file.  If the file's length is shorter,
that is considered an error and the patcher exits.  If the file's length
however is longer than the length given, then only <length> bytes of the
file are used, and a warning is output.  This allows for binary files which
may have been padded to fit in an Eprom.  The padding may be overwritten.

Files with more than one switchable memory bank are not supported yet.
The feature may be added if there is sufficient demand.  Unbanked 48K
ROMs should be OK.

The <crc32> directive checks the input files contents.  If there was no
prior "length" directive, then the crc is calculated for the entire file.
If a length directive was issued, then the crc is only calculated for
that many bytes.  If the crc test does not succeed, the user may still
choose to apply the patch if they wish to.

For people creating patches, the crc is calculated using the standard
crc32 algorithm.  A minimal crc32 program is included or a better one
can be found online for most systems if you don't have one installed.

The vpatch program can be built from source but statically linked binaries
for Windows, Linux (ARM and X86), and possibly Mac should eventually be
supplied in this directory.  It's a simple command-line program but it
should be easy to wrap it in a drag & drop interface for folks who find
typing a command too difficult.

There are several example patches in this directory.  Here is perhaps
the simplest possible example while still supporting safety checks:

         basename "CosmicChasm"
         patch    "Lives"
         length 4096
         crc32  $6c1afa52

         org $0851
         nop
         nop
         nop
         nop

         end

vpatch may be given more than one patch file parameter, and it will
apply each patch in turn to the input bin file.  Each patch checks
the crc32 of the *original* file, so it is the patch-maker's responsibility
to ensure that the multiple patches don't step on each others toes.
Frankly this is a feature that came for free due to the way the
underlying assembler was written, and it is probably not needed or
useful.  I wouldn't recommend relying on it - creating patches that
do everything you want in the one file would be a better plan...


--

PS...

Users don't need to know this stuff - the info below is just for patch makers:

If encoding an existing patch rather than creating one from scratch,
I would suggest creating a disassembly listing of the original file
and of the patched binary, and comparing them with "diff" to get a source
version of the changes.  As it happens, I have a new disassembler under
development, in https://gtoal.com/SBTPROJECT/generic/ (dec.c is the
disassembler, not all the files in there will be needed) which does
a reasonable job of disassembling Vectrex binaries without any extra
manual input.  It's new and not 100% finished, but already it's a *lot*
better than any alternatives I know of (except maybe the disassembler
in Vide which can use run-time tracing information to create a more
complete listing, but that one is not nearly as easy to use.)

To get just the changed binary bytes, you can create a hex listing
of the two files instead (using the supplied 'hexdump') and do a
simple diff of the two, though if you have 'sdiff' then the included
'bincmp' script produces nicer output. (basically just "sdiff -s")