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.