mode woes

[student0101]

You're right, I don't. I try to exhaust all other venues - manuals, search, etc., before I take up someone else's time. And then ask a simple question, in this case, is there a way to get MS-DOS 5.0 to report the current COM1 setting (without issuing a command to change it)?

What little experience I do have in forums such as this leads me to believe that a member of the community who knows the answer will simply share it. In this case the answer was a simple .exe file to download and run (see above).

Sorry to hear you don't see it that way.

[Squashman]

I am going to chalk your comments up to this psychology study.
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[Squashman]

Read a few dozen of the threads on the DOS forum and you tell me if it is really that simple!

[BC_Programmer]

Thanks, BC_Programmer. I was able to download MSD.EXE and run it on MS-DOS 5.0. Under COM Ports it reports COM1 is correctly set for Port Address, Baud rate, Parity, Data Bits and Stop Bits. Carrier Detect=Yes, Ring Indicator=No, Data Set Ready=Yes, Clear to Send=Yes, UART chip Used=16550AF. Printer working OK at the moment. I'll see what it says next time the printer isn't printing.

That's good, I was also able to see it change when I used the mode command to change the current options, so if the options were changed by other software in the meantime that will be reflected.

of course what software performed the change and why it seems to fail even after immediately setting the mode, that is a bit trickier to diagnose. It's a bit of cop-out but Printers themselves are already pretty finicky, and Serial Printers just add another layer of difficulty. It is also possible that it is failing on the Printer side as well, rather than something involving the computer itself.

I'm not certain but if it happens again and the MSD output doesn't give you anything useful, (eg looks identical) you might try doing the redirection I mention. If you redirect LPT1 to COM1, you should be able to do the same direct access by using PRN where you currently use COM1.

[BC_Programmer]

Read a few dozen of the threads on the DOS forum and you tell me if it is really that simple!

Threads in the DOS forum quite ironically hardly actually deal with DOS at all. Aside from this one, the first page only has 2 threads that actually involve actual MS/PC-DOS (ntfs4dos and an advertisement for MS-DOS based software). One could rename the forum to "NT Batch Scripting" and end up with a more accurate description of it's content. (This isn't limited to this forum, either- most sites talking about "DOS" are almost always about the NT Command Interpreter.).

The OP's only "mistake" was in thinking that the "Microsoft DOS" forum was about MS-DOS and would thus be populated with people who if nothing else, at least had access to a standard MS-DOS installation, if not also some understanding of some of the specifics of MS-DOS operation pertaining to what they are discussing.

[Squashman]

BC_Programmer, I agree with most of what you say.  From a technical stand point you and I know all that to be true.  But it is the other 90% of the people out there that still think cmd.exe is DOS and when you correct them they have no clue what you are talking about.

[foxidrive]

What might work to solve the problem if it reoccurs is either a tool to reset the COM port involved or maybe even loading a hardware diagnostic program like one of these will initialise the COM port: 

Test this in conjunction with powering down the printer to see if it is one, the other, or a combination of the two.  If the cable has circuitry then it may also be involved and need to be disconnected from both ends and reconnected.

Code: [Select]

--------===­­ agSI 1.2.2 ­­===--------
English version of the SystemInfo tool
 agSI with hundreds of items of info
   about hardware/system, operating
system, memory, software, drives, and
 configuration files, (running in DOS
   text mode) with many additional
  functions, such as changing system
    settings and disk formatting.
  >Extensive, detailed online help<
 New: extensive Intel chipset info,
   better hard disk bench, several
              bugfixes,...


Code: [Select]

          System Analyser version 5.2i

 Gives comprehensive information about your system.:
 Bios, Network, Dos, CPU/FPU, Cache, Memory, Video, AGP,
 Monitor, Drives, IDE, ATAPI, CD-Rom, DVD, RPC2, Lpt, Rs232,
 Mouse, Keyboard, IEEE 1284, Modem, Fax, ISDN, Sound,
 ASPI/CAM, SCSI, DMI, PCI, PCMCIA, Plug and Play, APM,
 ESCD, IRQ, DMA, CMOS, Y2K, ... and lots more!!

 It also gives benchmarks of the Processor, Memory,
 Harddisks, CD-Rom and the video adapter.

 Works with: DOS, Win3.1, Win95/98/ME, (Win NT/2000)

 Hans Niekus
 http://ourworld.cs.com/jniekus
 http://home.wxs.nl/~nieku001
 Email: [email protected]


Code: [Select]

¦   Hardware Info Program <SHAREWARE>   ¦
Ã---------------------------------------Â
¦ ¦ Recognizes 130 CPUs, CPU info, FPU  ¦
¦ ¦ Processor Number even if disabled ! ¦
¦ ¦ MultiCPU, P.I.ROM and Chipset info  ¦
¦ ¦ PnP, DMI, APM and ACPI information  ¦
¦ ¦ SPD Memory module and cache info    ¦
¦ ¦ ISA, EISA, MCA, PCI, A.G.P. devices ¦
¦ ¦ 421 VGA chipsets, memory size+type  ¦
¦ ¦ Video card, RAMDAC, TIGA, TV tuner  ¦
¦ ¦ VESA DDC monitor identification     ¦
¦ ¦ Sound card, CD-ROM, PCMCIA, Printer ¦
¦ ¦ COM, LPT, HW key, Modem info; 8042  ¦
¦ ¦ ASPI SCSI devices information       ¦
¦ ¦ E-IDE, ATAPI, LS-120, ZIP, DVD info ¦
¦ ¦ CPU Errata Test, IRQ & DMA list     ¦
¦ ¦ CPU, FPU, MMX, Disk, CD benchmarks  ¦
¦ ¦ Temperature, Voltage and FAN status ¦
¦      ... and much, much more ...      ¦
Ã---------------------------------------Â
¦ (c)1995-01 Martin Malík, BA, SLOVAKIA ¦
¦              mailto:[email protected] ¦
¦                 http://www.hwinfo.com ¦


Code: [Select]

Diag, the diagnostic programm (Author D. Marks)
-----------------------------------------------
Detects, tests and benchmarks your Hard- and Software.


Code: [Select]

PC-CONFIG V9.30 -Detects all the hardware
in your PC and shows them on the screen.
One of the best sysinfo-programs ever.
With CD-ROM benchmark routine! Finds
PCI boards, 6x86, K6-3, NexGen, Athlon
and Pentium III CPUs, detects lots of VGA
chips, APM functions, Burst Cache, Green
boards, Pentium Bug, PCMCIA, EIDE feat.
detailed PCI and SCSI info.


What you need to realise about question forums these days is that people don't give good details about their question,
or give bogus details, and are rude when you ask for further details - and you often don't hear from them when they have their solution.

It's a far cry from the days when everyone was an enthusiast and some respect was common.

[student0101]

Thanks for your help, folks.

Went through the application source code (written in DBL – DEC's Dibol variant) yesterday to see if there might be a stranded command that changes the COM port settings. Didn't find any. The only place it talks to the COM port is where it opens a channel to COM1, dumps the data into it, and closes the channel. It does it repeatedly most of the time without “misfiring.” Just to be sure, I reissued the MODE command just before opening that channel. No change.
   
Also spoke with the Black Box people. They say their converter simply takes the 8 data bits from the COM port, reassembles them into a parallel stream, and  sends the stream down to the Centronics plug. The DIP switches on this adapter are set to the same values as the COM port. They also suggested I bring the speed up, so I set it 19200, the max under DOS 5.0. Other than that, they say their converter listens to the printer for send/stop signals. The data streams are short - less than 1Kb total, way below the printer's 14K buffer capacity - so a stop signal is presumably never issued.

Further digging revealed that some escape sequences are not passed, the wrong sequence is passed, or are somehow packaged differently. This printer uses the Epson LQ-860 command set. However, symbol set “ESC (s12H” (27,'(s12H') embedded in the application software - and called under certain conditions - for example, locks up the printer whereas its decimal equivalent, 27,77, seems to get through OK. The lockup remains even after an initialize (27,64) string is issued. Don't know what effect other escape sequences might have.

So it seems the problem is not with the COM port setting after all. In any case, printer control beyond issuing basic commands is not my forte so, to eliminate the converter as the source, I ordered a serial interface, KX-PS14, for the printer. I'll see how that works and report back.

[Squashman]

You are certainly bringing back a lot of old memories for us.  But I am pretty sure my bourbon addiction has killed off most of my DOS brain cells.

[patio]

It's impossible to have a Bourbon addiction because of the nature of it's subliety's...

[foxidrive]

It's impossible to have a Bourbon addiction because of the nature of it's subliety's...

and coz it makes you forget how to spell

I ordered a serial interface, KX-PS14, for the printer. I'll see how that works and report back.

That will be of interest - and thanks for the detailed information.

[student0101]

I'm also looking at ATEN's AF142 printer switch as a workaround in case my serial interface solution bombs out, too. Their AF152.EXE loads a TSR hard-coded to capture Alt-L-Shift-1 and Alt-L-Shift-2 (or Alt-L-Shift-A and Alt-L-Shift-B) interrupts to select one of two parallel printers connected to the (one and only) parallel port via their AF142 switch. This arrangement isn't practical for batch processing (someone has to be there to physically press these keys together), so I want to simulate it in the application software.

Does anyone happen to know if there is an MS-DOS 5.0 command string or prog to simulate a PC-101 keyboard's Alt-L-Shift-1 and Alt-L-Shift-2 inputs? I can call any DOS command string or external prog from the application but assembly language programming to simulate keyboard scancodes is over my head.

[Squashman]

We got a guy over on the DosTips forum that is pretty good with Assembly.  I will see if I can get him to stop over here.

[foxidrive]

Does anyone happen to know if there is an MS-DOS 5.0 command string or prog to simulate a PC-101 keyboard's Alt-L-Shift-1 and Alt-L-Shift-2 inputs?

I can email any of these if you want to try them.

Code: [Select]

KeyTap v1.30 - Non-TSR keystroke simulator.
Runs application or shell whilst simulating
user keypresses. Ideal for automating menu
driven programs, or using from batch scripts.
Key list may given on command line or read
from file. Automatic pacing for slow apps.
Delays can be inserted into the key list.
less than 3.5K in memory!


Code: [Select]

KeyPress 3.0 is designed to "stuff" the keyboard buffer.  Unlike
other programs, however, KeyPress is not a TSR and does not hook any
interrupt vectors to do this.  The result is that KeyPress does not
require any memory and does not pose a compatibility problem for any
other programs.  The downside is that KeyPress can only stuff in 16
characters before running out of space in the keyboard buffer.


Code: [Select]

AUTOKEY
Automatic keyboard entry from a text file.
Batch file utility.

    @echo off
    :SET-EOF.BAT - Sets evar EOF=^Z  (Ctrl-Z)
     echo "set eof="F6 CR>temptemp.key
     echo "rem --- del temptemp.key" CR>>temptemp.key
     echo "release" CR>>temptemp.key
     mark
     autokey temptemp.key
    :End ------------------------------ -vjf-



Code: [Select]

  STUFFIT 3.21 / STUFFKEY 4.10
             ------------------------------------------
          Stuffit Copyright (c) Terje Mathison 1990 - 1992
       Stuffkey Enhancements Copyright (c) Juergen Geist 1992
      Stuffkey 4.10 Enhancements Copyright (c) Mike Smith 1995
       ------------------------------------------------------
         Although copyrighted, the described programs are a
                           'labor of love'
                        and completely free!



[student0101]

Thanks Squashman. Standing by...

Thanks for the offer foxidrive. Did these progs work for you? I've tried several of these but they all seem to be limited to 2-byte scancodes.

KeyTap and Autokey: Neither seems able to handle 3-byte scancodes (e.g. Alt+L-Shift+1 returns the same 2-byte code as Alt+1).

I didn't try Stuffit and Stuffkey because their doc doesn't even list 3-byte codes (e.g. Alt+L-shift+character) (http://files.mpoli.fi/unpacked/software/dos/utils/keyboard/stfkey41.zip/stuffkey.doc).

Autokey doesn't work for me because, according to their doc, it can't coexist with TSRs that call the keyboard input.

I couldn't find KeyPress 3.3 for MS-DOS 5.0 so if you have a copy that works - or a link to one - I'd appreciate it.