Communicate with Serial COM Port
Nov 23, 2018 18:24:21 GMT 1
Post by fnavarro on Nov 23, 2018 18:24:21 GMT 1
Jos,
I come back for the issue with communicating with the serial ports which I had started a topic in the sourceforge forum:
sourceforge.net/p/vdos/discussion/general/thread/fc2cf47c/
I apologize for not having returned before. Other jobs prevented me from continuing this. Now I would like to find a solution if possible. I think it could benefit many.
I was able to determine that the programs and libraries mentioned actually used reception driven by interruptions. I also discovered that this library has additional support for INT 14, but there are also problems to communicate with those functions. So I developed a library that implements the communication with IN / OUT and another one with INT 14.
The following drawbacks have arisen:
IN / OUT method
OUT correctly sends the characters. IN receives the characters from the response but I cannot know when to stop when there are no more characters to read, and successive INs continue to receive characters repeated cyclically. Basically I am not able to implement the logic of asking at first if there are characters available to receive, since doing IN to the Line Status Register (BASE + 5) to check if there are characters to be received I always get the FF hex value and not the bits that are expected in LSR.
INT 14 method
As with IN and OUT I also managed to implement the functions to initialize the port (function 0) and send characters (fn.1), and also as in IN & OUT I cannot obtain valid information with Get Port Status (fn 3) to know if there are response characters, and finally, this changed in the 2018 version: in the 2017 one, unlike with IN & OUT I cannot get the response by invoking Read Character from port (fn 2), the AL record where the characters should return remains unchanged, and in the 2018.05.01 version it works as expected like IN, only I have the problem mentioned above that I cannot determine the end of the response, because another INT 14.2 past the end of the response it continues fetching characters from the beginning.
I understand that the above is not dependent on the programming language I use. I have reduced the examples to basic commands executed with DEBUG.EXE and the same result is obtained, so, unless I am missing something important, I think the limitations found could be affecting all vDos users.
I can send examples if you like, although aiming for simplification, it can be summarized as follows:
Limitations to the implementation of IN / OUT:
There it can be seen values obtained from the line and modem status registers always respond FF regardless of the actual status thereof. It doesn’t matter if port exists or not either. Prevents knowing when there are no more characters to receive.
Limitations to the implementation of INT 14:
There it can be seen values obtained from the line and modem status registers always respond 0010 regardless of the actual status thereof. It doesn’t matter if port exists or not either. Prevents knowing when there are no more characters to receive.
I must be missing something. What is the intended way for retrieving responses?
Thank you so much!
Federico
I come back for the issue with communicating with the serial ports which I had started a topic in the sourceforge forum:
sourceforge.net/p/vdos/discussion/general/thread/fc2cf47c/
I apologize for not having returned before. Other jobs prevented me from continuing this. Now I would like to find a solution if possible. I think it could benefit many.
I was able to determine that the programs and libraries mentioned actually used reception driven by interruptions. I also discovered that this library has additional support for INT 14, but there are also problems to communicate with those functions. So I developed a library that implements the communication with IN / OUT and another one with INT 14.
The following drawbacks have arisen:
IN / OUT method
OUT correctly sends the characters. IN receives the characters from the response but I cannot know when to stop when there are no more characters to read, and successive INs continue to receive characters repeated cyclically. Basically I am not able to implement the logic of asking at first if there are characters available to receive, since doing IN to the Line Status Register (BASE + 5) to check if there are characters to be received I always get the FF hex value and not the bits that are expected in LSR.
INT 14 method
As with IN and OUT I also managed to implement the functions to initialize the port (function 0) and send characters (fn.1), and also as in IN & OUT I cannot obtain valid information with Get Port Status (fn 3) to know if there are response characters, and finally, this changed in the 2018 version: in the 2017 one, unlike with IN & OUT I cannot get the response by invoking Read Character from port (fn 2), the AL record where the characters should return remains unchanged, and in the 2018.05.01 version it works as expected like IN, only I have the problem mentioned above that I cannot determine the end of the response, because another INT 14.2 past the end of the response it continues fetching characters from the beginning.
I understand that the above is not dependent on the programming language I use. I have reduced the examples to basic commands executed with DEBUG.EXE and the same result is obtained, so, unless I am missing something important, I think the limitations found could be affecting all vDos users.
I can send examples if you like, although aiming for simplification, it can be summarized as follows:
Limitations to the implementation of IN / OUT:
>DEBUG.EXE
-i 3fd
FF
-i 3fb
FF
-q
There it can be seen values obtained from the line and modem status registers always respond FF regardless of the actual status thereof. It doesn’t matter if port exists or not either. Prevents knowing when there are no more characters to receive.
Limitations to the implementation of INT 14:
>DEBUG.EXE
-a
15A4:0100 mov ah,3
15A4:0102 mov dx,0
15A4:0105 int 14
15A4:0107
-p
AX=0300 BX=0000 CX=0000 DX=0000 SP=00FD BP=0000 SI=0000 DI=0000
DS=15A4 ES=15A4 SS=15A4 CS=15A4 IP=0102 NV UP EI PL NZ NA PO NC
15A4:0102 BA0000 MOV DX,0000
-p
AX=0300 BX=0000 CX=0000 DX=0000 …
15A4:0105 CD14 INT 14
-p
AX=0010 …
-q
There it can be seen values obtained from the line and modem status registers always respond 0010 regardless of the actual status thereof. It doesn’t matter if port exists or not either. Prevents knowing when there are no more characters to receive.
I must be missing something. What is the intended way for retrieving responses?
Thank you so much!
Federico