Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!sbcs!max!figuei
From: figuei@max.sunysb.edu (Francisco Figueirido)
Newsgroups: comp.os.minix
Subject: more minix ST 1.5.0 ...
Keywords: minix, atarist, upgrade
Message-ID: <1990Mar2.035305.4169@max.sunysb.edu>
Date: 2 Mar 90 03:53:05 GMT
Sender: Francisco Figueirido
Reply-To: figuei@max.sunysb.edu (Francisco Figueirido)
Organization: Institute for Theoretical Physics, SUNY at Stony Brook
Lines: 39

Thanks again for the replies to my postings! I have some more
questions and comments: 

1) I have GCC running on ans SGI 4D/220 (2 Mips processors) for
   cross-compiling to Minix. I got the (latest?) libraries from
   dsrgsun.ces.cwru.edu (version 1.36, I believe) and had problems
   at first with the 32 bits stuff, but after recompiling everything
   they work fine ... or seem to. I compiled a RPN calculator (a la
   PostScript, but no graphics for minix ...; if anybody is inte-
   rested I could post the sources) which I had running on the SGI
   (it supports XWindow and LineA for very simple graphics ...)
   and under TOS and it works fine with minix also. I also compiled
   kermit (the gnukernel version, NOT the one distributed with 1.5.0,
   which I haven't yet been able to compile) and it doesn't dump core
   but I get weird errors like not being able to set the correct 
   speed (for example, if I say: set speed 9600, and then look
   at /dev/tty1 with a !stty < /dev/tty1 it reports a speed of 110,
   or some weird number like that). I haven't discover any other
   problems yet ...
2) I once got the sources for the gnukernel but never managed to
   build the kernel. Anyhow, I think 1.5.0 is pretty good! Are there
   plans to put screen support (as /dev/screen did in the gnukernel)
   for some version? That would be good for my graphics program!
   Barring that, does minix relocate the screen ram? If not I guess
   I could write directly to /dev/mem ...
3) Are the diffs for the 1.5.3 (ST) kernel already available? I 
   haven't seen any postings. 
4) I think that it would be a good idea to have the sources 
   (especially the .s files) in GCC format, as it is easier to
   get access to a GCC-cross-compiler than an ACK-one. Has anybody
   compared the optimizations in both cases? Another suggestion 
   is to write some more routines, like scrolling, in assembler,
   or, at least, try to optimize it more (one could have portable
   routines capable of copying one raster line at a time, maybe).
   Scrolling is a little bit slow for the moment.

 Sorry that the article got so long!

	Francisco Figueirido