HDTenEightyP/NetNews huggingface dataset:
From: cct@node_35655.bnr.ca (Charles Calvin Tarlton)
Newsgroups: comp.unix.bsd
Subject: Re: The ultimate 386BSD machine?	(FAQ fodder)
Keywords: 386BSD
Date: 8 Oct 92 13:20:13 GMT
Organization: Bell-Northern Research, Research Triangle Park, NC

I would also like a few questions answered.  I am about to purchase a 486SX-25
system and I would like to be able to run dos and/or unix as well as X.  Is 
there a way to do this without rebooting each time?  I've seen things that will
"simulate" unix and give you most of the functionality, but I don't want that.
As far as hardware goes, are there things to definately be avoided if I'm planning to run Linux or any of these other unix derivatives?  I gather that Diamond Stealth video cards are a no-no for XFree386... True?  Will a generic
SVGA card without a windows accelerator be just as good for X?  
Thanks....


-- 
------------------------------------------------------------------------------
Calvin Tarlton 					
Bell Northern Research
Morrisville, NC
(919) 481-5296
------------------------------------------------------------------------------
Disclaimer:  The opinions expressed are my own and in no way reflect the 
official views or policies of Northern Telecom / Bell Northern Research.
------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: wutcd@chemnitz.guug.de (Joerg Wunsch)
Subject: Re: How to format UNIX floppies under 386BSD
Organization: tu-chemnitz
Date: Wed, 7 Oct 1992 15:31:47 GMT

alan@ulka.zso.dec.com (F. Alan Jones) writes:


>Thanks for the reply Brian.  So, what make/model is the floppy controller
>chip on a stock PC?  When I have that, I can write the manufacturer.  My
>PC is a "street" machine with no docs.  I assume the IBM PC Tech Ref is
>off the shelf and still in print.

It's easy. You can assume that any dos box is kept compatible to ancient
NEC 765 / Intel 8272 chip (nearly the same). For a command description
(very, very short) see the file /sys/i386/isa/ic/nec765.h (the name says
everything). But unlike the one who remarked that formatting will take
heavy i/o access: some years ago i've written a bios for a home-made
CP/M computer. As far as i remember, formatting will take only the
sec#, cyl#, and head# to write into id field, and _one byte_ which the
controller fills into all newly formatted sectors. Usually, the mentioned
numbers are the same as physical head/cylinder number (but they do not
need to be so - e.g. you're formatting a 360K disk within 1.2M drive),
and sectors are numbered 1 thru 15 (or 18). They _really_ start at one,
not zero!
Of course, you'll have to look at the current driver stuff for doing it
(track positioning, sleep until controller told ``seek complete''...).
Btw., i guess the driver should _not_ deal with bad sectors after for-
matting. This is not a problem of low-level format rather than the
high-level formatter (newfs) will have to check it, or you decide to
use any sector-remapping strategy the driver deals with (as done in
bad144) - but as far as i know, 386BSD diskettes won't use this.

If you're really interested, i could email you something more about
the controller. But that'll take me more time (since my info is in
German:-((). For example, you can get the relevant parts of my older
(CP/M) formatter if you'd like it (and if you're familiar with Z80
code).

	Enjoy,
	J"org

ps: A last hint: after making any driver function work, there must
be of course, a simple user interface program to the driver;-)
--
J"org Wunsch, TCD GmbH Dresden, R"ahnitzgasse 18, D-O-8060 Dresden
                                                              \     ~.~. 
	joerg_wunsch%bonnie@hadrian.hrz.tu-chemnitz.de         \   ~  | ~ 
	voice: +49-351-5965 137                                 \    ===
Newsgroups: comp.unix.bsd
Subject: Re: DOS and 386BSD
Supersedes: <92286.094751K390670@ALIJKU11.BITNET>
Organization: Johannes Kepler University Linz - Computing Center
Date: Monday, 12 Oct 1992 10:18:37 CET
From: <K390670@ALIJKU11.BITNET>

My machine is a 486-50 with 212MB Conner CP3204F (IDE) and 543MB Conner
CP3540 (SCSI-2), the latter of which is connected to an Adaptec 1542B.





I have painstakingly followed Terry Lambert's advice about setting the
IDE drive to its "native" parameters and about putting 386BSD (ptntype A5)
*first* on the disk, DOS second.

Besides that I lose all tracks beyond 1023 with this method, install
still fails:
>xxxxxxxxxxxxxxxxxxxx (some info about super-block backups)
>newfs: ioctl (WDINFO): No such process
>newfs: /dev/rwd0a: can't rewrite disk label
>Could not format filesystem. Installation failed.

Any suggestions are highly welcome.

As the 386BSD installation on the *whole* IDE performs flawlessly, I
think the best way to do it anyway is to dedicate the whole IDE to BSD,
to enable BIOS emulation of the Adaptec (which I tried to avoid up till
now), and to install DOS (and, by the way, OS/2 2.0 and Windows NT)
on the SCSI.Besides not losing 50MB of the IDE, switching to and fro
386BSD becomes ridiculously simple:
In the machine's setup, set drive C: to "user defined":
386BSD is run
In the machine's setup, set drive C: to "not installed":
DOS (or Win NT or OS/2 2.0) is run

Any comments on that?

------------------------------------------------------------------------------
Gregor 'Greg' Glawitsch
k390670@alijku11.edvz.uni-linz.ac.at

"Everybody should believe in something - I believe I should have another beer"
------------------------------------------------------------------------------







Newsgroups: comp.unix.bsd
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: 16-colour X server?
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 13 Oct 1992 01:57:35 GMT

Richard Tobin (richard@aiai.ed.ac.uk) wrote:
: Has anyone written / is anyone writing / are there any plans for a
: 16-colour driver for XFree386?  This would be useful for those of us
: with video boards with only 512k and should also be twice as fast as
: the 8-bit version (unless vga is even more brain-dead than it seems).
There is a mono driver called vga2 and a program called X386mono but I
cannot run it.
	Then it will be 8 times faster but you only have 2 colors, black and
white. I used to think that 8-bit is too much but when I run the XFree86, it
is so fast that there is no need to speed it up by 2 time. I'm only using
a non cached 386 25 Mhz without 387.
	In fact 16-bit is the ultimate. There is no need to go any futher.
The 24-bit and 32-bit DACs are wasteful because they do not take into account
human visual perception.
	At least that is what TV textbooks say. Is there any recent work proving
otherwise?

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.unix.bsd
From: grefen@wilbur.uni-mainz.de (Stefan Grefen)
Subject: Re: problems with Julian's SCSI 0.3 beta
Organization: Johannes Gutenberg Universitaet Mainz
Date: Wed, 7 Oct 1992 08:45:35 GMT

Just form looking at it (I haven't time to upgrade to beta3 jet) in
sdgetdisklabel  the line
       if(sd->flags & SDHAVELABEL) return;
should read 
       if(sd->flags & SDHAVELABEL) return(ESUCCESS);
Or am I missing something?
Stefan
-- 
Stefan Grefen   ---   Johannes Gutenberg University Mainz   ---    Germany
Email: grefen@goofy.zdv.uni-mainz.de       ---        Phone:  06131/392415

Newsgroups: comp.unix.bsd
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Problems with Kermit 5a
Organization: Nanyang Technological University - Singapore
X-Newsreader: Tin 1.1 PL4
Date: Wed, 7 Oct 1992 13:40:43 GMT

I'm currently using the kermit supplied in the etcdist. Somehow it just
does not work right. There are various blue characters appearing when
I press return key.
	Is it due to com.c problems?
Sorry if I missed any relevant pathces because ther are just too many
to follow.


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.unix.bsd
From: smm@iedv7.acd.com ( Steve McCoole       )
Subject: Diffs to BSDI Ported Software List 01/02
Organization: Applied Computing Devices, Inc., Terre Haute IN
Date: Tue, 13 Oct 1992 23:41:20 GMT

*** ported.list.01.v2	Thu Sep 24 20:12:46 1992
--- ported.list.01	Tue Oct 13 18:33:05 1992
***************
*** 39,45 ****
  
  ========================================================================
  
!                    BSDI SOFTWARE LIST ( 09-23-92 )
                                     
          Please leave this information at the top of the list.
                                     
--- 39,45 ----
  
  ========================================================================
  
!                    BSDI SOFTWARE LIST ( 10-13-92 )
                                     
          Please leave this information at the top of the list.
                                     
***************
*** 51,57 ****
  ========================================================================
  
  Subject: Section 1 Ported Software
! Date: Wed, 23 Sep 1992 09:00 EST
  
  ========================================================================
  
--- 51,57 ----
  ========================================================================
  
  Subject: Section 1 Ported Software
! Date: Tue, 13 Oct 1992 09:00 EST
  
  ========================================================================
  
***************
*** 744,750 ****
  ========================================================================
  
  Subject: Section 2.  Software that works with minimal/no effort.
! Date: Wed, 23 Sep 1992 09:00 EST
  
  ========================================================================
  
--- 744,750 ----
  ========================================================================
  
  Subject: Section 2.  Software that works with minimal/no effort.
! Date: Tue, 13 Oct 1992 09:00 EST
  
  ========================================================================
  
***************
*** 780,782 ****
--- 780,790 ----
          planet  - Generate imaginary worlds
          xpostit - Post-It(tm) Notes on X
  -----
+ mgfrank@avernus.com (Marc G. Frank)
+ The curses gopher client available in gopher1.03.tar.Z from ftp.uu.net
+ in a directory similar to pub/networking/info-services/gopher compiles
+ out of the box under BSDI beta 0.3.3.  I didn't try compiling the
+ server.
+ -----
+ 
+ 
Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: The ultimate 386BSD machine?	(FAQ fodder)
Keywords: 386BSD
Organization: Weber State University  (Ogden, UT)
Date: Fri, 9 Oct 92 00:28:10 GMT

In article <1992Oct8.164919.14096@eab.retix.com> erik@eab.retix.com (Erik Forsberg) writes:
>In article <Bvsss4.9nz@ibmpcug.co.uk> adrian@ibmpcug.co.uk (Superuser) writes:
>>Julians SCSI system works by setting th 1742B into 1542 mode, and then
>>when the probe works out its a 1742, it shoves the card into enhanced
>>mode itself.
>>
>
>This seems to be a BAD approach. It would EXCLUDE all existing 1740 cards
>from functioning. ONLY the newer 1740A (and obviously 1742A) allows switching
>between standard and enhanced mode at runtime. The older 1740 (which probably
>still is the most common Adaptec EISA card out there) requires you to
>download firmware that is specific to the operating mode.
>
>So, useful support for Adaptec 1740 cards, requires support for enhanced
>mode in everything (boot blocks, standalone boots and kernels).

This is, of course, an alternative.  To do so would require reqriting
nearly everything in an "isa" directory in the /usr/src/sys.386bsd
heirarchy.  In addition, this would be nearly twice the job of the ISA
code currently in use, because there's no telling if someone will plug
an ISA card into an EISA slot.  This means the code must support both
types of cards -- so be prepared to rewrite all the ISA code to fit into
the framework you establish with your EISA bus drivers.

Julian has chosen an alternative that allows you to use 32 bit EISA
transfers with [apparently] ISA cards.

Also, the older (non-A, non-B) versions of the controllers would require
new drivers anyway --  they aren't as "smart" as the newer models, and
the current drivers expect a certain level of intelligence from a card.
So the 1740 has two strikes against it -- three if you don't get a 1742
but want to use a boot disk.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd
From: boehme@unvax.union.edu (Eric M. Boehm)
Subject: 386BSD won't boot with AMI BIOS/Gateway 2000
Keywords: AMI Gateway 2000
Reply-To: Eric.Boehm@union.edu
Organization: Union College, Schenectady, NY
Date: Tue, 13 Oct 1992 03:46:43 GMT

I have seen oblique references to a problem with AMI BIOS in other
messages. I recently upgraded my BIOS from 030389 to 050591. 386BSD
still won't boot. The drive light comes on and stays on. Ctrl-Alt-Del
won't regain control -- time for the red button.

If anyone has suggestions, workarounds or pointers to explanatory
materials, I would greatly appreciate it.

Thanks in advance.


-- 
Eric M. Boehm
Eric.Boehm@union.edu
BOEHME@UNION.BITNET
Newsgroups: comp.unix.bsd
From: stripes@pix.com (Josh Osborne)
Subject: Re: [Xfree86 on 386BSD] xtank ported yet?
Organization: Pix Technologies -- The company with no adult supervision
Date: Thu, 15 Oct 1992 00:32:53 GMT

In article <1992Oct14.105519.1@max.u.washington.edu> anything@max.u.washington.edu writes:
>Has anyone ported Xtank to XFree86/386BSD yet?

Yes, I pestered Kurt (lidl@pix.com/uunet.uu.net) until he got out the offending
code (the thread stuff, very hard to write portable threading code...), he
forced me to explain how longjmp.s did it's majic, I fumbled, and Dave Hsu 
recovered for me.

The 1.3d release of xtank runs just fine on a *fast* 386BSD box.  Consult
archie for the closest ftp site or try azathoth.sura.net.  No, it doesn't
(yet) take advantage of the sound blaster driver, but it will (what else
would we have ported the driver code (from the BSDI version, which cane from
the Mach driver)?).
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Newsgroups: comp.unix.bsd
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: Sun/386BSD Cross Compiler?
Date: 7 Oct 92 12:59:18 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.uni-duisburg.de
NNTP-Posting-Host: du9ds3.uni-duisburg.de

In <7636@skye.ed.ac.uk> richard@aiai.ed.ac.uk (Richard Tobin) writes:

>In article <1992Oct5.204631.8172@tinman.mke.ab.com> tdphette@mke.ab.com (Thad Phetteplace x4461) writes:
>>I've been thinking it would be really handy if I could use one of my
>>SPARCstations to compile 386BSD code (in particular X386).

>Cross-compiling isn't too difficult a problem - gcc2 can be configured
                                                 ^^^^
I remembered there was once a 386bsd GCC2.2.2 kernel "project". Never heard
anything again about that after it has been said that gcc2 has some 
optimization "misfeatures". Any news there?

>as one.  I believe I sent out some patches to BSD's ld to use it as a
>cross-linker (it doesn't handle byte-order differences correctly)
>about 6 months ago, but I no can no longer find them.

>-- Richard
>-- 
>Richard Tobin,
>AI Applications Institute,                                R.Tobin@ed.ac.uk
>Edinburgh University.

Holger

-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|  | /   Dept. of Electr. Eng.   |   Sorry, the above really good fortune has
|  |/    Inst. f. Dataprocessing |      been CENSORED because of obscenity"
From: goran@astro.uu.se (Goran Hammarback)
Newsgroups: comp.unix.bsd
Subject: Re: xv for 386bsd ??
Date: 16 Oct 1992 13:01:55 GMT
Organization: Uppsala University
Distribution: world
NNTP-Posting-Host: solaris.astro.uu.se

In article <Bw7G74.LG2@cosy.sbg.ac.at>, peter@wiesel.cosy.sbg.ac.at (Peter Burgstaller) writes:
|> Has anybody ported xv for 386bsd/XFree86 ??
|> 

I have ported xv-2.21, and I'll gladly make it available if I only
knew where to put it (and how)...
Any suggestions?

-- 

Goran

------------------------------+---------------------------------
Goran Hammarback              |     goran@astro.uu.se
Astronomiska Observatoriet    |
Uppsala Universitet           |
S-751 20 SWEDEN               |
------------------------------+---------------------------------
Newsgroups: comp.unix.bsd
From: ruediger@ramz.ing.tu-bs.de (Ruediger Helsch)
Subject: Rumors about floating point exceptions (80x87 FP stack)
Organization: Mechanikzentrum, Technische Universitaet Braunschweig, Germany
Date: Fri, 9 Oct 1992 16:52:56 GMT

This article is written to shed some light on the function of the 80x87
floating point processor (and the 80486) and to help explain the
occurrence of arbitrary floating point exceptions in code that works
fine on other processors. Summary: undeclared floating point functions,
even if the result is ignored, cause the 80x87 floating point stack to
overflow at possibly entirely unrelated places of the program.

Each few days somebody writes here about GCC optimization errors
resulting in floating point exceptions. Last time it was in the patch kit
at patch00036. As the reason was given: "The gist of this is that an
external double function that isn't declared has an implicit type of int.
Assigning a double variable the return value of this function causes a
floating point exception. Declaring the function fixes 'ps'".

Obviously this was a programming error in 'ps' and not an optimization
bug. The 80x86/80x87 is extremely sensitive against function
misdeclarations. An undeclared floating point function, EVEN IF THE
RESULT IS IGNORED, may cause a floating point exception at any
point much further in the program. These bugs are very difficult to
locate.

The reason is the following: the 80x87 contains eight floating point
registers organized as a FP stack. During floating point calculations
temporary values are pushed onto this stack and popped when they
are used. It is the responsibility of the compiler to make sure that not
more than eight values are pushed and that the stack is cleaned up
after the temporaries are no longer needed.
Floating point functions also push their result onto this stack before
they return. The caller can then pop the function result from the FP stack
when it is used, emptying the stack.

If a floating point function is not declared as such, the compiler has no
way to guess that the function has pushed a value onto the FP stack.
The value will not be popped but will remain there, reducing the free
space on the FP stack to seven registers. After four more calls to the
function the FP stack will be shrink to three registers. Then, at some
completely unrelated place in the program, where a complicated FP
expression is computed, the FP stack will overflow and cause the
floating point exception.

The best way to trace these bugs is to watch the floating point stack
using a debugger. I do not know if such a debugger is available for
386bsd, my experiences come from ISC Unix, where the debugger
allowed to watch the FP stack growth.

I hope this makes the problems clearer and helps people who observe
seemingly unexplicable floating point exceptions.

Ruediger Helsch <ruediger@ramz.ing.tu-bs.de>
Newsgroups: comp.unix.bsd
From: jtk@netcom.com (Jane Valencia)
Subject: Re: [386BSD] crash 0/2
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sun, 11 Oct 1992 15:31:20 GMT

It has been discovered that another filesystem "fixup" is assumed
by the source code which follows.  As root, you need to cd to the
directory /usr/include/vm.  If this directory is empty on your
machine, you should then link the .h files from your vm/ directory
in your kernel source.  For me, the following worked:

# cd /usr/include/vm
# ls
# ln -s /sys/vm/*.h .

Perhaps there's some step in the install I missed which would
have done this.  But since it happened to someone else too, I
thought I should mention it.

				Regards,
				Andy Valencia

Newsgroups: comp.unix.bsd
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: [386BSD] System's not finding/using swap
Organization: Weber State University  (Ogden, UT)
Date: Thu, 15 Oct 92 19:57:56 GMT

In article <JDOLTER.92Oct15140414@sawtooth.eecs.umich.edu> jdolter@eecs.umich.edu (James W. Dolter) writes:
>>>>>> Regarding Re: [386BSD] System's not finding/using swap; terry@cs.weber.edu (A Wizard of Earth C) adds:
>
>   .....
>
>	terry> The swap has to go at the end of the disk.
>   .....
>
>That is not true.... I have both of my configured swap partitions in the
>middle of my disks.
>
>I suggest checking out your kernel config and swap386bsd.c to make sure
>that you have a entry in the swap device table (swdevt)...

The only error I see here is that the default dist.fs/fixit.fs don't have
swap devices configured.  It may be possible to recompile a kernel to set
this up without first having it set up in the default location (the end
of the disk).  Every time I have tried this, I have run out of memory
and crashed.  I suppose that it's posible if you have a large amount
of memory (physical RAM) in your box; but then again, if you're using
ISA drivers, there is a possiblity that your DMA will fail without the
"bounce buffer" patch to insure all DMA I/O occurs below 16Meg.

In either case, you will probably have to have a working kernel build
environment before you tackle this, and if you don't put the swap at the
end of the disk, you may not be able to have a build succeed.  This is like
trying to run a BusTek or AHA174x disk without Julian's drivers so you
can install them.


One potential workaroung of the memory problem is to make -n the kernel,
then enter in the compilation lines by hand.  This is messy, but it
worked for me.  It's much easier to accept the default configuration
from install, or make your own disktab entry and use the fixit.fs
procedure of Chris' in the FAQ.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.bsd