451061%UOTTAWA.BITNET@CORNELLC.CIT.CORNELL.EDU (Valentin Pepelea) (01/16/89)
First of all, does anyone know how I can post messages on comp.sys.amiga.tech
from Bitnet? In order to post here on comp.sys.amiga all I have to do is send
the message to amiga-relay@udel.edu .
Now, the real subject of this message. I have built the Lucas 68020 board for
my Amiga 1000, and are successful in loading up KS 1.1 and WB 1.1 but if I load
instead KS 1.2 or 1.3, then the Amiga hangs up on me before showing the WB
screen. Apparently a problem with autoconfig, but what exactly? The funny thing
is that all works so well under WorkBench 1.1, I can even use my Insider 1 Meg
expansion with it, by using addmem.
Valentin
-------------------------------------------------------------------------
"An operating system without Name: Valentin Pepelea
virtual memory is an operating Phone: (613) 233-1821
system without virtue." Bitnet: 451061@uottawa
- Ancient Inca Proverbmikeb@tikal.Teltone.COM (Mike Balch) (01/17/89)
In article <6731@louie.udel.EDU> 451061%UOTTAWA.BITNET@CORNELLC.CIT.CORNELL.EDU (Valentin Pepelea) writes: > >Now, the real subject of this message. I have built the Lucas 68020 board for >my Amiga 1000, and are successful in loading up KS 1.1 and WB 1.1 but if I load >instead KS 1.2 or 1.3, then the Amiga hangs up on me before showing the WB >screen. Apparently a problem with autoconfig, but what exactly? The funny thing >is that all works so well under WorkBench 1.1, I can even use my Insider 1 Meg >expansion with it, by using addmem. > > Valentin I'm expereincing similar problems with the Lucas board installed in my A1000. With no expansion peripherals connected to the Amiga, Kickstart 1.2 and 1.3 work just fine. When I add the Starboard2 memory card I just purchased and boot up with Kickstart 1.2, I never get the hand requesting the Workbench disk. I have tried various flavors of the 7474 in U9 of the Lucas board but it doesn't seem to help. I checked my PALs on the daughter board and they are the ones manufactured by MMI. I had previously installed the grounds for PALs, so now I'm looking for other possible solutions. I remember a posting concerning some filter caps that may be needed on the Starboard2 card, but I didn't have one then and just glanced at article. Any suggestion are welcomed! Mike Balch mikeb@tikal
me128-aw@kepler.Berkeley.EDU (me128 student) (01/17/89)
While we're on the subject of the Lucas board, I just buit mine today. It works just fine, except when I plug in my Starboard/Stardrive! I've heard of problems with the starboard putting noise on the power supply lines, an thought I had fixed the prob with a filter capacitor. Anybody out there got any solutions? I want my hard disk and memory! Waahhhh! So please note that the lucas board may not work in general with the stardrive mem expansion. Also, Mr. Fowles, I found that it did not work with a 74ls74 as U9, so your friend is incorrect. In my case it took an F part. Lastly, I paid for two boards/pals and only got one set. My friend is getting antsy and I'm getting low on cash. Is it in the mail? Thanks -Vince Lee
anakin@gpu.utcs.toronto.edu (Anakin Research) (01/17/89)
Valentin, I have another person who is experiencing the same problem, they have sent me their board as they have done everything they can to solve the problem and I am quite curious to discover their problem. Hopefully by finding this problem I can point you in the right direction. They said I should receive the board by Wed jan 18th. I'll let you know how it comes out Brad
anakin@gpu.utcs.toronto.edu (Anakin Research) (01/17/89)
Mike, Yes, there seems to be a problem with the LUCAS board and the Microbotics STARBOARD. I'm currently talking to Jerry at Microbotics and I hope to have a fix real soon. I'm sure that the problem is a LUCAS one and not the STARBOARD. I'm quite surprised by this bug as I own a STARBOARD and it works just fine. I did however borrow 2 different STARBOARDS from some friends and sure enough they cause the system to crash just as the WorkBench hand is about to appear. I have traced the problem to the auto-config stage. Sorry for the problems, but the best I can do is deal with it. I'll post soon as I have a fix. ..... Brad
anakin@gpu.utcs.toronto.edu (Anakin Research) (01/17/89)
Vince, As I've said in a previous message, LUCAS seems to have a problem with the STARBOARD, which is certainly NOT the STARBOARDS fault. I'm working on a fix and I'll post it soon as its tested O.K. It is not that my friend is wrong, it is that their are a very wide range a tolerances and noise levels in the A1000. In order to make the board work at high speeds I had to use tight margins. I received your letter and I have sent your board to you. I appologise for the screwup, but the mistake was an HONEST one. As stated so many times before, my friends call me Brad Brad
pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) (01/17/89)
In article <1104@tikal.Teltone.COM> mikeb@tikal.UUCP (Mike Balch) writes: >I checked my PALs on the daughter board and they are >the ones manufactured by MMI. I had previously installed the grounds for >PALs, so now I'm looking for other possible solutions. Speaking of which, I must have missed the article detailing the installation of said grounds. Could somebody drop me a line? Thanks. Peter M. Yadlowsky Academic Computing Center University of Virginia pmy@vivaldi.acc.Virginia.EDU
jesup@cbmvax.UUCP (Randell Jesup) (01/18/89)
In article <27557@ucbvax.BERKELEY.EDU> me128-aw@kepler.Berkeley.EDU (me128 student) writes: >While we're on the subject of the Lucas board, I just buit mine today. >It works just fine, except when I plug in my Starboard/Stardrive! > >I've heard of problems with the starboard putting noise on the power >supply lines, an thought I had fixed the prob with a filter capacitor. Have you tried the PAL-grounding trick? The Starboard is pretty low-load, but with the extra load of the Lucas, and the high-noise on the signal lines, things may get too low/noisy. Your needing an "F" part instead of an "ls" part may also be a symptom of this. Grounding the pals should reduce the noise, and may make the starboard work. See any number of magazine articles on grounding pals. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
trantow@csd4.milw.wisc.edu (Jerry J Trantow) (01/19/89)
In article <1989Jan17.125452.18316@gpu.utcs.toronto.edu> anakin@gpu.utcs.UUCP (Anakin Research) writes: >Valentin, >I have another person who is experiencing the same problem, they have sent me >their board as they have done everything they can to solve the problem and Brad, we have a LUCAS board that only gets to the WorkBench Screen. We have not spent much time debugging this board and have not checked to see if it would boot with 1.1 As soon as we try the other boards (we have 5) I will summarize our experience. One minor gripe is the layout has square pads for the monolithic chips, but does not have polarity indicated on the tant caps. One thing the gentleman with the non-working board did look at was the 16M clock. He said the rise time was pretty close to the spec as were the levels. (15nsec, 4V and .8Volts, specs quoted from memory) Any way we have been very impressed with the board.
me128-aw@kepler.Berkeley.EDU (me128 student) (01/19/89)
Help! I canna get m' Lucas board t' work with m' Starboard! The two work fine independantly of each other, but don't like each other at all. I have tried all types of chips for U9, but no success. By the way, none of the 74XX74 chips in the instructions worked. Instead, only a 74F74 worked, and not all of those either, but only of one manufacturer. I have grounded my pals an the lucas board. I cleaned the bus connector, and even tried putting filter caps across pins 10 and 11 of the 74ACT244 in the Starboard, as suggested by a fried and Ronin Engineering (hurricane board). Alas, no luck. Even replacing the 74ACT244 with a LS part did nothing, and I can't find an F version of the chip (as suggested by beforementioned friend) Has anybody out there gotten this combination to work together correctly? Microbotics was no help. They said it was the lucas board's fault and it could not be done (gee, thanks). HHHHEEEEELLLLPPP!!! -Vincent H. Lee
anakin@gpu.utcs.toronto.edu (Anakin Research) (01/21/89)
There is a possible fix, if you'd like to try it here it is. BTW Microbotics
is absolutely right it is my fault. They have been a great deal of help to
me, It was Jerry at Microbotics who came up with the terminator.
I have a fix for the LUCAS Micobotics problem that works on the
only two amiga's I have to try it on. I make no guarantees but I'd like
a couple of you out there to try it. The first thing that must be done
is to build a terminator for the bus. Take an 86 pin female edge connector
and put the following network on each of the 16 data lines and on *AS,
*LDS, *UDS, & R/*W. That's 20 lines total.
Data or Control line <------/\/\/\/\/\---------> 5 Volts +
| 4.7K
|
| | |
|----/\/\/\/\/\---| |---> Ground
1K | |
1000 pf.
Next change U9 to a 74LS74 and change U8 to a straight 7474.
I had a fix which involved using one type D pal, but I decided that
it was such a hassle (and $20.00) to update people with a new pal, and there
had to be a simpler method. I'm still not happy with this fix as it seems a
little sensitive to me. Besides why should I have all the fun of finding this
problem. Give it a try and let me know, don't be afraid to experiment.
There seems to be some evidence that a fast memory access right
after a *VMA and *VPA cycle could be a problem.
Remember that because LUCAS is ASYNC. it is constantly delaying and
speeding up to match up to the AMIGA 7M clock.
I know making this terminator seems like alot of work but there are
other advantages. One of my Amiga's doesn't like more than two peripherals
on the bus, but with the terminator it can handle four. I've also had some
success in operating LUCAS at 24 Meg with the terminator installed. True
it is a little flakey at the moment but maybe I can make it more stable.
By the way if anyone comes up with a more solid fix for the
Microbotics memory board, that works across a fair number of 1000's, I will
gladly send you a LUCAS board a PALS free. I'll keep trying for a better fix
but I've got to get back to finishing the design on the 32_bit memory board.
Good Luck ........ Brad
jdow@gryphon.COM (J. Dow) (01/21/89)
In article <5710@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <27557@ucbvax.BERKELEY.EDU> me128-aw@kepler.Berkeley.EDU (me128 student) writes: >>While we're on the subject of the Lucas board, I just buit mine today. >>It works just fine, except when I plug in my Starboard/Stardrive! >> >>I've heard of problems with the starboard putting noise on the power >>supply lines, an thought I had fixed the prob with a filter capacitor. > > Have you tried the PAL-grounding trick? The Starboard is pretty >low-load, but with the extra load of the Lucas, and the high-noise on the >signal lines, things may get too low/noisy. Your needing an "F" part instead >of an "ls" part may also be a symptom of this. > >Grounding the pals should reduce the noise, and may make the starboard work. >See any number of magazine articles on grounding pals. > >-- >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup There is a working solution posted on BIX anakin.1. It involves placing terminators on the bus on about 11 signals. (If I remember the posting correctly.) Seems the Amiga bus is a bit too noisey without it. -- Sometimes a bird in the hand leaves a sticky deposit. Perhaps it were best it remain there in the bush with the other one. {@_@} jdow@bix (where else?) Sometimes the dragon wins. Sometimes jdow@gryphon.CTS.COM the knight. Does the fair maiden ever {backbone}!gryphon!jdow win? Surely both the knight and dragon stink. Maybe the maiden should suicide? Better yet - she should get an Amiga and quit playing with dragons and knights.
mlelstv@faui45.informatik.uni-erlangen.de (Michael van Elst ) (01/24/89)
451061%UOTTAWA.BITNET@CORNELLC.CIT.CORNELL.EDU (Valentin Pepelea) writes: >Now, the real subject of this message. I have built the Lucas 68020 board for >my Amiga 1000, and are successful in loading up KS 1.1 and WB 1.1 but if I load >instead KS 1.2 or 1.3, then the Amiga hangs up on me before showing the WB >screen. You don't have an 68881 ? Since Kick1.2 the OS checks if the coprocessor is there to do additional stuff when task switching. This is done with a Coprocessor instruction. This instruction will never terminate if the Coprocessor cycle isn't terminated with a DTACK. The solution is to connect the ChipSelect with DSACK1 on the 68881. The cycle will terminate and result in an exeception that tells the OS that no REAL 68881 is there. Michael van Elst E-mail: UUCP: ...uunet!unido!fauern!faui45!mlelstv
dale@boing.UUCP (Dale Luck) (01/25/89)
In article mlelstv@faui45.informatik.uni-erlangen.de (Michael van Elst ) writes: >451061%UOTTAWA.BITNET@CORNELLC.CIT.CORNELL.EDU (Valentin Pepelea) writes: >>my Amiga 1000, and are successful in loading up KS 1.1 and WB 1.1 but if I load >>instead KS 1.2 or 1.3, then the Amiga hangs up on me before showing the WB >>screen. >You don't have an 68881 ? >Since Kick1.2 the OS checks if the coprocessor for 68881 >This is done with a Coprocessor instruction. This instruction will never >terminate if the Coprocessor cycle isn't terminated with a DTACK. >The solution is to connect the ChipSelect with DSACK1 on the 68881. Nope, if the 68881 is not there he should pull on buserr I think, signifying that an access to an unattached coprocesor device has been made. If the 68881 then standard bus protocol should be used. I could be wrong, it has been a while since we worked on that code and had the state anylizer hooked up testing the coldstart sequence. -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
anakin@gpu.utcs.toronto.edu (Anakin Research) (01/27/89)
>451061%UOTTAWA.BITNET@CORNELLC.CIT.CORNELL.EDU (Valentin Pepelea) writes: >>my Amiga 1000, and are successful in loading up KS 1.1 and WB 1.1 but if I loa d >>instead KS 1.2 or 1.3, then the Amiga hangs up on me before showing the WB >>screen. >You don't have an 68881 ? >Since Kick1.2 the OS checks if the coprocessor for 68881 >This is done with a Coprocessor instruction. This instruction will never >terminate if the Coprocessor cycle isn't terminated with a DTACK. >The solution is to connect the ChipSelect with DSACK1 on the 68881. >>Nope, if the 68881 is not there he should pull on buserr I think, signifying >>that an access to an unattached coprocesor device has been made. >>If the 68881 then standard bus protocol should be used. >>I could be wrong, it has been a while since we worked on that code and had >>the state anylizer hooked up testing the coldstart sequence. >>-- >>Dale Luck GfxBase/Boing, Inc. Oops! I'm afraid I don't pull *BERR if the Coprocessor ain't there. Does anyone else. Boy ya learn something new every day. I must admit that this makes perfect sense, Dale. Atleast his machine would GURU instead of going off to la-la land. I humbly appologise. Brad BTW Valentin, does the board work now with the 881 installed?
daveh@cbmvax.UUCP (Dave Haynie) (01/27/89)
in article <819@faui10.informatik.uni-erlangen.de>, mlelstv@faui45.informatik.uni-erlangen.de (Michael van Elst ) says: > You don't have an 68881 ? ... > The solution is to connect the ChipSelect with DSACK1 on the 68881. > The cycle will terminate and result in an exeception that tells > the OS that no REAL 68881 is there. That's won't work. Such a setup would just result in a coprocessor violation, since the 68020 would think a 68881 was there, but the data would be garbage. To run a 68020 without a 68881 and get the F-line exception generated properly, it's necessary to run the 68881 chip select to the 68020's bus error (BERR*) input. On the Amiga, you'll also have to make darn sure that the bus error signal going to the 68020 isn't the same line as the bus error going to the expansion bus, since on the expansion bus, the BERR* line is used to indicate a PIC collision, which makes everything immediately get off the bus. The way to wire this up is as such: |\ BERR* from Amiga ------| |------------------+----- BERR* to '020 |/ 7407 | |\ | 68881 CS* ------X X--------------| |--------+ jumper |/ 7407 The jumper can be closed when there's no 68881. A more elegant solution would gate the 68881 CS* with the 68881 SENSE* output, so the BERR* line is automatically switched in when the '881 isn't there. > Michael van Elst > > E-mail: UUCP: ...uunet!unido!fauern!faui45!mlelstv -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
c60a-1fy@web-2a.berkeley.edu (Anon) (01/30/89)
!!!!!!!! Finally, after 2 weeks of solid fiddling, I have successfully gotten my starboard/stardrive to work reliably with my Lucas board. I tried many different methods, but the only thing that worked was to build the bus terminator Brad posted, but modify it in a minor way. After first building the terminator I was able to get the workbench prompt to come up, but the machine would crash when I put in a disk or sometime in the middle of the startup-sequence. Games with long boot sequences were especially succeptible. Looking at the signals on the terminator with an oscilloscope allowed me to fix the problem. WHAT TO DO (or at least try if you're stuck) When assembling your parts, get 14, 16, 18, and 20 Mhz crystals. Some values for U9 won't work with a fast clock, others NEED one. Play around with U8, U9 and the crystal to get the best combination (get the farthest). Build the bus terminator, which, if you've been missing, consists of 4.7k pullups and 1k's with .001uF caps to ground on the data lines and 4 control lines. Don't solder your parts on the board, though, but instead use SOCKETED sips. When buying the sips, get 2.2 and 3.3k sips too. ******* This is it ****** If this works, great! If not, replace the 1k to ground on /AS with a 10k trimmer. This is what worked for me. The signal was suppressed when I saw it on the scope using a 1k resistor. My trimmer is set to about 3.7k but you might have to play around with it. Try again. You should be able to find a U9/U8/Crystal/Pot setting which works fairly well. Replacing the 4.7k pull ups with 3.3 or 2.2k values may help stabilize things. Good Luck. Here's my set-up as a starting point. I think I've mentioned all which seemed to fix the problem, but maybe something I did earlier was necessary in the final solution. LUCAS Board with 16 Mhz 020, 12 Mhz 881 Microbotics starboard with stardrive controller. 74ACT244 removed from the starboard and replaced with an LS part (cuz I needed an ACT part for the 68000 hack and couldn't find one) Beforementioned 68000 hack keeping the 68000 on the bus. Pal Upgrade kit. Ground wire from lucas board to amiga Metal springs placed between starboard and amiga to securely ground case 16Mhz Crystal 74LS74 for U8 74ALS74 for U9 CLOCK ON STARDRIVE Everything works except the Startime software. (works in 68000 mode) Apparently the software uses timing loops when accessing the clock, and even with the cache off it runs too fast (comes back immediately) to set/read the date/time correctly. FLAME HIGH I called Microbotics, and got no help at all. First, it took 20 minutes long distance for me to convince the guy that I was not having noise problems on the bus, and that my Lucas board was working fine. During our conversation, the guy repeatedly said (4-5 times), as if he were reading: "Microbotics designs its products to work with a base Amiga. We have no intention of modifying our product to work with a non-standard configuration" <--- !!!!! While I can see the position they are in, what do they call non-standard! How about we who want expansion RAM and, dare I dream, a hard disk?!!! They guy on the other end insisted that the clock not working was the lucas board's fault for being poorly designed! Well, I suppose if it were designed to provide no speedup at all, then yes, the clock probably would work, but I don't thing that's acceptable! For that matter, the Lucas board works just great on a "base" amiga too! In summary, don't call Microbotics for help. Also, before buying anything else from them, think twice and remember their "compatibility" policy--base machines need only apply. [In all fairness, I have called Microbotics on 2 previous occasions and got friendly, helpfull advice, so maybe it was only that this guy was a simple A****le.] -Vince Lee (posted by friend, so please don't mail him)