nerd@percy.uucp (Michael Galassi) (11/19/90)
I'm going to be ordering my '040 upgrade soon and have a few questions
about it.
a) In the price list NeXT refers to the posibility of using Parity
Memory. Would this use the same 1Meg / 4Meg SIMMs available for
$45 / $200 mail order for '386 boxes?
b) When booting my '030 I get a message telling me the RAM is of the
100 nS variety. Can I use faster memory and get fewer wait states
out of the CPU? Will this be the case for the '040? How do I
tell the CPU what speed is installed?
c) NuBus (a variation of which is called NeXTBus (I think?)) is touted
as supporting multi-processing, mach (a variation of which we run
on the NeXT supports multi-processing (I know)). All of us who
have '030s and upgrade to '040s will have 2 cpu boards. Given
these three facts (?) the logical question is can I run both
processors in my cube?
d) Is the SCSI connector on the '040 board the same as the one on the
'030 board?
e) It is my understanding that some applications that were a part of
1.0a software will NOT be a part of 2.0. If this is the case, will
the applications from my 1.0a OD work under 2.0?
f) I have not seen much talk of media for the OD, is the $150 device
from Businesland the only alternative or are there other sources/brands
that would work in the NeXT OD?
g) My cube is of the old variety with the out blowing fan, is it enough for
me to reverse the fan (mount it backward or are there other structural
changes that need to be made for the machine to be safe to my OD?
I don't think these questions have been answered recently so they may
be of general interest and thus warant posting of answers. Anything
I find out other than through postings will be sumarized here.
Thanks,
-michael
--
Michael Galassi | If my opinions happen to be the same as
...!tektronix!percy!nerd | my employer's it is ONLY a coincidence,
...!sun!nosun!percy!nerd | of course coincidences OFTEN DO happen.scott@mcs-server.gac.edu (Scott Hess) (11/19/90)
In article <1990Nov18.181541.16646@percy.uucp> nerd@percy.uucp (Michael Galassi) writes:
b) When booting my '030 I get a message telling me the RAM is of the
100 nS variety. Can I use faster memory and get fewer wait states
out of the CPU? Will this be the case for the '040? How do I
tell the CPU what speed is installed?
On regular '030 or '040 machines, I've heard that the answer is "no." It
sounds like there's some different reasoning that goes into the color
machines, though, because they seem to need 80ns ram. Maybe that's because
they're interlaced (now that I think about it, probably).
c) NuBus (a variation of which is called NeXTBus (I think?)) is touted
as supporting multi-processing, mach (a variation of which we run
on the NeXT supports multi-processing (I know)). All of us who
have '030s and upgrade to '040s will have 2 cpu boards. Given
these three facts (?) the logical question is can I run both
processors in my cube?
2 CPU boards plus multi-tasking bus/operating system != multiprocessor
computer. Most multiprocessor computers are specifically set up to
multitask. Presumably, the NeXT hardware is not set up for decent
shared memory, and I _know_ that it is not set up for a motherboard to
run in a slot other than slot 0. Also, I don't think that the multi-
processing Mach stuff is done yet - much less incorporated into NeXT's
version of Mach.
The best solution that we've (some friends and I) come up with is to
do the needed hardware mods, and run the second motherboard at a networked
node. Then, one of them netboots off the other, and we're home-free.
This has problems, also, the main one being that we aren't licensed to
run NextStep or Mach/Unix on both motherboards . . . that might be a
problem with attempting the multi-tasking solution, also.
e) It is my understanding that some applications that were a part of
1.0a software will NOT be a part of 2.0. If this is the case, will
the applications from my 1.0a OD work under 2.0?
So far, I believe the missing apps are Sybase, Common Lisp, and Mathematica
(that last is only missing for non-educational buyers). In at least the
case of Common Lisp, all NextStep1.0 licensees get a card, or something,
which allows them to run cl on 2.0. I believe there's something similar
with Sybase, but I'm not sure.
g) My cube is of the old variety with the out blowing fan, is it enough for
me to reverse the fan (mount it backward or are there other structural
changes that need to be made for the machine to be safe to my OD?
I've heard that simply reversing the fan doesn't work, either. Something
with how the casing is designed . . .
Which brings up a good question: Why isn't NeXT offering a case upgrade
to user's with the very old cases? This would seem to be relatively cheap,
so that they could either offer it free (ala the 40M swapdisk), or
fairly cheap. Presumably they get their cases from somewhere, right . . . ?
--
scott hess
scott@gac.edu
Independent NeXT Developer (Stuart)
GAC Undergrad (Horrid. Simply Horrid. I mean the work!)
<I still speak for nobody>charlie@wam.umd.edu (Charles William Fletcher) (11/19/90)
In article <SCOTT.90Nov18181255@mcs-server.gac.edu> scott@mcs-server.gac.edu (Scott Hess) writes: >In article <1990Nov18.181541.16646@percy.uucp> nerd@percy.uucp (Michael Galassi) writes: > c) NuBus (a variation of which is called NeXTBus (I think?)) is touted > as supporting multi-processing, mach (a variation of which we run > on the NeXT supports multi-processing (I know)). All of us who > have '030s and upgrade to '040s will have 2 cpu boards. Given > these three facts (?) the logical question is can I run both > processors in my cube? > >2 CPU boards plus multi-tasking bus/operating system != multiprocessor >computer. Most multiprocessor computers are specifically set up to >multitask. Presumably, the NeXT hardware is not set up for decent >shared memory, and I _know_ that it is not set up for a motherboard to >run in a slot other than slot 0. Also, I don't think that the multi- >processing Mach stuff is done yet - much less incorporated into NeXT's >version of Mach. > Also I don't believe you will have two processors (BusinessLand buyers take note). It has been my understanding from NeXT(I ordered the 030 on the academic deal) that to get the 040 upgrade at the *quoted* price you need to trade in your 030 board (NeXT wants them for future 030 support). You may-at an extra cost- buy the 030 board, but NeXT is NOT supporting both boards in the cube at this time (although there is a rumor someone put in some jumpers and did get them both working in one cube.) -Charlie
grant@gouche.UUCP (Grant Munsey) (03/16/91)
Just read the FAQ and still have a couple 'o ?s
I havn't gotten my slab yet so I don't have manuals.
1) I have a very old Apple LaserWriter. Am I going to be able
to use this in a well integrated fashion on th NeXT?
2) I have a Trailblazer T2500 modem. Do the serial ports on the
NeXT support hardware handshake and can they go at > 9600 baud?
3) I would like to network the NeXT to a i386 running Interactive
Unix (vers 2.2). Are there any known 'nasty suprises' I am going
to run into using thin wire ethernet and NFS?
4) Is the NeXT impl of 4.3bsd fairly faithful...will I finally be able
to compile programs from the net without the SYSVizeing them?
5) As shipped (with the std 8 meg) is the slab populated with 1 meg
by 8 simms or are the 4 meg by 8?
Thanks,
--
Grant Munsey, Mainticore, Inc. (408) 733-3838
grant@gouche.portal.com or {uunet!opusys,decwrl!apple!portal}!gouche!grantpaul@cgh.UUCP (Paul Homchick) (03/17/91)
In article <208@gouche.UUCP> grant@gouche.UUCP (Grant Munsey) writes: >1) I have a very old Apple LaserWriter. Am I going to be able > to use this in a well integrated fashion on th NeXT? It is very simple to hook up a Laserwriter to a serial port and use it as the default printer. I recently bought a NeXT printer, but for the 12 months prior to this change, I used a QMS800II on a 9600baud serial line with nary a problem. (The QMS is for sale, btw). If your Laserwriter is VERY old, it may have some postscript bugs. >2) I have a Trailblazer T2500 modem. Do the serial ports on the > NeXT support hardware handshake and can they go at > 9600 baud? My Trailblazer plus works fine. The new NeXTs support hardware handshaking if you supply a correctly-wired cable. >3) I would like to network the NeXT to a i386 running Interactive > Unix (vers 2.2). Are there any known 'nasty suprises' I am going > to run into using thin wire ethernet and NFS? If your Interactive box really does support NFS over ethernet, you shouldn't have any problems. I have a IBMPC hooked up using ftp software's telnet and Interdrive (their PCNFS). >4) Is the NeXT impl of 4.3bsd fairly faithful...will I finally be able > to compile programs from the net without the SYSVizeing them? If you use the -bsd compiler switch, most everything should work. However, you may have an occasional problem with multiply-defined routines from the shared library, and you have to keep in mind that the NeXT MACH does not support sbrk() and brk(). -- Paul Homchick :UUCP {rutgers | uunet} !cbmvax!cgh!paul Chimitt Gilman Homchick, Inc. :Internet cgh!paul@dsi.com 259 Radnor-Chester Rd, Suite 140 :MCI PHOMCHICK Radnor, PA 19087-5299 :GEnie HOMCHICK
drin@nro.cs.athabascau.ca (Adrian Smith) (03/18/91)
grant@gouche.UUCP (Grant Munsey) writes: > Just read the FAQ and still have a couple 'o ?s > I havn't gotten my slab yet so I don't have manuals. > 1) I have a very old Apple LaserWriter. Am I going to be able > to use this in a well integrated fashion on th NeXT? Don't know. I still can't *afford* a printer yet... :-) > 2) I have a Trailblazer T2500 modem. Do the serial ports on the > NeXT support hardware handshake and can they go at > 9600 baud? Yes and yes. > 3) I would like to network the NeXT to a i386 running Interactive > Unix (vers 2.2). Are there any known 'nasty suprises' I am going > to run into using thin wire ethernet and NFS? Not as far as I know. NFS seems to work just fine. > 4) Is the NeXT impl of 4.3bsd fairly faithful...will I finally be able > to compile programs from the net without the SYSVizeing them? Seems to be fairly faithful - I haven't had any problems. (Contradictions welcome :-) ) > 5) As shipped (with the std 8 meg) is the slab populated with 1 meg > by 8 simms or are the 4 meg by 8? 1 meg x 8. You have to pull a bank of four and drop in four 4 meg x 8 to increase memory. > > Thanks, > -- > Grant Munsey, Mainticore, Inc. (408) 733-3838 > grant@gouche.portal.com or {uunet!opusys,decwrl!apple!portal}!gouche!grant
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/20/91)
In article <Lyqyy5w164w@ersys.uucp>, ersys!drin@nro.cs.athabascau.ca (Adrian Smith) writes: > grant@gouche.UUCP (Grant Munsey) writes: >> 4) Is the NeXT impl of 4.3bsd fairly faithful...will I finally be >> able to compile programs from the net without the SYSVizeing >> them? > Seems to be fairly faithful - I haven't had any problems. > (Contradictions welcome :-) ) Well, you don't need to SysVize things. But it is *not* 4.3. To begin with, any program that expects to meddle with a.out files (for example, undump, or my symbol-table patchers) will need to be overhauled - and I don't mean just recompiled. NeXT's Mach uses a completely different format for executables. They have *no adb*. I don't know *what* possessed them to do away with it, but they did.... They've even done away with the loader-defined symbols _etext, _edata, and _end that UNIX has had since the dark ages. Other than that...no, I haven't found anything terribly non-UNIXish about it. :-) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jashley@hammerhead.cs.indiana.edu (J. Michael Ashley) (03/20/91)
In article <1991Mar20.125440.17013@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >In article <Lyqyy5w164w@ersys.uucp>, ersys!drin@nro.cs.athabascau.ca (Adrian Smith) writes: >> grant@gouche.UUCP (Grant Munsey) writes: >>> 4) Is the NeXT impl of 4.3bsd fairly faithful...will I finally be >>> able to compile programs from the net without the SYSVizeing >>> them? >> Seems to be fairly faithful - I haven't had any problems. >> (Contradictions welcome :-) ) > >They have *no adb*. I don't know *what* possessed them to do away with >it, but they did.... I was upset at first that adb is not on the NeXT, but I've since found gdb to be a more than adquate replacement, both in terms of functionality and friendliness. Disclaimer: I don't try to do fancy things with either adb or gdb; I just find out where I'm buyin' the farm. Mike
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (03/26/91)
In article <1991Mar20.085057.1217@news.cs.indiana.edu>, jashley@hammerhead.cs.indiana.edu (J. Michael Ashley) writes: > In article <1991Mar20.125440.17013@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >> In article <Lyqyy5w164w@ersys.uucp>, ersys!drin@nro.cs.athabascau.ca (Adrian Smith) writes: >>> grant@gouche.UUCP (Grant Munsey) writes: >>>> 4) Is the NeXT impl of 4.3bsd fairly faithful...will I finally be >>>> able to compile programs from the net without the SYSVizeing >>>> them? >> They have *no adb*. I don't know *what* possessed them to do away >> with it, but they did.... > I was upset at first that adb is not on the NeXT, but I've since > found gdb to be a more than adquate replacement, both in terms of > functionality and friendliness. As a debugger, so do I. But adb is useful for things other than normal debugging tasks. It makes a passable binary file editor. It can be used to disassemble snippets of data that do not happen to be part of an a.out file. It is the ed of debuggers and is useful for all the reasons ed is useful; notably, it behaves sanely when used as a filter in a pipeline. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
eps@toaster.SFSU.EDU (Eric P. Scott) (03/30/91)
In article <1991Mar20.125440.17013@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >They have *no adb*. I don't know *what* possessed them to do away with >it, but they did.... It would require *effort* to port. So would sdb or dbx. There's no ptrace() call--the functionality is available through a much more complex (though admittedly more flexible) set of mechanisms. >They've even done away with the loader-defined symbols _etext, _edata, >and _end that UNIX has had since the dark ages. In the dark ages, UNIX had extremely primitive memory management; there were two segments: text and data. Each was described by (starting address,length)--nothing more. On some machines they possibly lived in completely separate address spaces (e.g. PDP-11 with I&D space, Intel 80286 with Code and Data segments). The data segment was "open-ended"--it stopped at a point called the "break" which could be manipulated through the brk() and sbrk() calls. NeXT Mach uses a large linear address space in which text and data can be virtually discontinuous. Except in the most trivial cases, one can't identify a *single* value for those symbols-- each segment can have a different *meaningful* value--or perhaps more than one. In some respects, Mach is a lot more like VAX/VMS than UNIX. The vast majority of programs simply don't care. Asking "what should I plug in in place of _edata" is asking the wrong question. Rather, ask _why_ the code wants that information, because there's probably a much better (if Mach- specific) coding that captures the _intent_. -=EPS=-