Extending Turbo Vision with graphics?

[Jim Leonard]

I know this is a longshot as this group is nearly dead, but I have to try asking: I will be writing a menu front-end that must run on any DOS-based PC (even 808x systems, this is for a museum project) and would like to avoid writing an entire CUI framework from scratch. Turbo Vision obviously comes to mind, however one of the requirements is that, while running in text mode is ok, on VGA/SVGA systems the front-end should also display a bitmap that changes as the user selects a new item.

I have seen code that tries to extend Turbo Vision to run in graphics mode, so that it looks/feels identical to text mode but also lets you display graphics. I have also seen complete Turbo Vision replacements such as GraphicVision, but those have no text mode equivalent (and IIRC require a 386). So far the closest solution has been something like this: http://aeinc.ru/gtv.php but the documentation is all in Russian which I do not read.

Does anyone have any suggestions on how to (very simply) extend Turbo Vision to graphics mode? Is it as simple as hooking where the 80x25/43/50 raw screen data is and then redrawing that in graphics mode, or is that not feasible? Is there a prewritten library that I'm unaware of that fits the bill?

[Dr J R Stockton]

In comp.lang.pascal.borland message <f50d0908-5afb-4331-b86f-805c875885b

Post by Jim Leonard
I know this is a longshot as this group is nearly dead, but I have to
try asking: I will be writing a menu front-end that must run on any
DOS-based PC (even 808x systems, this is for a museum project) and
would like to avoid writing an entire CUI framework from scratch.
Turbo Vision obviously comes to mind, however one of the requirements
is that, while running in text mode is ok, on VGA/SVGA systems the
front-end should also display a bitmap that changes as the user selects
a new item.
I have seen code that tries to extend Turbo Vision to run in graphics
mode, so that it looks/feels identical to text mode but also lets you
display graphics. I have also seen complete Turbo Vision replacements
such as GraphicVision, but those have no text mode equivalent (and IIRC
require a 386). So far the closest solution has been something like
this: http://aeinc.ru/gtv.php but the documentation is all in Russian
which I do not read.

I looked there, and almost all seemed to be in English. Could you give
the URL of the actual Russian that you would like to read? The browser
Firefox has a convenient add-on translator - the icon is a simple red
letter "T" in a serif font - which (for you) I tested on the Russian
Wikipedia page for "Banana". The results seemed reasonably
comprehensibly and agreed with what little I know about Bananas. I
expect it is the same translator as at <http://translate.google.com/>.

Post by Jim Leonard
Does anyone have any suggestions on how to (very simply) extend Turbo
Vision to graphics mode? Is it as simple as hooking where the
80x25/43/50 raw screen data is and then redrawing that in graphics
mode, or is that not feasible? Is there a prewritten library that I'm
unaware of that fits the bill?

I certainly found it easy enough to get the screen data, encoded in
"8-bit ASCII". I could possibly do it again. But I expect you know all
about that part of it. IIRC, it is also easy enough to read (and alter)
the font table.

Perhaps you do not need the full TV GUI? If you can use a fixed box or
boxes in which menus appear, and use that font table, it could
substantially reduce the task of providing what you need.

FYI, I still have an Amstrad PPC640 running DOS 3.3 and TP5, with
2*720KB FDD. This networked WinXP machine can handle those discs.

[Stefan Strobel]

Post by Dr J R Stockton
FYI, I still have an Amstrad PPC640 running DOS 3.3 and TP5, with
2*720KB FDD. This networked WinXP machine can handle those discs.

Hi,
remember those days.
This was my first PC too.
Came together with "GEM" and had a EGA card
Kind regards
Stefan

[Marco van de Voort]

Post by Jim Leonard
I know this is a longshot as this group is nearly dead, but I have to try
asking: I will be writing a menu front-end that must run on any DOS-based
PC (even 808x systems,

That kills a lot of options. You'll be spending most of your time fighting
memory idiosyncrasies of the 16-bit memory model. Specially if you add
memory hungry graphics.

Post by Jim Leonard
this is for a museum project) and would like to
avoid writing an entire CUI framework from scratch. Turbo Vision
obviously comes to mind, however one of the requirements is that, while
running in text mode is ok, on VGA/SVGA systems the front-end should also
display a bitmap that changes as the user selects a new item.

The FPC TV clone (called FV) is based on a graphics vision (by Leon de
Boer, who afaik based himself on the PD C++ code), backported to textmode.

One of the major changes was reworking the codebase for changes to the
coordinate system (from pixels back to chars). If you can keep the
coordinates in chars, you can probably reuse most of any TV clone, and write an
appropriate drivers unit for it (that paints to graph mode)

The result will be less integrated since you still emulate text for most
drawing, so no fancy window borders, and all coordinates would be in
characters still.

Post by Jim Leonard
Does anyone have any suggestions on how to (very simply) extend Turbo
Vision to graphics mode? Is it as simple as hooking where the 80x25/43/50
raw screen data is and then redrawing that in graphics mode, or is that
not feasible?

It might also read the screen. But I think you can intercept it already
earlier, in the place where TV decides where to draw which parts of the
screen. TV draws incrementally, iow only areas that are changed. Probably
not unimportant on a 8086 :-)

Post by Jim Leonard
Is there a prewritten library that I'm unaware of that fits
the bill?

1) Create a drivers unit implementation for your graphics mode that emulates
the drawing of each widget. I don't know if the TV implementation really
only draws via drivers though.

2) For pixel graphics you could create a TView derivative that registers its
coordinates (on create/change/destroy) and the reference to the picture with
the (drivers/video) drawing backend (using a new interface)

The the drawing backend can use that knowledge to not paint character
emulation (the empty characters) to that tview area, and paint the picture
instead. (and e.g. use the tview background as fill colour for areas of the
tview that are not covered by the image.