How does this software behave without emm386 running?

When running without emm386, an endless blinking cursor.
When running in dosbox-x, the same ASCII mess followed by a reboot.

Are we sure this program didn't get corrupted when the SBC got zapped?

Fairly sure, the HDD contains 2 partitions, each partition contains the program and a backup. I've compared the files using winmere.
Only some CNC variables are different. To be sure, I tried all versions (same result)

Maybe a last clue (before I'm out off ideas). I tried some different things with dosbox-x to get some visual feedback and found out, when deleting one particular file. The program starts after blinking ASCII mess, but it it looks like all text is missing from the GUI. (I can navigate menu's).
This is dosbox running without emm386.

When I replicate the same on real hardware, it still show the ASCII mess.

I cant explain why this file, it contains readable text, what looks like parameters:

1[EDITLEN=10]
21|1|X  EXIST                                |YL  |0|1
35|0|X  +/- ROTATION                         |YL  |0|1
49|16|X  KV [1/SEC]                           |DL  |0|900
513|12510|X  VMAX / 8V [^1]                       |FL  |0|50000
617|50640|X  PULSES/1000[^2]                      |DL  |1|99999999

Is this with telling dosbox-x to emulate an et4000?

Is the program using 8x14 font maybe?
https://gekk.info/articles/8x14.html

PS: Older VGA cards often have had a "RAM BIOS" on the driver/utility disk.
It's a VGA BIOS that installs itself in RAM. ET-4000 had one, too, I think.
It was meant to improve performance (no ROM access needed).
That basically was an alternative to using shadow memory.

As Jo22 said, support for the indicated font size was removed from the BIOS to save space for other support and due to lack of use. I remember hearing that there is a driver which adds back that support but don't remember its name or where I found it. 🙁

wierd_w wrote on Yesterday, 16:11:

Is this with telling dosbox-x to emulate an et4000?

This comment led my into a rabbit hole of testing and gave me a hint of what is failing.
I found out some bits and pieces:
*By looking at strings off the .exe, I saw the path is hardcoded for the files and the program needs to be run from the correct directory.
*I've written a script that runs dosbox with every machine type available (including et4000x)
*I've written a script to test the different emm386 memory ranges.

Some conlusions:
I got a config that works in dosbox-x! (It doesn't hang and the GUI starts).
Many machine types work with "newer" graphic cards (S3, VGA, et4000x,...)
The file that I deleted, still needs to be deleted (I know what the function is - machine parameters -> worries for later)
Only the original config.sys with strange EMM386 memory ranges work (afterward I tried all suggestions)
The CPU type in dosbox-x can't be auto, it needs to be normal (so it is very picky)

When I try to replicate this setup in real hardware, the computer always hangs on the emm386 line. (I've also tried all the previous suggestions with the current knowledge).
(DEVICE=C:\DOS\EMM386.EXE FRAME=E000 RAM=B000-BFFF RAM=D100-D7FF X=D000-D0FF X=D800-D9FF RAM=C800-CFFF RAM=DD00-DFFF)

To be fair, I'm not fluent in dos memory mappings 😉

Little update:
I found out what makes troubleshooting harder, after booting (and running the config.sys) no more information is seen in the terminal.
For example, if I add some "echo comments" to the autoexec.bat and pause; I can see the computer waiting for the pause but no commands and no echo is seen on the screen.
So I suspect the program writes to the graphics card directly.

debnie wrote on Today, 08:50:

Little update: I found out what makes troubleshooting harder, after booting (and running the config.sys) no more information is […]
Show full quote

Little update:
I found out what makes troubleshooting harder, after booting (and running the config.sys) no more information is seen in the terminal.
For example, if I add some "echo comments" to the autoexec.bat and pause; I can see the computer waiting for the pause but no commands and no echo is seen on the screen.
So I suspect the program writes to the graphics card directly.

The problem here is the RAM=B000-BFFF option - text output needs either B800-BFFF (color) or B000-B7FF (monochrome). With RAM=B000-BFFF only applications that use an EGA/VGA graphics mode can display something...

Actually, by reprogramming the VGA chips it's possible to have text output in the A000 segment. With an appropriate DOS TSR it might then be ok to display text via DOS/BIOS - but I doubt that such an uncommon - and dangerous - config is the case here.

Baron is right: try replacing "RAM=B000-BFFF" with "RAM=B000-B7FF." That helped on several of my PCs. 😀 BTW, I remember having a tool that can add the video buffer starting at A000 to Conventional RAM but not its name or where I got it. 🙁

Baron von Riedesel wrote on Today, 09:37:

debnie wrote on Today, 08:50:

Little update: I found out what makes troubleshooting harder, after booting (and running the config.sys) no more information is […]
Show full quote

Little update:
I found out what makes troubleshooting harder, after booting (and running the config.sys) no more information is seen in the terminal.
For example, if I add some "echo comments" to the autoexec.bat and pause; I can see the computer waiting for the pause but no commands and no echo is seen on the screen.
So I suspect the program writes to the graphics card directly.

The problem here is the RAM=B000-BFFF option - text output needs either B800-BFFF (color) or B000-B7FF (monochrome). With RAM=B000-BFFF only applications that use an EGA/VGA graphics mode can display something...

Actually, by reprogramming the VGA chips it's possible to have text output in the A000 segment. With an appropriate DOS TSR it might then be ok to display text via DOS/BIOS - but I doubt that such an uncommon - and dangerous - config is the case here.

I tried (one of both gave a warning that there is option rom or ram within page frame):
*B800-BFFF
*B000-B7FF

Both resulted in the ASCII colorful mess.

If the ET4000 is not explicitly *necessary*, it may be valuable to check if the integrated VGA has a smaller bios or not, since the integrated vga is less likely to be angry about the B000-B7FF include.

Baron von Riedesel wrote on Today, 09:37:

Actually, by reprogramming the VGA chips it's possible to have text output in the A000 segment. With an appropriate DOS TSR it might then be ok to display text via DOS/BIOS - but I doubt that such an uncommon - and dangerous - config is the case here.

I've dumped both the ROM chips on the graphics card and compared the dump to all BIOS dumps of ET4000 cards available on theretroweb.com.
I found one dump that was almost identical: https://theretroweb.com/expansioncards/s/soun … inc-et4000-adap (Only date and a couple bytes are different at offset 0x786D).

I tried this found rom file in the graphics card (with the 3 emm386 settings), no difference.

I am mainly looking at how picky this NC program is about the dos memory map.

I'd like to steer you toward a configuration with the least 'difficulty inducing' features.

The ET4000 is a *great* card for any collection, but what makes it great for a retro enthusiast may be playing against you here.

From the sounds of it, your software *WANTS* to write on RAM in the monochrome display buffer area, but your hardware hates that.

The ET4000's register compatibility with MDA and CGA makes it a GREAT card for vintage gaming, as does it's very fast framebuffer access speeds... but it might not be a good fit here, if the onboard vga can be used, has a smaller ROM, and has no cares about B000 being used for UMB.

I'd like you to investigate those prospects.

Please humor me, in getting the MSD Memory page from an F5 boot, using the integrated VGA.

debnie wrote on Today, 17:58:

I tried (one of both gave a warning that there is option rom or ram within page frame): *B800-BFFF *B000-B7FF Both resulted in […]
Show full quote

I tried (one of both gave a warning that there is option rom or ram within page frame):
*B800-BFFF
*B000-B7FF
Both resulted in the ASCII colorful mess.

I'd say you shouldn't ignore this warning. It means that the 64 kB at segment address 0xE000 ( which is your page frame ) aren't really free to use. If this msg appears only after the RAM=B000-BFFF option has been modified - this may be explicable that without that modification there's no text video output possible at all...

wierd_w wrote on Today, 19:00:

...
Please humor me, in getting the MSD Memory page from an F5 boot, using the integrated VGA.

I will do this tomorrow, does it make sense to do this for other ISA graphic cards (I have 3 or so - all different types)?

Baron von Riedesel wrote on Today, 19:17:

debnie wrote on Today, 17:58:

I tried (one of both gave a warning that there is option rom or ram within page frame): *B800-BFFF *B000-B7FF Both resulted in […]
Show full quote

I tried (one of both gave a warning that there is option rom or ram within page frame):
*B800-BFFF
*B000-B7FF
Both resulted in the ASCII colorful mess.

I'd say you shouldn't ignore this warning. It means that the 64 kB at segment address 0xE000 ( which is your page frame ) aren't really free to use. If this msg appears only after the RAM=B000-BFFF option has been modified - this may be explicable that without that modification there's no text video output possible at all...

The OP provided an MSD memory page output for this system. MSD very clearly shows that there is 'something' in memory there.

If not for the program's hardcoded silliness, I'd strongly advise not putting the pageframe there.

'The thing that changed' is the SBC itself. (The old one got smoked). It is possible the replacement is a newer revision of the SBC, and this newer revision uses the E000 segment for something.

It's also possible that this is just ESCD data that should/could get relocated, and the system will be just fine. (It IS kinda big though. More than 32k in size, if MSD is to believed. Maybe a realmode USB keyboard/mouse driver, or a NIC rom?)

Getting a dump of the E000 region for analysis might be ok to ask for, but I dont want to stress the OP.

Given that the NC software is not explicitly tied to this SBC (it can run in dosbox-x), it may be advisable to hunt for a different ISA backplane SBC with a cleaner memory map. (I understand that some of them publish this in their manuals)

Re: size comparisons of other VGA cards

Yes, if you would. If you DO have one that ends at C7FF, we should try it.

Baron von Riedesel wrote on Today, 19:17:

...If this msg appears only after the RAM=B000-BFFF option has been modified - this may be explicable that without that modification there's no text video output possible at all...

I understand that the frame doesn't seem available, but I don't understand the explanation.

For the moment I don't have access to the hardware but I tested both ranges in D0sbox-X and get following results:
*RAM=B800-BFFF: The text from autoexec.bat is gone, GUI starts but is missing all text and images.
*RAM=B000-B7FF: I can see text from autoexec.bat, GUI starts but is completely wrong.
*RAM=B000-BFFF: The text from autoexec.bat is gone but GUI works completely.