GVAEB@isuvax.bitnet (tony bible, iowa state university) (10/28/88)
jim beug writes > >is there (or is anyone working on) a version of minix >for the Mac? > >jim beug CSc dept, cal poly >internet: jlbeug@polyslo.calpoly.edu >uucp: {csun|csustan|sdsu}!polyslo!jlbeug i would also like to know if there exists or will exist a Mac-MINIX. tony bible computation center iowa state university
lennox@lectroid.sw.stratus.com (Craig Scott Lennox) (06/05/90)
I asked this once before, with no response: Why is MacMINIX going to be a hosted app, rather than a REAL OPERATING SYSTEM as on the IBM PC, Atari, and Amiga?? -- | flame me at: lennox@shire.hw.stratus.com, Craig Lennox, Stratus Computer | |"Oh boy, virtual memory! Now I'm gonna make myself a REALLY BIG ram disk!" | | Disclaimer: My opinions are covered by section 2b of the Gnu Public | | License and thus do not belong to Stratus Computer. |
ast@cs.vu.nl (Andy Tanenbaum) (06/05/90)
In article <1458@lectroid.sw.stratus.com> lennox@lectroid.sw.stratus.com (Craig Scott Lennox) writes: > >Why is MacMINIX going to be a hosted app, rather than a REAL OPERATING SYSTEM >as on the IBM PC, Atari, and Amiga?? Because IBM, Atari, and Commodore are happy to tell you how the machine works. Apple's attitude is that you are a user and you can be trusted to point with the mouse. How the disk controller, clock, video, keyboard and DMA chips work is none of your bloody business. Kind of hard to write a native OS for a secret machine. Andy Tanenbaum (ast@cs.vu.nl)
kjh@pollux.usc.edu (Kenneth J. Hendrickson) (06/05/90)
In article <6785@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes:
% Because IBM, Atari, and Commodore are happy to tell you how the machine
% works. Apple's attitude is that you are a user and you can be trusted to
% point with the mouse. How the disk controller, clock, video,
% keyboard and DMA chips work is none of your bloody business.
% Kind of hard to write a native OS for a secret machine.
%
% Andy Tanenbaum (ast@cs.vu.nl)
<Flame on> /* whoosh */
This is good reason to avoid Apple products.
<Flame off> /* fwump */
Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjhgall@yunexus.UUCP (Norm Gall) (06/05/90)
kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: | In article <6785@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: | % Because IBM, Atari, and Commodore are happy to tell you how the machine | % works. Apple's attitude is that you are a user and you can be trusted to | % point with the mouse. How the disk controller, clock, video, | % keyboard and DMA chips work is none of your bloody business. | % Kind of hard to write a native OS for a secret machine. | <Flame on> /* whoosh */ | This is good reason to avoid Apple products. | <Flame off> /* fwump */ Well, its only a good reason if what you want is a hacker type machine... The Mac was designed to be an appliance that was simple to set up and operate. It wasn't designed to be a sponge that soaked up whatever came down the pike... The right tool for the right job........... nrg -- "It is not the task of philosophy to affirm or deny the existence of things, but rather to clarify what assertions or denials of existence signify, if anything." -- PMS Hacker
lennox@lectroid.sw.stratus.com (Craig Scott Lennox) (06/05/90)
In article <6785@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > Because IBM, Atari, and Commodore are happy to tell you how the machine > works. Apple's attitude is that you are a user and you can be trusted to > point with the mouse. How the disk controller, clock, video, > keyboard and DMA chips work is none of your bloody business. > Kind of hard to write a native OS for a secret machine. > > Andy Tanenbaum (ast@cs.vu.nl) Well isn't that special?!? To think that ten years ago, Apple used to tell you anything you ever wanted to know about the Apple ][ ... right down to detailed schematics. Now they are no fun anymore. These days, they'd be likely to SUE YOU for releasing something with the "look and feel" of A/UX. :-) Now, I don't mean to seem insulting, but if MacMINIX isn't a native operating system, then what exactly is it? And what good is it? I thought the whole point of MINIX was to teach students all the inner workings of a real O/S ... can't do that very well if it's stuck way up on the application level. -- | flame me at: lennox@shire.hw.stratus.com, Craig Lennox, Stratus Computer | |"Oh boy, virtual memory! Now I'm gonna make myself a REALLY BIG ram disk!" | | Disclaimer: My opinions are covered by section 2b of the Gnu Public | | License and thus do not belong to Stratus Computer. |
peter@ficc.ferranti.com (Peter da Silva) (06/05/90)
In article <6785@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > In article <1458@lectroid.sw.stratus.com> lennox@lectroid.sw.stratus.com (Craig Scott Lennox) writes: > >Why is MacMINIX going to be a hosted app, rather than a REAL OPERATING SYSTEM > >as on the IBM PC, Atari, and Amiga?? > Kind of hard to write a native OS for a secret machine. Personally, I'd rather it be a hosted application on the Amiga. AmigaOS is a far more capable system than IBM, Apple, or Atari is willing to sell you, and I'm not ready to give it up for MINIX just yet. I want the best of both worlds... -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
lennox@lectroid.sw.stratus.com (Craig Scott Lennox) (06/06/90)
In article <P:X377D@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > In article <6785@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > > In article <1458@lectroid.sw.stratus.com> lennox@lectroid.sw.stratus.com (Craig Scott Lennox) writes: >> > >Why is MacMINIX going to be a hosted app, rather than a REAL OPERATING SYSTEM > > >as on the IBM PC, Atari, and Amiga?? > > > Kind of hard to write a native OS for a secret machine. > > Personally, I'd rather it be a hosted application on the Amiga. AmigaOS is > a far more capable system than IBM, Apple, or Atari is willing to sell you, > and I'm not ready to give it up for MINIX just yet. I want the best of both > worlds... From a practical point of view, I agree with you! (Especially after seeing AmigaOS 2.0) However, MINIX is first and foremost a teaching OS with a "glass case", and how can MacMinix (or Amiga MINIX, were it also a hosted port) be much good when it's a glass case around a big black box?? I hope this shows everyone how phony Apple's so-called "commitment" to education really is. Instead of educating students, they really want to turn them into end-users. Craig. -- | flame me at: lennox@shire.hw.stratus.com, Craig Lennox, Stratus Computer | |"Oh boy, virtual memory! Now I'm gonna make myself a REALLY BIG ram disk!" | | Disclaimer: My opinions are covered by section 2b of the Gnu Public | | License and thus do not belong to Stratus Computer. |
V2057A%TEMPLEVM.BITNET@cornellc.cit.cornell.edu (Juan Jose Noyles) (06/06/90)
You say that the Mac is an appliance...well, waddya want with' MINIX?
peter@ficc.ferranti.com (Peter da Silva) (06/06/90)
In article <1477@lectroid.sw.stratus.com> lennox@lectroid.sw.stratus.com (Craig Scott Lennox) writes: > From a practical point of view, I agree with you! (Especially after seeing > AmigaOS 2.0) However, MINIX is first and foremost a teaching OS with a > "glass case", and how can MacMinix (or Amiga MINIX, were it also a hosted > port) be much good when it's a glass case around a big black box?? It depends on what sort of "glass case" you have. Some folks find an inside aquarium more convenient than a sea-lion pool in the back yard. :-> Seriously, you have a good point. but wouldn't it be loverly to be able to run Amiga SDB on your MINIX kernel? (re: apple flame) The Mac is designed for people who don't want a computer. It's like a Caddilac: it does its best to convince you you never left your living room. I don't see anything wrong with that. I do think Apple is being pretty damn E&R by claiming the rights to big ugly tail-fins, though. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
steven@m2xenix.psg.com (Steven Furber) (06/07/90)
In article <6785@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >works. Apple's attitude is that you are a user and you can be trusted to >point with the mouse. How the disk controller, clock, video, >keyboard and DMA chips work is none of your bloody business. >Kind of hard to write a native OS for a secret machine. If this is the case, how is Mac Minix going to run in comparison to the other versions where it is an independent OS? Even though it will not be a complete replacement for the operating system, why not make it a possible complete replacement for the standard Macintosh user interface? I have seen a couple of command line interfaces and button-oriented launching utilities that replace the standard GUI. This would at least allow Mac Minix folks to not be reminded of the attitudes of the Apple people all the time while running the machine. Since it is going to be an application, why type of performance should we expect from it? If at all possible I'd like to get rid of my MS-DOS BBS that handles Usenet (I use WAFFLE, if someone wonders) for something that really handles Usenet; like rn, cnews, ELM, and all of those other mail/news utilities that MS-DOS will never be able to compete with. Will this be possible, and what type of speed can be expected on a non-SE II or non-SE/30? I'm looking forward to whatever is released, and hoping that it will be able to take over this eye-sore of an MS-DOS machine's chores. [best place to respond is grouch@legion.uucp]
dbrown@apple.com (David Brown) (06/07/90)
In article <6785@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > Apple's attitude is that you are a user and you can be trusted to > point with the mouse. How the disk controller, clock, video, > keyboard and DMA chips work is none of your bloody business. > Kind of hard to write a native OS for a secret machine. But it also allows Apple to make significant changes to the underlying hardware (witness the recent IIfx) without breaking existing software. Each new machine and system software seems to break a few things, but think about how much worse it could be if Apple documented the hardware and developers wrote to those specs. And you could end up with different versions for each different CPU. (This is my own opinion; I don't know what Apple's official justification for secrecy is. In general I dislike secrecy; I would love to see everything documented, but it would have to be on on a per-CPU basis, which could eat up a lot of resources. I'd rather those resources go in to developing and testing new machines. Apple seems to have its hands full just keeping Inside Mac, which documents the ROM calls, up to date; I know that many Mac developers would love to see a revised single version of Inside Mac (rather than having to refer to Volumes IV & V for recent info). David Brown 415-649-4000 Orion Network Systems (a subsidiary of Apple Computer) 1995 University Ave. Suite 350 Berkeley, CA 94704
lennox@lectroid.sw.stratus.com (Craig Scott Lennox) (06/07/90)
In article <LTY3VWD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > The Mac is designed for people who don't want a computer. It's like a > Caddilac... Right.. and the Amiga is like Chitty-Chitty Bang-Bang! :-) :-) Follow-ups to poster, please. -- | flame me at: lennox@shire.hw.stratus.com, Craig Lennox, Stratus Computer | |"Oh boy, virtual memory! Now I'm gonna make myself a REALLY BIG ram disk!" | | Disclaimer: My opinions are covered by section 2b of the Gnu Public | | License and thus do not belong to Stratus Computer. |
kevin@cmi.com (Kevin Hegg) (06/07/90)
Instead of spending so much time speculating, why doesn't Andy Tanenbaum just give us the specific details of how MacMinix is going to work? Will it run on top of System 6.0 or 7.0 or AUX? Will you do development in MPW or some other environment? Do you need a 68030 or 68020 or what? Will you have access to the Macintosh Toolbox? On another subject, XINU was ported to the Mac a few years ago. I don't know the details of how it works, but if it doesn't require the MacOS then we might want to look at it to get some ideas on how to free MacMinix from the MacOS. Kevin Hegg Center for Machine Intelligence, EDS Corp. 2001 Commonwealth Blvd. Ann Arbor, Michigan 48105 (313) 995-0900 Internet:kevin@cmi.com Applelink:D5990
peter@ficc.ferranti.com (Peter da Silva) (06/07/90)
In article <1482@lectroid.sw.stratus.com> lennox@lectroid.sw.stratus.com (Craig Scott Lennox) writes: > In article <LTY3VWD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > > The Mac is designed for people who don't want a computer. It's like a > > Caddilac... > Right.. and the Amiga is like Chitty-Chitty Bang-Bang! :-) :-) Sarcastic response: you mean it looks like just another computer but has miraculous powers available when needed? I think so. Come on. There are people who need a Caddilac. And there are people who need a Macintosh. I would dearly love to be able to recommend anything else for computerphobes, but there's nothing on the market that's as easy to use. On the other hand, the software is hideously ugly internally, and if you want a computer rather than an appliance getting a Mac is a bad move. -- `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.ferranti.com> 'U` Have you hugged your wolf today? <peter@sugar.hackercorp.com> @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
al@escom.com (Al Donaldson) (06/08/90)
In article <8582@goofy.Apple.COM>, dbrown@apple.com (David Brown) writes: > think about how much worse it could be if Apple documented the hardware > and developers wrote to those specs. Yeah.. Think how much easier it would be if no one cared how the hardware worked and people just bought LOTS and LOTS of the next generation of boxes, and spent all day drawing pretty pictures and talking to other Macs and no one competed with Apple and ... I guess I had always assumed that the upcoming Mac-MINIX was going to control the machine rather than being controlled by "finder" or whatever. Given that, I'm a little surprised that Andy (a leading proponent of open systems) seems to be giving this his blessing. Al OBJ #1 -- "Who are those guys?" "Well, Furdley is the technical guy and Snerdley is just a beancounter." - from a recent Apple ad, names changed because I can't remember them, but you get the drift..) OBJ #2 -- "What's the difference between a Mac and an Etch'a'Sketch?" "You don't have to shake the Mac." - definitely NOT from an Apple ad.
ast@cs.vu.nl (Andy Tanenbaum) (06/08/90)
In article <1470@lectroid.sw.stratus.com> lennox@lectroid.sw.stratus.com (Craig Scott Lennox) writes: >Now, I don't mean to seem insulting, but if MacMINIX isn't a native >operating system, then what exactly is it? And what good is it? It is almost normal MINIX, including the regular FS and MM, except that in the kernel, the disk driver doesn't set bits in some device register to start the disk, it calls a BIOS routine to read a file SimulatedDisk or some such. Thus it is not THAT different from normal MINIX, except for the low level stuff, like I/O, interrupts etc. Andy Tanenbaum (ast@cs.vu.nl)
rw02@GTE.COM (Robert Weihmayer) (06/08/90)
With all this discussion on the nature of MacMINIX, the pros and cons of having it be a MacAPP, etc. has anyone tried to run MINIX with SoftPC on a MAC? Especially with the new SoftPC AT module, it is a very competent, albeit slow (6MHz AT level on a IIci), emulation of a full 286/287 EGA machine. The advantage I would see to this is that one could have the benefit from using a MAC and still be able to experiment with a full operating system down to interrupts and machine level I/O. Clearly performance should not be an issue with this configuration, one would clearly get very little of it. But MINIX is after all an OS teaching environment. ---------------------------------------------------------------------- Robert Weihmayer weihmayer@gte.com GTE Laboratories Inc. 40 Sylvan Road Senior Member of Technical Staff Waltham, MA 02254, USA Phone: (617) 466-2811 ----------------------------------------------------------------------
Patrick.Hayes@cediag.bull.fr (Pat Hayes) (06/12/90)
In article <2571@etsu.CMI.COM> kevin@cmi.com (Kevin Hegg) writes: >On another subject, XINU was ported to the Mac a few years ago. I don't >know the details of how it works, but if it doesn't require the MacOS then >we might want to look at it to get some ideas on how to free MacMinix from >the MacOS. I believe that the xinu port only works on the 68000 Macs. I'd rather have a (somewhat slower) hosted port of minix on my Mac II than be forced to use a Mac + or an SE... Pat -- Patrick Hayes BULL CEDIAG Poste-courrier: 58E02 68, Route de Versailles F-78430 Louveciennes FRANCE EMail : Patrick.Hayes@cediag.bull.fr or ...!uunet!mcsun!inria!bullfr!hayes Tel : (33 1) 39 02 59 86 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety" -- Benjamin Franklin 1759
craig_dewick@f1701.n7802.fido.oz (Craig Dewick) (06/27/90)
Original to: ast@cs.vu.nl I was of the opinion that there were books around that described in intimate detail how the Mac worked internally. Perhaps I was wrong. However, I would have expected Apple to at least tell somebody how the thing works. Perhaps Apple have got a big ego and they don't want to break it up over a miniscule bunch of users who they want to have nothing to do with?? That is usually Apple's approach to things like this. Shame, shame, shame on Apple. How do they expect to get a lot of third party support for their machines from the education and enthusiast community when they don't tell us how the machines tick?? Perhaps we are supposed to ask the fly on the wall!! 8-) C ya later.... Craig. --- TMail v1.15a * Origin: Prophet BBS (8:7802/1701)
jwindley@matt.ksu.ksu.edu (Jay Windley) (07/10/90)
I have a Macintosh SE with 1 MB RAM and a 20MB hard disk. I have used PC MINIX 1.2 for an intermediate operating systems class and would like to continue playing with it on my Mac. The questions are: 1. Does a robust version of MINIX exist yet for the Mac? 2. Does its presence on a hard disk interfere with the normal Mac system and Finder? The machine would still have to function occasionally as a Mac. 3. How much hard disk space is required for the bare-bones? For the sources? 4. Is one meg enough RAM? 5. Does it boot from a floppy like the PC version to short-circuit a boot from the hard disk? 6. I have Tannenbaum's book with 1.2's kernel. Aside from the 8088 assembler, will this suffice for a kernel reference? E-mail responses are fine: jwindley@matt.ksu.ksu.edu -- "Eat any good books lately?" Q to Worf, ST:TNG ---------------------------------------------------------------------------- Jay Windley - CIS Dept. - Kansas State University jwindley@matt.ksu.ksu.edu
hase@netmbx.UUCP (Hartmut Semken) (07/17/90)
craig_dewick@f1701.n7802.fido.oz (Craig Dewick) writes: >Shame, shame, shame on Apple. How do they expect to get a lot of third party >support for their machines from the education and enthusiast community when >they don't tell us how the machines tick?? Perhaps we are supposed to ask the >fly on the wall!! 8-) Well, this matter was discussed pretty much on comp.sys.mac and so on. Apple does not want to give up the crown jewels: hardware description and operating system as both are subject to change without notice... hase (typing on his new mac...) -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP Hi! (Zaphod Beeblebrox)
ching@brahms.amd.com (Mike Ching) (08/21/90)
I'm currently running 1.3 on a PC and plan to buy MacMinix. Will I be able to bring my PC to 1.5 with the Mac package? Am I wrong in assuming that it's OK to do this? It's only $30 to upgrade but why spend money unnecessarily. Thanks, Mike Ching
John_Thomas_Moylan@cup.portal.com (08/30/90)
I take that to mean that MacMINIX is finished and in PH hand awaiting
whatever action they plan to take with it? (been a LONG time since I've
seen PH software...)
are there any peculiarities in the Mac version(ie. something terribly
different from the other versions or did you manage to get it set in
the vaguely "standard" MINIX form?
INTERNET: JohnM@umde.dbrn.mich.edu (or @35.204.192.2)
CIS: 73715,1750 GENIE: J.MOYLAN
America Online: John moylnast@cs.vu.nl (Andy Tanenbaum) (08/30/90)
In article <33394@cup.portal.com> John_Thomas_Moylan@cup.portal.com writes: >I take that to mean that MacMINIX is finished and in PH hand awaiting >whatever action they plan to take with it? (been a LONG time since I've It is in production now. Release date is roughly Oct 1. I am going off to the ACM "SOSP" workshop in Italy in a couple of days. When I get back, I'll post a complete announcement on 1.5. Sorry for the delay. I am atempting to get all the information right. Andy Tanenbaum (ast@cs.vu.nl)
rex@nbc1.ge.com (Rex Espiritu) (09/05/90)
In article <7402@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >It is in production now. Release date is roughly Oct 1. I am going off... >Andy Tanenbaum (ast@cs.vu.nl) I have a Macintosh Plus w/ 4MB RAM and a 140MB Rodime HD. Does/Will MacMinix run on such a system? I'd love to have Unix at home for personal use without having to buy yet another piece of hardware as well. "Unix for the rest of us..." --Yeah, that's it! B#) -- M. Rex Espiritu, Jr. NBC News, A Division of rex@nbc1.NBC.GE.COM National Broadcasting Company, Inc. {uunet!crdgw1,ge-dab,philabs}!nbc1!rex 30 Rockefeller Plaza, Room 807 Voice: 212 664-5390 FAX: 212 664-3859 New York, NY 10112
archetyp@uxh.cso.uiuc.edu (Joseph R Pickert) (09/13/90)
rex@nbc1.ge.com (Rex Espiritu) writes: >I have a Macintosh Plus w/ 4MB RAM and a 140MB Rodime HD. >Does/Will MacMinix run on such a system? I'd love to have Unix at home for >personal use without having to buy yet another piece of hardware as well. Yes
glen_lalonde@canrem.uucp (glen lalonde) (12/17/90)
I have been using MacMinix for quite some time how, and have some comments and questions that might be of interest to people using MacMinix. First off I have a Mac plus with 4MB. I have ported a few things over to MacMinix, first was a better version of 'ls', since one column output as the default is rather a big pain. The version posted to the net that uses LSOPTS(environmental variable) as the defaults ported with no problem. Second I ported over the clam shell, I think it was the newest version. The only problem I had was with the termcap file. The entry in /etc/termcap for nd had an extra character on the end, thus the history recall was at times not working. Simply deleting this character fixed the problem. Now at least I have command editing an aliasing. I had one problem with elvis, it seems that at least for the mac plus the up/down arrow keys were reversed. So changing /etc/termcap fixed this. Later after porting clam I noticed the up/down keys were again revered. I now believe that clam is correct and that elvis is using the wrong termcap entries for up/down. Anyone have the elvis fix? Next is a.out.h, for best result just build this file using the information found on page 466 of the code listings. Not doing so will result in incorrect results from commands if rebuilt using the old a.out.h. Even the patch posted for a.out.h did NOT fix most of the problems. Rebuild it using the info from page 466. The original version of MacMinix did not work at all under multifinder on the plus, after the recent patches to the startup routines it now starts up and runs for about five minutes before it dies. Part of the boot process in MacMinix is trashing the address error trap vector(0x0c) in memory. Because of this an address error will cause strange results, most of the time what will happen is the internal drive will start to be accessed(for no reason at all!). Other memory in the range of 0x00-0x0f may also be altered upon boot but altering the address trap vector is the biggest problem, since macsbugs will not get called upon a trap. I have made one nice change to the system. It was taking something like 35 seconds for the ramdisk(550K in my case) to get copied upon startup. You will notice something in FS called FASTLOAD. The way the ramdisk gets loaded now is to: loop for each block in the boot fs(used or not): seek for the block on the ramdisk. read the block off the boot fs. memory copy over the block from the boot fs to the ramdisk mark the ramdisk block as dirty write the ramdisk block. endloop. Compiling using -DFASTLOAD will cause large chunks of the boot fs to be moved directly into ramdisk memory. This is only done for the used part of the boot fs. I also altered this so it will read it all in one shot. You must alter the floppy device driver in the kernel for this to work. By default the floppy device driver will only read at most one block at a time, but it calls the MacOS to do the read and the len passed to the macos is in a four byte int. Making these changes gets the boot fs(the part in use only) read directly into ramdisk memory in one shot. This takes about 4 seconds rather than 35 or so. Most of this is to figure out how much of the boot fs is used. If there is enough interest I will post the diffs, it is about 60 lines of code. I have tried many times to login via the serial port with no luck. I altered /etc/ttys and on the terminal I get the login prompt then I get the echo of my login name but once I hit <CR> junk comes up and that is it. Has anyone been able to login using one of the serial ports on the mac? THe c68 compiler recently posted works ok with macminix, but may I just ask what is so good about it? THe code produced is larger and slower than that of the default compiler. MDB will not be a simple port, I found the source code but it seems at first glance that some of the data structures that it needs are not in macminix. I compiled 'stevie' on macminix, which was easy but stevie does not seems to work correctly. It will startup, bring up the file and let you move around but doing a 'set' or cut/paste causes an address error. I know the source code is does work since I compiled it at work on my unix box and it works great. THe problem must be that the code assumes sizeof(int) == sizeof(int *). I altered the LINEWRAP macro in the config.h file but I don't think this will fix the problem of getting long lines running off the left of my screen. I could find no .h or .c file in the kernel that uses this macro. So how can I fix this? In all though MacMinix is stable and has never crashed on me when run from the finder, unless I ran some buggy command. -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
glen_lalonde@canrem.uucp (glen lalonde) (12/22/90)
A few comments on MacMinix, which I have now had some time to play with. Good news.. I did manage to get the version of ls that reads LSOPTS for the ls defaults ported over ok. Thus avoiding the endless ls -FC problem. I got clam ported over with no problem, having command editing and aliasing is real nice. One thing I did notice, the entry in /etc/termcap for 'nd' had an extra character. Thus command recall printed out garbage some of the time. Removing the extra character will fix the problem. I enabled the FASTLOAD option, thus with a 550K ramdisk setup I can get the system to load it up in 7 seconds rather than the 35 or so seconds under the old scheme. This change requires a change to the floppy task, since it will only accept 1 block reads. My patched version reads the entire boot fs(the used part ONLY) directly to ram in one shot. The c68 binary posted on the net works ok with macminix. By the way what is so good about this compiler. It produces code that is slower and larger than the default c compiler. Problems: The recent changes have enabled me to boot MacMinix from multifinder but it dies after about four minutes. I have a 4MB Mac+. The up/down arrow key entires elvis reads from /etc/termcap are reversed, at least on the mac+. At first I just reversed the entries in /etc/termcap. This caused clam to have the wrong command recall direction keys though. Anyone have the elvis fix? I have been unable to login via the modem port. I did setup my /etc/ttys correctly. What happens is I get the 'login' prompt and get the echo of my login name but once I hit <cr> all I get is garbage. Any ideas? I ported over stevie which I know works, since I compiled it on my workstation at work. It must assume sizeof(int)=sizeof(int *) since it crashed if you enter :set or cut/paste. Moving about works ok though. **** MacMinix upon boot overwrites the address error trap handler address in low memory! This will cause a great number of problems, since address errors will not drop you into macsbug but will cause strange system behaviour. Most of the time the internal drive will start to run, for no reason at all, after a little while of runnning some bad code it will just crash the system. PLEASE post a fix if you know what part of the system is trashing the vector. I think it is at 0x0c in memory if I recall correctly. -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
glen_lalonde@canrem.uucp (glen lalonde) (12/25/90)
Here is a patch to MacMinix that will enable LINEWRAP, that is
output will wrap to the next line after 80 cols.
In the file kernel/console.c in function vduput:
There is a line vdumoveto(v->crow, v->ccol+1);
return;
(this is for the normal char case) change this to:
if (v->ccol >(LINEWRAPPOS -2)) {
if (v->crow == NROW -1) {
for (i=0; i<NROW-1; i++) vducpyline(i+1,i);
vduclrline(i);
vdumoveto(c->crow,0);
} else vdumoveto(v->crow+1,0);
} else vdumoveto(v->crow, v->ccol +1);
return;
You need to put 'register i;' at the top of the function, and
to define LINEWRAPPOS as a macro, I made it 80 so it will wrap
at col 80 in my case.
Please report any problems with the above modification.
--
Canada Remote Systems. Toronto, Ontario
NorthAmeriNet Hostpaul@ukpoit.co.uk (Paul Wood) (12/31/90)
In article <1990Dec22.1046.1132@canrem.uucp> "glen lalonde" <glen_lalonde@canrem.uucp> writes: >Problems: > The recent changes have enabled me to boot MacMinix from >multifinder but it dies after about four minutes. I have >a 4MB Mac+. I get this, even under the plain Finder. If I start up MacMinix, and then DON'T DO ANYTHING except go make a cup of tea, not even login, then when I get back I'll have had a system crash. My guess is that my problem with the plain Finder and yours with the MultiFinder may well be related. Is something eating the heap or stack? >**** MacMinix upon boot overwrites the address error trap handler >address in low memory! This will cause a great number of problems, >since address errors will not drop you into macsbug but will cause >strange system behaviour. Most of the time the internal drive will >start to run, for no reason at all, after a little while of runnning >some bad code it will just crash the system. I get this as well. The internal drive (without a disk in it even!) will start running, eventually resulting in a system crash. I have attributed it to cron. Do you have cron running? Recently someone on the net recommended putting "extern char *malloc();" in cron, but that didn't seem to fix the problem for me. Ideas anybody? My current solution is to not run cron - great eh! :-( Thanks, Glen, for the interesting stuff that I have omitted. Paul Wood | UUCP Mail: paul@ukpoit.co.uk 31 Buttermere Drive, Dronfield Woodhouse, | Bang-Style: ...!ukc!ukpoit!paul Sheffield, England, S18 5PX | Voice: +44 246 418031
webber@csd.uwo.ca (Robert E. Webber) (01/03/91)
In article <199024.1046.1155@canrem.uucp> "glen lalonde" <glen_lalonde@canrem.uucp> writes:
.Here is a patch to MacMinix that will enable LINEWRAP, that is
.output will wrap to the next line after 80 cols.
(As described at the end of this message, it breaks a rare situation that
occurs while using elle - possibly other screen editors as well.)
.
.In the file kernel/console.c in function vduput:
. There is a line vdumoveto(v->crow, v->ccol+1);
. return;
. (this is for the normal char case) change this to:
For general compatibility, one probably wants to include this in an
#if LINEWRAP, which in turn means an #include <minix/config.h> needs
to be added to the top of console.c.
. if (v->ccol >(LINEWRAPPOS -2)) {
I decided to use NCOL instead of introducing a new macro. However, whether
or not it is a good idea to link NCOL to linewrapping is unclear given the
documentation in this module.
. if (v->crow == NROW -1) {
. for (i=0; i<NROW-1; i++) vducpyline(i+1,i);
. vduclrline(i);
. vdumoveto(c->crow,0);
I assume this is a typo for v->crow
. } else vdumoveto(v->crow+1,0);
. } else vdumoveto(v->crow, v->ccol +1);
. return;
.
.You need to put 'register i;' at the top of the function, and
.to define LINEWRAPPOS as a macro, I made it 80 so it will wrap
.at col 80 in my case.
.
.Please report any problems with the above modification.
Actually, I do notice a problem when using elle (that only occurs when
this patch to console.c has been made). If under elle one generates a
line that is overlong, it wraps around fine. However, if one goes
back to the beginning of that line and inserts a new character, both
lines are redrawn. In the redrawing of the second line (the wrapped
portion of the line), only the last character appears, the others are
blanked out. Control-l redraws the screen fine. When removing a
character from an overlong line, it redraws fine too. Incidently, on
a separate matter, a few times now, elle has freaked on me (behaving
as if all the keybindings had been changed) - has anyone else seen
this?
--- BOB (webber@csd.uwo.ca)
p.s., On another matter, letting MacMinix idle for 40 minutes without
anyone logging in after bootup doesn't crash my system (Mac+, 4meg, no ramdisk,
heap set to 1meg) running under plain finder. Perhaps people having problems
with this have some Init doing something. Also, in the early days, a comment
to the general effect that increasing heap size sometimes fixes problems
was made (hence my gargantuan heap).mkahl@world.std.com (Michael Kahl) (01/05/91)
In article <1990Dec22.1046.1132@canrem.uucp> "glen lalonde" <glen_lalonde@canrem.uucp> writes: >**** MacMinix upon boot overwrites the address error trap handler >address in low memory! This will cause a great number of problems, >since address errors will not drop you into macsbug but will cause >strange system behaviour. Most of the time the internal drive will >start to run, for no reason at all, after a little while of runnning >some bad code it will just crash the system. PLEASE post a fix if >you know what part of the system is trashing the vector. I think >it is at 0x0c in memory if I recall correctly. Here is the fix. I have no idea what the original code might have been meant to accomplish, but it's clearly in error. *** /usr/src/kernel/console.c~ Thu Dec 20 23:00:34 1990 --- /usr/src/kernel/console.c Thu Dec 20 23:00:59 1990 *************** *** 115,121 **** if (scrollrgn == 0) scrollrgn = NewRgn(); vdusetparams(line, 1, monaco, 9, line == 0 ? 1 : 0, 1, 0L, 1, 0, 0); ! GetNextEvent(GetNextEvent(0, &e)); } --- 115,121 ---- if (scrollrgn == 0) scrollrgn = NewRgn(); vdusetparams(line, 1, monaco, 9, line == 0 ? 1 : 0, 1, 0L, 1, 0, 0); ! GetNextEvent(0, &e); }
glen_lalonde@canrem.uucp (glen lalonde) (01/05/91)
Any reference to c->crow is a typo, they should all be v->crow. There is a problem with the shell file in /etc which unpacks all the disks for you. You will notice at the top a long list of directories it makes. There is one directory missing from this list, the list later on in that file that indicates where to 'cd' to and unpack from has the complete list. If you don't fix it and try to install most of the disks it dies because it will be unable to 'cd' to a directory. At least this is what happened to me. Once again I ask, has anyone been able to login to MacMinix over the modem/printer port? It does not seem to work. -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
webber@csd.uwo.ca (Robert E. Webber) (01/05/91)
[describes problem I had with the proposed console.c GetNextEvent fix and alternative fix that SEEMS to work better.] In article <1991Jan5.031942.446@world.std.com> mkahl@world.std.com (Michael Kahl) writes: .In article <1990Dec22.1046.1132@canrem.uucp> "glen lalonde" <glen_lalonde@canrem.uucp> writes: .>**** MacMinix upon boot overwrites the address error trap handler .>address in low memory! This will cause a great number of problems, .>since address errors will not drop you into macsbug but will cause .>strange system behaviour. Most of the time the internal drive will .>start to run, for no reason at all, after a little while of runnning .>some bad code it will just crash the system. PLEASE post a fix if .>you know what part of the system is trashing the vector. I think .>it is at 0x0c in memory if I recall correctly. . .Here is the fix. I have no idea what the original code might have been .meant to accomplish, but it's clearly in error. . .*** /usr/src/kernel/console.c~ Thu Dec 20 23:00:34 1990 .--- /usr/src/kernel/console.c Thu Dec 20 23:00:59 1990 .*************** .*** 115,121 **** . if (scrollrgn == 0) . scrollrgn = NewRgn(); . vdusetparams(line, 1, monaco, 9, line == 0 ? 1 : 0, 1, 0L, 1, 0, 0); .! GetNextEvent(GetNextEvent(0, &e)); . } . . .--- 115,121 ---- . if (scrollrgn == 0) . scrollrgn = NewRgn(); . vdusetparams(line, 1, monaco, 9, line == 0 ? 1 : 0, 1, 0L, 1, 0, 0); .! GetNextEvent(0, &e); . } When I installed this fix, elle continually responded wrong to control keystrokes (such as control-l initiating a search, control-p deleting a line). Currently I am running with a fix that replaces the original GetNextEvent(GetNextEvent(0, &e)); with GetNextEvent(0, &e); GetNextEvent(0, &e); This seems a less drastic change since it also performs the GetNextEvent twice, it just makes sure a meaningful location is passed for the null event to be stored in. If I am reading the Mac manuals right, a event mask of 0 means no event is taken from the queue although some side effects still occur. GetNextEvent should return a Boolean value of either 0 or 1 - in the original, this Boolean return is being used as a mask for the second call (that is short a parameter). If the Boolean is 0, then the above second line is the same thing. If it is 1, the manual indicates that this is a mask on a bit number that is NOT USED. The manual says GetNextEvent returns FALSE when returning a null event. Nothing I have read indicates why one might want to do GetNextEvent(0,&e) twice instead of once, but neither has anything indicated that doing it twice might cause a problem. The effect of this operation seems to be to tell the Mac monitor to check the queues for certain events like the key strokes that eject disks and perform them if they are pending. None of the events it catches are things I am aware of occurring while I have run these patches. --- BOB (webber@csd.uwo.ca)
brentb@nuchat.sccsi.com (Brent Burton) (01/06/91)
Obviously, GetNextEvent(GetNextEvent(0,&e)); is an error because the second call is not passed an event record address. If this particular method HAS to be used, then GetNextEvent(GetNextEvent(0,&e),&e); would be the 'correct' way. But more than likely, just the one call is fine. If this imbedded call method was used, the first event would be unprocessed... I haven't done the fix, but has this helped for others? Is this to help under multifinder (say, has that been fixed and I missed it?)? Thanks, Brent
glen_lalonde@canrem.uucp (glen lalonde) (01/13/91)
My setup is a Mac+ with 4MB. I wanted to enhance the speed of disk IO in MacMinix. First off I found the following. cat a 176K file to /dev/null from floppy takes real 15, user .1 sys 3.8. For a 337K from floppy it takes 30,1.8 and 7.0 Now from hard disk for a 243K file to /dev/null it takes real 16, u 1.4, sys 14.6 I don't understand why for sys the value from the hard disk is so high. Now I do understand that the larger real time for the floppy is just a result of it being a slower device. Also recall that the floppy and hard disk use the exact same driver code. You can connect /dev/fd0 to a hard disk file if you want. Anyways here is the good stuff. What I wanted to do is alter the way MacMinix does IO, now it opens a file and requests reads from the file, the file being the minix file system. Thinking that this is slow, since the macos will have to lookup where on the disk the sector for that pos in the file is, I alter the floppy task for /dev/fd1 to call the MacOS device driver for the floppy. Thus we don't get the overhead of going through a file. This was easy to do since you still just call PBRead, PBWrite. It only takes about 20 lines of changes. I formated a 3.5 inch disk and made sure that all the used sectors were at the front. They I added an offset of 42*512(42 sectors) to the pos to read when calling the .Sony device driver. I was thinking this would result in much faster IO, but it DID NOT. There was just about NO change in the IO rate! I only can conclude that the real time to do IO must be so large that the overhead in going through a MacOS file is small in percent terms. Now my change might be better for a hard disk since the physical IO does not take as long and thus the macOS file overhead might be a larger %. The only problem is setting up my harddisk to have a large continuous number of sectors that I can use is not easy. Anyways it was an interesting project. All mac io in macminix is done async, what does that do? Does the mac allocate processor time at vertical retrace time to do the IO? Recall on the mac+ there is no non-processor related IO(no real dma). -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
glen_lalonde@canrem.uucp (glen lalonde) (01/19/91)
I posted a few changes to console.c to enable linewrap. I have now found out that they break elvis(vi). It seems that elvis does not like the screen to scrole without it causing it. I think a better behaved version of vi might not have this problem. Also, you can't compile the recent version of c68 with the standard compiler. It will produce (almost) empty .s files. You must recompile getsym.c with a back level of c68 and bind it in. It seems the routine getch will not return if you don't do this. Regarding the esc key in minix, on a mac+ you can remap the clear on the keypad to escape by changing a few lines in keyboard.c -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
glen.lalonde@canrem.uucp (glen lalonde) (01/28/91)
You might have noticed before that I indicated I was unable to login to MacMinix via the serial port. I have found the bug, and have a fix. The problem is with the setting of the speed. The speed gets set correctly but trashed by the next call to ioctl. In rs232.c, routine rs_config there is on the return statement a encoding of the speed. This encoding is wrong. You can bypass this by changing the last statement of rs_ioctl from return(speed) to return(speeds) Now I can login to MacMinix at 9600 baud from my apple //e. The next problem you might have is with the terminal. The default has 25 lines, which will cause a lot of trouble with terminal emulators. The fix for this is to alter /etc/termcap to have a new entry vt100 with the proper settings. I also looked around at the routines in rs232.c and they seem correct, but I do often get a "can't set params" error on the console with regard to the serial port. So there still might be some small bug in there, at least the login now works. If anyone finds a problem with my fix let me now. -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
glen.lalonde@canrem.uucp (glen lalonde) (02/15/91)
There have been a lot of questions over the last little while about using the serial lines on the mac. Here is a summery of what I have found. I was unable to login using the serial port to minix, I found a bug in kernel/rs232.c, once this was fixed login worked fine. Thus you CAN login to minix via a modem, now going from minix I have not had much luck. Kermit allowed me to dial out for about 5 minutes then died. The login sessions never had any trouble,but did cause a message to come to the console some of the time. The message indicated that the PBControl call failed in rs232.c Now I tried at length to fix this but was unable to, it just seems there is a very odd bug in the rs232 code. The bug I fixed was that the speed was getting trashed by all calls after the first to ioctl, the encoding of the speed on one of the return statements was wrong. I can repost the fix if people want it. Also a patch was posted for the screen too low problem for the 9inch macs. The last time I ran multifinder, after making the lastest version of the mods to the kernel startup routines, everything ran fine for about five or more minutes. I logout before it died, but would like to ask people with a beta version of system 7 to give it a try. We might need to get all these bugs out of multifinder compatibility quickly so that minix will run under sys 7.0 which I think always runs in a multifinder type setup. -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
glen.lalonde@canrem.uucp (glen lalonde) (02/23/91)
One thing I would like to see is a way to alter the address error trap vector to point to a MacMinix routine that will kill the process and dump core. I really don't like my entire system to crash just because of one process going wild. I don't see why this is not possible, we might want to make it an option though. It would help reduce the number of times the entire system needs to be brought back to life. I have not checked the QUIT menu option, but it would be nice if it could do a SYNC then quit. At this point I always have to remember todo it myself, and have forgot more than once. -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
"glen lalonde" <glen.lalonde@canrem.uucp> (02/26/91)
My first version of this message did not seem to make it to the
net, so here we go agin.
I posted a patch to kernel/console.c a few weeks back that was
to enable linewrap. Later after I noticed how it broke the full
screen editors I indicated one should not use the patch.
I have a new version that checks the mode of the tty before
enabling linewrap. This gets around the problem of one needing
to turn off linewrap when in vi.
In kernel/console.c put:
if (v->ccol >(LINEWRAPPOS-2)) {
i = (v==&vduinfo[1]); /* console 0 or 1 */
if ((tty_struct[i].tty_mode & (RAW | CBREAK)) ==0) {
if (v->crow ==NROW-1) {
for (i=0; i<NROW-1; i++)
vducpyline(i+1,i);
vduclrline(i);
vdumoveto(v->crow,0);
} else vdumoveto(v->crow +1,0);
} else vdumoveto(v->crow, v->ccol+1);
} else vdumoveto(v->crow, v->ccol+1);
I think the original code had just vdumoveto(v->crow,v->ccol+1);
You will need to #define LINEWRAPPOS 80 at the top of the file.
You may also need a 'int i;' at the top of the function, vduput
which is where the changes are.
There is a bug in that when you are at the top of the screen
in elvis and hit 9 uparrow the screen does not get updated
correctly. It only updates correctly if you go up one line
at a time. Anyone have a fix to that one?
--
Canada Remote Systems. Toronto, Ontario
NorthAmeriNet Hostsalzman@bytor.Eng.Sun.COM (Isaac Salzman) (02/28/91)
glen.lalonde@canrem.uucp (glen lalonde) writes: >I was unable to login using the serial port to minix, I found a >bug in kernel/rs232.c, once this was fixed login worked fine. >I can repost the fix if people want it. would you please? i took a stab at it - and i *thought* i fixed it, but i'm now having more problems (which may be due to something else).... please put a real domain address or UUCP path in your signature - i tried to write to you directly but it bounced. thanks! -- * Isaac J. Salzman, Sun Microsystems Inc. ---- * Multi Media Platforms -- Audio Tools & Integration /o o/ / * 2550 Garcia Ave., Mt. View, CA 94043-1100, MS: MTV23-03 | v | | * AT&T : +1 415-336-4338 _| |_/ * Internet : salzman@Eng.Sun.COM / | | * UUCP : ...!sun!salzman | | |
paul@ukpoit.co.uk (Paul Wood) (02/28/91)
In article <199122.1046.1849@canrem.uucp> "glen lalonde" <glen.lalonde@canrem.uucp> writes: >I have not checked the QUIT menu option, but >it would be nice if it could do a SYNC then quit. At this point >I always have to remember todo it myself, and have >forgot more than once. Take care, there are times you want to be able to quit without sync'ing, notably after an fsck of the root file system. Yes, Quit should sync, but we also need an option that quits without sync'ing. paul@ukpoit.co.uk Paul Wood, 31 Buttermere Drive, Dronfield Woodhouse, Sheffield, England, S18 5PX. -- Paul Wood | UUCP Mail: paul@ukpoit.co.uk | iT: The Information iT (Unix Group) | Bang-Style: ...!ukc!ukpoit!paul | Technology Business of Barker Lane | Voice: +44 246 214256 | the UK Post 0ffice Chesterfield | FAX: +44 246 214353 |
lalonde@torolab2.vnet.ibm.com (Glen Lalonde) (03/11/91)
Sorry for the delay in my answer about the serial port problem. The problem is that speed gets trashed by the first ioctl call after you set the speed. Change the last line of rs_ioctl from return(speed) to return(speeds). I recall this being in the file rs232, but I might be wrong about the file. With this fix you can dial in ok but still will have trouble dialing out, that bug is still in there someplace. I recall that was one of the fixes coming in the update. As for printing, I think you MUST use the print command for it to work otherwise the output gets buffered. Internet address: lalonde@torolab2.vnet.ibm.com
rolfl@hedda.uio.no (Rolf Lindgren) (03/12/91)
I have heard tales of ftp-able patches to Minix, from 1.5 to 1.5.10. Where are they available from? I would also very much like to know of a patch to the errors, ommissions and inconsistencies of the MacMinix installation guide. I've got most of Minix up and running, but all doesn't work correctly. Thank you. Rolf Lindgren | "The opinions expressed above are 612 Bjerke Studentheim | not necessarily those of anyone" N-0589 OSLO 5 | rolfl@hedda.uio.no
ross@sugaree.uu.net (03/26/91)
Hello, I am considering purchasing MINIX for the Mac but I have a few questions first.... 1. I have a MacPlus with a 40mb disk and 1mb mem. (I would be willing to upgrade to 2.5mb if necessary). Will MINIX run with some resonable amount of performance on the configuration??? 2. Is my understanding correct, that MINIX on the Mac runs like a normal Mac application, not as the "true" operating system like on the PC version?? And if so does this make it perform poorly?? 3. Does the C compiler that comes with MINIX allow the use of the Mac Toolboxes to use windows. etc in my applications??? Thanks, Tom Ross
KENC@vaxb.acs.unt.edu (Ken Corey, CSCI Major...) (03/26/91)
>1. I have a MacPlus with a 40mb disk and 1mb mem. (I would be willing to >upgrade to 2.5mb if necessary). Will MINIX run with some resonable amount of >performance on the configuration??? When you say performance, I'm assuming you mean raw processing power. It works reasonably well, but it can't hold a candle to say...a sparc station, but then it doesn't have to... It runs reasonably quickly, but you might have some trouble trying to recompile the kernel due to memory restrictions. Seems a shame to be running with only 1MB of ram, when ram is down to around $35 per SIMM...try Chip Merchant...619-268-4774. Then you can run as many things as you can stand to wait for...;) >2. Is my understanding correct, that MINIX on the Mac runs like a normal Mac >application, not as the "true" operating system like on the PC version?? And if >so does this make it perform poorly?? Again, it depends on what you mean by 'properly'. It runs many of the programs that I'm used to using for work, on a full blown BSD system. It will run GCC, if you have the binaries. On the other hand (with my newly installed system 6.0.7) it works with multifinder... >3. Does the C compiler that comes with MINIX allow the use of the Mac Toolboxes >to use windows. etc in my applications??? I think it would, as the mac library seems to have a fairly complete set of toolbox routines. HOWEVER, these are Minix calls to the toolbox, NOT standard stand alone mac programs. Therefore, you're probably gonna get caught under the user license: "You may not sell or License commercial product....without the prior written consent of prentice hall...." "Make the program or any portion of the program publically accessible via electronic bulletin board, computer network or similar device or system....." What do you plan on using the C compiler for? See what I mean? | Ken Corey aka... kenc@vaxb.acs.unt.edu | | "We MUST succeed, otherwise we run the risk of failure...." | | -Dan Quayle |
lalonde@torolab2.vnet.ibm.com (Glen Lalonde) (04/30/91)
Here is a re-post of my MacMinix serial port fix: The problem is that speed gets trashed by the first ioctl call after you set the speed. Change the last line of rs_ioctl from return(speed) to return(speeds). I recall this being in the file rs232, but I might be wrong about the file. With this fix you can dial in ok but still will have trouble dialing out, that bug is still in there someplace. I recall that was one of the fixes coming in the update. To be released soon I hope :-) Other fixes are to: rmaker, console(to enable linewrap at 80 cols), keyboard(to fix up/down arrow keys), etc... I will try to post a list of patches to MacMinix kernel files. Regarding the question about what can one do with it, well you have the source so have fun. I have tried a number of interesting changes, most of which did not help much but you can learn at lot just trying. I am looking into memory protection. Using the pmmu in the 68030 to do memory protection so a runaway process can't trash the system. Anyone with a 68030 mac who might be interested in helping let me know. Project to start in 2.5 months or so. It is best to get gcc up and working first though, as I have. This way you have a ANSI C compiler. BTW, I know those performance hacks I talked about did not 'fit' into the design of minix. I just wanted to try and see how they would affect the performance. So stop telling me it is not legal.
lalonde@torolab2.vnet.ibm.com (Glen Lalonde) (05/08/91)
Here is the patches to get an advanced version of fastload working.
Let me know if you have any trouble with it. I have been using it for
more than 3 months with no trouble.
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 fast.shar.Z
M'YV-9<:@>0,"#X@6(,:\:>-B#)DT9A3,*4,&Q(D77K"\F/.BXPD0/A(N;/C0z
M# @>/"R^.*$ BXJ7(AD.9$,FP90Z;D T"9,'!(@:(&# T"%#AHX8-T#$R)$Cy
M1LL64&.Z0&,3ITZ>/H$*/6I#!PV@2YNV?$FVK%D58V':@,'"!M"R3Z.N;8OCx
M(-06+7V.2$"FC)DT;LJ ())DRI(O29X,H<(D:X(7*D"8&9-385_);^2 F$B'w
M#N S(.K 2$E2!,0#^>L :'B15X0>_O^#0QBRI @5*@4D5*$".(G(&P\CCRYv
M\IO+9C*#:%.'C6<X; 3+*1.&#,<[<M+0*3.'M6LL>OGZ!2SX"10JB9T$8?);u
MJ7#(RX]#3%-&,QV"A U_B6R9.X@[VJ$!& AV!'2?9JVUM )L$(%@1!!3,/9$t
M$$0H")M//HDWFV#Y'<8;A5(\\005("0% GS353<@'6@(5H8;GDT'@AQOO$$'s
M:F78D<88@MVW7!EM9-93@E@L.,*+);WVV@BRD:=3$:=A*.64/K5 PW G]F7'r
M"W*$T08+6>;X @IKI- &D""$X49%+VCY@AO-L9$0&V',T1V1X35)6VE-?$%$q
M$59,"0.6;0"FG)8["I:<9FV*V64;WBG@6D #%7209&R\ 0<<>9 $D404J931p
M1AVM!!*FFG+JJ4DHJ<222S"]0=,+9F2Z::=CV!3&C4Z\88=22<5 PU$YZ%!#o
M#DHQ!4-<"-6:*JY5Y;133S\%-10,70F5K%BPGN5M6I'A( ,+."0%%Q9W@2 Nn
M"SG 8!=4KR4@Y1AU<EC885=(D81N.B2@60^2?4'&&U_(0<8==*!@@AE?G&EGm
M"CLD(+$8*:ZQ0[SSUEO;;;GMUMMO_?Z+&L%V&(RPP@P[/ >8# ]<\,%T0 Q"l
M A139S'&&-([T6#W_K88$R&# '#+!*?QQAATL(%RP]S- ?'$%5]<)(,F/1@Ak
M$Q-6.+6\.6O<X1<?$A'BB#K,*'3 +AM,HXU+J_PTS5%;>.2:GX(WLY2RA=$<j
M'?WZ>W8123AAQ7H12PRWS5)GV(>2W7IK%KA*T7 #"TC-P!I9K_DT'1UUR.$&i
M"D)@/<1A4R2A11$0O[:XW2V% $+K)ZK0P^RTUV[[[;CGKOONO.N.%A:NLV9Xh
M @R/D>E$7X3!!AO#3QD9[*SU+OWTU%=O.Y&N0U%%Z$D,0> ;:514_/%E)+\\g
M"BG O@?T,Y9Q1AIS;*<98#>F(77P[;\??WV;T2%''4A#U:U88X;[88A]BP(!f
M"M)P-K9(YFP+LQ6GM@"#+NP ! Q,B1.DX"= =:\(4[A@&E:P I:1,'W FU*#e
M4&"&%OC #-,Q20@ !H,4@&!]*<Q0"WT !S&XP&A#6 ATRN"9-^2$ADPPH Y=d
MV$,70"$,CQ("&]9 A3S H0P_?,,3'Y5%*?C%"76 U-!<"$._*'%F4!#"$M*Pc
MO,2@C(EB %,-SXA&(0R!?&_D81R#DKH<SFR'930)#>D(@M6Y;G4^89Q/(&.]b
M1CKRD3WX'894,#RB?<%H2&.>X9SW.KM%#Y*@#&7N\ 0"*.AK<+K!((S05K2Ca
M)0T%;?@"'/R'PG3%H 9L*8KE[H(73[:/<YX#G>A(9SK4):Z0C'/="!ID-0E1z
M"':,%*4TI?F[X%'2<)946XWHT#PI/2^'LINF."&)O5*>$C=%4.6-LDF&M24Ly
MEK.4 PI=I[(PG$$P*H"G_PJ')3B #T;\\U&**J(<[&A'44RSDSWQ^1W7X=!Ux
M\!D"%.70DS?4X49A:%]UVA>'.G!GG32"%(L$DYHUN"!2?J3?C,"$*!Z!J3XTw
MDD-W!LF^Z>A/?OW[7P"=-4 5%)!]B=FBEUC30Z.=L9[W7,X9RX '^>7$#N 3v
MWR5AA+XSL@\^1 C(<7K4HH A53!P@**7B%B?.9RTG#YIJ6 ID\YN/!/5OC@u
M&5>HUI,$!01\X ..=,0CD !L@QV,ZQ! :$/8^8N(G?L<X)[01_RML*TNA,(3t
M2H>>)S@!!"4 0>@40\S3@6"&?.RDZPX+3,4&;G!,:*QH,21($$3P65M0JP79s
M=U7^M&@,JTE@&=Y@$K1BT"0H@*4L_1?9R>XK/2?2[#"_4+K3V3 D.W2#&#*%r
M6Z<9=G.)1<$<V5=4@@!L87!THEC;($4J6A&+1A-J&\ZXPR8"48C1*>(1%2@0q
M*+(F!0RCWQF[ZT*C>=$,8!2C9,@8P_V*P6C]?4,0D!9$G-R(IG[DKP^,)H0Zp
MF,$,_ ,8"C+EAC/8$+(^H)#80!A"[A[X#0GV8AP:O$H-<]C#P7VQF8;K5A\,o
MX0E5< *)(K-A(WIXLZ-C;C%5ZQ,)I_<-<VC"5L]FACD8(:13H ,4Z6!@!$]8n
MBTA^PH4Y<S802Y:RZ3$@^]+HQ>KDL8=@HH(4JF!,V-4T(&5(0X%0@(0@2($(m
M5[!S$<!D@C80^;<*;*\/_<N=O7V6AC;$KN= L%@QI]0D"C2R@AELT56"ML<=l
M3D&,?3SC>+KPQCFF@@HP_>/E-A=U\YP2:1/+Z,0X&G^*_AR0.]OF%!H2-DBJk
M6R)99[=HCO/7U?O=@H2'S2\8#\GE4YXF)<9)"WT2V-#N'9$6I#WN>0^JX0O8j
ML9&G;/19"(?#SA_\<*I2^SE;W/O33/QTNDX)#NFG4]MUN!.XP :R#((\G6 %i
M16A7P,+U@R'$( E-N (4AMLG*P1D# \=6G!CB'CA?6\;ABC?!B;QW!#7HWBCh
M.,4J7C&+ZNWB%\/(9 *;$>-I7&,;GW#F/6XWWAE*XQV1W7(Y]C'<&0]D Z5Vg
M<&1.;74+LI"%?!WMHN-.DCZYIL0LB<FD=7.2G9RDT:=^.U*:,@FH3*=*F>Y*f
MI;4U?9,2"$$,@I VA $PJP)512XR*HYXY%1F1[M#&M2JB[R*+""0%1E>$'<We
M-$17O/(5L"*G QC@X"@TV-:RT!65OO_])M*RKPP27Q2B="4&E@N+4QKG.,QUd
M"P1?B0$+OF*#R[V$6:"G 0Y&7X/$\_(U1*?ZU)%.[*77*6EOJ,[3DYZY<,J>c
MZM..'6FH\Y"<C!0$+XJ1=+Q44E7FG39AM1-*?7+UK'\OVV:X?:;,+(9M"BQ'b
M8*I..YN&PK3FZ LWZKZ-OF^'8]870>*?CIVDUOFS0(X&-AB7ZI%U+BG!(3LPa
M8@8H( ),D'O%!QI\@AKP8U(@0 4$L7UD4#8E0 -$L 14,B4%6!T4438^ 0,6z
M6 )C( (L$"^;EFG3=31K<"?*Q5E"YES)%0,P,'DV=TQ%AF3:833S!0-G= <"y
M$AT*=(+594,/-3,,!#! F((&E KQ$ A@0(Q@ ,J (.3EP(O,&LMB#J&I81Gx
MXX10*(4T0(56>&I)>(3=T0( 8VXII(6RLX)!)H:&U08QX *Q1 ?G=39?$S9)w
M"(<N\&^#M87J1P?L!Q(AT02!\P128$,FH%E9H!MY&(=?=ER6=3;^- <W:$2-v
MZ$0A,@1?L$%G4V=WEF>\<8DBQAM3, 5G$W]-<XF@IF-G@X:CA0(J0 9F!P=;u
M@ )_&(@^,(A!H 2&B(B*J!M=X *R& 9P4#!WH&E9.(RT:(O>IR6"J!.[V(NNt
M]8M%$(S*B'YUL@8CF(8)T&>;-UJJI83 I8>\ 07,106X406FF!(UE(5AY08[s
M,H!$L(#()P<Q!0(0^!F:)2(D4E(BN!QQ6([GF(Y3$(Z36(DYL0)GF(2H*'T*r
MB4%)^'_T(X BP 5B8)$8>9$:.8$5B%DA""8'67$OH!0Q2 -,,(/L@T@^MVN+q
MY'N_9W2_DR[XQQ:24WJOYTL2&8 #F($'2!JFH8"J<5(.B(\&*($4:($7B"$\p
MN8$8XH$>*8(D2&HI0(:LP8:T9D,CZ84HB9,V6'$0AC]Z.(=U"#!W6 0@PH]'o
M%8=\F$X:=HO.F(LZ48B'.(U"L(A%D)9.9%R5=5D $Y(XB)>FI!B;* 6=:&=Xn
MIF=X.8HD=HID,'[SQSYZN(HD8H34A818 B=M( ;\PUL@0)5N8".=F0?;<2<-m
MA2&PJ(RUZ)8Y\HQ-$(USF8AU"8S".(O&B(QIB)K,N'YOJ8N\^)K4:(VT*66Jl
ML8VCY8T@\&>/%9!%8(X10I!VU8YI^([Q* +SJ!KU>(_YV&'[.") N0;_2([+k
M.9!4H(Y]Y!,J"7LN^9+1AA9A5REDIU&R6 9J)RH:X7:F$A(#=28GD1)VUQ)&j
MP$;^H3SR$RH^,@>BX4]RL$[:5Y0MT1(O4 =S( <;(0=C0"L<X7ACH -Y,01Hi
MH";W5!%S0! LLBL8=", LCSPZ7S'EWQI(",0&BH* 5 PTAV<.5(M\2C--R"6h
ME4[19U:=Y* 0*J& 83QUT!=\!QAI@ <OH! RH:'@$02-&2J!<0<_HE!)E01$g
M (^PB+(IJ5=E6\](9RK<:)R(G_^M"9:^@8NT* :$:036J%K4!^!P0:TXFX-f
MX:0@X 1E0*5F@!-(@X-@(@;U0E YP53CIH_] 28\N"-H\!]L5*;<<:85X2-3e
MVA)?M:98T!)!@*+UU6$!ZJ)KPC_+9 :RX2 0XDQ:TQ)'$!TYP03*8T1](2D*d
! !)?c
b
endhp48sx@wuarchive.wustl.edu (HP48SX Archive Maintainer) (05/21/91)
There have been rumours that there will once be a macintosh MINIX available, that does not need the software of hte day before yesterday to be able to run. When will it come ? I only use pre-system 7.0 system for playing games, and they work best with my good old system 5.3. -- ******************************************************* Povl H. Pedersen hp48sx@wuarchive.wustl.edu HP48sx archive maintainer
brad@gobi.jpl.nasa.gov (Brad Pickering) (06/19/91)
I have one bug and one possible bug that I'd like to point out. Both of these are harmless. The bug is in the library routine 'relocate'. when relocate is called by macboot to relocate itself it calls the routine with a pointer to itself and 2 NULL pointers. The first NULL is supposed to point to the text segment but in this case the text segment can be found using the first argument (the pointer to the program header). This is correct, no bug here. The second NULL is supposed to be an array of longs that relocate fills in with the sizes of the segments. In the macboot case we don't care what these sizes are so the NULL makes sense. It is supposed to tell the relocate code that we don't wan't these values filled in. The bug is that relocate puts a value in the first element of the array even when a NULL is passed as the pointer to the array. This ends up putting a value in location 0 in memory. This is harmless though because this value is only used during reset. The second thing I'm not sure if it is a bug, but it looks strange to me. The startup code for macboot allocates space below a5 for quickdraw globals. Inside Mac says that quickdraw globals take 206 bytes but macboot allocates 210. I'm probably missing something here but what is it? Anyway, I think the worst that could happen is that were wasting 4 bytes. big deal. any comments would be appreciated -- -- Brad Pickering brad@gobi.jpl.nasa.gov --