knudsen@ihwpt.UUCP (mike knudsen) (04/07/86)
Phillips, Sony, and Microware (a not-quite-as-big SW house in Iowa that created/es OS9) have agreed on a standard for CD-ROM peripherals. The internal controller will be a 68000 running OS9/68K, presumably out of ROM (or booted from each CD disk maybe?). This was revealed in the latest MOTD, the newsletter of the National OS9 Users' Group. I don't know what percentage of CD-ROM machines this scheme will cover -- I think there are already some boxes out there. mike k "Facts? You can't post this in net.rumor!!"
jimomura@lsuc.UUCP (Jim Omura) (04/15/86)
Mike K. mentioned a CD-ROM standard based on OS-9 68K. In fact, it's
called CDI. Jerry Pournelle was very excited about it (see recent Infoworld
articles by him). We've had a special conference on CD-ROM this month on
BIX, but unfortunately, little has been said about CDI so far despite the
fact that two of us have asked about it. It may be because none of the
people closely involved with CDI showed up. I'm hoping that some of them
will before the end of the month. This summer is going to be very important
to the 68000 software industry.
Cheers! -- Jim O.
--
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
(416) 652-3880jimm@amiga.UUCP (Jim Mackraz) (04/17/86)
In article <1185@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > > Mike K. mentioned a CD-ROM standard based on OS-9 68K. In fact, it's >called CDI. >Jerry Pournelle was very excited about it (see recent Infoworld >articles by him). >This summer is going to be very important to the 68000 software industry. > > Cheers! -- Jim O. >James Omura, Barrister & Solicitor, Toronto I can sense Jim's glee now that OS-9 is the darling of JerryP and the InfoWorld circles of journalism, by virtue of its incorporation in the CDI standard, but I have reservations and I would like to hear some net input. As I understand it, OS-9 will be used as an internal control operating system within a closed, appliance type of product (i.e., like a stereo component) which will use custom--and we can assume proprietary-- chips for graphics and audio. The question is: What advantage is held by a computer running OS-9 if the CDI standard becomes a success? [By the way, I am not nearly as skeptical or sarcastic as the following may sound, it just came out that way today, and I'll let it ride, OK?] I can only conjecture: 1- that your computer will be able to execute software on the CDI disks. I doubt this very strongly. 2- that your computer will be able to be used as a development station for CDI software. This will require many other things. 3- that your computer manufacturer is in bed with the right people at an early stage, if he/she hurries, as far as arranging 2, above. 4- that you will catch nice publicity from Jerry Pournelle, since you are on the wave of the future of 68000 software technology. 5- that you can learn to be a great consultant for people who build CDI systems (none in the US, i think) authoring systems, and so on, to say nothing of those people swayed by item 4. 6- that OS-9 is really great, independent of CDI, and that you come out ahead even without any of the above panning out. This item would have been omitted, given the specific "question", but I know what OS fanatics are capable of doing to one's mail burden. cheers, and good luck to OS-9, 68000's, CDI, and you all. jimm
crowl@rochester.ARPA (Lawrence Crowl) (04/18/86)
DEC is also pushing a standard for CD-ROMS. It is a file system based
on their Files-11 file system. See the April 1986 issue of Mini-Micro
Systems. My one comment is that DEC's [dir,dir,dir]file.ext naming
scheme is not as good as the Unix /dir/dir/dir/file.ext naming scheme.
It tends to cause problems for name aliasing schemes. You also have
to hunt down the [] keys.
How many companies are pushing their own file system as standard? How
about putting them all together in one room until they come up with a
standard? Well, the standards that come out of committees like this
are always baroque and unwieldy. How about having someone who is not
finacially interested but is technically competent design a system
incorporating the best features of the various proposed standards?
Or am I dreaming?
--
Lawrence Crowl 716-275-5766 University of Rochester
Computer Science Department
...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627ralphw@ius2.cs.cmu.edu.UUCP (04/18/86)
In article <17347@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >DEC is also pushing a standard for CD-ROMS. It is a file system based >on their Files-11 file system. See the April 1986 issue of Mini-Micro >Systems. My one comment is that DEC's [dir,dir,dir]file.ext naming >scheme is not as good as the Unix /dir/dir/dir/file.ext naming scheme. >It tends to cause problems for name aliasing schemes. You also have >to hunt down the [] keys. The file naming scheme should be completely independent of the actual representation of files and internal filenames (which can use non-ASCII characters for internal delimiters) in the filesystem. A reasonable filesystem should allow for many naming systems (especially delimiters, including '[,]' (VMS), '/' (Unix, Apple ProDOS), '\' (MSDOS), or '<.>' (Tops-20), although typically only one user interface is provided. Hierarchical, tree-structured filesystems are 'in' now, but what about the more general digraph format, where a file or directory can be in more than one directory? (Unix sort of does this, but there is only one parent directory at each point in the tree, referenced by ..). If done properly this could solve the symbolic link semantics problem in Unix (cd through a link, then cd .. puts you somewhere you didn't expect to be). The user interface issues are more complicated, but that shouldn't prevent designers from building the digraph capability (my personal favorite) into the filesystem. -- - Ralph W. Hyre, Jr. Internet: ralphw@c.cs.cmu.edu (cmu-cs-c.arpa) Usenet: ralphw@mit-eddie.uucp Fido: Ralph Hyre at Net 129, Node 0 (Pitt-Bull) Phone: (412)CMU-BUGS
knudsen@ihwpt.UUCP (mike knudsen) (04/19/86)
> In article <1185@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > > > > Mike K. mentioned a CD-ROM standard based on OS-9 68K. In fact, it's > >called CDI. > > Cheers! -- Jim O. > >James Omura, Barrister & Solicitor, Toronto > > I can sense Jim's glee now that OS-9 is the darling of JerryP and the > InfoWorld circles of journalism, by virtue of its incorporation in > the CDI standard, but I have reservations and I would like to hear some > net input. > > As I understand it, OS-9 will be used as an internal control operating > system within a closed, appliance type of product (i.e., like > a stereo component) which will use custom--and we can assume proprietary-- > chips for graphics and audio. > > The question is: What advantage is held by a computer running OS-9 if > the CDI standard becomes a success? ... > 6- that OS-9 is really great, independent of CDI, and that you > come out ahead even without any of the above panning out. > jimm When I posted, I thought only of (6) above -- that this CD standard was a nice feather in the cap of OS9 and we could all brag about "knowing OS9 when." True, OS9 will be sealed up inside a box, and hardly anyone will know it's there. But I will, and so will you... mike k
dibble@rochester.ARPA (Peter C. Dibble) (04/21/86)
In article <821@ihwpt.UUCP>, knudsen@ihwpt.UUCP (mike knudsen) writes: > > In article <1185@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > > > > > > Mike K. mentioned a CD-ROM standard based on OS-9 68K. In fact, it's > > >called CDI. > > > Cheers! -- Jim O. > > >James Omura, Barrister & Solicitor, Toronto > > As I understand it, OS-9 will be used as an internal control operating > > system within a closed, appliance type of product (i.e., like > > a stereo component) which will use custom--and we can assume proprietary-- > > chips for graphics and audio. > > > > The question is: What advantage is held by a computer running OS-9 if > > the CDI standard becomes a success? CDI black boxes will certainly be sold, but I can't imagine Sony or Phillips (or any other company) passing up the chance to sell a powerful computer to CDI owners for the price of a floppy drive, keyboard, and some interface components. Perhaps the CDI player with OS-9 showing will cost $500 extra. For people who want a CDI player that should give the computer good price performance. .........: 680xx processor Excellent color graphics Excellent sound processing OS-9 (Multi-user Multi-tasking OS) Integrated CDI player Even if non-CDI OS-9 systems don't profit in any other way, lots of new users means lots of inexpensive software. Also, OS-9 supports networking. It should be easy to attach a minimal CDI computer to a host OS-9 system via network. ******* Peter Dibble@Rochester I'm not a bit unbiased about OS-9. If lots of people get OS-9 with their CDI players maybe some of them will buy my books!
jimomura@lsuc.UUCP (Jim Omura) (04/21/86)
In article <821@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes: >> >> As I understand it, OS-9 will be used as an internal control operating >> system within a closed, appliance type of product (i.e., like >> a stereo component) which will use custom--and we can assume proprietary-- >> chips for graphics and audio. >> >> The question is: What advantage is held by a computer running OS-9 if >> the CDI standard becomes a success? > ... >> 6- that OS-9 is really great, independent of CDI, and that you >> come out ahead even without any of the above panning out. >> jimm > >When I posted, I thought only of (6) above -- that this CD >standard was a nice feather in the cap of OS9 and we could all >brag about "knowing OS9 when." True, OS9 will be sealed up inside >a box, and hardly anyone will know it's there. >But I will, and so will you... mike k Mike, I've been trying to find out what level the CDI will see OS-9 and so far I haven't gotten an answer. On BIX, we are currently winding up a special conference with experts on CD-ROM, some of whom may know a bit about this, but my question seems to have been buried in the mass. If I remember, I'll try to ask the question again. I'll try to post what I find out at that time. In the meantime, we can't assume anything. Cheers! -- Jim O. -- James Omura, Barrister & Solicitor, Toronto ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura (416) 652-3880
geoff@desint.UUCP (04/21/86)
In article <333@ius2.cs.cmu.edu> ralphw@ius2.cs.cmu.edu.UUCP writes: > Hierarchical, tree-structured filesystems are 'in' now, but what about the > more general digraph format, where a file or directory can be in more than one > directory? (Unix sort of does this, but there is only one parent directory > at each point in the tree, referenced by ..). This is an old idea that has been tried more than once, including in earlier versions of Unix. To my knowledge, every attempt on a read-write file system has been a dismal failure. The problem is that there are just too many ways it can bite you. Probably the most common is the way linked files bit Unix-er's: some poor schmuck does 'cp msg /bin/mail' to install msg as the default mailer, not realizing that in the process he just wiped out /bin/rmail. It is an open question whether this would be a problem in read-only file systems. BTW, in passing I must put in my 2 cents' worth on Files-11. I am all too intimately familiar with the design of Files-11, as well as a large number of comparative systems (file system design is one of my subspecialties). Files-11 has a remarkable number of serious design flaws, along with less-serious howlers like their general principle of "store all data in the least-manipulable format, especially if that takes up extra space". -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
mc68020@gilbbs.UUCP (Tom Keller) (04/23/86)
In article <821@ihwpt.UUCP>, knudsen@ihwpt.UUCP (mike knudsen) writes: > > The question is: What advantage is held by a computer running OS-9 if > > the CDI standard becomes a success? > ... > > 6- that OS-9 is really great, independent of CDI, and that you > > come out ahead even without any of the above panning out. > > jimm > > When I posted, I thought only of (6) above -- that this CD > standard was a nice feather in the cap of OS9 and we could all > brag about "knowing OS9 when." True, OS9 will be sealed up inside > a box, and hardly anyone will know it's there. > But I will, and so will you... mike k In fact, OS9 was specifically designed to act not only as an interactive operating system, but as an embedded control environment. MicroWare made much of this capability in their early literature. I was operating OS9 back in 1980. -- Disclaimer: I hereby disclaim any and all responsibility for disclaimers. tom keller {ihnp4, dual}!ptsfa!gilbbs!mc68020 (* we may not be big, but we're small! *)
rb@ccird1.UUCP (Rex Ballard) (05/02/86)
In article <1053@amiga.amiga.UUCP> bruceb@amiga.UUCP (Bruce Barrett) writes: >In article <798@ccird2.UUCP> rb@ccird2.UUCP (Rex Ballard) writes: >>My guess is that the BIGGEST reason for using OS-9 in CDI is that >>OS-9 is the ONLY system which has a TRULY sharable Remote File System. >>[...] >> >>With it you can send an "open /usr/lib/libc.a" or whatever file name, >>and the treat it just like a standard block mode file. You don't >>have to know anything about how the files are structured, how >>they are stored, or what the format of the disk is. [...] > >Have you noticed that this is just like the amiga RAM: device? >As files are created, and deleted the RAM: disk memory is allocated >and freed. "Look ma, no sectors!" >>[... other nice OS-9 features, some of which we may not have...] Actually a RFS is quite different. The RAM: device can treat the hierarchy as it wishes, but the OS determines how to traverse directories, index of index blocks, find the next block,... In the RFS, the Driver determines all of this. The index blocks could be little endian, hashed, btree sorted, linked, indexed, and or contain contigous blocks, but the OS wouldn't know. When it is asked to "read(1,1000)", the RFS will give it the next 1000 bytes following current position in the file. The host OS will not know which block of the drive he just read, or even how he got there. Since the RFS is doing all the lookup, the driver might have to give the corrent seek position, or possibly do minimal deblocking. The RFS server is the only one who will know which block was read, or how he chose it.
rb@ccird1.UUCP (Rex Ballard) (05/03/86)
In article <17626@rochester.ARPA> crowl@rochester.UUCP (Lawrence Crowl) writes: >In article <798@ccird2.UUCP> rb@ccird2.UUCP (Rex Ballard) writes: >>... [Storing on CD-ROMs] things like ... with illustrations ... > >Egads! Is there a standard for storing images? Are they pixel based? >Will they fit on my screen? > >>... In addition, OS-9 has a VDI interface for presentation graphics, ... > >Will this deal with images, or graphics command sequences? >-- Well, I can't tell too much from the "product announcement", but it looks like the VDI can be build under either bit-map images, or command sequences. The announcement was for the 63484 VDI driver. Appearantly, they also have 7220 and bitmap versions as well. Basicly, the VDI approach used in OS-9 allows one to treat incoming and outgoing graphics commands as "streams". Even Unix, you could easily "cat pictures/bear |plot". All a VDI does is set things like clipping so that you can send "pictures" to different parts of the screen. This basicly allows you to use a single screen without knowing where in the "real" screen you are. As to the VDI interpretations, the just announced PD "superplot" package provides several options for getting from the CD to the "work-station". Options include postscript, plot(3) streams, or Tektronics, among others. Postscript is beginning to look attractive because it allows building of "macros" like "rounded rectangle", if it is not already part of the package. It isn't hard to convert from any of these "interchange formats" to your local "VDI" interface. Often, little more than a simple translation table is all that is required. There are a few PD programs which will "interpret" these streams into C routines (which are translated into system calls) as well. After looking at the GEM(Atari,IBM,et. al.), and Mac VDI specifications, I doubt it would be very difficult to come up with the apropriate interface. The important thing to remember about a CD VDI interface, is that you don't actually edit them directly. You do, however need to get editable "Units" and preferrable "Groups" which can be manipulated with an editor.
jimomura@lsuc.UUCP (Jim Omura) (05/07/86)
As VDI was explained to me, it is a Kernal based technology. That
is to say it is *position dependant*. If this is so then it is also
a system which makes support of one VDI device driver mutually exclusive
of other VDI device drivers. Have I misunderstood the point of VDI?
Cheers! -- Jim O.
--
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
(416) 652-3880rb@ccird1.UUCP (Rex Ballard) (05/13/86)
In article <1206@lsuc.UUCP> jimomura@lsuc.UUCP (Jim Omura) writes: > > As VDI was explained to me, it is a Kernal based technology. That >is to say it is *position dependant*. If this is so then it is also >a system which makes support of one VDI device driver mutually exclusive >of other VDI device drivers. Have I misunderstood the point of VDI? Yup! There are basicly two levels of graphics interface, the GKS or graphics kernal, which is very device specific, essentially the equivalent of a BIOS or UNIX device drivers, and the Virtual Device Interface. Part of the problem of course, is that the GKS isn't officially standardized yet (but is available for OS-9). The "graphics kernal" might be, for example, a bit mapped display, or a driver that converts "interchange commands" to graphics processor specific commands. For a given "desktop", the VDI input (calls, instructions, NAPLPS "text"... would be coverted from "device relative" positions to "screen absolute" co-ordinates. Also, the "kernal" would perform any "clipping" necessary. Ironically, VDI commands sent to, or read from, a disk drive might actual "calls" or some other "script" which can be directly executed or interpreted by the computer via a simple "cat" command. The VDI/Kernal interchange format could be very much proprietary. GEM's VDI commands, Mac's "Quickdraw", and Intuition's VDI are quite different, but funtionally they are practically identical. OS-9 simply "interprets" VDI commands similar to those of "Plot" on UNIX. Unlike UNIX however, the output is sent to a "mounted driver" rather than a "pipe" with it's blocking and context switching overhead. The end result, a full blown, fully interactive graphics system. To give a simpler example, "curses" and "termcap" are used to convert commands like "position curser" and "Insert lines" into "terminal commands" found in the "/etc/termcap" file. On OS-9, you could just as easily mount the "VT-100 Driver" into your "environment" and have the curses commands converted directly into curser motion. In the case where a terminal does not have "insert line" but has "set scrolling window" and "scroll window", these primitives could be used instead of the driver. If the screen were memory mapped, the "driver" could directly manipulate the the screen as needed by the "curses" calls. Of course, you could still use the normal curses/termcap technique if that was the driver installed. Now the main point is that VDI can go both ways. For example, you could put NAPLPS in, and get VDI out, or vice-versa. All you would need to do is decide which format your computer host wanted the "drive" to send.
jimomura@lsuc.UUCP (Jim Omura) (05/16/86)
OK. VDI isn't as bad as I thought. The explanation I got
earlier seems to have been for the IBM GKS. How thorough is VDI?
NAPLPS is extensible and already defined for 3 dimensional work.
It's current resolution is up to 4K by 4K and is conceptually
relative based on a 1 * 1 (* 1) screen (a "unit screen"). There
are complete character sets including symbols for Copyrights and
Trade Marks. There are graphics characters and color and texture
capabilities. You can buy NAPLPS terminals (Sony has a particularly
nice one) or convert many Personal Computers such as IBM's and Apples
and Commodore 64's (this latter isn't apparently a wonderful
NAPLPS machine, but it's adequate).
It seems to me that they overlap in philosophy at the least.
--
James Omura, Barrister & Solicitor, Toronto
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura
(416) 652-3880aglew@ccvaxa.UUCP (05/20/86)
>/* Written 7:19 pm May 15, 1986 by jimomura@lsuc.UUCP */ > > OK. VDI isn't as bad as I thought. The explanation I got >earlier seems to have been for the IBM GKS. How thorough is VDI? >NAPLPS is extensible and already defined for 3 dimensional work. >It's current resolution is up to 4K by 4K and is conceptually >relative based on a 1 * 1 (* 1) screen (a "unit screen"). There >are complete character sets including symbols for Copyrights and >Trade Marks. There are graphics characters and color and texture >capabilities. You can buy NAPLPS terminals (Sony has a particularly >nice one) or convert many Personal Computers such as IBM's and Apples >and Commodore 64's (this latter isn't apparently a wonderful >NAPLPS machine, but it's adequate). > > It seems to me that they overlap in philosophy at the least. Actually, NAPLPS is infinite precision. The 4K standard, and similar earlier standards, are just sets of minimum parameters that terminal designers should hope to have. A 4K page on a 256 terminal will draw properly, although all the text sizes you used may not be there so you might get some ugly wrappings, etc. NAPLPS's character sets are fairly complete, especially when you are using the kanji extensions. NAPLPS on an IBM is quite good, especially with the Revolution 9 or similar graphics board. I have heard a rumour that the NAPLPS package for the Commodore 64 is free, or at least sold at some extremely low price like 10$. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms