Check what int10 functions (especially ah=0x4f..) are used.

Pretty sure its 0x103-
Will see if I can find the relevant line with notepad++ and confirm.
Yes, I use 0x03 and 0x103

Best,
Byron

Well- those are the video modes used. All the video setting is done with the library's function vsa_init( hexmod ). I'm not calling int10h myself in the code, and I've not access to the library source so I do not know what it is passing there.

Can you compile a very short example program that exhibits the problem, and post it here?

I can't compile a repro case as I don't have a Borland C++ compiler working on my computer at the moment. The old program in question is pretty small by todays program-size standards and I've attached it.

I cannot remember exactly what the screen will look like if it works, but I believe you will get two homemade buttons presented in the middle of the screen, perhaps offering to load a file or build a simulation.

If it does not work, you'll get a short paragraph in red text from the vesa library beginning with the line posted earlier.

If you get neither- then I'm forgetting to include some file that it needs, like EGAVGA.BGI or something, though I believe all the files it needs were embedded into the .exe. Based on its timestamp, its been 14 years since I worked on it.

I did make this program work with dosbox a couple years ago- and I have a vauge impression that it was on my old vista machine laptop with an Nvidia 8600 card- but that machine has since melted.

Best,
Byron

I just found some old documentation I made on the program. It will need two additional files in the same director with the program to run properly if it runs at all. One is egavga.bgi, and the other is nodes.iaf which was sortof my version of a bitmap file. They are in the attached zip.

Best,
Byron

The error message is displayed when INT 10/4F01 is called to get information about VESA mode 0x103 (800x600x256) and bit 2 ("BIOS output supported" according to RBIL) of the mode attributes is not set.

I tried setting the bit in the attribute and the program went on to display this:

I suspect the attribute bit is set correctly for DOSBox's capabilities, but I'm not sure; however, the application might not really need that support.

Maybe a different machine= and/or univbe would work

What you're showing is correct. The program first tries to see if the 800x600x256mode will work by setting that mode, then setting back to a standard screen mode. It draws what you see using the old BGI routines from Borland, then once the user either reads or builds a new simulation, it initializes some neural networks, switches to the 800x600x256 mode and displays some animated results.

Is the magic you did "..setting the bit in the attribute " something any dosbox user can do? If so, could you direct me to the proper reading material?

All the best, and many thanks for your time with this.
Best,
Byron

I've been able to get the code to recompile, though it took some voodoo & tea leaves. It runs, but I had to omit text support in the 800x600x256 mode.

That vesa256bc.lib was a library written by someone called "Spyro Gumas" and included with the 1993 Sams Publishing book "Tricks of the Graphics Gurus"

Best,
Byron

I tried using SDD 5.3a for DOS, but then the program aborts with a divide overflow error for some reason.

I don't really know what I'm doing with the program, it's rather cryptic, but I got it to "run" some data and it produces a complicated screen in mode 103 that has text amongst the graphics. Do you actually lose anything by omitting the text requirement?

I've attached the TSR that I made to get past the error message.

Sir you are golden. With your tsr the old compilations run, and I have four of these programs I was going to have to dig up and modify. Editing files in turbo C++ through dosbox isn't all that fun. I appreciate it very much.

As the text provides a legend for what the various lines & colors mean, it wasn't quite the same without it.

The program is a neural-network simulator I wrote around 1993-1994. I've a somewhat newer version of it I did in 1998 (their general functioning is described in one of my blog entries)
http://drjbn.wordpress.com/2011/01/12/neural- … rning-research/

The program is cryptic as I was pretty much the only person who was ever going to be using it.

In the rare case you're curious, I've attached the manual I wrote back then to this post. I've also attached a simulation file that will run something and make for a nice display. When it asks for a filename, use exp4.txt, when it asks for a simulation name, just put exp4.

many thanks again,
Byron

ripsaw is it only about the output-bit? That should merely be the "string writing functions supported
in vesa graphics modes" which hal and/or harekiet added (fixed whatever), that should fully work.

Yes, the application appears to only have a problem because the attribute bit for "BIOS output" is missing. I wasn't sure if the text functions are supported in VESA modes, but apparently they are. The various mode types in VESA_GetSVGAModeInformation() have "modeAttributes = 0x1b;" so would it be appropriate to change that to "modeAttributes = 0x1f;" for some if not all of them?

Iirc anything that would cause vram banks to be switched (>64k) is not supported

You mean any string write that'd trigger a bank switch would mess up? I thought putpixel was used or so, thus being fine for that, but may be wrong.

Could be that I didn't find the right code location yet 😉

Think it's WriteChar which is where PutPixel kicks in. Looks solid, unless PutPixel dislikes certain vesa modes.....

If I'm reading PutPixel() correctly, only the M_LIN8 (256 color) type is supported among VESA modes, and I can confirm that changing the attributes on that type to 0x1f does make the application happy.