FRANCES 32-bit Memory Board  By Brad Fowles and Eric Haberfellner

Back in the December,1988 issue of Transactor I published an article on a public domain hardware project for an asyncronous design, 68020/68881 accelerator board called, "LUCAS". Well, now I'd like to introduce you to, "FRANCES". (Fast Ram At Nominal Cost, for Extended Storage).

Frances is a 32-bit wide memory board which fits onto the expansion connector of the LUCAS board. The focus of the article will describe the memory system as it relates to LUCAS board and the Amiga. You should read the original LUCAS article for a more complete understanding of the project as a whole. The purpose of this project is again to upgrade the performance of the A1000, while spending the minimum amount of cash. The raw compute power of the LUCAS-FRANCES combination is pretty impressive, however you should remember that the A1000 is an orphaned machine which is no longer supported by Commodore.  With the addition of the memory board it will truely make your Amiga 1000 a full 32-bit platform running at clock speeds from 16 to 20 Megahertz. As with the LUCAS board I will make available a bare board, 2 PALS, hardcopy schematic, and documentation disk for $75.00 U.S. ( See the end of the article for where to write). If you've got the urge to hack, or like me, just can't afford a full blown 2500 this project will tweek a wee bit more life out of the A1000.

I should state my bias right upfront. My real interest in the Amiga is as an experimental platform for 3D character animation. My needs therefore are for raw compute power and the project shows this bias.

Before we get into details let me thank all of you who participated in an experiment in public domain hardware. To date I have sent out 550 LUCAS boards. Some of you had problems with the project, and a few had no luck at all, but judging by the mail I receive most of you seemed to get the project up and running and were able to improve the performance of the A1000. Now we are going to see if we can make the grand ol'lady fly. 

Eric Haberfellner who is co-authoring this article with me not only wrote the AFM memory utility and all the diagnostic software to help me design the system, but stayed up all those long nights helping get the system working. I thank him for all his past work and all the answers he'll be giving to you folks when the time comes. My only complaint is that he and his brother slowed down the development of the first running prototype by booting up with FA/18 whenever my back was turned. By the way, at 20 meg the FA/18 demo runs in a little under 3 min. compared to 5 min 34 sec. on a stock Amiga

The thing that really kept the project going was the support you all gave to each other. I was constantly heartened by calls from local user group hardware guru's who were helping their friends get there systems up. LUCAS, is by no means perfect. There were problems with some peripherals, bus noise problems, and the now famous, selection of U9, but with a true hacker spirit most of you found a way to sort out the problems, and hopefully learned a little along the way. 

In the original article I said that the main benefit of having an '020 in your machine was that it provided a 32 bit wide upgrade path. Up till now the only 32-bit data transfers were those which were happening between the 68881 and the '020. This was great for floating point math but really did little for general purpose computing. All memory transfers were still only 16 bits wide. What we really needed was a 32 bit wide memory system to support the '020.

Design Criteria

The first decision is how much memory do we need. All we can get, right? I wanted to keep the board to a form factor which would be able to sit in the A1000 and still be able to put the case on. I didn't want to use those wonderful little SIMM modules as they can be hard to find, and can be quite expensive in small quantities. I looked at the space available and decided that I could put 4 megabytes of standard 20 pin DIP memory chips without too much problem. Next how fast? I priced out static memory fast enough to operate with no wait states, back in February '89 the price would have been $1200.00 per megabyte. So, O.K. we'll forget about that, what about DRAMS. At $25.00 per chip, that's $200.00 per megabyte. (at the time of writing this prices have dropped to $19.00 U.S. per chip) that seemed a little more reasonable. 1 meg. by 1 chips are slightly cheaper than 256K by 4 chips but with 1 meg. by 1 chips you would need to buy 32 chips right off. If I used 256K by 4 chips you could start out with 8 chips (1 megabyte) and build up in one meg. increments. Yeah! Better to do it that way. Keeping price in mind how fast should the memory be? It turns out that 100 ns. DRAMS will operate at 16 megahetz with only one wait state and at 20 megahertz with two. Even if we were to use 70 ns. DRAMS the same number of wait states would be required. Keeping these trade offs in mind I decided that 256K by 4 100ns. DRAMS were the best choice, but check the price of 70 ns. parts the differance may be negligable.
 
How will does the change from 16 to 20 megahertz clock speed effect performance? The '020 has a three cycle access. At 16 megahertz that's 3 X 62.5 ns. plus one wait state of 62.5 ns. equals 250 ns. total. At 20 megahertz its 3 X 50 ns. plus two wait states of 50 ns. equals, let's see uh, 250 ns. Hmmmmmmm! At either 16 or 20 megahertz the effective memory speed will be equal. Ofcourse, at 20 megahertz the transfers between the '881 and the '020 will be 1.25 times faster as will all the internal register stuff in the '020 itself. It is possible that running at 18 megahertz with one wait state if you used 70 ns. DRAMS would yield the best performance, I haven't tested that, perhaps one of you can. 

Now we need to select a DRAM controller. I remember just a few short years ago designing DRAM control circuitry with a plethora of discrete components and delay lines. These days there is a wide variety of highly integrated controllers from which to choose. Due to the nature of the project I decided on a controller which could be soft programmed to accomadate various clock speeds and DRAM configurations, and maufacturerers. I also wanted a controller which could support memory interleaving, but more on that later. The best choice I believe is the Nationl 8421A-20 or -25. So with the controller and memory chosen and adding a bit of glue and a few buffers and we're almost there.
 
In order to squeeze all the performance we can out of the memory board it would be desirable to get all those routines which are in the KickStart area of memory out of 16-bit wide space and into 32-bit space. Since we don't have an MMU to do the address translations for us were going to have to do it some other way. To discribe how this was done it's time to go a little deeper into the technical details. If you know nothing of hardware, hang in there and I'll try to give enough background so that it should make sense.

Practising "Not Being Seen"

I assume you have read the article on the LUCAS board. When the '020 is doing an access to the '881, it does so at full speed and the data path is 32-bits wide. If the circuitry of the Amiga sees this access it will become quite confused and respond with a *DTACK (Data Transfer Acknowledge) long after the original cycle has gone by. To prevent this we simply don't tell Amy this is going on. This is accomplished by not asserting *AS (Adrress Strobe) or either of the two data strobes *UDS or *LDS (Upper Data Strobe, Lower Data Strobe). This is done in Pal U7 by conditioning the term for these signals with the *CPCS signal (Co-Processor Chip Select) non asserted state. In this way the '881 practises, "Not Being Seen" by the amiga system underneath it. The memory board has the same type of restrictions, because it is much faster than the normal Amiga memory we don't want her to try and respond to these faster accesses, so same answer, we don't let her know about them. In order to effect these clandestine accesses we take the *CS (Chip Select) signal from the FRANCES decode PAL and run it back to U7. It just so happens that the U7 Pal on the LUCAS board recieves two signals from the LUCAS expansion connector. They are the *SRDSACK0 and *SRDSACK1 (Static Ram Data Size Acknowledge). This was back before I realized the costs of high speed Static Ram. So I redefined these lines, The *SRDSACK0 line became the *FRANCYC (Frances Cycle) line and SRDSACK1 became *FDSACK (Frances DSACK). Only one *DSACK line is needed as the FRANCES pal takes care of the byte addressability and therefore assume all accesses are 32-bits wide without any penalty. We condition the terms for *AS, *UDS and *LDS with the *FRANCYC line in the same way as we did for the co-processor so the FRANCES memory practises, "Not Being Seen", so there are no conflicts with the AMIGA decode circuitry.

I started this out by talking about remapping KickStart into 32-bit space. The first thing we must know is that an access to KickStart memory is about to take place. The '020 initiates a cycle by putting the address on the bus and then asserts *AS to tell the system that the address is valid. At 16 Megahertz the address is valid 15 ns. before *AS is asserted. This is the amount of time we have to do our remapping. (For a little perspective, 15 ns. is the time it takes for light to travel approximately 15 feet.) KickStart resides at the addresses $FC0000 to $FFFFFF (it is also at $F80000 to FBFFFF). So if we decode any address in which the top five bits are 1's we know that this will be a KickStart access. If you look at the schematic you'll see that I used a 74F30, 8 input nand gate to do this. Now we take this signal that we will call *REMAPK and invert it, so we now have two low true signals, which are effectively, this is a KickStart access, and this is not a KickStart access. We add two address buffers between the '020 and the FRANCES memory controller, on the upper 6 bits of the address bus. Either buffer will now supply the top six bits of the address depending on whether or not this is a KickStart Access. If it is not than the "real" address is passed through, if it is than the contents of the Jumper block which selects where in FRANCES memory KickStart will reside, are supplied. We need only copy KickStart to the area defined by the jumper block and then tell the circuitry that it is O.K to begin remapping. We do this by setting a Flip-Flop which enables the 74F30 to begin decoding. There is no contention with the Amiga because any access to the FRANCES memory will assert the *FRANCYC signal and it will practise "Not Being Seen." Nifty Huh!

Addressing Scheme of FRANCES

While designing the board I did a very non-Amiga like thing. The FRANCES memory doesn't autoconfigure. Before you send somebody for a rope, listen to my reasons and the ways I've solved various problems and then send somebody for the rope. To keep the design as flexible as possible I used a highly programable DRAM controller, but ofcourse, it has to be programmed, not possible with autoconfiguring. We have this nifty KickStart remapping scheme but what about games which take over the system, by not autoconfiguring we've found a way so that these games can also take advantage of KickStart in 32-bit space. My good buddy Eric will describe in much greater detail how this is done a little later, which is only fair seeing he came up with the solutions to all the problems of not autoconfiguring.

While we are waiting for the guy with the rope to get back, let me give you the bad news. There is no provision on the FRANCES board to allow DMA transfers. There are three reasons I didn't include this. CopOut #1, this is a very knotty problem, it neccesitates that the memory look like 32-bit wide memory to the '020, but 16 bit wide memory to expansion connector. I had a paper design that grew in complication to the point where I realized that this beast was going to be very difficult to layout on the P.C.B. CopOut #2, there are very few DMA devices out there for the A1000 and I couldn't see delaying all those folks who have been emailing me wondering where the memory board for another 6 months while I solved the problem. CopOut #3 My dog ate the original paper design ... Honest teacher! 

FRANCES can be run in or out of the normal Amiga 24-bit address space. Most people have 2 megs of fast ram so if your running in amiga space the board will reside between $400000 and $7ffffff. This has the added feature of keeping the decode circuitry as simple as possible, if you want to run out of AMIGA Space, perhaps because you have more than 2 megs of fast Ram you can run the board from $40400000 $407fffff. I also used two other high address spaces. I used $80800000 as the address which controls the flip-flop to enable the KickStart remapping, called ERKS (Enable Ram KickStart) and $80400000 as the address to strobe the programming pin of the DRAM controller. The programming details of the DRAM controller are beyond the scope of this article. They are described on the documentation disk which comes with the FRANCES board or in the spec. sheets which are available from National. I should however describe how this programming is done. The DRAM controller doesn't have any data lines going to it so it must be programmed using the address bus. This is done by strobing a pin on the controller called *ML (ModeLoad) and placing the value to be put in the 23 bit programming register on the address bus.
 
Interleaving

There is another place that we can squeeze a little more performance out of the memory system. The memory array is in four banks of 1 meg each. If you have a full 4 megabytes installed than it is possible to interleave the memory accesses so as to shorten the access time. Under normal cercumstances the top two address bits, in this case A20 & A21 select which bank is active. If however instead of using the top two address bits we use the bottom two, A2 & A3 ( A0 & A1 along with the SIZ0 and SIZ1 are not used for memory addressing directly but are used by the PAL on the FRANCES board to allow byte addressability) then long word sequential accesses which are most common will happen on separate banks. This allows the DRAM controller to reduce the *RAS precharge time on the second access. This is a relatively small performance improvement which is highly application specific, but it was easy to do and didn't cost anything. If you only have 1, 2 or 3 Megs installed then ofcourse you cannot interleave the memory. There are jumpers on the FRANCES board to select this option.

The FRANCES board will take either a right angle or a strait 96 pin DIN connector to mate with the LUCAS board. The right angle connector is much more preferable than the straight one, and is the one I intended.  I forgot to specify in the original LUCAS docs that this was the case so I made the FRANCES board compatible with both. However, the form factor of the board is slightly differant for each of the two types of connectors. If you are ordering a FRANCES board make sure you indicate which type of connector you used. The FRANCES board is L shaped and takes up the rest of the room on the "second level". 
There are two power connectors on the FRANCES board. First you remove the power connector which goes from the power supply to the Amiga mother board.  This gets plugged into the FRANCES board and then you take another cable and bus the power connector back down to the mother board.

The FRANCES Memory Configuration Utility (AFM)

Since the FRANCES memory does not autoconfigure we were faced with the task of making it available to AmigaDOS.

The program usually used to add non-autoconfig RAM to AmigaDOS is the ADDMEM program written by Commodore-Amiga. There are however some problems with this program which make it a less than perfect utility for our purposes.

ADDMEM clears the memory that it adds to AmigaDOS when it is called. This makes it unsuitable for use with rebootable ram disks like ASDG's VD0: or AmigaDOS's RAD:, since it clobbers them.

ADDMEM is usually invoked by the S:Startup-Sequence script file which gets executed as AmigaDOS is booting. This is basically the last thing which happens as AmigaDOS boots and by this time some things have been loaded into CHIP RAM which could have been loaded into into the FRANCES memory (trackdisk.device for instance). Since CHIP ram is probably the most precious resource available on an Amiga 1000, and programs may run slower there than in FAST RAM (depending on system DMA load), we decided that it would be desirable to come up with an alternative approach which would permit us to configure the FRAMCES memory as soon as possible in the boot. This would insure that as much executable code would get loaded into the FRANCES memory as possible (and really fly), and that as much CHIP RAM as possible would remain available.

ADDMEM must be run every time that the system is booted, or the memory will not be visible to AMigaDOS. This means that any memory that is made available to the system using the ADDMEM utility will not be used by applications which require rebooting the system, and do not have easily alterable startup-sequence files. This includes many copy protected applications, especially games.

ADDMEM has no mechanism for setting the priority of the memory that it adds. In the regular course of events, CHIP RAM is assigned a priority of -10, and autoconfigured FAST RAM is assigned a priority of 0. This insures that the FAST RAM will get allocated before CHIP RAM, unless CHIP RAM is explicitly indicated either in the hunks which the AmigaDOS loader reads, or in a program's memory allocation request. ADDMEM also assigns a priority of 0 to the memory it adds. This is a reasonable assumption in most cases because you can't ADDMEM CHIP RAM to the system, and the data bus on the 68000 is only 16 bits wide, therefore any memory being added to the system must be 16 bit FAST RAM. This of course is not true of the LUCAS-FRANCES combination. The 32 bit wide FRANCES memory is clearly the fastest RAM in the system, and the most desirable for executing programs. We wanted a method to specify that the FRANCES memory is of a higher priority than 16 bit FAST ram.

ADDMEM also requires knowing exactly how much memory is being added to the system, you must specify the start and end addresses of the RAM being made available to AmigaDOS. For our purposes this was awkward, since most people who build this memory board will probably not want to populate it with four megabytes of memory right away. Once you have been running with, lets say 1 megabyte for a few months, and then add another, it will be quite a nuisance to have to edit your Startup-Sequence files on all of your 42 or so boot disks to specify the new range of RAM available. You can then look forward to doing the same thing again when you go to four megabytes. Also if you are running kickstart out of FRANCES RAM, you would have to correctly specify the range of RAM available to AmigaDOS as 256K smaller than the full range of memory. This is not a big deal but it would mean changing two places in the Startup-Sequence file instead of only one (the ADDMEM command, and the load kickstart into FRANCES ram utility).

Since we were already going to have to write our own utility to configure the programable 8421A DRAM controller, copy KickStart to RAM and enable it. This utility would have to be included in the Startup-Sequence file anyway, so we decided to roll our own utility which would also add the memory and address the concerns listed above.

Thus was born AFM, the FRANCES memory configuration utility. The name AFM stands for "Add FRANCES Memory". This simple to use utility attempts to deal with all of the situations listed above as best as possible for non autoconfigure memory.

The syntax for AFM is as folows:
  
  AFM -mxxxxxx [-k] [-d] [-r] [-b]

Switches in square brackets are optional. These switches are described below:

The -m is the MODELOAD switch, and it is the only required switch. This switch is followed by a 6 digit hexadecimal number (24 bits) which specify the programming of the DRAM controller. Don't Panic, the FRANCES board documentation comes with the standard values for 16MHZ and 20 MHZ operation for all possible memory configurations. You will only have to pick the one which is right for your system. For brave souls who want to experiment with programming the DRAM controller, the description of what these bits do is also part of the FRANCES documentation.   
The -k is the optional KICKSTART switch. If this switch is specified, the top 256K of FRANCES memory will not be made available to AmigaDOS. Instead AFM will copy kickstart from the Amiga 1000 WCS RAM to this 256K area, and then enables the RAM kickstart feature of the FRANCES board (asserts ERKS). Once this is done, kickstart will be run from 32 bit wide FAST RAM.  Running kickstart from FRANCES RAM can make a whale of a difference for many applications.

The -d is the optional DEBUG switch. This switch can be used to display information about what AFM is doing if you are having any problems, or if you are just interested. When AFM is run in this mode, it will report where it found the the FRANCES memory and how much of it, etc.

The -r is the optional RESIDENT switch. This switch is the key to one of the most powerful features of the AFM program. If it is specified, AFM spawns of a little program of less than 300 bytes. This program is hooked into the AmigaDOS resident module list, and it will be executed by AmigaDOS at warm boot time, even before autoconfiguration of peripherals occurs. This resident module remembers what parameters AFM was run with, and configures the FRANCES board the same way every time the Amiga is booted from then on, until the Amiga is powered off. This means that once AFM is run once with this switch, the FRANCES board will act as if it were an autoconfigure memory board until power is removed. Once the resident module is added, you can boot your favorite copy-protected version of Raster-Blaster, and if it can use FAST RAM, it will use the 32 bit FRANCES RAM. Whenever AFM is run, it of course checks to see if the resident is already present. If the module is present, AFM knows that the memory has already been configured, and it exits without further adieu. Someone once said about the CARD ram disk that it, "Hangs on like grim death" till the system is powered down If you want to exeperiment with differant programming values for the DRAM controller don't use this switch.

The -b is the optional BOOT switch. This switch only makes sense in conjunction with the -r switch. If -b is specified, AFM will reboot the Amiga as soon as tthe RESIDENT module is spawned. The reason that you may want to do this is that the first time that you boot, the resident module will not be present. This will result in some stuff being loaded into CHIP RAM or 16 bit FAST RAM which should have gone into FRANCES RAM. These things will be loaded into FRANCES RAM the next time that you warm boot, because the resident module will have run early in the boot cycle. The -b switch causes this boot to happen immediately. This only takes a few seconds, and insures that you are running with as much stuff as possible loaded into FRANCES ram right away. If you are using this switch, you really should have the AFM program as the first line of your Startup- Sequence file since anything you have done during the boot up to this point will be lost. The first time we saw this complete re-boot from software we were quite startled, you sort of have to experience it to understand. 

The AFM program first programs the DRAM controller. It then checks location $40400000 and $00400000 for memory in that order. If it does not find memory in either of those locations, it announces that no FRANCES memory was found and exits. Once the FRANCES memory has been found AFM non-destructively checks the first byte of each megabyte boundary up to four megabytes to determine the amount of FRANCES memory available. If the RAM kickstart switch was selected, the size of the available memory is reduced accordingly, and kickstart is copied up to FRANCES RAM, and enabled. AFM adds the available FRANCES memory to the AmigaDOS memory list with a priority of 10. If the resident module was requested, it is now spawned and added to the resident list awaiting the next reboot. The resident module has been passed the location and extent of the FRANCES RAM, and whether kickstart is to be run from FRANCES memory. Finally if the automatic reboot was requested, The Amiga is now rebooted, otherwise, AFM exits cleanly.

AFM has been written in such a way, that it will run whether or not there is an '020 or FRANCES memory available in the system. If AFM finds that there is no '020 in the system, AFM exits with a return value of 5. This value can be checked for in the Startup-Sequence script and conditional action can be taken depending on the result. This is useful for those of you have done the "Evan Sidorak" modification to your LUCAS board which allows you to switch between the 68020 and the 68000 (with a reboot of course). The 32 bit FRANCES memory will of course not be available when using the 68000, by checking the return code of AFM it is possible to write a Startup-Sequence script which will work for both 68000 and 68020 boots. If AFM finds that there is an '020 in the system, but cannot find the FRANCES memory, it exits with a return value of 10. This is taken to be the more serious failure, because it indicates that the FRANCES memory may have failed. We beleive that this shceme gives the Startup-sequence programmer sufficient flexibility to deal with any LUCAS-FRANCES situation. 

Benchmarks

The following benchmarks will give an indication of the raw computing performance between a stock A1000, an A2500 with 2626 card running Kickstart in 32-bit space, and  the LUCAS-FRANCES combination at 16 and 20 megahertz. These are the same bench marks that I used in the LUCAS article. The results will vary slightly each time you run them. You should bear in mind that these benchmarks are designed to gauge the raw compute power of the system and do not take into account hard disk transfer speed. To give you an idea of how this effects the system once LUCAS & FRANCES are installed, Eric, once we got his machine up and running compiled his HANDSHAKE program. The hard disk light came on and just stayed on till the compile and link was complete. Guess where the bottleneck is now? Where raw compute really helps are applications like ray-tracing. I find with the LUCAS-FRANCES installed I am seeing my images rendered 2 1/3 times faster than with just the LUCAS board by itself.

Benchmarks

         Whetstone      Savage       Calcpi        Float

Stock A1000            24         23842         4.87         286.1

A2500/2620            247           444        23.75          58.1
K32
LUCAS-FRANCES         277           402        26.18          54.8
16 meg. K32
LUCAS-FRANCES         295           352        29.46          48.0
20 meg. K32
UNITS             KWhets/sec      50*sec     Kflops/sec  sec. for 256000 i

K32 means KickStart running ib 32-bit space

Conclusion

There is much more information available on the disk which comes with the FRANCES bare board. If you have questions both myself and Eric are available on UseNet and BIX. 
Eric Haberfellner   BIX  ehaberfellner  UseNet Eric@Haberfellner
Brad Fowles         BIX  anakin.1       UseNet anakin@utgpu
  
If you're interested in acquiring either a LUCAS or FRANCES bare board and pals, send a cheque or  international money order to:

The LUCAS Project
c/o Brad Fowles
RR #5 Caledon East
Ontario, Canada.
L0N1E0

LUCAS, 4 pals, and documentation disk ........ $75.00
FRANCES 2 pals, and documentation disk ....... $75.00
Don't forget to specify the type of 96 Pin DIN connector you used
Prices are quoted in U.S. Funds

PAL Equasions


PARTNO       U54 ;
NAME         FRANCES3 ;
REV          03 ;
DATE         March 3rd 1989;
DESIGNER     Brad Fowles ;
COMPANY      Anakin  ;
ASSEMBLY     Frances ;
LOCATION     U54 ;

/* PAL16l8B2 */
/* PAL DESIGN SPECIFICATION */
/* 68020-68881 /68000 AMIGA INTERFACE */

PIN 1 = DS ;
PIN 2 = A0 ;
PIN 3 = A1 ;
PIN 4 = SIZ0 ;
PIN 5 = SIZ1 ;
PIN 6 = MA23 ;
PIN 7 = MA22 ;
PIN 8 = A31 ;
PIN 9 = A30 ;
PIN 11 = AMY ;
PIN 12 = UUD ;
PIN 13 = UMD ;
PIN 14 = LMD ;
PIN 15 = LLD ;
PIN 16 = CS ;
PIN 17 = ERKS ;
PIN 18 = ML ;
PIN 19 = SPO1 ;									


!UUD  =    !A0   & !A1   & !DS;

!UMD  =    !SIZ0 & !A1   & !DS
         # A0    & !A1   & !DS
         # SIZ1  & !A1   & !DS;

!LMD  =    !A0   & A1    & !DS
         # !A1   & !SIZ0 & !SIZ1 & !DS
         # SIZ0  & SIZ1  & !A1   & !DS
         # !SIZ0 & !A1   & A0    & !DS;

!LLD  =    A0    & SIZ0  & SIZ1  & !DS
         # !SIZ0 & !SIZ1 & !DS
         # A0    & A1    & !DS
         # A1    & SIZ1  & !DS;
  
!CS   =  !MA23 & MA22  & !A31  & !A30  & AMY 
      #  !MA23 & MA22  & !A31  & A30   & !AMY;
                    
!ML   =  A31  & !A30  & MA23 & !MA22 & !DS ;

!ERKS =    A31 & !A30 & !MA23 & MA22 ; 



/*
DESCRIPTION: BYTE WRITE DECODE FOR *CAS GENERATION AND SYSTEM             DECODE
*/


PARTNO       U7 ;
NAME         NEWU7 ;
REV          01 ;
DATE         MARCH 3RD, 1989 ;
DESIGNER     Brad Fowles ;
COMPANY      Anakin  ;
ASSEMBLY     Lucas & Frances ;
LOCATION     U7 ;

/* PAL16l8B2 */
/* PAL DESIGN SPECIFICATION */
/* 68020-68881 /68000 AMIGA INTERFACE */

PIN 1 = HIGHZ ;
PIN 2 = DS20DLY ;
PIN 3 = A0 ;
PIN 4 = SIZ0 ;
PIN 5 = SIZ1 ;
PIN 6 = AS20DLY ;
PIN 7 = CPCS ;
PIN 8 = CPDSACK0 ;
PIN 9 = FDSACK ;
PIN 11 = SYSDSACK1 ;
PIN 12 = DSACK0	;
PIN 13 = FRANCYC ;
PIN 14 = DSACK1 ;
PIN 15 = CPDSACK1 ;
PIN 16 = AS00BUF ;
PIN 17 = AS00 ;
PIN 18 = LDS ;
PIN 19 = UDS ;									


AS00.OE = HIGHZ & FRANCYC ;
!AS00   = (CPCS )& (!AS20DLY );

AS00BUF.OE = HIGHZ &FRANCYC;
!AS00BUF   = (CPCS )& (!AS20DLY );

UDS.OE = HIGHZ & FRANCYC;
!UDS  = (!DS20DLY )& (!A0 ) & (CPCS) ;

LDS.OE = HIGHZ & FRANCYC ;
!LDS  = ( !DS20DLY ) & ( SIZ1 ) & (CPCS) # 
        ( !DS20DLY ) & (!SIZ0 ) & (CPCS) # 
        ( !DS20DLY ) & ( A0 ) & (CPCS) ;

!DSACK1 = (!FDSACK )& (!AS20DLY )#
          (!CPDSACK1 )& (!AS20DLY )#
          (!SYSDSACK1)& (!AS20DLY ) ;

!DSACK0 = (!FDSACK )& (!AS20DLY )#
          (!CPDSACK0 )& (!AS20DLY ) ;

/*
DESCRIPTION: ADDRESS STROBE, UPPER AND LOWER DATA STROBE AND FINAL DSACKX
             GENERATION
*/
