Re: svgalib/ggi

Search this archive.

From: Russell Marks (russell.marks@dtn.ntl.com)
Date: Wed 16 Feb 2000 - 12:34:37 IST


> I think that the answer Michael wrote (two or three years) ago is pretty
> much applicable today. Plus the fact that ggi people seem to broaden
> the scope of their library every once in a while (3d, input, ...) and
> also seem to completely change the kgi driver model every once in a
> while (which requires rewrite of all drivers), which is why they have
> very few working drivers after all those years.

Ah.

> > > About cga and mda cards, svgalib has no support for them. It does not
> > > make sense to add support, as no current svgalib program will work,
> > 
> > With respect, while svgalib should certainly not have *anything* to do
> > with CGA/MDA (*shudder*), it might be nice if something like this was
> 
> I use MDA with my celeron, nothing special about that. 
> I also used for a few months a 386 with mda to write my papers, so an
> svgalib equivalent could be nice. I had to use X, though.

Well, I should rephrase (retract?) what I said there - I don't
actually have a problem with svgalib supporting those, as such, it
just seems like an extra complication you don't need. If you *want* to
do it, of course, then hey, why not. :-)

Actually, I think there's some old Hercules (I think it's
(pedantically) Hercules not MDA if we're talking about graphics mode,
isn't it?) code on metalab. Yep, found it, it's
/pub/Linux/apps/graphics/viewers/hgcpbm.tgz. Looks like it wouldn't be
too hard to adapt.

> > FWIW though, in case it's relevant, I should point out you have
> > virtually zero chance of existing svgalib programs running in ELKS,
[...]
> I don't even know if they use the same binary format, I just said that
> if you keep api close to svgalib, then porting apps should be easier,
> which is true in a general way.

Oh, yes, that's true.

> > > since svgalib has no 2 bit color modes. If you design a library for
> > 
> > Are you sure? From vga.h:
> > 
> > > #define G640x480x2   9
> 
> 2 is number of colors, so 640x480x2 is 1 bit color.

D'oh! Mental note: I must... think... before... posting... :-) I plain
forgot about the 320x200 2-bit mode; I must have been thinking of
640x200 1-bit. I think true CGA cards have a 160x200 16-colour mode,
too, don't they?

> > ghostscript!? I think you really must have missed the ELKS bit. It's
> > just too big, alas (and the slowness would be mind-blowing). Not sure
> > about tmview, but that seems fairly unlikely too. And FWIW, zgv is
> > *right out*. :-)
> 
> I'm sure they will get beyond the 64K limit sometime.

It's tricky due to segmentation. Go over 64k and you need to deal with
far pointers and all that fun stuff you need in e.g. medium/large/huge
memory models on 16-bit DOS C compilers, as you (obviously) no longer
have a flat memory space. That's why real-mode Minix never got past
64k+64k (per process). Maybe the ELKS folks'll do it (they could
already have done it for all I know), but most ports would still be
hard work.

> I remember writing a simple postscript interpreter for a spectrum
> (+2, but there are segmenting issues as well).

*Yow!* We're not worthy! We're not worthy!

Somehow, though, I can't imagine golfer.ps coming out all that well on
a ZX Printer... :-)

-Rus.


This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:23 IST