home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
rtsi.com
/
2014.01.www.rtsi.com.tar
/
www.rtsi.com
/
OS9
/
OS9_6X09
/
SYSMODS
/
BLOB_Stop.lzh
/
readme2.intro
< prev
next >
Wrap
Text File
|
1994-09-10
|
7KB
|
180 lines
BLOBSTOP V1.0
readme2.intro
*********************** Introduction Part II ********************************
September 1, 1994
-----------------------------------------------------------------------------
First, a few definitions are in order:
1. BLOB:
Boot List Order Bug. A condition in which a CoCo fails to boot or after
booting, behaves improperly. Yet, when the modules in the OS9boot file
are reordered, the problem goes away.
2. true BLOB:
BLOB in which the problem is genuinely RELATED to the position of a
module in memory.
3. pseudo BLOB:
Other hardware or software problems which cause erratic operation which
may mimick true BLOB.
4. domino effect:
The condition in which the generation of one error results in abnormal
system operation due to other hardware or software bugs. For example,
after the occurance of an error #244 (as a result of BLOB) a person
MAY find that all futher commands lead to a #232 (bad module CRC) error.
5. memory surge:
A sudden, large demand on memory resources, especially SYSTEM memory.
6. 1773 or 1793:
The floppy disk controller (FDC) chip made by Western Digital. It is
used in virtually every floppy controller made for the CoCo.
--------------------------------------------------------------------------
**************************************************************************
************** Symptoms of the true BLOB which the patches ***************
************** in this archive should completely cure: ***************
**************************************************************************
1. Floppy formats abort with an error #244 (Read error) during the first
phase of formating (physical format - before it asks you for the disk
name). Note that the system MAY cease to function after this point
and all commands yield an error #232. The error #232 in not directly
caused by BLOB, but rather is the result of the domino efect.
2. Reads or Writes to floppies may yield an error #244 or more commonly,
no error, yet the first byte of each sector is lost. PCDOS will corrupt
file xfers under these conditions. Also, dirs may yield filenames
with the first letter missing.
3. Floppy boots fail. Yet, when cc3disk is moved around in OS9boot
or when another module, especially an odd length module like INIT, is
moved across cc3disk's position, the boot succeeds.
***************************************************************************
********************* Frequently Ask Questions ****************************
Q1: I use a Disto SCII controller in the buffered mode. So, I can't have
BLOB, right?
A1: wrong. The Disto drivers use a format routine that is susceptable
to BLOB. The included patches will fix this. Also, you need to patch
the stock lv2 boot module if you intend to boot from a floppy.
Q2: What does memory surge have to do with CoCo floppy drivers?
A2: Both the Disto and conventional cc3disk drivers consume 6.5K of SYSTEM
memory space for VERY brief intervals during the first stage of
formatting. You'll have trouble catching it in the act with utilities
like smap, but believe me, it's there. Just try a format with less than
6k of free system space. This "problem" is NOT fixed with the current
crop of patches. Future versions could fix this by blocking interrupts
and swapping in a new 8k block into the system space as is done in the
SCSI cache of Matt Thompson's SCSI system. Also, it would be nice to
have an add on 8-16k buffer for CoCo floppy controllers. This would
be especially practical for the SCII which already has all the support
logic needed. All it needs is a bigger counter and static RAM chip.
For the time being, just curtail multitasking during formats and watch
out for low system space conditions.
Q3: Do the included patches have any known negative side effects?
A3: Well, it depends on what you consider negative. After these patches
are installed, cc3disk will lock the system until a disk is inserted
into the drive and the drive door is closed if floppy I/O is attempted
without a floppy disk in the drive. Now, this behavior occurred under
certain conditions with even the stock cc3disk. So, it really isn't
something new. However, there is NO way of implementing a device not
ready check and still keep everything BLOB-proof. Note that in the case
of the Disto drivers, only the format routine is patched. So, the driver
will act exactly the same during buffered reads and writes.
Q4: Are the Western Digital 2793 controller chips susceptable to the BLOB
bug?
A4: unknown. The 27xx series offers many improvements over the 17xx series.
Hopefully, they fixed the BLOB problem in the 27xx series.....hopefully.
Q5: What about 17xx compatible clone chips made by companies other than
Western Digital?
A5: This is also unknown. When in doubt, patch.
Q6: I have modified my controller and driver to support High Density
floppies and/or give me other custom features. How do I get the needed
patches for my setup?
A6: In the tech info document, I provide you with enough information for you
to modify your custom driver using a disassembler, a text editor, and
asm, the level I assembler. In other words, I give you the source code
changes needed.
Q7: How is the cc3disk module size affected by these patches?
A7: Believe it or not, the modules actually get SHORTER after patching!
The exceptions are the boot patch which does not alter the length
of the boot module (I think this is required under Level II.). The
12b and 12c patches do increase the size of the stock cc3disk module
due to the pcdos capability overhead. Nevertheless, 12b and 12c are
still shorter than version #11.
Q8: What about the GIME S0-S2 decoding BLOB hardware fix? How does this
fit into everything?
A8: I am not convinced that this was ever a problem. Instead, I suspect that
the 1773 problem is responsible for the vast majority of BLOB related
phenomena. If the patches in this archive do not fix your problem, you
can try jumpering pin6 of IC9 to the E clock (the pin of R9 facing away
from the GIME is a good source of E) and see if your problem goes away.
If you need a hardware fix for S0-S2, read my misctips.txt file for more
info on this subject.
Q9: BLOB has something to do with keeping modules in the "proper" order
and/or trying to keep cc3disk in the same 8K block as RBF, right?
A9: wrong. As is explained in the tech info file, BLOB has to do with the
absolute position of cc3disk in memory not it's relative position
to other modules.
*****************************************************************************
Well, that about does it. I wish you good luck with your patching!
---
Michael Shell September 1, 1994
-- EOT --