apratt@atari.UUCP (Allan Pratt) (09/19/90)
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes: >Is the TT's memory mapped by the MMU so that it appears >contiguous? No. There is no address translation going on in the MMU. If there were, every program that wrote an address into a chip (video, DMA, etc.) would have to be able to do the logical-to-physical translation. This is impractical, and would result in nearly 100% incompatibility with existing programs. The MMU is used, however, so don't mess with it. It's used to get around a bug in the 68030's design; I may explain in more detail later. >I need this info for my hard disk driver which has to >decide if some transfer is to be made into fast or slow RAM. Right you are. That's what the _FRB cookie is for. But you are looking at the problem in the wrong terms: rather than deciding what kind of RAM the transfer is destined for, your program should decide only what it has to: in this case, decide if it's being made to/from a place that the ACSI DMA chip can access. This prevents you from hard-coding the location or size of different pieces of RAM. This saves you from having to re-release your driver when somebody complained that he couldn't access VME RAM with it, because you didn't think of that. The ACSI DMA chip can access memory only in the low 24 bits of the address space, so that's your answer: you check the high byte of the transfer address. If it's zero, you can use ACSI directly. If it's not, you must use the FRB. You never examine any part of the address other than the high byte, and you only test that against zero. Minimizing the information you require in this way leads to maximum portability and future compatibility. As an aside to SCSI driver writers, you have less to worry about. As mentioned above, the definition of accessibility on the ACSI bus is "the high byte must be zero." The definition of accessibility on the SCSI bus is "the bus must be 32 bits wide." This means that A24/D16 VME memory is not accessible to SCSI, and you should use the buffer pointed to by the _FRB cookie. Finally, to defeat nit-pickers before they strike, I *know* that the ACSI DMA chip can't really talk to everything in the 24-bit ST address space: it can't see ROM, for example. But it *can* access any real RAM in that space, and if you're trying to DMA to something else (like the palette) you deserve what you get. >---------------------------------------------------------------------- >Claus Brod, Am Felsenkeller 2, Things. Take. Time. >D-8772 Marktheidenfeld, West Germany (Piet Hein) >csbrod@medusa.informatik.uni-erlangen.de >---------------------------------------------------------------------- ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (09/19/90)
apratt@atari.UUCP (Allan Pratt) writes: >The ACSI DMA chip can access memory only in the low 24 bits of the >address space, so that's your answer: you check the high byte of the >transfer address. If it's zero, you can use ACSI directly. If it's >not, you must use the FRB. You never examine any part of the address >other than the high byte, and you only test that against zero. Ah, that's it. Tnx! >VME memory is not accessible to SCSI, and you should use the buffer >pointed to by the _FRB cookie. Hum, hum, and how do we detect that some RAM is a) VME RAM and b) 16 bits wide? Did I miss something here? ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
apratt@atari.UUCP (Allan Pratt) (09/21/90)
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes: >apratt@atari.UUCP (Allan Pratt) writes: >>VME memory is not accessible to SCSI, and you should use the buffer >>pointed to by the _FRB cookie. >Hum, hum, and how do we detect that some RAM is a) VME RAM and b) 16 >bits wide? Did I miss something here? My comment about VME RAM was not clear. In the TT030, which is the full name of the machine that's now available, there are two kinds of VME address space: A24/D16 and A16/D8. These are not 32 bits wide, so the SCSI chip can't access them. The memory map, telling where in memory those segments appear, should be part of the TT documentation: if it's not, it will be. The VME expansion isn't really for RAM anyway: VME RAM for a TT is expensive and slow -- slow because it's only 16 bits wide, because it goes through the VME bus, and because it's not cacheable by the 68030. You're far more likely to want to put a video display card there, or extra serial ports or something. For those, the fact that the processor can't get at the memory at full speed won't hurt too much. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
tony@raid5.uucp (Tony Andrews) (09/23/90)
In article <2310@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >My comment about VME RAM was not clear. In the TT030, which is the >full name of the machine that's now available, there are two kinds of >VME address space: A24/D16 and A16/D8. These are not 32 bits wide, so >the SCSI chip can't access them. The memory map, telling where in >memory those segments appear, should be part of the TT documentation: >if it's not, it will be. The thing that has interested me most about the TT is that it is probably going to be the cheapest VME machine around. My company develops disk arrays that operate over the VME interface (among others). We currently find it difficult to give each software developer their own VME host and disk array. A cheap VME machine like the TT might change all that (once a UNIX port is available, anyway). Could you give me some more specifics about the VME on the TT? Is it a 6U card cage? How many slots are available? How much power is available? Are A24/D16 and A16/D8 the only supported modes? (A16/D16 would be nice.) Is host memory accessible by VME bus masters? -- Tony Andrews uunet!dunike!onecom!raid5!tony Array Technology Corp. 4775 Walnut St., Suite B Boulder, Colorado 80301 USA
apratt@atari.UUCP (Allan Pratt) (09/26/90)
tony@raid5.uucp (Tony Andrews) writes: >Could you give me some more specifics about the VME on the TT? Is >it a 6U card cage? How many slots are available? How much power >is available? Are A24/D16 and A16/D8 the only supported modes? >(A16/D16 would be nice.) Is host memory accessible by VME bus >masters? I misspoke: A16/D16 is available. There is only one slot, but I have seen a new box for the TT030 with many VME slots -- this was from another company, in Germany, but it proves it can be done. I think the internal slot is half-Eurocard, 3U. If I'm abusing the VME terminology, I apologize: I don't really grasp it myself. The cards I've seen that fit are about 6.5" by 4.5". Host memory is not accessible through the VME bus -- that is, a VME card in the TT030 cannot be a bus master. My standard answer on this subject is as follows: "It is not unreasonable to suppose that there may be a future machine from Atari with a full-size, full-feature, multi-slot VMEbus interface." ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
ckp@grebyn.com (Checkpoint Technologies) (09/26/90)
In article <2304@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >with existing programs. The MMU is used, however, so don't mess with >it. It's used to get around a bug in the 68030's design; I may explain >in more detail later. Well, you got me curious, so go ahead and explain it. There's a bug in the 68030 design that can be fixed via the MMU? Is it perhaps related to the behavior of the instruction and data caches? -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
daveh@cbmvax.commodore.com (Dave Haynie) (09/27/90)
In article <22218@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <2304@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >>The MMU is used, however, so don't mess with it. It's used to get around >>a bug in the 68030's design; I may explain in more detail later. >Well, you got me curious, so go ahead and explain it. There's a bug >in the 68030 design that can be fixed via the MMU? Is it perhaps >related to the behavior of the instruction and data caches? It's a data cache anomaly. There are two data caching modes, standard and write allocate; the latter is required for cache consistency when user and supervisor data spaces access the same logical memory. However, in write allocate mode, the data cache is updated on writes. If you write a longword aligned longword to a longword port, the cache entry is marked valid. In all modes, the write cycle ignores the CIIN* signal (hardware driven cache inhibit), so this can be a problem in dealing with things like 32 bit I/O registers, since you'll end up caching the register even if hardware tries to inhibit such caching (which would be natural for any I/O operation). While there are several ways around this problem, the simplest is to use the MMU and make all your I/O pages uncachable. The caches always obey the MMU table entry... >First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM