Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!lth.se!newsuser From: d87sg@efd.lth.se (Svante Gellerstam) Newsgroups: comp.sys.amiga.hardware Subject: Re: Bank switched CHIP RAM? (Re: 24 Bit Video ..) Keywords: That was not the main point really... :-) Message-ID: <1990Oct8.211957.2528@lth.se> Date: 8 Oct 90 21:19:57 GMT References: <1990Sep28.022138.19237@zip.eecs.umich.edu> <1990Sep30.233751.3244@zorch.SF-Bay.ORG> <1990Oct3.194556.7031@lth.se> <106878@convex.convex.com> Sender: newsuser@lth.se (LTH network news server) Reply-To: d87sg@efd.lth.se (Svante Gellerstam) Organization: Lund Institute of Technology, Sweden Lines: 55 In article <106878@convex.convex.com> swarren@convex.com (Steve Warren) writes: >In article <1990Oct3.194556.7031@lth.se> d87sg@efd.lth.se (Svante Gellerstam) writes: > [...] >>Interlace screen on a A3000. Even on a 25MHz '030 a measly >>(professionally speaking) 640 x 400 screen becomes zippy as old >>chewinggum. > [...] >The solution to the bandwidth problem is banks. We already have two >seperate banks of chip mem in the 3000 with 2 Megs of chip. The trick >is to set it up so that as long as the video DMA is accessing one of the two >banks, the CPU can have transparent access to the other bank simultaneously >(ie no cycle-stealing necessary). The best way to utilize this is by using >an 8- or 16- byte interleave, so that every 16 consecutive bytes will be >in alternating banks. > > < stuff deleted >... > This is a method I have not considered - interesting! But I really think a more 'device' oriented solution is better - you send commands to a video device and get results on the screen - this enables all types of implementations. As it is now (and the line of thought of most people) all video adapters have to positively rape the machine to be both compatible and able to meet say 1280 x 1024 x 8 bandwidth. It is of course possible to build some kind of video DMA that will allow whatever desired with the current setup - the blitter (and friends) does the graphics housekeeping. Thing is they are too slow to cope with hires and many-colored screens. Thus we need some agreed upon (sanctioned by Commodore) protocol that allows any type of video adapter (all from 80 x 25 text only to 1600 x 1280 x 24) to be connected and useable. That is - the WorkBench should run fine on it - applications should have the option of interrogating the system for available resolutions and color modes. The main point here is not to build the damn thing to be compatible with present standards, but to define a way to connect every concievable tope of video adapter. Building something to be locked into the existing structure is an indication of regression in development d;^). We already have all these beautiful dynamically loaded libraries and device drivers and separate filesystems - why not device independent grahics? Apart from being a way to control pee wee's do-it-yourself megapixeldisplay, it would be a way to control other types of raster displays like printers and so on... (Sorry Steve - MG messed up your footer :-( -- 2:200/107.4 Svante Gellerstam (Fido) d87sg@efd.lth.se (InterNet) It's the african anteater ritual! -- Can't Buy Me Love