[net.micro.amiga] Orphaned Response

bees@infoswx.UUCP (11/26/85)

>/* Written 11:37 pm  Nov 18, 1985 by well.UUCP!perry in net.micro.amiga */
>/* ---------- "Re: net.sources.amiga - (Lets make" ---------- */
>Haven't we passed around enough bytes dealing with how to create a net.sources
>for the AMIGA. 
>Someone should just set something up. Chances are the way chosen will directly
>benefit a significant   fraction  of those concerned.  I am confident that the 
>rest of the interested public will be provided for.

The reason we go through all this rigamarole before creating another
newsgroup is that keeping this net half-way organized takes a lot of
work.  In order to maintain sanity, everyone using this net needs to
take it upon [him|her]self to follow the "rules of etiqette" agreed
upon by the members at large.

Discussing the pluses and minuses of creating a new group helps keep
un-needed groups from appearing constantly.  It also helps those with
the idea of creating it decide the best place to put it and the best
thing to name it.  This avoids a lot of mistakes.

There currently IS a mechanism for distributing sources.  Post them to
net.micro.amiga since the traffic there is still small enough to
manage.

I posted the original suggestion for a sources group, and have been
collecting all relevant discussion in net.micro.amiga and
net.news.group, for the last couple weeks.  Soon I will post the
results of the discussion and voting.  At that point, either more
discussion will be needed or the group will either be created or not.

Patience!

Ray Davis
Teknekron Infoswitch, Richardson, TX
infoswx!bees, (214)644-0570

bees@infoswx.UUCP (12/03/85)

According to my local dealer, if I buy an Okimate 20 with the
PC kit, Okidata will automatically send me the new ROMs.

I assume that either the dealer or I have to request them.  They
also said that they would be able to get the ROMs from the local
Okidata rep.

..... wondering if I should wait for the real Amiga kit .....

Ray Davis

mikel@ccvaxa.UUCP (12/24/85)

The mand1.c version we received was broken. Here is some of the broken things
I have found.

open_winds()
{
   int i,color;

   nw.Width = max_x;
   nw.Height = max_y+STARTY;

   if (color_mode & 1) {
      ns.ViewModes = NULL;
      ns.Depth = 5;
   }

----> Somethings missing here, I assume it should be an else ???

      ns.ViewModes = HAM;
      ns.Depth = 6;
   }
/* then the following with the stuff in between removed */
   nw.Screen = screen;
   w = (struct Window *)OpenWindow(&nw);
   if (w == NULL) {
      CloseScreen(screen);
      fputs("Can't open new window!\n",console);
      return (1);
-->
/* seems to be missing a } */


Could someone please send me a version which works?

My address is:
	mikel@gswd-vms	<-- prefered
	inhp4!uiucdcs!ccvaxa!mikel

Thanks,

Mikel Matthews
Gould CSD Urbana, IL

jim@haddock.UUCP (12/25/85)

/* Written 11:59 pm  Dec 11, 1985 by french@caip in haddock:net.micro.amiga */
/* ---------- "MAND1.C - Mandelbrot Set - 2 of 2" ---------- */
From: "french robert%d.mfenet"@LLL-MFE.ARPA

/*
                   MAND1.C - Graphics routines
             Mandelbrot Self-Squared Dragon Generator
                    For the Commodore Amiga
                         Version 1.00

                      Accompanies MAND.C

             Copyright (c) 1985, Robert S. French
                  Placed in the Public Domain

This program may be distributed free of charge as long as the above
notice is retained.

*/


/*-------------------*/
/* Lots of includes! */

#include <exec/types.h>
#include <exec/tasks.h>
#include <exec/libraries.h>
#include <exec/devices.h>
#include <devices/keymap.h>
#include <graphics/copper.h>
#include <graphics/display.h>
#include <graphics/gfxbase.h>
#include <graphics/text.h>
#include <graphics/view.h>
#include <graphics/gels.h>
#include <graphics/regions.h>
#include <hardware/blit.h>
#include <intuition/intuition.h>
#include <intuition/intuitionbase.h>
#include <stdio.h>


/*-------------------*/
/* Misc. definitions */

#define EVER ;;
#define MAXX 640
#define MAXY 390
#define STARTY 10

#define TOPW2 w2->BorderTop
#define BOTTOMW2 (w2->Height - w2->BorderBottom)
#define LEFTW2 w2->BorderLeft
#define RIGHTW2 (w2->Width - w2->BorderRight)


/*---------------------------------*/
/* Fast-Floating-Point Definitions */

extern   int     SPFix();
extern   int     SPFlt();
extern   int     SPCmp();
extern   int     SPTst();
extern   int     SPAbs();
extern   int     SPNeg();
extern   int     SPAdd();
extern   int     SPSub();
extern   int     SPMul();
extern   int     SPDiv();
 
extern   int     SPAtan();
extern   int     SPSin();
extern   int     SPCos();
extern   int     SPTan();
extern   int     SPSincos();
extern   int     SPSinh();
extern   int     SPCosh();
extern   int     SPTanh();
extern   int     SPExp();
extern   int     SPLog();
extern   int     SPPow();
extern   int     SPSqrt();
extern   int     SPTieee();
extern   int     SPFieee();

extern int MathBase,MathTransBase;


/*----------------------*/
/* Graphics definitions */

extern struct   GfxBase       *GfxBase;
extern struct   IntuitionBase *IntuitionBase;
 
struct   RastPort      *rp,*rp2;
struct   ViewPort      *vp;
 
struct TextAttr TextFont =
    {
       "topaz.font", /* Standard system font */
       8,    0,    0
    };
 
struct   Window        *w,*w2;
struct   Screen        *screen;
struct   IntuiMessage  *message;
 
struct NewScreen ns = {
   0, 0,                               /* start position                */
   320, 200, 6,                        /* width, height, depth          */
   0, 1,                               /* detail pen, block pen         */
   HAM,                                /* Hold and Modify ViewMode      */
   CUSTOMSCREEN,                       /* screen type                   */
   &TextFont,                          /* font to use                   */
   "",                                 /* default title for screen      */
   NULL                                /* pointer to additional gadgets */
   };
 
struct NewWindow nw = {
         0, 0,                          /* start position                */
         320, 200,                      /* width, height                 */
         -1, -1,                        /* detail pen, block pen         */
         CLOSEWINDOW|MOUSEBUTTONS,      /* IDCMP flags                   */
         ACTIVATE|WINDOWCLOSE|BORDERLESS|BACKDROP,
                                        /* window flags                  */
         NULL,                          /* pointer to first user gadget  */
         NULL,                          /* pointer to user checkmark     */
         "Mandelbrot Dragons",          /* window title                  */
         NULL,                          /* pointer to screen (set below) */
         NULL,                          /* pointer to superbitmap        */
         0, 0, 320, 200,                /* ignored since not sizeable    */
         CUSTOMSCREEN                   /* type of screen desired        */
};

struct NewWindow aw = {
         0, 10,
         100, 70,
         -1, -1,
         NULL,
         WINDOWDRAG|WINDOWSIZING|SMART_REFRESH,
         NULL,
         NULL,
         "Analysis",
         NULL,
         NULL,
         0, 0, 320, 200,
         CUSTOMSCREEN
};

long last_color;


/*----------------------------------*/
/* Miscellaneous Global Definitions */

extern union kludge {
   float f;
   int i;
} start_r,end_r,start_i,end_i;  /* Block bounds for set */
extern int max_x,max_y;  /* Graphics window size */
extern int max_count,color_inc,color_offset,color_set,color_mode,color_div;
extern int color_inset,func_num;

extern int v_starty,max_mem;
extern long v_offset;
extern UWORD *color_table,*v_mand_store;

extern int modified,want_read;

extern FILE *console,*v_fp,*redir_fp;
 

/*----------------*/
/* Color routines */

init_colors()
{
   switch (color_set) {
      case 0: init_cincr(); break;
      case 1: init_c7rot(); break;
   }
}

init_cincr()
{
   UWORD i;

   for (i=0;i<4096;i++)
      *(color_table + i) = i;
}

init_c7rot()
{
   UWORD i,j,*base;

   base = color_table;
   *(base++) = 0;

   for (j=0;j<39;j++) {
      for (i=1;i<16;i++)
         *(base++) = i;
      for (i=1;i<16;i++)
         *(base++) = i << 4;
      for (i=1;i<16;i++)
         *(base++) = i << 8;
      for (i=1;i<16;i++)
         *(base++) = i | (i << 4);
      for (i=1;i<16;i++)
         *(base++) = i | (i << 8);
      for (i=1;i<16;i++)
         *(base++) = (i << 4) | (i << 8);
      for (i=1;i<16;i++)
         *(base++) = i | (i << 4) | (i << 8);
   }
}


/*----------------*/
/* Other routines */

open_winds()
{
   int i,color;

   nw.Width = max_x;
   nw.Height = max_y+STARTY;

   if (color_mode & 1) {
      ns.ViewModes = NULL;
      ns.Depth = 5;
   }
      ns.ViewModes = HAM;
      ns.Depth = 6;
   }

   if (color_mode & 2) {
      ns.Height = 400;
   }
   else
      ns.Height = 200;

   if (color_mode & 4) {
      ns.Width = 640;
      ns.ViewModes |= HIRES;
      ns.Depth = 4;
   }
   else
      ns.Width = 320;
   screen = (struct Screen *)OpenScreen(&ns);
   if (screen == NULL) {
      fputs("Can't open new screen!\n",console);
      return (1);
   }
 
   ShowTitle(screen,FALSE);

   nw.Screen = screen;
   w = (struct Window *)OpenWindow(&nw);
   if (w == NULL) {
      CloseScreen(screen);
      fputs("Can't open new window!\n",console);
      return (1);

   vp = &screen->ViewPort;
 
   SetDrMd(rp,JAM1);
   SetBPen(rp, 0);

   if (color_mode & 1)
      for (i=0;i<28;i++) {
         color = *(color_table+i*color_inc);
         SetRGB4(vp,i+4,(color >> 8) & 0xf,(color >> 4) & 0xf,color & 0xf);
      }

   return (0);
}
 
void wait_close()
{
   ULONG class;
   USHORT code;

   if (redir_fp) {
      Delay(600);
      CloseWindow(w);
      CloseScreen(screen);
      return;
   }

   for (EVER) {
      if (message = (struct IntuiMessage *)GetMsg(w->UserPort)) {
         class = message->Class;
         code  = message->Code;
         ReplyMsg(message);
 
         if (class == CLOSEWINDOW) {
            CloseWindow(w);
            CloseScreen(screen);
            return;
         }
      }
   }
}

gen_mand()
{
   void write_out();

   int x_coord,y_coord,count;
   union kludge x_gap,y_gap,z_r,z_i,u_r,u_i,temp,temp2,temp3,const0;
   union kludge const1,const2,const12;
   ULONG class;
   USHORT code;

   if (v_fp) {
      fclose(v_fp);
      v_fp = NULL;
   }

   v_fp = fopen("Mandelbrot.temp.file","w+");
   if (v_fp == NULL) {
      abort("Can't open temporary file!");
   }

   v_starty = 1;
   v_offset = 0L;
   modified = FALSE;
   want_read = FALSE;

   if (open_winds())
      return (1);

   x_gap.i = SPDiv(SPFlt(max_x),SPSub(start_r.i,end_r.i));
   y_gap.i = SPDiv(SPFlt(max_y),SPSub(start_i.i,end_i.i));

   const0.i = SPFlt(0);
   const1.i = SPFlt(1);
   const2.i = SPFlt(2);
   const12.i = SPDiv(SPFlt(2),SPFlt(1));

   for (y_coord=0;y_coord<max_y;y_coord++) {
      last_color = 0xfff;
      v_pos_line(y_coord);
      modified = TRUE;
      for (x_coord=0;x_coord<max_x;x_coord++) {

         while (message = (struct IntuiMessage *)GetMsg(w->UserPort)) {
            class = message->Class;
            code  = message->Code;
            ReplyMsg(message);
/* This routine crashes for some reason, thus it is left out
            if (class == CLOSEWINDOW) {
               CloseWindow(w);
               CloseScreen(screen);
               fclose(v_fp);
               v_fp = NULL;
               return (0);
            }                       */
         }

         if (func_num == 0)
            z_r.i = const0.i;
         else
            z_r.i = const12.i;

         z_i.i = const0.i;
         u_r.i = SPAdd(start_r.i,SPMul(SPFlt(x_coord),x_gap.i));
         u_i.i = SPAdd(start_i.i,SPMul(SPFlt(max_y-y_coord-1),y_gap.i));
         count = 0;
         for (count=0;SPFix(SPAdd(SPMul(z_r.i,z_r.i),SPMul(z_i.i,z_i.i)))<4&&(count<max_count);count++) {
            if (func_num == 0) {  /* z = z^2-u */
               temp.i = SPSub(u_r.i,SPSub(SPMul(z_i.i,z_i.i),SPMul(z_r.i,z_r.i)));
               z_i.i = SPSub(u_i.i,SPMul(SPMul(const2.i,z_r.i),z_i.i));
               z_r = temp;
            }
            else if (func_num == 1) {  /* z = uz(1-z) */
               temp2.i = SPSub(z_r.i,const1.i);
               temp3.i = SPNeg(z_i.i);
               temp.i = SPSub(SPMul(temp3.i,z_i.i),SPMul(temp2.i,z_r.i));
               z_i.i = SPAdd(SPMul(temp2.i,z_i.i),SPMul(temp3.i,z_r.i));
               z_r = temp;
               temp.i = SPSub(SPMul(z_i.i,u_i.i),SPMul(z_r.i,u_r.i));
               z_i.i = SPAdd(SPMul(z_r.i,u_i.i),SPMul(z_i.i,u_r.i));
               z_r = temp;
            }
         }
         if (count >= max_count)
            count = 0;
         *(v_mand_store+(y_coord-v_starty)*max_x+x_coord) = count;
         write_out(count,x_coord,y_coord);
      }
   }
   return (0);
}
 
disp_mand()
{
   void write_out();

   int x_coord,y_coord,count;

   if (open_winds())
      return (1);

   want_read = TRUE;

   for (y_coord=0;y_coord<max_y;y_coord++) {
      last_color = 0xfff;
      v_pos_line(y_coord);
      for (x_coord=0;x_coord<max_x;x_coord++) {
         count = *(v_mand_store+(y_coord-v_starty)*max_x+x_coord);
         write_out(count,x_coord,y_coord);
      }
   }

   return (0);
}

anal_mand()
{
   union kludge x_gap,y_gap,z_r,z_i,u_r,u_i,const0,const1,const2,const4;
   union kludge const12,temp,temp2,temp3;
   int count,x,y,width,height,last_x,last_y,select,lines;
   ULONG class;
   USHORT code;

   if (disp_mand())
      return (1);

   x_gap.i = SPDiv(SPFlt(max_x),SPSub(start_r.i,end_r.i));
   y_gap.i = SPDiv(SPFlt(max_y),SPSub(start_i.i,end_i.i));

   const0.i = SPFlt(0);
   const1.i = SPFlt(1);
   const2.i = SPFlt(2);
   const4.i = SPFlt(4);
   const12.i = SPDiv(SPFlt(2),SPFlt(1));

   last_x = -1;
   last_y = -1;
   select = 0;
   lines = 0;

   aw.Screen = screen;
   w2 = (struct Window *)OpenWindow(&aw);
   if (w2 == NULL)
   {
      CloseWindow(w);
      CloseScreen(screen);
      fputs("Can't open analyzing window\n",console);
      return (1);
   }

   rp2 = w2->RPort;
 
   SetDrMd(rp2,JAM1);
   SetBPen(rp2, 0);

   SetAPen(rp2, 1);
   RectFill(rp2,LEFTW2+1,TOPW2+1,RIGHTW2-1,BOTTOMW2-1);

   for (EVER) {
      if (message = (struct IntuiMessage *)GetMsg(w->UserPort)) {
         class = message->Class;
         code  = message->Code;
         ReplyMsg(message);
 
         if (class == CLOSEWINDOW) {
            CloseWindow(w2);
            CloseWindow(w);
            CloseScreen(screen);
            return (0);
         }
         if (class == MOUSEBUTTONS)
            if (code == SELECTDOWN) {
               if (w->MouseY < STARTY)
                  lines = !lines;
               else
                  select = TRUE;
            }
            else if (code == SELECTUP)
               select = FALSE;
      }
      if ((last_x != w->MouseX || last_y != w->MouseY) && select &&
          w->MouseX < max_x && w->MouseY >= STARTY && w->MouseY < max_y+STARTY) {
         last_x = w-> MouseX;
         last_y = w-> MouseY;
         SetAPen(rp2,1);
         RectFill(rp2,LEFTW2+1,TOPW2+1,RIGHTW2-1,BOTTOMW2-1);
         width = RIGHTW2 - LEFTW2 - 6;
         height = BOTTOMW2 - TOPW2 - 4;
         SetAPen(rp2,3);
         Move(rp2,LEFTW2+2,TOPW2+height/2+2);
         Draw(rp2,RIGHTW2-2,TOPW2+height/2+2);
         Move(rp2,LEFTW2+width/2+3,TOPW2+2);
         Draw(rp2,LEFTW2+width/2+3,BOTTOMW2-2);
         SetAPen(rp2,2);
         if (func_num == 0)
            z_r.i = const0.i;
         else
            z_r.i = const12.i;
         z_i.i = const0.i;
         u_r.i = SPAdd(start_r.i,SPMul(SPFlt(last_x),x_gap.i));
         u_i.i = SPAdd(start_i.i,SPMul(SPFlt(max_y-(last_y-STARTY)-1),y_gap.i));
         count = 0;
         for (count=0;SPFix(SPAdd(SPMul(z_r.i,z_r.i),SPMul(z_i.i,z_i.i)))<4&&(count<max_count);count++) {

            temp.i = SPDiv(const4.i,SPMul(z_r.i,SPFlt(width)));
            x = SPFix(temp.i);
            temp.i = SPDiv(const4.i,SPMul(z_i.i,SPFlt(height)));
            y = SPFix(temp.i);

            if (!lines)
               if (x != 0 || y != 0)
                  WritePixel(rp2,x+width/2+LEFTW2+3,height/2-y+TOPW2+2);
               else ;
            else
               if (count == 0)
                  Move(rp2,x+width/2+LEFTW2+3,height/2-y+TOPW2+2);
               else
                  Draw(rp2,x+width/2+LEFTW2+3,height/2-y+TOPW2+2);

            if (func_num == 0) {  /* z = z^2-u */
               temp.i = SPSub(u_r.i,SPSub(SPMul(z_i.i,z_i.i),SPMul(z_r.i,z_r.i)));
               z_i.i = SPSub(u_i.i,SPMul(SPMul(const2.i,z_r.i),z_i.i));
               z_r = temp;
            }
            else if (func_num == 1) {  /* z = uz(1-z) */
               temp2.i = SPSub(z_r.i,const1.i);
               temp3.i = SPNeg(z_i.i);
               temp.i = SPSub(SPMul(temp3.i,z_i.i),SPMul(temp2.i,z_r.i));
               z_i.i = SPAdd(SPMul(temp2.i,z_i.i),SPMul(temp3.i,z_r.i));
               z_r = temp;
               temp.i = SPSub(SPMul(z_i.i,u_i.i),SPMul(z_r.i,u_r.i));
               z_i.i = SPAdd(SPMul(z_r.i,u_i.i),SPMul(z_i.i,u_r.i));
               z_r = temp;
            }
         }
      }
   }
}

void write_out(color,x,y)
int color,x,y;
{
   void ham_write();

   y += STARTY;

   if (!(color_mode & 1)) {
      if (color == 0)
         color = color_inset;
      else
         color = color*color_inc+color_offset;
      ham_write(*(color_table+color),x,y);
   }
   else if ((color_mode & 1) && !(color_mode & 4)) {
      if (color == 0)
         color = color_inset % 28;
      else
         color = (((color-1)/color_div+color_offset) % 28);
      SetAPen(rp,color+4);
      WritePixel(rp,x,y);
   }
   else if (color_mode & 4) {
      if (color == 0)
         color = color_inset % 12;
      else
         color = (((color-1)/color_div+color_offset) % 12);
      SetAPen(rp,color+4);
      WritePixel(rp,x,y);
   }
}

void ham_write(color, x, y)
int color;
int x, y;
{
   if ((color & 0xf00) != (last_color & 0xf00)) {
      SetAPen(rp,((color & 0xf00) >> 8) + 0x20);
      WritePixel(rp,x,y);
      last_color = (last_color & 0xff) | (color & 0xf00);
      return;
   }

   if ((color & 0xf0) != (last_color & 0xf0)) {
      SetAPen(rp,((color & 0xf0) >> 4) + 0x30);
      WritePixel(rp,x,y);
      last_color = (last_color & 0xf0f) | (color & 0xf0);
      return;
   }

   SetAPen(rp,(color & 0xf) + 0x10);
   WritePixel(rp,x,y);
   last_color = (last_color & 0xff0) | (color & 0xf);
   return;
}
/* End of text from haddock:net.micro.amiga */

keithd@cadovax.UUCP (Keith Doyle) (12/29/85)

In article <26600013@ccvaxa> mikel@ccvaxa.UUCP writes:
>
>The mand1.c version we received was broken. Here is some of the broken things
>I have found.
>
>open_winds()
>{
>   int i,color;
>
>   nw.Width = max_x;
>   nw.Height = max_y+STARTY;
>
>   if (color_mode & 1) {
>      ns.ViewModes = NULL;
>      ns.Depth = 5;
>   }
>
>----> Somethings missing here, I assume it should be an else ???
>
>      ns.ViewModes = HAM;
>      ns.Depth = 6;
>   }
>/* then the following with the stuff in between removed */
>   nw.Screen = screen;
>   w = (struct Window *)OpenWindow(&nw);
>   if (w == NULL) {
>      CloseScreen(screen);
>      fputs("Can't open new window!\n",console);
>      return (1);
>-->
>/* seems to be missing a } */
>
>Could someone please send me a version which works?

Ditto.  I made the same observations here, and after adding the
'else {' and the '}', it still dosen't work very well.  I can
get it to compile, and when executed it sort of runs, but 
can't make it do much useful.  I'd enjoy a fixed version too
if someone has figured it out.

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
#  cadovax!keithd@ucla-locus.arpa

stephen@datacube.UUCP (01/15/86)

Price! Price! Price!


Stephen Watkins                    UUCP: ihnp4!datacube!stephen
Datacube Inc.; 4 Dearborn Rd.; Peabody, Ma. 01960; 617-535-6644

bees@infoswx.UUCP (03/10/86)

>Idea:	Could O/S hackers please make the file system detachable from the
>	rest of the O/S? This requires treating file systems like they
>	existed at the other end of a network, and doing remote procedure
>	calls like "create a directory entry for file X and give it name Y".
>
>	An immediate benefit of this is that when you plug a FOO-format
>	diskette (or binary file) into a BAR-machine all your ordinary
>	utilities keep working but they use a different name for the
>	diskette drive in order to use a different file-system server.
>
>More:	To do this, you distinguish between a "device-driver" which hides
>	those details of hardware to horrible for ordinary mortals to
>	behold and a "file-system" which assigns meanings to the bit
>	ingested and egested by the device-driver.

I believe that this is possible on the Amiga.  Each disk inserted into
the machine gets it's own "file-system" task.  Also, everything in the
OS is a linked list, so why couldn't I link in a different "file-system"
for say an ms-dos diskette or whatever?

Ray Davis

bees@infoswx.UUCP (03/10/86)

> 1) A Font Editor   
According to Commodore-Amiga in PA, they will soon be releasing a programmer
utilities disk for sale at your local dealer.  It is supposed to come with
a "real nice" font editor.

Ray Davis

page%ulowell@ulowell.UUCP (04/25/86)

Recently, dillon@CORY.BERKELEY.EDU (Matt Dillon) wrote:
>	That IDIOT *!#@$% RUN command sets the process priority of the 
>process it's running to -5!!!!

That seems pretty logical to me.  If I say 'I want this in the
background', to me it means 'do it, no hurry.'  FYI, the c-shell
works the same way when you "&" something.

> Meaning, that if I have a compile running in the foreground, and an
> ED in the background, the compile gets priority over the ED.

Maybe you should rethink your application!  Why not edit in the
foreground and compile in the background?

..Bob
-- 
UUCP: wanginst!ulowell!page	Bob Page
ARPA: page@ulowell.CSNET 	U of Lowell CS Dept
VOX:  +1 617 452 5000 x2233	Lowell MA 01854 USA

acs@amdahl (04/25/86)

In article <4@intelca.UUCP> cem@intelca.UUCP (Chuck McManis) writes:

> 
> Datta T Miruke writes :
> > 
> >  1. the ^S feature to stop the flow does seem to work when 'typ'ing some file,
> >     but ^Q does not, rather it takes a return key to restart the flow. Is this
> >     consistent?
> 
> I haven't tried porting anything but I do know the answer to the first one :
> 
> Use the right (Menu) mouse button to stop output. (Press and hold to stop
> release to continue) It seems anything you type will stop the output but
> it also gets fed into the AmigaDOS typeahead buffer so after the file 
> prints you usually get a bunch of "Unknown Command" prompts.
> 
I don't know what the developer's *did* but this is how things appear (to
me) to operate in the CLI "window":
  *  Any keyboard activity will stop output.
  *  Any activity which would return the cursor to the left-most edge of
     the screen will resume output.
In other words, if you hit the space bar output will stop.  If you hit the
space bar 2 more times then a backspaces *or* a carriage-return *or* ^X
will resume output.  If you *don't* use the CR key, the CLI will not
remember ever seeing what you've typed (i.e. those spaces and their ^X or
backspaces will disappear).
-- 
Tony Sumrall                    ...!{ihnp4,hplabs,seismo,sun}!amdahl!acs

[ Opinions expressed herein are the author's and should not be construed
  to reflect the views of Amdahl Corp. ]

sgt%alice@alice.UUCP (04/25/86)

>From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
>	That IDIOT *!#@$% RUN command sets the process priority of the 
>process it's running to -5!!!! Meaning, that if I have a compile running in
>the foreground, and an ED in the background, the compile gets priority over
>the ED.  So, when the compile stops going to disk and goes into it's "do nasty
>calculations all in memory", the editor stops working until the compile is
>done.
>	My question is..... how can we fix it.  More importantly, I'm asking
>the Amiga people to fix it in upcomming versions ...  the RUN command should
>set the priority to ZERO... and not make any assumptions about the process
>it's running (the current assumption being that any process in the background
>is not as important as one in the foreground).

It seems to me that since the scheduler handles priorities this
way that it severly limits the usefulness of having priorities at all.
For most of the situations I would use, there would seem to be
essentialy only low, medium, and high, with little use for more
levels.

A better fix would be to alter the scheduler so that low-priority
processes still get some time.
Then, you could pick the priorities so that the compiler was fast enough
to satisfy you, and let the editor crawl along, or whatever.
When there is a big difference in the priority numbers, Nearly all
of the time could go the high-priority one like it does now, so you'd
have the best of both worlds.

If the fix Matt sugests is implemented, lets keep the old RUN
and rename it NICE.

bobp@amiga (04/26/86)

TITLE:  Scroll control under CLI

This is not ^S/^Q or anything like it.

Think of it as "clean type-ahead".

Basically, anytime the CLI input buffer is non-empty, it stops sending
lines to the screen.  This keeps the echoing of your characters from
being mixed with whatever's being written to the screen.

Thus when you type a few characters, scrolling stops.  If you backspace
back over those characters, scrolling restarts.  Since the CLI treats
^X as a "line-kill" character, typing ^X clears the input buffer and
allows scrolling to continue.  In addition, typing a CR empties the input
buffer and allows scrolling to continue.  Typing a CR also has the effect
of having the CLI record whatever you have typed as "type-ahead" which
will be acted upon as soon as the CLI finishes whatever it is currently
doing.

The CLI treats a typed ^S as just another input character.  Thus if
you type one scrolling stops.

The CLI treats a typed ^Q as just another input character ALSO.  Thus if
you type one scrolling stops (or stays stopped).

Personally, I use, Space and Backspace as my "scroll control" characters.
Others here use different combos.

As pointed out by someone else, you can also use the mouse buttons to
lock the CLI window temporarily which has the effect of stopping
scrolling as well.

cc1@ucla-cs (04/30/86)

There is one very major bug with run setting a lower priority. On unix,
this is no problem as
A. Background jobs by default get no terminal input
B. Unix has a scheduler that adjusts priorities.

BOTH of these assumptions FAIL on the amiga.

I recently had to change my startup-script to 'run loadwb' just so that
the 'run execute' command i have in there starts up competitive jobs.

IF you can get newcli to take a command script THEN I will agree that
run should set a lower priority. BUT THERE IS NO WAY (Please, please,
correct me if I'm wrong!!!) to start a second interactive program without
either the workbench or the run command. NEWCLI does not work--I want
a program (specifically, clock, notepad, and a newcli with a custom window)
to be available at the standard priority with no other window on screen.

Unfortunatly, the original window refuses to go away if there is any
'run command' task still active.
			Michael Gersten
-- 
Views expressed here may not be those of the Computer Club, UCLA, or anyone.

acs@amdahl (04/30/86)

Isn't there a pgm to set the priority of a running task?  If there isn't
it seems to me that C-A screwed up by not providing it (not a big screw-up,
just a little one).  Aside from that,  shouldn't the RUN cmd have an
option which allows the user to specify the priority?

Just a thought.
-- 
Tony Sumrall                    ...!{ihnp4,hplabs,seismo,sun}!amdahl!acs

[ Opinions expressed herein are the author's and should not be construed
  to reflect the views of Amdahl Corp. ]

emjej@uokvax.UUCP (05/08/86)

Well, it's finally happened officially.  OS-9/68000 for the Atari 520ST
and 1040 ST was announced and demonstrated at COMDEX in Atlanta last week.
Languages listed as available are Basic09, C, Pascal, Fortran, and COBOL.

According to messages on the CompuServe OS-9 SIG, support is already there
for all ST hardware, including MIDI and CD-ROM ports (the latter not being
*too* surprising in view of the joint Sony-Philips-Microware work on CD-
ROM).  The fellow who saw the beast saw it running with an Atari 20Mbyte
hard disk, with a terminal hung off the RS-232 port.  Basic09/68000, alas,
is still slower than one would like.

People there say that Jack and Sam Tramiel had it demonstrated to them
and were VERY interested and asking questions.  Plans are for a graphics
interface (I would presume VDI, considering Microware's work with GSS)
and a facility whereby one could run TOS as a process under OS-9.

TLM (the folks who did the port) also had their 68010 board for the
International BM PC AT/XT running OS-9 there.

Messages on CIS from folks at MicroTRENDS, the company marketing OS-9
for the 520ST, say that OS-9 for the Amiga should follow shortly.  (One
wonders what the presence of a true multitasking OS on the ST will
do to Amiga sales.)

						James Jones

@hpislx.UUCP (05/08/86)

This message is empty.

robp@amiga.UUCP (Robert A. Peck) (05/13/86)

SYNOPSIS:

This tutorial note deals with the AmigaDOS Execute function, showing in 
detail how its various FileHandle combinations affect the way the function
executes.  It also provides the source for a RUNBACKGROUND command that
you can add to your workbench to start one or more processes from the
s/startup-sequence and still allow the initial CLI to end with the
command line "endcli > NIL:".


SPECIAL NOTES ABOUT EXECUTE REDIRECTION

The Execute function can accept file handles as part of the command, 
where the file handle is used to redirect the stdin and/or stdout.  
There are special rules that Execute uses for this redirection.  The
following specifies the various forms that the Execute function call
can take and their effects.


Execute("something",0,0) 

	means use "*" (that is, the current CLI window) for output.  
	There is NO input expected for stdin.  This form crashes if 
	used under Workbench because there is NO WINDOW to which the 
	output can be directed!  The "something" string can include
	the redirection commands (< and >).  If you specify no
	redirection commands, the string will literally be interpreted
	as though you asked for the function:

		Execute("something > * ",0,0);

	which says "use the current window for output".  Since workbench
	itself has no current window of its own (its process simply has
	no window assigned), the function cannot terminate correctly.

	When you perform the Execute function with this calling sequence,
	it calls the RUN command, which, in turn, uses CreateProc()
	to load the code for the something you wish to run.   This
	code runs as a child of the CLI and the CLI must hang around 
	until the child finishes.  Likewise it also means that the 
	Execute command will not finish until the child exits.

	If you call Execute as:

		Execute("RUN something",0,0);

	you are asking the system to spawn a new CLI process that can
	handle the child process on its own, thereby seeming to free
	the originating CLI from handling the process, and control
	returns to the originating CLI immediately after RUN begins
	to operate.  HOWEVER, even though you've called RUN, the 
	originating CLI still may not be able to "endcli > NIL:" itself,
	because  "something" inherits the stdout (*) from the calling process.
	
	This effectively prevents the originating CLI from going away until 
	the user-count of its stdout output handle has gone to zero,  since 
	that process has become a user of the stdout (*).  If EITHER ONE of 
	the file- handles is a 0, the user-count for * is incremented, 
	regardless of whether the program uses stdin or stdout at all.  
	This happens since Execute cannot tell what will be in the 
	execute-string.

	Thus, the originating CLI must hang around if either of the handles
	is zero, just to be sure the input and output paths are available
	if needed.  See Execute("something", nilfh, nilfh) for a way
	around this.


Execute("something",0,fout)

	means use fout (a valid file handle) for output.  There is NO input 
	expected from stdin, although the current CLI window (*) is still
	marked as having one more user.

	The FileHandle fout is not closed for you once Execute has finished.  
	You must close fout yourself.

	This form of the function works either under Workbench or CLI,
	as long as fout is valid.  The "something" can ALWAYS be a command that
	includes both < or > redirection.  The output redirection will be
	utilized for error messages from the CLI if the comand-string 
	encounters an error.   

		
Execute("something",fin,fout) 

	Means do "something", then continue to read commands from "fin".  
	The "something" can just as easily be specified as "" (the null 
	string), which means do nothing, then continue to read commands from 
	the file whose handle is "fin".  Again, you'll have to close fin 
	yourself.

	Control returns when the CLI finishes "something".   Anything 
	specified in fin will be done simultaneously with your own
	task that now is free to run.  (The CLI has done "something",
	and is now free to go on to do something else, while the execute
	process continues to read fin.)

	When fin is an interactive input stream (See IsInteractive()),
	the fin handle becomes the handle that you would get
	if you opened "*".   This means that you have asked the
	system to create a new interactive CLI process, with
	prompts and so on.   Since a CLI process is now a user of
	"*", the window cannot be made to go away until you issue an
	explicit ENDCLI command.  

	It also means that the caller of this form of Execute will NOT
	regain control until the CLI completes its task.  Because fin 
	it is an interactive process, it always has some input pending;
	thus it cannot be finished with its job until the input actually
	ends the CLI.  So the caller will go to sleep waiting for the
	interactive CLI to end. 


Execute("something", fin, (fout = 0))
	
	FileHandle fout should normally be a file handle specifying some output 
	such as a con: window or a file.  There is, however, one very special 
	case, which is when fout is 0.  This means, as described earlier,
	use "*" as the output.  

	Note that in this special case,  fin MUST be a console handler 
	stream (CON:, RAW:, or "*").  Additionally, if you want to 
	recognize an end-of-file condition on the input, you'll have 
	to use only CON: windows.  CON: windows translate CTRL-\ into 
	an end-of-file;  RAW: windows, on the other hand, pass on the 
	numeric value of this key combination without treating it as EOF.


Execute("something_with_no_stdin_or_stdout", nilfh, nilfh)

	Here, "nilfh" is a file handle resulting from a call to Open
	with a filename of NIL:, as:

		struct FileHandle *nilfh;

		nilfh = Open("NIL:",MODE_NEWFILE);

	Several developers and users have expressed an interest
	in being able to start background processes using the Workbench
	startup script (s/startup-sequence).  An example would be to start
	things such as the CLOCK or something else, then end up on the 
	Workbench without the originating CLI having to hang around for 
	the user to close down. 

	If you want the originating CLI to go away, you must somehow
	prevent any process started by that CLI from opening "*"
	for either input or output as mentioned above.   

	Within the "something..." string, you must spawn an independent
	CLI process.  Additionally the independent process must have its own
	I/O restricted so that it does not in any way depend on or
	attempt to communicate with the originating CLI.  Here, then,
	is PART of the something-string:

		RUN >NIL: <NIL: <rest_of_string>

	This starts an independent process.

	The rest_of_string can contain the command and its parameters.
	But be aware that if your command uses the standard startup sequence,
	it still needs to open its stdin and stdout file handles.  You'll
	need to assure that a proper file handle is actually provided for
	stdin and stdout, so the rest of the string should look like this:

	rest_of_string = "MyCommand >NIL: <NIL: Parm1 Parm2 Parm3 etc";

	
	Thus, the complete Execute command string appropriate to letting
	the originating CLI close down and leave the CLOCK open on the 
	Workbench is to run a program such is listed below.  Note, however, 
	that the file handle to NIL:, dynamically allocated by this program, 
	must hang around "forever" until the next system reset.  It has to be 
	dynamically allocated, since you want this program and its calling 
	CLI to die and leave the CLOCK and Workbench active. 


/* runclock.c */

/* Author:  Rob Peck.  5/9/86 */

#include "exec/types.h"
#include "exec/memory.h"
#include "libraries/dosextens.h"

extern struct FileHandle *Open();

main()
{
	LONG success;
	struct FileHandle *nilfh;
	nilfh = (struct FileHandle *)
		AllocMem(sizeof(struct FileHandle),MEMF_CLEAR | MEMF_PUBLIC);

	success = Execute("RUN >NIL: <NIL: CLOCK >NIL: <NIL:",nilfh,nilfh);	
	if(success)
	{
	    printf("Started CLOCK as a separate process\n");
	}
	else
	{
	    FreeMem(nilfh, sizeof(struct FileHandle));
	}
	/* Notice that if the program succeeds, nobody ever frees this mem */
}


	To try this program, your startup-sequence should contain
	at least the following lines:

	    LOADWB
	    RUNCLOCK
	    ENDCLI > NIL:

	Notice that this program does NOT close the "nilfh", that is,
	the file handle obtained by opening NIL:.   This will tie up
	a small block of memory somewhere in the system until the next
	boot, unless someone spawns a process that keeps track of when
	the CLOCK tool exits, then finally frees this file handle.  But
	this piece of memory is probably not too high a price to pay
	to obtain the functionality people have requested. 	
	   

        Here is a general purpose implementation of the above technique,
	allowing you to run a named process "in the background".  It
	includes a delay parameter to minimize disk thrashing among
	sequentially loaded processes.  It is a bit more complicated
	in that we've installed the appropriate error handling. 

	DISCLAIMER:

	This program is provided as a service to the programmer
        community to demonstrate one or more features of the Amiga
        personal computer.  These code samples may be freely used
        for commercial or noncommercial purposes.

        Commodore Electronics, Ltd ("Commodore") makes no
        warranties, either expressed or implied, with respect
        to the program described herein, its quality, performance,
        merchantability, or fitness for any particular purpose.
        This program is provided "as is" and the entire risk
        as to its quality and performance is with the user.

	(Other standard disclaimers apply)

/* 

--------------
runbackground.c  
---------------

SUMMARY:  A Workbench Disk can be used to autostart an application
	  through the use of the startup script and close the startup CLI.


Users have commented that it is not possible to start a process going 
from the startup script and then cause the initial CLI to go away.   
Here is the solution to that problem, named appropriately:

	RUNBACKGROUND

which starts and runs a background task.  This does indeed allow you to
create a startup script that will set up your workbench running any
programs you might wish, removing the initial CLI in the process.

Your s/startup-sequence can contain lines such as the following:

	RUNBACKGROUND -3 clock
	RUNBACKGROUND utilities/calculator
	RUNBACKGROUND -5 utilities/notepad

where RUNBACKGROUND is the command and the second parameter is the filename
which may be preceded by a flag-variable that specifies an optional delay 
time.  The delay can be from 0 to 9, for the number of seconds that 
the startup script should sleep while allowing the background task to 
load and start.  I've put that in to minimize thrashing of the disk as it
tryies to load several projects at once.


LIMITATIONS:

    The program that you run cannot require any input from an interactive
    CLI that starts it.    Additionally, you cannot specify any file 
    redirection in the command line since this program provides the
    redirection for you already.  If you need to use redirection for
    your command, you can modify the source code where shown, thus
    allowing the redirection to become one of the parameters passed
    through to your program.

    RUNBACKGROUND does pass your command line parameters to the program
    you wish to start, but limits the total length of your command
    string to 227 (255 minus the 28 characters for "RUN >NIL: <NIL: " 
    preceding your own file pathname and ">NIL: < NIL: " following it.)


LINKING INFORMATION:

    (Amiga/Lattice C)	use -v option for pass 2   (lc2 -v filename.q)
			to disable stack checking code installation.
			(stack checking code sometimes is incorrect).

    FROM lib:Astartup.obj runbackground.o
    TO runbackground
    LIBRARY lib:amiga.lib, lib:lc.lib

    ****************************  NOTE:  ********************************
    If you use Lstartup.obj, it won't let the startup CLI go away. This is
    because the source code for Lstartup.asm either opens its own window 
    or uses an existing CLI window (Open("*",....)), so that it has some 
    guaranteed place to put the output.   Astartup.obj does not do this.
    *********************************************************************

Hope this helps.


robp.
*/

/* runbackground.c */
/* Author:  Rob Peck.  5/9/86 */


#include "exec/types.h"
#include "exec/memory.h"
#include "libraries/dosextens.h"

extern struct FileHandle *Open();
extern struct FileLock *Lock();

main(argc, argv)
int argc;
char *argv[];
{	
    LONG success, delaywillbe;
    UBYTE commandstring[255];
    char *test, *filename;
    LONG fromparm;
    struct FileInfoBlock *fib;
    struct FileHandle *nilfh;	/* NOTE: will hang around until next reset */
    struct FileLock *lock;
    
    fib = NULL;			/* No file info block so far. */
    delaywillbe = 1;

    if(argc < 2 )
    {
usage:
    printf("Usage: RUNBACKGROUND [ -<loaddelay>] <name> [<parm(s)>]\n");
    printf("          where optional loaddelay is 0-9,\n");
    printf("          specified in seconds for the CLI\n");
    printf("          to sleep, waiting for task to load\n");
    printf("          (minimizes inter-task disk-thrashing)\n");
    if(fib) FreeMem(fib, sizeof(struct FileInfoBlock));
    exit(0);
    }

    /* See if there is a delay parameter present */

    test = argv[1];

    if(*test++ == '-')
    {
	filename = argv[2];	/* argv[1] is delay so argv[2] is file  */
	fromparm = 3;		/* Copy parms from 3 to end  		*/

	if(*test >= '0' && *test <= '9')
	{
	    delaywillbe = 1 + (50 * (*test - '0')); 
	}
	if (argc < 3) goto usage; /* Only a delay, and no filename!! */

	argc--;		/* one less parm to copy */
    }
    else
    {
	filename = argv[1];
	fromparm = 2;		/* Copy parms from 2 to end 		*/
    }

    /* Now see if the file exists!  If not, it can crash the background
     * CLI and take the system along with it.
     */
    lock = Lock(filename,ACCESS_READ); 
    if(!lock)
    {
	test = filename;
	if(*test == '?') goto usage;
	else
	{
	    printf("%ls: Command not found\n",filename);
	    goto usage;
	}
    }
    else
    {
	/* If file exists, it better be a file and not a directory */

	/* Unfortunately, it is difficult to tell if it is an executable
	 * file.  If not executable, we'll still get blown out of the
	 * water, but that is up to the user to do it right!
	 */

	fib =  (struct FileInfoBlock *)
        	AllocMem(sizeof(struct FileInfoBlock),MEMF_CLEAR);
	if(!fib)
	{
	    UnLock(lock);
	    printf("Ran out of memory!\n");
	    exit(0);
	}
	else
	{
	    success = Examine(lock,fib);
	    if(fib->fib_DirEntryType > 0) 	/* its a directory!! */
	    {
		printf("%ls is a directory, not a file!\n",filename);
		goto usage;
	    }
	}
   	FreeMem(fib, sizeof(struct FileInfoBlock));
	UnLock(lock);
    }
 
    nilfh = Open("NIL:",MODE_NEWFILE); /* will always succeed */

    strcpy( &commandstring[0], "RUN >NIL: <NIL: " );
    strcat( &commandstring[0], filename);  

    /* REMOVE THIS NEXT LINE IF YOU WANT TO INCLUDE REDIRECTION IN
     * THE COMMAND LINE FOR RUNBACKGROUND.   (The line was installed
     * to assure that something like "RUNBACKGROUND date ?" would
     * not crash the system.  "Date ?" is expecting to have an interactive
     * CLI, and unless it is specifically told to direct its output to nil:
     * it causes a crash.  If the next line is removed, and you are careful
     * about putting only NON-interactive commands in the command line,
     * everything should be ok.  Notice that if you do not specify a 
     * non-interactive file handle (named_disk_file or NIL:) for your
     * program, it may still prevent the originating CLI from going away
     * until your program ends.  Also note that specifying two instances 
     * of the same redirection (">somewhere" or "<somewhere") for a 
     * background task crashes.
     */

    strcat( &commandstring[0], " >NIL: <NIL: ");  /* stop interactive crash */ 

    argc--;

    while(--argc > 0)	/* Rebuild parameter string for passing it on */
    {
	strcat( &commandstring[0], " ");	/* add a blank */
	strcat( &commandstring[0], argv[fromparm++]);  
    }

    success = Execute( &commandstring[0] , nilfh, nilfh);

    /* The full command passed to Execute now looks like this:
     *
     *	"RUN >NIL: <NIL: FILENAME >NIL: <NIL: PARAMETER(s)"
     *
     */

    if(success)
    {
	printf("Started %ls as a background task\n",filename);

	/* Execute, in this case, returns IMMEDIATELY.  The process
	 * that is loading the code that is to be run as a background
	 * process is working to get everything in and started.  
	 */
    }
    /* Now, to minimize thrashing between tasks, lets put this task to 
     * sleep so that the each task actually gets a chance to load.
     */
    Delay(delaywillbe);
}

strcpy( to, from )
register char *to, *from;
{
   do {
   	*to++ = *from;
   } while( *from++ );
}
strcat( to, from )
register char *to, *from;
{
    while( *to ) to++;
    strcpy( to, from );
}

bees@infoswx.UUCP (05/19/86)

Why does the sidecar have a 8088 in it?  Geez, how old tech.
I might have considered it had it been a 286 (AT compatible),
or even a fast 8086!  ...  but an 8088!!!  Come on....

Ray Davis

aglew@ccvaxa.UUCP (05/20/86)

>/* Written 12:12 pm  May  9, 1986 by bruceb@amiga.UUCP */
>
>>I don't know of any DOS that doesn't allow unlimited directory sizes, [...]
>	Apple-][ DOS (not Prodos), TRS-DOS, CP/M, MS-DOS (setable, but finite)
						  ^^^^^^
>--Bruce Barrett

Only the root directory on MS-DOS has a limited number of files (settable
in the Media Parameter Block).

Subdirectories are structured like any other files, and can be any length
that while fit on your disk. Not that you'd like to wait for the sequential
scans, though - I once improved compilation time 30% on a large PC DOS
system by splitting the project up into 4 subdirectories, and sorting the
entries in the directory by frequency of use (put stdio.h first!).
I suspect that these abysmal search times are what prompted Metacomco to try
hashed directories - that, and the ever-present desire to try something neat
out.

Incidentally, MS-DOS files are linear linked lists, so seeking from the
start of a file can involve `looking' at all the blocks - except that this
is done in one fixed size map.

dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (05/22/86)

	The 8088 is cheep.  It only has an 8 bit bus so the support 
hardware is cheep.  There are far more programs for the IBM-PC (/XT) then
there are for the AT (and the XT uses an 8088).  I would go with an 8088
for those reasons also. 

	But then again, since I have a choice, I think I'll stick with
a 68xxx.  My real question is, why didn't Amiga go with a 68020?

						-Matt
	

randy@cbmvax.UUCP (05/23/86)

In article <45100045@infoswx> bees@infoswx.UUCP writes:
>
>Why does the sidecar have a 8088 in it?  Geez, how old tech.
>I might have considered it had it been a 286 (AT compatible),
>or even a fast 8086!  ...  but an 8088!!!  Come on....
>
	Why not? The best, and easiest way to insure compatability
is to use the same processor. Changing processors would mean
a different crystal freq., ala different timing. 

	Everyone has their criteria for what makes a PC 'IBM
compatable'. In order to compete against IBM and other clones
it makes sense to make it better. The purpose of the SideCar is
provide added functionality to the Amiga. As an add-on, it would
be silly to make it any more expensive than necessary. It serves
its intended purpose as is.

	Who knows, if SideCar does well maybe there will be
a SideCar-XT, or SideCar-AT :-).


-- 
     + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 
Randy Weiner -- Commodore Business Machines <<Amiga Technical Support>>
		uucp: {ihnp4|seismo|caip}!cbmvax!randy
		arpa: cbmvax!randy@seismo
		(or)  randy@cbmvax.UUCP@{seismo | harvard}
		TEL:  215-431-9180

jec@iuvax.UUCP (05/26/86)

	I think the reason Amiga didn't go with the 68020 is a very
good one: price.  I'm glad they went with the 68000 and saved me big
bucks.  When I need a 68020 (and can afford one), I'll buy the CSA
board.

	By the way, I read in EDN that Motorola has their 68851 MMU
out now.  This is the replacement for the 68451 MMU (really yucko chip)
and supports demand paging virtual memory.  Any chance CSA will be
including this in one of there boards in the future?  Hope so, makes a
UNIX port all that much more possible.


--
James E. Conley			Usenet: {ihnp4,pur-ee,purdue}!iuvax!jec
I.U. Dept. of Computer Science  Phone:  (812) 335-9389
021-C Lindley Hall			(812) 333-6702 [Home]
Bloomington, IN. 47405

emjej@uokvax.UUCP (05/28/86)

/* Written 1:48 pm May 8, 1986 by rb@ccird1.UUCP in net.micro.amiga */
My main reason for suggesting that OS-9 would be the FIRST contender is that
it is already available, and people are doing the ports now.
/* End of text from net.micro.amiga */

As a matter of fact, MicroTRENDS in Schaumburg IL is at work on the port
to the Macintosh even as I (figuratively) speak, and I've talked to a fellow
who has seen TLM's Amiga port running.

						James Jones

farmer@ico (05/29/86)

>And is the net interested in a Robotron-like game?

>Nicko
You bet.  I was so impresed by the game that I went out and bought the full
sized arcade game.  It appears to have two 68ks in it.  I wanted to try to
make a game that looks like it, but have had little luck with animation so
far.

rj@amiga.UUCP (Robert J. Mical) (06/04/86)

Robotron on the Amiga!  It is do-able.  Needs a special type of imagery.
I think I know how to pull it off.  Now *that* would be a fun project.

I really like Robotron.  Joust too.  I came from Williams Electronics, 
before I joined Amiga.  I'm a Williams freak.  I think they have made most 
of the best video games.

Imagine my delight:  at Williams, we had a room full of coin-op video games 
all set for "FREE PLAY" all day and all night long.  It was a cool place 
to work.  It was a good job.

I think that Atarisoft has the rights to the Williams games.  Atari had
the rights to Marble Madness (I think) and they released these to EA,
including a version on the Amiga.  Maybe Atarisoft would put income over
Atari's competition with the Amiga.

Someone should ask Atarisoft about this.  I'd be willing to throw in on
such a project, you betcha!

RJ Mical >:-{)*

=============================================================================
=RJ Mical=
 Suite 123
 999C Edgewater Blvd.
 Foster City, CA   94404

 (415) 573-0497
=============================================================================

bees@infoswx.UUCP (06/08/86)

>	The 8088 is cheep.  It only has an 8 bit bus so the support 
>hardware is cheep.  There are far more programs for the IBM-PC (/XT) then
>there are for the AT (and the XT uses an 8088).  I would go with an 8088
>for those reasons also. 

I agree it is cheaper, but the 8086 is upward compatible with the 8088.
Look at the Olivetti box (AT&T 6300, Xerox 606x), it has a faster 8086,
but is PC compatible... at least 99.9999999%!

Ray

haddock@ti-csl (06/08/86)

Personally, I'd like to see `ChipWits' on the Amiga.  Should be
fairly "easy" to do.  The user interface would be the most time
consuming portion of the programming.

				-Rusty-
================================================================
*hardcopy*		*electr{onic, ic}*
Rusty Haddock		ARPA:  Haddock%TI-CSL@CSNET-RELAY.ARPA
POB 226015 M/S 238	CSNET: Haddock@TI-CSL
Texas Instruments Inc.	USENET: {ut-sally,convex!smu,texsun}!ti-csl!haddock
Dallas, Texas 75266	VOICE: (214) 995-0330

bees@infoswx.UUCP (06/10/86)

  >I meant just that.  I am not a fan of pull-down menus, where you have to
  >keep your finger on the mouse button, etc.  What I'd rather see is:
Me either, I agree!

  >User brings the mouse to some area on the display and clicks the 'menu'
  >button.  Instead of a row of items across the top of the screen, a
  >menu structure appears, centered under the position of the mouse.
  >From there, user can do whatever s/he wants (including ignoring the
  >menu).  When the time is right, the user can click the 'select'
  >button over the menu item desired.  If that creates a sub-menu, then
  >that's what happens ... again, centered under the current mouse pointer.
  >when the final selection (last in the submenus or whatever) is
  >selected, the menu goes away.
  >
  >If the user decided that the 'menu' button wasn't what was wanted,
  >just clicking the 'menu' button again clears the menu.
  >[...]	Bob Page, U of Lowell CS Dept

Your description of a menu button popping up menus where the mouse is
sounds a bit like the way the 5620 terminal (AT&T Teletype, also know
as a Blit) works.  You press the mouse key while in an active window,
and it's high level menu pops up.  Right under the mouse cursor, unless
you are at the bottom of the screen.  If you release the mouse button
without selecting an item, the menu goes away.  Sub-menus can appear
either when items in the first menu are selected or when they are
pointed at.  Menus can be graphic as well as text.

The diff here is in the number of button strokes.  I want as few as
possible.  It makes more sense to press the menu button and let its
release be either a select or ignore, rather than having to press the
menu button, press it again to select something, then press a select or
forget it spot.

Ray Davis

farmer@ico (06/24/86)

>2) I seem to be having trouble when swapping disks (I only have one drive),
>in getting the system to recognize that the new disk is different.  It is a
>royal pain having to reboot everytime I change applications.  Is there
>something I am missing out on?  (Ex.  I boot on my workbench disk, do some
>system things, and decide to play on Dpaint awhile.  When I pop out
>workbench and put in the Dpaint disk the system flashes a requestor on the
>screen for the workbench disk.)
It is looking on c: to find programs.  If you reasign c: to "Dpaint:c" it
will look there.  It also has assigns for libs, and other things.  Type
assign to find out what all is assigned.

>3) How do I get my preferences onto the Dpaint disk?  I don't think this is
>all that crucial, but I don't like the original arrow pointer.  So I drew
>my own (after all, thats what preferences is for right?)  The only problem
>is that Dpaint uses the pointer that I hate; and I want my own!!
There is a preferences on the Dpaint disk.  The manual for Dpaint says to
not write on the disk, except to use preferences.  Whatever you do, don't
write the program disk.

>If any of these questions are in the manual, please give me page nos. or
>somthing, any help is much appreciated.
I don't have my manuals here.

>                                please respond to
>                                ihnp4!okstate!uokvax!lorne
Sorry, I can't mail to this address.

aglew@ccvaxa.UUCP (07/01/86)

I've noticed a lot of people talking about shorts and ints and longs,
and whether an int should be 16 or 32 bits, and what the size of a 
short should be.

I've also noticed somebody say that he always uses shorts or longs,
because they always have a definite size. SHAME! Where is it written
in stone that shorts are 16 bits and longs are 32 bits, and ints one
or the other? What if you have a machine that supports 64 bit integers
in hardware - wouldn't it be natural to have shorts 16 bits, ints 32 bits,
and longs 64 bits? Sure it would be! - but you can't do the sensible
thing because of all sorts of brain-damaged non-portable programs that
assume an int is the same thing as a long, 32 bits worth. Which leads
to abominations like long longs, etc.

This is what is going to kill C - not Ada, just the accumulation of
implicit machine dependencies.

Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms

dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (07/04/86)

	I Believe K & R define shorts and longs to be not less than 16 and
32 bits respectively.

			-Matt

rico@oscvax.UUCP (07/07/86)

In article <8607040632.AA22409@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU.UUCP writes:
>
>	I Believe K & R define shorts and longs to be not less than 16 and
>32 bits respectively.
>
>			-Matt

I don't have my K&R with me right now to check but I beleive that the
above is incorrect.  I think it's

	int >= 16 bits

	# of bits in a short <= # of bits in an int
	# of bits in a long  >= # of bits in an int

That's all she wrote... meaning  you could have a system with 
	ints = shorts = longs = 16 bits  (yecch!)

I think char's are "the smallest addressable unit large enough to hold a
character" which is almost always a "byte" (I think its bigger on Honeywells).
I don't know if there are any guarantees about this...

Like I said, I'm not sure about this.  This should probably be in net.lang.c

	-Rico

stroyan@hpfcdc.HP.COM (Mike Stroyan) (07/07/86)

> 	I Believe K & R define shorts and longs to be not less than 16 and
> 32 bits respectively.
> 
> 			-Matt

   And I believe that robots are stealing my luggage.

   While K & R does list several machine dependent examples which obey
that rule, it makes no such general claim.  It does state that -
"About all you should count on is that short is no longer than long."

Mike Stroyan, [ihnp4!]hpfcla!stroyan

chapman@pavepaws.berkeley.edu (Brent Chapman) (07/08/86)

In article <430@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes:
>In article <8607040632.AA22409@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU.UUCP writes:
>>	I Believe K & R define shorts and longs to be not less than 16 and
>>32 bits respectively.
>>
>>			-Matt
>
>I don't have my K&R with me right now to check but I beleive that the
>above is incorrect.  I think it's
>
>	int >= 16 bits
>
>	# of bits in a short <= # of bits in an int
>	# of bits in a long  >= # of bits in an int
>
>That's all she wrote... meaning  you could have a system with 
>	ints = shorts = longs = 16 bits  (yecch!)
>
>Like I said, I'm not sure about this.  This should probably be in net.lang.c
>
>	-Rico

K&R specificly does NOT specify the "minimum size" in bits of any type
(including char).  What it says is (from pages 182-183):

	Up to three sizes of integer, declared short int, int, and
	long int, are available.  Longer integers provide no less
	storage than shorter ones, but the implementation may make
	either short integers, or long integers, or both, equivalent
	to plain integers.  "Plain" integers have the natural size
	suggested by the host machine architecture; the other sizes
	are provided to meet special needs.


Brent

--

Brent Chapman
chapman@pavepaws.berkeley.edu
ucbvax!pavepaws!chapman

TANSTAAFL!  (There Ain't No Such Thing As A Free Lunch!)

mwm@eris.berkeley.edu (07/08/86)

In article <8607040632.AA22409@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes:
>	I Believe K & R define shorts and longs to be not less than 16 and
>32 bits respectively.

Sorry, Matt, but K&R defines shorts to be no longer than ints, and
longs to be no shorter than ints. I once worked on a "K&R" compiler
with 18 bit ints, longs and shorts (I forget, but I think bytes were
18 bits long also!).

The ANSI standards adds the restrictions you speak of - shorts at
least 16 bits, and longs at least 32 bits. This implies that ints are
also at least 16 bits.

Of course, the standard only tells you how to choose the smallest
portable size to hold a value. It doesn't tell you how to choose the
fastest. That should be ints, but...

	<mike

jdg@elmgate.UUCP (Jeff Gortatowsky) (07/09/86)

In article <26600033@ccvaxa>, aglew@ccvaxa.UUCP writes:
> 
> I've noticed a lot of people talking about shorts and ints and longs,
> and whether an int should be 16 or 32 bits, and what the size of a 
> short should be.
> 
> I've also noticed somebody say that he always uses shorts or longs,
> because they always have a definite size. SHAME! Where is it written
If it's my message you refer to I guess:
  A: I mis-stated what I meant. On the Amiga shorts are 16 bit and longs
are 32 (yes It's not cast in concrete) but it makes sense and _WORKS_.
  B: As I state below this assumption is QUITE portable to larger data size
machines.
  C: When I choose a data type I choose the smallest that will hold the
expected value of the data. That means shorts for data <65536.  It's
faster and portable (Blast you megamax!) to 16 bit CPUS or >.
> in stone that shorts are 16 bits and longs are 32 bits, and ints one
> or the other? What if you have a machine that supports 64 bit integers
> in hardware - wouldn't it be natural to have shorts 16 bits, ints 32 bits,
> and longs 64 bits? Sure it would be! - but you can't do the sensible
> thing because of all sorts of brain-damaged non-portable programs that
> assume an int is the same thing as a long, 32 bits worth. Which leads
> to abominations like long longs, etc.
> 
> This is what is going to kill C - not Ada, just the accumulation of
> implicit machine dependencies.
> 
> Andy "Krazy" Glew. Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!aglew
> 1101 E. University, Urbana, IL 61801    ARPAnet: aglew@gswd-vms


I don't know if it was me your refering to as using longs and shorts only,
but thats about what I do.  Your point about 64 bit machines doesn't apply.
I don't assume anything except that ints are non-portable, period. If
shorts are 16 or 32 bits on a 64 bit machine, my code works. Further on a
restricted bus machines (like 68000 and 68010 or a 64 bit CPU on a 32 bit
bus) my coding practice is a big win. If longs are 32 bits or 64 bits my
code works. Can you say the same for ints? 

I think we are on the same side.  I don't assume anything about the SIZE of
a data type. But I do assume shorts and longs will be upward (size wise)
compatible. 

BTW Longs would(should) be 64 bits, not long longs (gimme a break 8-)). 
double long?
Nah....


-- 
Jeff Gortatowsky       {allegra,seismo}!rochester!kodak!elmgate!jdg
Eastman Kodak Company  
<Kodak won't be responsible for the above comments, only those below>

droch@ihlpa.UUCP (Kraft) (07/10/86)

> In article <8607040632.AA22409@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU.UUCP writes:
> >	I Believe K & R define shorts and longs to be not less than 16 and
> >32 bits respectively.
> >			-Matt
> 
> I don't have my K&R with me right now to check but I beleive that the
> above is incorrect.  I think it's
> 
> 	int >= 16 bits
> 
> 	# of bits in a short <= # of bits in an int
> 	# of bits in a long  >= # of bits in an int
> 
> Like I said, I'm not sure about this.  This should probably be in net.lang.c
> 
> 	-Rico

page 34 of The C Programming Language (Kernighan & Ritchie but of
course) states:

	The intent is that short and long should provide
	different lengths of integers where *practical*;
	int will normally reflect the most ``natural''
	size for a particular machine.  As you can see,
	each compiler is free to interpret short and long
	as appropriate for its own hardware.  About all you
	should count on is that short is no longer than long.

					Ciao guys,
					David Roch
					AT&T Bell Labs

You can't get there from here - REM

gregg@okstate.UUCP (07/14/86)

From K&R...

char    a single byte, capable of holding one character
        in the local character set.
int     an integer, typically reflecting the natural size of integers
        on the host machine.

The intent is that short and long should provide different lengths of integers
where practical;  int will normally reflect the most ``natural'' size for a
particular machine.  As you can see, each compiler is free to interpret short
and long as appropriate for its own hardware.  

NOW, READ THIS....

                                               About all you SHOULD count on
is that short is no longer than long.


-----------------------------------------------------------------------------

So, as you can see, it is pretty much up in the air.  There is nothing like
nondeterminant computing...


Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA:  gregg%okstate.csnet@CSNET-RELAY.ARPA  
    or
ARPA:  gregg@A.CS.OKSTATE.EDU

fnf@unisoft.UUCP (07/16/86)

In article <430@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes:
>I think char's are "the smallest addressable unit large enough to hold a
>character" which is almost always a "byte" (I think its bigger on Honeywells).
>I don't know if there are any guarantees about this...

One of the earliest C implementations I experimented with was on a Decsystem-20
and implemented char's as 36 bits...

-Fred

hamilton@uiucuxc.CSO.UIUC.EDU (07/31/86)

>I have been trying to use the StarTerm public-domain terminal emulation
>program available on the Fish disks to talk to _videovax_ via a modem.
>StarTerm dials nicely, but does not seem to pass the Escape ($27)
>character to the screen driver.
>
>I have set up a modified ANSI termcap on _videovax_ following the
>information in the AmigaDOS reference manual (the new version with three
>volumes in one).  What I get on the screen is the character sequences
>that follow the escape, with no evidence that the escape was recognized.
>
>Is there a problem with StarTerm not passing the Escape character to the
>screen driver?  Does StarTerm open some kind of custom window that does
>not perform ANSI terminal emulation?  Is the source to StarTerm available
>so I can look into these questions?

    most of the PD terminal programs i've seen do their own intuition
calls (Text(), etc) rather than use the console.device, so you can
ignore what the amigados manual says.  if the program does any emulation
at all, it's probably partial vt100 or something other than the ansi
emulation the console tries to do.
    not only is starterm not available in source, compuserve has been
getting uppity lately about free distribution of the binary.

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton%uiucuxc@a.cs.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%uiucuxc@uiuc.csnet	Phone:	(217)333-8703

hamilton@uiucuxc.CSO.UIUC.EDU (08/04/86)

/* Written 10:26 am  Aug  1, 1986 by star@fluke.UUCP in uiucuxc:net.micro.amiga */
/* ---------- "VT-100.c by Dave Wecker (posted in" ---------- */
Has anyone worked out this program so that it compiles under Lattice.  The
sources posted to mod.amiga.sources uses an 'definition' include file which
is not available currently in Lattice.
Dave Whitlock
/* End of text from uiucuxc:net.micro.amiga */

    are you referring to "functions.h"?  this file merely defines all the
exec/intuition/amigados function return values.  try compiling without this
#include, and add any definitions needed to squelch lattice complaints.

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton%uiucuxc@a.cs.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%uiucuxc@uiuc.csnet	Phone:	(217)333-8703

danny@convex.UUCP (08/07/86)

[alright, come and eat this]


Now guys, if the only thing you are worried about here is price, I suggest that
you look a little harder.  A local computer store (Mr. Micro) wants $50 for a
box of ten double-sided Sony's.  I get the same box from Soft Warehouse for $20.
Now then, if you still can't find a good deal, look in your favorite magazine
for the mail order house that sells them by the hundred, find some friends...

If you want to do it, do it right.  Don't do something that you'll regret later.


A little wisdom yours for the taking.

Dan Wallach
...!ihnp4!convex!danny

jacobson@uiucuxe.CSO.UIUC.EDU (08/07/86)

Arc is available for download on our BBS locally (a Fido BBS) 
in two versions. The older version is the one that was hunkpaded, it is one
that will not work after August 11 (just set the date back on your system)
then you can also download the newer version of Arc that we have (which is
Arced) and de-Arc it with the old version. The BBS is Hackers Anounymous and
the number is 217-333-8301. Be warned it is busy, it has a file and message
area for Amiga, as well as MS-DOS systems (it is running on a AT with a 20
MEG, by the Universiy) and alot of MS-DOS and locals use it. You may have to
try late at night but if you get on look for the file area for Commodore.
Area 9 I believe. You will find both versions of Arc listed near the end
of the file listing. I hope this helps.
 

jacobson@uiucuxe.CSO.UIUC.EDU (08/07/86)

I went back and checked the name of the old Arc that is padded
so that it will run is just ARC, no extentions. The other file you want is
AMIGO16.ARC. This is the new version of ARC with no date limitations, probably
has docs too. Just use the old ARC on it, and change the date if you use it
after August 11. Hope you can get on the BBS to get it.