Martin McCormick wrote:
>
>         I found an example interrupt-driven serial device driver in a book
> called the MSDOS Encyclopedia.  The driver looks like it should be a great
> core around which to build some PIC communication routines if I can ever
> get it working.
>
>         Since these things can be rather involved to diagnose, I think I
> have the problem narrowed down to one thing.  I have yet to see a single
> hardware-driven interrupt happen.  The code sets up all four possible
> interrupt triggers that one can have on a P.C. serial port.  There is an
> interrupt enable register in which four bits correspond to these switches
> and they are definitely set correctly.  The code also sets the ISR vectors
> and a special enable bit which is called USR2 that is a final interlock
> which can turn off the interrupts from a serial port.  In other words,
> everything that can be turned on appears to be on and I get not one interrupt
> no matter what happens on the port.
>
>         This is definitely not a case of the ISR not working right.  I have
> placed test code at the beginning of the ISR which clicks the P.C. speaker
> any time it runs and there is not a sound.  There are also no characters
> being put in to the ring buffer.  I can hammer the serial port with megs
> of bytes and it is as if the cable were not connected.  Now, if I run a
> program like Kermit or a little C-based utility that talks to the device
> driver, I can see that all the right hand-shake signals such as DTR, CTS,
> and DCD are all on and data are flying in both directions.  The port
> and cable both work as advertised.  It is something I am doing or not doing
> that prevents the driver ISR from ever getting a chance to run.  Others who
> have run this code report that it works.  I have run it on more than one
> computer with different versions of DOS and with or without ansi.sys and
> it is deaf to all interrupts.  It does output data, but there are still no
> hardware interrupts happening and therefore the flow-control doesn't work
> for the same reason that it can't receive data.
>
>         Has anybody ever seen this sort of problem before?  The assembler
> source is about 900 lines long so I am not including it.  The problem is
> definitely that no interrupts are occurring on the serial port. Whether the
> ISR code works is another point, but there must be interrupts first and I
> will worry about the ISR later.
>
>         When working, this should be really nice for those who want robust
> communications with a PIC or some other device.  The serial input buffer
> should gather data until it either overflows or is read and the standard
> DOS function calls for reading and writing are sufficient.
>
>         Just so there is no confusion, the system does not behave any
> differently after installing the driver so it is not crashing anything.
> There are just no serial interrupts at all.
>
>         I would appreciate either a direct answer if this is familiar or
> a pointer to some more example serial interrupt code that is hopefully
> written in assembler that I can examine and see what is different.
> If I find out what is wrong, I will gladly share with others since this code
> is about 10 years old and is based on various public domain sources.
>
> Martin McCormick

10 years ago :))) i developted a Assembly Program (Resident Program with
 Interrupt Serial) that
allows
a remote computer (PC) uses my A and B drive, using the serial communication!
The remote have a Resident Program (Assembly too) that when is pressed ShiftF5
 (i'm not remember
if is this sequence), changes the Drive A: and B: for remote remote.
When the remote user type DIR A:, the drive of my computer runs, and the data
 returns for the
remote computer.

My host computer, when receive a serial data, automatic a interrupt is trigged.

I can look for you this old source code!

mIGUEL.