kruger@16bits.dec.com (Bear with me) (04/06/88)
Randall Jessup writes that the way to a faster Amiga is a 32-bit blitter.... Actually, a 32 bit blitter only helps on block moves. I'd prefer to see two 16 bit blitters (possibly in the same package). Consider a system with two separate 512K chip RAM areas. The copper could look at one or the other, and if you hit the one it's not looking at, there's NO contention. Yeah, each section of chip RAM could have a blitter per bank, but that's expensive.... Where 32 bit width would help a lot is in the copper, because that would lower the cost of video bandwidth. Well, let's be honest, we'd still see blocking, because we'd go for higher resolution and more planes! On a related note: Commodore, are you listening? We know what's coming. A 68020 in every pot, then '030s. NOW is the time to support other types of memory for the weirder and weirder configurations we are going to see. I don't say Commodore's board will do this, but, we have the possibility of: VFRAM (Very Fast RAM) just 32 bits wide, EFRAM (Extremely fast RAM) (static, keeps up with the '20), HFRAM (HyperFast RAM!) static and burst and synchronous 2 clock memory for the '030. I would like to see sensible allocation of these resources when they are available. Doubtless, there will be a much smaller amount of fast static RAM, which I would prefer to see used in the really critical areas. So how about new classes of memory, separate pools, etc? If support is created intelligently now, then perhaps people will be using it well by the time these resources become available -- maybe ;-). For example, if you've got 2M of VFRAM and 2M of existing Fast RAM, I'd like to see a RAM Disk grab the old stuff if I'm running big jobs that fill VFRAM. Otherwise, my jobs will be bumped into FRAM, and run slower. we could also use memory migration routines, so that a job can be put on the back burner (under it's own control?) Finally, for those systems with a small amount (say 256K) or HFRAM, you want a task to be able to request "the fastest you've got, Scotty!" for small amounts of memory. In addition to system calls, it would be a good idea to insert this information into a task, so programmers can specify a) I want this data in CHIP RAM. I have encountered this problem, and the only thing I could think of doing was to allocate CHIP RAM and copy the data in. This is silly, since the loader could do it to start with. It wastes resources (Not that I run out these days :-) ) Still, it's ugly, and it's work for the programmer, and I'm lazy ;-). In any case, you should also be able to request all the same levels of memory so that you are not forced to copy them yourself later. Have the loader do it right the first time. <END REQUEST!> Keep up the good work! With all the minor annoyances, this system blows the socks off anything I've ever played with! Mac ][ go home! dov Digital Equipment cannot be held responsible for the things I do. Likewise, if you're having trouble with your VAX, feel free not to call me :-)