thomsen@spf.trw.com (Mark R. Thomsen) (06/24/91)
I thought some of you could stand a chuckle. I was asked to present my group's software on NeXT at a rather small gathering of NeXT folk and company folk. Steve Jobs was to be there to give a talk, some new products were promised from 3rd party vendors, and some of us custom developers were going to look over one another's shoulders. Sounded like fun. Well, not having our NeXTdimensions yet (we be slow, no fault of NeXT here) we first wanted to get our software running on NeXTdimension. (We had used a NeXT prototype called Red October to get to a color application, for those wondering). We asked our local NeXT rep to borrow his ND for a day and managed to get the software mostly running. 40MB CPU RAM and 16MB ND RAM. Got good animation of ozone hole opening and closing. Did the rest of the work on grey cubes and got it to run. We go to the gathering last Friday. We asked for a ND to be provided. It was. But we did not mention memory. The hard disk (in cube provided by someone else - not NeXT) did not have room for the app. The configuration was 16 MB CPU RAM and 4 MB ND RAM. Started deleting stuff from HD and barely could run. Everything ran slow. (We sling around 3MB images like chips at a poker game). The HD got to NO SPACE available. We are frantically trying to improve it when ... Steve decided to drop by and see what we are up to. We show a couple of things. Some Q&A about machine and what they are looking at that might help. We apologize for performance due to low memory configured. Then he grabs for the mouse. Two clicks and it pretty much dies. Just the way you want your software remembered. It could have been embarrassing. However he (and several other NeXT folk there) was more interested in our thoughts on the development environment and the overall machine. It will not go down as our best demonstration moment. I will post real soon on the talk itself. And I want the machine Steve demonstrates on (one NeXTie called it, at last fall's roll-out, "The most expensive machine we can build"). Mark R. Thomsen
flynn@yoda.eecs.wsu.edu (Patrick J. Flynn) (06/25/91)
In article <28652826.11D5@deneva.sdd.trw.com> thomsen@spf.trw.com (Mark R. Thomsen) writes: > >We asked our local NeXT rep to borrow his ND for a day and >managed to get the software mostly running. 40MB CPU RAM >and 16MB ND RAM. Got good animation of ozone hole opening and >closing. Did the rest of the work on grey cubes and got it >to run. > >We go to the gathering last Friday. We asked for a ND to be >provided. It was. But we did not mention memory. The hard >disk (in cube provided by someone else - not NeXT) did not >have room for the app. The configuration was 16 MB CPU RAM >and 4 MB ND RAM. Started deleting stuff from HD and barely >could run. Everything ran slow. (We sling around 3MB images >like chips at a poker game). Those of you considering the purchase of ND systems might be interested in this future NextAnswer created by Sharon Zakhour at NeXT (posted with her permission). I asked the questions, she was nice enough to answer them. I was intrigued by the following items in the answer: 1. The i860 pages via the '040. I wouldn't want to have an I/O bound ND board, so load up on ND memory, folks. 2. You can't memory-map the ND's VRAM. This may spell Big Trouble for the people wanting X on the ND system. As far as I know, all the current NeXT X implementations memory-map the frame buffer. TTFN Pat "My ND arrives next week, drool drool" Flynn ---- snip snip snip ---- NeXTdimension memory i860 Q. I've purchased a NeXTdimension system and wish to expand the memory. What performance advantages can I expect to gain from adding memory to the ND board as opposed to the CPU board? Is there a mini-Mach running on the i860? Can the i860 swap to disk? Can I memory-map the memory on the ND board? A: The DRAM on the NeXTdimension is used for displaying all windows which appear on the ND monitor. The ND board is driven by a Mach loadable device driver (which loads into the Mach kernel on the host) and a NeXTdimension screen driver, part of which loads into the WindowServer, and another part which loads into the i860. This i860 software consists of a mini Mach-like kernel, specially designed to support low-level PostScript drawing and virtual memory for window backing stores. It is NOT possible to program the i860 directly -- see NeXTanswer color.648 for more information. Neither the DRAM nor the VRAM on the NeXTdimension can be memory mapped by the application. When it becomes necessary, the i860 pages to disk via the host 040 -- it does not write directly to disk itself. Whether you increase memory on the 040 or the ND depends upon how you plan to use the system. In general we recommend that you keep them fairly balanced. If you are going to be keeping lots of windows on the ND system then we suggest that you keep the memory on the i860 somewhat ahead. The less paging you do the better. You cannot extend the VRAM [video ram] on the NeXTdimension. The NeXTdimension-related files on the 2.1 Release (ND systems only) are located as follows: ND PostScript Driver: In the directory /usr/lib/NextStep/Displays/NeXTdimension.psdvr: reloc dynaloads into WindowServer ND_MachDriver loaded into Mach NDserver loads i860 code and provides I/O support NOTE: The size of the VM space on the i860 is directly related to the VSIZE that ps will report for the NDserver task. This task shows up in a "ps aux" as: root 149 0.0 3.4 28.3M 280K ? S 40:47 (NextDimension) -NDSlot 2 CPU use by this task directly reflects I/O activity, including paging, by the i860. Video Support: /usr/include/appkit/NXLiveVideoView.h include file for video view /usr/lib/NestStep/GraphicsPackages/video_reloc dynaloads into WindowServer /usr/shlib/libvideo_s.A.shlib shlib image /usr/lib/libvideo_s.a shlib archive Demos & Examples: NeXTtv video/grab Demo ScreenScape video out Demo VideoApp generic video Demo and Example See also: color.648 for more information on the i860 color.607 for information on color lookup tables video.578 for information on video window size for the NeXTdimension performance.739 for performance issues involving large amounts of bitmap data QAxx Not valid for 1.0 Valid for 2.0 -- +-----------------+--------------------------+----------------------------+ |Patrick J. Flynn | School of eeks, er, EECS | Washington State University| +-----------------+--------------------------+----------------------------+