NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/apple2/24304

Text File | 1992-11-20 | 3.5 KB | 69 lines

Newsgroups: comp.sys.apple2
Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!rochester!galileo.cc.rochester.edu!ee.rochester.edu!seah
From: [e-mail] (David Seah)
Subject: Re: Animation and video card design...
Message-ID: <[e-mail]>
Organization: Univ of Rochester, College of Engineering and Applied Science
References: <[e-mail]>
Date: Sat, 21 Nov 1992 09:55:27 GMT
Lines: 58

In article <[e-mail]> [e-mail] (Matthew W. Hacker) writes:
>   A sugestion came up a while back that a video card should
>have separate memory from the GS, and that if something wanted
>to access video memory directly, it could DMA to the card.
>As I pondered this idea, I had a couple of questions/comments:
>
>1) All the GS/OS stuff should use the toolbox, so if the card
>   was coprocessed, this wouldn't be bad. Right?

It sounds like a good idea.

>2) If it shadowed the GS's video memory, then it would be backwards
>   compatible with older stuff that did direct memory writing

If you wanted to provide more colors in a convenient framebuffer
arrangement, the board would have to do some massaging of the shadowed
data.  In 320 mode, each byte contains 2 pixels, each a nibble wide.
You could have a framebuffer that was organized just like the SHR
screen, with an auxiliary page that has the extra 4-bits for glorious
256 colors.  Unfortunately, you end up with something like the Apple IIgs's
80 column mode...bleah!  It might make more sense to shadow the SHR
screen to an onboard duplicate and use this as a 16-color overlay channel
that goes on top of the cool 256-color+ framebuffer, but you'd need to
decide which color is transparent blah blah blah.  It would be like the
VOC in some way, I suppose.

>3) Sounds pretty good except for one thing.  What about animation?
>   Doesn't animated stuff still use direct access?  Then having
>   to write to memory, and then DMA to the card is really going to
>   slow things down.

>Of course the only other real option (as I see it, anyhow) is to
>design a memory card that let the memory be accessed from two
>sides.  This would make animation twice as fast, but with the
>8 meg limit on the GS might be a bit of a trade-off.  Along
>with having to put two cards in your machine.

This could be expensive if you really want it to be twice as
fast.  You could design a board that could grant access to
port A or B one-at-a-time, but you end up with the old processor vs.
graphics hardware war contest.  The processor would want the bus to
run your animation code, but by using the bus you're denying it to
animation engine.  On the other hand, if you use actual dual-ported
RAM, the price per megabyte could be several times higher...lessee,
I think it's about $99 for 256K or 512K of Mac VRAM.

I've always thought it would be neat to take advantage of memory
reserved above the 8Meg mark.  The 65816 can address 16M with its
24-bit address bus, after all.  So, define a nice contiguous
framebuffer somewhere that NO program would ever be, and hope that
whoever is in charge of this area (DTS, I guess) is kind enough to
let you do it officially.  From my disadvantaged perspective, I can't
think of any reason why DTS would disapprove of something like this.
--
Dave Seah ^..^   | Graduate MSEE, University of Rochester, New York           |
                 | Apple II Graphics & Sound Forum Consultant, America Online |

[Internet] [e-mail], [e-mail]   [America Online] AFC DaveS