Author: Johan Klockars (as12-5-4.kp.g.bonet.se)
Date: 01-27-2002 16:50
> and their suggestion was: Since the SDRAM
> is 64 bit wide and every byte has a
> parity bit, we have a total of 72 bits on
> one DIMM,
I know you've given up on this now, but I just thought I should clarify a couple of things.
PC66/100/133 SDRAM normally does not have parity. You can find it with ECC, though (for a lot of extra money). Even if you had 8 extra bits per module, the CPU would have been unable to write those bits in any normal way, however.
> RAM clocked at twice the CPU speed, then
> the VIDEL and the CPU could access RAM
> each other time, without interruptions,
An individual access to SDRAM takes something on the order of half a dozen (bus-)clock cycles, so you would not want to do it quite that way. Rather, you'd do a burst of several words at a time into a buffer in your RAM controller.
Since the '040 only has a 32 bit bus, there should be lots of free bandwidth even with a 66 MHz (64 bit wide) bus, and that should be significantly easier to get to work.
Since people are likely to want PCI, I'd suggest you go that way regarding the video in any case. Sure, it will not be 100% compatible, but it will be flexible and fast.
> human eye canīt tell any difference
> between 24, 30 or 36 bit color, so
While that is indeed a common belief, it is not entirely true. You may not be able to see banding in gradients of pure red, green or blue, but that is not necessarily the case for other colours. Not anything I would worry about, but there have been cards with 30 bit colour for just this reason, and I've heard that 10 bit greyscale is not uncommon in medical display equipment.
It certainly would have been nice if nature had had better foresight. ;-)
> The 882, again.
...
> The only application that we could notice
> any difference at all with, was POV.
> However, the FPU bar on Centbench
> indicated a 60% raise, when the FPU was
> not used, but that fell down very
> quickly, as soon as something used the
> FPU.
I might be missing something here, but I don't understand what it is you're saying that you did. You didn't install an '882 in an '040 machine, right?
I'm genuinely interested in what you were testing and how it relates to the '040/'882 combination.
> The biggest problem when booting up MagiC
> and Jinnee on a MAC, is that the
> harddrive almost jumps out of the
> computer case! It really gives the HD a
That sounds strange. Are you sure you have enough cache allocated?
Atari software usually does not use lots of small pieces, so I don't see why there should be any significant harddisk thrashing.
> hard time, and it also is a horrible
> bottleneck. With the RAMdisk, the
Well, with a modern harddisk (and an IDE controller that is up to the job), you should be able to get transfer speeds not far from that of my AB040 copying FastRAM.
Of course, track swithing is still slow, but most Atari software does not need lots of small files from all over the place, so I don't think this really should be too much of a problem.
There are reasonably cheap IDE flash disks available, anyway, for those who may want them.
|
