aimania@killer.DALLAS.TX.US (Walter Rothe) (11/10/88)
The Lucas board is a fantastic idea that should prolong the life of the 1000
and 2000. Now if someone would just build a board like this with 64k of
32 bit direct mapped cache on board and with capability of plugging in a
68030 when it comes down in price.
There are a couple of things that bother me about the Lucas board. The first
is that the documentation says that you might have to select parts for U9.
Any design that is requires this is a commercial no-no. I question the
stability over temperature of a design like this.
The second is that there seems to be an incompatability between the 68020
and the 68000 when operated in byte mode. The 68k puts out UDS when the
byte in bits 8-15 gets put out and LDS when the byte in bits 0-7 gets
put out. The 68k manual says that that it puts the data out in both bytes
when only one of the strobes is true. However, the 68020 always puts bytes
out in bits 24-31. The problem with the Lucas board is that if you do a
byte move to an odd address, the 68020 winds up writing to bits 8-15 where
the 68k writes to bits 0-7. Am I overlooking something? I didn't see
anywhere in the 68020 manual where is says that it duplicates data on the
bus when in byte mode.
As someone else mentioned, the schematics with the distribution were in
Draw Plus format. I don't have this so I drew up a schematic on one
8 by 11 sheet of paper from the node list. If anyone would like a copy,
please send me a self addressed stamped envelope and I will send them one.
Maybe someone could convert Draw Plus to IFF and send it over the net.
One thing I didn't understand about the node list was that one address line
and one data line go to the crystal. Any help?
Walter Rothe
2008 Mary Street
Carrollton, Texas 75006
--
Walter Rothe at the UNIX(Tm) Connection, Dallas, Tx
UUCP: {rutgers}!smu.killer.aimaniaanakin@gpu.utcs.toronto.edu (Anakin Research) (11/13/88)
Walter and other interested folk! I've a lot of messages and I'll reply them soon, but anyone who draws out a schematic from a node list deserves an instant reply. You say: >There are a couple of things that bother me about the Lucas board. The first >is that the documentation says that you might have to select parts for U9. >Any design that is requires this is a commercial no-no. I question the >stability over temperature of a design like this. >The second is that there seems to be an incompatability between the 68020 >and the 68000 when operated in byte mode. The 68k puts out UDS when the >byte in bits 8-15 gets put out and LDS when the byte in bits 0-7 gets >put out. The 68k manual says that that it puts the data out in both bytes >when only one of the strobes is true. However, the 68020 always puts bytes >out in bits 24-31. The problem with the Lucas board is that if you do a >byte move to an odd address, the 68020 winds up writing to bits 8-15 where >the 68k writes to bits 0-7. Am I overlooking something? I didn't see >anywhere in the 68020 manual where is says that it duplicates data on the >bus when in byte mode. Yes indeed this is a commercial no no, but in the end I could not solve the async problem any other way. I know its klugey, but it works. So far I've noticed no temperature problems. I felt it was a small trade off in order to have boards that work at 12 through 20 Meg. (25 with a PAL change) as many cannot afford the more expensive parts. In my day work I could never get away with it. God, I love the Public Domain! There is no byte incompatability in byte mode to an odd address. The internal multiplexor duplicates the byte in all four places(D0-7 D8-15 D16-23 D24-D31) whenever SIZ0 = 1 and SIZ1 = 0. In byte transfers A0 and A1 have no meaning. (See page 5-5 of the 020 USER MANUAL) The crystal socket has 14 pins only four of which are used by the oscillator. I'm afraid I used the others as vias when I was laying out the board. Honest, it was tight and I never thought I'd get caught. I'm so ashamed. Brad Fowles
papa@pollux.usc.edu (Marco Papa) (11/14/88)
In article <1988Nov12.235643.5124@gpu.utcs.toronto.edu> anakin@gpu.utcs.UUCP (Anakin Research) writes: >Walter and other interested folk! [lots of tech stuff deleted] Brad. This stuff is good for comp.sys.amiga.tech. Please move to that group any further discussion of the "technical" aspects of the design. Keep using comp.sys.amiga for the more general questions. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
daveh@cbmvax.UUCP (Dave Haynie) (11/15/88)
in article <6053@killer.DALLAS.TX.US>, aimania@killer.DALLAS.TX.US (Walter Rothe) says: > Keywords: Lucas 68020 68881 > The second is that there seems to be an incompatability between the 68020 > and the 68000 when operated in byte mode. The 68k puts out UDS when the > byte in bits 8-15 gets put out and LDS when the byte in bits 0-7 gets > put out. The 68k manual says that that it puts the data out in both bytes > when only one of the strobes is true. However, the 68020 always puts bytes > out in bits 24-31. The problem with the Lucas board is that if you do a > byte move to an odd address, the 68020 winds up writing to bits 8-15 where > the 68k writes to bits 0-7. Am I overlooking something? Yes. What you're not considering is PORT SIZE. Where a particular chunk of data shows up is determined by the address you're using, the instruction size, and the size of the physical memory port you're writing to. If the LUCAS board is doing it's job (if it works at all, it is), all of the Amiga system looks to the 68020 as a 16 bit wide port (port width is controlled with the Data Size ACKnowldege lines /DSACK0 and /DSACK1). The 68020 will write to bits 0-7 (or 16-23 from the '020s point of view) for the 68000 /LDS equivalent, and bits 8-16 (== 24-31) for the 68000 /UDS equivalent. > I didn't see anywhere in the 68020 manual where is says that it duplicates > data on the bus when in byte mode. You need to read over the bus sizing stuff again, especially how DSACKs work. > Walter Rothe -- 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
timg@ziebmef.uucp (Tim Grantham) (11/15/88)
In article <6053@killer.DALLAS.TX.US> aimania@killer.DALLAS.TX.US (Walter Rothe) writes: > >The Lucas board is a fantastic idea that should prolong the life of the 1000 >is that the documentation says that you might have to select parts for U9. >Any design that is requires this is a commercial no-no. I question the >stability over temperature of a design like this. > First of all, it is not the _design_ of the LUCAS board that requires U9 to be selected from several different parts, it is the variation in the 1000s out there that the board has to cope with. Brad struggled mightily to design a board that would simply drop into any 1000 but even he was ultimately defeated by the noisy nature of the machine. As it is, the LUCAS board is a tremendously elegant hack (if that's not a contradiction in terms :-) ). Secondly, LUCAS is _not_ commercial. On the board it says ``Public Domain Hardware''. I think that fiddling around with one part is a small price to pay for such a terrific product. >Walter Rothe at the UNIX(Tm) Connection, Dallas, Tx >UUCP: {rutgers}!smu.killer.aimania Tim.
aimania@killer.DALLAS.TX.US (Walter Rothe) (11/16/88)
Brad, does your board work with an Amiga 2000 or does it just fit
the 1000?
By the way, you've done a great job designing an asynchronous interface to
the Amiga. Not an easy problem. A low cost accelerator board is just what
the Amiga needs.
--
Walter Rothe at the UNIX(Tm) Connection, Dallas, Tx
UUCP: {rutgers}!smu.killer.aimaniatope@enea.se (Tommy Petersson) (11/17/88)
In article <6053@killer.DALLAS.TX.US> aimania@killer.DALLAS.TX.US (Walter Rothe) writes:
:
:The Lucas board is a fantastic idea that should prolong the life of the 1000
:and 2000. Now if someone would just build a board like this with 64k of
:32 bit direct mapped cache on board and with capability of plugging in a
:68030 when it comes down in price.
:
Have I missed something? Isn't the Lucas Board just for the 1000?anakin@gpu.utcs.toronto.edu (Anakin Research) (11/17/88)
The Lucas Board works with a 2000 but the form factor makes it impossible to put the 2000 back together again. There are two people out there who are trying to use an adaptor link to make it fit. If they are successful I'll post a message. There also are two other people who have taken my PCAD files and are trying to lau out a board for the 2000. Again if they achieve any success I'm sure you'll hear about it. I have been asked many times why I developed the board only for the 1000. Firstly, that is the Amiga I have, and I do alot of animation and rendering. Having owned many orphaned machines I am just trying to breathe some more life into the ol' 1000. I believe the 1000 is the hacker's machine, and hackers are chronically broke. The 2000 is being fed by the market and I'm sure over the next year many 020 and 030 boards will become available. I have no wish to compete with these products as I'm sure they will likely be far more expandable and compatible than the Lucas board. I simply wanted the 020 and 881 with a couple of megs of 32-bit wide ram available for my renderings on the 1000. I felt that there were probably many out there with 1000's with the same needs so I made the project available as cheap as I could. The main reason for the async design was to make the chip sets which are available at 12 Meg. (relatively cheap) useable, as well as 20 meg parts if you can afford (read beg, borrow, or steal)useable as well. Brad Fowles anakin@utgpu
daveh@cbmvax.UUCP (Dave Haynie) (11/19/88)
in article <1988Nov17.141028.16337@gpu.utcs.toronto.edu>, anakin@gpu.utcs.toronto.edu (Anakin Research) says: > Keywords: Lucas 68020 68881 > Checksum: 51474 > There also are two other people who have taken my PCAD files and are > trying to lau out a board for the 2000. Again if they achieve any success > I'm sure you'll hear about it. If any of these folks are modifying the design to work as an A2000 CPU slot device, and need any help with the coprocessor slot protocol, let me know and I'll try to help out. > I have been asked many times why I developed the board only for the 1000. > Firstly, that is the Amiga I have, and I do alot of animation and rendering. A good portion of the 68020 boards sold so far are for this purpose. They ALWAY speed up rendering, but depending on the board design, the 32 bit memory available, and the hard disk controller, they can actually slow down some other things. > Having owned many orphaned machines I am just trying to breathe some more > life into the ol' 1000. I believe the 1000 is the hacker's machine, and > hackers are chronically broke. And the A1000 is really only a hardware orphan. I like the idea of PD hardware, and may have some available for the 1000 sometime soon. > The 2000 is being fed by the market and I'm sure over the next year many > 020 and 030 boards will become available. I have no wish to compete with > these products as I'm sure they will likely be far more expandable and > compatible than the Lucas board. And the current ones are. However, the LUCAS board is clocked faster than any of the commercially available boards. No one has yet marketed an asynchronous design, though I've heard rumors of at least three of them in the works. > I simply wanted the 020 and 881 with a couple of megs of 32-bit wide ram > available for my renderings on the 1000. Is there a 32 bit wide RAM design out for this yet? Just wondering; the 7.16MHz RAM boards for the A2000 are pretty much slam-dunk designs using standard DRAMs. Faster DRAM boards require lots more thought, and I'd be interested to see if anyone has it yet. > Brad Fowles anakin@utgpu -- 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