How do I read out certain fields of the Request Header

[Earnie]

This is my intialization routine. It works fine, but it outputs something I didn't expect.
The program has no specific purpose, it's just me playing to help my understanding.

Code Select Expand

initial  proc   near
         lea    dx,msgl         ;msgl was defined earlier
         mov    ah,9
         int    21h

         mov    dl,es:[bx]      ;"Length" field from Request Header
         mov    ah,2            ;write character to standard output
         int    21h

         mov    dl,es:[bx]+1    ;"Unit code" field from Request Header
         mov    ah,2            ;write character to standard output
         int    21h
       
         mov    dl,41h          ; "A"
         mov    ah,2            ;write character to standard output
         int    21h
         ret
initial  endp

The Output is:    1) the msgl message
                        2) an upward-pointing arrow
                        3) nothing
                        4) the character 'A'

I expected to get the length of the request header instead of this upward-pointing arrow.
Also the "unit code" was just a space character.

Is there maybe something wrong in the way I address the field? 

[FORTRANS]

Hi,

   The "upward-pointing arrow" is the character for the code
value 24 (18H).  That looks okay for the length.  The problem
(I guess) is that DOS function 2 is for character output and
not binary data per say.  Use a binary to numeric ASCII routine
to print the binary (byte) value as a human readable number.

   If the unit is zero nothing (blank) will be printed using function 2.

HTH,

Steve N.

[dedndave]

yah, Earnie
you need a little routine that converts binary values into hex or decimal ascii strings
may as well make it so it handles 16-bit values   :bg
hex is probably easiest

once you get that going, you can write some code to dump the entire request header

[Earnie]

I'll try that and report the outcome.

:U

[Earnie]

It works   :clap: I wrote a routine that does the conversion from decimal to ASCII

Thanks guys, I would not have found this mistake without you. At least not fast, cause I was totally on the wrong track.

[dedndave]

very good   :U
did you dump the entire header ?
show us the results   :bg

[Earnie]

Code Select Expand


LENGTH: 024
UNIT CODE: 000
COMMAND NUMBER: 000
STATUS: 000


Pretty boring so far

[Earnie]

I don't want to open up a new thread for this, so I'll ask here.

The thing is, I've been asking myself what it is that I want to achieve. I want to do low-level programming. That is the basic requirement for any project I'm going to start. But just playing around is so depressing, so I need a real project. And printing some characters in the console isn't going to do it for me. Can't get excited about that.

The ideas that came across my mind were these:

1) serial communication with another computer   
   problem: I only have 1 PC with the old COM port (my laptop has only USB, of course)
   although I could possibly use a rs232-usb converter for that

2) communication over NIC and ethernet cable
    problem: probably far, far beyond my current skills
 
Do you habe any suggestions for a suitable project ? I haven't found that much about device driver programming in this forum. Is it silly to try and build a device driver for DOS in this day and age?  Are there actually people in this forum who are still developing DOS device drivers?
I need some perspective on this so that I don't waste my time.

A further thought: Is it humanly possible to build for example a USB device driver or implement your write your own TCP/IP protocol stack without an insane amount of experience, say 20 years ?

[MichaelW]

For USB I think the biggest problem would be in understanding what you need to do, not in writing the code to do it. In any case, it's already been done, in (A86) assembler no less:

http://bretjohnson.us/

[FORTRANS]

Hi,

   If both your PC and laptop have parallel ports, you
could write a communications program using those.

   Another idea might be a language like Forth or Logo.

Regards,

Steve N.

[redskull]

If you want to do "real" low level stuff, the first thing you need is a computer running "real" DOS; NTVDM (windows 'dos boxes') just won't cut it.  They have bad habits of putting the kibash on anything out of the ordinary (TCP/IP, USB, block mode drivers), and you will end up having more hacks and kludges than good low level learning experiences.

-r

[dedndave]

Steve's suggestion about the parallel port is probably the easiest route
the DOS LPTn: drivers really aren't written to handle bi-directional communications (they are written for printers)
but the port hardware will handle it rather well

[Earnie]

Nope, no parallel port on my laptob. Just USB.

[dedndave]

need to google "USB 2.0 specification"
the DOS USB drivers in the link above are probably too out of date (hardware wise) to be of much use
then, you need to decide what you want to do
you could write a block device driver to access the drive on one machine from the other via USB
or, to send text strings back and forth, a character device driver
the nature of the 2 device types is quite different

[MichaelW]

Dave,

The DOS USB drivers at the link above are still under development, and I know of an industrial application where they are (or at least were) working with some recent SBCs running DOS/DPMI.