C70:info-cpm (06/26/82)
>From ucivax!csuf!bruce@Ucb-C70 Fri Jun 25 21:18:52 1982
Are there any known bugs in the sector blocking/deblocking algorithms
supplied by Digital Research with CP/M? I don't mean the field patch that
DR distributes (the one you make to MOVCPM). I've already installed that
one. My problem is this:
ONLY when running the CP/M editor 'ed', files larger than one extent (128
records, in my system) end up garbled. What happens is a sector from the
NEXT extent ends up replacing the corresponding sector in the PREVIOUS
extent. This continues throughout the whole file. NONE of the other
programs I have, CP/M-supplied or otherwise, do this. I have one clue;
when I patch the BIOS to jump around the code that checks for a write to
an unallocated block, the problem goes away. I have checked and rechecked
the code that is being skipped over, and I can't find anything wrong with
it. The code in question is between the labels 'chkuna:' and 'alloc:'.
I'm using exactly this code in my BIOS. Has anyone else had a problem
similar to this one?
Bruce
ucbvax!ucivax!csuf!bruceC70:info-cpm (06/26/82)
>From ucivax!csuf!bruce@Ucb-C70 Sat Jun 26 06:23:53 1982
Ah HAH!!! I found the problem! It IS a bug in the Digital Research-supplied
code. If you write the lower 128 bytes of a 256-byte UNALLOCATED blocked
sector, everything is fine. If you then decide to read or write a sector in
another block, everything is still fine; the original unallocated sector gets
written out correctly. However, if you then decide to write the upper 128
bytes of the altered sector, the BIOS thinks it's still in the unallocated
block, and decides not to preread the original sector. This causes you to
lose the first 128 bytes of the sector. After wasting an entire day on this
problem, I now have a working BIOS. It sure would be nice if Digital Research
would send a bug fix for this problem. It only takes one instruction to fix...
bruce
ucbvax!ucivax!csuf!bruceC70:info-cpm (06/26/82)
>From w8sdz@BRL Sat Jun 26 15:23:11 1982
Bruce, are you sure you have the newest version of DR's deblocking?
The original release had some bugs, as I recall, and they revised it
when CP/M 2.2 was released. If you have CRCK.COM, please use it on
the distribution file you have and tell me what CRC it reads. I'll
check that against mine to see if you have the newer version.C70:info-cpm (06/28/82)
>From POURNE@Mit-Mc Mon Jun 28 04:13:50 1982
Godbout/Compupro will shortly be supplying a new BIOS with their
equipment. This was written by Tony Pietsch, and features
provisions for M (warp) drive, m (mini-floppy), as well as
driving the Godbout controller faster than anything we've seen
yet. Alas they are removing Tony's builtin provision for the N
Drive (semi-disk) on the , sigh, reasonable grounds that they're
not responsible for providing software to support another
company's competing products.
If you have an older Compupro you should think about
getting the new BIOS, which ought to be available in perhaps a
month. One nice feature: if you try to access a drive with no
disk in it, it says "Load the Drive, Stupid" instead of BDOS
error...
This impressed a couple of Compupro engineers no end last night
when they were over for a couple of hours and I demonstrated the
BIOS. As always you get the source code.
(NOTE: I have no commercial interest in this at all; but
I have seen a number of people go slightly mad because they
don't have the BIOS source, or can't do certain things, or get
BDOS errors when they shouldn't, and I conclude that one reason
I like my computer so much is that I seem to have awfully good
software; better than I knew until I saw what others put up
with...)
JEPC70:info-cpm (07/02/82)
>From ucivax!csuf!bruce@Ucb-C70 Fri Jul 2 12:33:48 1982
Well, I found out why I was having difficulty...
WARNING!!!!! To all those who are implementing a BIOS that uses the Blocking/
Deblocking algorithms supplied by Digital Research!!!!!
While the bug that I found has been fixed in the copy of the algorithm supplied
in DEBLOCK.ASM on the CP/M distribution disk, DR did NOT update the CP/M 2.2
Alteration Guide! I was using the listing printed in the guide when I typed in
my BIOS, and did not think to check the copy on the file. As it was, DR's fix
takes two instructions, while mine takes only 1, and mine is more efficient!
For those of you who are waiting with baited breath (phew!), my fix is as
follows:
filhst:
;may have to fill the host buffer
lda sekdsk ; the desired sector is now the current sector
sta hstdsk
lhld sektrk
shld hsttrk
lda seksec
sta hstsec
lda rsflag ; need to read?
ora a
cnz readhst ; yes, if non-zero
xra a ; no pending write
sta hstwrt
sta unacnt ; <----- this is my modification - if we get
; here, we can't still be within an unallocated
; block.
Digital Research fixed the problem by clearing 'unacnt' EVERY time a read is
performed. My fix allows you to read back the sector you just wrote, without
forgetting that you're within an unallocated block. Hmmm... come to think of
it, my way of doing it may not be right, either. What if you write the first
128 bytes of a sector in an unallocated block, and then read then second 128
bytes? It seems to me that I'll get garbage... oh well, doing a preread on the
unallocated block, THEN returning the second 128 bytes will also give you
garbage, so I'm not going to worry about it.
Actually, neither solution is optimal. What if you write a sector in an
unallocated block, then go off and read something elsewhere on the disk, and
then come back to write the next sector in the unallocated block? This happens
fairly often when you are copying a file from one place to another on the same
disk, but normally it happens so rarely that I didn't think it was worth the
trouble to implement. In any case, my BIOS now works, so I'm happy...
Bruce