Hi these are my test cases:
SEND.COM (size 24 bytes): sends 2 letters “HI” to COM1 using INT 14-1
RECEIVE.COM (size 18 bytes): receive characters from COM1 using INT 14-2 until AH is not zero
RECEIVE1.COM (size 13 bytes): receive one character from COM1 using INT 14-2
Step by step instructions to whom interested
:
-Download com0com to make virtual serial port pairs from
sourceforge.net/projects/com0com/files/com0com/3.0.0.0/com0com-3.0.0.0-i386-and-x64-signed.zip/download ( home page
com0com.sourceforge.net . As stated there “Alternatively, you can use Virtual Serial Port Driver by Eltima Software” )
-Run the proper setup program i.e. Setup_com0com_v3.0.0.0_W7_x64_signed.exe, choose the option COM#<->COM#
-On Windows Device Manager look for entries under com0com – serial port emulators and check if it has a warning sign, right click on it and choose “Update Driver..” , the process should go automatically and warning sign disappear.
-Look for port numbers* assigned under Ports (COM and LPT) or the com0com management app.
-Download vDos
www.vdos.info/download.html - Installation program 2018.05.01 and run vDosSetup.exe
-Put SEND.COM RECEIVE.COM RECEIVE1.COM on vDos folder
-Omit running DPTEST autoexec.txt (rem CALL DPTEST\STARTDP)
-On this test we would run 2 vDos Windows and communicate each other thru the virtual comm pair, having one COM port attached to each vDos, but for simplicity each of them would see the port as COM1 regardless which port number was assigned on Windows: so, although this could be done in several different ways, simply edit config.txt, supposing the pair was COM5<->COM6, adding the line COM1 = “COM5”: at the end of the file and run vDos.exe (let call this instance vDos1)
-Then modify config.txt again changing that line for COM1 = “COM6”: and run another vDos.exe (let call this instance vDos2)
(So both instances sees a COM1 port and have direct access to the files SEND.COM RECEIVE.COM RECEIVE1.COM)
-On vDos1 run SEND.COM (this sends 2 letters to COM1 – no screen output)
-On vDos2 run RECEIVE.COM, it should lock if it cannot detect the end of the characters sent by vDos1 (otherwise it may return to the command line) – no screen output. If it hungs, close that window and reopen vDos.exe again.
-On vDos1 run SEND.COM (this sends 2 letters to COM1 – no screen output)
-On vDos2 run RECEIVE1.COM, this receive 1 letter “H” from COM1 – no screen output (just inform AH thru errorlevel exit code)
-On vDos2 run RECEIVE1.COM again, this receive 1 letter “I” from COM1 – no screen output
-On vDos2 run RECEIVE1.COM again, this try to receive another letter from COM1 – no screen output, but as there is no more characters to receive it would either:
a-Lock until sender sends a new character
b-Terminate normally as it would receive a character (AH=0 , AL unchanged) – fake
c-Terminate normally informing AH = 80 (as expected for INT 14-2 when no more characters to receive, ideal situation but I was not able to verify on several different test)
If it was (a):
-On vDos1 run SEND.COM (this sends 2 letters to COM1 – no screen output), checking vDos should automatically continue and terminate RECEIVE1 normally (it receives the “H” from “HI”)
-On vDos2 run RECEIVE1.COM again, this receive 1 letter “I” from COM1 – no screen output
-On vDos2 run RECEIVE1.COM again, this try to receive another letter from COM1 – no screen output, but as there is no more characters to receive it should lock again (until running again SEND.COM)
If it was (b) or (c), is possible to see dos exit code - errorlevel?
-Alternatively copy to vDos folder a DEBUG.EXE from old Microsoft o.s. files appropriate for vDos or DEBUG.COM / DEBUGX.COM from
thestarman.pcministry.com/asm/debug/debug.htm quote “Enhanced DEBUG (current version, since DEC 2014, is 1.30b).”:
sites.google.com/site/pcdosretro/enhdebug/DEBUGX.ZIP?attredirects=0-Run DEBUG and issue following commands:
-nreceive.com (indicate name of the file)
-l (load file)
-u (list instructions)
-p (run next instruction step by step, monitoring register’s contents)
-p
…
-p (until at least INT 14 is called to look for result on AH)
That’s is. That simplified test case represents exactly what happens also to my test app in Clarion 3 which would need an environment setup to test but please tell me if you need to look into that anyway. The same behavior is seen on both programs connecting with virtual serial ports and (option a – lock) and on both programs connecting through a usb to serial adaptor to a real device (option b – fake characters reception – no 80 in AH).
Listings:
-nsend.com
-l
-u
06B6:0100 BA0000 MOV DX,0000
06B6:0103 B401 MOV AH,01
06B6:0105 B048 MOV AL,48
06B6:0107 CD14 INT 14
06B6:0109 BA0000 MOV DX,0000
06B6:010C B401 MOV AH,01
06B6:010E B049 MOV AL,49
06B6:0110 CD14 INT 14
06B6:0112 88E0 MOV AL,AH
06B6:0114 B44C MOV AH,4C
06B6:0116 CD21 INT 21
...
-nreceive.com
-l
-u
06B7:0100 BA0000 MOV DX,0000
06B7:0103 B402 MOV AH,02
06B7:0105 CD14 INT 14
06B7:0107 80FC00 CMP AH,00
06B7:010A 74F4 JZ 0100
06B7:010C 88E0 MOV AL,AH
06B7:010E B44C MOV AH,4C
06B7:0110 CD21 INT 21
...
-nreceive1.com
-l
-u
06B7:0100 BA0000 MOV DX,0000
06B7:0103 B402 MOV AH,02
06B7:0105 CD14 INT 14
06B7:0107 88E0 MOV AL,AH
06B7:0109 B44C MOV AH,4C
06B7:010B CD21 INT 21
...
Attachments:RECEIVE.COM (18 B)
RECEIVE1.COM (13 B)
SEND.COM (24 B)