dale@boing.UUCP (Dale Luck) (11/30/90)
Why is it so difficult to design a simple memory
mapped frame buffer board. I've gotten the specs
on a couple, like the firecracker and most seem
to have forgotten that the main cpu of the Amiga
is 68000 based. Read: FLAT ADDRESS SPACE.
Any kind of interface that forces the programmer to
hit multiple i/o registers to peek and and poke pixels
through a porthole just makes progamming more difficult.
In my case I would like to support these frame buffer
boards with the X Window System. Getting it to support
this architecture is not trivial. I believe such interfaces
are a step backward.
Is anyone doing a simple frame buffer board with VRAM
to drive a reasonable resolution monitor with at least
256 colors and a direct memory mapped raster? On the
A3000 it could even be accessed 32 bits at a time to
double the speed of operations.
Dale Luck
--
Dale Luck GfxBase/Boing, Inc.
{uunet!cbmvax|pyramid}!amiga!boing!dalepeterk@cbmger.UUCP (Peter Kittel GERMANY) (12/01/90)
In article <916@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: > >Any kind of interface that forces the programmer to >hit multiple i/o registers to peek and and poke pixels >through a porthole just makes progamming more difficult. > >Is anyone doing a simple frame buffer board with VRAM >to drive a reasonable resolution monitor with at least >256 colors and a direct memory mapped raster? On the >A3000 it could even be accessed 32 bits at a time to >double the speed of operations. I believe they fear to waste too much of the existing address space of an A2000 when they want to use 24 (or at least 8) bitplanes. The RAM has to be dual-ported for video access at highest priority. And when it also has a digitizing part, then it even has to be triple-ported. Perhaps they find this too difficult (or too slow?). But on the A3000, your argument is perfectly valid. With its huge address space and its fast bus, there shouldn't arise any real problems. (or?) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
ckp@grebyn.com (Checkpoint Technologies) (12/01/90)
In article <916@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >Why is it so difficult to design a simple memory >mapped frame buffer board. I've gotten the specs >on a couple, like the firecracker and most seem >to have forgotten that the main cpu of the Amiga >is 68000 based. Read: FLAT ADDRESS SPACE. The 8 meg expansion address space of the Amiga is too precious to devote a meg or more of it to "just" a frame buffer. True, Zorro III has plenty of space (1.7 Gig?) for such a device. But right now, no developer would be so stupid as to make an A3000-only device. The market's way too small. -- First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / / \\ / / Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o Now for the witty part: I'm pink, therefore, I'm spam! \/
dale@boing.UUCP (Dale Luck) (12/02/90)
In article <23699@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: >In article <916@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>Why is it so difficult to design a simple memory >>mapped frame buffer board. I've gotten the specs >>on a couple, like the firecracker and most seem >>to have forgotten that the main cpu of the Amiga >>is 68000 based. Read: FLAT ADDRESS SPACE. > >The 8 meg expansion address space of the Amiga is too precious to >devote a meg or more of it to "just" a frame buffer. I think the benefit far out weighs the cost. I'd be glad to give up 1/8 of my address space for a 1024x1024x8 frame buffer board. I think it is a very small price to pay. I just don't see that many people unwilling to give up 1M-2M of memory. It still leaves 4-6 megs of memory for programs as well as the 1M of chip memory. I expect there are a lot of machines out there (A2500 like) that are basically 1M chip, 4M on the 030/030 board and no other memory board in the system. One reason for this is my programs slow down terribly when they dig into the 16bit ram. So the address space is wasted in this case. Actually a whole 4M is wasted. Boy would I like a 24bit 1kx1k color card, that would fit in quite nicely. I did not realize that SO MANY were running with fully blown out (8M of ram) systems that use all of it up the last 1-2M during normal program execution. Besides which the VRAM is still real ram, and you get some real interesting patterns on the display when using it as regular ram and compiling with Lattice. ;-) -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
peter@sugar.hackercorp.com (Peter da Silva) (12/02/90)
In article <23699@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: > The 8 meg expansion address space of the Amiga is too precious to > devote a meg or more of it to "just" a frame buffer. I don't know about that. Every A2000 already has a megabyte allocated to pretty much that very purpose. If you're going to shove more than a few megs of RAM into your 2000 you're likely to be running a 68020 or so and have almost 2 gig of RAM-only address space available on your CPU card. (yes, I know that most 68020 cards don't take advantage of >16M memory, but it's in the CPU's address space and should be used. The only problem with it is that you can't access it from the Zorro bus so you can't DMA to it, but that's a SMOP.) I'd think that paged I/O cards would be a bit of a pain for any hypothectical future device-independent graphics.library, too. Another reason to go to a flat address space, no? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
DXB132@psuvm.psu.edu (12/04/90)
In article <918@boing.UUCP>, dale@boing.UUCP (Dale Luck) says: >I did not realize that SO MANY were running with fully blown out >(8M of ram) systems that use all of it up the last 1-2M during >normal program execution. I agree, this is pretty unusual! Saying that there's not enough address space sounds like a lame excuse for a bad design. By the way, I was pretty surprised at the nice video card that my Dad bought for his (ick) clone. It can do VGA (boring!) plus 1024x768 256 colors (non- interlaced) AND 512x480 16 million colors (non-interlaced), has a 34010, 1MB VRAM standard, 2MB of program RAM for the 34010 optional. This for $620 from a name brand supplier (Hercules). Is Commodore's A2410 similar? (not that I would buy one, just curious :-)) -- Dan Babcock
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (12/05/90)
In article <918@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >I think the benefit far out weighs the cost. >I'd be glad to give up 1/8 of my >address space for a 1024x1024x8 frame buffer board. I think >it is a very small price to pay. I just don't see that many >people unwilling to give up 1M-2M of memory. It still leaves >4-6 megs of memory for programs as well as the 1M of chip memory. Hmm, I can't see much benefit from this besides ease of programming. IMHO, it is sufficient to map a smaller rectangular part. The drawing routines can be adapted without much peformance loss. What benefits do you think of ? Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
fsset@bach.lerc.nasa.gov (Scott E. Townsend) (12/06/90)
In article <1411@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >In article <918@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>I think the benefit far out weighs the cost. >>I'd be glad to give up 1/8 of my >>address space for a 1024x1024x8 frame buffer board. I think >>it is a very small price to pay. I just don't see that many >>people unwilling to give up 1M-2M of memory. It still leaves >>4-6 megs of memory for programs as well as the 1M of chip memory. > >Hmm, I can't see much benefit from this besides ease of programming. >IMHO, it is sufficient to map a smaller rectangular part. The drawing >routines can be adapted without much peformance loss. > >What benefits do you think of ? > >Regards, >-- >Michael van Elst >UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve >Internet: p554mve@mpirbn.mpifr-bonn.mpg.de > "A potential Snark may lurk in every tree." One benifit I can think of is indeed ease of programming, which also results is a good size performance gain. For example, a quick circle drawing routine would slow down a fair amount if it had to worry about drawing across this rectangular window into the real image. This would be a lot like clipping, which isn't a real quick operation. A similar application would be in image processing. Image segmentation by boundary following would have to constantly check if it has gone past the window boundary. Essentially, one could say the reason I would like a flat memory space is that I don't like the headaches a window has. Headaches cause harder programming, larger code, and usually measurably slower code. I like the 680x0's simple address space better than the 80x86's segmented address space too ;-) -- ------------------------------------------------------------------------ Scott Townsend | Phone: 216-433-8101 NASA Lewis Research Center | Mail Stop: 5-11 Cleveland, Ohio 44135 | Email: fsset@bach.lerc.nasa.gov ------------------------------------------------------------------------
dale@boing.UUCP (Dale Luck) (12/06/90)
In article <1411@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >In article <918@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>I think the benefit far out weighs the cost. >>it is a very small price to pay. I just don't see that many >>people unwilling to give up 1M-2M of memory. It still leaves >>4-6 megs of memory for programs as well as the 1M of chip memory. > >Hmm, I can't see much benefit from this besides ease of programming. This is a MAJOR benefit. Ease of programming. >IMHO, it is sufficient to map a smaller rectangular part. The drawing >routines can be adapted without much peformance loss. If you can constrain most of your work to small regions then that is fine. In a windowing environment we have little control over this. A driver that needs to quickly access different portions of the display for moving windows around, scrolling etc. the segment architecture means an extra layer of complexity, over an above the complexity of overlapping windows. IMHO the benefits of a complete memory mapped frame buffer far outweigh the costs giving up 1-2M of address space on the bus. The benefits of of a mapped rectangular region just do not seem compare with the large costs of much more complex code and slower speed. I think Intel had the same thoughts regarding the 8088,8086, etc. line of processors vs 68000 linear address space. Guess you know what most Amiga people prefer. It also seems to me that 100% mapped frame buffer compared to a portal type frame buffer would be easier to design. > >Regards, >-- >Michael van Elst >UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve >Internet: p554mve@mpirbn.mpifr-bonn.mpg.de > "A potential Snark may lurk in every tree." -- Dale Luck GfxBase/Boing, Inc. {uunet!cbmvax|pyramid}!amiga!boing!dale
daveh@cbmvax.commodore.com (Dave Haynie) (12/06/90)
In article <916@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >Why is it so difficult to design a simple memory >mapped frame buffer board. I've gotten the specs >on a couple, like the firecracker and most seem >to have forgotten that the main cpu of the Amiga >is 68000 based. Read: FLAT ADDRESS SPACE. It really isn't very difficult. The problem depends alot on the design. Many of the video controllers on the market like to have total control of the memory, so forcing the programmer to go through some register ugliness (like the 8653/8568 chip in the C128, and other traditional video controllers) rather than directly to memory simplifies the video controller design. I gather than even modern systems like the TI 340 series (especially the 34010) force the same thing. The other explanation is that many of the video toys on the market have been designed with PC Clones in mind, and these babies not only have to deal with a 64K maximum segment, but a severe limit on the amount of address space that can be devoted to video display. Neither of these is sufficient explanation, as far as I'm concerned, for why such ugliness needs to find it's way onto the Amiga. At least the TI34020 seems to have made provision for a host CPU interaction with memory, though of course in the TI systems the host CPU needs less involvement anyway. There is supposedly a very cool sounding 34020 board coming out from some group in Germany. In that it supports real CAD resolutions rather than the typical video resolution, it interests me personally more than FireCrackers and that ilk -- I want CAD, not video. >In my case I would like to support these frame buffer >boards with the X Window System. Getting it to support >this architecture is not trivial. I believe such interfaces >are a step backward. At least with the TI systems, they provide an interface library. But you can bet that going through I/O registers, speed-wise anyway, is going to be a step backwards. Ever wonder why 99% of the VGA devices out there are slow? It's not because there's no fast CPU around to push pixels around, nor is it because of CPU segmentation. >Is anyone doing a simple frame buffer board with VRAM >to drive a reasonable resolution monitor with at least >256 colors and a direct memory mapped raster? On the >A3000 it could even be accessed 32 bits at a time to >double the speed of operations. On the 3000, you could in theory get at least 4x the speed of such a board on the 2000, assuming the video fetch cycle didn't eat too much time. I don't have an answer, and actually wish I had some spare time myself to muck with this. The 3000 certainly has enough juice in the '030 to drive a video board as fast as NeXT or the good '030 Suns, and faster than Mac NuBus video toy. You should be able to implement most of a simple, dumb video controller in a handful of PALs and PLDs; depending on the architecture, it's not all that much more complicated than a plain old DRAM circuit, which can be done in three or four PALs. For example, the sleezy Zorro III DRAM board design done for last summer's DevCon was something I cooked up in a week. Taking the same simple approach, you would think someone could do a video toy in a month or two, but I suppose they need to be convinced there's a market for it. >Dale Luck GfxBase/Boing, Inc. >{uunet!cbmvax|pyramid}!amiga!boing!dale -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Wheeeeeeeeeeeeeeee...........
brian@babbage.csus.edu (Brian Witt) (12/06/90)
In article <1990Dec5.165513.16570@eagle.lerc.nasa.gov> fsset@bach.UUCP (Scott E. Townsend) writes: >In article <1411@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >>Hmm, I can't see much benefit from this besides ease of programming. >>IMHO, it is sufficient to map a smaller rectangular part. The drawing >>routines can be adapted without much peformance loss. >>[..] >>Michael van Elst > >One benifit I can think of is indeed ease of programming, which also results >is a good size performance gain. For example, a quick circle drawing >routine would slow down a fair amount if it had to worry about drawing >across this rectangular window into the real image. This would be a lot like >clipping, which isn't a real quick operation. > (I'm playing the devil's advocate, so keep the flames low. This is more of a `what if..' than a complaint..) What about multiple monitors attached to the same box. macintosh's do this quite naturally. I was told by an ex-Sun employee that SunViews was kludged to look like it does multiple monitors. Would be neat to drag your mouse from an interelaced monitor to a productivity monitor. Having multiple monitors would be like having your display segmented (evil word, but I'm playing the devil's advocate :-). Each segment of display memory represents a different physical video board. Would the solution be similar to vide-paging on, say, an IBM PC VGA board? This is graphics (slow) overhead, but it would be a great feature. Is this the way these things are done? However, if the graphics operation is repeated for each video video monitor, just ignore me. I do systems, so please someone set me straight here. But is this a direction that people would like to see tha Amiga travel? After all, the Copper given multiple scren resolutions without the cose of multiple screens. However, to complete in a graphics workstation market, having a 21" mega-graphics display next to a clean textual display is real glitzy :-). But a $15K Amiga might be *TOO* outrageous. (many folk have asked for wonder hardware features, but don't want to pay for them.. :-( Food for thought. Yearn for Peace. >------------------------------------------------------------------------ >Scott Townsend | Phone: 216-433-8101 >------------------------------------------------------------------------ ---------------------------------------------------------------- brian witt | brian@babbage.ecs.csus.edu You are what you click | (and if you click it twice...) Not representing Cal State Sacramento, the ECS dept, or Iraq ---------------------------------------------------------------- -- ---------------------------------------------------------------- brian witt | brian@babbage.ecs.csus.edu You are what you click | (and if you click it twice...) Not representing Cal State Sacramento, the ECS dept, or Iraq
kent@swrinde.nde.swri.edu (Kent D. Polk) (12/06/90)
In article <1990Dec5.212627.24551@csusac.csus.edu> brian@babbage.csus.edu (Brian Witt) writes: >In article <1990Dec5.165513.16570@eagle.lerc.nasa.gov> fsset@bach.UUCP (Scott E. Townsend) writes: >> >>One benifit I can think of is indeed ease of programming, which also results >>is a good size performance gain. For example, a quick circle drawing >>routine would slow down a fair amount if it had to worry about drawing >>across this rectangular window into the real image. This would be a lot like >>clipping, which isn't a real quick operation. Ah, beat me to it. Also, try doing nXn filter operations on a windowed graphics card. Just memory map the framebuffer & let me keep/massage my data right in the framebuffer. Then I only have to keep temp buffers for the special stuff & can use offscreen buffers if I don't want the operations visible. >What about multiple monitors attached to the same box. macintosh's do I'd be happy running Intuition on the standard monitor & a device- independent package (like X11) on the Lowell card with a NEC5D. It would be nice to drag that Intuition application over to the next display, though. Speaking of X11, I want to thank Dale Luck (GfxBase) for loaning a copy of X11 on the Amiga for the recent demo at Southwest Research Institute. Looks pretty good (saving up my pennies...). Wish I had one of those 'productivity screens' on my 2500/20 :^( (Will Xamiga support the Lowell card as it is supported on the A3000UX?) The price is right & the product is right for those of us in a network environment. Looking forward to when X11 isn't such a cpu hog though. ==================================================================== Kent Polk - Southwest Research Institute - kent@swrinde.nde.swri.edu "Well... can't you get a Novell card for your Cray ?" ====================================================================
telam@pyrps5.pyramid.com (Thomas Elam) (12/06/90)
In article <7182@sugar.hackercorp.com>, peter@sugar.hackercorp.com (Peter da Silva) writes: |> In article <23699@grebyn.com> ckp@grebyn.UUCP (Checkpoint Technologies) writes: |> > The 8 meg expansion address space of the Amiga is too precious to |> > devote a meg or more of it to "just" a frame buffer. |> |> I don't know about that. Every A2000 already has a megabyte allocated to |> pretty much that very purpose. If you're going to shove more than a few megs |> of RAM into your 2000 you're likely to be running a 68020 or so and have |> almost 2 gig of RAM-only address space available on your CPU card. Maybe a 68020, '030, or '040 coprocessor (as exist on the accelerator boards that are available) could be an integral part of the board, so that the CPU could access all 2 or 3 ports (or more) ports of the RAM, and 1024x1024x24 or larger bit planes could be supported. One would have to make some speed calculations to make sure the frame buffer board would not be slowed down so much by the Amiga's system bus speed that the board would not be a winning peripheral. |> (yes, I know that most 68020 cards don't take advantage of >16M memory, but |> it's in the CPU's address space and should be used. The only problem with it |> is that you can't access it from the Zorro bus so you can't DMA to it, but |> that's a SMOP.) For the extra address space to be accessible to the system CPU, the system bus needs the extra address bits. How many address bits are there on the A2000's system bus (Zorro II, right?)? Isn't it just 24? That would provide a 16 MByte address space. Often, the addresses in a computer are not fully decoded, thus wasting some address space. I don't think more than 9 MBytes of configurable address space is gauranteed by the specifications of the A2000 to exist in an A2000. By the way, some calculation: 3 bytes (24 bits) x 1024 x 1024 x 3 ports = 9 MBytes. |> I'd think that paged I/O cards would be a bit of a pain for any hypothectical |> future device-independent graphics.library, too. Another reason to go to a |> flat address space, no? |> -- |> Peter da Silva. `-_-' |> <peter@sugar.hackercorp.com>. Tom
markv@kuhub.cc.ukans.edu (12/07/90)
> In article <918@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >>I think the benefit far out weighs the cost. >>I'd be glad to give up 1/8 of my >>address space for a 1024x1024x8 frame buffer board. I think >>it is a very small price to pay. I just don't see that many >>people unwilling to give up 1M-2M of memory. It still leaves >>4-6 megs of memory for programs as well as the 1M of chip memory. > Hmm, I can't see much benefit from this besides ease of programming. > IMHO, it is sufficient to map a smaller rectangular part. The drawing > routines can be adapted without much peformance loss. Well, if the board's memory can be used as normal system memory when not being used as a frame buffer...? This might be a nice compromise and certainly would have its marketing strong points ("Get a 2MB memory expansion and frame buffer in one..."). I've had to deal too much with VGA and EGA progrmaming where everything has to be done through either I/O ports, or a limited area of memory. It works, and you dont take too much of a performance hit, but its a pain in the *bleep*. Having the whole buffer available certainly is nice, but not essential. However, if the buffer is bitplane oriented (and not "chunky" pixel), then having enough of an address window for one whole bitplane at once is certainly sufficient and a good compromise. > Michael van Elst -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum /\ \ | / H a p p y Academic Computing Services / v\ -- * -- H o l i d a y s ! :-) University of Kansas /v v\ / | \ /// /__v___\ Only /// /| __ _ Bitnet: MARKV@UKANVAX || \\\ /// /__| |\/| | | _ /_\ makes it Internet: markv@kuhub.cc.ukans.edu \/\/ / | | | | |__| / \ possible ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
brianm (Brian Moffet) (12/07/90)
dale@boing.UUCP (Dale Luck) writes: >Is anyone doing a simple frame buffer board with VRAM >to drive a reasonable resolution monitor with at least >256 colors and a direct memory mapped raster? On the >A3000 it could even be accessed 32 bits at a time to >double the speed of operations. Or, as I would like to see, but don't have adequate knowledge to do myself, is a frame buffer which will support 640 x 400 interlaced with > 256 colors (non-ham). This would not necessarily be used for animation, but would be just be this board which I could hook up to my ami 1000. It would put out analog RGB at 15... Mghz so that I could hook it up to my existing amiga monitor, or to a Genlock. It would not be accessable by the special chips, it would just be this memory that could be displayed... 24 bits would be nice :-) Oh, some really useful information, the Black Belt HAM-E box will not necessarily work with an Amiga, if that Amiga has an accelerator board in it. My ami 1000 with a CSA Midget Racer won't work. I am currently talking to Black Belt to see what I can do to get it to work. I may send them the MidgetRacer to see if they can do something. They have been quite helpful. brian moffet
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (12/08/90)
In article <1990Dec5.165513.16570@eagle.lerc.nasa.gov> fsset@bach.UUCP (Scott E. Townsend) writes: >In article <1411@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >>Hmm, I can't see much benefit from this besides ease of programming. >>IMHO, it is sufficient to map a smaller rectangular part. The drawing >>routines can be adapted without much peformance loss. >is a good size performance gain. For example, a quick circle drawing >routine would slow down a fair amount if it had to worry about drawing >across this rectangular window into the real image. Not quite that. The circle drawing algorithm has more to do than poking pixels into the frame buffer, so checking is only a small fraction. But what is even more important is that you can determine from the start coordinates when you cross window boundaries which reduces overhead even more. >Essentially, one could say the reason I would like a flat memory space is >that I don't like the headaches a window has. Headaches cause harder >programming, larger code, and usually measurably slower code. As I said, it is _easier_ to write code for a memory mapped framebuffer but doesn't imply major performance loss. Think of a framebuffer addressed through the concatenated row and column number which isn't a flat contigous memory at all but which is surely faster to access for graphics purposes. >I like the 680x0's simple address space better than the 80x86's segmented >address space too ;-) Well, the 8086 has the fault that you NEED segments to address all memory. I wouldn't argue against segmented memory if the segments can be as large as the logical address space. Think of UNIX where you have a segmented address space (usually one segment per process) even with 680x0 processors. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
L98CC@CUNYVM (12/12/90)
In article <920@boing.UUCP>, dale@boing.UUCP (Dale Luck) says: > ===== some stuff deleted. ===== > >This is a MAJOR benefit. Ease of programming. > I agree! ===== some more stuff deleted ====== >IMHO the benefits of a complete memory mapped frame buffer far outweigh >the costs giving up 1-2M of address space on the bus. The benefits of ******************************* Assuming 1) I am willing to give up 2 meg space but not expansion ram space. 2) I want the design to be compartible with all brands of Amiga.( Maybe some little mods for A500 and A1000. ) 3) I do not want to violate any hardware design rule set by CBM. ( i.e. do not use reserved address space etc.. ) 4) I am actually designing a frame buffer :-) Where do I find the 2 meg of address space to give up? ( This is neither a crude cynisism or a flame. I really do not know. ) ------- From Internet : if your site has a dumb mailer try | for a smart mailer try SH941727%CCNYVME.BITNET@CUNYVM.CUNY.EDU | SH941727@CCNYVME.BITNET Today's Quote : Just say NO! To the hot chocolate without mashmellows!
daveh@cbmvax.commodore.com (Dave Haynie) (12/18/90)
In article <90345.181101L98CC@CUNYVM.BITNET> L98CC@CUNYVM writes: >In article <920@boing.UUCP>, dale@boing.UUCP (Dale Luck) says: >>IMHO the benefits of a complete memory mapped frame buffer far outweigh >>the costs giving up 1-2M of address space on the bus. The benefits of > ******************************* >1) I am willing to give up 2 meg space but not expansion ram space. >3) I do not want to violate any hardware design rule set by CBM. ( i.e. > do not use reserved address space etc.. ) These two desires are at odds with one another. The only memory mapped hardware supported is autoconfiguring hardware. There is 8.5 meg of space open for this, 8 of which is contiguous and many folks use for expansion RAM. If you want a memory mapped frame buffer that takes up 2 meg for it's mapped memory, that leaves 6 meg of space for other things, including expansion RAM. There is no other memory available on a 68000 system. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "I can't drive 55" -Sammy Hagar
jesup@cbmvax.commodore.com (Randell Jesup) (12/19/90)
In article <1421@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: >As I said, it is _easier_ to write code for a memory mapped framebuffer >but doesn't imply major performance loss. Think of a framebuffer addressed >through the concatenated row and column number which isn't a flat contigous >memory at all but which is surely faster to access for graphics purposes. Worse yet, if you need to access the frame buffer via registers, you either have to allow only one task to use it (ever), or save/restore those register on every task swap. Fun fun fun. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)