![]() Use our site to get millions Rapidshare links. All the files are relevant and ready to be loaded. Auto-convection refill Canon PGI-750 CLI-751 BCI-350 BCI-351 PGI-550 CLI-551 ink cartridge - Duration: 5:52. Refill House-填充小站-噴墨印表機-墨水-連供-改機-連續供墨-解碼. ![]() Well, that is quite a story, probably better to communicate directly: [email protected] (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). Soal cpns pdf gratis. 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. 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? 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. At the 'hardware' level, only reading from and writing to the base port (Transmitter Holding Buffer/Receiver Buffer) will be realistic, the rest is just ignored. To support more, would be trial and error sessions; what when to fake, like the LSR and so forth. Interrupt driven communications will be more demanding; besides the interrupt servicing routines being executed at the right moment, those routines will first try to determine what actually caused the interrupt, more faking.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |