home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frozen Fish 1: Amiga
/
FrozenFish-Apr94.iso
/
bbs
/
alib
/
d6xx
/
d698
/
scram500.lha
/
SCRAM500
/
SCRAM500.lzh
/
docs
/
design.doc
< prev
next >
Wrap
Text File
|
1992-06-20
|
12KB
|
269 lines
DESIGN PHILOSOPHY
=================
Some years ago I designed a product for the Amiga which was a very
simple 2 Meg RAM board for the A500/A1000. I was amazed at the success
of this little project and decided to do a sequel with more features -
but still simple and cheap.
8 Megs of RAM and an AutoBooting SCSI controller with an upgrade path to
an '030 seemed like a reasonable design goal. This should all fit in a
box no higher than the A500, and still allow you to pick up the Amiga
without disconnecting the unit. The PCB would be a cheap double sided
affair - no multi layer and no surface mount - to make assembly simple.
To put all this on a small board would require extensive use of
minimalism and GALs. What eventually came out of this was the SCRAM 500.
CASE
====
I think we must conclude that Commodore planned mischief when they
designed the Amiga 500 Expansion Slot. This is apparent in the A590 and
various other appendages which sprout from the left side of the machine.
I don't think it is possible to make a box for the side of the A500
which really looks good. Who knows what they had in mind when they
drew it up. Hey Guys - Let's put the slot here and watch them get
something onto that!
The SCRAM 500 lives in an unassuming, dignified rectangular extrusion -
sturdy if nothing else - which pays no mind to bevelled snouts and mock
plastic ribs and fins. True, it has been compared rather cruelly to a
milk carton, but the extrusion provides good RFI shielding and
simplifies assembly - the PCB with front and back just slides into the
extrusion and is held by 2 screws.
The extrusion is wide enough to fit 2 cards. There is a companion card
(which I am currently developing) with an '030 , 68882 and 8Megs of 32
bit wide RAM which can go in the case with the SCRAM board. I think this
will make quite a desirable little expansion box for the Amiga 500.
AUTOCONFIG
==========
The SCRAM 500 AutoConfigures as two boards - a 2/4/8 Meg RAM card and a
SCSI interface card. These cards (notionally two - physically one)have
their own product number and so on. The BERTIE Chip does most of the
AutoConfig work by providing the sequences of config nibbles to the
Amiga. The 74F521 (U19) initially decodes the AutoConfig space (E80000)
via the R-NETS, and later decodes the IO base offset latched into U24.
AutoConfig is inhibited by CFIN\ into U17A being high. At the end of the
AutoConfig sequence the signal CFGO\ (Config Out for next board) is
latched and also drives the "ACTIVE" LED on the front panel. This LED
indicates that the Amiga has interrogated the SCRAM 500, found
everything in order and included it in the IO board list. This is a very
useful LED. It will immediately extinguish on reset, and only come on
after a good config procedure.
Note that BERTIE looks at the RAM SIZE jumpers JP1, JP2 to tell the Amiga
how much RAM is available (0/2/4/8 Meg). There is no latch for the RAM
base offset, as it is assumed all the available 8Meg space is available.
The Amiga always allocates RAM from 200000 onwards. If you want to put
some other RAM in the space, partially populate the RAM array (2/4 Meg).
Even though the full 8 Meg space is decoded, the missing RAM chips can
not drive the data bus, so something else can. You will get the odd wait
state inserted by the refresh logic, but that is all.
PASS-THROUGH (PASS-THRU for non-English)
============
The SCRAM 500 supports pass-through! So you don't have to forget CDTV
and other devices. You may have the left side of your Amiga festooned
with all manner of chunky boxes.
If you install the pass-thru option, the SCRAM 500 generates a ConfigOut
signal for daisy-chaining to subsequent boards. Solder a jumper from pin
12 on the pass-thru connector to pin 11 on the SCRAM PCB. This will
allow AutoConfigOut to daisy-chain on to the next device. The case has a
hatch to allow access for pass-thru.
Be warned however, pass-thru can be a pain-in-the-pass-thru. You are
connecting lots of things to the raw 68000 bus, so loading and noise can
cause trouble. You are also relying on every device to follow the rules
of AutoConfig. The SCRAM 500 will always configure RAM at 200000 and if
you are using 4 Meg DRAMs then it will insert the odd wait state
anywhere in the 8Meg RAM expansion space. These things are determined by
the GALs, so if there is a conflict for some other expansion device it
is possible to fix it.
I would recommend a HC68000 device in your Amiga if you are determined
to pass-thru. This should give you cleaner signals with better noise
immunity. Good luck.
RAM ARRAY
=========
The SCRAM 500 uses ZIP DRAMs in the RAM section. As you can see from the
PCB overlay, there are 16 ZIP locations in the top front corner of the
board. You can use either 1Meg (256Kx4) chips or 4Meg (1Mx4 chips) as
they are pin compatible. The standard BERTIE chip only allows for 2/4/8
Meg, so partial population with the older 256Kx4 RAMs is not possible.
These days 2 Meg is pretty cheap, so I can't see that much call for less
than 2 Megs. Using 4 Meg chips the minimum configuration is just 4 ZIPs
for 2 Megs!
You will notice that the RAM circuit does not use buffers. The design
goal for the SCRAM 500 was small and simple - which didn't really allow
room for buffers. A few years ago I designed a 2Meg RAM board for the
Amiga using a similar circuit. Nearly 10,000 of these boards were made
and functioned reliably. What I did discover was that some (most?) Amiga
500s don't have pullups on their data bus. There are holes there for
them, but they aren't populated. When the SCRAM 500 was being debugged
it was observed that with NO RAM installed, the SCSI interface was prone
to errors during long transfers. Plugging RAM in fixed the problem -
which seemed to indicate that the Amiga 68000 was prone to noise on the
data bus. 10K pullups installed on the 68K data bus fixes the noise
problem - I think they should be on the Amiga 500 main board as
standard.
RAM CONTROLLER
==============
The RAM controller is probably the most complex section of the SCRAM
500. U20 - U22 (LS257) are address multiplexors which switch the bus
address to RAS and CAS addresses. GRISWOLD is the main timing generator
which converts a 68000 cycle into RAS and CAS cycles, and inserts a
refresh cycle every 16uS or so. HUMPHREY converts memory addresses into
Bank RAS pulses, accomodates 1M/4M chips and handles CPU XRDY Timing.
The HCT393 counter (U26A) divides the CPU E clock by 12 to give the
refresh rate.
The SCRAM design uses CAS before RAS refresh for the DRAMs. This is an
economical design because you don't need a refresh address counter - the
DRAMS have this built in. GRISWOLD generates a RDY signal to hold off
any 68000 cycle which starts whilst a refresh cycle is in progress.
Pushing most of the DRAM control functions into GRISWOLD and HUMPHREY
results in a simple, compact design. This modular design is also easy to
fix. The LS257 chips are pretty tough - I don't think anyone could blow
them up - which leaves GRISWOLD, HUMPHREY, and the RAM chips (all
socketed). If you poke around this circuit with a scope, you will soon
see what is going on.
SCSI INTERFACE
==============
If you look at the SCSI controller schematic (sheet 2 of 3), you will
see it is also very simple! CYRIL 8, DP8490, Terminators and SCSI
connector, yet this interface returns DiskSpeed results of over
500KB/sec with a standard Amiga and well over 1Mb/sec in an 030 machine.
The key to this compact design is using a single PLD (CYRIL 8) to handle
all the glue functions for the SCSI chip. This includes address decode,
LED controller, BOOT ROM mapping, interrupt and DMA synchronization.
The data transfer method used in the SCRAM is known as DTACK
SYNCHRONIZATION. A lot of designers use it - I first saw it in a
Motorola APP NOTE. All it does is delay 68000 bus cycles until the SCSI
chip has the next byte to send. In general, this is not a good idea for
any DMA device, but for high speed block orientated things like SCSI, it
is fine. The only thing about this type of interface is you need tight,
optimized code to make it perform.
The alternative to DTACK SYNCHRONIZATION is a DMA CONTROLLER like
Commodore uses. DMA is far more complex to design, and uses up a lot
more board space - unless you have access to Gate Array technology. The
advantages of DMA are not that apparent to a user, and for an Amiga 500
system hardly justify the additional cost and complexity. Anyway, I like
minimal designs.
PROGRAMMING MODEL for the SCSI CONTROLLER
=========================================
The SCSI part of the SCRAM 500 AutoConfigs as a separate PIC from the
RAM controller. This section comes up as a 64K IO device with a
switchable vector to ROM boot code. The SCRAM will usually be the only
AutoConfig device attached, and so the IO block will be allocated offset
E90000, directly after the AutoConfig space of E80000.
Memory Map
-----------------
| |
| Boot ROM |
| |
----------------- C000h
| |
| Pseudo DMA |
| Data Transfer |
----------------- 8000h
| SCSI Registers |
----------------- 6000h
| Set LED ON |
----------------- 4000h
| |
| Boot ROM |
| |
----------------- 0000h <-- Offset int0 64K IO space (E90000)
0000 - 3FFF BOOT ROM available in even bytes.
4000 - 5FFF Write in this space sets LED on.
6000 - 7FFF SCSI chip in even addresses. Clears the LED
8000 - 9FFF Direct data access (even bytes)
C000 - FFFF BOOT ROM available in even bytes
The BOOT ROM is available at both 0000h and C000h in the IO space at
even addresses. This is the driver code which is read in by KickStart at
Boot time.
The SCSI chip is located at offset 6000h in the IO space. Only even
locations, so valid addresses are 6000h, 6002h, 6004h, 6006h, 6008h,
600Ah, 600Ch and 600Eh.
To set the LED on, perform a write to location 4000h in the IO space.
The LED is cleared by any access to the SCSI chip (6000h).
The SCRAM 500 supports a Direct Data mode of transfer to improve disk
throughput. The direct data access mode is a form of psuedo DMA. Instead
of hardware doing the data transfer, Data is read or written by
accessing location 8000h which - via CYRIL 8 - directly accesses the DMA
port on the SCSI chip.
CYRIL 8 automatically synchronizes the 68000 to the SCSI controller DMA
Channel via DRQ and XRDY so you don't have to do any status checking.
Just read or write. The routine which does this transfer should really
be organized as a block sized subroutine (512 bytes). Between blocks you
should check status to ensure there is a valid REQ\ from the device.
This is because if you initiate the block transfer (access 8000h) with
no DRQ pending, the 68K will be held off indefinitely by XRDY. If there
is no data pending from the SCSI controller, or the SCSI terminates
unexpectedly, then the system could hang. Make sure that if you ever
access 8000h (Direct Data access) you know FOR SURE you have a data
block waiting for you with DRQ active.
The unpleasant situation mentioned above is affectionately known as a
"DTACK hang". CYRIL 8 has a failsafe mechanism buit in to protect
against non-self-inflicted DTACK hangs caused by unforseen terminations
in the SCSI chip. If the SCSI Interrupt is set, this signal disables
DTACK synchronization - releasing a DTACK hang. Otherwise, the interrupt
is passed straight to the Amiga from the SCSI chip as INT2\.
You can use any programming technique to minimise the overheads of
hauling in the data from 8000h. The best method is probably to use MOVEP
IO accesses and long word transfers. Do a cycle count and you will find
it is possible to get a 33% increase in throughput. Also note that low
address lines are not used in decoding the 8000h space, so 8000, 8002,
8004 etc. will all work so you could treat the Direct Data space as a
block of 512 WORDS, where the even BYTES are valid data.
Norman Jackson
Plumbago Ridge Design Studio
P.O. Box 98
TABULAM
NSW 2470
Australia
EMAIL normj@runx.oz.au