DOS ain't dead

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

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

> 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!

> 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.

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

> 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.

> 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!

> > 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.

> 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

> 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

> 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

> 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

> > 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

> 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