gbuce@pixar.UUCP (George Buce) (03/10/89)
[Oh yeah? Try eating this!]
A while ago I mailed this fix to Brad Fowles as a fix for the U9 swapping on
the LUCAS boards. I haven't gotten a response (I don't know of the mail ever
reached anakin), so I'm posting this to usenet hoping it will help some folks.
If someone spots a problem with this, please feel free to point it out...
Well, this U9 fix seems to work. The problem seems to be in the area where
Brad re-generates C1* + C3* by using 7MB2. The problem stems from the fact
that there is no way to know if the regenerated signal is low during S1 and S5
or if it is low during S3 and S7, since the 7MB2 signal starts up at a random
state. What I had proposed in my previous note was to somehow sync up the 7MB2
signal with the falling edge of 68000 S5, possibly by using the first DTACK*
from the system. Well, that's exactly what I did. Since we know that the first
DTACK* comes from within the Amiga during the call to ROM directly after reset,
and the Amiga specs state that you aren't allowed to return DTACK* before the
beginning of S4, we know that the DTACK signal will fall somewhere during the
S4 state. What my fix does it to hold the 7MB2 flip-flop in a preset state
(with the 7MB2 signal going into U6 held low) until the first occurence of
DTACK*'s falling edge. The 7MB2 is then allowed to free run starting with the
rising edge of 7M at the beginning of S6. This guarantees that we will
correctly generate C1* + C3* by ORing 7M and 7MB2.
(Schematic follows...)
The fix consists of a piggy back 74LS74 over the U9 74x74. I first bent up pin
10 of the bottom (U9) 74x74. I then clipped pins 5, 6 and 9 of the top 74LS74
and bent up pins 8, 10, 11 and 12. The remaining pins of the top 74LS74 are
soldered directly to the corresponding pins of the bottom U9 74x74. These pins
should be pins 1, 2, 3, 4, 7, 13 and 14. Pin 10 of the bottom U9 74x74 should
be connected to pin 8 of the piggyback 74LS74. (I just bent the pins together
(veeery carfully!) but you may want to use a small wire.) Pin 12 is tied to
ground (on the chip stack is easiest) At the 68000 socket, DTACK* (pin 10?) is
tapped into and run to the unused inverter at U10, pin 9. The output at U10,
pin 8 is run to the DTACK input on the piggyback flip-flop (called U12 from
here on) pin 11. The 68000 RESET* (pin 18?) line is tapped into and run to U12,
pin 10. This fix does not require any cuts to the main circuit board, so it's
always easy to undo.
+---------------+
| +5V |
| | |
| 13| |
| ------- |
| 12| C |9 |
+---|D Q|-- |
11| U9b _|8 |
7M ----|> Q|---+---- 7MB2
| P |
-------
+5V 10| 74F74
| |
13| |
------- |
12| C |9 |
U10 GND----|D Q|-- |
_____ |\ 11| U12b_|8 |
DTACK------O| >-----------|> Q|----------+
9 |/ 8 | P |
74F04 -------
10| 74LS74
_____ |
RESET-------------+
Theory of Operation:
The theory of operation is rather straightforward. Upon system RESET, the
flip-flop at U12 is preset so that the Q* output at pin 8 is low. This presets
U9b so that the Q* output (named 7MB2) is low. Having 7MB2 remain low means
that the DTPRELIM* signal will be generated everytime the 7MHz clock is low.
The first DTACK* from the Amiga will arrive during 68000 state S4, permitting
DTTRIG* to be generated during S5. The first DTACK* will also clock in a zero
on U12, releasing the RESET line on U9. This will permit 7MB2 to continue
operating normally from that point on, remaining in sync with 68000 state S5 as
is needed to synchronise the 68020 with the 68000.
Before this mod, I could only get the LUCAS board to boot up with a 12MHz xtal
and a 74HC74. I took two 74LS74s for this piggyback fix and had no problem
booting up at 20MHz. As far as using 74LS parts, I don't see any reason why a
part any faster than 74LS would be needed. Since the 7MB2 signal is rather
slow and we don't care how slow the piggyback U12 responds to DTACK*, the only
question that remains is whether or not U9a latching SYSDSACK1* is fast enough.
The arrival of the DTTRIG* signal is totally asynchronous to the 16M clock, so
if it arrives a little after the setup time for U9a, we'll miss it until the
next rising edge of 16M. That's probably the safest thing to do, since
otherwise the DSACKx* to DATA valid timing will be a little tight... I just
recieved the latest on the LUCAS board concerning DMA access (and eliminating
the synchronization on the R/W line). If that half a flip-flop will be unused,
people could avoid a piggyback fix by using the abandoned R/W flip-flop. (BTW,
thanks to Brad for not tying the unused input on the 'F04 inverter to power or
ground. That made this a "no cuts" fix 8{)...)
I hope this helps. I'm still having problems with a Micron 2Meg board working
with the LUCAS board, but I'm working on it.
George (8{>
+-----------------------------------------------------------------------------+
| George Buce (8{> | Disclaimer: Of course I don't represent Pixar. |
|...!ucbvax!pixar!gbuce | Discourager: They don't use Amigas... 8{( |
+-----------------------------------------------------------------------------+
| Boys and Girls, can you say sixty four bitplanes? |
| How about $30,000 ? Sure... I knew you could... |
+-----------------------------------------------------------------------------+daveh@cbmvax.UUCP (Dave Haynie) (03/14/89)
in article <3291@pixar.UUCP>, gbuce@pixar.UUCP (George Buce) says: > Keywords: LUCAS 68020 accelerator u9 swapping fix > Summary: no more U9 swapping > Since we know that the first DTACK* comes from within the Amiga during the > call to ROM directly after reset, and the Amiga specs state that you aren't > allowed to return DTACK* before the beginning of S4, we know that the DTACK > signal will fall somewhere during the S4 state. No, actually, we don't KNOW that (I'm not sure if it's true for an unexpanded A1000, but it's not true for an unexpanded A500 or A2000). The bus master (the 68020, in this case) can't ACT on DTACK* before the falling edge of S4, which is where DTACK* should be sampled by a device like LUCAS. But DTACK* can really fall at any time, legally. In fact, you almost certainly get a glitch on DTACK* at around S3 when asserting OVR* from the expansion bus to drive your own DTACK*. That's nothing to worry about, though, based on the definition (from the 68000 spec) that DTACK* isn't sampled until that S4 edge. With that said, your fix probably has a good chance of working on an A1000 with no memory added, based on the way DTACK* is actually generated by the 1000. With external memory added, there's no guarantee you'll stay synced, since a memory board or other expansion device can legally add any number of wait states, which looks like it would be bad if you're really trying to stay synched to a particular part of the Agnus cycle. > George (8{> -- 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
gbuce@pixar.UUCP (George Buce) (03/15/89)
In article <6232@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <3291@pixar.UUCP>, gbuce@pixar.UUCP (George Buce) says: >> Since we know that the first DTACK* comes from within the Amiga during the >> call to ROM directly after reset, and the Amiga specs state that you aren't >> allowed to return DTACK* before the beginning of S4, we know that the DTACK >> signal will fall somewhere during the S4 state. > >No, actually, we don't KNOW that (I'm not sure if it's true for an unexpanded >A1000, but it's not true for an unexpanded A500 or A2000). The bus master >(the 68020, in this case) can't ACT on DTACK* before the falling edge of >S4, which is where DTACK* should be sampled by a device like LUCAS. > --- >With that said, your fix probably has a good chance of working on an A1000 >with no memory added, based on the way DTACK* is actually generated by the >1000. With external memory added, there's no guarantee you'll stay synced, Actually, since we're only interested in re-generating C1* + C3* on the LUCAS board and only need to sync it once (after the initial reset), I don't see how the external memory boards can be a problem. I haven't done any developing since the A500/A2000 were introduced, but since the autoconfig boards aren't enabled directly after a reset, I can't imagine that there would be a glitch during S3. The only thing we're interested is the *very first call* the 68000 makes to the Amiga, which is going to be a read to the ROM. Does Fat Agnus respond with DTACK* during S3? If so, then my 'U9 fix' won't work on an A500 or A2000 (thought the LUCAS wasn't designed for them...) Will a soft reset still generate a call to the ROMs before autobooting off of RAD:? (Brad, correct me if I'm wrong, but) The LUCAS board seems to handle refresh wait state de-synchronisation by extending the wait until it is in sync with an original S5 state again... >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 George (8{> +-----------------------------------------------------------------------------+ | George Buce (8{> | Disclaimer: Of course I don't represent Pixar. | |...!ucbvax!pixar!gbuce | Discourager: They don't use Amigas... 8{( | +-----------------------------------------------------------------------------+ | Boys and Girls, can you say 80 Mbytes per second? (hard disk transfer speed)| | How about $7,500? Sure... I knew you could... (*actual milage may vary) | +-----------------------------------------------------------------------------+
anakin@gpu.utcs.toronto.edu (Anakin Research) (03/15/89)
>>daveh@cbmvax.UUCP (Dave Haynie) writes: >>in article <3291@pixar.UUCP>, gbuce@pixar.UUCP (George Buce) says: >>> Since we know that the first DTACK* comes from within the Amiga during the >>> call to ROM directly after reset, and the Amiga specs state that you aren't >>> allowed to return DTACK* before the beginning of S4, we know that the DTACK >>> signal will fall somewhere during the S4 state. >> >>No, actually, we don't KNOW that (I'm not sure if it's true for an unexpanded >>A1000, but it's not true for an unexpanded A500 or A2000). The bus master >>(the 68020, in this case) can't ACT on DTACK* before the falling edge of >>S4, which is where DTACK* should be sampled by a device like LUCAS. >> --- >>With that said, your fix probably has a good chance of working on an A1000 >>with no memory added, based on the way DTACK* is actually generated by the >>1000. With external memory added, there's no guarantee you'll stay synced, >Actually, since we're only interested in re-generating C1* + C3* on the LUCAS >board and only need to sync it once (after the initial reset), I don't see how >the external memory boards can be a problem. I haven't done any developing >since the A500/A2000 were introduced, but since the autoconfig boards aren't >enabled directly after a reset, I can't imagine that there would be a glitch >during S3. The only thing we're interested is the *very first call* the 68000 >makes to the Amiga, which is going to be a read to the ROM. Does Fat Agnus >respond with DTACK* during S3? If so, then my 'U9 fix' won't work on an A500 >or A2000 (thought the LUCAS wasn't designed for them...) Will a soft reset >still generate a call to the ROMs before autobooting off of RAD:? (Brad, >correct me if I'm wrong, but) The LUCAS board seems to handle refresh wait >state de-synchronisation by extending the wait until it is in sync with an >original S5 state again... Yes George, you are correct! LUCAS can startup on the wrong side of the C1+*C3 cycle. and your fix corrects that problem. Once your in sync, the circuitry on the LUCAS board takes care to sync up to the S5 state as you surmised. This is a startup problem which appears to affect about 10% of the Amiga's out there, judging by the reports I receive. I have yet to have someone with this problem not have it eliminated by your fix. Turning the machine off and on again a couple of times also works, but that's pretty tacky. Brad
papa@pollux.usc.edu (Marco Papa) (03/16/89)
This is the kind of stuff for comp.sys.amiga.tech. Move it there, please. Thank you. -- 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] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
hbit@PacBell.COM (Henry Bitter) (05/27/89)
For those of you who said they didn't see the "Pixar Fix" I am reposting it for george who no longer works at Pixar. From pacbell!ames!ll-xn!mit-eddie!uw-beaver!cornell!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!pixar!gbuce Mon Mar 13 07:45:10 PST 1989 Article: 32798 of comp.sys.amiga: Path: pbhya!pacbell!ames!ll-xn!mit-eddie!uw-beaver!cornell!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsfcgl!pixar!gbuce >From: gbuce@pixar.UUCP (George Buce) Newsgroups: comp.sys.amiga Subject: LUCAS board fix (long)(technical) Summary: no more U9 swapping Keywords: LUCAS 68020 accelerator u9 swapping fix Message-ID: <3291@pixar.UUCP> Date: 9 Mar 89 22:11:46 GMT Reply-To: gbuce@pixar.UUCP (George Buce) Organization: Pixar -- Marin County, California Lines: 106 [Oh yeah? Try eating this!] A while ago I mailed this fix to Brad Fowles as a fix for the U9 swapping on the LUCAS boards. I haven't gotten a response (I don't know of the mail ever reached anakin), so I'm posting this to usenet hoping it will help some folks. If someone spots a problem with this, please feel free to point it out... Well, this U9 fix seems to work. The problem seems to be in the area where Brad re-generates C1* + C3* by using 7MB2. The problem stems from the fact that there is no way to know if the regenerated signal is low during S1 and S5 or if it is low during S3 and S7, since the 7MB2 signal starts up at a random state. What I had proposed in my previous note was to somehow sync up the 7MB2 signal with the falling edge of 68000 S5, possibly by using the first DTACK* from the system. Well, that's exactly what I did. Since we know that the first DTACK* comes from within the Amiga during the call to ROM directly after reset, and the Amiga specs state that you aren't allowed to return DTACK* before the beginning of S4, we know that the DTACK signal will fall somewhere during the S4 state. What my fix does it to hold the 7MB2 flip-flop in a preset state (with the 7MB2 signal going into U6 held low) until the first occurence of DTACK*'s falling edge. The 7MB2 is then allowed to free run starting with the rising edge of 7M at the beginning of S6. This guarantees that we will correctly generate C1* + C3* by ORing 7M and 7MB2. (Schematic follows...) The fix consists of a piggy back 74LS74 over the U9 74x74. I first bent up pin 10 of the bottom (U9) 74x74. I then clipped pins 5, 6 and 9 of the top 74LS74 and bent up pins 8, 10, 11 and 12. The remaining pins of the top 74LS74 are soldered directly to the corresponding pins of the bottom U9 74x74. These pins should be pins 1, 2, 3, 4, 7, 13 and 14. Pin 10 of the bottom U9 74x74 should be connected to pin 8 of the piggyback 74LS74. (I just bent the pins together (veeery carfully!) but you may want to use a small wire.) Pin 12 is tied to ground (on the chip stack is easiest) At the 68000 socket, DTACK* (pin 10?) is tapped into and run to the unused inverter at U10, pin 9. The output at U10, pin 8 is run to the DTACK input on the piggyback flip-flop (called U12 from here on) pin 11. The 68000 RESET* (pin 18?) line is tapped into and run to U12, pin 10. This fix does not require any cuts to the main circuit board, so it's always easy to undo. +---------------+ | +5V | | | | | 13| | | ------- | | 12| C |9 | +---|D Q|-- | 11| U9b _|8 | 7M ----|> Q|---+---- 7MB2 | P | ------- +5V 10| 74F74 | | 13| | ------- | 12| C |9 | U10 GND----|D Q|-- | _____ |\ 11| U12b_|8 | DTACK------O| >-----------|> Q|----------+ 9 |/ 8 | P | 74F04 ------- 10| 74LS74 _____ | RESET-------------+ Theory of Operation: The theory of operation is rather straightforward. Upon system RESET, the flip-flop at U12 is preset so that the Q* output at pin 8 is low. This presets U9b so that the Q* output (named 7MB2) is low. Having 7MB2 remain low means that the DTPRELIM* signal will be generated everytime the 7MHz clock is low. The first DTACK* from the Amiga will arrive during 68000 state S4, permitting DTTRIG* to be generated during S5. The first DTACK* will also clock in a zero on U12, releasing the RESET line on U9. This will permit 7MB2 to continue operating normally from that point on, remaining in sync with 68000 state S5 as is needed to synchronise the 68020 with the 68000. Before this mod, I could only get the LUCAS board to boot up with a 12MHz xtal and a 74HC74. I took two 74LS74s for this piggyback fix and had no problem booting up at 20MHz. As far as using 74LS parts, I don't see any reason why a part any faster than 74LS would be needed. Since the 7MB2 signal is rather slow and we don't care how slow the piggyback U12 responds to DTACK*, the only question that remains is whether or not U9a latching SYSDSACK1* is fast enough. The arrival of the DTTRIG* signal is totally asynchronous to the 16M clock, so if it arrives a little after the setup time for U9a, we'll miss it until the next rising edge of 16M. That's probably the safest thing to do, since otherwise the DSACKx* to DATA valid timing will be a little tight... I just recieved the latest on the LUCAS board concerning DMA access (and eliminating the synchronization on the R/W line). If that half a flip-flop will be unused, people could avoid a piggyback fix by using the abandoned R/W flip-flop. (BTW, thanks to Brad for not tying the unused input on the 'F04 inverter to power or ground. That made this a "no cuts" fix 8{)...) I hope this helps. I'm still having problems with a Micron 2Meg board working with the LUCAS board, but I'm working on it. George (8{> +-----------------------------------------------------------------------------+ | George Buce (8{> | Disclaimer: Of course I don't represent Pixar. | |...!ucbvax!pixar!gbuce | Discourager: They don't use Amigas... 8{( | +-----------------------------------------------------------------------------+ | Boys and Girls, can you say sixty four bitplanes? | | How about $30,000 ? Sure... I knew you could... | +-----------------------------------------------------------------------------+ Henry Bitter * Pacific Bell * (415) 823-2836 San Ramon, Calif. { }!pacbell!pbhya!hbit If I had a disclaimer I wouldn't give it away !