Date   : Tue, 03 May 1983 13:25:02-EDT
From   : dudley@nadc.arpa
Subject: vt180 & mboot3

I beat the vt180.  I have successfully gotten mboot3 running
on the little sucker.  The port poop revealed in the letter excerpt
below is only part of the solution:

       From: Dick <MEAD@USC-ECLB>
       Subject: Re: vt180 port poop

       COMM port values are:
               DATA=58H
               STAT=59H        TBE=01,RDA=02

       CONSOLE values are:
               DATA=40H
               STAT=41H        (I assume same bit values)

       One gotcha, I read that interrupts are used in the VT180,
       so MBOOT3 and other adaptations to this system may need
       to do some trickery to work at all. I had used the right
       bits/addresses in one try and still no good.
       -------

The real trick is that since incoming characters are handled by interrupts,
the usart will never seem to have any characters ready when it is polled
by mboot3 in the normal fashion.  Rather then do what I suggested in an
earlier letter, i.e. turn off the interrupts, I did what DEC did in the
RDR: device handler in the vt180 bios.  That is, I poll the memory locations
that the interrupt handler uses to communicate with the bios.  In the latest
version of CPM that DEC is supplying [2.2 (1.1)], *the magic locations are:*

       0f541h  =       rec'd data available if == 1
       0f546h  =       rec'd character

The code to check for status in mboot3 is thus:

       before:                         |       after:
       in      modctlp                 |       lda     0f541h
       ani     modrcvr                 |
       cpi     modrcvr                 |       ora     a
       jnz     term    ;no char rec'd  |       jz      term    ;no char rec'd

and the code to get the rec'd char is now:

       in      moddatp                 |       mvi     a,0     ;clear status
       ani     7fh                     |       sta     0f541h
                                       |       lda     0f546h  ;get char
                                       |       ani     7fh

I got the magic location values by disassembling the bios RDR: handler.
Once you get past the IOBYTE nonsense, the handler loads the IX register
with the location of the status table for the RDR: device, and jumps to
a routine that polls the memory locations pointed to by the IX register
to wait for a char to come in.  The magic locations listed above are
actually IX+2 and IX+7 in the RDR: handler.  These location are likely
to change if DEC releases a new version of the bios.

I haven't gotten mdm707 running yet, although I'm close.  The overlay
method won't work since the code size of the routines is so different 
from that in the standard version of mdm707.  Instead, the entire mdm707.asm
file must be edited and re-assembled.  Since the little toy disks on
the vt180 are so small, I do the editing and assembling on another CPM
machine and use mboot3 to bring over the com file.  Time has not permitted
me to finish the debug of mdm707 as a result of all the kludges.

Let me know if you get any revelations on the vt180.

                                       good luck--
                                               dudley@nadc

~v