home *** CD-ROM | disk | FTP | other *** search
/ Otherware / Otherware_1_SB_Development.iso / amiga / info / scram_50.lzh / SCRAM500.lzh / docs / design.doc < prev    next >
Encoding:
Text File  |  1992-06-20  |  11.9 KB  |  269 lines
  1. DESIGN PHILOSOPHY
  2. =================
  3.  
  4. Some years ago I designed a product for the Amiga which was a very
  5. simple 2 Meg RAM board for the A500/A1000. I was amazed at the success
  6. of this little project and decided to do a sequel with more features -
  7. but still simple and cheap.
  8.  
  9. 8 Megs of RAM and an AutoBooting SCSI controller with an upgrade path to
  10. an '030 seemed like a reasonable design goal. This should all fit in a
  11. box no higher than the A500, and still allow you to pick up the Amiga
  12. without disconnecting the unit. The PCB would be a cheap double sided
  13. affair - no multi layer and no surface mount - to make assembly simple.
  14. To put all this on a small board would require extensive use of
  15. minimalism and GALs. What eventually came out of this was the SCRAM 500.
  16.  
  17.  
  18. CASE
  19. ====
  20.  
  21. I think we must conclude that Commodore planned mischief when they
  22. designed the Amiga 500 Expansion Slot. This is apparent in the A590 and
  23. various other appendages which sprout from the left side of the machine.
  24. I don't think it is possible to make a box for the side of the A500
  25. which really looks good. Who knows what they had in mind when they
  26. drew it up. Hey Guys - Let's put the slot here and watch them get
  27. something onto that!
  28.  
  29. The SCRAM 500 lives in an unassuming, dignified rectangular extrusion -
  30. sturdy if nothing else - which pays no mind to bevelled snouts and mock
  31. plastic ribs and fins. True, it has been compared rather cruelly to a
  32. milk carton, but the extrusion provides good RFI shielding and
  33. simplifies assembly - the PCB with front and back just slides into the
  34. extrusion and is held by 2 screws.
  35.  
  36. The extrusion is wide enough to fit 2 cards. There is a companion card
  37. (which I am currently developing) with an '030 , 68882 and 8Megs of 32
  38. bit wide RAM which can go in the case with the SCRAM board. I think this
  39. will make quite a desirable little expansion box for the Amiga 500.
  40.  
  41.  
  42.  
  43. AUTOCONFIG
  44. ==========
  45.  
  46. The SCRAM 500 AutoConfigures as two boards - a 2/4/8 Meg RAM card and a
  47. SCSI interface card. These cards (notionally two - physically one)have
  48. their own product number and so on. The BERTIE Chip does most of the
  49. AutoConfig work by providing the sequences of config nibbles to the
  50. Amiga. The 74F521 (U19) initially decodes the AutoConfig space (E80000)
  51. via the R-NETS, and later decodes the IO base offset latched into U24.
  52. AutoConfig is inhibited by CFIN\ into U17A being high. At the end of the
  53. AutoConfig sequence the signal CFGO\  (Config Out for next board) is
  54. latched and also drives the "ACTIVE" LED on the front panel. This LED
  55. indicates that the Amiga has interrogated the SCRAM 500, found
  56. everything in order and included it in the IO board list. This is a very
  57. useful LED. It will immediately extinguish on reset, and only come on
  58. after a good config procedure.
  59.  
  60. Note that BERTIE looks at the RAM SIZE jumpers JP1, JP2 to tell the Amiga
  61. how much RAM is available (0/2/4/8 Meg). There is no latch for the RAM
  62. base offset, as it is assumed all the available 8Meg space is available.
  63. The Amiga always allocates RAM from 200000 onwards. If you want to put
  64. some other RAM in the space, partially populate the RAM array (2/4 Meg).
  65. Even though the full 8 Meg space is decoded, the missing RAM chips can
  66. not drive the data bus, so something else can. You will get the odd wait
  67. state inserted by the refresh logic, but that is all.
  68.  
  69.  
  70. PASS-THROUGH (PASS-THRU for non-English)
  71. ============
  72.  
  73. The SCRAM 500 supports pass-through! So you don't have to forget CDTV
  74. and other devices. You may have the left side of your Amiga festooned
  75. with all manner of chunky boxes.
  76.  
  77. If you install the pass-thru option, the SCRAM 500 generates a ConfigOut
  78. signal for daisy-chaining to subsequent boards. Solder a jumper from pin
  79. 12 on the pass-thru connector to pin 11 on the SCRAM PCB. This will
  80. allow AutoConfigOut to daisy-chain on to the next device. The case has a
  81. hatch to allow access for pass-thru.
  82.  
  83. Be warned however, pass-thru can be a pain-in-the-pass-thru. You are
  84. connecting lots of things to the raw 68000 bus, so loading and noise can
  85. cause trouble. You are also relying on every device to follow the rules
  86. of AutoConfig. The SCRAM 500 will always configure RAM at 200000 and if
  87. you are using 4 Meg DRAMs then it will insert the odd wait state
  88. anywhere in the 8Meg RAM expansion space. These things are determined by
  89. the GALs, so if there is a conflict for some other expansion device it
  90. is possible to fix it.
  91.  
  92. I would recommend a HC68000 device in your Amiga if you are determined
  93. to pass-thru. This should give you cleaner signals with better noise
  94. immunity. Good luck.
  95.  
  96.  
  97.  
  98. RAM ARRAY
  99. =========
  100.  
  101. The SCRAM 500 uses ZIP DRAMs in the RAM section. As you can see from the
  102. PCB overlay, there are 16 ZIP locations in the top front corner of the
  103. board. You can use either 1Meg (256Kx4) chips or 4Meg (1Mx4 chips) as
  104. they are pin compatible. The standard BERTIE chip only allows for 2/4/8
  105. Meg, so partial population with the older 256Kx4 RAMs is not possible.
  106. These days 2 Meg is pretty cheap, so I can't see that much call for less
  107. than 2 Megs. Using 4 Meg chips the minimum configuration is just 4 ZIPs
  108. for 2 Megs!
  109.  
  110. You will notice that the RAM circuit does not use buffers. The design
  111. goal for the SCRAM 500 was small and simple - which didn't really allow
  112. room for buffers. A few years ago I designed a 2Meg RAM board for the
  113. Amiga using a similar circuit. Nearly 10,000 of these boards were made
  114. and functioned reliably. What I did discover was that some (most?) Amiga
  115. 500s don't have pullups on their data bus. There are holes there for
  116. them, but they aren't populated. When the SCRAM 500 was being debugged
  117. it was observed that with NO RAM installed, the SCSI interface was prone
  118. to errors during long transfers. Plugging RAM in fixed the problem -
  119. which seemed to indicate that the Amiga 68000 was prone to noise on the
  120. data bus. 10K pullups installed on the 68K data bus fixes the noise
  121. problem - I think they should be on the Amiga 500 main board as
  122. standard.
  123.  
  124.  
  125. RAM CONTROLLER
  126. ==============
  127.  
  128. The RAM controller is probably the most complex section of the SCRAM
  129. 500. U20 - U22 (LS257) are address multiplexors which switch the bus
  130. address to RAS and CAS addresses. GRISWOLD is the main timing generator
  131. which converts a 68000 cycle into RAS and CAS cycles, and inserts a
  132. refresh cycle every 16uS or so. HUMPHREY converts memory addresses into
  133. Bank RAS pulses, accomodates 1M/4M chips and handles CPU XRDY Timing.
  134. The HCT393 counter (U26A) divides the CPU E clock by 12 to give the
  135. refresh rate.
  136.  
  137. The SCRAM design uses CAS before RAS refresh for the DRAMs. This is an
  138. economical design because you don't need a refresh address counter - the
  139. DRAMS have this built in. GRISWOLD generates a RDY signal to hold off
  140. any 68000 cycle which starts whilst a refresh cycle is in progress.
  141.  
  142. Pushing most of the DRAM control functions into GRISWOLD and HUMPHREY
  143. results in a simple, compact design. This modular design is also easy to
  144. fix. The LS257 chips are pretty tough - I don't think anyone could blow
  145. them up - which leaves GRISWOLD, HUMPHREY, and the RAM chips (all
  146. socketed).  If you poke around this circuit with a scope, you will soon
  147. see what is going on.
  148.  
  149.  
  150. SCSI INTERFACE
  151. ==============
  152.  
  153. If you look at the SCSI controller schematic (sheet 2 of 3), you will
  154. see it is also very simple! CYRIL 8, DP8490, Terminators and SCSI
  155. connector, yet this interface returns DiskSpeed results of over
  156. 500KB/sec with a standard Amiga and well over 1Mb/sec in an 030 machine.
  157. The key to this compact design is using a single PLD (CYRIL 8) to handle
  158. all the glue functions for the SCSI chip. This includes address decode,
  159. LED controller, BOOT ROM mapping, interrupt and DMA synchronization.
  160.  
  161. The data transfer method used in the SCRAM is known as DTACK
  162. SYNCHRONIZATION. A lot of designers use it - I first saw it in a
  163. Motorola APP NOTE. All it does is delay 68000 bus cycles until the SCSI
  164. chip has the next byte to send. In general, this is not a good idea for
  165. any DMA device, but for high speed block orientated things like SCSI, it
  166. is fine. The only thing about this type of interface is you need tight,
  167. optimized code to make it perform.
  168.  
  169. The alternative to DTACK SYNCHRONIZATION is a DMA CONTROLLER like
  170. Commodore uses. DMA is far more complex to design, and uses up a lot
  171. more board space - unless you have access to Gate Array technology. The
  172. advantages of DMA are not that apparent to a user, and for an Amiga 500
  173. system hardly justify the additional cost and complexity. Anyway, I like
  174. minimal designs.
  175.  
  176.  
  177.  
  178. PROGRAMMING MODEL for the SCSI CONTROLLER
  179. =========================================
  180.  
  181. The SCSI part of the SCRAM 500 AutoConfigs as a separate PIC from the
  182. RAM controller. This section comes up as a 64K IO device with a
  183. switchable vector to ROM boot code. The SCRAM will usually be the only
  184. AutoConfig device attached, and so the IO block will be allocated offset
  185. E90000, directly after the AutoConfig space of E80000.
  186.  
  187. Memory Map
  188.  
  189.            -----------------
  190.        |                 |
  191.        |    Boot ROM     |
  192.        |                 |
  193.         -----------------   C000h
  194.        |                 |
  195.           |  Pseudo DMA     |
  196.        |  Data Transfer  |
  197.         -----------------   8000h
  198.           |  SCSI Registers |
  199.         -----------------   6000h
  200.           |  Set LED ON     |
  201.         -----------------   4000h
  202.        |                 |
  203.        |    Boot ROM     |
  204.        |                 |
  205.            -----------------   0000h <-- Offset int0 64K IO space (E90000)
  206.  
  207.  
  208. 0000 - 3FFF      BOOT ROM available in even bytes.
  209. 4000 - 5FFF      Write in this space sets LED on.
  210. 6000 - 7FFF      SCSI chip in even addresses. Clears the LED
  211. 8000 - 9FFF      Direct data access (even bytes)
  212. C000 - FFFF      BOOT ROM available in even bytes
  213.  
  214. The BOOT ROM is available at both 0000h and C000h in the IO space at
  215. even addresses. This is the driver code which is read in by KickStart at
  216. Boot time.
  217.  
  218. The SCSI chip is located at offset 6000h in the IO space. Only even
  219. locations, so valid addresses are 6000h, 6002h, 6004h, 6006h, 6008h,
  220. 600Ah, 600Ch and 600Eh.
  221.  
  222. To set the LED on, perform a write to location 4000h in the IO space.
  223. The LED is cleared by any access to the SCSI chip (6000h).
  224.  
  225. The SCRAM 500 supports a Direct Data mode of transfer to improve disk
  226. throughput. The direct data access mode is a form of psuedo DMA. Instead
  227. of hardware doing the data transfer, Data is read or written by
  228. accessing location 8000h which - via CYRIL 8 - directly accesses the DMA
  229. port on the SCSI chip.
  230.  
  231. CYRIL 8 automatically synchronizes the 68000 to the SCSI controller DMA
  232. Channel via DRQ and XRDY so you don't have to do any status checking.
  233. Just read or write. The routine which does this transfer should really
  234. be organized as a block sized subroutine (512 bytes). Between blocks you
  235. should check status to ensure there is a valid REQ\ from the device.
  236. This is because if you initiate the block transfer (access 8000h) with
  237. no DRQ pending, the 68K will be held off indefinitely by XRDY. If there
  238. is no data pending from the SCSI controller, or the SCSI terminates
  239. unexpectedly, then the system could hang. Make sure that if you ever
  240. access 8000h (Direct Data access) you know FOR SURE you have a data
  241. block waiting for you with DRQ active.
  242.  
  243. The unpleasant situation mentioned above is affectionately known as a
  244. "DTACK hang". CYRIL 8 has a failsafe mechanism buit in to protect
  245. against non-self-inflicted DTACK hangs caused by unforseen terminations
  246. in the SCSI chip. If the SCSI Interrupt is set, this signal disables
  247. DTACK synchronization - releasing a DTACK hang. Otherwise, the interrupt
  248. is passed straight to the Amiga from the SCSI chip as INT2\.
  249.  
  250. You can use any programming technique to minimise the overheads of
  251. hauling in the data from 8000h. The best method is probably to use MOVEP
  252. IO accesses and long word transfers. Do a cycle count and you will find
  253. it is possible to get a 33% increase in throughput. Also note that low
  254. address lines are not used in decoding the 8000h space, so 8000, 8002,
  255. 8004 etc. will all work so you could treat the Direct Data space as a
  256. block of 512 WORDS, where the even BYTES are valid data.
  257.  
  258.  
  259. Norman Jackson
  260.  
  261. Plumbago Ridge Design Studio
  262. P.O. Box 98
  263. TABULAM
  264. NSW     2470
  265. Australia
  266.  
  267. EMAIL normj@runx.oz.au
  268.  
  269.