DirectSerial patch

[LordSnark]

Ok I finally got it to log. All it says is:

"COM1: BASE 3f8, IRQ 4"


thats it.

[h-a-l-9000]

You sure you chose the right COM port in the application? I get at least a failed attempt in the log here. The default in the application seemed to be COM2.

[LordSnark]

Ok, sorry for the gap, I found an error I made in the config file. So now that its fixed I get a better result from the log file. Of course it still doesn't work.

Here is the log file:

COM1: BASE 3f8, IRQ 4

1.000 Port type directserial realport com1
1.000 RTS off.
1.000 DTR off.
1.000 CTS off.
1.000 msr interrupt on.
1.000 DSR off.
1.000 RI off.
1.000 CD off.
1.000 msr interrupt off.
23658.199 write 0x80 to LCR.
23658.199 write 0xc to THR.
23658.200 write 0x0 to IER.
23658.201 write 0x7 to LCR.
23658.201 write 0x0 to IER.
23658.202 read 0x1 from ISR.
23658.203 read 0x60 from LSR.
23658.203 read 0x0 from MSR.
23658.241 write 0x3 to MCR.
23658.241 RTS on.
23658.241 DTR on.
23658.241 CTS on.
23658.241 msr interrupt on.
23658.241 msr interrupt off.
23659.000 DSR on.
23659.000 msr interrupt on.
23659.000 msr interrupt off.
23659.000 tx 0x50 (P)
23659.000 read 0x0 from LSR.
23659.000 read 0x30 from MSR.
23659.143 tx interrupt on.
23660.000 rx 0x00 (0)
23660.000 rx interrupt on.
23660.000 break received
23660.000 error interrupt on.
23672.931 write 0x3 to MCR.
23672.931 tx interrupt off.
23672.931 tx 0x52 (R)
23672.932 error interrupt off.
23672.932 read 0x11 from LSR.
23672.932 read 0x30 from MSR.
23673.074 tx interrupt on.
23727.841 write 0x3 to MCR.
23727.841 tx interrupt off.
23727.841 tx 0x4f (O)
23727.841 read 0x1 from LSR.
23727.841 read 0x30 from MSR.
23727.984 tx interrupt on.
23782.790 write 0x3 to MCR.
23782.790 tx interrupt off.
23782.790 tx 0x47 (G)
23782.790 read 0x1 from LSR.
23782.790 read 0x30 from MSR.
23782.933 tx interrupt on.
23837.699 write 0x3 to MCR.
23837.699 tx interrupt off.
23837.699 tx 0x52 (R)
23837.699 read 0x1 from LSR.
23837.699 read 0x30 from MSR.
23837.842 tx interrupt on.
23892.641 write 0x3 to MCR.
23892.641 tx interrupt off.
23892.641 tx 0x41 (A)
23892.641 read 0x1 from LSR.
23892.641 read 0x30 from MSR.
23892.784 tx interrupt on.
23947.549 write 0x3 to MCR.
23947.549 tx interrupt off.
23947.549 tx 0x4d (M)
23947.549 read 0x1 from LSR.
23947.549 read 0x30 from MSR.
23947.693 tx interrupt on.
24002.489 write 0x3 to MCR.
24002.489 rx interrupt off.
24002.489 write 0x1 to MCR.
24002.489 RTS off.
24002.490 read 0x60 from LSR.
24002.519 write 0x3 to MCR.
24002.519 RTS on.
25003.000 write 0x1 to MCR.
25003.000 RTS off.
25003.000 read 0x60 from LSR.
25003.000 CTS off.
25003.000 msr interrupt on.


Thanks.

-Derrick

[h-a-l-9000]

Your device doesn't respond so good to the communication attempt... can't tell why.

[LordSnark]

Hmmm, ok well now I know that its on my side.

Thanks for all your help.

-Derrick

[LordSnark]

Ok I tried one last time, this time I get the repeating overrun error.


Here is the log file.

[h-a-l-9000]

Almost looks like the baud rate is wrong.

[LordSnark]

like the radio is transmitting too fast?

[Merrickk]

I have a program written in Turbo pascal that I am trying to get working. The program interfaces via serial port to a programming coil that uses magnetic communication to interface with a device that is a hermetically sealed housing. Anyway... I'm told that the app will not work above 33mhz so I am attempting to use DosBox to solve this problem. I feel as if I am also having serial port issues. I have been reading up on this for about 5 hours now, and have tried about everything that has been listed. Attached is my log from the serial debug version of HAL's build. I would appriciate any help you all can give me on this.

Thanks!!!

[h-a-l-9000]

Bugfix attached (may it help or not).
Build: http://home.arcor.de/h-a-l-9000/test/dosbox_int14_b.zip

[h-a-l-9000]

Patch for serial to use multiprop stuff. I hope this is what it was supposed to be . No user-recognizable changes.

[jcoppens]

Guys,

A friend of mine has this way old gas flow sensor, which is fed by the RS-232 signals themselves. I tried to run the corresponding program (DOS, of course), in DOSemu without much success.

Someone on the DOSemu list prompted me to use DOSbox. The results were better, but not convincing yet. I started to suspect drive current problems (those modern CMOS drivers might not be able to feed the sensors), so I put an amplifier on the lines that matter (TXD and DTR in this case). No difference.

DOSemu basically doesn't communicate at all, DOSbox gets the data in just a couple of seconds, needing several retries to get it right. Original DOS (or FreeDOS) do the same communication instantaneously - no retry at all! The program won't work at all under Windows XP's DOS (surprise).

To start/feed the sensor, the program sends first a series of 0x0F's, then starts the protocol. Still, there is some (probably timing) issue that makes things fail.

Can anyone suggest some steps to debug this?

Thanks,
John

[h-a-l-9000]

If you haven't already found it:
On my homepage the 'megabuild' has serial debugging and UART FIFO implementation. It can create logs from serial activity. Configure it like this:

serial1=directserial realport:<yourport> dbgall

It will add the logs in the subdirectory 'capture'.

I'm interested in finding the exact issue, even if it can't be fixed. However I don't have the hadware and thus can't do it myself.

[jcoppens]

On my homepage the 'megabuild' has serial debugging and UART FIFO implementation. It can create logs from serial activity.

Great! I've downloaded the megabuild (and to be sure the other version with seriallog included), I'll publish the results later - an extra complication is that the machine to test it on is at 30 km from here.

[hm]

Hi Hal,

Does it contain the VESA 1600x1200/256 also?

Regards,

Hugo

[h-a-l-9000]

> Does it contain the VESA 1600x1200/256 also?

No, not yet. Can take a few more days.

[h-a-l-9000]

I've finally finished the Linux-specific part in the serial FIFO patch.

http://home.arcor.de/h-a-l-9000/test/do ... rial15.zip

In the download the patch file, a Windows binary and a Ubuntu32 Linux binary are included. (I do not know how useful the latter on another system is). The builds only include the serial15 patch.

Compatibility and regression testing welcome since a part of the non-FIFO mode was changed too in the process of adding the FIFO part.

[lightmaster]

thank you hal! :thumbsup:

[davek]

I hope I will not upset the network gods (and goddesses) asking this question here with my non-existent network skills.

I am a user of CAPing software at work. This, conversationally, makes G-code programs for machine tools to run. The CAP software, of course, is an older dos package, is a gazillion dollars to update, and won't run under XP. And of course, they need to run all computers on XP now.

Our IS department got it running with Dosbox and the megabuild. Needed the megabuild to have the software access a dongle. It runs surprisingly well. with one fatal problem.

They are running the software from our network, and say they must. It loads up quickly, runs OK, but seems to have some problems with some access.

When you are paging through screens of program filenames, there is a distinct lag when paging down. The really big problem though, is that when you start a new program there is a lockup of a minute or so. When it is starting a new file it takes forever. If you start that new file in a directory with just a few filenames (ridiculously few) it does OK.

I've been trying to separate our thousands of files into sub, and sub-sub-sub directories, but it is just too cumbersome. If there is any way you all could help me help our network guys get this going, I would greatly appreciate it. They are about to give up and the next step is third-party software which. I feel, would be inferior.

Save me from genera-CAP!

[MiniMax]

An user here has run into a similar issue, with trillions of CAD-drawings stored on a file server. He is trying to isolate the piece of code that makes accessing networked drives slow.

Found the thread:
viewtopic.php?t=19561