mm65+@andrew.cmu.edu (Michael Scott McMahon) (02/18/88)
Howdy y'all,
Does anyone know of, or is anyone working on, a Unix OS for the //?
Certainly it would be a recent development, since the only system that would
be capable of supporting it is a //gs or a supercharged //e.
This is one of those "no need to reinvent the wheel" deals.
Danke,
Mikey
mm65@andrew.cmu.edu
[Only one address! Sniffle...]jordan%lvvb.span@SDS.SDSC.EDU (RICH) (02/18/88)
Why work on a Un*x for the //s? In a while Apple will have A/UX out, and all we'll need is a Mac 2 emulator! :-) Seriously, I don't think I'd want one until a faster processor (say 6 - 8 MHz was available in a GS. An accelerated 6502 would impose (I think) too many architectural restrictions. It seems likely that a Un*x on the //s would have fixed or limited process address spaces (no virtual memory) due to lack of hardware memory management support. Does anyone know what the actual data transfer rate is for SCSI hard disks like the CMS SD60 or the Sider D40 (sic) when attached to a //GS? The flyers list seek time and such, but don't mention the transfer rate. Rich Richard Jordan SAIC Las Vegas <jordan%lvva.span@sds.sdsc.edu> Disclaimer: The opinions reflected above are my own and do not necessarily reflect the opinions of SAIC or the U.S. Gov't etc...
ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) (02/19/88)
Minix is probably about as close as you will get.
I don't have a GS, but if I get a 65816 board for my ]['s I'll try it.
I hate porting assembly code, and some of Minix is in 8088 assembly.
--
- Ralph W. Hyre, Jr.
Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PAgwyn@brl-smoke.ARPA (Doug Gwyn ) (02/19/88)
In article <cW6RxIy00VoDgIk0V6@andrew.cmu.edu> mm65+@andrew.cmu.edu (Michael Scott McMahon) writes: > Does anyone know of, or is anyone working on, a Unix OS for the //? I don't think anyone is working on quite that. I've given considerable thought to what is possible versus what would be desired, and have concluded that it would be better to provide a UNIX-like command, programming, and execution environment rather than a UNIX clone. This is primarily because of the need to support the built-in loading, memory allocation, etc. in the IIGS ROM, which assumes ProDOS is available. Because ProDOS supports a hierarchical directory system similar to UNIX's, I think it could be used for file management in a UNIXy environment. The main lossage is that there doesn't seem to be any really good way to support preemptive multitasking, although with some explicit scheduling hooks it could be emulated to some degree. Personally I would be satisfied with an APW shell that more resembled the UNIX environment instead of VMS or whatever their model was.
whitney@think.COM (David Whitney) (02/19/88)
In article <880218153959.21c039ee@Sds.Sdsc.Edu> jordan%lvvb.span@SDS.SDSC.EDU (RICH) writes: >Seriously, I don't think I'd want one until a faster processor (say 6 - 8 >MHz was available in a GS. Watch for MDIdeas' GSx card - runs things at 5.6MHz. I saw a blurb for it in the winter 1988 edition of the Apple //gs Buyer's Guide. There's also what may come from Apple, as it has been noted that they have been buying large quantities of 12MHz 65816s... >many architectural restrictions. It seems likely that a Un*x on the //s >would have fixed or limited process address spaces (no virtual memory) due >to lack of hardware memory management support. Watch for an implementation of MINIX (lots o talk on it in comp.sys.minix). Somebody is probably working on it (hello?? anybody doing this? hint hint :-) >Does anyone know what the actual data transfer rate is for SCSI hard disks >like the CMS SD60 or the Sider D40 (sic) when attached to a //GS? The flyers >list seek time and such, but don't mention the transfer rate. Transfer rate is awful mighty high. Much higher than the Apple // or even Macs (mac II not included) can compare to. For the most part, a hard drive is waiting for the computer - not the other way around. I have a ProAPP 20S, and the tech guy said that transfer rate for it is 5Mbit/sec. He then said that the Mac II is the only Apple-type computer that would be able to keep up with that... He didn't mention other brands. David Whitney, MIT '90 Still learning about my Apple //GS {the known universe}!ihnp4!think!whitney and all of its secrets. Any and all whitney@think.com technical info appreciated. DISCLAIMER: You didn't actually believe all that, did you?
buyse@convexe.UUCP (02/20/88)
I don't believe that any of the current II family is up to pre-emptive
multitasking. In addition to greater (possibly) ROM support or Prodos
routine support, there simply isn't the speed, and I don't believe the
architecture was designed with multitasking in mind.
The very least that would be helpful would be 2-3 times the processing
speed. Does anyone know if this is on the horizon?
-Russell Buyse.
UUCP: {allegra,ihnp4,uiucdcs,ctvax}!convex!buysejm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness") (02/20/88)
Doug Qwyn writes... > I've given considerable thought to what is possible versus what would be >desired, and have concluded that it would be better to provide a UNIX-like >command, programming, and execution environment rather than a UNIX clone. >This is primarily because of the need to support the built-in loading, >memory allocation, etc. in the IIGS ROM, which assumes ProDOS is available. >Because ProDOS supports a hierarchical directory system similar to UNIX's, >I think it could be used for file management in a UNIXy environment. The >main lossage is that there doesn't seem to be any really good way to >support preemptive multitasking, although with some explicit scheduling >hooks it could be emulated to some degree. This may not seem like much, but Kyan's Kix shell that came with Kyan pascal could be used to do just this. All input is assumed to be a prodos execute-file command. "prefix" for example, would be a command file called prefix that changes the directory. "Prefix" can be renamed to, say, "cd" like in UNIX. What's nice about Kyan is that the shell itself is extremely small. The trouble is, I have not heard anything about the promised 16-bit version of Kix for a long, long time. Too bad... it promised things like batch file support, multiple command input, etc. Anyone know what happenned to Kyan? Sincerely, Capt. Albatross
blume@netmbx.UUCP (Heiko Blume) (02/21/88)
i would be *very* interested too...(i have a supercharged //e :-).
the only multitasking OS i heard of is (sniffle too..) smalltalk-pc...
which i didnt succeed to get my hands on yet...its hard if you want to
spend money & cant get contact to the outlet :-(((( i hate it...
--
Heiko Blume # DOMAIN: blume@netmbx.UUCP { BITNET: ( mixed }
Seekorso 29 # BANG : ..!{backbone}!netmbx!blume
D-1000 Berlin 22, West-Germany # Phone : (+49 30) 365 55 71 or ... 365 75 01
Telex : 183008 intro d # Fax : (+49 30) 882 50 65 lwv@n8emr.UUCP (Larry W. Virden) (02/22/88)
I would like to see any technical writeups which describe the hardware deficienies in the 65816 which prevent preemptive multitasking. You see, I have seen lots of writeups saying that the 65816 is faster than 8088's, etc. and I KNOW that Unix version 6 ran on the oldest PDP 11's, which were no speed daemons themselves. So if minix, venix, etc. can run on these junky little ibms, then why in the world couldnt it be ported to the 65815 with an address space of 8+ meg!!! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 cbosgd!n8emr!lwv (UUCP) cbosgd!n8emr!lwv@PSUVAX1 (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.
buyse@convexe.UUCP (02/24/88)
I don't believe that there is any intrinsic limitation of the 65c816
processor that would prevent it from being the cpu of a Unix-like
operating system. However, the requirements for efficient pre-emptive
multitasking are more than those just on the central processor. The
entire architecture of the machine has to be built with an eye on
multitasking. Multitasking OS's are incredibly complex and are very
demanding on on the computer's resources. Just the context switch
requires a fair amount of fiddling.
-Russell Buyse.
UUCP: {allegra,ihnp4,uiucdcs,ctvax}!convex!buyseralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre) (02/25/88)
In article <452@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes: > >I would like to see any technical writeups which describe the hardware >deficienies in the 65816 which prevent preemptive multitasking. You see, >I have seen lots of writeups saying that the 65816 is faster than 8088's, >etc. and I KNOW that Unix version 6 ran on the oldest PDP 11's, which were >no speed daemons themselves. So if minix, venix, etc. can run on these >junky little ibms, then why in the world couldnt it be ported to the 65815 >with an address space of 8+ meg!!! No reason. The 8088 has more general purpose registers, and compiler technology is more mature (anyone want to port GCC to the 65816?) Until I get a 65816 (and C compiler for it), I don't have much incentive to try the port, though. I'd be happier with something designed with bank-switching in mind, since I have two CPU's (6502 in //e, Z80 in PCPI AppliCard) that can do that. Even C-64's and C-128's can do bank-switching. CP/M 3.0 machines can bank switch. Potentially large but somewhat fragmented market out there. Bank switching is also better protection than segments, at least. -- - Ralph W. Hyre, Jr. Internet: ralphw@ius2.cs.cmu.edu Phone:(412)268-{2847,3275} CMU-{BUGS,DARK} Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA