Path: utzoo!attcan!lsuc!canrem![glen_lalonde@canrem.uucp] From: glen_lalonde@canrem.uucp (glen lalonde) Newsgroups: comp.os.minix Subject: macminix Message-ID: <1990Dec17.1046.957@canrem.uucp> Date: 17 Dec 90 07:26:49 GMT Reply-To: "glen lalonde" Organization: Canada Remote Systems Lines: 93 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 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