Path: utzoo!yunexus!hydroesm!jtsv16!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!uupsi!rodan!amichiel
From: amichiel@rodan.acs.syr.edu (Allen J Michielsen)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Patching ROMs
Keywords: ROM Patch
Message-ID: <3543@rodan.acs.syr.edu>
Date: 29 May 90 18:57:17 GMT
Article-I.D.: rodan.3543
References: <19838@duke.cs.duke.edu> <2660b6ad-1d5b.1comp.sys.ibm.pc-1@vpnet.chi.il.us>
Reply-To: amichiel@rodan.acs.syr.edu (Allen J Michielsen)
Organization: Syracuse University, Syracuse, NY
Lines: 21

In article <2660b6ad-1d5b.1comp.sys.ibm.pc-1@vpnet.chi.il.us> cgordon@vpnet....
>>...the POST facility
>>does some form of checksum on the ROM itself to verify integrity. 
>
>It doesn't matter where the check routine is; the requirement is very easy
>to satisfy.  Simply calculate the 16-bit arithmetic sum of the ROM contents,
>ignoring overflows.  The least significant byte of the sum should be zero. 
>That's all it takes!
>
>This is usually done...
   To say this simpler, if the current value is FFh and you want make the
usable value at that location F0h, then you would add 0Fh to the checksum.
If the checksum value is currently FCh and you add a OFh to it, you get 10Bh.
Since only 0Bh can be stored in 16 bits, simple throw away the leading 1 making
10Bh into 0Bh.  Simple as pie.
   If you are only changing a few bytes, this is easier than doing the whole
string over again.  Besides, the checksum can use other sum values than 00h.
It's a convention and anything could be used, or even a different method, 
making this non trivial problem w/out more info.  This probably isn;t the case
here, however...
al