One of the reasons Dosbox is intended for games only and not for programs that are "mission critical". There is a patch for dosbox that might make it work reliable but you'd need a special build for that...

Ok... can you point me to a site where I could get that? 😀

I even tried PC-BASIC 3.23, but that didn't work, either. It "times out" when trying to access the COM1 port, just like it does in DOSBOX.

Again, Dosbox is not suited for this task.

I don't know whether there is a build with just this patch around, there are builds that have a multitude of patches applied, which might not help in the way you want to use Dosbox

Bummer. Oh well, thanks.

What about trying QBasic64?

FYI, midnight rollover is implemented in SVN.

If QBASIC will run this program, that could make it possible... but this is a 32 bit system.

What is "SVN"? 😀

http://www.qb64.net/

DOSBox SVN Builds

Well.... unfortunately, QB64 doesn't support the important COM(x) port functions that I need! Sigh. 🙁

SO FAR, the issue is either the serial works or the clock works. They are thus far mutually exclusive, due to limitations in the BASIC emulation software I've tried! Sigh.... 🙁

The thought of having to re-write the GWBASIC software in some other, very different language, is DAUNTING!

A rewrite might be your best solution. How big is the program? I don't know what other languages you know. Here is some advice for converting from GWBasic to VB.NET:

https://social.msdn.microsoft.com/Forums/en-u … rum=Vsexpressvb

But I suspect that it might be quicker to rewrite from scratch.

And how does SVN of Dosbox cope?

I think I found a solution! With some clever use of loops in a BAT file, I can make the program drop to DOS at midnight, where the looping batch re-launches DOSBOX, thus re-syncing the system clock.

I will leave it running for a few days this way, and see how well it holds up. 😀

Re-writing the code is pretty much out of my realm... so far, I THINK this solution should work.

I will limit my future replies to THIS thread, only. 😀

In case anyone is curious... that did the trick! 😀 Even if the clock drifts a few seconds by the end of the day, that's not too serious. The midnight re-sync has been working all week.

The looping BAT files also have the added advantage of re-launching the program, if it's accidentally closed. (Closing the DOSBOX "status" window breaks the loop, which is good.)

Thanks for the suggestions! 😀 The SVN version of DOSBOX also seems to have been an important factor to getting this working properly. 😀

Just for the sake of those that have followed this thread, the looping BAT files did, indeed, do the trick. It's been running flawlessly for months, now. 😀 (Not counting the fact that Windows, itself, gets stupid and needs a reboot about once a month.)

id see if there is no simple ntp like solution for dos maybe? - just less compli

That's cool that it's working, but your solution seems kind of convoluted... how about using FreeBasic? It supports COM ports. Edit: Just use the #lang "fblite" command at the beginning, and your QB code should run with minimal modifications.

Another geek (MUCH more advanced than I!) whipped up a nice little EXE file that syncs the DOS clock to the Windows system clock. It's not NTP, itself, but Windows calls an NTP to sync itself so this utility gets accurate time.

One of the BAT files calls the EXE and exits back to the GWBASIC program. I use that file in another application where I needed to keep the clock in a different BASIC program in sync with Windows. (It has no need of COM ports, so it runs in a Windows DOS box.)

I'm using GWBASIC because the manufacturer created the original logging program in it, and I am fairly familiar with this language, so I just kept with it. 😀

Thanks folks! 😀