[net.micro.16k] DSI-32 review update

jk@utastro.UUCP (John Krist) (02/08/86)

               I  thought  that an update review of the DSI-32 board  from
          Definicon Systems,  Inc.  might be of interest to those who  are  
          still looking into this product.   I have found new things since  
          my original review from December.  But first..
           
          ** DON'T FLAME ON ME !!  I DON'T WANT TO HEAR IT !! HAVE A
             QUESTION? ASK !!  FEEL LIKE INSULTING AND QUOTING SALES
             HANDOUTS?  KEEP IT TO YOURSELF !! This is going to be a
             review, and I don't want to find my mailbox filled with
             blah, blah, blah about how this or that system or  chip 
             is better and that I am stupid, as has happened before.

          Whew!  Ok, on to the fun stuff...

               Let's  talk  about compilers.   There has been  talk  about  
          accuracy  of the compilers in this newsgroup before,  so I won't  
          say anything on that.
               The   documentation  doesn't  include  any  references   to  
          compiler  switches which are there.   Some of these  affect  the  
          results considerably.   One (-x88) suppresses generation of slow  
          and  wasteful code to get around old FPU bugs.   This speeds  up  
          the  Fortran Whetstone by about 20%.   Another (-x71) makes  all  
          Fortran  calls for single precision variables be made in  single  
          precision  (the  default is to convert to double  precision  and
          back again.  Is this teh UNIX default also?).   All this gives a  
          Whetstone time of 3.56 seconds (about 280k whetstones/sec).  
               The  Pascal  compiler seems to have trouble with the  field  
          width specifier in the write statements.  The following code,

                                 WRITELN ( 'h':6 )

          produces "hhhhhh" instead of "     h".   I have had very  little  
          experience  with  the Pascal,  so there could very well be  more  
          bugs.  
               I  have had not done much with the C compiler,  and I  have
          not found any bugs.
               The  compilers and libraries have been updated  about  four  
          times in the past three months.  Updates are $15.
               It  seems that much of the blame for whatever problems  are  
          in  the compilers lies with Green Hills Software.   They do  not  
          want to provide much information on the compilers (the Definicon  
          people  found the extra switches by searching through the source  
          code)  and  do not even provide full reference manuals  for  the  
          languages  (I  use  the  manual from my  Digital  Research  F77,  
          which, by the way, is the worst compilers imaginable).

               There  are  errors  in both the manual  and  read.me  files
          concerning  the  SVC interrupt calls to the MS-DOS  shell.   The
          read.me  file is incorrect regarding the SVC 20 call  (call  IBM
          interrupts).   The  entry in the manual is  correct.   Interrupt
          calls  ARE  available  through the _BDOS call from  any  of  the
          languages.  Also, there are calls available from any language to
          move  memory  to and from the IBM ram and  DSI  ram,  input  and
          output to a port, and make C library calls.

               I  have the graphics package,  which supports the IBM color
          graphics card and the Hercules graphics card (720x348).   It  is
          easy  to set up the memory so that many frames can be  generated
          and  downloaded for animation purposes.   The animation  results
          are  acceptable,  and  I get about 8-14 frames per second  (very
          rough guess).   The problem is that the downloading of the frame
          can  be seen (those familiar with the way the Apple loads  in  a
          picture  by  BLOADing  it know exactly how  it  looks,  only  it
          happens fast but perceptibly).   I suppose,  though, that things
          would be better on an AT,  since I have the regular PC,  and the
          memory fetching would be faster.
               The really big problem is the time it takes to generate the
          pixel in memory.   With the source code (in C) included, one can  
          see that for every pixel, the following is used :

               temp = 0x2000 * (row % 4) + 90 * (row / 4) + (col / 8)

          Ugh! Ack!  This takes FOREVER!  I'm trying to find a better way,  
          but  I'm not too hot on pixel mapping and such.   If someone out  
          there knows the secret,  HELP!  Of course, with the way the card  
          works, you can't have cursors.

               Let's talk about support.   First word of advice; don't try  
          calling  them except between 2 pm and 3 pm California time  (the  
          fact  that they're in California readily  explains  this).  They  
          don't seem to hang around long, but when you get them, they know
          what they are talking about.
               The bad thing is that they keep really quiet about updates,  
          bugs, etc.  If you're lucky, they will send you updates from out  
          of the blue and ask for $15.  Don't pay the money and they won`t  
          send you any more updates.  Don't expect to get bug reports, and  
          if you can get on the semi-support BBS (I tried an hour each day  
          for  a week to no avail) then the bug reports you will find  are  
          the  ones  the customers have entered on the BBS.   This is  the  
          weakest  point  of  the  entire  DSI-32  board.    If  you  want
          information,  you have to call,  wait 10 minutes for someone  to  
          find the right person,  and then find out that you were not sent  
          the already-a-month-old update.  Don't write (it took 6 weeks to  
          get a reply by writing).

               In  all,  I  still  think this is a great  board,  and  the  
          compilers  are superior to the ones for the PC.   The  only  big  
          problem  is the lack of bug reports,  and this is something that  
          Definicon should take seriously.

          John Krist
          U. Texas Astronomy Dept.
          jk@utastro.UUCP
          {allegra,ihnp4}!{noao,ut-sally}!utastro!jk