rjc@.tmc.edu (Ray Cromwell) (12/17/90)
[cross-posted because of the hardware & software aspects of RTG] [reposted. It seems the last time I posted it, it disappeared.] About a year ago if you asked a developer why there aren't any video boards or device independent libraries he might respond: 'There aren't any video boards because there isn't any device independent library support, and there aren't any device independent libraries because there are no video boards.' This type of circular reasoning seemed to suggest the Amiga video market was boxed in at both sides. Miracously, it has broken out of this loop. I can count atleast 10 framebuffers or video mode enhancer boards (HAM-E) now. The reason I'm writing this is because it will be atleast another year before Commodore releases any retargetable specs/libraries, but we need them now. I suggest that the Amiga hardware and software vendors should get together and work towards a temporary stop-gap for video independence. If the PC world can do it (EISA?), so can we. Now I'm not suggesting running Intuition screens on video boards/frame buffers. What I'm suggesting in a simple set of graphic primitives to dump IFF24 bit files to framebuffers. Perhaps, a rtg.library which Commodore can replace at a later date with their own. What this library might contain is calls to plot a pixel, plot a line, do a pattern fill, and dump a scanline. (also routines to read pixels/scanlines, and request screen dimensions). If you haven't noticed, Imagine supports output to Firecracker, Toasterpaint outputs to the Toaster(of course), DCTV and HAM-E have their own paint programs. Its getting redundant having software specially tailored to specific hardware. With a simple library of primitives, current software could utilitize all the new boards coming out. In fact, simple hacks could be created to make current software work without any changes. Simply make a DOS level IFF handler. (IFF: ?) And have software save files to IFF: instead of disk. (I guess it would be better to pipe the data to IFF: and disk. So it isn't lost.) The only thing that would be required is that vendors make their own rtg.device. Then, an Amiga owner could easily put the IFF: handler in his mountlist and have it use the right rtg.device. Please, I don't wish to start any flame wars. Don't respond to this message with posts like 'If Commodore doesn't implement RTG immediately, the Amiga is dead.' Instead of attacking Commodore or the Amiga, why don't we utilitize our combined skills, and actually do something productive- like try and agree on a temporary stop-gap for RTG until Commodore gets their act together-. My ideas are merely suggestions. Lets not get too complicated with stuff like emulating the blitter/copper, and supporting intuition/workbench style windows on video boards. I'm only interested in allowing portability between video software and hardware until real RTG is implemented. (Hopefully ADOS 2.1/2. RTG is easier to do than MMU Protection.) I also realize none of this is needed as we could all go out and buy ASDG's Art Department, process the images, and load them up into dctv/hame/toaster/firecracker24s conversion software. This process is lengthy (it could be automated by arexx assuming all the conversion software had an arexx port and STANDARD commands), but it is much easier to support a dump from a library directly to the attached hardware for display. So now the Amiga is getting a myriad of video boards. I feel one way or another this is going to FORCE an rtg standard. The Amiga is not an IBM, we just can't go poking registers on hardware boards, and making drivers for each board.(like IBM programmers have to do with all those cga/ega/vga/super vga/foobar enhanced vga). Amiga developers are used to having OS facilities to help development. I don't think anyone feels like crafting routines to poke registers on hame/dctv/firecracker everytime they develop some new software.
swarren@convex.com (Steve Warren) (12/18/90)
In article <1990Dec17.135654.24229@mintaka.lcs.mit.edu> rjc@.tmc.edu (Ray Cromwell) writes: ^^^^^^^^^^^^ What kind of address is this? A bogus one? Or just a screwed up server? [...] >[cross-posted because of the hardware & software aspects of RTG] > >[reposted. It seems the last time I posted it, it disappeared.] [...] OK, an honest mistake. Please stop. This is the fourth copy that has appeared here. Does anyone know what to make of this header? : >Path: convex!texsun!newstop!sun-barr!olivea!mintaka!!rjc >From: rjc@.tmc.edu (Ray Cromwell) ^^^^^^^^^^^^ >Newsgroups: comp.sys.amiga,comp.sys.amiga.tech,comp.sys.amiga.hardware >[2] Retargetable Graphics. A temporary Stop-gap? >Message-ID: <1990Dec17.135654.24229@mintaka.lcs.mit.edu> >Date: 17 Dec 90 13:56:54 GMT >References: <1015.276C6133@weyr.FIDONET.ORG> >Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius) ^^^^^^^^^^^^^^^^^^ >Organization: None >Lines: 61 >Xref: convex comp.sys.amiga:59014 comp.sys.amiga.tech:17135 comp.sys.amiga. >+ hardware:4722 Ray, if you are for real then why don't you leave a real address to reply to? -- _. --Steve ._||__ DISCLAIMER: All opinions are my own. Warren v\ *| ---------------------------------------------- V {uunet,sun}!convex!swarren; swarren@convex.COM