raz%kilowatt@Sun.COM (Steve -Raz- Berry) (08/05/89)
Time for the hardware guys to get a question in sideways... Here's the situation. I am doing this project that might or might not make my Amiga (B2000) go a lot faster. In reading thru the hardware Tech manual I came across this ambiguity... IF you are responding to a VPA* signal because the GARY chip decodes a periphal address, does this mean that DTACK* is *not* asserted during this cycle ??? The 68K manual says it's not, but the GARY chip isn't in the 68K manual. Ok, now for the even more advanced students, do the 8520's respond to VMA* by issuing an INT6/2* ? And if so can I assume that Paula will suck up this interrupt and generate an IPL code that I will have to feed to my 68020 ??? Can I assert AUTO* right away when I detect an interrupt ? Or do I have to wait until everybody goes tri-state before I drop AUTO* ??? Hmm, I wonder how many people are going to figure out what I am tring to build here? ;-) All the signals that I am refering to are those seen at the co-processor card edge. As always, any help given is appreciated muchly. --- Steve -Raz- Berry Disclaimer: It wasn't me! I was volatilizing my esters. UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
grr@cbmvax.UUCP (George Robbins) (08/06/89)
In article <119697@sun.Eng.Sun.COM> raz%kilowatt@Sun.COM (Steve -Raz- Berry) writes: > > Here's the situation. I am doing this project that might or might not > make my Amiga (B2000) go a lot faster. In reading thru the hardware > Tech manual I came across this ambiguity... > > IF you are responding to a VPA* signal because the GARY chip decodes a > periphal address, does this mean that DTACK* is *not* asserted during > this cycle ??? The 68K manual says it's not, but the GARY chip isn't > in the 68K manual. DTACK isn't asserted, since it these cyles are self-terminating. > Ok, now for the even more advanced students, do the 8520's respond to > VMA* by issuing an INT6/2* ? And if so can I assume that Paula will > suck up this interrupt and generate an IPL code that I will have to > feed to my 68020 ??? Can I assert AUTO* right away when I detect an > interrupt ? Or do I have to wait until everybody goes tri-state before > I drop AUTO* ??? Huh? Interrupts are done in a simple, but not obvious way. The processor does an ineterrupt acknowledge cycle. The address lines during this cycle are clearly defined and based on the IPL being service. The address selects ROM. The vector numbers are read from ROM, not any peripheral device. Co-processor boards are free to do AVEC type interrupts if they do the function code decoding, the results are equivalent. Real vectored with codes from the devices and whatnot aren't adequeatly supported by the expansion bus - no priority chains or encoding. You sound generally confused about 68000 interrupts though. > Hmm, I wonder how many people are going to figure out what I am tring > to build here? ;-) Well, have fun, but beware of reventing the wheel. There are reasonable coprocessor solutions out there from hacker kit to high dollar already. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
raz%kilowatt@Sun.COM (Steve -Raz- Berry) (08/06/89)
In article <7553@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <119697@sun.Eng.Sun.COM> raz%kilowatt@Sun.COM (Steve -Raz- Berry) writes: >> Ok, now for the even more advanced students, do the 8520's respond to >> VMA* by issuing an INT6/2* ? And if so can I assume that Paula will >> suck up this interrupt and generate an IPL code that I will have to >> feed to my 68020 ??? Can I assert AUTO* right away when I detect an >> interrupt ? Or do I have to wait until everybody goes tri-state before >> I drop AUTO* ??? >Huh? Interrupts are done in a simple, but not obvious way. The processor >does an ineterrupt acknowledge cycle. The address lines during this cycle >are clearly defined and based on the IPL being service. The address selects >ROM. The vector numbers are read from ROM, not any peripheral device. >Co-processor boards are free to do AVEC type interrupts if they do the >function code decoding, the results are equivalent. Real vectored >with codes from the devices and whatnot aren't adequeatly supported by >the expansion bus - no priority chains or encoding. Ok, so you got me. I confused the name of the AVEC* line. I was thinking about AUTOvectoring, and my fingers did the rest. This is what I needed to know, thanks. >You sound generally confused about 68000 interrupts though. Only slightly. It's not always easy dealing with custom hardware and two different processors. If this was a simpler machine, I wouldn't have had to ask ;-) >Well, have fun, but beware of reventing the wheel. There are reasonable >coprocessor solutions out there from hacker kit to high dollar already. >George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr Hacker kit? Hmm, I haven't seen anything like this for the 2000. LUCAS is the only thing that immediately comes to mind, and that's the wrong Amiga. I won't settle for anything less than a accellorator that plugs into the coprocessor slot and allows me the upgrade path to 32 bit ram. I haven't seen anything on the market that I can personally afford. I don't really mind if I re-invent things either, I'm doing this for fun/education so it doesn't have to be original. Besides, I can put in the stuff that *I* consider important. As an added side affect, it's cheaper too. --- Steve -Raz- Berry Disclaimer: It wasn't me! I was volatilizing my esters. UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
grr@cbmvax.UUCP (George Robbins) (08/07/89)
In article <119763@sun.Eng.Sun.COM> raz@sun.UUCP (Steve -Raz- Berry) writes: > In article <7553@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > > >Well, have fun, but beware of reventing the wheel. There are reasonable > >coprocessor solutions out there from hacker kit to high dollar already. > > >George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr > > > Hacker kit? Hmm, I haven't seen anything like this for the 2000. LUCAS > is the only thing that immediately comes to mind, and that's the wrong > Amiga. I won't settle for anything less than a accellorator that plugs > into the coprocessor slot and allows me the upgrade path to 32 bit ram. > I haven't seen anything on the market that I can personally afford. > > I don't really mind if I re-invent things either, I'm doing this for > fun/education so it doesn't have to be original. Besides, I can put in > the stuff that *I* consider important. OK, just be warned that the do-it-exactly-right '020 and '030 interfaces are non-trivial. Little details just keep popping up and kicking you back in the direction of square 1. I haven't seen a Lucas boards, though the noises are generally positive. You might comtemplate implementing one on a PCB to fit the A2000 slot. Note that I'm not stating whether the Lucas board is 100% right or not, but at least it's an active project and you stand a chance of finding out how to fix/upgrade it... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
daveh@cbmvax.UUCP (Dave Haynie) (08/08/89)
in article <119697@sun.Eng.Sun.COM>, raz%kilowatt@Sun.COM (Steve -Raz- Berry) says: > Keywords: hardware hairy hendersons VMA* VPA* DTACK* and their brothers. > Time for the hardware guys to get a question in sideways... > IF you are responding to a VPA* signal because the GARY chip decodes a > periphal address, does this mean that DTACK* is *not* asserted during > this cycle ??? The 68K manual says it's not, but the GARY chip isn't > in the 68K manual. Correct -- DTACK* isn't asserted during VPA*, however, only the 8520s are supposed to respond using the VPA*/VMA* mechanism. While these signals are present on the expansion bus, and an expansion card could be carefully designed to fit a device or two in the decoded space unused by the 8520s, this isn't supported, and is guaranteed to break in a future system. Thus, the VPA*/VMA* mechanism is officially a motherboard-only resource. > Ok, now for the even more advanced students, do the 8520's respond to > VMA* by issuing an INT6/2* ? And if so can I assume that Paula will > suck up this interrupt and generate an IPL code that I will have to > feed to my 68020 ??? VMA* and the interrupts are separate concepts. An 8520, as with most devices that generate interrupts, will generate an interrupt at any time, at least from the processor's point of view. The INT2* and INT6* lines are in fact fed to Paula, who does synchronize them and priority encode them with any custom chip based interrupts to generate the appropriate IPL code. For a read or write of an 8520, Gary decodes the 8520 addresses and generates VPA*, the 8520 chip selects are generated based on either A12 or A13 going low with VMA*, depending on which 8520 you're talking to. > Can I assert AUTO* right away when I detect an interrupt ? Or do I have to > wait until everybody goes tri-state before I drop AUTO* ??? The autovector signal should be the same for any interrupt. You can generate it based on a CPU space decode of an interrupt acknowledge cycle alone if you like; it's a cycle terminator, just like DSACKx*, STERM*, or BERR*. Such a cycle should not be made visible to the system outside the 68020/30, though in practice it's not a problem, since it ends up reading ROM space anyway as I recall. > Hmm, I wonder how many people are going to figure out what I am tring > to build here? ;-) Well, it sounds like you're interested in the normal way of building a 68020 or 68030 CPU interface for an A2000 type machine; far as I know, everyone does AVEC in much the same way. It still doesn't make your 8520 interrupts fast, since they get vectored to a table that's in Chip memory unless you use the VPA register, which apparently isn't supported in 1.3, or use some MMU tricks. > Steve -Raz- Berry Disclaimer: It wasn't me! I was volatilizing my esters. > UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com > KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it
grr@cbmvax.UUCP (George Robbins) (08/08/89)
In article <7563@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: > in article <119697@sun.Eng.Sun.COM>, raz%kilowatt@Sun.COM (Steve -Raz- Berry) says: > > Keywords: hardware hairy hendersons VMA* VPA* DTACK* and their brothers. > > > Well, it sounds like you're interested in the normal way of building a 68020 > or 68030 CPU interface for an A2000 type machine; far as I know, everyone > does AVEC in much the same way. It still doesn't make your 8520 interrupts > fast, since they get vectored to a table that's in Chip memory unless you > use the VPA register, which apparently isn't supported in 1.3, or use some > MMU tricks. Gawd Dave, it must be getting late. It's the VBR register (vector base reg), and maybe it'll be supported eventually if/when available. However, some discussion with the software folk reveals that simply getting the vectors out of chip ram is only a partial solution. The software has to make several access to chip registers as part of the interrupt serivce/analysis processing, so all you can do is reduce the number of "slow" accesses, not eliminate them. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
raz%kilowatt@Sun.COM (Steve -Raz- Berry) (08/10/89)
In article <7563@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <119697@sun.Eng.Sun.COM>, raz%kilowatt@Sun.COM (Steve -Raz- Berry) says: >> Hmm, I wonder how many people are going to figure out what I am tring >> to build here? ;-) >Well, it sounds like you're interested in the normal way of building a 68020 >or 68030 CPU interface for an A2000 type machine; far as I know, everyone >does AVEC in much the same way. It still doesn't make your 8520 interrupts >fast, since they get vectored to a table that's in Chip memory unless you >use the VPA register, which apparently isn't supported in 1.3, or use some >MMU tricks. Not exactly. Right now my system has a boring old 68K in it. I want to make the *whole* machine go faster, not just this one part of the protocal. >-- >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" > Be careful what you wish for -- you just might get it I wish for a free A2630 w/4meg ram ;-) Thanks for the response. But since I have your attention, might I impose on you for some more information? Right now I have a way of disabling the 68K on the 2000's motherboard, but I would be very interested in hearing a brief description from you on the particular timing involved. The way I am approaching it now is to wait for the Ami to come out of reset before I issue CBR*. Also if you have any thoughts that you would care to share on any particular signals to watch out for, I'd be mighty interested. As George said, I keep getting knocked back to square one, (lately on the clk high to FC valid timing - why oh why is it different than address valid to AS* asserted???) and I'd like to eliminate as much of that as possible. --- Steve -Raz- Berry Disclaimer: It wasn't me! I was volatilizing my esters. UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
daveh@cbmvax.UUCP (Dave Haynie) (08/11/89)
in article <120525@sun.Eng.Sun.COM>, raz%kilowatt@Sun.COM (Steve -Raz- Berry) says: > Right now I have a way of disabling the 68K on the 2000's motherboard, > but I would be very interested in hearing a brief description from > you on the particular timing involved. The way I am approaching it now > is to wait for the Ami to come out of reset before I issue CBR*. That's pretty much what the A2620/30 do. They sit and wait for reset to end, and actually for the first cycle to start, then kick in the CBR* -> CBG* -> BOSS* sequence. The main reason for that is that we weren't sure just when the 68000's arbiter woke up when we did the A2620, and I didn't have any reason to change it for the A2630, though I'm certain there's no reason to wait for the first cycle to start. > Also if you have any thoughts that you would care to share on any > particular signals to watch out for, I'd be mighty interested. As > George said, I keep getting knocked back to square one, (lately on the > clk high to FC valid timing - why oh why is it different than address > valid to AS* asserted???) and I'd like to eliminate as much of that as > possible. Clock high to FC/Address is just a different spec than FC/Address to AS*. OK, it's been awhile since I looked at the 68000 spec, but certainly on 68030s, FC and Address are the same thing, timing wise. Since function codes are really an extension of the Address, you wouldn't expect them to act any differently than the Addresses do, eh? > Steve -Raz- Berry Disclaimer: It wasn't me! I was volatilizing my esters. -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Be careful what you wish for -- you just might get it
raz%kilowatt@Sun.COM (Steve -Raz- Berry) (08/11/89)
In article <7617@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Clock high to FC/Address is just a different spec than FC/Address to AS*. >OK, it's been awhile since I looked at the 68000 spec, but certainly on >68030s, FC and Address are the same thing, timing wise. Since function >codes are really an extension of the Address, you wouldn't expect them to >act any differently than the Addresses do, eh? No, that's the kicker. Any more like that just hanging around waiting to bite me? >Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Back to the timing diagrams... --- Steve -Raz- Berry Disclaimer: It wasn't me! I was volatilizing my esters. UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com