nessus@nsc.UUCP (Kchula-Rrit) (08/02/84)
[With such a weapon I could boil Earth to vapor.]
[With such a weapon I could boil Earth to vapor.]
My article requesting info on how to reduce the TV interference my
homebrew RAM expansion makes didn't get too many ideas on how to deal with
the interference, but a number of people asked me how I homebrewed the board.
I thought the net may be interested; this may generate some traffic in this
newsgroup.
First, a little background info. The overall memory map looks like this:
0000->1FFF Console ROM
2000->3FFF *** EXPANSION RAM LOW BANK ***
4000->5FFF Device Service Routine Space
6000->7FFF Cartridge access
8000->9FFF CPU RAM, Video&Speech Access
A000->FFFF *** EXPANSION RAM HIGH BANK ***
I have highlighted the address spaces that we are concerned with(*** ***).
The problem is to make non-contiguous address spaces appear contiguous to the
Expansion Memory Board(EMB). My solution was to take a 74S288 32x8 PROM and
use it as a decoder/address translator. The address inputs to the PROM are
like this:
PROM TI Signals
Address
A4 A0
A3 A1
A2 A2
A1 MEMEN
A0 Grounded
The chip-select signals are then taken from the PROM outputs, which are
programmed accordingly. You may also wish to use another PROM to generate
signals to enable a buffer to send data to/from the console. My set-up looks
like this:
------------- ---------- ---------- -----------
| RAM ARRAY | | | | | | |
| +==+ BUFFER +=====> >=====+ BUFFER +==+ CONSOLE |
| +==+ +=====> >=====+ +==+ |
| | | | ^ ^ | | | |
------------- ---------- Ribbon ---------- -----------
Cable
The reason two buffers are necessary is that the data bus connector is
connected directly to the CPU data pins!! The tech manual recommends that
a buffer be installed between the console connector and the interface cable
(I can see why!). The buffer must be enabled ONLY WHEN THE EMB IS BEING
ACCESSED!! Otherwise the EMB will walk all over the data bus, messing up
accesses to other parts of the machine. I also programmed my PROM to enable
the buffer at accesses to 4000->5FFF(Device Driver Space) because I am going
to be adding my own printer,RS232,disks, etc. I wired a 8255 PIO chip to
5000 and am writing a driver program to drive a TRS-80 Color Graphic-Printer
(Pseudo-Centronics/subset). My Driver PROM will be at 4000, and is turned
on & off by the CRU select signals. Anyway I digress...
A WORD OF WARNING!!!!! I FOUND OUT THE HARD WAY.
A0 is the MOST SIGNIFICANT address bit.
D0 is the MOST SIGNIFICANT data bit.
EVEN BYTE is the MOST SIGNIFICANT byte.
ODD BYTE is the LEAST SIGNIFICANT byte.
The first item in the list I read on a data sheet. The others I learned
in the course of building/testing/programming the EMB and printer driver.
In the [disk-based]Editor/Assembler Manual, there is a section titled "Number
Systems and Memory Organization". Having been a hardware type for ~6.5 years,
I passed over this section, because I "knew" what would be in there: an
explanation on the Hex number system for computer novices. Boy, what a
mistake! The four items above were in that section. If anyone out there
homebrews a EMB&peripherals, please heed the advice of one who has trod the
path before! It took me a 7+days to figure out why my stuff would'nt work.
This is turning into a flame against TI, so I should stop.
To those of you who dare, good luck!
Kchula-Rrit
!menlo70!nsc!nessus
P.S. With all the discussion about copyrights&patents a few months ago, I
hope this doesn't violate anyone's copyrights/patents.