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 / misctips.txt < prev    next >
Text File  |  1994-09-10  |  8KB  |  207 lines
  1.                           BLOBSTOP V1.0
  2.  
  3. misctips.txt 
  4.  
  5. ****************************************************************************
  6.  
  7. September 1, 1994
  8.  
  9.  
  10.      Here's a bunch of odd ball items that you might find helpful:
  11.  
  12.  
  13.  
  14.    1. In case anybody is wondering who turns up the speed, one of the last
  15.       things the boot module does is to put the CoCo into the 2 Mhz mode.
  16.  
  17.  
  18.    2. If you have test code within a device driver and you want it to send
  19.       you a "signal", try poking values into the border register at $FF9A.
  20.       OS9 won't mind a bit.
  21.  
  22.    
  23.    3. If your disassembler is the type that misses IRQ routines and prints
  24.       them as a bunch of fcbs, try this trick: a. Disassemble the code.
  25.       b. Put in long branch subroutines (lbsr) to the beginning of each IRQ
  26.       routine that the disassembler missed. The best place to do this is in
  27.       the last instructions that the disassembler picked up:
  28.  
  29.       .
  30.       .
  31.       .
  32.       decb
  33.       bne L004b
  34.       clrb
  35.       rts
  36.      * end of code here
  37.  
  38.  
  39.       Becomes:
  40.  
  41.       .
  42.       .
  43.       .
  44.       decb
  45.       bne L004b       note that the lbsrs are in a "path of 
  46.       clrb            execution"           
  47.       lbsr D0100      branch to IRQ#1 that disa missed
  48.       lbsr D02f0      branch to NMI that disa missed
  49.       lbsr D01a0      branch to IRQ#2 that disa missed
  50.       rts
  51.      * end of code
  52.  
  53.       c. Assemble the code with asm. d. Disassemble the resulting object
  54.       code. e. Remove the statements that you added. Remember that the
  55.       offset labels to code after your inserted code will no longer be valid
  56.       as offsets from the start of the module. If you have no labels after
  57.       the place where your lbsrs were, then this will not be a problem.
  58.       f. Presto, fully disassembled code!
  59.  
  60.  
  61.    3. The magnetic zones on a disk tend to repel or attract each other 
  62.       depending on their respective polarities, just like little magnets.
  63.       Thus, the ones and zeros on a disk tend to "move" a bit depending on
  64.       the adjacent bits. If pronounced enough, this effect can lead to read
  65.       errors. This is particularly true on the inner (high #) tracks where
  66.       the bits are closer together. Write precompensation is a process in
  67.       which the position of the bits is shifted during writes to compensate
  68.       for the natural "wandering" of the bits. As Kevin Darling mentioned
  69.       in his book "Inside OS9 Level II" (p 3-5-3), cc3disk never activates
  70.       the 1773's built in write precomp circuits. However, I found unused,
  71.       leftover code in cc3disk that is designed to activate write precomp.
  72.       Talk about skeletons in the closet! Perhaps future patches could
  73.       renable precomp on the inner tracks. A small improvement in read
  74.       relability could be realized especially by those using older drives.
  75.  
  76.  
  77.    4. If you are experiencing I/O errors with a MPI, especially with the
  78.       buffered mode of the SCII, try changing IC1 on the older MPI or IC2
  79.       on the newer MPI. These chips handle the E clock and some other signals.
  80.       I have seen a case in which a bad chip caused some of the address lines
  81.       to bounce with transitions of the E clock -> bad news!
  82.  
  83.  
  84.   5. The owner's manual of my Disto SCII has a mistake in table 2. The 
  85.      register addresses are listed backwards. Here's the corrections:
  86.  
  87.      Table 2 - SCII registers
  88.  
  89.          Location                            Description
  90.        Hex    Dec
  91.  
  92.       FF77   65399                 FF76 mirror
  93.  
  94.       FF76   65398                 write: D0 = 0 FDC write operation *1
  95.                                              = 1 FDC read operation *1
  96.                                           D1 = 0 normal mode
  97.                                              = 1 buffered mode
  98.                                           D2 = 0 normal NMI
  99.                                              = 1 masked NMI
  100.                                           D3 = 0 no FIRQ (masked)
  101.                                              = 1 FIRQ enabled
  102.                                    read:  D7 = FDC INTRQ status (inverted)
  103.  
  104.       FF75   65397                 FF74 mirror
  105.       FF74   65396                 Read/Write buffer *2
  106.  
  107.  
  108.       *1: In the buffered mode.
  109.       *2: Any write to $FF76 or $FF77 clears the buffer counter.
  110.       
  111.       Note that the data buffer mirror allows std and ldd for pseudo
  112.       16 bit transfers.
  113.  
  114.  
  115.    Also, there are a few corrections needed to the SCII schematic set:
  116.  
  117.    On V1.3:
  118.  
  119.       a. There should be an inverter in series with the line that leads
  120.          to the counter (between pin 18 of U6 and pin 1 of U7). This is
  121.          the small "hack" that you see on the "wrong" side of the PC board
  122.          near the CoCo connector.
  123.     
  124.       b. The address line pins of U6 should read: 1,3,5,7,2,4,6,8 not
  125.          8,7,6,5,4,3,2,1 as given.
  126.  
  127.    On V1.4:
  128.  
  129.       c. Pin 1 of U8 should be shown connected to GND not VCC.
  130.  
  131.    On both versions:
  132.  
  133.       d. Pin 10 of U8 connects to pin 12 of U13, NOT to pin 13 of U13.
  134.  
  135.  
  136.    6. Concerning GIME S0-S2 hacks: Four signals are produced by IC9 on the
  137.       CoCo3 motherboard. They are SCS (which helps decode I/O devices),
  138.       CTS (which turns on the cartridge ROM), ROM (which turns on the
  139.       motherboard ROM), and the signal which decodes the PIAs which I'll
  140.       call PIA. These signals belong to two different groups.
  141.  
  142.           a. Address Decoding Signals (ADS). SCS and PIA belong to this
  143.              group. These signals are used in conjunction with the address
  144.              lines to decode an address. The E clock is then used to actually
  145.              turn on the device.
  146.  
  147.           b. Chip Select Signals (CSS). CTS and ROM belong to this group.
  148.              When these signals are active, the devices turn on regardless
  149.              of the E clock.
  150.  
  151.      The problem many hackers see with all this is that CTS and ROM do not
  152.      APPEAR to be gated with E (unless the GIMEs do this internally). So, a
  153.      ROM device could start outputting junk onto the data bus without checking
  154.      E. Since ROMs tend to be a bit slow, this could cause a collision on the
  155.      data bus. The result is a BLOB causer.
  156.         As a solution, many hackers rigged U9 so that ALL FOUR signals were
  157.      gated with the E clock. This is fine and well for CTS and ROM, but I
  158.      don't think this is a good idea for SCS and PIA. The ADS signals
  159.      should be stable BEFORE E becomes high in order to give the address
  160.      decoding logic enough time to stablize prior to E becoming high. If
  161.      SCS changes with E, a logic race condition could occur in some CoCo
  162.      accessories. This could cause I/O glitches.
  163.         So, I suggest that any E gating hacks should be confined to CTS and
  164.      ROM. A 74LS157 (or 74ACT157 if you want the best) should do the job
  165.      nicely (E clk to A/B select; A inputs go to VCC; B inputs go to CTS and
  166.      ROM; outputs are new, gated CTS and ROM).
  167.         Since CTS is hardly ever used under OS9, but ROM is used for every
  168.      interrupt, you can try a simpler hack that affects the ROM on the
  169.      motherboard only. Using an inverter, make an inverted E clock and then
  170.      route this signal to pin 22 (OE, active low) of the ROM. Be sure and
  171.      remember to cut the trace that currently grounds pin 22.
  172.         As a final note, all of this address decoding appears to have been
  173.      done correctly with the SAM chip in the CoCo2. However, without knowing
  174.      how the GIME generates S0-S2, we can't be sure that it is done correctly
  175.      in the CoCo3. Note that the GIME probably does SOME additional
  176.      processing of these signals. For example, R/W is probably taken into
  177.      account to prevent the CPU from trying to write to a ROM and thereby
  178.      creating the mother of all bus collisions. If the GIME does indeed
  179.      consider E and R/W properly in developing S0-S2, then no hack should
  180.      be needed at all. Gating SCS with E, as most "improper" hacks do, delays
  181.      the enable of the 1773 chip by a few nanoseconds. This could affect
  182.      the 1773 BLOB problem. Thus, many S0-S2 hacks may appear to fix GIME
  183.      problems, when in fact, the 1773 was the problem all along.
  184.         Time spent with a logic analyzer could settle this issue once and
  185.      for all. 
  186.  
  187.      
  188. -----------------------------------------------------------------------------
  189.  
  190.  
  191.    Well, I hope this stuff helps somebody out there. Happy CoCoing!
  192.  
  193.  
  194.                                                    Michael Shell
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.     
  206.          
  207.