booloo@lll-lcc.aRpA (Mark Boolootian) (01/13/88)
----- I am interested in porting Minix to the Macintosh and would like to know if this has already been done. I'd further like to know from you bright Minix gurus if have any suggestions or precautions of which I should take heed. Thanks. mb
ast@cs.vu.nl (Andy Tanenbaum) (01/14/88)
In article <1436@lll-lcc.aRpA> booloo@lll-lcc.llnl.gov.UUCP (Mark Boolootian) writes: >----- > >I am interested in porting Minix to the Macintosh and would like to know if >this has already been done. I'd further like to know from you bright Minix >gurus if have any suggestions or precautions of which I should take heed. The only 68000 port is the Atari. Release maybe (!= promised) some time in the Spring (March 21 - June 21). There is no doubt that any port to a 68000 based machine should start with the Atari version. All the problems caused by the lack of an MMU are solved, as are the assembly code parts. The major differences between the Atari and Mac and Amiga relate to I/O drivers. You will need disk, clock, printer and tty drivers that talk the same protocol to FS as the IBM version, but get the work done somehow. You may be able to use the "BIOS", certainly for output, but maybe for other things too. If you want to get started immediately, I would suggest (1) study MINIX carefully so you know how it works, and (2) start working on the above drivers. Once they are ready, replacing the Atari drivers by them should not be hard. Andy Tanenbaum (ast@cs.vu.nl)
roskos@csed-1.UUCP (Eric Roskos) (01/21/88)
Another problem with porting to the Mac will probably be that the really low-level interfaces are not well documented at all. There is some boundary between what's in ROM and what is loaded by the resource manager from the system file, but (because Apple didn't want people to bypass the well-defined interfaces) this doesn't seem to be documented anywhere in the amount of detail needed to port another OS to the Mac. For example, how system initialization occurs (*in detail*) when you first start the system does not seem to be documented anywhere. This is likely to be a problem in at least two areas (besides initialization): 1) There's no character generator, so ideally you would like to use QuickDraw, probably, to write to the display. But how to get QuickDraw to use a particular font you have (given that the normal QuickDraw calls use the Font Manager and Resource Manager) without initializing some other parts of the Mac Toolbox may take some work to figure out. (Also on some of the earlier Macs there were not fonts in ROM.) 2) Disk I/O to the floppy disk drive is not done via a disk controller the way it is on the PC; it is done via an "Integrated Woz Machine" which seems to be just some simple control logic you can use to turn on the drive, toggle the write line (or sense the read line) from the disk head, step the head, etc. They have a tight loop in the disk driver that sits and looks at bits coming in, or generates bits going out, rather than issuing a request to the disk drive like "read a block" or "seek to track n". Again, this means that the best way to do it would be to use the ROM, but again it is not that well documented exactly how to do it. (Also, while disk I/O is going on you can't do anything else, which means you lose some of your concurrency.) This is not to say "don't try it," but rather just that the documentation supplied by Apple is not as helpful as that provided with the PC (in the Technical Reference) since they intentionally have tried to layer the machine's architecture such that what you see as an applications programmer is a "smart machine" with the underlying mechanisms hidden. Actually this is an admirable design goal (despite the many drawbacks of the conventional parts of the OS, which are very primitive), but to keep people from "cheating" they way they do on the PC (calling the BIOS directly, etc.) I think an intentional attempt was made not to document the low-level architecture. There seem to be scattered "underground" documents where people have gone in and figured out things by trial-and-error or disassembly of parts of the ROM, though, (e.g., in MacTutor, maybe), so with some research you probably can find those. But it is likely to take some time just to figure out how to work the machine before you can start porting Minix to it.
brad@cayman.COM (Brad Parker) (01/24/88)
roskos@csed-1.UUCP (Eric Roskos): > > Another problem with porting to the Mac will probably be that the really > low-level interfaces are not well documented at all. There is some boundary ..... I'm interested in "Minix-on-the-Mac", but from another angle. Has anyone thought of running minix as an application? The SCSI disk "system" used on the Mac supports partitioning the disk, so it would be easy to write a scsi driver and use the minix file system. Also, it would be nice to "use" the MMU as a way to partition/protect tasks. I suspect that any MMU hacking required would break with as-yet-unannounced-and-no-one-at-apple- will-confirm-this MMU software for the Mac, but it would be worth trying for the short future. (re: I'm sure apple is doing MMU work for the Mac OS, but I'm not aware of any specifics and no one at apple has told me about it) Anyway, it would be nifty to launch minix as an application, use it for what ever task is required and then quit back to the Mac. Multifinder support comes to mind, but the Minix/MMU/Multifinder interaction would probably be way to hairy. Anyone thought of this? -brad -- Brad Parker Cayman Systems "You are sleeping; you don't want to believe..." brad@Cayman.com - from a (yet another) Smith's tune
drew@wolf.UUCP (Drew Dean) (01/24/88)
I, as a Mac owner, would like to see Minix ported to the Mac. However, I see
2 options:
1) Run Minix as a guest OS under the Finder/MultiFinder in a window, and pass
all I/O through to the Mac OS to handle
or
2) Forget ALL about the Mac OS, and do everything yourself. This means no
QuickDraw, no Memory Manager needed for QuickDraw, no [blank] needed for {blank}... Designing a font and writing it directly to the screen really isn't that
hard, and floppy control is doable too. Note that the IWM is a single chip
implementation of the Apple II disk controller board, and plenty of copy-
protected Apple II software knew how to talk to it without any other routines.
(So do all the copying programs for both machines) Treated like this, the Mac
becomes a generic 68000 with a bit-mapped screen, .5 - 4 Mb Ram, and a SCSI
port. I have a feeling that the floppy would only be used for loading Minix
onto the hard drive anyway. Note also that the hard drive can hold more than
one partition, each with a different OS, and there is some control over what
boots. Look in Inside Mac Vol 5 for more info(Yes, Vol 5 is available, I bought
it from Addison-Wesly at MacWorld last week). Writing hard disk drivers for
each type of hard disk would be a pain, but it seems that the IBM world is
facing the same problem....
Drew Dean
UUCP: {sdcsvax,ihnp4}!jack!wolf!drew
FROM Disclaimers IMPORT StandardDisclaimer;FYS-MA%FINTUVM.BITNET@cunyvm.cuny.edu (Matti Aarnio) (01/27/88)
>In article <175@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >>Has anybody gotten any information on the 68070? There was a short blurb >I've seen a Philips (or probably Signetics, come to think of it) >datasheet that didn't have 'preliminary' or 'advance information' >stamped all over it, so I guess it actually exists. Thats true, Its PHILIPS, and I have one (preproduction) sample, but they claimed, it on production now. >It isn't pin compatible, but a little board should have done the trick. >They did something stupid though, requiring you to use active glue >to replace a 68000 with it. I don't remember exactly what they did >but it was something dumb like inverting one or two signal lines. You will need two active things: 20 MHz (or almoast at least) Xtal (it has internal clock generator), and some logics to attach built- in interrupt controller to original pins. (There aren't those IPL-lines, neither FC-lines -- there is INTERNAL MMU, you know ;-) Who then would care about supervisor-only accesses to be detected with auxiliary hardware ?) > Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) > The shell is my oyster. Matti Aarnio, FYS-MA@FINTUVM.BITNET (or mea@kolvi.hut.fi for UUCP) Univ. of Turku, Wihuri Physical Laboratory, Finland