
	There are a couple of new things on this disk. 
	 
	If you look in the hacks drawer, there is a file called hacks.
There is an ingenious hack which allows you to keep the 68000 in the system
and select which processor you wish to use at boot time. I suggest if you are
going to try this hack, get the LUCAS board going in its plain vanilla
form, then try this hack. There is no sense making your debugging phase, if
needed, any more complicated than it needs to be.


	There is a file in the Making_It/Builging_IT directory called
hints. These are a few things that I have learned from the letters
I have had and the E-Mail I get. Common problems are discussed here.
From the mail I get I'd guess about 10% of the people who build boards 
have some problems (as of Dec 16th). If your having problems or would just
like to see the type of problems others have had, please read this file.  

	Note that the source files for the two Mandelbrot programs are 
no longer on the disk. I needed the space for these extra files. If you
would like to get the source for the mandelbrot programs send me a disk 
plus mailing( oh... 2 bucks) and I will send it to you. From what I hear 
the LUCAS.ARC file is around on most bulletin boards. You can also find
the source to the mandelbrot programs there.

	If you want to run the LUCAS board without the '881 then jumper
pins 7 & 15 of U7.

					Brad Fowles 

	Bugs:


	Somehow when making the disks up before I forgot to tell people
how to wire up the jumpers. Since there was no difference in operation
no one was confused, with the inevitable exception. There are a few Amigas
out there which seem to need to see FC2, mine doesn't so I didn't know.
The jumpers should be wired with the square hole of J1 wired to the square
hole of J2. Again looking at the diagram this jumpers FC2 to FC20 which
will pass along the '020 FC2 (called on the diagrams FC20) to the Amiga
motherboard. See hard-copy of the schematics.


	An interesting problem has arisen with the performance of HardDisks
with the LUCAS board (or any high clocked '020 accelerator board). The
performance can actually be a little slower (especially during writes) than
with the 68000. This is caused by the fact that the '020 is back so fast
requesting the next piece of data that it gets a busy signal from the 
controller. Then being a conscienceous (wonder how that's really spelt) little
beast it goes and does some housekeeping before doing another request. This
can take more time than doing it at a slower speed. Luckily there is a fix.
I have a COMSPEC 170 Meg HardDrisk and when I asked them about this problem
they gave me a new set of EPROMS for my controller and now it really screams.
With more and more '020 based systems being used it is worth while for the
makers of HardDisks to provide an upgrade path. Right now I can only
say COMSPEC is doing this but I'm sure if you contact the manufacturer of
your HardDisk he should be able to help you. If he can't, then you'll
be forced to either doing the tinkering yourself or asking your local
hardware GURU to look into it for you. 

	There seems to be one combination which works with almost all
Amiga's. If your having problems with the mysteries of U9 try a 20 MEG.
oscillator and a straight 7474 for U9. It doesn't matter what speed your
'020 and 881 are, try this configuration to see if your board is working.
Remember you have to be close to try this fix, if your not flashing the LED 
then this is no magic. If you get to the point of reading KICKSTART and then
are getting failures try this out. Once this works then you will have the 
confidence to do some tinkering and tuning to get it just right.

	I'm going to stress one more thing, I've now had some experience
with helping people get there LUCAS board going. I find that people are
spending too much time with doubting their chips, Pals, U9, and a whole
plethora of bizarre technical problems. 95% of the time it is a short
on the board. If it doesn't work, take an ohmmeter (preferably with
an audio beep and CHECK, CHECK,  C H E C K !

	Here is some more information on problems that people have had 
with building the LUCAS board and some fixes for those problems. Again,
don't let them scare you. I feel that its important to help those
who are having trouble so I'm presenting as much information on
these various problems as I can, in case your board doesn't work 

	I've had a couple of reports that the clock oscillator isn't
putting out sufficient drive. I used the Motorola spec. which is
O.K. for this design, but it appears all oscillators are not created
equal. There is a simple fix if this is the case. There is a spare 
inverter on the board (pin 8, and 9 of U10, (9 is the input)) and
you can run the output of the oscillator through this inverter to
increase its drive. Don't do this unless you've looked at the signal
with a scope and seen it to be iffy. This signal will always appear as
a sine wave so don't expect it to look like this: 
        ___     ___
       |   |   |   |
   ____|   |___|   |____

	This fix has only been needed in a few cases.

	Once your LUCAS board is working you may find that it will not
always boot the first time you turn the machine on, but will on the
second or third try. It will then go on to work flawlessly. This
appears to be true in about 5% of the boards that I have received
reports about so far. The reason for this is the way I generate the
signal which syncs LUCAS up to the AMIGA C1/*C3 phase of the clock.
All of the Amiga's which were used during the prototying of the 
board did not exibit this problem, so I was unaware of it. George
Buce had this problem and came up with an ingenious fix for it, and
you can find it in the hacks directory as the Pixar_fix (George
works at Pixar). I thank him for his work and permission to share
it with you. This is one of the reasons I put the LUCAS board in the 
Public Domain. With all of you working with the board the design can
only improve.

	Many of you are operating the board at 20 Meg. and would like
to go faster. I know of two LUCAS boards working at 24 Meg. I've had
a good look at the timings and there seems to be no way in which all
the setup time will be met. (Faster Pals (D pals) don't give the 
necessary margins). It would appear that the noise floor on your 
Amiga, especially with peripherals attached is also a problem. I in no
way wish to discourage experimentation, but you should know that
the chances are slim. LUCAS was designed for 16 Meg operation, 20
was a bonus, but that's the ceiling.

	There are three fixes to the amiga which are important in
controlling bus noise. The first is grounding the pals on the
kickstart daughter board. This fix is easy and should be done to 
all amigas (it is described elsewhere in these docs). The second
is the bus terminator which is described at the end of this
file. I now install one of these on any machine I work on, even
if it has no LUCAS board. It simply allows more peripherals to
be attached with more reliable operation. The third fix is to use 
faster, less noisy pals on the amiga daughter board. You can do these
yourself or they are available from C-Ltd. This is not a simple
fix and should only be used if your having problems you believe are
noise related.

	There is a way to have a look at a non workin memory board
without your system crashing at boot time. To do this, inset a 
Kickstart 1.1 disk and boot. then use a 1.1 Workbench to complete 
the boot. This will allow your machine to come up without 
auto-configuring any of the peripherals on the bus. It will also not
initialize the 68881, if you doubt the 68881 this is a good test.
All peripherals on the A1000 bus which auto-configure are initially at
base address $E80000. The address $E80048can be written to, to change the
base address of the board. If you write a $20 to address $E80048 then
the memory board will be put at base address $200000 but will not be 
added to the memory list. You can then use a debugger like metascope 
to look at the memory without actually running any code there. This is
a good way to tune that 10K pot on *AS. If you don't understand the
autoconfig process please look in the commodore docs.	

	I've had a few reports of shorts on the LUCAS board between
pads and traces. On the whole I quite pleased with the work the board
manufacturer has done and I do some inspection when I get the 
boards. I inquired about having a short test done on the boards but it 
was prohibatibly expensive. I suggest when you get your board that 
you take an ohmmeter and after a good visual inspection test any area 
that looks suspect. A little time upfront can save alot of debug time.
I've only had 5 reports out of 400 but its always good to check.

        Some memory boards and Hard Disks seem to be very sensitive
to when the *AS goes high. If you are having problems with a memory
board or Hard disk you can try the following hack to try and get
by the problem.
        What we want to do is to lenthen the time that *AS is low. To
do this you will need a 74LS04. Remove the 74F74 in the U8 position
from the LUCAS board. Bend up pin 13 of the F74. Bend up all pins on the 
LS04 except pins 7 and 14. Place the LS04 on top of the F74 and solder
pins 7 and 14 of the LS04 to 7 and 14 of the F74. (These are the power
and ground pins) Next solder a wire from pin 12 of the F74 to the to
pin 1 of the LS04. Solder pins 2 and 3 of the LS04 together. Solder a 
wire to pin 4 of the LS04 to pin 13 (the one you bent up) of the F74.
Place the "tower" back in the U8 socket. You can add more delay by
using 4 or 6 inverters instead of 2.
                                      1    2    3    4
                                        |\       |\
                                     +--| O------| O---+
                                     |  |/       |/    |
                                     |       ----------|
                                     |     13|        74LS04
                                     |    -------   
                                     | 12|   C   |9 
                      *AS20----------+---|D     Q|--
                                       11|  U8b _|8 
                                  7M ----|>     Q|------- *AS20DLY
                                         |   P   |
                                          -------
                             +5V           10|  74F74
                              |--------------|


	Here is some more information on problems that people have had 
with building the LUCAS board and some fixes for those problems. Again,
don't let them scare you. I feel that its important to help those
who are having trouble so I'm presenting as much information on
these various problems as I can, in case your board doesn't work 


	The Microbotics STARBOARD problem still exists though a
fair number of them kluged into working. This problem has, however
made us much more aware of the problems of noise on the bus and
some of the fixes have helped with many other problems. So let me
go through the variety of fixes for this problem. They may be
useful in discovering a fix for some other peripheral you may have.
	There are three fixes to the amiga which are important in
controlling bus noise. The first is grounding the pals on the
kickstart daughter board. This fix is easy and should be done to 
all amigas (it is described elsewhere in these docs). The second
is the bus terminator which is described in the "what's newer"
file. I now install one of these on any machine I work on, even
if it has no LUCAS board. It simply allows more peripherals to
be attached with more reliable operation. The third fix is to use 
faster, less noisy pals on the amiga daughter board. You can do these
yourself or they are available from C-Ltd. This is not a simple
fix and should only be used if your having problems you believe are
noise related.
	Some success has been had by putting a 10K pot to ground on
the *AS (pin 74) line on the terminator. It seems that tuning this 
to about 3K will correct the timing and allow the STARBOARD to work.
It is simple to try, so why not.

	One fix for the STARBOARD which has helped folks getting it
working with the LUCAS board is to change the only 74ACT244 on the
STARBOARD itself to a 74LS244. *** A strong word of caution ***, this 
goes against my grain to ask you to hack away at a perfectly working 
board just to get it working with the LUCAS board. Microbotics has 
designed a wonderful memory board and it is LUCAS's fault that it
doesn't work with it. So, do this at your own RISK, it has worked for
some and if you do it carefully then there are no problems. Make sure
if you remove the chip to put a socket in its place. Ofcourse, if you
do this badly you can destroy your memory board, its up to you
to try this fix.


        Bus Terminator 

	The terminator can help control bus noise. It is not a cure all
but has been used successfully to get some peripherals up and
running.

        To build the bus terminator you will need an 86 pin wire wrap
edge connector, 20 10k resistors, 20 1k resistors and 20 .1 mf monolithic
caps. Basically you want to put a termination network on each of the 16
datalines plus on the four control lines, *AS, R/*W, *UDS, and *LDS. The
network looks like this:
                              10K

       Signal >--------------/\/\/\/\/------->5V+
                         |
                         |              | | .1 cap
                         ----/\/\/\/\/--| |----
                                        | |   |
                               1K             | Ground
                                             ----
                                            / / /


        86 pin connector

        Note: pins number at 1 on the top pin closest to the front of
the amiga, 2 underneath, 3 back on top next to 1 etc.

Pin 1,2,3,4,13,25,37,49,61,73,85   Ground
Pin 5,6      5V+
Pin 75 D0                         Pin 80 D8
Pin 77 D1                         Pin 78 D9
Pin 79 D2                         Pin 76 D10
Pin 81 D3                         Pin 71 D11
Pin 83 D4                         Pin 69 D12
Pin 86 D5                         Pin 67 D13
Pin 84 D6                         Pin 65 D14
Pin 82 D7                         Pin 63 D15
Pin 74 *AS                        Pin 68 R/*W
Pin 70 *LDS                       Pin 72 *UDS

Update Oct 24/89

	There seems to be some problem with the AMAX software and the
FRANCES board. I've discussed the problem with Tim Grantham and together
we came up with a very klugy fix. I'm investigating a pal change to make 
this work better. If you have a better fix let me know. Here is the UseNet
message Tim uploaded describing the fix.

From geac!becker!cbmtor!timg Tue Oct 24 06:50:13 1989
Received: by gpu.utcs.utoronto.ca with UUCP id 5344; Tue, 24 Oct 89 06:50:06 EDT
Received: by geac.UUCP (smail2.5)
	id AA09050; 24 Oct 89 06:47:05 EDT (Tue)
Received: by becker.UUCP (smail2.5)
	id AA24341; 24 Oct 89 04:37:24 EDT (Tue)
Received: by cbmtor.UUCP (smail2.5)
	id AA01997; 23 Oct 89 23:35:08 EDT (Mon)
To:	anakin@utgpu
Message-Id: <8910232335.AA01995@cbmtor.UUCP>
Date:	Mon, 23 Oct 89 23:35:07 EDT
From:	timg@cbmtor.UUCP (Tim Grantham )
Status: RO

Subject: A-max and LUCAS/FRANCES
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Keywords: A-max Macintosh LUCAS FRANCES

I've spent the last week trying to get the A-max Macintosh emulator to work
with the LUCAS/FRANCES combination on my A1000. Actually, it works fine with
LUCAS -- it's FRANCES that won't work with A-max. Happily, I can report that
with the help of a lot of people I have been able to get it work, and work
well.

My system is as follows: an A1000, LUCAS board with 12 MHz 68020 and 68881
parts, FRANCES board with 2 Mb of 70 nsec. DRAMs, an A1020 5.25" drive, a
SystemGate M300 Mac compatible 800K floppy, and the A-max hardware. Note that
I have nothing on the expansion bus, which probably explains why I can run the
whole thing at 20 MHz with 1.5 wait states (well, 1 most of the time, 2 some-
times).

The problem arises because the Mac operating system in the 64 Kb and 128 Kb
ROMs uses the upper 8 bits in addresses for private things. But the FRANCES
board also uses the top 2 bits (A31 and A30): the FRANCES address decode PAL
conditions A31 with other jumpers to program the DRAM controller. A30 is used
when addressing the memory if it has been put outside of the regular Amiga 
memory map.

When the Mac OS asserts A31, it may cause the DRAM controller to be inadver-
tently reprogrammed; if both A30 and A31 are asserted, the FRANCES decode
PAL will say ``this isn't a FRANCES address'' and the Mac OS will try to 
write to memory that doesn't exist.

Brad Fowles suggested I try switching A30 and A31 at the FRANCES decode PAL
to ground, after the initial programming of the DRAM controller (which is done
with Eric Haberfellner's AFM program), like this:

	______					________
	     |					|
	     |					|
 FRANCES     |					| 68020
   PAL       |					|
	     |______________________ \__________|A30
	     |         \ 			|
	     |         /			|
	     |_________\____________ \__________|A31
	     |   \     /   			|
	     |   /     \ 1K Ohm 		|
	     |   \    ---			|
	_____|   /     - 			|_______
		 \ 1K Ohm
		---
		 -

In other words, the switches are closed during normal Amiga operation, open
during Mac OS operation. During Mac OS operation, the FRANCES PAL sees A30 and
A31 as always zero.

The timing of the change-over proved to be crucial. A31 must be switched out
after the AFM memory configuration program is run and before Mac OS operation
begins. A30 must be switched out *after starting the A-max program but before
the A-max program loads in the Mac ROMs*. I don't know why this should be so;
neither does Simon Douglas, the programmer of A-max. But unless A30 is switched
out *after* starting A-max, A-max will not find the FRANCES memory, *even
though Exec knows the FRANCES memory is there!*

My hardware mod, at this point, consists of bending up pins 8 and 9 on the
FRANCES PAL, and running wires from those pins and from their respective
sockets to a DPST switch and the resistors. Then, once I have A-max's con-
figuration screen up, I through the switch and command A-max to start loading
the ROMs.

I am now able to run the ROMs out of either the WCS RAM or out of 32-bit RAM.
I have been able to run numerous Mac programs without problems, including
Adobe Illustrator (only under Finder, I don't have enough memory to run it under
Multifinder), Quark Express, SmartCom, MacDraw, Paint 2.0, Microsoft Word,
Freeterm, etc.,. I have been able to run load and run several applications
under Multifinder.

Ok, I lied: two problems. I have not been able to print PostScript files
generated by Mac applications on a NEC PostScript laserprinter; and sometimes
my Mac-compatible floppy cannot read files when the Mac ROMs are running out
of 32-bit RAM -- it reads them fine when the ROMs are running out of the WCS.
This is probably some kind of timing problem with either the floppy or the
emulation software.

I'm still working on rough benchmarks for this system but I can report one
preliminary result. The operation consists of a blend operation with 500
steps between two 100-unit diameter circles, 300 units apart, done in Adobe
Illustrator. On a Mac II, equipped with a math chip, this took 1:52. On my
system it took 4:54. On a standard A2000, this took 13:10. (this is
minutes:seconds).

This test does not require any screen refreshes (except for the ticking
watch icon) and does not require any disk I/O, so I beleive it's a fair
comparison of CPU performance.

I hope this message is reasonably clear. Maybe if Brad Fowles sees this,
he can correct/elaborate.

Thanks to Brad Fowles, Eric Haberfellner, Bruce Becker, Doug Lee, Craig Hubley
and Paul Bosacki for their help. (and Simon Douglas, too).

Tim.

EOF

