Date: Fri, 12 May 95 11:46:33 MDT From: terry@cs.weber.edu (Terry Lambert) To: SahagunS@aol.com Cc: Questions@FreeBSD.org Subject: Re: SCSI boards and then some. Message-ID: <9505121746.AA01776@cs.weber.edu> In-Reply-To: <950512015447_116005844@aol.com> from "SahagunS@aol.com" at May 12, 95 05:12:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> After reading section 3, titled 'Hardware compatibility', it is not clear if > the SCSI portion of a Sound Blaster 16 SCSI-2 card will work with freeBSD > 2.0. I do have a need for sampling, but under Windows only, and I don't > anticipate that i'll ever need to boot from a SCSI device. I'm really just > trying to avoid buying a sound card and a SCSI card. I really don't have my > heart set on a particular brand of sound card or CD-ROM. I'm open for > suggestions. The answer depends on your answer to the question "which SCSI interface of the three available for the Sound Blaster do you have?". There is an AIC6360 driver (Adaptec 1522) that will work with one of them as long as you get the intterupts, etc. right. I believe they are *all* supported (including the Mitsumi) in the upcoming 2.0.5 release. You should be aware that these interfaces aren't really bus mastering, and so will have poor performance. You should get a real SCSI card if this is a problem for you. > Is shared memory as a means of IPC allowed in freeBSD 2.0? Yes. There are several issues, like time stamp updating that make it unsuitable for really abusive programs likes INN, but for the most part it should work. > Can the priority levels of tasks be changed dynamically? man nice man renice top > How do two tasks, for example, share the PC's screen? Usually by console switching. This is generally true for any I/O system that can't guarantee atomicity of state change commands. For instance, the VMS broadcast facility relies on the fact that the VMS I/O subsystem will always use atomic writes because it has embedded knowledge of when the terminal is at state 0 in escape sequence processing. VMS can do this because it simplified the problem by choosing to support on DEC terminals. This was further refined when session switching came into vogue (LAT + VT330/VT340, etc.) and in supporting transparent printing by removing the escape key from DEC manufactured terminals (no lie). Making these assumptions buys you neat features, like status line updates and functional transparent printing (which you can get using a state machine seperate from the I/O subsystem without making the full assumption -- Digiboard does it) at the cost of hardware independence. There are a lot of other examples, like baud rate recognition by way of carriage return baud rate bit spreading (you crank the baud to it's highes level, and ussume any incoming data is a carriage return. Then you match the sequences against a catalog to get the real baud rate. Try this some time; it's terrifically hardware dependent on the serial card clock and dividers; PC hardware simply has insuffcient quality control to make it reliable without calibrating each card). These are tradeoffs that UNIX and UNIX work-alikes in general do not make, since they are intended as protable to diverse hardware. > And finally, is there a port of FreeBSD for a 68k platform? No. FreeBSD has approached the problem depth-first instead of breadth-first. Both are equally valid approaches. With the support of the NetBSD code, a port would be trivial, or you could run the NetBSD code itself. Eventually I expect that the two will get to a point where they are virtually indistinguishable. You already see some ossification of both systems by attempts to conform to standards by system rather than library changes (ie: POSIX, IBCS2, the X<->console interface, etc.). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505121746.AA01776>