h-a-l-9000 wrote:

Another update:

- diff for current cvs
- modem update

Thanks hal9000. I appreciate the time you have put in on this more than you know.

Modem now works for Tyrian (and Radix and Tzone).
But where to find an opponent 😁

coooool

Hey hal9000,

I am trying to get your serial port mod to work with orz's realtime clock mod (see hello AND performance).

I started with a successful version of orz's realtime clock mod and applied the changes to allow your serial port mod to work. I could not, however, get the project to compile. There were too many errors, undefined symbols, and code changes that I was unable to follow.

Instead, I took a successfully compiled version of your serial port mod and applied the changes specified in orz's realtime clock mod. His patch ran smoothly on your modified code, and I was able to compile the results into a new executable. Unfortunately, this executable fails to access the serial port.

Upon inspection of the code using WinMerge (http://winmerge.org/), one of the differences that I have noticed is in the placement of "extern Bitu cycle_count", which it appears that orz's version uses to cycle the CPU's clock speed.

Is it possible that your version of DOSBox initializes the serial port based on the cycle_count variable? If this variable gets changed (i.e. the CPU clock cycle is increased or decreased), would something in the setup of your serial port routines report a failure? Any idea how to work around such a glitch? (I assume you are immersed in this code *much* more than I have been) If it helps, my code is attached.

Regards,

To further enhance your debugging experience, I have noticed that this version of DOSBox (dosbox_serialRT.exe) works when cycles=36000 in the [CPU] section of dosbox.conf but not when cycles>=50000. Interesting...

I'll investigate further into this tomorrow. Have a good evening, everyone!

You are not using my latest diff here...
Since you get RX overrun (as well as me on my old test pc, it means more data came than the emulated application was able to fetch from the serial port), have you tried increasing Dosbox' cycles?
I also see you are using the fastest baudrate, you could try a slower one if possible to give the emulator more time.
Looks like I have to add some buffer...

I don't use cycle_count at all.

Oh, too fast is not good neither..
At 50000 you probably have 100% CPU usage. Set cycles lower to stay under 100%.

Got these errors:

1Serial port: line error.
2Serial port: line error.
3Serial port at 0x3f8: RX Overrun!
4Serial port at 0x3f8: Write to reserved register, value 0x0, register 2
5Serial port: line error.

Software is a kind of datalogger which requires authentication/adapter dongle connected to COM1. Baudrate is 9600 and can't change it. Software also requires slowing down in real DOS @ Pentium133.
It would be great to get this working.
Thanks.

musta myy wrote:

Got these errors: […]
Show full quote

Got these errors:

Copy code to clipboard

1Serial port: line error.
2Serial port: line error.
3Serial port at 0x3f8: RX Overrun!
4Serial port at 0x3f8: Write to reserved register, value 0x0, register 2
5Serial port: line error.

Software is a kind of datalogger which requires authentication/adapter dongle connected to COM1. Baudrate is 9600 and can't change it. Software also requires slowing down in real DOS @ Pentium133.
It would be great to get this working.
Thanks.

I get those same RX Overrun errors, but they don't seem to hurt anything.

To get serial communication to work for our software dongle, I had to set the core=dynamic, cycles=33000 (actually, anything up to 33000 cycles works for my situation), and be sure to set enabled=false for each COM port your PC does not have (my DELL laptop only has COM1). These values are in the dosbox.conf file. If you don't have a dosbox.conf file, you can generate one while running DOSBox by entering "C:\>config -writeconf dosbox.conf" at the prompt. It will write the file to the same directory you are running the DOSBox executable from.

Hope this helps!

Hello there. I am totally blind and in the ole dos days, I used some special hardware that attached to the serial port, com2.
I would really like to use this capability under dos box, but I dont know what to do because it won't work. I've downloaded the latest dosbox patch, made the necessary changes to the dosbox.conf file but I'm still not getting anywhere. I keep getting the error: ax6033 dx1
unhandled int 14 call 1
Can anyone help?
😢

It's missing BIOS support. What you could try from here:
Download the BNU 1.70 FOSSIL driver (http://www.pcmicro.com/bnu/),
extract it, make the files availible in Dosbox, and run BNU.COM. It should say
that there is at least one device availible. Now run your program.
Hopefully the FOSSIL driver implements the standard INT14h functions.

first, the good news
if I start up a command prompt and load the bnu.com driver, I am able to use my speech hardware.
Now the bad news, if I start up dosbox and run the bnu program then load the speech software, the software freezes and I am not able to do anything except click on the x button to close down dosbox.

so it looks like I'll never be able to make use of dos box to play my old classics. really frustrating

well the serial stuff is still being worked on.
So don't give up hope easely. maybe it's possible to share the application with hal9000 to see if he can figure out what is wrong with it.

@whocrazy: You could also try other drivers like http://www.digsys.se/adf.html, and my new version (which still has no BIOS support). Maybe your application can be configured to use the UART directly instead of INT14h BIOS?

About the new "version":

Configuration:
The configuration can be changed on-line within Dosbox. At the prompt, type 'serial1 modem', if you want a modem on com1. For a real serial port, type 'serial1 directserial realport:com1'. 4 serial ports are supported.
In the config file, it has moved to the BIOS section. I had to rename the entries from comX to serialX because of a config change issue.

Directserial:
- line error messages more detailed
- more tolerant handling of received data, so a slowly running application has a bigger chance to get it before RX overflow occurs

Modem:
- accepts connection only if a modem-aware program is running (DTR on)
- tested with the following terminal software:
Telix
Bananacom
SBBS with both MS Telnet and terminal running in Dosbox as client
BNU FOSSIL driver (not everything tested)

- tested with the following games:
Tyrian
Radix (Demo)
C&C 1
Warcraft
Warcraft2
Descent
Descent2
Terminal Velocity
TZone
F-29 Retaliator

- Does not work for:
Moo2 (1.3 patch, lower version even less) - It can connect, but shows me clock mouse pointer after I chose my color, and nothing more happens.

I've also been working on the IPX emulation, and have been able to make some more games work. But maybe at a high price: It uses up a hardware interrupt, as I can't think of any other way to make the protected mode runtime switch to the right context for event notification.
- Additional working games (always only 2 players tried):
Tyrian
Radix
Moo2
Warcraft

- still not working:
C&C1 (Multiplayer game can be started, but immediately says "Games are out of sync" and also does some illegal reads, which are caused by a zero pointer. It does not crash anymore, though.

These games are still working despite of me messing with IPX:
Warcraft2
Terminal Velocity
Descent (I think)
Descent2

Testing with more than 2 players and other would be required.

How about linux support? I could write up a basic version, and assist in testing. Lacking a serial port, I couldn't test/support it, however.

Of course, further compatibility would be great.
I have been looking for multiplatform libraries, but found none with all the required functions. It's actually rather difficult to find them at all.
We can do it on our own, too.
I'd probably find a way to test it with real serial ports (maybe Dosbox works on Knoppix, or I put Linux on a spare harddisk..).

Hello there. the link:
http://www.digsys.se/adf.html
doesn't work, it says not found

Hi. when running your compiled version of dos box I get the error this application has failed to start because the file msvcp71d.dll was not found. Where the hell can I get that file?

Sounds like that binary was compiled with Microsoft Visual C++ and the person forgot to include the MSVC++ DLLs with it. You might be able to get them from Microsoft's web site.