king@client2.DRETOR.UUCP (Stephen King) (06/29/88)
I have been thinking for some time about designing an auxilliary frame
buffer for the Amiga. I would like to see more discussion about the kind of
features an item like this should have. Here are my ideas:
1) Works as expansion RAM or dedicated to video.
2) Will scan convert - works as deinterlacer, scan doubler.
3) Sits on Amiga bus: uses Amiga system timing. (not on PC bus side)
4) 16 bits per pixel: 5 each RGB, 1 ignored.
Comments? Is this the best place for a discussion, or should it go to the
.tech group? Ideally, I would like to design this thing, get some bucks
together to have a PC board cut and then release the whole thing PD. I am,
however, constrained by conflict-of-interest guidelines, and may not be
able to take the thing all the way on my own. I can contribute to any
ongoing discussion and point out certain ways of accomplishing the above
goals, if the net so desires. We should establish some sort of a standard
for aux. Amiga frame buffers (for obvious reasons).
Stephen J King ...{utzoo|mnetor}!dciem!dretor!kingcmcmanis%pepper@Sun.COM (Chuck McManis) (07/01/88)
In article <726@client2.DRETOR.UUCP> (Stephen King) writes: >I have been thinking for some time about designing an auxilliary frame >buffer for the Amiga. I would like to see more discussion about the kind of >features an item like this should have. Here are my ideas: Good idea, some untenable goals however. >1) Works as expansion RAM or dedicated to video. Implementation questions, how would you tell it how to autoconfig? The only option I can see would be no autoconfig and a user program to optionally add it to user space. Second question, the first idea seems to indicate it would be in the Amiga RAM space, any idea how you would get things to draw in the particular area? There is no AllocMem(MEMF_WHERE_I_WANT_IT) call. Tough problem there. >2) Will scan convert - works as deinterlacer, scan doubler. Not possible sitting on the Amiga bus but you could always run a cable over to the video bus to achieve the same effect as the FlickerFixer. Still, one has to ask if this isn't a bit of overkill for this project. >3) Sits on Amiga bus: uses Amiga system timing. (not on PC bus side) This is the good part, I like this best. >4) 16 bits per pixel: 5 each RGB, 1 ignored. Make the extra bit mean something, maybe a monochrome graphics overlay or special video mode. If you could do feedback from the Amiga video into the board (as idea 2 seems to indicate) you might consider thinking about making this bit select your frame buffer or Amiga video. >Comments? Is this the best place for a discussion, or should it go to the >.tech group? Ideally, I would like to design this thing, get some bucks >together to have a PC board cut and then release the whole thing PD. I am, >however, constrained by conflict-of-interest guidelines, and may not be >able to take the thing all the way on my own. I can contribute to any >ongoing discussion and point out certain ways of accomplishing the above >goals, if the net so desires. We should establish some sort of a standard >for aux. Amiga frame buffers (for obvious reasons). >Stephen J King ...{utzoo|mnetor}!dciem!dretor!king Don't worry about standards, build something, if it is useful it will be standard. 80% of the computer user population seems to have forgotten that it is nearly impossible to come up with a standard first and an implementation second. Do something, if it's good we'll standardize on it. The next comment is a bit more down to earth. This is an interesting idea if not incredibly overreaching. That's good, cause you grow when you are overextended, but it doesn't bode well for the prospects of the project ever seeing the light of day given you available commitment to it. Consider the following scaled down project : Build an autoconfig card for the Amiga that has a VGA chip on it. I was reading an advertisement where one of the chip houses have everything but the 6 support chips and 8 DRAMS in one package. That gives you all the modes you will want in the near future, a ready supply of monitors, and equivalent capabilities of the "competition". The whole design would take you a month tops. Then sit down and write a resident library that talks to this think. Add to it all of the kinds of things you do with intuition now, (you can probably get away without doing windows and layers but it would be nice to support the mouse on that screen) make the thing PD if you want or license it to software developers for $100. Then start pluggin these things into Amigas and capturing a bunch of applications (like CAD) that aren't taking the Amiga seriously. Because it is a resident library and you have *Documented* all of the calls to it, other vendors might start building frame buffers and using your library interface. Make sure the library has a call that returns all of the possible configurations of the screen to the calling program so that everyone can take maximum advantage of your board. Suddenly, two things will have happened. First, there will be a "frame buffer graphics" standard, and second, the graphics market for the Amiga will be wide open again. If it really flys maybe we can get Jim and Dale to support it by making a layers/intuition interface to it. If you are going to wait for Commodore to do this, don't. They are too busy with the stuff they already are doing. If you are seriously considering pursuing this then let me know. Between this and the BusAdapter I think I have the fundamentals for a fairly reasonable business plan. Gail, if you are reading this, let's have lunch. :-) --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.