RM> Am about to try out yr BTPE executable. I fired it up on its own a
Thanks. I see you had a 0.15 second turnaround on the ENQ,
which is great. Can you see what MNP4 does now?
RM> 57600 isn't recognized. The source file DATA.C defines it
RM> only for OS2. Reason?
The reason is that originally I was after a 32-bit Binkley port,
and I couldn't give a stuff about DOS. Later on I realised that
I probably hadn't actually done anything to disrupt DOS, so I
tried recompiling under DOS, and was successful (can't remember
if it needed a little bit of work or not). The idea originally
was to just make it 32-bit so that I could use my proper
compilers on it to debug some of the problems I have had with
running my system. One of the enhancements I did make was to
allow 57600 for OS/2. I didn't even consider DOS. Now I just
went and checked your previous calls, and they were done with
Binkley 2.50. And Binkley 2.50 didn't support 57600, so why
did you suddenly think BTPE would? It's not something I would
have expected you to even try. Why do you want to do that
anyway? You're not transferring uncompressed files with me?!
And even if you were, my end is only 38400.
Anyway, I've just checked the code, and the way it works is
that those values in DATA.C are used to send the speed to
the fossil. However, there is only 3 bits used to specify
the speed, and they are...
010 = 300 baud
011 = 600 ''
100 = 1200 ''
101 = 2400 ''
110 = 4800 ''
111 = 9600 ''
000 = 19200 '' (Replaces old 110 baud mask)
001 = 38400 '' (Replaces old 150 baud mask)
As you can see, everything is used up, although an obvious
thing to do would be to scrap the 600 baud. However, you
don't need to even do that. If you leave it at 38400 in
the Binkley config, and tell your fossil to lock at 57600
(check out the X00 docs), then it should IGNORE any request
from Binkley to change the baud rate, so you will get the
desired 57600, or even 115200! BFN. Paul.
P.S. FREQ FSC-0015.* for the fossil specs
@EOT:
---
* Origin: X (3:711/934.9)
|