[comp.os.minix] more minix ST 1.5.0 ...

figuei@max.sunysb.edu (Francisco Figueirido) (03/02/90)

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

bammi@curie.ces.CWRU.Edu (Jwahar R. Bammi) (03/03/90)

In article <1990Mar2.035305.4169@max.sunysb.edu> figuei@max.sunysb.edu (Francisco Figueirido) writes:

      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 ...
The version of gkernel/library you have has different values for the
constants #defined in <sgtty.h>. The kermit with the gkernel stuff,
assumes and uses facilities provided by Howard Johnsons tty driver.
The St V1.5 driver is totally different, and does'nt provide many of
the facilities. It is totally useless above 2400 baud. With howards
driver and other facilities in gkernel, you can quite comfortably run
kermit at 9600 baud with extended packet sizes.

      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 ...

Not a good idea. Incorporating the screen mods into your present
kernel is fairly trivial (the origonal posting from eric smith gave
the diffs against the normal St kernel).

   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

the gcc .s files are already in the library.

      compared the optimizations in both cases? Another suggestion 

you cant really compare the two. you know the answer already.

      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.

gekernel (will soon) have a blazingly fast console driver. dale
schumaker wrote some very fast scrolling routines for it. of course,
it will support some of the current features such as virtual consoles,
autowrap, loadable fonts etc.
--
--
bang:   {any internet host}!dsrgsun.ces.CWRU.edu!bammi	jwahar r. bammi
domain: bammi@dsrgsun.ces.CWRU.edu
GEnie:	J.Bammi