rkn@ulowell.UUCP (11/22/86)
Is anyone aware of a unix port for the amiga? Either finished or in progress. ---------------------------------------------------- Roger Stoller, rkn@ornl-msr.arpa, (615) 576-7886 Oak Ridge National Laboratory, Oak Ridge, TN. 37830 ----------------------------------------------------
swalton@well.UUCP (Stephen R. Walton) (11/24/86)
In article <781@ulowell.UUCP> rkn@ORNL-MSR.ARPA (Roger E. Stoller 576-7886) writes: >Is anyone aware of a unix port for the amiga? Either finished or in progress. This seems as good a time as any to post this. Andrew Tanenbaum has just finished a very tiny UNIX Version 7 workalike called MINIX, which will be available in January from Prentice Hall Software for $80, INCLUDING SOURCE!! While it implements all the UNIX system calls, it is implemented as a set of four interlocking servers, all written in C and communicating via message passing in the best object-oriented philosophy. One of the many advantages of this approach is that you can probably port parts of it (like the file server, for example) to get some UNIX-like features on your Amiga. How tiny? Well, you can buy a version which will run on a 256K PC/XT with 1 floppy. You can't "cc" with this combination, though; for that, you'd need 640K and two floppies. Sounds like a candidate for Amiga porting; a generic 68000 version of MINIX is under development right now. For you OS hackers, Tanenbaum is giving a paper on MINIX's design at USENIX in January.
drh@spock.uucp (D. Ryan Hawley) (02/01/88)
Cheers, There has been some debate about Unix availability for the Amiga. I know this is speculation but, Commodore did bring an Amiga to Comdex, with a 68020. What is your reading, do any of you know something I dont? I like the Amigados cli interface, but would love a csh, or ksh interface, and the UNIX utilities like more, grep, etc. What kind of response do you Amiga users feel this will receive. I've heard a bit about "csh" like interfaces already available. What's available? D. Ryan Hawley "And they will fly with the wings of eagles"
chanst@atrium.UUCP (Steve T Chan) (02/03/88)
In article <33396@spock.uucp>, drh@spock.uucp (D. Ryan Hawley) writes: > Cheers, > > There has been some debate about Unix availability for the Amiga. > I know this is speculation but, Commodore did bring an Amiga to > Comdex, with a 68020. What is your reading, do any of you know > something I dont? I like the Amigados cli interface, but would > love a csh, or ksh interface, and the UNIX utilities like more, > grep, etc. What kind of response do you Amiga users feel this > will receive. I've heard a bit about "csh" like interfaces already > available. What's available? > I'd like to see a csh for the Amiga.. also the 'login' capability.. I think that won't be too tough to do.. -------------------- +----------------------------------------------------------------------+ | Steve Chan UUCP: gatech!petro!atrium!chanst | | @ Atrium @ The Alamo ARPA: atrium!chanst@rutgers.edu | | San Antonio, Texas BITNET: rutgers!atrium!chanst@cunyum | | | | 'If you put your minds to it, you could accomplish anything!' - Doc | +----------------------------------------------------------------------+
spencer@eris (Randal m. Spencer [RmS]) (02/03/88)
Recently on *comp.sys.amiga* drh@spock.uucp (D. Ryan Hawley) wrote: ...Cheers, ... ...There has been some debate about Unix availability for the Amiga. ...D. Ryan Hawley I don't know about the actual availability of Unix on the Amiga, I think that would be quite a project, and remember that there are those at Commodore who feel that if you want something on the A2000 you can always put it on the bridge card side of the world. I would love to see Unix on the Amiga and with all this '020 back and forth I would imagine that Unix can't be an impossibility. Infact, if Unix does make it out for the 2000 I may end up getting one of those suckers after all. That would be one of the first real uses that I would have for the 2000 over my beloved 1000s. I can survive without the [1|2] meg of chip ram, and any additional graphic features would HAVE to be emulated with some sort of SetFunction so that software would run on UnEnhanced Amigas (albiet slower). One question for any WC people who are still reading this message, what is happening with the supply of 1000 motherboards that we have sent back to you all these years? Are they getting repaired? Do they get stacked in a pile in the back forty? Is it possible for those of us sticking with the 1000 to get some of them cheap as kind of a PARTS machine(s)?
harald@leo.UUCP ( Harald Milne) (02/06/88)
In article <6836@agate.BERKELEY.EDU>, spencer@eris (Randal m. Spencer [RmS]) writes: > I don't know about the actual availability of Unix on the Amiga, I > think that would be quite a project, and remember that there are those > at Commodore who feel that if you want something on the A2000 you > can always put it on the bridge card side of the world. I would love > to see Unix on the Amiga and with all this '020 back and forth I would > imagine that Unix can't be an impossibility. Infact, if Unix does > make it out for the 2000 I may end up getting one of those suckers > after all. Unix on the bridge card? Ack! Where is my feather! I feel better now. With the A2620 (MMU included), UNIX would be trivial. If one wanted UNIX for the sake of UNIX, no problem at all. But if you wanted any hope of running ANY software you have now, this is not trivial. It's a huge pain/can of worms. Just what would you do with a UNIX that doesn't support the world of the Amiga? Would you be willing to have UNIX and no software. Well to be fair, you could /etc/shutdown and reboot a game. What would you do with the graphics, the sound, the, the.... Pretty heavy context switch, if you ask me. You could reinvent every application that currently exists for the Amiga! ACK! Or you could have a UNIX that is compatable! You know, run everything you have now! What a challenge! I would love to grapple with that one, just to see it done right. You know, the ultimate form of compatabitilty, run a game with realtime graphics, sound, controller response! Screw the reboot. Now that's the kind of UNIX I would like to see!!!! Or am I flashed off. Am I the ONLY person on the face of this planet that feels this way? Somebody have a gun and shut me up! -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Home of Regulus and hamiga) UUCP: uunet!ccicpg!leo!harald
langz@athena.mit.edu (Lang Zerner) (02/08/88)
In article <1869@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > > Or you could have a UNIX that is compatable! You know, run everything >you have now! What a challenge! I would love to grapple with that one, just >to see it done right. You know, the ultimate form of compatabitilty, run a >game with realtime graphics, sound, controller response! Screw the reboot. > > Or am I flashed off. Am I the ONLY person on the face of this planet >that feels this way? I think it would be a shame to force people to choose, and I also think that someone who wants Unix is mainly interested in the already existing power of Unix. I may be wrong, but it seems to me that since so much of the current Amiga environment is in ROM (i.e. system calls), it shouldn't be too difficult to have that environment running as a task under Unix, softwarily speaking. Stuff like disk formats, etc., are another story. Be seeing you... --Lang Zerner langz@athena.mit.edu ihnp4!mit-eddie!athena.mit.edu!langz "To be clever enough to get a great deal of money, one must first be stupid enough to want it." -- G.K. Chesterson
rogers@ncrcce.StPaul.NCR.COM (Bob Rogers) (02/08/88)
In article <2836@bloom-beacon.MIT.EDU> langz@athena.mit.edu (Lang Zerner) writes: >I may be wrong, but it seems to me that since so much of the current >Amiga environment is in ROM (i.e. system calls), it shouldn't be too difficult >to have that environment running as a task under Unix, softwarily speaking. >Stuff like disk formats, etc., are another story. I imagine that Amiga UNIX (A/UX?, nah - dumb name :-) ) would run on a 68020 board much like PC-DOS runs on the Bridge. Shouldn't you be able to use both Amiga DOS and UNIX at the same time (and PC-DOS, for that matter)? You could use a terminal emulator running under Amiga DOS to access the UNIX side of the machine. -- ----------------------------------------------------------------------------- Bob Rogers rogers@StPaul.NCR.COM NCR Comten, St. Paul, MN
peter@nuchat.UUCP (Peter da Silva) (02/10/88)
Hey, if apple can run mac-software-that-was-never-designed-with-multitasking- in-mind under UNIX, surely commodore can get a UNIX that supports well-behaved- amiga-software-in-protected-mode. UNIX *does* support shared memory segments, you know. AllocMem would have to be pretty hacked up, as would all the AmigaDOS junk... but intuition.library and all the standard devices should work OK with just a little care. A whole shitload of work on the pat of whoever sets it up... If you need a dedicated UNIX and Amiga fanatic to work on it, I'm not that cheap but I am enthusiastic :->/2. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
peter@nuchat.UUCP (Peter da Silva) (02/10/88)
In article ... rogers@ncrcce.StPaul.NCR.COM (Bob Rogers) writes: > I imagine that Amiga UNIX (A/UX?, nah - dumb name :-) ) would run on a 68020 > board much like PC-DOS runs on the Bridge. Shouldn't you be able to use > both Amiga DOS and UNIX at the same time (and PC-DOS, for that matter)? You > could use a terminal emulator running under Amiga DOS to access the UNIX > side of the machine. Please, if that's what C='s thinking of... don't do it. We need to get the reliability of UNIX for AmigaDOS applications. What happens to your UNIX coprocessor system when you get a Guru that could have been avoided by UNIX' memory management? It still wouldn't be as reliable as a plain vanilla UNIX implementation, 'cos of all the shared memory segments... but hopefully you could blow the AmigaDOS emulation out of the water and get back to plain UNIX if you did get a guru. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
morgan@brambo.UUCP (Morgan W. Jones) (02/11/88)
In article <2836@bloom-beacon.MIT.EDU> langz@athena.mit.edu (Lang Zerner) writes: >Amiga environment is in ROM (i.e. system calls), it shouldn't be too difficult >to have that environment running as a task under Unix, softwarily speaking. >Stuff like disk formats, etc., are another story. The natural solution to this problem is to have separate partitions for the AmigaDos and Unix portions of the system. Either that, or else have Unix load the program and pass it off to AmigaDos, but that would be a little more difficult. -- Morgan Jones - Bramalea Software Inc. ...!utgpu!telly \ !brambo!morgan ...!{uunet!mnetor, watmath!utai}!lsuc!ncrcan / "These might not even be my opinions, let alone anyone else's."
morgan@brambo.UUCP (Morgan W. Jones) (02/11/88)
In article <619@ncrcce.StPaul.NCR.COM> rogers@ncrcce.StPaul.NCR.COM (PUT YOUR NAME HERE) writes: >I imagine that Amiga UNIX (A/UX?, nah - dumb name :-) ) would run on a 68020 >board much like PC-DOS runs on the Bridge. Shouldn't you be able to use >both Amiga DOS and UNIX at the same time (and PC-DOS, for that matter)? The 68020 cards work in a completely different manner than the bridgecard. The bridgecard has its own bus, and runs concurrently with the 68000. The 68020 runs on the 68000 bus, and as a rusult runs INSTEAD of the 68000. As a result, you could never run the 68000 and the '20 at the same time. About the only way that you could get around this is to install another bus to be used by the '20. -- Morgan Jones - Bramalea Software Inc. ...!utgpu!telly \ !brambo!morgan ...!{uunet!mnetor, watmath!utai}!lsuc!ncrcan / "These might not even be my opinions, let alone anyone else's."
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/16/88)
In article <647@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > It still wouldn't be as reliable as a plain vanilla UNIX implementation, 'cos > of all the shared memory segments... but hopefully you could blow the AmigaDOS > emulation out of the water and get back to plain UNIX if you did get a guru. Good point Peter, I should be possible to create a virtual memory space that duplicated the existing Amiga memory space. Some fooling of the kickstart into believing that there was only 'nK' of memory where n >= 512 might be necessary. The exception handlers (the fastest way to the big G) would of course be handled by UNIX and they could pop you into a UNIX process that was debugging the AmigaDOS memory image. One bit of subterfuge that may be required would be a hook into the UNIX process scheduler that would give the AmigaDOS process higher priority (so it could run when it wanted to and act like a 'real' Amiga). Anyone besides me that would rather see a Memory protected, virtual address space AmigaDOS that can run 'old fashioned' in a separate Task? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
harald@leo.UUCP ( Harald Milne) (02/17/88)
In article <41976@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > In article <647@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > > It still wouldn't be as reliable as a plain vanilla UNIX implementation, 'cos > > of all the shared memory segments... but hopefully you could blow the AmigaDOS > > emulation out of the water and get back to plain UNIX if you did get a guru. > > Good point Peter, I should be possible to create a virtual memory space that > duplicated the existing Amiga memory space. Some fooling of the kickstart into > believing that there was only 'nK' of memory where n >= 512 might be necessary. Creating a memory space is not a problem, but how can you run a multi tasking Amiga on a multi-tasking Unix base? Together? You can not run the Amiga environment as seperate process entities, just because of the way the Amiga passes messages to tasks by pointer. No sharing here, the whole environment has to exist in one environment. Well you could modify UNIX to allow this SHARED action, but debugging, and a host of other nasties would become complicated. (But not impossible) > The exception handlers (the fastest way to the big G) would of course be > handled by UNIX and they could pop you into a UNIX process that was debugging > the AmigaDOS memory image. I mentioned this idea before, but there are a lot of problems here. One, UNIX handles machine resources just as Exec does, they BOTH can't! One or the other has to be in control, and this case, it would be logical that UNIX wins for obvious reasons. > One bit of subterfuge that may be required would > be a hook into the UNIX process scheduler that would give the AmigaDOS process > higher priority (so it could run when it wanted to and act like a 'real' > Amiga). Jeez come on now. I have been kicking this idea around for 2 months with nothing but silence. You need a lot of hooks and a specially modified UNIX to accomplish this. Remember, we are now going to SHARE resources! > Anyone besides me that would rather see a Memory protected, virtual > address space AmigaDOS that can run 'old fashioned' in a separate Task? Yessir! Just so long it doesn't take 1 minute to run the Amiga task from UNIX like the MacII under AUX! ACK! Like I said, realtime, transparent! > --Chuck McManis > uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com > These opinions are my own and no one elses, but you knew that didn't you. -- Work: Computer Consoles Inc. (CCI), Advanced Development Group (ADG) Irvine, CA (RISCy business! Was an Amiga, now an AT, ACK! BARF!) UUCP: uunet!ccicpg!leo!harald
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/19/88)
In article <1907@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > Creating a memory space is not a problem, but how can you run a multi > tasking Amiga on a multi-tasking Unix base? Together? You can not run the > Amiga environment as seperate process entities, just because of the way the > Amiga passes messages to tasks by pointer. He goes, on but mostly because I wasn't clear in what I wrote. The idea is similar to the virtual machine idea's thrown about into the world in the early 70's. It's like this : *One* UNIX process becomes a *One* virtual Amiga 500/1000/2000. When that process is running the virtual amiga exists, when it is not running the virtual amiga doesn't exist. You can run multiple psuedo amiga *tasks* in one *UNIX* process. If that process is get 50% of the cycles then it will run half as fast as a 'real' Amiga. All of those tasks running together are in the same address space (because they are *one* UNIX process) and can share messages to their hearts content. Calls to exec devices (trackdisk, narrator, serial, etc) get handed off to UNIX to service. Mallocs and such simple grab memory in that one address space, and nothing else has to change. The disadvantage to this technique is that it is slow, primarily because you are running a scheduler within a scheduler, and the psuedo Amiga does not get all of the cycles it might want. If the new processor is running 4 times faster (say like a fast '020 or '030) then you may actually get original Amiga speed out of one psuedo amiga. When the psuedo Amiga 'Gurus' the UNIX O/S dumps its core and frees up all of its resources (it can do that because it has an MMU and is tracking resource usage). You the adventerous programmer can then use adb to figure out what died (or maybe a UNIX version of Wack). It is crufty but it offers that all important backward compatibility. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
peter@nuchat.UUCP (Peter da Silva) (02/21/88)
In article <272@brambo.UUCP>, morgan@brambo.UUCP (Morgan W. Jones) writes: > The natural solution to this problem is to have separate partitions > for the AmigaDos and Unix portions of the system. Either that, or else > have Unix load the program and pass it off to AmigaDos, but that would > be a little more difficult. The natural solution is to replace AmigaDOS with an alternate handler that talks to UNIX and pretends to be AmigaDOS. xDThat should be *much* easier than any of the alternatives, particularly given the ease by which you can replace chunks of the Amiga operating system. The easiest way of doing this would be to have a handler (UNIX:?) and make UNIX:/usr/whoever sys:. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
terry@wsccs.UUCP (terry) (02/23/88)
In article <2836@bloom-beacon.MIT.EDU>, langz@athena.mit.edu (Lang Zerner) writes: > In article <1869@leo.UUCP> harald@leo.UUCP ( Harald Milne) writes: > > > > Or you could have a UNIX that is compatable! You know, run everything > >you have now! What a challenge! I would love to grapple with that one, just > >to see it done right. You know, the ultimate form of compatabitilty, run a > >game with realtime graphics, sound, controller response! Screw the reboot. > > > > Or am I flashed off. Am I the ONLY person on the face of this planet > >that feels this way? You are flashed off. A 68000 can not run protected memory. This would limit you to SysIII and it's derivatives (Tandy 6000 style Xenix, etc). Just because the only place you have to worry is a stack grow doesn't mean that you don't want an mmu. There is a lot of code for the NCR/Sperry/Unisys boxes that I'd like to run. Of course you could always replace the 68000 with a 68010 ($20 or so with shipping), but that would mean you are no longer safe with some games doing a MPSW. > I think it would be a shame to force people to choose, and I also think that > someone who wants Unix is mainly interested in the already existing power of > Unix. I may be wrong, but it seems to me that since so much of the current > Amiga environment is in ROM (i.e. system calls), it shouldn't be too difficult > to have that environment running as a task under Unix, softwarily speaking. > Stuff like disk formats, etc., are another story. Mostly already existing software, actually. It would also make it a business (gasp!) machine. As far as getting a UNIX up on top of the ROM bios, good luck. I'm not saying it couldn't be done, but it would be a bugger. You would probably have more success at VMS-- the programmer interface is very similar (unfortunately. Lot of overhead for a small machine). | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
terry@wsccs.UUCP (terry) (02/26/88)
In article <645@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: > Hey, if apple can run mac-software-that-was-never-designed-with-multitasking- > in-mind under UNIX, surely commodore can get a UNIX that supports well-behaved > amiga-software-in-protected-mode. If by UNIX, you mean Berkley $.3 or SystemV.3, not a snowballs chance. Commodore, in it's infinite wisdom, use the 68000 chip, not a 68010, so the Amiga can't run a vmunix... it can't support an MMU. Tandy was able to get a Xenix up on their model 16 and the model 6000 (both 68000 boxes), but it was an OEM from Microsoft, and they don't usually part with code, let alone something BB (Big Blue? ...Big Brother?) might consider back-stabbing. It is a very inteligent decision on the part of Microsoft... an intelligent *business* decision. Besides, everyone knows Xenix is fixed SystemIII with nifty things AT&T is only now coming out with. It might be possible to run protected *IF* you replaced your 68000 with a 68010. If by "well-behaved", you mean compatable with the idea of not doing the nasty-no-no (MPSW), workbench fails that test. Try replacing your 68000 with a 68010 and adding something using the desk calculator. > UNIX *does* support shared memory segments, you know. AllocMem would have > to be pretty hacked up, as would all the AmigaDOS junk... but > intuition.library and all the standard devices should work OK with just a > little care. The amount of care required by such a task (get it? 'task'?) is more than adequately summed up by your next sentence: > A whole shitload of work on the pat of whoever sets it up... > If you need a dedicated UNIX and Amiga fanatic to work on it, I'm not that > cheap but I am enthusiastic :->/2. I'm not cheap either, but it's a nifty idea... I think I'd want to be able to run something like NCR tower software or some other systems before going off and hacking a hell of a lot of code I can't run anything on and that noone would buy enough of for that deficiency. AT&T is charging a good $65,000 for a source liscence to SysV for the 3B2, and that isn't even the most recent version. I'd have to be able to at least recoup my investment... | Terry Lambert UUCP: ...!decvax!utah-cs!century!terry | | @ Century Software or : ...utah-cs!uplherc!sp7040!obie!wsccs!terry | | SLC, Utah | | These opinions are not my companies, but if you find them | | useful, send a $20.00 donation to Brisbane Australia... | | 'There are monkey boys in the facility. Do not be alarmed; you are secure' |
peter@nuchat.UUCP (Peter da Silva) (02/28/88)
In article <183@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes: > You are flashed off. A 68000 can not run protected memory. Who's flashed off? The 68000 runs protected memory just fine. I won't run demand paged virtual memory, but... PROTECTED MEMORY DOES NOT MEAN DEMAND PAGED VIRTUAL MEMORY!!!!!!!! Just because you have to be careful of your stack (compile in probes on function calls with big locals, etc...) doesn't mean it's bogus or limited to SYSIII. We're running System V on a dual 68000 system at work. An Arete/Sperry box. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
eric@hector.UUCP (Eric Lavitsky) (03/01/88)
In article <197@wsccs.UUCP> terry@wsccs.UUCP writes: >In article <645@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: >> Hey, if apple can run mac-software-that-was-never-designed-with-multitasking- >> in-mind under UNIX, surely commodore can get a UNIX that supports well-behaved >> amiga-software-in-protected-mode. > > If by UNIX, you mean Berkley $.3 or SystemV.3, not a snowballs chance. >Commodore, in it's infinite wisdom, use the 68000 chip, not a 68010, so the >Amiga can't run a vmunix... it can't support an MMU. Tandy was able to get I think the idea is to run Unix when you have an A2620 in your machine - that's Commodore's 68020 board with the 68851 PMMU... You can also sell a Unix that wants a 68010 for the Amiga, simply include the chip as part of the package. > If by "well-behaved", you mean compatable with the idea of not doing >the nasty-no-no (MPSW), workbench fails that test. Try replacing your 68000 >with a 68010 and adding something using the desk calculator. What? - are you still running 1.1? This bug has been fixed since 1.2 came out... > The amount of care required by such a task (get it? 'task'?) is more >than adequately summed up by your next sentence: > >> A whole shitload of work on the pat of whoever sets it up... > >> If you need a dedicated UNIX and Amiga fanatic to work on it, I'm not that >> cheap but I am enthusiastic :->/2. I'm sure some large organization like Commodore might consider the task one that they could handle... I seem to remember that they had Unix developers in house for the now defunct Commodore 900 series. You don't need to spend the money on development... Eric ARPA: eric@topaz.rutgers.edu "Lithium is no longer available UUCP: ...{wherever!}ulysses!eric on credit..." ...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854
ross@swan.ulowell.edu (Ross Miller) (03/01/88)
In article <197@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: ... lots of stuff deleted ... > If by "well-behaved", you mean compatable with the idea of not doing >the nasty-no-no (MPSW), workbench fails that test. Try replacing your 68000 >with a 68010 and adding something using the desk calculator. ... lots of stuff deleted ... Just checked. Works fine. But even if it didn't, I have never had anything guru on a priviledge problem, save brain dead games, if I run the public domain DeciGel trap handler. Many thanks to this author by the way. Lately I don't even bother running it and nothing that I have crashes. Ross -- csnet: ross@swan.ulowell.edu uucp: ross@swan.ulowell.edu || ...harvard!ulowell!ross Trust the computer. The computer is your friend.
schein@cbmvax.UUCP (Dan Schein CATS) (03/01/88)
In article <5167@swan.ulowell.edu> ross@swan.ulowell.edu (Ross Miller) writes: >In article <197@wsccs.UUCP> terry@wsccs.UUCP (terry) writes: >... lots of stuff deleted ... >> If by "well-behaved", you mean compatable with the idea of not doing >>the nasty-no-no (MPSW), workbench fails that test. Try replacing your 68000 >>with a 68010 and adding something using the desk calculator. > If you are using AmigaDOS V1.1 *AND* a 68010, then doing a "*" will cause a visit from the Guru. >Just checked. Works fine. > If you are using AmigaDOS V1.2 *AND* a 68010, then doing a "*" will not cause a vist from the Guru. > >But even if it didn't, I have never had anything guru on a priviledge >problem, save brain dead games, if I run the public domain DeciGel >trap handler. Many thanks to this author by the way. At home I use a 68010 and find that the most common Guru makers are games! I run DeciGel all the time on almost anything, (kind of a habit I guess), and it is a great little Guru saver. > Lately I don't even bother running it and nothing that I have >crashes. > Just think what would have happened if the SCA virus would not run with a 68010 :-) :-) > Ross -- Dan Schein uucp: {ihnp4|allegra|burdvax|rutgers}!cbmvax!schein Commodore AMIGA ARPANET: cbmvax!schein@uunet.uu.net 1200 Wilson Drive Bix: dschein Plink: Dan*CATS West Chester PA 19380 phone: (215) 431-9100 ext. 9542 +----------------------------------------------------------------------------+ All spelling mistakes are a result of my efforts to avoid education :-) +----------------------------------------------------------------------------+ I help Commodore by supporting the AMIGA. Commodore supports me by allowing me to form my own suggestions and comments.
peter@nuchat.UUCP (Peter da Silva) (03/03/88)
In article <197@wsccs.UUCP>, terry@wsccs.UUCP (terry) writes: > If by UNIX, you mean Berkley $.3 or SystemV.3, not a snowballs chance. > Commodore, in it's infinite wisdom, use the 68000 chip, not a 68010, so the > Amiga can't run a vmunix... it can't support an MMU. The 68000 supports an MMU just fine. It doesn't support demand paged virtual memory, but it supports an MMU just fine. I've done a lot of work with 68000 based UNIX. In fact I'm using a 68000 based UNIX box from Arete at work right now. And, of course, there's no reason you couldn't require a 68020 with the UNIX if you're a demand-paging bigot. Myself, I'd rather just add more real memory. Virtual memory means virtual performance. Real time systems like Amy don't like VM at all... > Tandy was able to get > a Xenix up on their model 16 and the model 6000 (both 68000 boxes), but it > was an OEM from Microsoft, and they don't usually part with code, let alone > something BB (Big Blue? ...Big Brother?) might consider back-stabbing. Don't judge the 68000 but the Tandy 6000. They deliberately crippled the MMU in the box. > Besides, everyone knows Xenix is fixed SystemIII with > nifty things AT&T is only now coming out with. Xenix is Version 7 (not System III) with a couple of minor improvements and a bunch of business-oriented features of dubious value, tricked out to look like it's System III. > It might be possible to run > protected *IF* you replaced your 68000 with a 68010. You need a seperate MMU to run protected mode whether you get a 68000, a 68010, or a 68020. > If by "well-behaved", you mean compatable with the idea of not doing > the nasty-no-no (MPSW), workbench fails that test. Try replacing your 68000 > with a 68010 and adding something using the desk calculator. The calculator is not part of the Workbench. It's a separate program. By "well behaved", I mean not allocating message buffers on the stack; always using MEMF_PUBLIC with AllocMem; not using processor-specific instructions; not diddling around in private data structures, and so on. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
shimoda@rmi.UUCP (Markus Schmidt) (03/19/88)
Hi all!
Maybe a dream comes true?!?!
Today I spoke with a friend, who was at the big computerfair (CEBIT)
in Hannover yesterday.
He told me, that CA had a UNIX-card for an A2000 there!!
Maybe he got fooled or hell knows what but if this would be true ....
Unix running on an 68020 in an Workbechwindow (maybe like PC-Window).
He was told that the cost would be DM 1.500 (about $850).
*Nothing of this is verified, maybe someone else knows something!*
C u
Markus
(shimoda@rmi.UUCP)
|._,|
- -
==O== Never trust a smiling cat
`-'brianm@sco.COM (Brian Moffet) (04/28/88)
Why would I like to see Unix on the Amiga? Well, I own an
Amiga 1000. I have owned this beast since Jan of 86
and I really like it. I was able to do work on my math
thesis (analytical ray tracing of algebraic surfaces)
on the machine when it had only 512K RAM an 2 floppies. I think
it is a wondeful machine.
However, things that *NIX has (personnaly, I like SYS V)
The devices for a *Nix system have a consistant interface
for basic work. For the most part, almost all devices
can be treated as files. This allows the ability to
do backups to almost any media your machine has a driver
for, without the backup knowing anything special about
your device (backup 0uf /dev/console :-) )
The memory managment capabilities are good. As stated before,
you don't really need *nix for this.
The versatility of *nix is outstanding. The power of shell commands
when you don't want to write a program (compiled).
Large User Base: Yes, there is a fairly large user base out there.
Multiuser support: This is good for things like UUCP connections.
I have the version of UUPC for the Amiga, I really do use it.
but *nix has a much better tested version.
Networking Standards: Well, sort of standards. The key point is lots
of people use a common TCP/IP Ethernet under *nix.
By having Unix with a TCP/IP connection, I could connect to
the Local University VAX say, and be able to transport data
file between my amiga and the Sun. This would be nice.
Yes, A lot of this stuff is out for the amiga. I just wish I could
afford it all. However, *nix allows the user a much richer command
set and much more power than I have seen in any other PC OS.
--
Brian Moffet brianm@sco.com {uunet,decvax!microsof}!sco!brianm
The opinions expressed are not quite clear and have no relation to my employer.
'Evil Geniuses for a Better Tommorrow!'cmcmanis%pepper@Sun.COM (Chuck McManis) (05/03/88)
In article <517@viscous> brianm@sco.COM (Brian Moffet) writes:
->However, things that *NIX has (personnaly, I like SYS V)
->
->The devices for a *Nix system have a consistant interface
-> for basic work. For the most part, almost all devices
-> can be treated as files. This allows the ability to
-> do backups to almost any media your machine has a driver
-> for, without the backup knowing anything special about
-> your device (backup 0uf /dev/console :-) )
This is a function of the backup program and *not* UNIX* per se.
All AmigaDOS devices have a consistent interface at the exec level.
Therefore this problem reduces to a SMOP (simple matter of programming :-))
->The memory managment capabilities are good. As stated before,
-> you don't really need *nix for this.
You need an MMU for good intertask memory protection and I agree that UNIX
is not required for this.
->The versatility of *nix is outstanding. The power of shell commands
-> when you don't want to write a program (compiled).
Again a SMOP. Write a shell that does what the UNIX shell does. Dillon/Drew
shell does this. I saw one at DevCon (Tshell) that is extremely flexible too.
->Large User Base: Yes, there is a fairly large user base out there.
For UNIX? Yes and no. There are probably more machines running AmigaDOS
than there are running UNIX by now (Amiga installed base was given at
600,000+ at the DevCon, Adding up all of the workstations (about 200,000)
and all of the Vaxes (about 75,000) and all of the Tandy Xenix boxes
(Another 100,000) and giving 100,000 for misc stuff we are still under
600,000) Of course UNIX machines can and do often have several users.
[Note this is much hand waving and should not be considered the definitive
estimate for all installed machines running UNIX or UNIX derivatives]
Besides, and this is the main point, both the top C compilers are getting
to the point where most UNIX programs will compile and run with no changes.
->Multiuser support: This is good for things like UUCP connections.
-> I have the version of UUPC for the Amiga, I really do use it.
-> but *nix has a much better tested version.
Time will cure this.
->Networking Standards: Well, sort of standards. The key point is lots
-> of people use a common TCP/IP Ethernet under *nix.
-> By having Unix with a TCP/IP connection, I could connect to
-> the Local University VAX say, and be able to transport data
-> file between my amiga and the Sun. This would be nice.
The Ameristar folks have all the TCP/IP stuff you need to port your
UNIX programs to the Amiga.
->Yes, A lot of this stuff is out for the amiga. I just wish I could
->afford it all. However, *nix allows the user a much richer command
->set and much more power than I have seen in any other PC OS.
Again a SMOP, check out the tshell, it looked like it addresses the
commands issue.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.brianm@sco.COM (Brian Moffet) (05/03/88)
In article <51577@sun.uucp>, cmcmanis%pepper@Sun.COM (Chuck McManis) writes: > In article <517@viscous> brianm@sco.COM (Brian Moffet) writes: > > ->However, things that *NIX has (personnaly, I like SYS V) > -> > ->The devices for a *Nix system have a consistant interface > -> for basic work. For the most part, almost all devices > -> can be treated as files. This allows the ability to > -> do backups to almost any media your machine has a driver > -> for, without the backup knowing anything special about > -> your device (backup 0uf /dev/console :-) ) > > This is a function of the backup program and *not* UNIX* per se. > All AmigaDOS devices have a consistent interface at the exec level. > Therefore this problem reduces to a SMOP (simple matter of programming :-)) Yes, they all have the same command set at the exec level, except that most have some additional quirky stuff. I guess that could be classified similar to ioctl(S) calls in *nix. However, 1 major point that I have lamented silently over is not being able to call fd = open( "df1:", O_RDWR ); and have it work. I have tpo go in and lay down the data myself. If you have gotten this to work, then let me know by all means. :-) I would like to be able to have a _any_ program read and write to _any_ device. *nix is the only OS I have seen do this. I do not want to call opendevice() and all that other rot. I guess I am a lazy programmer, in that I want system calls to handle most of the work. > > Time will cure this. But I want it now!! (pout and all that stuff ) :-) I agree that time will cure a lot of things, but I like most people am sort of impatient. (even though it's taken me 2.5 years to get beyond 512K ram and 2 floppies. ) -- Brian Moffet brianm@sco.com {uunet,decvax!microsof}!sco!brianm The opinions expressed are not quite clear and have no relation to my employer. 'Evil Geniuses for a Better Tommorrow!'
peter@sugar.UUCP (Peter da Silva) (05/04/88)
Here's one thing that will never, ever, be implemented on the Amiga...
pid = fork();
switch(pid) {
case -1: perror(argv[0]); exit(1);
case 0: ...
default: ...
}
Don't tell me that AmigaDOS tasks are more efficient, or more powerful,
or less filling. I think they taste great myself. The point remains that
fork() is not compatible with them.
Consider this a challenge, if you like... I don't think it's possible to
implement fork on the Amiga in the general case.
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter
-- Disclaimer: These aren't mere opinions, these are *values*.dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/05/88)
:Don't tell me that AmigaDOS tasks are more efficient, or more powerful, :or less filling. I think they taste great myself. The point remains that :fork() is not compatible with them. : :Consider this a challenge, if you like... I don't think it's possible to :implement fork on the Amiga in the general case. I never liked fork() anyway. It is cute conceptually but not very powerful.... more like wastefull. -Matt
peter@sugar.UUCP (Peter da Silva) (05/05/88)
I said (emphasis added): :_Don't_tell_me_that_AmigaDOS_tasks_are_more_efficient_, or more powerful, :or less filling. I think they taste great myself. The point remains that :fork() is not compatible with them. : :Consider this a challenge, if you like... I don't think it's possible to :implement fork on the Amiga in the general case. In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) replied: > I never liked fork() anyway. It is cute conceptually but not very > powerful.... more like wastefull. I know it's less filling. I just said that, Matt. Argh. The problem is that if you're going to emulate UNIX on the Amiga (see that there Subject: line?) you need to emulate fork(). There's no question about it. It's one of the core system calls. A side note: why did Manx implement "fexec" but not "system"? "System" is a much better mapping for the AmigaDOS "Execute()" function than a nonstandard fork/exec merge. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
doug-merritt@cup.portal.com (05/06/88)
Peter da Silva remarks that he doesn't think that the Unix fork()
call to create a duplicate child process will ever be implemented on
the Amiga.
The reason to doubt this is that the *right* way to implement it
depends on having sufficient memory management to give each process
its own address space, so that you can copy the parent to the child,
and have all pointers behave.
However, there is a way to do it. There've been zillions of discussions
about this over in the minix group, and it's actually been implemented
in the Atari ST version of Minix. You just swap the child process in
every time it gets cpu time (i.e. copy it back to the same place in
memory it used to be in). Inefficient, and wastes memory, but it works.
There are certainly problems with doing this with general processes under
AmigaDOS (I'd imagine that AmigaDOS could scribble on the wrong copy
of a process). But it works with the Amiga *hardware*. It conceivably
could even work under AmigaDOS, if you thought it out carefully enough,
possibly restricting the way in which the forked() process used AmigaDOS
services.
Doug
ucbvax!sun!cup.portal!doug_merrittjesup@pawl6.pawl.rpi.edu (Randell E. Jesup) (05/06/88)
In article <1923@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >Here's one thing that will never, ever, be implemented on the Amiga... > > pid = fork(); > switch(pid) { > case -1: perror(argv[0]); exit(1); > case 0: ... > default: ... > } > >Don't tell me that AmigaDOS tasks are more efficient, or more powerful, >or less filling. I think they taste great myself. The point remains that >fork() is not compatible with them. I think they taste filling. :-) >Consider this a challenge, if you like... I don't think it's possible to >implement fork on the Amiga in the general case. >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter Challenge accepted. I went over all this when people wer talking about a minix port for the amiga. The way to do it is to copy the data segments and stack to save areas, then spawn another process. You'll have to modify the task variables to swap the data/stacks if needed when one of the two tasks gets CPU, plus some shenanigans for ending tasks. (By modify the task variables, I mean the code called when getting/losing CPU). I never said it would be pretty. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// beowulf!lunge!jesup@steinmetz.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup) BIX: rjesup (-: The Few, The Proud, The Architects of the RPM40 40MIPS CMOS Micro :-)
ford@elgar.UUCP (Ford Prefect ) (05/09/88)
In article <1932@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >:Consider this a challenge, if you like... I don't think it's possible to >:implement fork on the Amiga in the general case. > >In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) replied: >> I never liked fork() anyway. It is cute conceptually but not very >> powerful.... more like wastefull. > >I know it's less filling. I just said that, Matt. Argh. > >The problem is that if you're going to emulate UNIX on the Amiga (see that >there Subject: line?) you need to emulate fork(). There's no question about >it. It's one of the core system calls. 99 percent of all forks could be vforks instead. Vfork is better because it doesn't actually create a whole new process, just another thread in the old memory space. The parent thread is put in suspended animation until the child thread does an exit() or an exec(). This results in a very efficient creation of a subprocess executing another file, without making a copy (virtually or otherwise) of the parent process's memory space. It's functionally similar to Aztec's fexec(), but with the semantics of fork (at least in terms of what the program's source code looks like). This works fine on the Amiga: pid = vfork(); switch(pid) { case -1: perror("vfork"); exit(1); case 0: puts("parent: the child is off and running"); break; default: execvp(prog, args); perror("execvp"); exit(1); } vfork() is in my Unix compatibility library for the Amiga. I did not call it fork() just to force a manual inspection of calls to fork() to see if they are replacable by vfork(). Almost all are, but I still don't want to claim that my library does something that it can't. Many versions of Unix have vfork already... I think it's standard on BSD, and I've used it on a few SysV systems. It turns out that wait() is more difficult to implement on the Amiga than vfork() was (I'm still working on wait()). Incedentally, the System V Interface Definition encourages the use of system() rather than fork(). This is an especially good idea on AmigaDos, since the command-string that is passed to system() can be directly passed to Execute(), while the argv that is passed to exec (after forking) must be re-assembled into a CLI command string. This is not always consistent with Unix; for example, some programs do an exec() expecting each element of argv to be passed to the executed program exactly as is, but on the Amiga argv gets recombinified into a command-string and then transmogrified back into an argv. system() is a bit more predictable since it's argument is *supposed* to be parsed and split into argv[]. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/10/88)
>>In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) replied: >>> I never liked fork() anyway. It is cute conceptually but not very >>> powerful.... more like wastefull. >99 percent of all forks could be vforks instead. Vfork is better Yah, I use vfork() all the time. It's a hack. My opinion stands, but perhaps I should reword it: "Having used UNIX systems extensively, I have never liked the way child processes are spun off with fork()/vfork(). The method is cute conceptually, but not very powerful... more like wastefull (even vfork())." Note that my main point is that the calls are not very powerful. -Matt
peter@sugar.UUCP (Peter da Silva) (05/12/88)
In article <146@elgar.UUCP>, ford@elgar.UUCP writes: > In article <1932@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > >The problem is that if you're going to emulate UNIX on the Amiga (see that > >there Subject: line?) you need to emulate fork(). There's no question about > >it. It's one of the core system calls. > 99 percent of all forks could be vforks instead. 99% of all fork/exec pairs could be system()s or popen()s instead, too. But they're not. Because on UNIX the ground call is fork(). The cases where you need the semantics of fork() can't be fixed up this way. > Vfork is better > because it doesn't actually create a whole new process, just another > thread in the old memory space. vfork() is a kludge. By implementing a copy-on-write fork instead you can get all the efficiency of vfork() and all the generality of fork(). > Incedentally, the System V Interface Definition encourages the use of > system() rather than fork(). This is an especially good idea on > AmigaDos... This I agree entirely with, and I am still mystified as to why Aztec bothered to implement fexec at all. Actually, there's something to be said for implementing Execute() on UNIX... -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
peter@sugar.UUCP (Peter da Silva) (05/12/88)
This means waugh! In article ... dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: [ Re: fork() ] > Note that my main point is that the calls are not very powerful. OK, buster. What mechanism would you use? Side comment: I finally got a good description of the Berkeley select() call. It's great. It's the conceptual breakthrough needed to do asynchronous I/O in UNIX. The *right* way. Too bad that name "wait" was already taken. What's the structure of a bitset, anyone? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/13/88)
In article <8805092040.AA17873@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Yah, I use vfork() all the time. It's a hack. My opinion stands, >but perhaps I should reword it: > > "Having used UNIX systems extensively, I have never liked the way >child processes are spun off with fork()/vfork(). The method is >cute conceptually, but not very powerful... more like wastefull >(even vfork())." > > Note that my main point is that the calls are not very powerful. Agreed that they aren't very powerful. However, the fact that they aren't very powerful -- er.. MORE that they do simple & useful things -- allows GREAT flexibility in what can be done on the system. THe fact/opinion that 99% of all fork()'s are immediately followed by the child doing an exec() SHOULD cause a new system call that does the combination of fork()/exec() directly. vfork() is the stupid hack. There are things which you can do in an environment where fork()/exec() are split that you can't do (er.. are harder to do) when fork()/exec() are not seperated. An example is the classic terminal program on Unix. You have one process that does a fork(), the parent handles terminal to modem traffic and the child handles modem to terminal traffic. There is no busy waiting because read() calls hang until i/o is available. It's very simple to write, I've got one that's about 1-2 screens long which I came up with about 10 minutes thought when I needed a really simple one to do something. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- Windowing... The Amiga has windowing. The Mac has windowing (echoes of <---- Jonathan Livingston Seagull: "Just flying? A mosquito can do that much!").