Path: utzoo!attcan!uunet!snorkelwacker!apple!julius.cs.uiuc.edu!wuarchive!psuvax1!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: Bank switched CHIP RAM? (Re: 24 Bit Video ..) Keywords: Off the wall idea? Message-ID: <14823@cbmvax.commodore.com> Date: 2 Oct 90 23:37:52 GMT References: <1990Sep21.184056.14 <27024b15-2c05.11comp.sys.amiga-1@tronsbox.xei.com> <1990Sep28.022138.19237@zip.eecs.umich.edu> <1990Sep30.233751.3244@zorch.SF-Bay.ORG> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 92 In article <1990Sep30.233751.3244@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >When Apple upgraded the Apple ][+ (64K box) to the Apple ][e (128K >box), they exceeded the addressing capability of the 6502 chip, >sort of like going past 2M would exceed the addressing capability >of 2M Agnus. They chose to make the memory addressable by the chip >in banks, with some sort of register where the memory could be >flipped (a low page was mapped common, and some other details not >too interesting in the spitballing part of a product's >evolutionary planning). This was hardly a new trick at Apple -- CP/M machines did the same kind of thing for CP/M 3.0, Commodore B128s did this early on, and the Commodore 128 did it a few years after the larger Apples came around. You see the lastest incarnation of this in the LIM (Lotus, Intel, Microsoft) banked memory scheme for MS-DOS machines. The word that correctly describes all of these schemes is: K K L U U DDDDD GGGG EEEEEE K K L U U D D G G E K K L U U D D G E KK L U U D D G EEE K K L U U D D G GGG E K K L U U D D G G E K K LLLLL UUUU DDDDD GGGG EEEEEE >Agnus, I suspect, would be Fat, Dumb and Happy addressing _any_ >two meg, as long as we didn't bother to let the old girl know the >rug had been pulled out from under her and a new one run in. That's true. However, you would then have two completely disjoint chunks of Chip memory. No piece from one bank could have any effect on any piece of the other bank, or disaster strikes. How would you use the second bank if, for instance, Workbench and all the system gadgets are in the first bank. You can't even blit between the two banks. >So here's my question: since we can already work with bitmaps at >least 1K x 1K, we can promote pretty good resolution. With a >(possibly third party) add on board that gave bank switched CHIP >RAM in two meg chunks, dual ported with a really zingy set of >video DAC's on the other side to pull up to (24-48, you pick a >number) bits of color off the other side with or without a color >look up table, and defaulting to act just like the current 2M CHIP >RAM, how big a hit would existing software take to shoehorn in >support for the bank switching commands? Well, even if you're attempting to organize this as "deeper" rather than "more" banked memory, you're going to get into trouble. For example, video fetch DMA isn't the only DMA going on -- you have memory refresh DMA, which would have to be applied to every bank, every time, to work. You have floppy disk DMA, which would wind up dumping to whatever bank was in context unless you found a way to insure the alternate banks are in context only during video fetch. And without a Denise doing the display, I don't see any advantage to this scheme vs. a plain old VRAM based visual RAM display. You couldn't support multiple screens; the area of memory that's displayed would be fixed. Etc. and so forth. Even setting up a system with more Agnus, Denise, and memory subsystems would be easier to deal with than this banking idea, which is just about impossible to consider in the context of what Agnus does. You have to realize that the CPU bank switching was under very controlled conditions. Those systems only have one processor playing with memory, we have two. All the software that supports their bank switching is written with that switching in mind, and all software that doesn't support the banking doesn't see it happen. And of course, that's much easier to control when you only have to deal with a single program running. Now, the idea of support multiple Agnus chips could work a bit better, though still not optimally. Any program that doesn't know about the extra Agnus chips could go about it's merry way; all disk DMA probably happens only in the main Agnus. Each bank has it's own blitter, refresh, etc. Programs that know about the extra Agnus systems would run the same routines, only with an offset to pick the extra banks. What you would really like as well is some kind of Denise-without-colormapping mode to be supported for the custom multi-Agnus screens. System software wouldn't have a clue about which Agnus/chipram bank to deal with; plain memory writes, allocations, etc would work fine, but any addressing of Agnus would have to change. And you would have to special case blits in-bank vs. blits between banks. In other words, a hairy kludge, but still something that could, with enough imagination, work. I would estimate the software effort to put this kind of support into graphics.library just a little easier than what it would take to support arbitrary video display devices. Then again, I would really dig playing around with a blitter per color, or better yet, a blitter per bitplane. >Kent, the man from xanth. > -- 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