DOS ain't dead - Jordan Hargraphix SvgaBGI goes MIT license

Berlin, Germany,
19.12.2020, 14:58

Jordan Hargraphix SvgaBGI goes MIT license (Announce)

In April 2020 I got in touch with Jordan Hargrave, who wrote SVGA BGI drivers for Turbo C/Turbo Pascal/Borland C++ until the mid-1990s: Third-party BGI drivers - Borland Graphics Interface - Wikipedia.

Jordan writes today:
Hi Robert,

If you are still interested in the BGI drivers, I found an old box of disks which had my original Svga driver source on it! So I've now posted that up to github.
It would be interesting to know if they still work!!

https://github.com/jharg93/SvgaBGI

Enjoy!
--jordan hargrave

According to the Wikipedia article, there are bugs in the drivers, which can be fixed now.

---
Forum admin

DosWorld

19.12.2020, 15:25
(edited by DosWorld, 19.12.2020, 15:44)

@ rr

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

Definitely i am not a BGI'fan, but nice to hear it! :ok:

> According to the Wikipedia article, there are bugs in the drivers,
> which can be fixed now.

If somebody start work with it, please pay attention for optimization and speed. Speed of original Borland-BGI drivers can kill any interest.

For modern time, may be speed is acceptable, but at 80286-time it was usable to draw schoolar's y=f(x) only.

Another point - using BGI without Borland.

---
Make DOS great again!
Make Russia small again!

RayeR

CZ,
19.12.2020, 19:07

@ DosWorld

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> For modern time, may be speed is acceptable, but at 80286-time it was
> usable to draw schoolar's y=f(x) only.

Yeah, I remember the same experience when I started programming on my 486. My 1st y=f(x) was in QBASIC and then we was learning Pascal at school so I used BGI in some of my programs. Uh, happy it's gone and switched to C long time ago...

---
DOS gives me freedom to unlimited HW access.

marcov

21.12.2020, 14:40

@ DosWorld

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> For modern time, may be speed is acceptable, but at 80286-time it was
> usable to draw schoolar's y=f(x) only.

How many of the alternatives were mode independent ?

That modeindependence bit, and the plotter option were the main attractions (note, haven't used BGI in this century, moved to FPC's graph unit), as well as having at least a scalable font option, though not the nicest(*).

(*) I did some (non dos) opengl work with signed distance fonts, and they look way nicer.

DosWorld

22.12.2020, 15:40

@ marcov

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> How many of the alternatives were mode independent ?

I don't want start fight about it, because it is different type of parameters - "speed" and "mode-independent" (like compare what better - "stone" or "keyboard"). For each use-case, answer could be different.

PS: Yep, i don't remember alternatives for mode-independent API in Dos.

---
Make DOS great again!
Make Russia small again!

marcov

22.12.2020, 22:49

@ DosWorld

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> > How many of the alternatives were mode independent ?
>
> I don't want start fight about it, because it is different type of
> parameters - "speed" and "mode-independent" (like compare what better -
> "stone" or "keyboard"). For each use-case, answer could be different.

No fighting needed, just wanted to insert a different perspective.

Yes, mode X was easy to do fast with a bit asm, but that was fairly lowres.

There was no effective VESA 2.0 yet in BP times (we are talking 1994 here), so that was basically the state of it.

I was doing a Chemical Engineering masters in that time, and making pretty graphs in dos that were somewhat portable was a boon.

Guti

21.12.2020, 09:51

@ rr

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

I used them in the past but soon moved to SVGA386.BGI by Ullrich von Bassewitz with are a lot of faster (https://www.von-bassewitz.de/uz/bgi.php)

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Guti

23.12.2020, 16:48

@ Guti

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> I used them in the past but soon moved to SVGA386.BGI by Ullrich von
> Bassewitz with are a lot of faster
> (https://www.von-bassewitz.de/uz/bgi.php)

If anyone's is interested I just forked your Ullrich von Bassewitz's SVGA BGI drivers on Github, and applied some optimizations and updates:
https://github.com/javiergutierrezchamorro/SVGABGI/tree/main/svga

Regards.

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Khusraw

Bucharest, Romania,
23.12.2020, 18:40
(edited by Khusraw, 23.12.2020, 19:06)

@ Guti

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> If anyone's is interested I just forked your Ullrich von Bassewitz's SVGA
> BGI drivers on Github, and applied some optimizations and updates:
> https://github.com/javiergutierrezchamorro/SVGABGI/tree/main/svga
>
> Regards.
>
>
> > I used them in the past but soon moved to SVGA386.BGI by Ullrich von
> > Bassewitz with are a lot of faster
> > (https://www.von-bassewitz.de/uz/bgi.php)

IIRC his SVGA BGI driver used the width in pixels instead of the number of bytes per scan line in calculating the video offsets, and that made it not work properly in cases where the number of bytes per scan line is larger. Did you fix this bug in your fork? IIRC again, it was easy to fix, just by replacing a variable name in a few places.

---
Glory to God for all things

Guti

24.12.2020, 08:46

@ Khusraw

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> IIRC his SVGA BGI driver used the width in pixels instead of the number of
> bytes per scan line in calculating the video offsets, and that made it not
> work properly in cases where the number of bytes per scan line is larger.
> Did you fix this bug in your fork? IIRC again, it was easy to fix, just by
> replacing a variable name in a few places.

Not yet. Just started looking at it and applying tight changes. Mainly enabling it to build with TASM 5 too. Of course you can fork it or submit a patch.

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Khusraw

Bucharest, Romania,
24.12.2020, 11:25
(edited by Khusraw, 24.12.2020, 12:18)

@ Guti

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> Not yet. Just started looking at it and applying tight changes. Mainly
> enabling it to build with TASM 5 too. Of course you can fork it or submit a
> patch.

Unfortunately I don't have time now to contribute with a patch and, to be honest, my interest in it is quite low, but the problem arises from the fact that it uses "MaxX" instead of "BytesPerLine" in the calculations needed to get the video offset (and bank). You can see a couple of examples (taken at random) below, "MaxX" should be replaced with "BytesPerLine" to make it work properly in cases where the number of bytes per scan line is larger than the width in pixels (I have a couple of video cards that make the problem obvious in mode 800x600).

PROC PutPixel add bx, [PageOfs] ; Bildschirmseiten-Korrektur mov cl, dl ; Farbe retten xchg ax, bx ; Y in ax, X in bx mul [MaxX] ; * Zeilenl„nge add bx, ax ; + Offset adc dl, 0 ; Segment-šberlauf mov [Seg64], dl ; Segment merken call [SegSelect] ; Segment einstellen mov ds, [VideoSeg] ; Videosegment holen mov [bx], cl ; Byte schreiben ret ENDP PutPixel

PROC RestoreBitmap NEAR [...] ; Errechnen wieviel bei Erreichen des Punktes X2+1 dazugez„hlt werden muá um ; X1 in der n„chsten Linie zu erreichen mov cx, [MaxX] sub cx, ax push cx ; Wert retten [...] ENDP RestoreBitMap

---
Glory to God for all things

Guti

24.12.2020, 12:28

@ Khusraw

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> > Not yet. Just started looking at it and applying tight changes. Mainly
> > enabling it to build with TASM 5 too. Of course you can fork it or submit
> a
> > patch.
>
> Unfortunately I don't have time now to contribute with a patch and, to be
> honest, my interest in it is quite low, but the problem arises from the
> fact that it uses "MaxX" instead of "BytesPerLine" in the calculations
> needed to get the video offset (and bank). You can see a couple of examples
> (taken at random) below, "MaxX" should be replaced with "BytesPerLine" to
> make it work properly in cases where the number of bytes per scan line is
> larger than the width in pixels (I have a couple of video cards that make
> the problem obvious in mode 800x600).
>
> PROC PutPixel> > add bx, [PageOfs] ; > Bildschirmseiten-Korrektur > mov cl, dl ; Farbe retten > xchg ax, bx ; Y in ax, X in bx > mul [MaxX] ; * Zeilenl„nge > add bx, ax ; + Offset > adc dl, 0 ; Segment-šberlauf > mov [Seg64], dl ; Segment merken > call [SegSelect] ; Segment einstellen > mov ds, [VideoSeg] ; Videosegment holen > mov [bx], cl ; Byte schreiben > ret > > ENDP PutPixel
>
> PROC RestoreBitmap NEAR> [...] > > ; Errechnen wieviel bei Erreichen des Punktes X2+1 dazugez„hlt werden > muá um > ; X1 in der n„chsten Linie zu erreichen > > mov cx, [MaxX] > sub cx, ax > push cx ; Wert retten > > [...] > ENDP RestoreBitMap

Thank you. According to the DOCs, and it seems so in the code, during initalization it will use VESA BytesPerLine. This was added in original 3.51A: "The driver no longer assumes that logical and real line lengths are identical (this is when controlling via VESA driver.

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Khusraw

Bucharest, Romania,
24.12.2020, 12:46
(edited by Khusraw, 24.12.2020, 13:01)

@ Guti

Jordan Hargraphix SvgaBGI goes MIT license

Post reply

> Thank you. According to the DOCs, and it seems so in the code, during
> initalization it will use VESA BytesPerLine. This was added in original
> 3.51A: "The driver no longer assumes that logical and real line lengths are
> identical (this is when controlling via VESA driver.

I don't know which driver doesn't assume it, because the latest driver I know still assumes it, being the driver that made the bug manifest to me. As you can see in cards.asi, the value for the number of bytes per scan line is correctly saved in "BytesPerLine", but in the calculations from svga.asm the driver uses "MaxX" instead of "BytesPerLine" ("MaxX" being the width in pixels, in case you know a line of code where "MaxX" gets the value of "BytesPerLine", please point it to me).

; VESA-Infos wurden erfolgreich geholt, es:di zeigt auf den VESA-Info Block. ; Zuerst mal die Anzahl Bytes pro Scanzeile holen und in der globalen ; Variable BytesPerLine speichern. Dies berschreibt die Vorbelegung von ; Init, bisher steht dort derselbe Wert wie in MaxX. @@L2: mov ax, [(VESA_InfoBlock es:di).BytesPerLine] mov [BytesPerLine], ax

---
Glory to God for all things