🚀 go-pugleaf

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!             \/

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

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>.

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

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."

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
------------------------------------------------------------------------

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

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...........

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

> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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."

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!

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

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")  ;-)