[comp.sys.amiga.tech] Amiga 1000 Lucas/Frances optimizations

dad@obie.paradyne.com (10/06/89)

	Greetings Brad et all,

		After assembling the Lucas/Frances expansion boards for my 1000, I 
wanted to TWEEK the various jumpers and program settings to achieve the
best performance possible. First, a little description of my hardware base:

      AMIGA 1000
	  internal 256K (front panel expansion)
	  PALs grounded 
	  Bus unterminated
	  Six pole switch mod to keep 68000 in system

		The components used in LUCAS were 16Mhz 68020 and 68882. Before
FRANCES, the system worked well at 24Mhz! When I added FRANCES, I had to
cut back to 20Mhz (more on that later). For FRANCES I purchased the full
4 meg of memory TMS44L256-10N. I also bought the 25Mhz version of the
memory controller (in hopes of greater speeds in the future). Besides, it
was only 10$ more anyway!

		Now comes the fun part... The original documents I got with FRANCES
said there was trouble with the bus transceivers. The docs said something
about being unable to use high speed parts because of a spike during switch-
ing. I tried several logic families to see if they all suffered from this
pitfall. ALS, F, H, etc. I stumbled upon 74HCT245, this is the high speed
CMOS TTL compatible chip (5 ns propagation with a very hefty drive capacity).This is just the ticket for a large array of DRAMs. The success with this
chip encouraged me to investigate the jumpers on FRANCES

		J3 (4) 			set KICKSTART address $7C0000 - $7FFFFF
		J4 (2) 			select *DS as part of buffer enable logic
		J5 (1,3,6,8)	enable interleaving
		J6 (none)		Amiga Space $400000
		J7 (none)		NO EXTRA WAIT STATE!!!
		J8 (2,3,6,7)	Follow Motorolla 20Mhz schematic
						2) sync *DTACK with system clock
						3) *AS is delayed 1/2 clock cycle
						6) system clock direct (not inverted)
						7) pass *DS (from J4) to buffer enable

		That does it for JUMPER selection, now to programming... The AFM
program provided with FRANCES accepts a six digit hex number to set the
various parameters on the 8421 memory controller. The actual command is:

		AFM -m16800C -k -r

		The "k" installs KICKSTART in 32 bit wide space, the "r" installs
the configured memory as a resident setting (survives warm re-boots).
(A0 - A23). Some of these bits are "should always be set"s and others are
"experiment with this"s. Pictured below is the code I use. The 'X's are
bits that have been designated as "experiment with this"s.


               1       6       8       0       0       C
            ------- ------- ------- ------- ------- -------
	A23		0 0 0 1 0 1 1 0 1 1 0 0 0 0 0 0 0 0 0 0 1 1 0 0     A0
			0 0 X 1 X 1 1 0 1 X 0 0 0 X 0 X 0 X 0 X 1 1 0 0 
                ^   ^         ^       ^   ^   ^   ^
				A   A         A       A   A   A   A
				2   1         1       1   8   6   4
				1   9         4       0   ^   ^   ^
                ^   ^         ^       ^   ^   ^---^
A21             ^   ^         ^       ^---^   ^      A4 A6
Row address     ^   ^         ^       ^       ^      RAS clock cycles
set-up time\    ^   ^         ^       ^       ^    /      refresh/precharge
0 = 15 ns   >---^   ^         ^       ^       ^   /  0  0    2       1 
1 = 25 ns  /        ^         ^       ^       ^--<   0  1    2       2
                    ^         ^       ^           \  1  0    3       2
A19                 ^         ^       ^            \ 1  1    4       3
Col address         ^         ^       ^
set-up time\        ^         ^       ^              A8 A10
0 = 0 ns    >-------^         ^       ^              WAIT STATES
1 = 10 ns  /                  ^       ^            / 0  0    none
                              ^       ^           /  0  1    1/2
A14                           ^       ^----------<   1  0    1
CAS                           ^                   \  1  1    1 1/2
0 = same for           \      ^
    reads & writes      \     ^
1 = internal delay or    >----^
    clk rise after RAS  /
	(whichever is last)/


			And that's it! And what does all of this TWEEKing yield in terms
of actual performance increases? The following is a table of timings for
the standard benchmarks distributed on the LUCAS diskette:
			
              stock 2500   -m16C45C   -m16800C			
Whetstone         243         297        384       (KWhets/sec)
CalcPI            23.13       29.62      37.06     (KFlops/sec)
Float             59.88       49.6       37.86     (sec/256000)
Savage            495         354        295       (sec*50/2500)
	

			Ok, so much for the good news. Now, what if I still want to go
faster? As I said before, I had my LUCAS running at 24Mhz before FRANCES.
Here is the problem, there are two clock signals that must be supplied to
the memory controller ship (8421). CLK is the system clock and is what
read and write signals are decoded with. This line must therefore run at
24Mhz (if the 69020/68882 is to do so). The second clock is the DELCLK. 
This signal is used to generate an internal 2Mhz clock for the delay line
which controls refresh timing etc.. Unfortunately, the DELCLK divisor
maximum programmable value is 10 (allowing a 20Mhz signal to be used).
A simple solution to the problem is to provide 24Mhz to the CLK line and
then use a single FlipFlop gate to halve the frequency of the system clock
and feed this to the DELCLK. Then program the 8421 for a 12Mhz DELCLK.
Easy, right? WRONG! The DELCLK and CLK lines are tied together on the
FRANCES board. This means that to supply each with it's own frequency
would require that the trace connecting them be CUT. Ok, so were is this
trace? Between pins 56 and 57 on the 68 pin socket of the 8421. The best
I can see is that these pins are connected on the component side of the
board (under the socket!). 

		Can ANYBODY tell me if the trace between 56 and 57 are indeed
under the 68 pin 8421 socket? I will have to drillthrough from the back
of the board to cut that trace (I really do not want to remove the socket).
Once CLK and DELCLK are separated, a FlipFlop can be added and HOPEFULLY
the system will once again run at 24Mhz!

		Dean Du Bois