Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Bank switched CHIP RAM? (Re: 24 Bit Video ..) Summary: Apple ][e did it, can we? Keywords: Off the wall idea? Message-ID: <1990Sep30.233751.3244@zorch.SF-Bay.ORG> Date: 30 Sep 90 23:37:51 GMT References: <1990Sep21.184056.14 <27024b15-2c05.11comp.sys.amiga-1@tronsbox.xei.com> <1990Sep28.022138.19237@zip.eecs.umich.edu> Organization: SF-Bay Public-Access Unix Lines: 71 Part of the problem with trying for higher resolution/more colors is not invalidating the existing OS/application software base. Working (in this area) from a knowledge base of nearly zero, let me blunder on ahead with Yet Another Proposed Improved Graphics (YAPIG) for the Amiga family. 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). 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. 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? The goal, of course, is to switch from bank to bank writing the six or so bitplanes currently supportable until all the banks needed to support (12, 18, 24, 30, 36, 42, 48) bitplanes to do one modification of the picture had been done. Each bank would have the usual slop left around all over for offscreen copies of information hidden onscreen, and so forth. The immediate difficulty I see is that you'd probably want to cut overhead by writing everything for one bank before switching, but current software probably would be more comfortable going pixel deep by pixel deep. On the hardware side, I'm guessing you'd have to pretty much hijack the mother board's memory access; would an eight inch ribbon cable and the additional add in board trace lengths kill the CHIP memory timing, or is there some slack in there that corresponds to the time to get to and from FAST RAM? This isn't the world's prettiest solution (can you say "segmented architectures reek?") but if it's feasible at all it could move us off the dime without blowing away the chance to be a little more clever further down the line. If it looks doable, could the good folks at "CBU" (really? I always found them under "Comdre") set a standard way of addressing a bank flipping mechanism so that the third parties, and Commodore if they like, could go crazy with new hardware? I'd love to see a solution that gates NTSC 24 bit color plus 8 bits of overlay, or maybe 48 bits for double buffering (actually you can fit two 1K x 1K x 6 maps per bank, I think, so it wouldn't have to be _real_ 48 bit), today, with an easy upgrade path to whatever HDTV standard finally emerges tomorrow. If the video side of the port were widely controllable, this tool might even be able to do most of HDTV just by downloading some numbers describing the new scan dimensions and rates. I know this is either three bricks shy of a load, or a little under half baked, but what do you expect for free? Fire when ready, Gridley! ;-) Kent, the man from xanth.