28 Feb. 1991

   Known Bugs in CPU32Bug Version  1.00
   ------------------------------------
    1. DC
       a. "DC 88<<44" returns 00000880 instead of 0.
       b. "DC ([A0])" example in 332Bug manual doesn't work correctly.

    2. MM
       a. When an error entry is made, no error indication (message, bell) is
          given except to re-open the same location for a new entry.  While
          this is technically not an "error" because the manual doesn't state
          that an error indication should occur, it would seem a good thing
          to indicate when an error occurs so the user can correct it.
                 Ex:   332Bug>MM 4100
                       00004100 1234? 12W9       (Illegal hex value)
                       00004100 1234?            ($4100 re-opened)

    3. CPUx
       a. The CPU tests are not implemented.  The CPU however, is tested
          during the system confidence tests (self-test) during power on/
          reset.

    4. BERR
       a. The BERR tests are not implemented.




       +---------------------------------------------------------------+
       |                    ***  N O T I C E  ***                      |
       | 332Bug has been superceded by a new product called CPU32Bug   |
       | which is being released 28 FEB 91.  This new product, as the  |
       | name implies, is a generic bug for any CPU32 based MCU        |
       | supplied on the BCC unit, such as 68332 and 68331.  This new  |
       | product was derived from 332Bug 1.02, but has "fixes" for the |
       | following bug numbers listed below.                           |
       |                                                               |
       |        5, 6, 7, 8 (documentation change), 9, 10, 11           |
       |                                                               |
       +---------------------------------------------------------------+

   Known Bugs in 332Bug Version  1.02
   ----------------------------------
    1. DC
       a. "DC 88<<44" returns 00000880 instead of 0.
       b. "DC ([A0])" example in 332Bug manual doesn't work correctly.

    2. MM
       a. When an error entry is made, no error indication (message, bell) is
          given except to re-open the same location for a new entry.  While
          this is technically not an "error" because the manual doesn't state
          that an error indication should occur, it would seem a good thing
          to indicate when an error occurs so the user can correct it.
                 Ex:   332Bug>MM 4100
                       00004100 1234? 12W9       (Illegal hex value)
                       00004100 1234?            ($4100 re-opened)

    3. CPUx
       a. The CPU tests are not implemented.  The CPU however, is tested
          during the system confidence tests (self-test) during power on/
          reset.

    4. BERR
       a. The BERR tests are not implemented.

    5. LO/VE Commands
       a. The optional <ADDR> field does not function properly for negative
          values as per the example ("LO -65000000") shown in the manual.
          Also, the problem cannot be overcome by entering the two's comple-
          ment of the required value, i.e., FFFFF800 for -800.

          As a workaround, always enter the port number when a negative
          <ADDR> field is required, i.e., enter "LO 0,-800" or "LO ,-800"
          for the default port number (0).

    6. RESET Button
       a. When the RESET button is pressed, the long word at $4000 for Rev.
          B BCC units is over-written with $660E660E due to the Rev. A/Rev.
          B detection algorithm employed.  There is no problem with Rev. A
          BCC units.

          As a workaround, whenever RESET is pressed, users with Rev. B BCC
          units should restore the contents of locations $4000 through $4003,
          either by reloading the program via the LO command or by using the
          MM command.  For large programs, use the DU command to save a copy
          of only the affected locations, i.e., enter "DU 4000 4003".

    7. CSBOOT
       a. Upon powerup, CSBOOT defaults to 13 wait cycles and remains at
          this value until all chip selects are programmed after the
          software determines which Revision type of BCC board it is
          operating on, A or B.  This prevents booting in the 8-bit mode
          because the extra time required for two memory accesses per
          instruction causes the bus monitor to time out after it is
          changed from its default of 64 clock cycles to its operational
          value of 16.

    8. MS
       a. The manual does not state that all data is stored on a byte-by-
          byte basis and thus the MS command should not be used on any
          locations that require word accessing only, such as the TPU
          registers.  For those locations requiring word accessing, use
          the MM command with the ";W" (default) or ";L" option.

    9. AUTO BOOT VECTORS
       a. The ROM auto boot vectors at parameter offset $78 in Appendix C
          of the 332Bug User's Manual will be taken when activated,
          irregardless of any diagnostic error on power up/reset.

   10. RL
       a. The diagnostic command, Read Loop, does not properly handle BUS
          ERRORs caused by a read operation.  Control of the system is lost
          after the "BUS ERRORS!" message is reported.

   11. WR
       a. The diagnostic command, Write/Read Loop, does not properly handle
          BUS ERRORs caused by a read operation.  Control of the system is
          lost after the "BUS ERRORS!" message is reported.


   Version 1.01 Bugs Fixed in Version 1.02
   ---------------------------------------
    1. The test used to determine whether 332Bug is executing on a Rev. A
       or Rev. B BCC unit did not work correctly, causing 332Bug on Rev. B
       units to malfunction ("crash") before the system ready prompt
       ("332Bug>") was issued.

   **END**