........................................................................
;             >>>>> Please put the title here <<<<<
laser
topmargin 1"
margin 1"
bottommargin 1"
hlt bold
; pick one of the fonts, and comment out or erase the one you don't want
;font helvetica
font times
point 9.4285
leading 1
symbol on
bl |
; The following rulers work for Times-Roman and Helvetica
; Three columns per page (2 1/16")
.................................<
AAA
by SDH

center
_A Closer Look at the DDB_

 Hello  assemblers!  A  couple  of
notes before we start. Last month's
AAA  did  not  contain  the program
listing. Whoops! You  may, however,
get  a  copy  of this file off  the
Network  by  _.LOG_ging  to  [100,51]
and transmitting  CLRAND.M68 across
the  phone  line. Also,  before  we
continue  with   more   programming
examples that deal with  file  I/O,
let's  take  one more close look at
the DDB (Dataset  Driver Block) and
understand  the  features  of  this
beast.
center
_Creating a DDB "Show" Program_
 One creative way to examine a DDB
for  any  one  file  is to create a
program that displays the contents!
Now  there's  an  idea!  In   fact,
that's  exactly  what  the  program
below  does - it shows the contents
of any file's  DDB. The program was
designed for the following format:
center
_.SHODDB Devn:filename.ext[P,PN]_
 The  main  program  is actually a
series  of  MACRO  "type"  commands
that  have been defined  above  the
main body of the code. These "type"
MACROs   make   the   source   code
extremely  compact and easy to read
while maintaining  correctness  and
efficiency. Let's take a close look
at  each  of  these  special "type"
MACROs contained in SHODDB.M68.
center
_TYPE1    AA,BB,CC_
 This MACRO  needs three variables
passed  to it before  it  generates
the   correct   code.   The   first
variable,  _AA_,  is  a  text  string
variable.  _BB_  is  a  one character
string that is appended to  the MOV
instruction  contained  within  the
MACRO,  and  _CC_ is the offset  into
the DDB. Time  to  walk through one
pass of TYPE1.
 Look  one  line below  the  label
TOP:. You should see
center
_TYPE1  < D.FLG>,B,D.FLG_
The three variables contained after
the TYPE1 call  are  passed  to the
TYPE1  MACRO  definition  contained
above  the main body. The following
lines are then generated by TYPE1:
_TYPE  < D.FLG>
TAB
CLR    D1
MOVB   FILE+D.FLG(A4),D1
OCVT   0,OT$TRM
CRLF_
The  lines produced will first TYPE
out the  D.FLG  string, then a TAB,
followed  by  a  (hex   or   octal)
number.  All  of  these  lines have
been covered in previous articles.
 There is a special case when  the
main body of the program comes  to,
for example, the following line:
center
_TYPE1 <BLOCK NUMBER>,  ,D.REC_
Notice here that  the  variable  _BB_
has  been intensionally left blank!
This blank  will be "passed" to the
MACRO    definition     and    used
accordingly. Notice that  this type
of variable passing is exactly  the
same as before, but now the code at
the MOV'BB line becomes  _MOV_. Slick
trick!
center
_TYPE2  AA,BB,CC_
 This  MACRO  also  expects  three
strings  to  be  passed:  a  string
value  _AA_,  an  offsett  _BB_, and  a
monitor call _CC_. Let's see  how one
example  of  the  TYPE2  MACRO call
generates code. Look for the second
TYPE2  line  in the main body.  You
should see:
center
_TYPE2   <  D.FIL>,D.FIL,UNPACK_
The following code will be produced
from this line:
_TYPE    <  D.FIL>
TAB
LEA     A1,FILE+D.FIL(A4)
LEA     A2,BUFFER(A4)
UNPACK
UNPACK
CLRB    @A2
LEA     A2,BUFFER(A4)
TTYL    @A2
CRLF_
Notice that you  may  actually pass
an instruction or monitor call to a
MACRO and have it part of the code.
Also  notice  that the first  TYPE2
command does _not_  pass  a  variable
for  _CC_.  This  is  similar  to the
"special case" discussed for TYPE1.
center
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
;ED!!!!!!! INCLUDE AAA16.M68 HERE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
;!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
_SHODDB Line-by-Line_
Now  let's take a quickie  look  at
some  of  the  lines  contained  in
SHODDB.M68.  Most of these commands
have  been  previously  covered  in
earlier sessions  -  but since this
is  a  "review"  of sorts,  I  have
included  some  repeat  topics  for
your benefit.
_SEARCH   SYS
 {etc, etc}
VEDIT_
 Here is where we search the files
contained on DSK0:[7,7]  to  obtain
special MACRO names and symbols. It
is  also where a version number  is
defined.
_.OFINI
.OFDEF   FILE,D.DDB
.OFDEF   BUFFER,8.
.OFSIZ   IMPSIZ_
 Two  variables are defined to our
user  memory  partition:  FILE  and
BUFFER.  FILE  is  our DDB variable
that we will be typing  out  to the
screen.   BUFFER   is   used  as  a
temporary   workspace  buffer   for
UNPACKs etc.
_{etc.. etc..}
FSPEC    FILE(A4),TXT
INIT     FILE(A4)
LOOKUP   FILE(A4)
JNE      QUIT_
 Here is where we get the filename
on the input line and then fill the
DDB  with  the   values   necessary
before   any   file   I/O   may  be
performed.
 The  FSPEC call expects a pointer
to  a  DDB.   FSPEC  processes  the
ASCII characters  on the input line
and places these characters  in the
DDB  at  the correct offsets within
the DDB (see  May  '87  AAA  for  a
picture  of  the  DDB structure and
offsets).   Notice   that   if   no
extension was provided on the input
line,   AMOS   will   assume    the
extension of .TXT.
 LOOKUP expects a pointer to a DDB
also. It will take the filename  in
the DDB and look in the appropriate
directory  for  the file. If found,
LOOKUP  will place  the  number  of
blocks,  the  first  block  of  the
file,  and  the  end-of-file  value
into  the   DDB   at   the  correct
offsets.   These  values  are   all
contained in the directory.
 INIT expects a pointer  to  a DDB
and will execute two functions. One
function   will   be  to  find  the
correct driver. For example, if the
file is on a Hawk Pack or a Floppy,
the  driver  requirements  will  be
different. The  second  function is
to allocate a buffer in user memory
-  the  size of which is determined
by  the driver.  For  example,  all
disk  type  devices  need  a buffer
space of 512 bytes (because  that's
how  big  a  disk  block  is).  The
buffer  size  and  its  pointer are
then  placed  in  the  DDB  at  the
correct offsets.
 At  this  time, the DDB is set up
and filled -  ready  for  file I/O.
The  rest  of the program uses  the
two "type" MACROs  discussed above,
except for the following section:
_TYPE  < D.PPN>
TAB
TYPE   <[>
PRPPN  FILE+D.PPN(A4)
TYPECR <]>_
 The only gizmo new  here  is  the
PRPPN   monitor   call.  This  call
expects a pointer  to  a  valid PPN
value. The monitor call then  takes
this  value  and  types  it  to the
screen  in  the P,PN format. Notice
that the brackets  "[]"  had  to be
produced  by  the  code and not the
PRPPN call.
_A Wrap_
 The rest is pretty  cake.  See if
you can follow the MACRO theory and
notice how the variables are passed
to  the MACROs to produce the final
code.
 After  you have assembled SHODDB,
enter  in  some  default  filespecs
(a file in your  current  PPN)  and
notice the default values displayed
in the DDB for the PPN and DSK etc.
Then enter in a valid filespec of a
file  that  is  not in your current
PPN and notice the output from this
entry. I have included  a sample of
the output below.
center
_.SHODDB DSK1:A.A[300,1]_
produces the following:
_D.FLG  40
D.ERR    0
D.DEV   DSK
D.DRV   1
D.FIL   A
D.EXT   A
D.PPN   [300,1]
BLOCK NUMBER    789
BUFFER ADDRESS  EA600
BUFFER SIZE     200
BUFFER INDEX    0
D.LVL    0
D.OPN    0
D.ARG    6
D.DVR    5A24
D.WRK:
  NUMBER OF BLOCKS           1
  ACTIVE BYTES LAST BLOCK    12F
  FIRST BLOCK NUMBER         789_

You are viewing proxied material from gopher.floodgap.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.