|
Post by fnavarro on Mar 11, 2023 0:16:44 GMT 1
Yes I understand, please send it to me
Logging could be usesful to discard the other elements in play (com0com, realterm) but I didn't see the same effect with the Windows version of my program using also them. I will monitor if it happens again with that int86 change and notice here if does.
|
|
|
Post by fnavarro on Mar 11, 2023 16:10:51 GMT 1
Hi Jos, thanks INT 14 is working as before!
I saw the logging option with serial output, I reverted to using _int86x to have more chances the problem poping again, an make a shortcut to this vdos version with /log to use it as default, but as far I couldn't reproduce the problem.
I found other issues but not related to serial com so those I will comment in another thread.
|
|
|
Post by fnavarro on Apr 22, 2023 1:06:02 GMT 1
Hi Jos, This is just to mention I finally discovered the second problem that happens very rarely. It did happen again today and could track down the problem. vDos log showed the byte was sending correctly. I enabled traces on com0com and it did noted there the problem
2023/04/21 20:14:24.814 COM2/FP FdoPortWrite WRITE 1: 81 * . *, status=SUCCESS
2023/04/21 20:14:24.814 COM5/FP c0cIoControl WAIT_ON_MASK [RXCHAR|CTS|DSR|RLSD|BREAK|ERR|RING]
2023/04/21 20:14:24.814 COM5/FP c0cRead READ length=256
2023/04/21 20:14:24.814 COM5/FP FdoPortRead READ 1: 01 * . *, status=SUCCESS
There it can be seen how 81 is changed to 01, dropping the eighth bit. I was starting vDos with a shortcut not doing MODE COM first, and some times the port starts with a config of 1200 baud, 7 bits, parity Even, etc. So the solution is to force using MODE or another workaround with com0com is setting the alldatabits option on the port that vDos uses: eg issuing on com0com console: change cnca0 alldatabits=yes
AllDataBits={yes|no} - enable/disable all data bits transfer disregard
data bits setting (disabled by default)
(needs reloading drives or reboot)
Regards,
Federico
|
|
|
Post by fnavarro on May 16, 2023 1:08:52 GMT 1
Hi Jos,
Perhaps I should start a new thread.
I've just found a wrong behavior receiving data in vDos.
There is a problem receiving the ASCII 255 0xff character.
The problem seems to be present in previous versions too. Tested 2019, 2021 and the current 2023.
Both INT 14,2 Receive caracter and INT 13,3 Get serial port status are affected.
It can be demonstrated with two vDos sessions and com0com or with vDos communicating to a serial port (tested with a usb serial port).
Sending INT 14,1 works with that character, only receiving misbehave.
Federico
|
|
|
Post by Jos on May 16, 2023 7:05:03 GMT 1
vDos uses the Windows ReadFile() function to read bytes from a serial port. The DSR status bit is also determined by that.
Since ReadFile() then removes the eventual pending byte, that is saved in a signed integer to be used later on. -1 indicating no byte was previously saved. The read byte of ReadFile() was however also interpreted as signed. Causing 0xff to be saved as -1. I changed it to an unsigned byte.
Didn’t test this fix, will send you a corrected vDos.exe.
Jos
|
|
|
Post by fnavarro on May 16, 2023 15:14:50 GMT 1
Thanks Jos, with the fix, 0xff is correctly received
|
|