Discussion:
bsum - compute BSD checksums of your files
(too old to reply)
Mateusz Viste
2017-04-09 18:09:30 UTC
Permalink
Hello,

I needed to verify the integrity of a few files after transferring them
to/from my 8086 PC the other day. The obvious method for such task is
computing a checksum of the file, like MD5, SHA1, etc... However, on an
8086 this may take ages (even on a fairly fast 386, computing the MD5 sum
of a 2 MiB file takes one minute).

Since I don't like waiting, I created an alternative tool over the
weekend: bsum.

bsum is a tiny DOS tool that computes the BSD checksum of a file. It's
very tiny: only 256 bytes (half of which is taken by the help screen), so
it will easily fit in a single disk sector. A BSD checksum is obviously
not as strong as MD5 or SHA1, but it's still more than enough for
verifying whether or not a file got corrupted during a transfer.

bsum is compatible with 8086 and requires only a few kilobytes of memory.
Also, it's very fast.

Homepage: http://bsum.sourceforge.net

Mateusz
Computer Nerd Kev
2017-04-10 22:36:28 UTC
Permalink
Post by Mateusz Viste
bsum is compatible with 8086 and requires only a few kilobytes of memory.
Also, it's very fast.
Homepage: http://bsum.sourceforge.net
Nice, should be handy with my old portable PCs and their floppy
drives in varying states of decay.
--
__ __
#_ < |\| |< _#
Kerr Mudd-John
2017-04-11 21:12:04 UTC
Permalink
On Sun, 09 Apr 2017 19:09:30 +0100, Mateusz Viste
Post by Mateusz Viste
Hello,
I needed to verify the integrity of a few files after transferring them
to/from my 8086 PC the other day. The obvious method for such task is
computing a checksum of the file, like MD5, SHA1, etc... However, on an
8086 this may take ages (even on a fairly fast 386, computing the MD5 sum
of a 2 MiB file takes one minute).
Since I don't like waiting, I created an alternative tool over the
weekend: bsum.
bsum is a tiny DOS tool that computes the BSD checksum of a file. It's
very tiny: only 256 bytes (half of which is taken by the help screen), so
it will easily fit in a single disk sector. A BSD checksum is obviously
not as strong as MD5 or SHA1, but it's still more than enough for
verifying whether or not a file got corrupted during a transfer.
bsum is compatible with 8086 and requires only a few kilobytes of memory.
Also, it's very fast.
Homepage: http://bsum.sourceforge.net
Looking at your source, I can see how to save another 9 bytes:

have a single printerrorandexit part; set dx to relevant msg then j[cc] to
it. (Also avoids the skipping).

At start you compute dx for the fn from the psp, but di is just a byte
away!

Here's what I did to the start:

mov di, 0080h
xor cx,cx
mov cl,[di]
inc di
mov bx, cx
; add a 0 terminator to the arg, so it can be passed to INT 21h fopen()
mov [di+bx], ch
mov al, 20h
repe scasb
; no arg: print help screen and quit with err 01
mov dx, MSGHLP
jz msgexit

; set dx to the start of the argument (ignore leading white spaces)
;lea dx, [bx+80h]
;sub dx, cx
dec di ; di is 2nd char of parm
mov dx,di

; open file

...

; I/O error -> close file and quit!
mov ah, 3Eh ; DOS 2+ "close file" (bx contains the file handle
already)
int 21h
mov dx, MSGERR

msgexit:
mov ah, 09h
int 21h

mov ax, 4C01h
int 21h

...
--
Bah, and indeed, Humbug
Mateusz Viste
2017-04-12 08:07:44 UTC
Permalink
Hi Kerr,

I didn't study your code yet, but I did try to paste and assemble it.
Unfortunately, it doesn't seem to react correctly - when called without
any argument, it outputs "ERROR" instead of the help screen. But well,
perhaps I missed something, I will try to look more closely to that later.

BTW, the source code of bsum evolved slightly since the v1.0, the latest
version is here:
https://sourceforge.net/p/bsum/code/HEAD/tree/trunk/

Mateusz
Post by Kerr Mudd-John
On Sun, 09 Apr 2017 19:09:30 +0100, Mateusz Viste
Post by Mateusz Viste
Hello,
I needed to verify the integrity of a few files after transferring them
to/from my 8086 PC the other day. The obvious method for such task is
computing a checksum of the file, like MD5, SHA1, etc... However, on an
8086 this may take ages (even on a fairly fast 386, computing the MD5
sum of a 2 MiB file takes one minute).
Since I don't like waiting, I created an alternative tool over the
weekend: bsum.
bsum is a tiny DOS tool that computes the BSD checksum of a file. It's
very tiny: only 256 bytes (half of which is taken by the help screen),
so it will easily fit in a single disk sector. A BSD checksum is
obviously not as strong as MD5 or SHA1, but it's still more than enough
for verifying whether or not a file got corrupted during a transfer.
bsum is compatible with 8086 and requires only a few kilobytes of memory.
Also, it's very fast.
Homepage: http://bsum.sourceforge.net
have a single printerrorandexit part; set dx to relevant msg then j[cc]
to it. (Also avoids the skipping).
At start you compute dx for the fn from the psp, but di is just a byte
away!
mov di, 0080h xor cx,cx mov cl,[di]
inc di mov bx, cx ; add a 0 terminator to the arg, so it can be passed
print help screen and quit with err 01 mov dx, MSGHLP jz msgexit
; set dx to the start of the argument (ignore leading white spaces)
;lea dx, [bx+80h]
;sub dx, cx dec di ; di is 2nd char of parm mov dx,di
; open file
...
; I/O error -> close file and quit!
mov ah, 3Eh ; DOS 2+ "close file" (bx contains the file handle
already)
int 21h mov dx, MSGERR
mov ah, 09h int 21h
mov ax, 4C01h int 21h
...
Kerr Mudd-John
2017-04-12 09:40:06 UTC
Permalink
On Wed, 12 Apr 2017 09:07:44 +0100, Mateusz Viste
Post by Mateusz Viste
Hi Kerr,
I didn't study your code yet, but I did try to paste and assemble it.
Unfortunately, it doesn't seem to react correctly - when called without
any argument, it outputs "ERROR" instead of the help screen. But well,
perhaps I missed something, I will try to look more closely to that later.
It was just meant to be a snippet, as you've got copyright!
Post by Mateusz Viste
BTW, the source code of bsum evolved slightly since the v1.0, the latest
https://sourceforge.net/p/bsum/code/HEAD/tree/trunk/
Mateusz
[]
Post by Mateusz Viste
have a single printerrorandexit part; set dx to relevant msg beforehand
then j[cc]
to it. (Also avoids the skipping).
At start you compute dx for the fn from the psp, but di is just a byte
away!
Bad formatting of pasted code removed the crlfs!

But I was hoping the description was enough!

As you're also printing a crlf, you can have a general msgexit routine,
and dec bp before jmping to it


at end:

mov dx, CRLF
dec bp
jmp short msgexit



earlier (after failed read)

... (close file)

mov dx, MSGERR
msgexit:
mov ah, 09h ; print message
int 21h
xchg ax, bp ; smaller than doing a mov ax, 4C01h
int 21h
--
Bah, and indeed, Humbug
Mateusz Viste
2017-04-15 16:41:05 UTC
Permalink
Hi, I looked more closely today at it. Your remarks do make perfect
sense, and save a few bytes here and there. Thanks!

Mateusz
Post by Kerr Mudd-John
On Wed, 12 Apr 2017 09:07:44 +0100, Mateusz Viste
Post by Mateusz Viste
Hi Kerr,
I didn't study your code yet, but I did try to paste and assemble it.
Unfortunately, it doesn't seem to react correctly - when called without
any argument, it outputs "ERROR" instead of the help screen. But well,
perhaps I missed something, I will try to look more closely to that later.
It was just meant to be a snippet, as you've got copyright!
Post by Mateusz Viste
BTW, the source code of bsum evolved slightly since the v1.0, the
https://sourceforge.net/p/bsum/code/HEAD/tree/trunk/
Mateusz
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
have a single printerrorandexit part; set dx to relevant msg
beforehand then j[cc]
to it. (Also avoids the skipping).
At start you compute dx for the fn from the psp, but di is just a byte
away!
Bad formatting of pasted code removed the crlfs!
But I was hoping the description was enough!
As you're also printing a crlf, you can have a general msgexit routine,
and dec bp before jmping to it
mov dx, CRLF dec bp jmp short msgexit
earlier (after failed read)
... (close file)
mov ah, 09h ; print message int 21h xchg ax, bp ; smaller
than doing a mov ax, 4C01h int 21h
Kerr Mudd-John
2017-04-19 20:36:22 UTC
Permalink
On Sat, 15 Apr 2017 17:41:05 +0100, Mateusz Viste
Post by Mateusz Viste
Hi, I looked more closely today at it. Your remarks do make perfect
sense, and save a few bytes here and there. Thanks!
Mateusz
Glad to help - you can now add 8? extra bytes to the error messages!
Post by Mateusz Viste
Post by Kerr Mudd-John
On Wed, 12 Apr 2017 09:07:44 +0100, Mateusz Viste
Post by Mateusz Viste
Hi Kerr,
I didn't study your code yet, but I did try to paste and assemble it.
Unfortunately, it doesn't seem to react correctly - when called without
any argument, it outputs "ERROR" instead of the help screen. But well,
perhaps I missed something, I will try to look more closely to that later.
It was just meant to be a snippet, as you've got copyright!
Post by Mateusz Viste
BTW, the source code of bsum evolved slightly since the v1.0, the
https://sourceforge.net/p/bsum/code/HEAD/tree/trunk/
Mateusz
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
have a single printerrorandexit part; set dx to relevant msg
beforehand then j[cc]
to it. (Also avoids the skipping).
At start you compute dx for the fn from the psp, but di is just a byte
away!
Bad formatting of pasted code removed the crlfs!
But I was hoping the description was enough!
As you're also printing a crlf, you can have a general msgexit routine,
and dec bp before jmping to it
mov dx, CRLF dec bp jmp short msgexit
earlier (after failed read)
... (close file)
mov ah, 09h ; print message int 21h xchg ax, bp ; smaller
than doing a mov ax, 4C01h int 21h
--
Bah, and indeed, Humbug
Kerr Mudd-John
2017-07-18 12:22:39 UTC
Permalink
Post by Mateusz Viste
Hi, I looked more closely today at it. Your remarks do make perfect
sense, and save a few bytes here and there. Thanks!
Mateusz
Post by Kerr Mudd-John
On Wed, 12 Apr 2017 09:07:44 +0100, Mateusz Viste
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
Post by Mateusz Viste
BTW, the source code of bsum evolved slightly since the v1.0, the
https://sourceforge.net/p/bsum/code/HEAD/tree/trunk/
Mateusz
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
At start you compute dx for the fn from the psp, but di is just a
byte away!
Just looked at the current code ; someone's stuck their name at the end
to pad to 256 bytes; I can't see much else; but you didn't incorporate
my dx suggestion (probably because I had inc where it should have been
dec!)

... - code not copied
;## MJ - my comments
;;; - your code commented out
3 space leader - my code suggestion to put in



...
repe scasb
mov dx, MSGHLP ; preset MSGHLP in case I need to quit with help screen
jz short PRINTANDQUIT ; no arg: print help screen and quit
; set dx to the start of the argument (ignore leading white spaces)
;## MJ shorter:
dec di ; back to 1st non-blank in parm string
mov dx, di ; dx is now a filename, we hope
;;;lea dx, [bx+80h]
;;;sub dx, cx




; open file
mov ax, 3D00h ; DOS 2+ "open file", read-only - di contains the file name
int 21h
;## MJ drop setting dx here
;;;mov dx, MSGERR
;;;jc short PRINTANDQUIT
;## MJ replace with
jc ERREXIT
...


saves another 6, I think.
...
;## MJ insert label:
ERREXIT:
mov dx, MSGERR
PRINTANDQUIT:
...
Mateusz Viste
2017-08-16 13:21:02 UTC
Permalink
Hi Kerr, thank you again for your input! I applied both your suggestions
to the bsum's svn trunk. They save 3 bytes each, for a grand total of 6
bytes. I won't release a new version yet, though. I will wait for a few
months so perhaps I will change some other stuff in the code, and then
publish a formal v1.2.

thanks!

Mateusz
Post by Kerr Mudd-John
Post by Mateusz Viste
Hi, I looked more closely today at it. Your remarks do make perfect
sense, and save a few bytes here and there. Thanks!
Mateusz
Post by Kerr Mudd-John
On Wed, 12 Apr 2017 09:07:44 +0100, Mateusz Viste
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
Post by Mateusz Viste
BTW, the source code of bsum evolved slightly since the v1.0, the
https://sourceforge.net/p/bsum/code/HEAD/tree/trunk/
Mateusz
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
At start you compute dx for the fn from the psp, but di is just a
byte away!
Just looked at the current code ; someone's stuck their name at the end
to pad to 256 bytes; I can't see much else; but you didn't incorporate
my dx suggestion (probably because I had inc where it should have been
dec!)
... - code not copied ;## MJ - my comments ;;; - your code commented
out 3 space leader - my code suggestion to put in
...
repe scasb mov dx, MSGHLP ; preset MSGHLP in case I need to quit
with help screen jz short PRINTANDQUIT ; no arg: print help screen and
quit ; set dx to the start of the argument (ignore leading white spaces)
dec di ; back to 1st non-blank in parm string mov dx, di
; dx is now a filename, we hope
;;;lea dx, [bx+80h]
;;;sub dx, cx
; open file mov ax, 3D00h ; DOS 2+ "open file", read-only - di
contains the file name int 21h ;## MJ drop setting dx here ;;;mov dx,
MSGERR ;;;jc short PRINTANDQUIT ;## MJ replace with
jc ERREXIT
...
saves another 6, I think.
...
...
Kerr-Mudd,John
2017-08-22 14:10:57 UTC
Permalink
Post by Mateusz Viste
Hi Kerr, thank you again for your input! I applied both your
suggestions
Post by Mateusz Viste
to the bsum's svn trunk. They save 3 bytes each, for a grand total of 6
bytes. I won't release a new version yet, though. I will wait for a few
months so perhaps I will change some other stuff in the code, and then
publish a formal v1.2.
I'd be inclined to scrap the end text filler; or at least take this guys
name out:
i.e.

FILLER resb 256-($-START) ; adjust the binary to 256 bytes

-not-

FILLER db " Mojmir V." ; adjust the binary to 250 bytes


I have a shorter filename setup:

; is there a (non-empty) argument?
mov al, 20h ; scan for non space chars
mov di, 0080h ; set to PSP parms
xor bx, bx ; bh=0
mov bl, [di] ; get lth of parm string into bx
inc di ; di points to parm string
mov [di+bx], bh ; set terminating ASCII zero
mov cx, bx ; lth in cx for scasb
repe scasb

16 bytes:
B020 BF8000 31DB 8A1D 47 8839 87D9 F3AE
Post by Mateusz Viste
thanks!
Mateusz
Post by Kerr Mudd-John
Post by Mateusz Viste
Hi, I looked more closely today at it. Your remarks do make perfect
sense, and save a few bytes here and there. Thanks!
Mateusz
Post by Kerr Mudd-John
On Wed, 12 Apr 2017 09:07:44 +0100, Mateusz Viste
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
Post by Mateusz Viste
BTW, the source code of bsum evolved slightly since the v1.0, the
https://sourceforge.net/p/bsum/code/HEAD/tree/trunk/
Mateusz
[]
Post by Mateusz Viste
Post by Kerr Mudd-John
At start you compute dx for the fn from the psp, but di is just a
byte away!
Just looked at the current code ; someone's stuck their name at the end
to pad to 256 bytes; I can't see much else; but you didn't incorporate
my dx suggestion (probably because I had inc where it should have been
dec!)
... - code not copied ;## MJ - my comments ;;; - your code commented
out 3 space leader - my code suggestion to put in
...
repe scasb mov dx, MSGHLP ; preset MSGHLP in case I need to quit
with help screen jz short PRINTANDQUIT ; no arg: print help screen and
quit ; set dx to the start of the argument (ignore leading white spaces)
dec di ; back to 1st non-blank in parm string mov dx, di
; dx is now a filename, we hope
;;;lea dx, [bx+80h]
;;;sub dx, cx
; open file mov ax, 3D00h ; DOS 2+ "open file", read-only - di
contains the file name int 21h ;## MJ drop setting dx here ;;;mov dx,
MSGERR ;;;jc short PRINTANDQUIT ;## MJ replace with
jc ERREXIT
...
saves another 6, I think.
...
...
Loading...