Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!rutgers!bpa!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: A2630 questions (for Dave Haynie this time) [REPOST] Keywords: A2630 Message-ID: <9731@cbmvax.commodore.com> Date: 19 Feb 90 19:21:54 GMT References: <1251@crash.cts.com> <9442@cbmvax.commodore.com> <1277@bmers58.UUCP> <1287@bmers58.UUCP> <9696@cbmvax.commodore.com> <-1773786386@convex.convex.com> Reply-To: daveh@cbmvax.cbm.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 95 In article <-1773786386@convex.convex.com> swarren@convex.com (Steve Warren) writes: >In article <9696@cbmvax.commodore.com> daveh@cbmvax.cbm.commodore.com (Dave Haynie) writes: >>By the rules, any device in the $00200000-$009FFFFF range MUST be autoconfiguring, >>and any device that doesn't autoconfigure MUST be located outside of that >>range. That puts extra 32 bit memory outside of the 68000's address space, >>since there isn't any other space available to add-ons in the 68000 address >>space. So if you follow the rules, on A2500/xx and below, all autoconfigured >>memory will be accessible by DMA device, no AddMemed memory will be. > [...] >Is this just because the controller can't get to the 'extended' address >bus bits for 32-bit processors? Yes, the reason the DMA devices can't DMA outside of the 68000 address space is their inherent addressing limitation. This is based on the Zorro II bus specification, which only tells you what to do with 24 bits of addressing information. >If so then the distinction would appear to be location in the address mapping, >not addmemed/non-addmemed (oh yes, you did mention that this applies for systems >that follow the rules. Is it illegal to have non-autoconfig devices within the >68000 address space?). Well, it is based on address mapping. The rules are that it's illegal to add a memory mapped expansion device that's not autoconfiguring, period. However, that's a bit restrictive; what's closer to the truth is that it's illegal to plug a device into the Zorro II bus that's not autoconfiguring, and it's also illegal to add a device through any other means that puts itself into space reserved by Commodore as motherboard space. The first restriction is a logical outgrowth of being a Zorro II board -- it's impossible to follow the Zorro II spec and still work without also being an autoconfiguring board -- this is enforced in hardware. This last restriction, of course, means that everyone who follows it will be happy in the future with new memory maps, and those that don't might have just hard-mapped their favorite toy over the space that Commodore was planning for some new thing on the next new motherboard. There is a bit of middle ground, that of the 32 bit address space. CBM wasn't the first to deliver a full 32 bit system, or desire more than an extra 8 megs or so of memory. There aren't alot of these systems running around with gobs of memory, but they do exist, and of course they had to put that memory somewhere. At the time, there was no great master plan through the 90's of where things go, so it has been pretty much up to the individual 32 bit card where memory goes. If it's possible for such memory to act as if it were a valid autoconfig device, I think it belongs in autoconfig space, at least up to the limits of memory. That's what we did on the A2620 and A2630. Once that space is out, autoconfig is impossible; there's no support in Zorro II for more than 24 bit addressing, in software or hardware. But some folks still want the memory. My guess at the time was "how about starting at the next 16 meg chunk and working your way up". But I see things like these extra memory cards, such as an A2630 daughterboard, very system-specific. You're not going to add 10 daughterboards, or 5, or even 2 to an A2630 -- you'll add one at most. So the location of the memory is not a serious problem, and hardwiring it to link it in with AddMem is the best solution for this kind of thing. >I am not making light of the "rules", I am just trying to make sure I >properly understand how they apply. I assume that DMA would be possible >via an extended bus connection? Perhaps by running an address-cable >with the extra bits directly to the card in question? That would allow >DMA to an AddMemed memory card. Would that be a problem? Given a new system, new DMA cards, new memory cards, etc. you could expect things to work pretty much like they do now -- everything autoconfigs, all support DMA, only in 32 instead of 24 bits. But there's no good way to retrofit this. If everyone back in 1985 had decided on some address extension spec, maybe now you'd have an extra cable or something, but nothing can be done at this point, and in general, that probably would not have been the proper solution. Either a card respects 32 bit addressing or it doesn't, there's no middle ground. Today's DMA cards very likely don't have the extra 8 bits available anywhere on them, probably not even at the register level. If you started running 32 bit cycles without more cleverness, you'd have all your 24 bit stuff responding to the 24 bit portion of a 32 bit address that in fact was looking for something outside of the 24 bit space. Believe me, there are solutions that are upward compatible to this kind of problem, but nothing that'll give you 32 bit DMA with today's 24 bit cards. >BTW, I would have redirected this to comp.sys.amiga.hardware, but this >group still hasn't shown up at our gateway, and then I wouldn't be able >to read the response. Who invoked the new group, and why are some of >us still not getting it? If it was done right it should show up >automatically, right? I think that was Ben Blish and the gang at BlackBelt Systems. I dunno this net stuff, but it all just magically appeared at my electronic front door one day. You may have to consult with the local usenet gurus on your end to see if they maybe need to request the new group(?). >--Steve -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough