Image Map Image Map
Results 1 to 7 of 7

Thread: DOS MODE LPT1 redirection failing: how to determine why?

  1. #1
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,638

    Default DOS MODE LPT1 redirection failing: how to determine why?

    I've been chasing some weirdness with a homebrew XT serial card. The card is a revised version of my original prototype, which seems to work 100%. Other than physical layout the only difference between the two is the second version has the data lines to the UART passing through a 74HCT245 buffer while the original was directly on the ISA bus. I've tested both in two different machines (Tandy 1000 EX and HX) and both cards pass Checkit diagnostics and seem to work correctly with most programs. There are two anomalies with the buffered card, however:

    1: On only one of the two machines DOS Kermit (3.14) doesn't work. Switching to terminal mode shows it transmitting characters correctly but only receiving some characters, almost like the parity settings are screwed up. Running the UART with the same speed/settings in Procomm looks okay.

    2: On both machines if I try to set up LPT1->COM1 or COM2 redirection using the DOS MODE command it fails to take effect. (I've tried several DOS versions.) I can set the speed on the port using the usual "mode com2:96,n,8,1" syntax, and running "mode lpt1:=com2" loads the resident part of MODE into RAM, but running "mode" again to show status shows that lpt1: is *not* redirected, and attempting to throw a print job at lpt1 won't work. Programs configured to directly throw print jobs at COM2 work fine, however.

    I can only assume that the buffer is introducing some kind of latency or... something?, although maybe I should try swapping UART chips between them to make sure the problem doesn't follow the UART. (So to be clear, I'm willing to accept there's a hardware anomaly as the root cause.) However, I am curious if anyone knows why the DOS MODE redirection might be failing; what criteria is it trying to use to decide if it's working or not? I found a thread on Vogons where someone was having issues trying to use the same redirection syntax in both VMs and on a physical DOS box and it simply failed the same way, but another poster said it was working fine on their stuff... and that was it in the thread. It's strange that mode setting works, programs that hit the port work, and it's happy to load the redirector but then it just seems to wander off into the weeds. Is there a device control block address in memory that's not getting updated for, reasons, that it doesn't think merits an error message?
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,671
    Blog Entries
    18

    Default

    A '245 seems to be an odd choice for a bidirectional bus, though not out of the question. Why not a '645? Could it be a problem with your bus steering logic?

  3. #3
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,638

    Default

    Quote Originally Posted by Chuck(G) View Post
    A '245 seems to be an odd choice for a bidirectional bus, though not out of the question. Why not a '645?
    I'm looking at the datasheet for a '645 and I'm sad to say I'm not clear what the difference is? (They're both 8-bit transceivers with 3-state outputs and a direction signal?)

    The card has two devices behind the '245, the UART and an 8-bit XT-CF interface. There's an AND gate in front of the OE line on the '245 which combines the separate enables for the CF device and UART, and direction is controlled by the ISA signal IOR. The motherboard of the machine uses similar looking logic (in its case a '245 in front of a slew of separate onboard peripherals) so it seemed like a legit design. I only have an old analog oscilloscope to work with so I'm not sure if I'd be able to see if there's something going on with propagation delay between the '245 and the AND that's rendering drive pulses too short, but like I said, the card passes diagnostics and seems to work for everything *but* these things, so if it is a signaling problem it's expressing itself only in very specific circumstances.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    32,671
    Blog Entries
    18

    Default

    My error--I read 245 and thought 244. The 245 is a pretty fast device, so I doubt that it's prop delay.

    Have you looked at the code for MODE? You should find relevance in the "INVOKE.ASM" module. Is your port being detected by the BIOS and its address set into 0:0 -> 0:7?

  5. #5
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,638

    Default

    Quote Originally Posted by Chuck(G) View Post
    My error--I read 245 and thought 244. The 245 is a pretty fast device, so I doubt that it's prop delay.
    So... I just tried the experiment of swapping UARTs and nothing changed... except for the worse. The card that I remember *was* working now no longer does the mode redirection either. And swapping it back doesn't restore it. I only used it the one time, I'm starting to think it was a fluke.

    Have you looked at the code for MODE? You should find relevance in the "INVOKE.ASM" module. Is your port being detected by the BIOS and its address set into 0:0 -> 0:7?
    It seems like the BIOS knows about them. If I try running the mode set commands on the port (setting the baud rate, etc) it'll tell me COM2 is an invalid device if I run it with it pulled out. And its settings take effect; I need to use MODE to set the port speed correctly before starting programs that hit COM2 directly, so it's doing that much.

    It actually seems like there's some general issue with MODE going resident. (On DOS 5) If I run "mode com2:96,n,8,1,P" mode returns "RESIDENT PORTION OF MODE LOADED", but then if I run "mode com2" it returns:

    Status for device COM2:
    ---------------------------
    Retry=NONE

    Shouldn't it return a different value for "Retry" now?
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  6. #6
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    1,638

    Default

    Re: the BIOS detection, I've run several diagnostic programs, including a shareware thing called "COMPORT" that specifically can tell you what an interrogation of the BIOS data area thinks is installed, and they all indicate that DOS *should* know about the COM ports. And MODE seems to see them; it's just not behaving correctly when it goes resident. At all.

    ... and, WT and an F. I just tried the "MODE" binary from FreeDOS (I didn't load FreeDOS, just downloaded its version of MODE.COM) and it seems to set up the redirection just fine. What's really weird about it is it doesn't load anything resident, at least that I can see with mem /c or Checkit.

    I wonder if this could be some Tandy BIOS thing.
    Last edited by Eudimorphodon; November 21st, 2019 at 01:27 PM.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  7. #7

    Default

    Quote Originally Posted by Eudimorphodon View Post
    it's just not behaving correctly when it goes resident. At all.
    This may or may not be related, but elsewhere I described a different problem (bug?) related to MODE.COM going resident, although it had to do with display settings. That was with DOS 6.x, but it may have been introduced with DOS 5; DOS 3.3 didn't exhibit the issue.

    That makes me wonder whether 3.3 would 'fix' your redirection issue as well... since a different (FreeDOS) version of MODE worked for you, perhaps it's a related bug introduced in later MS versions.
    int10h.org :: :: :: blog

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •