Well, that is quite a story, probably better to communicate directly: jas@vdos.info (the “a” should be an ”o”). Problematic with serial communications in vDos are programs that install and rely on their interrupt driven routines. You can check if a program does so by starting vDos with the /log option (“vLog.exe” /log). If the vDos.log shows “Int 0B => XXXX:XXXX” or “Int 0C => XXXX:XXXX”, it indeed implements these routines, that are then never called in vDos. If those entries are missing, the program would directly poll the serial port(s). Though then the serial port has to be initialized correctly outside and before vDos starts, with MODE COMx (at the Windows command prompt). PRUF.EXE working or not, doesn’t mean the actual program would likewise.

Hola Cristian, perdon por la falta de detalles. Impresora: Emulador Fiscal (www.impresoras-fiscales.com.ar)Epson TMU220AF/AF II Puerto COM: ELTIMA Virtual Serial Port (COM2) Windows XP SP3. Emulador fiscal crack email Date added:. Faster this enzyme Hardkernel advanced the ODROID-C2 as a 64-bit ARM meet board that would happen shipping in March. Alguien sabe como probar un modulo fiscal? Les comento yo tengo un modulo para imprimir en Hasar y Epson como puedo hacer para probarlo sin tener la Impresora?

The one could use interrupt driven communications, while the other doesn’t. Interrupt driven communications are somewhat specific to dedicated communication programs, supporting high transfer rates. Not to be expected with a program, occasionally communicating with a Fiscal Printer at a mere 9,600 bps. Jos, thanks for answering and for your support Unfortunately in many cases software is provided 'as is', or even own developed software may rely on 3rd party communications library, binary closed source without support, and in those cases vDos users are quite unable to workaround that situation.

May Interrupt driven communications being supported on vDos on the near future? Does it depend on the how many people would benefit from it or it is definitely out of scope? I tried vDos /log.

PRUF indeed shows int B, however my program does not. But both cannot communicate. I can send you details by private mail if you prefer. I dig a bit more and debugged my program running step by step disassembled instructions and monitoring registers, what I found it fails in the first try to open port (not even at the stage of setting baud rate or handshaking lines or trying to sending / receiving data). Particularly there are some IN / OUT instruction to the line control register of serial port COM2 (2FB). (dx=02FB) in al, [dx] --> al is set to FF (whereas on a working PC it is set to 30), so on the following instructions it will report that the port cannot be opened. Does this helps?

Metal gear solid 3 download. Is there anything else I could try? Regards, Federico FWIW to other who may be interested, a reference to those registers with a fast google search: (i have not done those test, it is just for reference). Serial communications in vDos are quite basic; BIOS 14h functions 1-3 are more or less supported and tested, enabling a program to send and receive data. So vDos can do with Windows file functions to communicate with the assigned device (For most programs this will suffice.