From local@cbmuucp.commodore.com Wed Feb 2 17:14:58 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Stuck without any messages..." (Feb 2, 10:29am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Zik Saleeba , mw@eunet.ch Subject: Re: Stuck without any messages... Cc: chavez@mikey.convex.com, netbsd-amiga@cbmuucp.commodore.com Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 2, 10:29am, Zik Saleeba wrote: > Now if only I could get nfsd to work on my A3000 so I can cross-mount > /usr... Has anyone had any success with nfs serving from NetBSD? Yes, fairly easy even, export the stuff from within /etc/export, and nfsd will handle it. -- Markus Illenseer From local@cbmuucp.commodore.com Wed Feb 2 21:13:07 1994 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: conf/AMIGA Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-amiga-Owner@cbmuucp.commodore.com In article <199402012304.AAA17943@eunet.ch> mw@eunet.ch writes: > Hm, I still believe that the right thing to do is to adjust the clock on the > ados side. Given the future perspective of ados supporting timezones as well > (at least the requester is there by now...), this should be the way IMHO.. Well, I wish the Amiga used GMT for the RTC too, but it doesn't. The timezones support doesn't know anything about DST, and won't until _at least_ the OS release after next. Who knows if they'll do it even then. Add a release after that for it to appear on all machines, looking at recent history. And ADOS will still probably want to run the RTC in locatime then anyway. Also,programs like Time Preferences read and write the RTC themselves, so to make it all work correctly, you have to wedge battclock.resource as well. Then there's the question of booting from other drives without the clock adjuster program installed. Particularly for people who only ran NetBSD part-time, this solution could be more trouble than it's worth. NetBSD, on the other hand, already has a good time database, it has source, so we can add the required support easily, and it doesn't conflict with the existing standard of RTC as localtime. besides, my solution is purely optional. You can still run RTC=GMT if you like. You don't even have to recompile the kernel to switch. NetBSD/amiga already tries to cooperate with AmigaOS wherever posible, so I don't see any reason not to provice at least the option to cooperate on this as well. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From local@cbmuucp.commodore.com Thu Feb 3 00:01:40 1994 From: mw@eunet.ch Subject: Re: Floppy code To: pepersb@cuug.ab.ca (Brad Pepers) Cc: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 643 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > timings in device drivers? I need to be able to do very short delays > (3ms) in the floppy driver I have written. From what I understand the > timeout() routine can do at best a delay of a few ticks which at 100 > HZ is somewhere around 20-30ms. Hm, how accurate do those delays have to be? Would you be able to sleep on the event, or would you have to poll? Problem is wakeup on CIA-A would generate a pretty lowlevel interrupt, and you'd probably not be waked up in time. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Thu Feb 3 00:09:31 1994 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Getty not answering the phone! Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I had getty setup to work via null modem with my IBM and it worked great except the bug with the handover after loging on.. (If someone could post the fix patch or the line number to comment out that would be great). But when I switched it over to my HST Dual and tried dialing it up it would not answer it did initialize the modem and all but won't pickup. I use something like this in gettytab tty00 "/usr/libexec/getty std.19200" dialin on secure this stringed worked null modem but then again I didn't have to ring in.. the dialin maybe dialup can't recall! Is there some other thing that needs to be set to make it work? thanks -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From local@cbmuucp.commodore.com Thu Feb 3 00:09:46 1994 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: anoying message I can't get rid of. Sender: netbsd-amiga-Owner@cbmuucp.commodore.com running my system in multi-user every so often I get this message that goes something like this: timed[xxx]: send /home/usr/../../timed/time/acksend.c send to network failed network not working.. That's as close as I can recall. This has something to do with the rootfs720 default files. I cannot figure out which one this message is being generated in to remove it. Perhaps someone else has found it and could share that info.. thanks. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From local@cbmuucp.commodore.com Thu Feb 3 00:09:53 1994 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Mail not Working Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I finally got mail working thanks to the help. Here is what I had to do. ftp src0712.tar.gz and unpack it cd /src/usr.sbin/sendmail/cf/cf/ then run "m4 cs-exposed.mc >sendmail.cf" (choose one of the macros there read them and see which you want) then edit sendmail.cf and search and replace localhost with your site. look for local mail and change them from /bin/mail /bin/mail.local copy /usr/libexec/mail.local to /bin/local.mail then make a directory in /var/ called mail that's it. should run great. Now I know there is way's to edit the macros to fix the above to work better but I'm not sure how to do this. So this will get things working locally. I think if you want both internet mail and local mail, you will have to choose one of the other macro's.. NOT SURE. But it would be nice is there was a macro supplied that was more generic for NetBSD (I'm sure there is a better macro to choose from) (I would love to know) Hope it helps. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From local@cbmuucp.commodore.com Thu Feb 3 00:34:18 1994 From: Zik Saleeba Subject: Re: Stuck without any messages... To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: mw@eunet.ch, chavez@mikey.convex.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1147 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I wrote: > Now if only I could get nfsd to work on my A3000 so I can cross-mount > /usr... Has anyone had any success with nfs serving from NetBSD? Then Markus Illenseer replied: > Yes, fairly easy even, export the stuff from within > /etc/export, and nfsd will handle it. I've tried this, and quite a few other contortions along this line. I happily managed to mount filesystems from a 386 NetBSD box, but every attempt from my A3000 resulted in "Permission denied" errors. I remember someone (Michael L. Hitch) commenting on a similar problem a while back. If anyone else has solved a problem along this line I'd love to hear from them. This is all that's keeping me from getting my A2500/020 from running NetBSD with only 52Mb of local disk :-) Thanks in advance, +-----------------------------------+------------------------------------+ | zik@zikzak.apana.org.au | "People who like quotations | | zik@bruce.cs.monash.edu.au | love meaningless generalisations" | | Zik Saleeba | - Graham Greene | +-----------------------------------+------------------------------------+ From local@cbmuucp.commodore.com Thu Feb 3 03:30:40 1994 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Mail not Working Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Sorry bout the above, I didn't test it from the user's side. ONLY as root. There seems to be a problem with file permissions. The mail files themselfs are being created by daemon in group daemon and -rw--------- so no users other then root (superuser) can read mail.... If anyone knows what to do about this could you let me know please. Thanks -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From local@cbmuucp.commodore.com Thu Feb 3 05:16:44 1994 To: NetBSD-Dev@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: daily CVS update output Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-dev-Owner@cbmuucp.commodore.com Seen in current-users: In article <199402021139.DAA15651@sun-lamp.cs.berkeley.edu> Charlie Root writes: > Subject: sun-lamp CVS update output > > Updating src and othersrc trees: > [...] > U src/sys/arch/amiga/conf/ROUS Yow! That's my config file. I don't mind it being included, but I dunno as it's really useful to anyone else. Was including it intentional? If you do want it, at least let me give you an up-to-date version... -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From local@cbmuucp.commodore.com Thu Feb 3 05:46:32 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: sources at sun-lamp To: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 680 Sender: netbsd-dev-Owner@cbmuucp.commodore.com I have been actively tracking and updateing the sun-lamp sources. The new accepted site for grabbing source is one of the su-lamp mirrors (this includes ftp.eunet.ch) Already merged: my patches to 744. M Hitch's scsi re-org. I hve also removed all the warnings I could find from the amiga code and it should now compile without warning. Anyone sending patches to markus may wish to also cc them to me, if I understand them they may get merged quicker. Also note sun-lamp is a dynamic tree source. While I try to keep the amiga section compiling valid kernels, as all current users in general are warned, this cannot be counted on. I am looking into config.new no news yet. From local@cbmuucp.commodore.com Thu Feb 3 06:06:17 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sources at sun-lamp To: chopps@emunix.emich.edu (Chris Hopps) Cc: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 108 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > Also note sun-lamp is a dynamic tree source. While I try to keep the and a source tree even :^) Chris. From local@cbmuucp.commodore.com Thu Feb 3 07:58:10 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy code To: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1574 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > > timings in device drivers? I need to be able to do very short delays > > (3ms) in the floppy driver I have written. From what I understand the > > timeout() routine can do at best a delay of a few ticks which at 100 > > HZ is somewhere around 20-30ms. > > Hm, how accurate do those delays have to be? Would you be able to > sleep on the event, or would you have to poll? Problem is wakeup on > CIA-A would generate a pretty lowlevel interrupt, and you'd probably > not be waked up in time. > I'm not sure just how tight the timings are. I know when the timings were too short there were problems but they may be able to be a bit longer. In past code I've written I've used one of the CIA timers, set it not to interrupt, and polled for when it timed out. Accurate but not friendly to the OS! What is the smallest timeout I can do on the system using the regular OS features and not hogging the system? 1 tick + time before I get notified the tick has gone by? The timing is all in the track stepping and motor control. Once that is done a whole track is read in by dma and then there is a disk block done interrupt. +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From local@cbmuucp.commodore.com Thu Feb 3 11:01:07 1994 From: mw@eunet.ch Subject: Re: daily CVS update output To: tsarna@endicor.com (Ty Sarna) Cc: NetBSD-Dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 473 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > Yow! That's my config file. I don't mind it being included, but I dunno > as it's really useful to anyone else. Was including it intentional? > > If you do want it, at least let me give you an up-to-date version... Go ahead:-) Yup, I think it's a good idea to have some sample config files in the tree. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Thu Feb 3 11:19:46 1994 To: netbsd-x@cbmuucp.commodore.com Subject: new version of xrdb yet ? From: John Vrolijk Sender: netbsd-x-Owner@cbmuucp.commodore.com Hi I was just wondering if there is a new version of xrdb, or should I get a new /usr/lib/libXmu.so.5.0 ? By the way, would it be possible to take the source for /usr/lib/libXmu.so.5.0 from my sun and compile it under NetBSD/X11 ???? The xrdb I have now complains about /usr/lib/libXmu.so.5.0 ld.so: undefined symbol _XtCvtStringToFont -John From local@cbmuucp.commodore.com Thu Feb 3 12:05:28 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Stuck without any messages..." (Feb 3, 10:26am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Zik Saleeba , markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Subject: Re: Stuck without any messages... Cc: mw@eunet.ch, chavez@mikey.convex.com, netbsd-amiga@cbmuucp.commodore.com Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 3, 10:26am, Zik Saleeba wrote: > I've tried this, and quite a few other contortions along this line. I > happily managed to mount filesystems from a 386 NetBSD box, but every > attempt from my A3000 resulted in "Permission denied" errors. I > remember someone (Michael L. Hitch) commenting on a similar problem a > while back. If anyone else has solved a problem along this line I'd > love to hear from them. This is all that's keeping me from getting my > A2500/020 from running NetBSD with only 52Mb of local disk :-) Be sure you export the partitions with permissions set, like: /usr rw=hostname secure /usr ro /usr/stuff -access=hostname see more in exports(5) -- Markus Illenseer From local@cbmuucp.commodore.com Thu Feb 3 15:52:04 1994 Subject: Re: sources at sun-lamp From: David Jones To: NetBSD-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: netbsd-dev-Owner@cbmuucp.commodore.com > Anyone sending patches to markus may wish to also cc them to me, if I > understand them they may get merged quicker. Anybody sending patches should also send them to me. If they make sense, they will appear in the next "how2compile" document regardless of what happens on sum-lamp or eunet. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From local@cbmuucp.commodore.com Thu Feb 3 16:10:38 1994 From: Petri Nordlund Subject: Whois, Joe and LhA uploaded to ftp.eunet.ch To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I have uploaded these to ftp.eunet.ch: aterm-whois.tar.gz 7554 Whois client for Term joe-1.0.7.tar.gz 96899 Nice text editor that has more features than Pico but is still very easy to use and install. Built in help. lha-1.00.tar.gz 24410 Unix LhA V1.00 Petri -- _ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Petri Nordlund _ // petrin@mits.mdata.fi -------------------------------\X/------------------------------------- From local@cbmuucp.commodore.com Thu Feb 3 16:24:04 1994 To: NetBSD-amiga@cbmuucp.commodore.com Subject: Probs with 744 kernel From: Sami Ala-Pohja Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Hi folks! I'm quite new in this mailing-list so please forgive me if solution to my problem has already been here. I tried to compile a 744 kernel that would be more suitable for my needs. After long struggle at last I managed to have vmunix of my own. Only problem is that it hangs when I try to load it (cat vmunix.744 >/dev/reboot). No text on screen, just grey screen. I applied the chopps744 patch to my 744 source, but it did not help either. I have tried about everything that I could imagine without success. The 744 vmunix I uploaded from net works fine. HELP! file vmunix says: old sun-2 pure executable not stripped My complete configuration is as follows A2000 OCS 1M chip-mem 4M ZorroII mem GVP G-Force Combo 25 Mhz 68030 68882 with 5M 32-bit mem 2 * Nec 42M SCSI Rootfs720 kernel 730/744 (generic) gcc 2.5.6 config.744 and my CONFIG file : --------------------- machine "amiga" cpu "M68030" ident TIVOLI timezone 0 maxusers 8 maxfdescs 512 # Standard options options SWAPPAGER,VNODEPAGER,DEVPAGER options INET #options NFS,NFSSERVER,NFSCLIENT options MFS options FIFO # Graphics options options GRF options GRF_CUSTOM_CHIP_MODES options GRF_OCS options GRF_ECS #options GRF_ACS options GRF_NTSC options GRF_PAL options "GRF_A2024" options "COMPAT_43" options "COMPAT_NOMID" options "PANICWAIT" # Options specific to this host. options FPCOPROC #options PANICBUTTON #options "BUFPAGES=900" options "NKMEMCLUSTERS=256" config vmunix root on sd0a swap on sd0b and sd1b #config vmunix swap generic # manufacturer 1 is a pseudo and stands for `builtin' master gvp11scsi0 at manufacturer 2017 product 11 # further builtin devices device ser0 at manufacturer 1 product 3 device par0 at manufacturer 1 product 6 disk sd0 at gvp11scsi0 slave 0 disk sd1 at gvp11scsi0 slave 1 disk sd2 at gvp11scsi0 slave 2 disk sd3 at gvp11scsi0 slave 3 #tape st0 at gvp11scsi0 slave ? device grf0 at manufacturer 1 product 7 device grf1 at manufacturer 18260 product 6 # builtin clock (should all identify as "rtclock") device rtclocka0 at manufacturer 1 product 4 device rtclockb0 at manufacturer 1 product 9 # ethernet board #device le0 at manufacturer ? product ? pseudo-device sl 1 pseudo-device ite 2 pseudo-device view 10 pseudo-device kbd 1 pseudo-device mouse 2 pseudo-device pty 32 pseudo-device loop ------------------------------------ //Sami From local@cbmuucp.commodore.com Thu Feb 3 16:33:47 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sources at sun-lamp To: dej@eecg.toronto.edu (David Jones) Cc: NetBSD-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1332 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > > > Anyone sending patches to markus may wish to also cc them to me, if I > > understand them they may get merged quicker. > > Anybody sending patches should also send them to me. If they make sense, > they will appear in the next "how2compile" document regardless of what > happens on sum-lamp or eunet. While this is a nice service you offer I have to question the usefullness of a document of patches to source where the source would already be patched. I plan on keeping sun-lamp *up-to-date* if you were on the source-changes list you would see that I have modified the tree constantly for about 4 days now. I also hope that people will be useing the sun-lamp sources. That way we can find bugs. I don't imagine that Markus will release any more source snapshots. There is no need and it would discourage the use of sun-lamp source which needs to be debuged by most people. I guess that if the source snapshots continue this document may be of some use, however if not I don't see the need. On the other hand a more usefull document would be a how to get and compile sun-lamp sources. This document would also benifit netbsd-amiga's main developers as it would encourage people to use the sun-lamp tree exclusively. > -- > David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto Chris. From local@cbmuucp.commodore.com Thu Feb 3 17:22:35 1994 From: Alan Bair Subject: Re: sources at sun-lamp To: chopps@emunix.emich.edu (Chris Hopps) Cc: dej@eecg.toronto.edu, NetBSD-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: netbsd-dev-Owner@cbmuucp.commodore.com > > While this is a nice service you offer I have to question the > usefullness of a document of patches to source where the source would > already be patched. I plan on keeping sun-lamp *up-to-date* if you > were on the source-changes list you would see that I have modified the > tree constantly for about 4 days now. I also hope that people will be > useing the sun-lamp sources. That way we can find bugs. I don't > imagine that Markus will release any more source snapshots. There is > no need and it would discourage the use of sun-lamp source which needs > to be debuged by most people. I guess that if the source snapshots > continue this document may be of some use, however if not I don't see > the need. > > On the other hand a more usefull document would be a how to get and > compile sun-lamp sources. This document would also benifit > netbsd-amiga's main developers as it would encourage people to use the > sun-lamp tree exclusively. Does this imply that the Amiga changes for NetBSD are now being incorporated into the NetBSD source tree with the 386 and other architecture versions? If yes, then I suppose this also means that sun-lamp is the most up to date place for obtaining the source code, provided everyone places their patches there. After being away from NetBSD for awhile, I was trying to update to 744. So it sounds like I should take the source from sun-lamp instead to ftp.eunet.ch. If this is correct, then information on obtaining the sun-lamp sources would be very helpfull. > > Chris. > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From local@cbmuucp.commodore.com Thu Feb 3 17:29:32 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Dev@cbmuucp.commodore.com Subject: Re: daily CVS update output Sender: netbsd-dev-Owner@cbmuucp.commodore.com On Feb 3, 10:54am, mw@eunet.ch wrote: > > Yow! That's my config file. I don't mind it being included, but I dunno > > as it's really useful to anyone else. Was including it intentional? > > > > If you do want it, at least let me give you an up-to-date version... > > Go ahead:-) Yup, I think it's a good idea to have some sample config > files in the tree. Perhaps some of the sample config files should include some comments about what the sample config file is doing differently than the AMIGA file. In my case, the ZEUS config file is my normal config file which I created to support both the Zeus SCSI adapter and the 33C93 adapters (specifically the GVP in my case). Since that support is now included in the AMIGA config file, the ZEUS file stays pretty close to AMIGA. The ZEUSONLY was another example of configuring a kernel that only included support for the ZEUS SCSI adapter. This isn't needed anymore since the rz/tz stuff is now obsolete and not used. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From local@cbmuucp.commodore.com Thu Feb 3 19:57:24 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: sources at sun-lamp" (Feb 3, 10:26am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chopps@emunix.emich.edu (Chris Hopps), dej@eecg.toronto.edu (David Jones) Subject: Re: sources at sun-lamp Cc: NetBSD-dev@cbmuucp.commodore.com Sender: netbsd-dev-Owner@cbmuucp.commodore.com On Feb 3, 10:26am, Chris Hopps wrote: > On the other hand a more usefull document would be a how to get and > compile sun-lamp sources. This document would also benifit > netbsd-amiga's main developers as it would encourage people to use the > sun-lamp tree exclusively. Gets my full support, just one point: make the sun-lamp source tree available on other ftp-sites, sun-lamp is rather slow compared to other sites (slow 386 machine :-) Is it possible to mirror sun-lamp tree somewhere in europe, or is this already done? ftp.eunet.ch even? -- Markus Illenseer From local@cbmuucp.commodore.com Thu Feb 3 20:08:18 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sources at sun-lamp To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: chopps@emunix.emich.edu, dej@eecg.toronto.edu, NetBSD-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 671 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > > On Feb 3, 10:26am, Chris Hopps wrote: > > On the other hand a more usefull document would be a how to get and > > compile sun-lamp sources. This document would also benifit > > netbsd-amiga's main developers as it would encourage people to use the > > sun-lamp tree exclusively. > > Gets my full support, just one point: make the sun-lamp source > tree available on other ftp-sites, sun-lamp is rather slow compared > to other sites (slow 386 machine :-) > > Is it possible to mirror sun-lamp tree somewhere in europe, or > is this already done? ftp.eunet.ch even? Markus W. tells me that sun-lamp current source tree is mirrored at ftp.eunet.ch Chris. this already done? ftp.eunet.ch even? Markus W. tells me that sun-lamp current source tree is mirrored at ftp.eunet.ch Chris. From local@cbmuucp.commodore.com Thu Feb 3 20:26:27 1994 From: Markus Landgraf To: chopps@emunix.emich.edu Cc: markus@techfak.uni-bielefeld.de, chopps@emunix.emich.edu, dej@eecg.toronto.edu, NetBSD-dev@cbmuucp.commodore.com Subject: Re: sources at sun-lamp Sender: netbsd-dev-Owner@cbmuucp.commodore.com >>>>> "Chris" == Chris Hopps writes: >> On Feb 3, 10:26am, Chris Hopps wrote: > On the other hand a >> more usefull document would be a how to get and > compile >> sun-lamp sources. This document would also benifit > >> netbsd-amiga's main developers as it would encourage people to >> use the > sun-lamp tree exclusively. >> >> Gets my full support, just one point: make the sun-lamp source >> tree available on other ftp-sites, sun-lamp is rather slow >> compared to other sites (slow 386 machine :-) >> >> Is it possible to mirror sun-lamp tree somewhere in europe, or >> is this already done? ftp.eunet.ch even? Chris> Markus W. tells me that sun-lamp current source tree is Chris> mirrored at ftp.eunet.ch But the mirror @ eunet seems to be disactivated, because the newest files in software/os/bsd/NetBSD/NetBSD-current/src/sys/arch/amiga were built at december 17th. Since I am administrator of an amiga site which mirrors NetBSD (ftp.hrz.uni-kassel.de), I volunteer to install the mirror to sun-lamp, but I don't know the exact name of 'sun-lamp' and the directory, were the BSD-source tree is kept. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From local@cbmuucp.commodore.com Thu Feb 3 20:43:12 1994 X400-Originator: /dd.id=1619692/g=hamish/i=hi/s=macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.936:03.01.94.19.33.13] X400-Content-Type: P2-1984 (2) Content-Identifier: kernel compil... From: "hamish (h.i.) macdonald" To: netbsd-dev@cbmuucp.commodore.com Subject: kernel compilation time? Sender: netbsd-dev-Owner@cbmuucp.commodore.com As a contrast, it took about 7 minutes to compile the entire linux/68k kernel on a 128M HP9000/720 with gcc 2.5.8 and the -O2 option (excluding the "make depend" step). It is somewhat slow (~1 hour or so?) on my 8M A3000 under AmigaOS, probably from the lack of filesystem caching. I'll have to recompile it under Linux and see how long it takes. From local@cbmuucp.commodore.com Thu Feb 3 20:51:08 1994 From: Hubert Feyrer Subject: Re: sources at sun-lamp To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1099 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > On Feb 3, 10:26am, Chris Hopps wrote: > Gets my full support, just one point: make the sun-lamp source > tree available on other ftp-sites, sun-lamp is rather slow compared > to other sites (slow 386 machine :-) ^^^ i486. > Is it possible to mirror sun-lamp tree somewhere in europe, or > is this already done? ftp.eunet.ch even? NetBSD-current is mirrored on ftp.eunet.ch in software/os/bsd/NetBSD/NetBSD-current. I've set up a mirror for NetBSD-current here on ftp.uni-regensburg.de, too, mirroring from ftp.eunet.ch. But from what I've just read on this list, I'll switch over to mirror from sun-site directly, after the initial slurp is done from eunet. Regards, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf ========================================================================== From local@cbmuucp.commodore.com Thu Feb 3 21:20:55 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sources at sun-lamp To: hubert.feyrer@rrzc1.rz.uni-regensburg.de (Hubert Feyrer) Cc: markus@techfak.uni-bielefeld.de, netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1236 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > > > On Feb 3, 10:26am, Chris Hopps wrote: > > Gets my full support, just one point: make the sun-lamp source > > tree available on other ftp-sites, sun-lamp is rather slow compared > > to other sites (slow 386 machine :-) > ^^^ > i486. I didn't say that :^) you quoted the wrong name. The one above that said it was slow. :^) > > > Is it possible to mirror sun-lamp tree somewhere in europe, or > > is this already done? ftp.eunet.ch even? > > NetBSD-current is mirrored on ftp.eunet.ch in > software/os/bsd/NetBSD/NetBSD-current. > > I've set up a mirror for NetBSD-current here on ftp.uni-regensburg.de, > too, mirroring from ftp.eunet.ch. But from what I've just read on this > list, I'll switch over to mirror from sun-site directly, after the > initial slurp is done from eunet. If you have the time and would like to offer yet another worthwhile service you could look into setting up a sup database, this would allow developers to simply run the sup program and it would contact your site's database and fetch only the changed files. This is really what developers need to stay current, that or mirror the entire thing on there machine. > Hubert Chris. From local@cbmuucp.commodore.com Thu Feb 3 21:51:23 1994 From: mw@eunet.ch Subject: Re: sources at sun-lamp To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: chopps@emunix.emich.edu, dej@eecg.toronto.edu, NetBSD-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 659 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > Gets my full support, just one point: make the sun-lamp source > tree available on other ftp-sites, sun-lamp is rather slow compared > to other sites (slow 386 machine :-) > Is it possible to mirror sun-lamp tree somewhere in europe, or > is this already done? ftp.eunet.ch even? I'm sup'ing -current daily, so as long as sup can set up a connection to sunlamp, the mirror should be quite uptodate. There are sometimes problems reported by sup, which can delay updates by a few days. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Thu Feb 3 21:53:10 1994 From: mw@eunet.ch Subject: Re: sources at sun-lamp To: landgraf@crunch.ikp.physik.th-darmstadt.de (Markus Landgraf) Cc: chopps@emunix.emich.edu, markus@techfak.uni-bielefeld.de, dej@eecg.toronto.edu, NetBSD-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 796 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > Chris> Markus W. tells me that sun-lamp current source tree is > Chris> mirrored at ftp.eunet.ch > > But the mirror @ eunet seems to be disactivated, because the newest > files in software/os/bsd/NetBSD/NetBSD-current/src/sys/arch/amiga were > built at december 17th. Please reverify next time before stating bogus information. I have files of Feb 1, Jan 30,29.27,26 besides Dec 17 in that directory, showing quite working mirror activity. Don't forget too that I didn't update the sun-lamp source tree for quite a while, and am now really happy that Chris Hopps is doing such a wonderful job at keeping it uptodate. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Thu Feb 3 23:02:24 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: sources at sun-lamp" (Feb 3, 8:38pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Hubert Feyrer , markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Subject: Re: sources at sun-lamp Cc: netbsd-dev@cbmuucp.commodore.com Sender: netbsd-dev-Owner@cbmuucp.commodore.com On Feb 3, 8:38pm, Hubert Feyrer wrote: > I've set up a mirror for NetBSD-current here on ftp.uni-regensburg.de, > too, mirroring from ftp.eunet.ch. But from what I've just read on this > list, I'll switch over to mirror from sun-site directly, after the > initial slurp is done from eunet. Fine! Helps alot. -- Markus Illenseer From local@cbmuucp.commodore.com Fri Feb 4 02:13:34 1994 To: NetBSD-Dev@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: sources at sun-lamp Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-dev-Owner@cbmuucp.commodore.com In article <9402031842.AA18457@kleiber.techfak.uni-bielefeld.de> markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) writes: > Gets my full support, just one point: make the sun-lamp source > tree available on other ftp-sites, sun-lamp is rather slow compared > to other sites (slow 386 machine :-) Actually, i believe it's a fast 486. The problem is that it's massively overloaded. It serves FTP, SUP, the mailing lists, CVS, development, etc. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From local@cbmuucp.commodore.com Fri Feb 4 03:58:02 1994 To: NetBSD-Dev@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: daily CVS update output Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-dev-Owner@cbmuucp.commodore.com In article <199402030954.KAA23604@eunet.ch> mw@eunet.ch writes: > > Yow! That's my config file. I don't mind it being included, but I dunno > > as it's really useful to anyone else. Was including it intentional? > > > > If you do want it, at least let me give you an up-to-date version... > > Go ahead:-) Yup, I think it's a good idea to have some sample config > files in the tree. Here's an update dversion of mine, then. Not very exciting, though -- mainly just the recent GENERIC version, with stuff I don't need removed. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." # # ROUS -- rous.endicor.com # # A3000T 2C/8F, A2065, A2024 # machine "amiga" #cpu "M68020" cpu "M68030" #cpu "M68040" ident ROUS # # Add support for about 16 users. This variable is used to size # various kernel structures. # maxusers 16 # # Set the timezone offset that the kernel will use. # timezone 6 dst # US/Central # # Set the maximum number of file descriptors # maxfdescs 2048 # # The following adds additional floating-point capabilities to # the MC68040. A subset of the MC6888x instruction set is # executed by the MC68040 on-chip FPU. The remaining # floating-point instructions are emulated in software. # #options FPSP # MC68040 floating point support options FPCOPROC # Support for MC68881/MC68882 (mandatory) # # Networking options # options INET # Basic networking support (mandatory) #options GATEWAY # packet forwarding for gateways #options MULTICAST # multicast IP #options MROUTING # multicast routing #options ISO # ISO Networking support #options TPIP # ARGO TP networking support #options CCITT # CCITT X.25 #options NS # Xerox XNS # # File system related options # #options QUOTA # Disk quotas for local disks options NFSSERVER # NFS server side code options NFSCLIENT # NFS client side code # # Support for various types of filesystems # options MFS # Memory based filesystem options PROCFS # Process filesystem options KERNFS # Kernel parameter filesystem #options MSDOSFS # DOS filesystem options FDESC # /dev/fd filesystem options LOFS # Loopback filesystem options ISOFS # CD ROM support options PORTAL # Portal filesystem options FIFO # FIFO operations on vnodes # pager options options SWAPPAGER # Pager for swap device options VNODEPAGER # Pager for vnodes options DEVPAGER # Pager #options BANKEDDEVPAGER # Retiname bank pager # # Compatability options for various existing systems # options COMPAT_SUNOS # Support to run Sun-2/3 executables #options HPUXCOMPAT # HP300 HPUX compatability options "COMPAT_43" # 4.3 BSD compatible system calls options "TCP_COMPAT_42" # Use 4.2 BSD style TCP options "COMPAT_NOMID" # ??? # # Support for System V IPC facilities. # options SYSVSHM # System V shared memory options SYSVMSG # System V messages options SYSVSEM # System V semaphores # # Graphics options # options GRF_ECS # Enhanced Chip Set options GRF_NTSC # NTSC options GRF_PAL # PAL options "GRF_A2024" # Support for the A2024 options ITE_AUTOWRAP # turn ite autowrap on by default # # Support for various kernel options # options LKM # Loadable Kernel Modules options KTRACE # Add kernel tracing system call options "PANICWAIT" # Require keystroke to dump/reboot options DIAGNOSTIC # Add additional error checking code #options DEBUG # Add debugging statements #options PANICBUTTON # Forced crash via keypress (???) options "NKMEMCLUSTERS=256" # Size of kernel malloc area #options GENERIC # Mini-root boot support #options PROFTIMER # Kernel profiling support #options PRF_INTERVAL=500" # Clock ticks between profile interrupts #options KGDB # Kernel debugger (KGDB) support options "PPP_OUTQ_SIZE=4096" # Size of large PPP output queue # # Kernel name and root/swap parameters # #config netbsd swap generic config netbsd root on sd0a swap on sd0b #pseudo-device sl 1 # Serial Line interface #pseudo-device ppp 1 # Point-to-Point Protocol (PPP) pseudo-device bpfilter 16 # Berkeley packet filter pseudo-device ite 2 # Bit-mapped display terminal emulator pseudo-device view 10 # View (graphics mapping) pseudo-device kbd 1 # Keyboard support pseudo-device mouse 2 # Mouse support pseudo-device aconf # AUTOCONFIG(TM) info device driver pseudo-device pty # Pseudo-tty support pseudo-device loop # Loopback network (mandatory) pseudo-device ether # Ethernet support pseudo-device vn 10 # Vnode disk driver # # The following sections describe various hardware options. # # # Devices on an Amiga 3000 # master a3000scsi0 at manufacturer 1 product 1 disk sd0 at a3000scsi0 slave 0 disk sd1 at a3000scsi0 slave 1 disk sd2 at a3000scsi0 slave 2 disk sd3 at a3000scsi0 slave 3 disk sd4 at a3000scsi0 slave 4 disk sd5 at a3000scsi0 slave 5 disk sd6 at a3000scsi0 slave 6 tape st0 at a3000scsi0 slave ? tape st1 at a3000scsi0 slave ? # # Devices on an A2091 # #master a2091scsi0 at manufacturer 514 product 3 #disk sd0 at a2091scsi0 slave 0 #disk sd1 at a2091scsi0 slave 1 #disk sd2 at a2091scsi0 slave 2 #disk sd3 at a2091scsi0 slave 3 #disk sd4 at a2091scsi0 slave 4 #disk sd5 at a2091scsi0 slave 5 #disk sd6 at a2091scsi0 slave 6 #tape st0 at a2091scsi0 slave ? #tape st1 at a2091scsi0 slave ? # # Devices on an GVP Series II # #master gvp11scsi0 at manufacturer 2017 product 11 #disk sd0 at gvp11scsi0 slave 0 #disk sd1 at gvp11scsi0 slave 1 #disk sd2 at gvp11scsi0 slave 2 #disk sd3 at gvp11scsi0 slave 3 #disk sd4 at gvp11scsi0 slave 4 #disk sd5 at gvp11scsi0 slave 5 #disk sd6 at gvp11scsi0 slave 6 #tape st0 at gvp11scsi0 slave ? #tape st1 at gvp11scsi0 slave ? # # Devices on an PPI Zeus SCSI # #master zeusscsi0 at manufacturer 2026 product 150 #disk sd0 at zeusscsi0 slave 0 #disk sd1 at zeusscsi0 slave 1 #disk sd2 at zeusscsi0 slave 2 #disk sd3 at zeusscsi0 slave 3 #disk sd4 at zeusscsi0 slave 4 #disk sd5 at zeusscsi0 slave 5 #disk sd6 at zeusscsi0 slave 6 #tape st0 at zeusscsi0 slave ? #tape st1 at zeusscsi0 slave ? # # Devices on an CSA Magnum SCSI # #master magnumscsi0 at manufacturer 1058 product 17 #disk sd0 at magnumscsi0 slave 0 #disk sd1 at magnumscsi0 slave 1 #disk sd2 at magnumscsi0 slave 2 #disk sd3 at magnumscsi0 slave 3 #disk sd4 at magnumscsi0 slave 4 #disk sd5 at magnumscsi0 slave 5 #disk sd6 at magnumscsi0 slave 6 #tape st0 at magnumscsi0 slave ? #tape st1 at magnumscsi0 slave ? # # Common hardware # # # Serial port interface # device ser0 at manufacturer 1 product 3 # # Parallel port interface # device par0 at manufacturer 1 product 6 # # Floppy drive support (sigh) # #master floppy0 at manufacturer 1 product 2 # # Graphics routines for the AMIGA native custom chip set # device grf0 at manufacturer 1 product 7 #device grf1 at manufacturer 18260 product 6 # Retina # # A2410 # #device tiga0 at manufacturer 1030 product 0 # # builtin clock (should all identify as "rtclock") # device rtclocka0 at manufacturer 1 product 4 # A3000/A4000 device rtclockb0 at manufacturer 1 product 9 # A2000 # # ethernet board (AMD 7990 LANCE controller, A2065 or Ameristar) # device le0 at manufacturer ? product ? From local@cbmuucp.commodore.com Fri Feb 4 07:29:08 1994 To: NetBSD-Dev@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: sources at sun-lamp Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-dev-Owner@cbmuucp.commodore.com In article tsarna@endicor.com (Ty Sarna) writes: > > Would it be possible to keep a file src/sys/arch/amiga/doc/CHANGES, > listing Amiga-specific changes you commit? Or on second thought, howabout adding notes to the global doc/CHANGES file? -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From local@cbmuucp.commodore.com Fri Feb 4 09:41:43 1994 From: Markus Landgraf To: mw@eunet.ch Cc: chopps@emunix.emich.edu, markus@techfak.uni-bielefeld.de, dej@eecg.toronto.edu, NetBSD-dev@cbmuucp.commodore.com Subject: Re: sources at sun-lamp Sender: netbsd-dev-Owner@cbmuucp.commodore.com >>>>> "mw" == mw writes: Chris> Markus W. tells me that sun-lamp current source tree is Chris> mirrored at ftp.eunet.ch >> But the mirror @ eunet seems to be disactivated, because the >> newest files in >> software/os/bsd/NetBSD/NetBSD-current/src/sys/arch/amiga were >> built at december 17th. mw> Please reverify next time before stating bogus information. I mw> have files of Feb 1, Jan 30,29.27,26 besides Dec 17 in that mw> directory, showing quite working mirror activity. Don't forget mw> too that I didn't update the sun-lamp source tree for quite a mw> while, and am now really happy that Chris Hopps is doing such mw> a wonderful job at keeping it uptodate. sorry, today I looked into NetBSD-current/src/sys/arch/amiga and all files were there and new. I can't remembeer what was going on in my emacs when I explored ftp.eunet.ch. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From local@cbmuucp.commodore.com Fri Feb 4 19:08:07 1994 From: Petri Nordlund Subject: GVP G-Force reboot problem To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 549 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I'm using NetBSD in A2000+G-Force 030/882 and I just noticed that for the reboot command on NetBSD side to work correctly, fastrom must be turned off before starting NetBSD, i.e. 'GvpCpuCtrl NOFASTROM'. It might be a good idea to mention this in the NetBSD FAQ, if it isn't already there. Petri -- _ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Petri Nordlund _ // petrin@mits.mdata.fi -------------------------------\X/------------------------------------- From local@cbmuucp.commodore.com Fri Feb 4 20:16:21 1994 From: Eric Augustine Subject: joe1.0.7 To: netbsd-amiga@cbmuucp.commodore.com (Net Amiga) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 385 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Hadn't noticed a similar post - I grabbed joe1.0.7 from ftp.eunet and gzip reports that the file is incomplete... I tried ftping world.std.com for the sources but, for the last two days logins as "anonymous" have been refused. Is there a secondary site that either mirrors world.std.com, or that has a different copy of the binaries from the ones at eunet? Thanks - - Eric From local@cbmuucp.commodore.com Fri Feb 4 20:51:27 1994 From: Eric Glanz - Unix Support Subject: NetBSD boot error... To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I am having a strange problem, and was wondering if anyone had an answer for this: I have a 3000T, 5meg of memory, and have a 200 meg hitachi drive dedicated to BSD (ID #6). After laying down the boot partition with filetodev and booting BSD, I get the following error: sl0 attached ppp0 attached changing device to sd6a dmanext at end!!! Then BSD halts... Any reason why this happens? I had the boot partition working correctly before, and and using the exact same filetodev parameters as before, except this time I get this error! Any ideas? --Eric Glanz ucsedg@uwplatt.edu From local@cbmuucp.commodore.com Fri Feb 4 21:38:43 1994 From: mw@eunet.ch Subject: Re: joe1.0.7 To: uairk@mcl.mcl.ucsb.edu (Eric Augustine) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 429 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Hadn't noticed a similar post - I grabbed joe1.0.7 from ftp.eunet > and gzip reports that the file is incomplete... I tried ftping You're right, I removed the file (including the readme). Could the person who provided the original archive reupload it please? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Fri Feb 4 23:30:54 1994 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: NetBSD-Dev@cbmuucp.commodore.com Subject: Problem with tape backup (rst0) Sender: netbsd-dev-Owner@cbmuucp.commodore.com I have setup the tape in the kernel as follows: tape st0 at gvp11scsi 0 slave 2 And when I try to write to the tape with the following: tar czvpf /dev/rst0 /etc I get a warning at the beginning and at the end that there is a block mismatch and it says 512 / 7144 the error says something simlar at the end as well plus it states io error couldn't right to /dev/rst0. I'm using a 150 meg tape back up to do this with. And when I try to untar with the following command it works except I'm missing some files in the etc directory. tar xzvpf /dev/rst0 there's about 5 or 6 files missing. Tar works fine I tried testing it on the same directory to a file/path without problem. So I think that I either have something configured wrong in the kernel or there is a bug in the kernel. Same problem when I tried writing to the tape from the usr directory. An error at the begining and end. thanks. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From local@cbmuucp.commodore.com Fri Feb 4 23:31:01 1994 From: DCG9367@tntech.edu Subject: Problems starting network To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I have installed version 744 and all of the binaries excpet for X11R5. When I try to go to multiuser mode, it gets through saying "starting network ..." and then it freezes. I had to reboot back to single user and executed /etc/netstart with sh -x /etc/netstart. It spits out a few envrionment variable definitions and then hangs after gated=NO When I do these by hand, they work fine. Does anyone know whats going on?!?! I have a 2000, GVP G-Force 040/33 with 4mb 32-bit, and a Retina. Nothing else special. Also, I have an Irwin 5040 tape drive which does not seem to work right under NetBSD. First of all, it configures as sd5, a disk not a tape. I think this is because the Irwin is a scsi direct device, not a sequential like most tape drives. I put my tar files on tape from AmigaDos, loaded netbsd, and tar xvf /dev/sd5c. The files extracted fine, no complaints from tar. But the files are corrupt and refuse to ungzip. I untarrd the archives from AmigaDos and they all tested fine. Whats up? Thanks, David. From local@cbmuucp.commodore.com Sat Feb 5 06:39:11 1994 From: windiba@server.uwindsor.ca (Chris Windibank) Subject: mount flags MNT_SYNCHRONOUS ? To: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: netbsd-dev-Owner@cbmuucp.commodore.com Does the mount flag MNT_SYNCHRONOUS in mount.h make the file system physically write the data to the device immediately ? If not what exactly does it do ? Chris From local@cbmuucp.commodore.com Sat Feb 5 09:41:35 1994 From: "William J. Coldwell" To: netbsd-amiga@cbmuucp.commodore.com Subject: MAILING LISTS ARE MOVING Cc: netbsd-x@cbmuucp.commodore.com, netbsd-dev@cbmuucp.commodore.com Sender: netbsd-amiga-Owner@cbmuucp.commodore.com First off, let me apologize for having to make another change to the lists, especially so soon after the last one. BUT, there are some really good sides to this... 1) The site we're moving to is sun-lamp.cs.berkeley.edu.. sound familiar? This means that it will be stable, and will be around forever (well, long enough) 2) It uses the Majordomo mail list handler software, which means everything stays the same as far as the commands that you are used to. 3) You won't have to resubscribe.. that's right.. we're just moving you right on over there... 4) I still remain your dedicated NetBSD-Amiga admin. Why is this good? Because you don't have to learn the new person's name to complain to him ;-). You will have to change a few things on your end: 1) Obviously, you will have to change the site name. cbmuucp will forward the current lists and new (un)subscribes to sun-lamp for you for a while. 2) the NetBSD-X and NetBSD-Dev list names will _have_ to change to not conflict/confuse the current list names there. I will post more info on that in the next message. Why are we moving? I can't say at this time, but it will become clear soon. -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From local@cbmuucp.commodore.com Sat Feb 5 09:42:39 1994 From: "William J. Coldwell" To: netbsd-amiga@cbmuucp.commodore.com Subject: MAILING LISTS ARE MOVING Cc: netbsd-x@cbmuucp.commodore.com, netbsd-dev@cbmuucp.commodore.com Sender: netbsd-x-Owner@cbmuucp.commodore.com First off, let me apologize for having to make another change to the lists, especially so soon after the last one. BUT, there are some really good sides to this... 1) The site we're moving to is sun-lamp.cs.berkeley.edu.. sound familiar? This means that it will be stable, and will be around forever (well, long enough) 2) It uses the Majordomo mail list handler software, which means everything stays the same as far as the commands that you are used to. 3) You won't have to resubscribe.. that's right.. we're just moving you right on over there... 4) I still remain your dedicated NetBSD-Amiga admin. Why is this good? Because you don't have to learn the new person's name to complain to him ;-). You will have to change a few things on your end: 1) Obviously, you will have to change the site name. cbmuucp will forward the current lists and new (un)subscribes to sun-lamp for you for a while. 2) the NetBSD-X and NetBSD-Dev list names will _have_ to change to not conflict/confuse the current list names there. I will post more info on that in the next message. Why are we moving? I can't say at this time, but it will become clear soon. -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From local@cbmuucp.commodore.com Sat Feb 5 09:42:51 1994 From: "William J. Coldwell" To: netbsd-amiga@cbmuucp.commodore.com Subject: MAILING LISTS ARE MOVING Cc: netbsd-x@cbmuucp.commodore.com, netbsd-dev@cbmuucp.commodore.com Sender: netbsd-dev-Owner@cbmuucp.commodore.com First off, let me apologize for having to make another change to the lists, especially so soon after the last one. BUT, there are some really good sides to this... 1) The site we're moving to is sun-lamp.cs.berkeley.edu.. sound familiar? This means that it will be stable, and will be around forever (well, long enough) 2) It uses the Majordomo mail list handler software, which means everything stays the same as far as the commands that you are used to. 3) You won't have to resubscribe.. that's right.. we're just moving you right on over there... 4) I still remain your dedicated NetBSD-Amiga admin. Why is this good? Because you don't have to learn the new person's name to complain to him ;-). You will have to change a few things on your end: 1) Obviously, you will have to change the site name. cbmuucp will forward the current lists and new (un)subscribes to sun-lamp for you for a while. 2) the NetBSD-X and NetBSD-Dev list names will _have_ to change to not conflict/confuse the current list names there. I will post more info on that in the next message. Why are we moving? I can't say at this time, but it will become clear soon. -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From local@cbmuucp.commodore.com Sat Feb 5 17:17:41 1994 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Problem with tape unit Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I'm having a problem with a tape unit I just bought, I'm not sure if it's a bug, or configuration problem. I compiled my own kernel and added the following: tape st0 at gvp11scsi slave 2 now when I try to use the tape I use the following command: tar czvpf /dev/rst0 /etc/ Which will produce the following errors while packing the files (which it does with limited succes. at the start: st: stat-0, blklen=512 displays a couple file names then prints Feb 5 04:41:26 cquest /vmunix: st: stat=0, blklen=512 Feb 5 04:41:26 cquest /vmunix: st: stat=0, blklen=512 displays the rest of the files being packed then at the end displayss these errors: st0: I/O not block aligned 512/7798 st0: ILLEGAL REQUEST Feb 5 04:35:27 cquest /vmunix: st0: I/O not block aligned 512/7798 tar (child): can't write to /dev/rst0: Input/Output error Feb 5 04:35:28 cquest /vmunix: st0: ILLEGAL REQUEST Then when I try to unpack using the following, I find myself missing some files directorys and symlinks: tar xzvpf /dev/rst0 Perhaps this is a bug, but it could be a configuration problem or something I need to do different. I just bought the tape drive and have a 7 day trial to make sure it works right (it's used) and could really use the help on this. It's a gvp 150 meg wangtech tape drive internal which I have hooked up the third on a line with a 240 meg HD and a 42 meg hd. If you can offer suggestions to try please do. Thanks! -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From local@cbmuucp.commodore.com Sat Feb 5 18:14:26 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Problem with tape unit Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 5, 11:10am, Joe Vasher wrote: > I'm having a problem with a tape unit I just bought, I'm not sure if > it's a bug, or configuration problem. It neither - it's how you are using it. > st: stat-0, blklen=512 > > displays a couple file names then prints > > Feb 5 04:41:26 cquest /vmunix: st: stat=0, blklen=512 > Feb 5 04:41:26 cquest /vmunix: st: stat=0, blklen=512 I think this is syslog echoing the previous output to the console. > Feb 5 04:35:27 cquest /vmunix: st0: I/O not block aligned 512/7798 > tar (child): can't write to /dev/rst0: Input/Output error > Feb 5 04:35:28 cquest /vmunix: st0: ILLEGAL REQUEST > > Then when I try to unpack using the following, I find myself missing some > files directorys and symlinks: > > tar xzvpf /dev/rst0 > > Perhaps this is a bug, but it could be a configuration problem or something I > need to do different. I just bought the tape drive and have a 7 day trial to > make sure it works right (it's used) and could really use the help on this. > It's a gvp 150 meg wangtech tape drive internal which I have hooked up the > third on a line with a 240 meg HD and a 42 meg hd. > > If you can offer suggestions to try please do. Thanks! The problem is that the Wangtek tape drive only works with fixed-length blocks of 512 bytes. By specifying the 'z' option on tar, the tar output is passed through compress. The output of compress will not be a multiple of 512 bytes, so when the tape driver receives a buffer that is not a multiple of 512 bytes, it will generate the "I/O not block aligned" message: the first number is the block size, the second number is the size of the buffer. The tape driver will then force the I/O to generate an error by clearing the fixed-length bit in the SCSI command, which will cause the "illegal request" error. This also means that that data (which is probably the the last output from compress) will not get written to the tape, so will be missing when you try to restore. To write to the tape correctly, you either need to remove the 'z' option on tar (so that the output will be a multiple of 512 bytes), or you need to pipe the tar output to dd and specify the block size on dd. I don't remember if dd will pad the data to a blocksize boundary by default, or if you need to tell dd to pad it. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From local@cbmuucp.commodore.com Sat Feb 5 18:28:21 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Problems starting network Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 4, 4:26pm, DCG9367@tntech.edu wrote: > > I have installed version 744 and all of the binaries excpet for X11R5. > When I try to go to multiuser mode, it gets through saying "starting > network ..." and then it freezes. I had to reboot back to single user > and executed /etc/netstart with sh -x /etc/netstart. It spits out > a few envrionment variable definitions and then hangs after gated=NO > When I do these by hand, they work fine. Does anyone know whats going > on?!?! > > I have a 2000, GVP G-Force 040/33 with 4mb 32-bit, and a Retina. > Nothing else special. I'm not certain that the 744 version of the kernel will run properly in 4MB. I've had trouble running the last few versions of the kernel in 4MB. If I rebuild the kernel and reduce the size by removing some items from the configuration. Prior to my modifications to the scsi drivers, I had to get rid of the ISO file system (which meant I couldn't use my CDROM) and had to build a kernel with only Zeus SCSI support. Since I have consolidated the scsi drivers, I can now run with both the Zeus and 33C93 drivers, but I still can't include the ISO file system. I looked into this problem a while ago. I don't remember which version of the kernel it was, but I found that if I had just a few more pages of memory, the kernel would run (but swapped considerably). What I would see was that the kernel would boot fine in single user mode, but when I tried to start multi user mode, it would hang. The hang turned out to be the vmfault routine waiting for an available physical page. I haven't figured out any solution other than more memory or a smaller kernel. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From local@cbmuucp.commodore.com Sat Feb 5 18:32:54 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Eric Glanz - Unix Support , netbsd-amiga@cbmuucp.commodore.com Subject: Re: NetBSD boot error... Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 4, 1:43pm, Eric Glanz - Unix Support wrote: > I am having a strange problem, and was wondering if anyone had an answer for > this: > > I have a 3000T, 5meg of memory, and have a 200 meg hitachi drive dedicated to > BSD (ID #6). After laying down the boot partition with filetodev and booting > BSD, I get the following error: > > sl0 attached > ppp0 attached > changing device to sd6a > > dmanext at end!!! > > Then BSD halts... > > Any reason why this happens? I had the boot partition working correctly > before, and and using the exact same filetodev parameters as before, except > this time I get this error! Any ideas? This problem has happened to at least two other people with A3000T systems. I think my latest changes to the scsi drivers may have fixed the problem. I don't know of any kernels with these changes available yet. I think if you binpatch _scsi_no_dma, you should be able to get the system booted up. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From local@cbmuucp.commodore.com Sat Feb 5 22:43:20 1994 From: DCG9367@tntech.edu Subject: Re: Problems starting network To: osymh@gemini.oscs.montana.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"osymh@gemini.oscs.montana.edu" X-Vms-Cc: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: netbsd-amiga-Owner@cbmuucp.commodore.com >of memory, the kernel would run (but swapped considerably). What I >would see was that the kernel would boot fine in single user mode, but >when I tried to start multi user mode, it would hang. The hang turned >out to be the vmfault routine waiting for an available physical page. I finally found out what was causing my hang up. I had forgotten to get the new binaries for ps, bash, and make. Bash was the culprit. After the netstart script sets gated_flags it then executes this: hostname=`cat /etc/hostname` (or something like that). The backquotes crashed Bash on the 040 ( I remember reading this earlier). When I installed the new Bash, everything was alright. Multiuser mode comes up just fine; at least for now :) I plan on getting more memory as soon as I can get the money (GVP simms are EXPENSIVE!) I still don't know what to do about my tape drive though?!? David. From local@cbmuucp.commodore.com Sun Feb 6 00:49:32 1994 From: Tim Newsham Subject: kermit/tty bug To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: netbsd-amiga-Owner@cbmuucp.commodore.com (re kermit and /dev/tty00) Ok. I finally got around to having the remote echo various characters back at me to see if it would trigger the strange behaviour I observed. I tried all characters from 0 to 200, only '^S' triggers the problem. When I receive a control-S, I cannot send anything to the remote serial line even though I may receive (even from processes other than kermit). If I try to exit kermit at this point, only the child process dies and the original process stays around indefinitely. What is the correct behaviour of the serial line when receiving a control-s? If the remote truely sent it then the local should probably stop sending right? What about if it was caused by line noise? The local has no way of getting the remote to send back a ^Q (or any key, in the case of IXANY). It seems that the process that originally opened the line cannot close it either (or at least kermit cannot) so the only solution at this point is a reboot. This doesnt sound right. Tim N. From local@cbmuucp.commodore.com Sun Feb 6 03:17:39 1994 From: mbeausej@qc.bell.ca (michel beausejour) To: netbsd-amiga@cbmuucp.commodore.com Subject: files required Sender: netbsd-amiga-Owner@cbmuucp.commodore.com If i want to recompile the kernel,do i need the bsdsysrc744.tar.ga file only? where is the gcc compiler and support files? Thank you Michel B From local@cbmuucp.commodore.com Sun Feb 6 09:04:09 1994 From: cavatina@gnu.ai.mit.edu To: netbsd-amiga@cbmuucp.commodore.com Subject: MAILING LISTS ARE MOVING Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > 1) The site we're moving to is sun-lamp.cs.berkeley.edu.. sound familiar? > This means that it will be stable, and will be around forever (well, long > enough) > Why are we moving? I can't say at this time, but it will become clear soon. C='s going belly-up? From local@cbmuucp.commodore.com Sun Feb 6 16:01:07 1994 From: Vince Reed -- "Sub Zero" To: netbsd-amiga@cbmuucp.commodore.com Subject: Non FPU Kernel Sender: netbsd-amiga-Owner@cbmuucp.commodore.com NetBSD'ers... I wanna run netbsd on a 1000 with Derrringer 50MHZ '030 board that has no fpu. anybody got a bootable kernel they can ship me to start with? The kernels in the ftp sites I've checked assume an FPU. Vince Reed (waiting to start running netbsd) From local@cbmuucp.commodore.com Sun Feb 6 19:39:29 1994 From: Gregory Kritsch Subject: Okay, what's the deal with the termcap file... To: netbsd-amiga@cbmuucp.commodore.com (NetBSD Amiga List) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 508 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Okay, I give up! Once upon a time, with a 600 series kernel, in multi-user mode, I managed to get vi and more and tset to work. Thing is I don't remember doing anything to cause this to happen. I was hoping upgrading to the 720 rootfs would magically solve my problem, well, it didn't... Why can't vi/tset/more read the termcap file? I've heard one reference to this having been ``explained'' elsewhere, but I can't find any references. What must I do to get termcap functions working?? Help! Gregory From local@cbmuucp.commodore.com Sun Feb 6 21:42:12 1994 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: ttyd0 or tty00 which and were is? Sender: netbsd-amiga-Owner@cbmuucp.commodore.com In taylor uucp docs, there is a reference to use ttyd0 for dialing out. It seems that such a file doesn't exits in the dev directory. Is there something else that is needed to be used for NetBSD. thanks -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From local@cbmuucp.commodore.com Sun Feb 6 22:09:01 1994 To: cavatina@gnu.ai.mit.edu Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: MAILING LISTS ARE MOVING From: Raffie's Protege Sender: netbsd-amiga-Owner@cbmuucp.commodore.com => => > 1) The site we're moving to is sun-lamp.cs.berkeley.edu.. sound familiar? => > This means that it will be stable, and will be around forever (well, long => > enough) => > Why are we moving? I can't say at this time, but it will become clear soo n. => => C='s going belly-up? :-) Haha..thas pretty good. :) I hope it isn't true of course. :) sri =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |Sriram Ramkrishna email: |Purdue University Computing Center internet: aru@mentor.cc.purdue.edu |General Consultant/Systems Operator bitnet: xaru@purccvm.bitnet From local@cbmuucp.commodore.com Sun Feb 6 22:43:47 1994 From: mw@eunet.ch Subject: Re: ttyd0 or tty00 which and were is? To: jvasher@cquest.mi.org (Joe Vasher) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 407 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > In taylor uucp docs, there is a reference to use ttyd0 for dialing > out. It seems that such a file doesn't exits in the dev directory. Is there > something else that is needed to be used for NetBSD. Use /dev/tty00 for dialout. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Sun Feb 6 23:39:40 1994 From: Zik Saleeba Subject: nfs problems solved To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 727 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I finally found the source of the problems I was having with getting my A3000 to serve nfs - in sheer desperation I copied across mountd, nfsd and nfsiod from the newer binary distribution and suddenly all was working well! Somehow I must have forgotten to update some of the binaries on my old 8Mb rootfs. Thanks to everyone who offered suggestions! +-----------------------------------+------------------------------------+ | zik@zikzak.apana.org.au | "People who like quotations | | zik@bruce.cs.monash.edu.au | love meaningless generalisations" | | Zik Saleeba | - Graham Greene | +-----------------------------------+------------------------------------+ From local@cbmuucp.commodore.com Sun Feb 6 23:59:17 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: ADOS filesystem To: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 129 Sender: netbsd-dev-Owner@cbmuucp.commodore.com I would really like to get my hands on this :^) What part of the system is GNU copyleft? (i.e. needs to be re-written) Chris. From local@cbmuucp.commodore.com Mon Feb 7 02:04:14 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Non FPU Kernel" (Feb 6, 9:54am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Vince Reed -- "Sub Zero" , netbsd-amiga@cbmuucp.commodore.com Subject: Re: Non FPU Kernel Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 6, 9:54am, Vince Reed -- "Sub Zero" wrote: > I wanna run netbsd on a 1000 with Derrringer 50MHZ '030 board that > has no fpu. anybody got a bootable kernel they can ship me to start with? > The kernels in the ftp sites I've checked assume an FPU. The kernel is not the problem - the tools are the problem. It starts with fsck and ends at dc - they all need fpu. -- Markus Illenseer From local@cbmuucp.commodore.com Mon Feb 7 02:05:42 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Okay, what's the deal with the termcap file..." (Feb 6, 1:29pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Gregory Kritsch , netbsd-amiga@cbmuucp.commodore.com (NetBSD Amiga List) Subject: Re: Okay, what's the deal with the termcap file... Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 6, 1:29pm, Gregory Kritsch wrote: > Why can't vi/tset/more read the termcap file? I've heard one reference > to this having been ``explained'' elsewhere, but I can't find any references. > What must I do to get termcap functions working?? export TERM=vt100 export TERMCAP=/etc/termcap -- Markus Illenseer From local@cbmuucp.commodore.com Mon Feb 7 07:05:06 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1086 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: BFFS 1.3 problem Sender: netbsd-amiga-Owner@cbmuucp.commodore.com I have installed the BFFSFileSystem and got it to automount my three NetBSD partitions for me (i.e., the partitions are already available in the boot manager). I haven't actually tried writing to them, but otherwise things seem to work fine. Is it dangerous to write to the NetBSD partitions from AmigaDOS? Like how about creating a Disk.info file on them? :-) Anyway, the problem I am having is that the "user_manual" states that I should change reserved blocks at beginning to "-1" using HDToolBox (as I have it in my mountlist entry). I did that, but now NetBSD can't find my root partition anymore. I changed the value back to "0" and NetBSD works again. Also the partition still automounts correctly. What does that "-1" stand for anyway? Is it important at all? Thanks, Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@cs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE_Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From local@cbmuucp.commodore.com Mon Feb 7 11:06:38 1994 From: Tim Newsham Subject: BSD Vs USL To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: netbsd-amiga-Owner@cbmuucp.commodore.com !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! FOR IMMEDIATE RELEASE UNIX System Laboratories, Inc. and the University of California, Berkeley have announced they have reached an agreement resolving their disputes. The settlement clears the way for the University to release a new, unencumbered version of the Berkeley 4.4 BSD operating system software, to be called 4.4 BSD-Lite. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From local@cbmuucp.commodore.com Mon Feb 7 13:33:40 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "BSD Vs USL" (Feb 6, 11:16pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Tim Newsham , netbsd-amiga@cbmuucp.commodore.com Subject: Re: BSD Vs USL Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 6, 11:16pm, Tim Newsham wrote: > Subject: BSD Vs USL Where can one obtain the official statement for that? NetBSD-Lite? :-) -- Markus Illenseer From local@cbmuucp.commodore.com Mon Feb 7 16:16:20 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Meeting Karlsruhe Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Hello, just a little review for the Amiga Internet/Usenet meeting we had last weekend in Karlsruhe/Germany. About 80 Amiga-freaks were assembled, of which about 10 used NetBSD, thus we can say it was a 'whole NetBSD-Amiga community of Germany'-meeting :-) As Markus Wild also attended the meeting, we had lot of stuff to speak about and to discuss. Using the local network - Ethernet or Slip/ppp - many of the network-clients have been used and prooved once again the stability of NetBSD. It was just too easy (I cite hubertf) to install slip: just 3 commands needed, no further headaches :-) (Contrary to the AmigaDos-Freaks with Envoy) Using nfs and ftp, most tried to catch up their delay on current sources and binaries, also some nice binaries for X11 were found and compiled, small machines could even use X11 via nfs. I am really pleased to see the Xretina X server (haven't seen it before), it's quite fast and looks awfully good! It was also fun to use X on an A2024 with 1024x1024 in mono, workstation- feelings! You may ask what we have done other than testing and discusing - not much :-) We were all to busy to use NetBSD, rather than to develop anything new. I finished the X11-FAQ (needs some more polishment, will release RSN) and began a 5MB minimal Rootfs, which will handle simple network-stuff and will also have X11 support *grin*. All in all - not very productive, but much fun! -- Markus Illenseer From local@cbmuucp.commodore.com Mon Feb 7 16:21:35 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Installation Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Just a reminder, with the release of BFFS 1.3 we should reconsider the Installation of NetBSD. It is no longer needed to use dcp/filetodev, a normal partition will be sufficient due to the provided newfs of BFFS, hence, all we need is a good lha-file (or tgz). Anyone willing to test that, and creating such a new 'rootfs.lha' ? As a base i'd say the files of rootfs.720 are a good start. -- Markus Illenseer From local@cbmuucp.commodore.com Mon Feb 7 16:38:43 1994 From: Alan Bair Subject: Re: Installation To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > > Just a reminder, with the release of BFFS 1.3 we should > reconsider the Installation of NetBSD. It is no longer needed > to use dcp/filetodev, a normal partition will be sufficient > due to the provided newfs of BFFS, hence, all we need is > a good lha-file (or tgz). > > Anyone willing to test that, and creating such a new 'rootfs.lha' ? > As a base i'd say the files of rootfs.720 are a good start. I'd be willing to give it a try. I just picked up the BFFS release last night, but have not installed it yet. Since I built the rootfs_720 and it is still in place, I could use it as a quick test. I have been planning on building a "small" rootfs, with the idea that it could be used as the initial install. Then with a minimal NetBSD running, tar could be used to add to this or build larger root partitions. Your idea of a reduced rootfs sounds like the same idea. Could you provide some details on what is the minmum required. > > > -- > Markus Illenseer > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From local@cbmuucp.commodore.com Mon Feb 7 17:13:01 1994 From: francis@hasler.ascom.ch (Francis Demierre) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation (BFFS 1.3) Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) > Date: Mon, 7 Feb 1994 16:14:30 MET > X-Mailer: Mail User's Shell (7.1.0 4/25/90) > To: netbsd-amiga@cbmuucp.commodore.com > Subject: Installation > Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Content-Length: 415 > Status: RO > > Just a reminder, with the release of BFFS 1.3 we should > reconsider the Installation of NetBSD. It is no longer needed > to use dcp/filetodev, a normal partition will be sufficient > due to the provided newfs of BFFS, hence, all we need is > a good lha-file (or tgz). > > Anyone willing to test that, and creating such a new 'rootfs.lha' ? > As a base i'd say the files of rootfs.720 are a good start. > > > -- > Markus Illenseer > Hi Markus, do you have an idea where I can get BFFS 1.3 ? (I looked thru ftp.eunet.ch and could not find it !) Thanks in advance Francis. ----------------------------------------------------------------------- Francis Demierre SMTP : francis@hasler.ascom.ch Ascom Hasler AG, UUCP: ...!mcsun!chsun!hslrswi!francis Abt. NVEI2, X.400: S=francis/O=ascom/P=eunet/A=arcom/C=ch Belpstrasse 37,, Tel. : +41 31 999 3503 CH-3000 Bern 14 Fax : +41 31 999 3735 ----------------------------------------------------------------------- From local@cbmuucp.commodore.com Mon Feb 7 18:17:03 1994 From: mw@eunet.ch Subject: Re: BFFS 1.3 problem To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 353 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Anyway, the problem I am having is that the "user_manual" states that > I should change reserved blocks at beginning to "-1" using HDToolBox Eh, that's bogus.. that value has to be 0. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Mon Feb 7 18:22:00 1994 From: hooper@gdls.com (Chris Hooper) To: mw@eunet.ch, sgberg@charon.bloomington.in.us Subject: Re: BFFS 1.3 problem Cc: netbsd-amiga@cbmuucp.commodore.com Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > > Anyway, the problem I am having is that the "user_manual" states that > > I should change reserved blocks at beginning to "-1" using HDToolBox > > Eh, that's bogus.. that value has to be 0. I should have stated in the user_manual that for anyone running NetBSD, the value should be zero. BFFS is using the Reserved blocks field to decide whether or not to look for a partition table. Since NetBSD on the Amiga is not using the BSD partition table BFFS wouldn't find it anyway. Markus is right. A value of zero should work fine for you. - Chris Hooper Computer Sciences Corporation - System Support Engineer at hooper@gdls.com General Dynamics [Sterling Heights, MI] (810) 825-5061 From local@cbmuucp.commodore.com Mon Feb 7 18:31:06 1994 From: hooper@gdls.com (Chris Hooper) To: markus@TechFak.Uni-Bielefeld.DE, netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Just a reminder, with the release of BFFS 1.3 we should > reconsider the Installation of NetBSD. I believe Ty Sarna is already working on this for the CD-ROM installation package he is setting up. He helped beta test BFFS, so you might want to find out from him if he already has something running. - Chris Hooper Computer Sciences Corporation - System Support Engineer at hooper@gdls.com General Dynamics [Sterling Heights, MI] (810) 825-5061 From local@cbmuucp.commodore.com Mon Feb 7 18:49:43 1994 From: mw@eunet.ch Subject: Re: Installation To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 586 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Just a reminder, with the release of BFFS 1.3 we should > reconsider the Installation of NetBSD. It is no longer needed > to use dcp/filetodev, a normal partition will be sufficient > due to the provided newfs of BFFS, hence, all we need is > a good lha-file (or tgz). Eh, take care... I'd say it's very difficult to do this under ados, as we can't create device-nodes, and they're certainly required for a rootfs... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From local@cbmuucp.commodore.com Mon Feb 7 18:54:22 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 7, 6:35pm, mw@eunet.ch wrote: > > Just a reminder, with the release of BFFS 1.3 we should > > reconsider the Installation of NetBSD. It is no longer needed > > to use dcp/filetodev, a normal partition will be sufficient > > due to the provided newfs of BFFS, hence, all we need is > > a good lha-file (or tgz). > > Eh, take care... I'd say it's very difficult to do this under ados, > as we can't create device-nodes, and they're certainly required for > a rootfs... There is a mknode command included in BFFS 1.3, according to the documentation, this will create the device nodes. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From local@cbmuucp.commodore.com Mon Feb 7 18:55:21 1994 From: Markus Landgraf To: netbsd-amiga@cbmuucp.commodore.com Subject: ppp to sun crashes Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Hi NetBSDers, I try to run a ppp link to a Sparc Cassic under Solaris 2.3. On the Sparc side we use the ppp which is included in Solaris aspppd/aspppls. All works well until the two ppp-daemons get in contact, at this moment the sparc reboots. I have tested this with the following procedure: - First aspppd was stared automatically on the sparc - then I logged logged in via kermit from the NetBSD side - then I started the aspppls manually on the sparc - when wiered characters appear on the screen ( I think these are ppp configuration requests etc), I stop kermit and start the pppd on NetBSD. Until this moment all was as expected ( and documented). But in the moment the NetBSD pppd is started the Sparc dies. Can someone help me ? Is it a wrong config or just a Solaris bug ? Is it possible that NetBSD pppd produces invalid requests ? Thank you in advance for any help ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From local@cbmuucp.commodore.com Mon Feb 7 18:59:53 1994 From: Markus Landgraf To: netbsd-dev@cbmuucp.commodore.com Subject: Wangtek 6200 HS Sender: netbsd-dev-Owner@cbmuucp.commodore.com After consulting mw in how to read a sun tape which was written by a sun, I think I was able to configure the st.c to dive my Wangtek 6200 HS DAT drive (it was faily simple, 6200 works just like 5099). Is someone interested in the diffs ? Should they added to the standard kernel source ? ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From local@cbmuucp.commodore.com Mon Feb 7 19:02:17 1994 From: bsieker@TechFak.Uni-Bielefeld.DE (Bernd Sieker) "Re: Installation" (Feb 7, 12:16pm) X-Mailer: Z-Mail (2.1.5 09aug93) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation Content-Length: 1574 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com On Feb 7, 12:16pm, Chris Hooper wrote: > Subject: Re: Installation > > Just a reminder, with the release of BFFS 1.3 we should > > reconsider the Installation of NetBSD. > > I believe Ty Sarna is already working on this for the CD-ROM > installation package he is setting up. He helped beta test > BFFS, so you might want to find out from him if he already has > something running. I have read sometimes about a CD-ROM compilation of NetBSD. When and how will this be available? I know of some people who would lke to run UNIX, but have no ftp-access. > > - Chris Hooper Computer Sciences Corporation - System Support Engineer at > hooper@gdls.com General Dynamics [Sterling Heights, MI] (810) 825-5061 -- _ Real Life Bernd Sieker, Universitaet Bielefeld only // IRC Pink Amiga__// HAM Radio DG 6 YHI \X/ email bsieker@techfak.uni-bielefeld.de -------------------------------------- Minister, minister, care for your children, order them not into damnation to eliminate those who would trespass against you. (Fish, Forgotten Sons) -- _ Real Life Bernd Sieker, Universitaet Bielefeld only // IRC Pink Amiga__// HAM Radio DG 6 YHI \X/ email bsieker@techfak.uni-bielefeld.de -------------------------------------- Minister, minister, care for your children, order them not into damnation to eliminate those who would trespass against you. (Fish, Forgotten Sons) From local@cbmuucp.commodore.com Mon Feb 7 19:32:51 1994 From: carson@taltos.sbi.com To: Markus Landgraf Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: ppp to sun crashes Content-Length: 350 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Solaris 2.3 has a bug in its PPP code. Sun has released a patch - talk to your sun rep or (if you _really_ have no alternative) I can look up the patch number. I'd be more helpfull, but I'm swamped with work right now... -- Carson Gaspar -- carson@cs.columbia.edu, carson@taltos.sbi.com From local@cbmuucp.commodore.com Mon Feb 7 19:53:14 1994 From: francis@hasler.ascom.ch (Francis Demierre) To: landgraf@crunch.ikp.physik.th-darmstadt.de Subject: Re: ppp to sun crashes Cc: netbsd-amiga@cbmuucp.commodore.com Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Date: Mon, 7 Feb 1994 13:23:54 +0500 > Message-Id: <9402071823.AA09094@taltos.> > From: carson@taltos.sbi.com > To: Markus Landgraf > Cc: netbsd-amiga@cbmuucp.commodore.com > Subject: Re: ppp to sun crashes > In-Reply-To: <9402071747.AA15483@crunch> > References: <9402071747.AA15483@crunch> > Reply-To: carson@taltos.sbi.com > Content-Length: 350 > Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Status: RO > > > Solaris 2.3 has a bug in its PPP code. Sun has released a patch - talk to > your sun rep or (if you _really_ have no alternative) I can look up the > patch number. I'd be more helpfull, but I'm swamped with work right now... > > -- > Carson Gaspar -- carson@cs.columbia.edu, carson@taltos.sbi.com > > This might be the Patch ID (that is the only one about PPP for SunOS5.3 according to official patch list dated Sat Feb 5 22:16:43 MET 1994. Patch-ID# 101425-01 Keywords: negotiation address LCP packets ACKed Synopsis: SunOS 5.3: ppp violates standard for LCP packets. Date: Dec/13/93 Solaris Release: 2.3 SunOS release: 5.3 Topic: SunOS 5.3:ppp violates standard for LCP packets, interoperability problems BugId's fixed with this patch: 1145413 1150836 Relevant Architectures: sparc Francis From local@cbmuucp.commodore.com Mon Feb 7 21:19:22 1994 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Installation Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-amiga-Owner@cbmuucp.commodore.com In article <199402071735.SAA09575@eunet.ch> mw@eunet.ch writes: > Eh, take care... I'd say it's very difficult to do this under ados, > as we can't create device-nodes, and they're certainly required for > a rootfs... I suggested a mknod packet to Chris Hooper for just this reason, and he implemented it (actually, he worked out a more generalized CREATE_OBJECT packet with Randal Jessup and implemented that). I'm working on a tar command that knows how to take full advantage of BFFS, so it will be possible to do away with filesystem images soon. Unfortunately, I'm going to be really busy this week working on something else, so I won't be able to release tar until next week. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From local@cbmuucp.commodore.com Mon Feb 7 21:20:33 1994 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Installation Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-amiga-Owner@cbmuucp.commodore.com In article <9402071857.ZM7379@farn> bsieker@TechFak.Uni-Bielefeld.DE (Bernd Sieker) writes: > > I have read sometimes about a CD-ROM compilation of NetBSD. When and how > will this be available? My company is doing a NetBSD/amiga CDROM. There is no official timeline (because NetBSD has no official timeline). However, if you want to be notified when it gets close to production, send me mail and I'll put you on a list of interested people. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From local@cbmuucp.commodore.com Mon Feb 7 21:23:40 1994 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Installation Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: netbsd-amiga-Owner@cbmuucp.commodore.com In article <9402071716.AA13115@vangogh> hooper@gdls.com (Chris Hooper) writes: > > Just a reminder, with the release of BFFS 1.3 we should > > reconsider the Installation of NetBSD. > > I believe Ty Sarna is already working on this for the CD-ROM > installation package he is setting up. He helped beta test > BFFS, so you might want to find out from him if he already has > something running. Yes, I'll be releasing a tar command shortly that knows how to talk to BFFS 1.3 to create device nodes, links, etc, correctly. lha won't work because it doesn't know about those things. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From local@cbmuucp.commodore.com Mon Feb 7 21:30:17 1994 From: Hubert Feyrer Subject: re: mount flags MNT_SYNCHRONOUS ? To: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 680 Sender: netbsd-dev-Owner@cbmuucp.commodore.com > Does the mount flag MNT_SYNCHRONOUS in mount.h make the file system > physically write the data to the device immediately ? If not what > exactly does it do ? RTFM! ;-) From the mount-man-page: > M_SYNCHRONOUS All I/O to the file system should be done synchronously. I guess, this is clear. Regards, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf ========================================================================== From local@cbmuucp.commodore.com Mon Feb 7 22:25:34 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: clock losing time To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 475 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Ok, this must be something that others have noted too. The NetBSD clock really seems to loose some time. The drifting is around 10 minutes per day, at least. I tried to correct the time by using adjtime(2) system call (after writing a small program) but it hadn't any effect. Does this system call work at all? Anyway, the time drifting is my main problem. Is there some reason, why time is lost? 100Hz clock interrupts are missed? Why? My hardware is 25MHz A3000. ++Tero From local@cbmuucp.commodore.com Mon Feb 7 22:32:47 1994 From: Bob Slawson Cc: netbsd-amiga@cbmuucp.commodore.com Subject: clock losing time Sender: netbsd-amiga-Owner@cbmuucp.commodore.com From: tero.manninen@oulu.fi (Tero Manninen) Date: Mon, 7 Feb 1994 23:19:33 +0200 (EET) Ok, this must be something that others have noted too. The NetBSD clock really seems to loose some time. The drifting is around 10 minutes per day, at least. ??????? seconds perhaps I've never seen anything this large although I have noticed a loss of time after being up for a week or so. BobS From local@cbmuucp.commodore.com Mon Feb 7 22:46:24 1994 From: dvb@ssd.kodak.com (Dave Blaszyk) To: netbsd-amiga@cbmuucp.commodore.com Subject: bash Content-Length: 582 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Does anyone have a version of 'bash' for AmigaOS. The version of 'pdksh' that I have doesn't work well with pipes and redirection. I have tried the "latest" version of pdksh, and I still have the same problems. When I try recompiling the kernel, ``gnumake'' hangs and causes a guru when redirecting output to locore.s. Any help would be appreciated. /-// \\-\Dave Blaszyk e-mail : dvb@ssd.kodak.com /-//\ /\\-\(716) 253-7953 mail : Eastman Kodak ///d// \\v// \\b\\\ C Plant, Bldg. 10 MC 39011 \\\// \// \\/// Rochester, New York 14620 From local@cbmuucp.commodore.com Mon Feb 7 23:13:12 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: clock losing time To: bslawson@phobos.astro.uwo.ca Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 579 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > From: tero.manninen@oulu.fi (Tero Manninen) > Date: Mon, 7 Feb 1994 23:19:33 +0200 (EET) > > Ok, this must be something that others have noted too. > The NetBSD clock really seems to loose some time. The > drifting is around 10 minutes per day, at least. > ??????? > seconds perhaps > > I've never seen anything this large although I have noticed a loss of > time after being up for a week or so. No, this is minutes. I'll put the clock into right time now and check it after 12 to 24 hours. I'll let you know the accurate results then. ++Tero From local@cbmuucp.commodore.com Mon Feb 7 23:46:59 1994 Subject: Re: bash To: dvb@ssd.kodak.com From: "Fred Fish" Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 851 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com > Does anyone have a version of 'bash' for AmigaOS. There is a version on my Dec93 Freshfish CD-ROM that compiles and runs internal commands. It has problems running external commands, so it needs work. > The version of 'pdksh' > that I have doesn't work well with pipes and redirection. I have tried the "latest" > version of pdksh, and I still have the same problems. What "latest" version. The version on my CD-ROM has been working pretty well for me. I had similar problems with the version I got from aminet until I got a couple of patches from other people and rebuilt it. It's still not perfect, but now I can usually get through a complete gcc 3-stage build without crashing or getting enforcer hits. Before I would be lucky to get through a single stage build without having the system crash or get dozens of enforcer hits. -Fred From local@cbmuucp.commodore.com Tue Feb 8 00:21:45 1994 From: Zik Saleeba Subject: Re: clock losing time To: tero.manninen@oulu.fi (Tero Manninen) Cc: bslawson@phobos.astro.uwo.ca, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 990 Sender: netbsd-amiga-Owner@cbmuucp.commodore.com Tero Manninen said: > > > The NetBSD clock really seems to loose some time. The > > drifting is around 10 minutes per day, at least. > > ??????? > > seconds perhaps > > > > I've never seen anything this large although I have noticed a loss of > > time after being up for a week or so. > > No, this is minutes. I'll put the clock into right time now I can verify this. My A3000 seems to lose quite a few minutes each day - sometimes it's nearly an hour behind by the time the system crashes after a few days :-) (And there I was thinking that it was my A2232 driver causing the problem :-) +-----------------------------------+------------------------------------+ | zik@zikzak.apana.org.au | "People who like quotations | | zik@bruce.cs.monash.edu.au | love meaningless generalisations" | | Zik Saleeba | - Graham Greene | +-----------------------------------+------------------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 05:45:03 1994 From: "William J. Coldwell" To: netbsd-amiga@cbmuucp.commodore.com Subject: TEST Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu You should get this message twice. -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 05:54:22 1994 From: "William J. Coldwell" To: netbsd-amiga@cbmuucp.commodore.com Subject: TEST Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu You should get this message twice. -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 8 06:00:39 1994 From: "William J. Coldwell" To: amiga@sun-lamp.cs.berkeley.edu Subject: ADMIN: News. Read this. Cc: amiga-x@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu The mailing list site has moved to sun-lamp.cs.berkeley.edu. The names of the lists _had_ to change also (yeh, I know..). cbmuucp will continue to forward the old names to the new lists at the new site for a short while (two weeks or less). UPDATE YOUR ALIASES, IN YOUR FILES AND IN YOUR FINGERS. WHAT WAS: NOW IS: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ netbsd-amiga@cbmuucp.commodore.com amiga@sun-lamp.cs.berkeley.edu netbsd-x@cbmuucp.commodore.com amiga-x@sun-lamp.cs.berkeley.edu netbsd-dev@cbmuucp.commodore.com amiga-dev@sun-lamp.cs.berkeley.edu By you getting this message, it obviously means that you are on the lists, and do not have to send majordomo@sun-lamp.cs.berkeley.edu any addition subscription messages. Bill NetBSD-Amiga Mailing List Administrator (Did I say "sun-lamp.cs.berkeley.edu" enough? ;-) -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Feb 8 06:04:35 1994 From: "William J. Coldwell" To: amiga@sun-lamp.cs.berkeley.edu Subject: ADMIN: News. Read this. Cc: amiga-x@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu The mailing list site has moved to sun-lamp.cs.berkeley.edu. The names of the lists _had_ to change also (yeh, I know..). cbmuucp will continue to forward the old names to the new lists at the new site for a short while (two weeks or less). UPDATE YOUR ALIASES, IN YOUR FILES AND IN YOUR FINGERS. WHAT WAS: NOW IS: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ netbsd-amiga@cbmuucp.commodore.com amiga@sun-lamp.cs.berkeley.edu netbsd-x@cbmuucp.commodore.com amiga-x@sun-lamp.cs.berkeley.edu netbsd-dev@cbmuucp.commodore.com amiga-dev@sun-lamp.cs.berkeley.edu By you getting this message, it obviously means that you are on the lists, and do not have to send majordomo@sun-lamp.cs.berkeley.edu any addition subscription messages. Bill NetBSD-Amiga Mailing List Administrator (Did I say "sun-lamp.cs.berkeley.edu" enough? ;-) -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 06:06:46 1994 From: "William J. Coldwell" To: amiga@sun-lamp.cs.berkeley.edu Subject: ADMIN: News. Read this. Cc: amiga-x@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu The mailing list site has moved to sun-lamp.cs.berkeley.edu. The names of the lists _had_ to change also (yeh, I know..). cbmuucp will continue to forward the old names to the new lists at the new site for a short while (two weeks or less). UPDATE YOUR ALIASES, IN YOUR FILES AND IN YOUR FINGERS. WHAT WAS: NOW IS: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ netbsd-amiga@cbmuucp.commodore.com amiga@sun-lamp.cs.berkeley.edu netbsd-x@cbmuucp.commodore.com amiga-x@sun-lamp.cs.berkeley.edu netbsd-dev@cbmuucp.commodore.com amiga-dev@sun-lamp.cs.berkeley.edu By you getting this message, it obviously means that you are on the lists, and do not have to send majordomo@sun-lamp.cs.berkeley.edu any addition subscription messages. Bill NetBSD-Amiga Mailing List Administrator (Did I say "sun-lamp.cs.berkeley.edu" enough? ;-) -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Feb 8 08:02:23 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Subject: compiling makedepend From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I took the source for mkdepend from my X source tree at work and tried to compile it. It complained about the following piece of code in main.c: 266 #ifdef _POSIX_SOURCE 267 sigemptyset(&sig_act.sa_mask); 268 sigaddset(&sig_act.sa_mask, SIGINT); 269 sigaddset(&sig_act.sa_mask, SIGQUIT); 270 sigaddset(&sig_act.sa_mask, SIGBUS); 271 sigaddset(&sig_act.sa_mask, SIGILL); 272 sigaddset(&sig_act.sa_mask, SIGSEGV); 273 sigaddset(&sig_act.sa_mask, SIGHUP); 274 sigaddset(&sig_act.sa_mask, SIGPIPE); 275 sigaddset(&sig_act.sa_mask, SIGSYS); 276 #else In order to get it through the compiler I added the following to def.h" /* * $XConsortium: def.h,v 1.17 91/05/13 10:23:29 rws Exp $ */ #include #include #include #define X_NOT_POSIX #ifndef X_NOT_POSIX blablabla . . [rest of stuff deleted] . After that, it compiled ok and I've now got a working mkdepend. Can someone tell me it this is OK ? Should X_NOT_POSIX be defined like that or did I make a terrible mistake ?? -John From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 08:03:46 1994 From: "William J. Coldwell" To: Tim Newsham Subject: Re: BSD Vs USL Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu Any idea how this will affect our development? Like perhaps positively? -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 08:53:24 1994 From: "William J. Coldwell" To: amiga@sun-lamp.cs.berkeley.edu Subject: ARCHIVE INFORMATION Sender: owner-amiga@sun-lamp.cs.berkeley.edu The lists are archived at sun-lamp.cs.berkeley.edu in the /pub/NetBSD/mailing-lists/amiga* files, and are available via anon-ftp, sup, and gopher. -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 16:57:24 1994 From: Matthias Kirschnick Subject: NetBSD-Amiga FAQ available via WWW To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 990 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello, today I put the FAQ into my WWW-page-tree. Feel free to access http://www.informatik.uni-erlangen.de/IMMD-IV/Persons/kirschni/ and follow the NetBSD-Amiga-FAQ link. Perhaps I'll put the other files from the DOCS-dir on our server, too. Are you interested? Matthias ------------------------------------------------------------------------------ Dipl.-Inf. Matthias Kirschnick Phone: 49 9131 85 8027 IMMD IV, Universitaet Erlangen-Nuernberg Fax1: 49 9131 85 8732 Martensstrasse 1; D-91058 Erlangen Fax2: 49 9131 39 388 kirschnick@immd4.informatik.uni-erlangen.de http://www.informatik.uni-erlangen.de/IMMD-IV/Persons/kirschni/ ------------------------------------------------------------------------------ "Es geht auch anders, aber so geht es auch!" "You can do this differently, but you can also do it like this!" (Lotti Huber) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 8 17:05:02 1994 From: graulich@cadis.de (Robert Graulich) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: compiling netbsd kernel Cc: graulich@cadis.de Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi! I want to recompile the NetBSD kernel, because it is too big for my A1000 (ChipRAM). I have the kernel sources for version 712 and GCC 2.5.7. I followed the instructions in RECOMPILE, but there are some problems. 1) I had to 'makedir' compile/amiga. (Ok, that's no problem.) 2) The config program generates a link named 'machine' in compile/amiga. But this link is dead. Where must I link it? I tried some pathes in the gcc hierarchy, but with no success. The great question is: Can I use the normal AmigaGCC to compile the NetBSD kernel? Or must I have a special version??? Robert. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 17:51:45 1994 From: terjem@stud.cs.uit.no (Terje Normann Marthinussen) Subject: Re: clock losing time To: zik@aurora.cc.monash.edu.au (Zik Saleeba) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1470 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Tero Manninen said: > > > > > The NetBSD clock really seems to loose some time. The > > > drifting is around 10 minutes per day, at least. > > > ??????? > > > seconds perhaps > > > > > > I've never seen anything this large although I have noticed a loss of > > > time after being up for a week or so. > > > > No, this is minutes. I'll put the clock into right time now > > I can verify this. My A3000 seems to lose quite a few minutes each day > - sometimes it's nearly an hour behind by the time the system crashes > after a few days :-) > > (And there I was thinking that it was my A2232 driver causing the problem :-) I've experienced something similar on my A2000 also when running AmigaDOS. I haven't really tried to check this out, but I'm pretty sure that the first time I noticed was after I started to run the WB in NTSC mode... (I am really a little confused about this thing, but... first time I noticed was after I switched to running WB in NTSC interlaced and was running ncomm on a PAL screen, well, it's the only thing that I can think of that got different in my setup, either that has nothing to do with it, or I simply haven't noticed before...) The fun thing is that the battery clock seems to stay right. If you try a setclock load the time will be correct again. I'll try (sometime after my exam tomorrow :) to check if I can find something that might do a difference. Terje Marthinussen terjem@stud.cs.uit.no From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 17:56:09 1994 From: terjem@stud.cs.uit.no (Terje Normann Marthinussen) Subject: BFFS 1.3, DirOpus etc. To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 389 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Just wondering. What is the reason why BFFS 1.3 won't work with the filecompletion in KingCon, or will give you any files in the file windows in Directory Opus when you try to access a BSD partition? I'm not really complaining, it's a lot better now when it does nothing, compared to earlier versions where it blocked (deadlocked?) my disk :) Terje Marthinussen terjem@stud.cs.uit.no From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 17:58:29 1994 From: Eric Augustine Subject: BFFS 1.3 To: amiga@sun-lamp.cs.berkeley.edu (Net Amiga) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 210 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Someone posted here a request to find where you can get BFFS 1.3 at this time, since it isn't present at eunet as of 08Feb94. Are we waiting for it? Or did I miss something somewhere? Thanks - - Eric From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 18:14:46 1994 Subject: Re: BFFS 1.3, DirOpus etc. From: David Jones To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Just wondering. > What is the reason why BFFS 1.3 won't work with the filecompletion > in KingCon, or will give you any files in the file windows in Directory Opus > when you try to access a BSD partition? BFFS does not support AmigaOS filesystem semantics. e.g. cd / goes to parent under AmigaOS, but root on BFFS. This may be enough to break you. Also, AmigaOS doesn't grok symlinks that well. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 18:49:31 1994 From: mw@eunet.ch Subject: Re: clock losing time To: tero.manninen@oulu.fi (Tero Manninen) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 463 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > The NetBSD clock really seems to loose some time. The > drifting is around 10 minutes per day, at least. Measure it as good as you can (over a long enough period), than divide the measured by the real amount of time passed, and adjust the constant that is loaded in the CIA timer appropriatly. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 19:38:53 1994 Subject: Re: clock losing time (fwd) To: amiga@sun-lamp.cs.berkeley.edu From: Cornelius Keck X-Mailer: ELM [version 2.3 PL11 913261353] Content-Type: text Content-Length: 818 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Zik Saleeba said: > > Tero Manninen said: > > > > > The NetBSD clock really seems to loose some time. The > > > drifting is around 10 minutes per day, at least. > > > ??????? > > > seconds perhaps > > > > > > I've never seen anything this large although I have noticed a loss of > > > time after being up for a week or so. > > > > No, this is minutes. I'll put the clock into right time now > > I can verify this. My A3000 seems to lose quite a few minutes each day > - sometimes it's nearly an hour behind by the time the system crashes > after a few days :-) > > (And there I was thinking that it was my A2232 driver causing the problem :-) > Same thing here. Clock drifts some minutes per day. This "feature" is available not only with NetBSD, but also under Amiga-Unix 2.1c. CU, CK. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 21:55:58 1994 X400-Originator: /dd.id=1619692/g=hamish/i=hi/s=macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.916:08.01.94.20.34.25] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: clock los... From: "hamish (h.i.) macdonald" To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: clock losing time Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> On Tue Feb 8 15:14:00 1994, >>>>> Tero wrote: tero> That's not strange, because battery backed clock runs its own tero> life, totally separated of the CIA timers. Now in NetBSD we tero> seem to use one interval timer for a 100Hz counter. Here is tero> the catch: tero> /usr/src/sys/arch/amiga/amiga/clock.c tero> /* the clocks run at NTSC: 715.909kHz or PAL: 709.379kHz. tero> We're using a 100 Hz clock. */ tero> #define CLK_INTERVAL (715909 / 100) tero> and later.. tero> interval = CLK_INTERVAL - 1; tero> ciab.talo = interval & 0xff; tero> ciab.tahi = interval >> 8; tero> BTW, could this be a configurable thing (PAL vs. NTSC) like many tero> other things in system configuration file? AmigaDOS knows the E clock frequency (the frequency of ticks that the CIAs count). This problem is solved in linux by having the linux bootstrap loader pass this frequency indication to the kernel via the "boot info" structure which contains all the other configuration information. The kernel then sets the number of CIA ticks in a 100Hz tick appropriately. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 22:47:45 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: clock losing time" (Feb 8, 5:35pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: clock losing time Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 8, 5:35pm, Terje Normann Marthinussen wrote: > I haven't really tried to check this out, but I'm pretty sure that the first > time I noticed was after I started to run the WB in NTSC mode... > (I am really a little confused about this thing, but... first time I noticed > was after I switched to running WB in NTSC interlaced and was running ncomm > on a PAL screen, well, it's the only thing that I can think of that got > different in my setup, either that has nothing to do with it, or I simply > haven't noticed before...) > > The fun thing is that the battery clock seems to stay right. > If you try a setclock load the time will be correct again. > > I'll try (sometime after my exam tomorrow :) to check if I can find > something that might do a difference. I wonder what happens here, because i never encountered such problems on my machine (A3000/25), and I alwys run NTSC (though PAL is enabled on the motherboard). -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 8 23:04:52 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: clock losing time To: terjem@stud.cs.uit.no (Terje Normann Marthinussen) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1576 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > (I am really a little confused about this thing, but... first time I noticed > was after I switched to running WB in NTSC interlaced and was running ncomm > on a PAL screen, I have been using NTSC screens for Workbench, but the machine is jumpered to PAL system. I have not experienced any time lossage in AmigaOS, but only with ixemul.library using programs (there is a same kind of bug in the ixemul like here (at least in older ixemul versions) ;-) > The fun thing is that the battery clock seems to stay right. > If you try a setclock load the time will be correct again. That's not strange, because battery backed clock runs its own life, totally separated of the CIA timers. Now in NetBSD we seem to use one interval timer for a 100Hz counter. Here is the catch: /usr/src/sys/arch/amiga/amiga/clock.c /* the clocks run at NTSC: 715.909kHz or PAL: 709.379kHz. We're using a 100 Hz clock. */ #define CLK_INTERVAL (715909 / 100) and later.. interval = CLK_INTERVAL - 1; ciab.talo = interval & 0xff; ciab.tahi = interval >> 8; When calculating the difference of 709.3 and 715.9 (note that the interval is divided by 100, thus losing accurary) I get only about 13 minutes too slow clock per 24 hours. As I promised yesterday, I have now calculated how much my clock loses time. Well.. it is: 17 minutes during a period of 21 hours!! So, the 17-13 minutes difference is still a mystery after CLK_INTERVAL adjustment.. BTW, could this be a configurable thing (PAL vs. NTSC) like many other things in system configuration file? > Terje Marthinussen ++Tero From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 8 23:53:58 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Arcnet-driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I am currently in the nice position to have two Amiga's connected with ArcNet (A2060). The problem is that i'd need any source code for a 2060.device in order to be able to write a, hm, a0 driver for NetbSD-Amiga. I want to try out if it is possible to make the driver somewhat transparent so that all the other clients like ifconfig will work with it assuming the card is a ethernet-card rather than arcnet, if this is not possible i go the easy way, but then we probabl will have to change some other parts of other sources... Anyone? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 01:23:39 1994 From: Eric Augustine Subject: BFFS 1.3 To: amiga@sun-lamp.cs.berkeley.edu (Net Amiga) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 181 Sender: owner-amiga@sun-lamp.cs.berkeley.edu My impatience is evident once again... BFFS 1.3 finally showed up at eunet sometime this afternoon (Which I might assume means early in the morning there...) Thanks - Eric From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 9 02:43:38 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Loadbsd To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 470 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Anyone trying to run from the current sources should note 2 things: - mv the ld.old in /usr/bin to /usr/bin/kernel-ld - get the binary loadbsd-current.gz from ftp.eunet.ch (in incoming or when moved somewhere else :^) This is the same binary that M Hitch distributed and is a compile of the source in the stand directory of the same name. It correctly implements the version control that was added to the kernel to avoid the blank screen thing from now on. Chris. From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Feb 9 08:09:37 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Anyone got a new libXmu.so.5.0 ?? From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Just wondering if anoyone's got an new version of libXmu.so.5.0 I would like to use the xrdb program and that one doesn't seem to work with the current libXmu.so.5.0 -John From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 9 08:10:13 1994 To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: ld: RRS text relocation at 0x........... symbol ( ..... ) From: John Vrolijk Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Whenever I compile a program, I get dozens of the following message: ld: RRS text relocation at "some hex location" symbol ( some symbol name ) It occurs a number of times but the binaries seem to work ok. Do I need a new ld or something ? -John From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 08:15:49 1994 To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: ld: RRS text relocation at 0x........... symbol ( ..... ) From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Whenever I compile a program, I get dozens of the following message: ld: RRS text relocation at "some hex location" symbol ( some symbol name ) It occurs a number of times but the binaries seem to work ok. Do I need a new ld or something ? -John From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 08:29:42 1994 From: Mike Schwartz Subject: Re: BSD Vs USL To: newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL0] Content-Type: text Content-Length: 602 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > > FOR IMMEDIATE RELEASE > > UNIX System Laboratories, Inc. and the University > of California, Berkeley have announced they have reached an > agreement resolving their disputes. The settlement clears > the way for the University to release a new, unencumbered > version of the Berkeley 4.4 BSD operating system software, > to be called 4.4 BSD-Lite. > > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > Tastes GREAT! Less filling... Now do we have to watch the BSD bowl comerrcials during the superbowl? :-) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 9 11:00:23 1994 To: NetBSD-Dev@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Arcnet-driver Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9402082245.AA22151@jade.techfak.uni-bielefeld.de> markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) writes: > I am currently in the nice position to have two Amiga's connected > with ArcNet (A2060). The problem is that i'd need any source code > for a 2060.device in order to be able to write a, hm, a0 driver > for NetbSD-Amiga. I don't know if you could get a2060.device source code from Commodore, but the binary is only about 5.5K, so programming it can't be too difficult. Since it's so small, you could probably even disassemble it and figure it out fairly easily (relative to disassembling a scsi driver or something). You might also see what chip is on the board, and see if NetBSD/i386 has a driver for it (I don't know if they have any arcnet drivers,but it's worth looking). > I want to try out if it is possible to make the driver somewhat transparent > so that all the other clients like ifconfig will work with it assuming > the card is a ethernet-card rather than arcnet, if this is not possible > i go the easy way, but then we probabl will have to change some other > parts of other sources... You don't want to do this, any more than you'd want a slip driver that looked like ethernet. There is a RFC for IP-on-arcnet which you'll want to get and follow. It shouldn't be very difficult, and will probably work better (and be more compatible) that way. ifconfig & co shouldn't need any changes, since the if (interface) ioctls are designed to be fairly device-independant. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 9 12:08:48 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "ld: RRS text relocation at 0x........... symbol ( ..... )" (Feb 9, 7:57am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , amiga@sun-lamp.cs.berkeley.edu Subject: Re: ld: RRS text relocation at 0x........... symbol ( ..... ) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 9, 7:57am, John Vrolijk wrote: > Subject: ld: RRS text relocation at 0x........... symbol ( ..... ) > > Whenever I compile a program, > I get dozens of the following message: > > ld: RRS text relocation at "some hex location" symbol ( some symbol name ) > > It occurs a number of times but the binaries seem to work ok. > Do I need a new ld or something ? You just discovered the magic of shared libs... The above mentioned text is a debug information of the linker, nothing serious, just helpful. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 12:13:39 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "ld: RRS text relocation at 0x........... symbol ( ..... )" (Feb 9, 7:57am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , amiga@sun-lamp.cs.berkeley.edu Subject: Re: ld: RRS text relocation at 0x........... symbol ( ..... ) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 9, 7:57am, John Vrolijk wrote: > Subject: ld: RRS text relocation at 0x........... symbol ( ..... ) > > Whenever I compile a program, > I get dozens of the following message: > > ld: RRS text relocation at "some hex location" symbol ( some symbol name ) > > It occurs a number of times but the binaries seem to work ok. > Do I need a new ld or something ? You just discovered the magic of shared libs... The above mentioned text is a debug information of the linker, nothing serious, just helpful. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 12:14:26 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "BFFS 1.3" (Feb 8, 4:02pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Eric Augustine , amiga@sun-lamp.cs.berkeley.edu (Net Amiga) Subject: Re: BFFS 1.3 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 8, 4:02pm, Eric Augustine wrote: > Subject: BFFS 1.3 > > > My impatience is evident once again... BFFS 1.3 finally showed up > at eunet sometime this afternoon (Which I might assume means early > in the morning there...) Well, it was on AmiNet since friday :-) Remember, BFFs is for Amiga-DOS not NetBSD-Amiga, thus AmiNet is the best place to upload it. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 9 12:19:54 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Arcnet-driver" (Feb 9, 7:04am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tsarna@endicor.com (Ty Sarna), NetBSD-Dev@cbmuucp.commodore.com Subject: Re: Arcnet-driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 9, 7:04am, Ty Sarna wrote: > I don't know if you could get a2060.device source code from Commodore, > but the binary is only about 5.5K, so programming it can't be too > difficult. Since it's so small, you could probably even disassemble it > and figure it out fairly easily (relative to disassembling a scsi driver > or something). You might also see what chip is on the board, and see if > NetBSD/i386 has a driver for it (I don't know if they have any arcnet > drivers,but it's worth looking). Disassembling is already done, even with comments, just one problem - i have no idea of progamming with Assembler :-) The chip is either (U20) COM 90C26 / SMC C8934 or (U19) LH5216-12 / 8901 or is the Hybrid for interest (guess not). > You don't want to do this, any more than you'd want a slip driver that > looked like ethernet. There is a RFC for IP-on-arcnet which you'll want > to get and follow. It shouldn't be very difficult, and will probably > work better (and be more compatible) that way. ifconfig & co shouldn't > need any changes, since the if (interface) ioctls are designed to be > fairly device-independant. Ok, acknowledged. Which RFC is it? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 14:33:37 1994 From: Mike Schwartz Subject: Re: ld: RRS text relocation at 0x........... symbol ( ..... ) To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL0] Content-Type: text Content-Length: 610 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > On Feb 9, 7:57am, John Vrolijk wrote: > > Subject: ld: RRS text relocation at 0x........... symbol ( ..... ) > > > > Whenever I compile a program, > > I get dozens of the following message: > > > > ld: RRS text relocation at "some hex location" symbol ( some symbol name ) > > > > It occurs a number of times but the binaries seem to work ok. > > Do I need a new ld or something ? > > You just discovered the magic of shared libs... > The above mentioned text is a debug information of the linker, nothing > serious, just helpful. > Doesn't help me one bit :-) > > -- > Markus Illenseer > From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 9 16:18:59 1994 To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: new libXmu.so.5.0 ?? From: John Vrolijk Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Is there a new libXmu.so.5.0 ? If not, how can I recompile it ? I've the complete X11R5 tree on my Sun SS2. What do I need to rebuild a working libXmu.a and/or libXmu.so.5.0 ??? -John From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 16:22:21 1994 To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: new libXmu.so.5.0 ?? From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Is there a new libXmu.so.5.0 ? If not, how can I recompile it ? I've the complete X11R5 tree on my Sun SS2. What do I need to rebuild a working libXmu.a and/or libXmu.so.5.0 ??? -John From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 17:28:51 1994 X400-Originator: /dd.id=1619692/g=hamish/i=hi/s=macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.714:09.01.94.15.51.40] X400-Content-Type: P2-1984 (2) Content-Identifier: re:new libXmu... From: "hamish (h.i.) macdonald" To: etmjvro@etmsun.ericsson.se Cc: amiga@sun-lamp.cs.berkeley.edu Subject: re:new libXmu.so.5.0 ?? Sender: owner-amiga@sun-lamp.cs.berkeley.edu Please do *not* send messages to both the amiga and amiga-dev mailing lists. Use one *or* the other. I don't want multiple copies. Thanks, Hamish. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 19:54:27 1994 From: terjem@stud.cs.uit.no (Terje Normann Marthinussen) Subject: Re: clock losing time To: tero.manninen@oulu.fi (Tero Manninen) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1136 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > (I am really a little confused about this thing, but... first time I noticed > > was after I switched to running WB in NTSC interlaced and was running ncomm > > on a PAL screen, > > I have been using NTSC screens for Workbench, but the machine is > jumpered to PAL system. I have not experienced any time lossage > in AmigaOS, but only with ixemul.library using programs (there is > a same kind of bug in the ixemul like here (at least in older > ixemul versions) ;-) You are right, tried it out today. No differnce whatever I did. Lost a lot of time anyway. > As I promised yesterday, I have now calculated how much my > clock loses time. Well.. it is: 17 minutes during a period of > 21 hours!! So, the 17-13 minutes difference is still a mystery > after CLK_INTERVAL adjustment.. BTW, could this be a configurable > thing (PAL vs. NTSC) like many other things in system configuration > file? > He, I lost approx 5 minutes during a 30 minute period!!!!! Or.. after 30 minutes the difference between the battery clock and the CIA clock was approx 5 minutes... (Using AmigaOS...) Terje Marthinussen terjem@stud.cs.uit.no From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 20:09:52 1994 From: Hubert Feyrer Subject: Re: Meeting Karlsruhe To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1339 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Using the local network - Ethernet or Slip/ppp - many of the network-clients > have been used and prooved once again the stability of NetBSD. It was just > too easy (I cite hubertf) to install slip: just 3 commands needed, no ^^^ only 2: :-) 1.) slattach -s /dev/tty00 2.) ifconfig sl0 netmask 255.255.255.0 > further headaches :-) (Contrary to the AmigaDos-Freaks with Envoy) :-) > > Using nfs and ftp, most tried to catch up their delay on current sources > and binaries, also some nice binaries for X11 were found and compiled, > small machines could even use X11 via nfs. By the way, are those binaries released now? I missed to copy them, but I'd really like to have them... > > I am really pleased to see the Xretina X server (haven't seen it before), > it's quite fast and looks awfully good! Hm... have you seen DageeX on the Picasso II? THAT was fast...! Regards, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf ========================================================================== From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 20:56:20 1994 From: Bob Slawson To: amiga@sun-lamp.cs.berkeley.edu Subject: clock losing time Sender: owner-amiga@sun-lamp.cs.berkeley.edu He, I lost approx 5 minutes during a 30 minute period!!!!! Or.. after 30 minutes the difference between the battery clock and the CIA clock was approx 5 minutes... (Using AmigaOS...) ^^^^^^^ ==> _not_ a NetBSD problem Terje Marthinussen terjem@stud.cs.uit.no Me thinks your clock battery may be dying. They only have a 3--4 year life expectancy. I've seen this sort of problem in old Primitive Computers. BobS From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 9 22:35:30 1994 To: NetBSD-Dev@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Arcnet-driver Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9402091105.AA00630@aidec512.techfak.uni-bielefeld.de> markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) writes: > Ok, acknowledged. Which RFC is it? RFC1201 is what you want. you can get it at ftp.uu.net:/inet/rfc. You may need to get 1340 (asigned numbers) too. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 22:43:26 1994 From: ozzy@catt.ncsu.edu (Chris Mattingly) Posted-Date: Wed, 9 Feb 1994 16:26:46 -0500 (EST) Subject: slattach To: amiga@sun-lamp.cs.berkeley.edu (netbsd) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 556 Sender: owner-amiga@sun-lamp.cs.berkeley.edu When I try and to a slattach -s 19200 /dev/tty00 I get the following error: ioctl (SLIOCSFLAGS): Inappropiate ioctl for device. Any idea why I am getting this? I can use kermit just fine.... Thanks for any help.. -- Chris Mattingly | No nifty sig yet ... creativity is still on vacation. 414-C Wood Hall | PO Box 21553 | Home computer: A3000 - crazytrain.catt.ncsu.edu NCSU | 030/2Chip/4Fast/Math-Co Raleigh, NC 27607 | Email: Chris_Mattingly@ncsu.edu OR (919) 512-3230 | cmatting@nyx.cs.du.edu From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 9 23:25:55 1994 From: songcc@vnet.IBM.COM To: amiga@sun-lamp.cs.berkeley.edu Subject: DageeX Sender: owner-amiga@sun-lamp.cs.berkeley.edu >> I am really pleased to see the Xretina X server (haven't seen it before), >> it's quite fast and looks awfully good! > >Hm... have you seen DageeX on the Picasso II? THAT was fast...! Is DageeX an X server for NetBSD-Amiga or AmigaDOS? Also, What is the status of X servers for other graphics boards (e.g. GVP Spectrum, Piccolo, ...) and how do they compare? Cheng-Chung Song From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 10 01:31:57 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Meeting Karlsruhe" (Feb 9, 7:57pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Hubert Feyrer , markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Subject: Re: Meeting Karlsruhe Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 9, 7:57pm, Hubert Feyrer wrote: > 1.) slattach -s /dev/tty00 > 2.) ifconfig sl0 netmask 255.255.255.0 3) route add default juliet [...] > > and binaries, also some nice binaries for X11 were found and compiled, > > small machines could even use X11 via nfs. > > By the way, are those binaries released now? I missed to copy them, > but I'd really like to have them... Hem, ok, i will make a nice archive out of X11 binaries (you really interested in xspringies, xboulderdash and xasteroids? .-) > > I am really pleased to see the Xretina X server (haven't seen it before), > > it's quite fast and looks awfully good! > > Hm... have you seen DageeX on the Picasso II? THAT was fast...! I have :-) But thats not NetBSD :-/ (DaggeX beats everything seen for Amiga concerning X) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 10 08:36:26 1994 From: Tim Newsham Subject: tty00, ^s To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Does anyone know why tty00 locks up when it receives a ^S? How hard would it be to fix? Where would one look, in the amiga/dev/ser.c code? in the kernels tty code? Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 10 17:03:59 1994 From: Markus Landgraf To: mw@eunet.ch Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: ppp to sun crashes Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "mw" == mw writes: >> I try to run a ppp link to a Sparc Cassic under Solaris 2.3. On >> the mw> Did you apply sun-patch 101425-01? This is from its README: mw> Patch-ID# 101425-01 Keywords: negotiation address LCP packets mw> ACKed Synopsis: SunOS 5.3: ppp violates standard for LCP mw> packets. Date: Dec/13/93 mw> Solaris Release: 2.3 mw> SunOS release: 5.3 mw> Unbundled Product: mw> Unbundled Release: mw> Topic: SunOS 5.3:ppp violates standard for LCP packets, mw> interoperability problem s No, I didn't and I think this was the problem. I will test it at this weekend. My brother got the same information from the Sun Newsgroup. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 10 17:21:43 1994 From: Markus Landgraf To: mw@eunet.ch Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: ppp to sun crashes Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "mw" == mw writes: >> I try to run a ppp link to a Sparc Cassic under Solaris 2.3. On >> the mw> Did you apply sun-patch 101425-01? This is from its README: mw> Patch-ID# 101425-01 Keywords: negotiation address LCP packets mw> ACKed Synopsis: SunOS 5.3: ppp violates standard for LCP mw> packets. Date: Dec/13/93 mw> Solaris Release: 2.3 mw> SunOS release: 5.3 mw> Unbundled Product: mw> Unbundled Release: mw> Topic: SunOS 5.3:ppp violates standard for LCP packets, mw> interoperability problem s No, I didn't and I think this was the problem. I will test it at this weekend. My brother got the same information from the Sun Newsgroup. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 10 17:23:34 1994 From: Kevin M Mccarthy Subject: att2.cs.mankato.msus.edu To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 859 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I am sorry to have to inform this list, but the ftp site at att2.cs.mankato.msus.edu is going down tonight. The Computer Science department here is turning it into an OS/2 machine for a programming class. It may or may not come back next quarter... We'll have to see. Sorry for all of the inconvienience. If you have any questions or comments, mail me at signals@krypton.mankato.msus.edu. -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "I have all my wisdom teeth, Two up top, Two beneath. And yet I'll recognize, my mouth says things that aren't so wise." -Crash Test Dummies ------------------------------------------------------------------------------- GCS d++(--) p+ c++ !l u++ e+ m* ss/+ n-(--) h@ f+(?) !g w- t r- y+ From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 10 17:31:16 1994 From: mw@eunet.ch Subject: Re: ppp to sun crashes To: landgraf@crunch.ikp.physik.th-darmstadt.de (Markus Landgraf) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 618 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > I try to run a ppp link to a Sparc Cassic under Solaris 2.3. On the Did you apply sun-patch 101425-01? This is from its README: Patch-ID# 101425-01 Keywords: negotiation address LCP packets ACKed Synopsis: SunOS 5.3: ppp violates standard for LCP packets. Date: Dec/13/93 Solaris Release: 2.3 SunOS release: 5.3 Unbundled Product: Unbundled Release: Topic: SunOS 5.3:ppp violates standard for LCP packets, interoperability problem s Ciao, -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 10 18:09:44 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: tty00, ^S To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Does anyone know why tty00 locks up when it receives a ^S? Specifically your asking why a XOFF ( or XON, I'm not sure ) character does what it does. What you need to do is specify that the XON, XOFF characters need to be sent as data, instead of being translated by the terminal. > How hard would it be to fix? Where would one look, in the > amiga/dev/ser.c code? in the kernels tty code? The easiest way is to send a ^Q back as the next character to tell the terminal to resume display again. Ron Roskens From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 10 20:56:38 1994 From: Tim Newsham Subject: Re: tty00, ^s To: danny@astro.rug.nl (Danny R. Boxhoorn) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > Does anyone know why tty00 locks up when it receives a ^S? > > How hard would it be to fix? Where would one look, in the > > amiga/dev/ser.c code? in the kernels tty code? > > Er, maybe I'm wrong but isn't ^S normally the 'stop' character? > It is meant to halt output - while still taking input - so that > ^Scba will not show anything until ^Q is pressed after which > cba will be displayed. > stty -a will show you if ^S is bound to 'stop' or not. Yes, this is the stop character, but when tty00 is used to dial out (ie. kermit) this doesnt seem to be the proper behavior. It is not possible at this point to get the remote to send a ^Q because you cant get any info to the remote period. It is not possible at this point to exit and have tty00 reset, at least from kermit, kermit seems to hang in a dead state after the exit() system call is called. At this point nobody can use the device until the machine is rebooted. (Well, actually, receiving still works, just cant send any data on the serial line). > Kapteyn Laboratorium E-Mail: > Postbus 800 danny@astro.rug.nl > 9700 AV GRONINGEN danny@sron.rug.nl From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 10 20:56:40 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu Subject: x11_dist uploaded Sender: owner-amiga@sun-lamp.cs.berkeley.edu I uploaded the long-awaited x11 distribution of mine, hope you like it. Get the README.x11_dist first. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 10 21:30:25 1994 From: "William J. Coldwell" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: 5380 support added. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Michael incorporated my generic 5380 code into a kernel, which I have to wait a whole 8 hours until I get home to test. I believe that it will work right off of the bat. Next is IDE ;-)). -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Feb 11 09:17:45 1994 From: "Danny R. Boxhoorn" Subject: Re: tty00, ^s To: newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu "This announcement, produced by the author of this e-mail, contains important information and is *NOT* for broadcast!" X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 320 > It is not possible at this point to get the remote to send a > ^Q because you cant get any info to the remote period. It is > not possible at this point to exit and have tty00 reset, at least Maybe 'stty ixon' or 'stty ixany' solves the problem. Danny R. Boxhoorn From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Feb 11 10:28:36 1994 From: Tim Newsham Subject: Re: tty00, ^s To: danny@astro.rug.nl (Danny R. Boxhoorn) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > It is not possible at this point to get the remote to send a > > ^Q because you cant get any info to the remote period. It is > > not possible at this point to exit and have tty00 reset, at least > > Maybe 'stty ixon' or 'stty ixany' solves the problem. Here is the current settings while I am in kermit (I'm using it now) : speed 2400 baud; lflags: -icanon -isig -iexten -echo echoe echoke echoctl iflags: -icrnl ixoff -ixany ignbrk -brkint ignpar oflags: -opost cflags: cs8 -parenb clocal Notice that it is ixoff. Maybe this is the problem? Maybe the tty00 doesnt respond properly while in ixoff? Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 11 19:38:37 1994 From: "William J. Coldwell" To: amiga@sun-lamp.cs.berkeley.edu Subject: 5380 SCSI support added! Sender: owner-amiga@sun-lamp.cs.berkeley.edu Well, I have an A1200 with a CSA Twelve Gauge that comes up running NetBSD. The code that I gave Michael Hitch has proved to be quite functional, and should be released in the next kernel (provided Michael is ready). With his ability to wrap a driver around my code, we should be able to have IDE support in the kernel shortly! Mr. Hopps.. how about a compromise.. if you won't do an AGA driver, how about letting us be able to use Productivity mode of the ECS chipset? Way cool! -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 11 20:34:08 1994 From: William E Costello/Focal Point Software To: amiga@sun-lamp.cs.berkeley.edu Subject: BFFS 1.3 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Help!!!!, I just Downloaded the new version of BFFS, and about the only thing it did for me was hang my system. I tried it using the mount command, and about 3 seconds after you hit return, the system locks. No guru, just a hang of the system. Has anyone else run into this? I have an A3000, with 16meg, and two 200 meg external drives. Any help is much appreciated. William E. Costello bill@neosoft.com From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 12 06:35:41 1994 From: ozzy@catt.ncsu.edu (Chris Mattingly) Posted-Date: Sat, 12 Feb 1994 01:27:45 -0400 (EDT) Subject: problem To: amiga@sun-lamp.cs.berkeley.edu (netbsd) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 781 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I finally got bin-usrbin and bin-execlib from funet, and now I am having promblems running a lot of the stuff that can in the usrbin dist... After setting it up so that it could find ld.so (partition problem :-), I get giddy and type 'w' just for it to spew back the error: trapsignal(x, 8, 2, 0, 200x0d2) Floating point exception A lot of the binaries give me this, with the values for x changing... Any and all help appreciated. Thanks. -- Chris Mattingly | No nifty sig yet ... creativity is still on vacation. 414-C Wood Hall | PO Box 21553 | Home computer: A3000 - crazytrain.catt.ncsu.edu NCSU | 030/2Chip/4Fast/Math-Co Raleigh, NC 27607 | Email: Chris_Mattingly@ncsu.edu OR (919) 512-3230 | cmatting@nyx.cs.du.edu From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 12 16:04:35 1994 From: Kimmo T Paasiala Subject: Lockups under heavy disk access To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 369 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Symptoms: When I'm doing something that causes heavy disk traffic (for example compiling something) sometimes the system hangs with the disk light staying on. My system: A2000 equipped with A2630(4 Megs) + GVP Series II HD-controller + Rodime RO3259TS (200 Megs) I'm using the newest kernel(#744). Any suggestions ? -- Kimmo Paasiala (Kimmo.Paasiala@Helsinki.fi From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 12 18:06:22 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Length: 1343 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Lockups under heavy disk access Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi Kimmo (Kimmo T Paasiala), in <199402121450.QAA29864@klaava.Helsinki.FI> on Feb 12 you wrote: >Symptoms: When I'm doing something that causes heavy disk traffic >(for example compiling something) sometimes the system hangs with >the disk light staying on. > >My system: A2000 equipped with A2630(4 Megs) + GVP Series II HD-controller > + Rodime RO3259TS (200 Megs) >I'm using the newest kernel(#744). I have these problems with my tape drive, both under NetBSD and AmigaDOS. The problem is due to noise in my lines. I never managed to fix the problem. The external cable is three feet long and shielded, both internal and external devices are properly terminated at the end. As far as I can see I didn't break any rules, but I still have problems. Part of the reason is my 040 accelerator which puts a higher load on my SCSI bus (since it can access the controller faster). I have an Amiga 500 with GVP controller. My fix for this is to boot NetBSD with 16 bit memory which slows my 040 down enough so that I can do backups at least. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@cs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE_Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 12 19:05:04 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: 5380 SCSI support added! Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 10, 11:53pm, "William J. Coldwell" wrote: > Well, I have an A1200 with a CSA Twelve Gauge that comes up running NetBSD. > The code that I gave Michael Hitch has proved to be quite functional, and > should be released in the next kernel (provided Michael is ready). With his I'm not sure you would recognize much of your code in the driver. It's a conglomeration of the 33C93 scsi.c structure, and the 5380-specific code is kind of a mix of the Macintosh 5380 driver, Bill's code, and my own knowledge of the 5380. The driver is just a very minimal implementation that works. It needs some more work before being ready for public consumption (unless someone really wants to see it). I plan on adding support psuedo-DMA for data transfers (at least for my board and the CSA Twelve Gauge). I've also got a Supra Word Sync controller that I want to add support for. From looking at the Supra driver I have, it looks like the driver supports 5 different implementations of Supra boards. I haven't figured out if I can do a single Supra driver to handle all boards, or if I will need to create several different driver entries. What now constitutes a "next kernel"? Any changes I pass on to Chris Hopps will be merged into the sun-lamp current tree, so will be included in any kernels created from that tree. Is Markus or someone going to be creating kernels from the sun-lamp tree and making them available? > ability to wrap a driver around my code, we should be able to have IDE > support in the kernel shortly! Don't expect as quick a response on an IDE driver as I was able to do with the 5380 driver. I have a homebuilt 5380 board to test with, and several years of experience working on the driver for that board, so it was quite easy to get the 5380 driver working. I don't have much experience with programming an IDE driver (I did try to do that on my A1000 scsi board, but wasn't very sucessful getting it to work right). I also don't have an A1200 or A4000 to test a driver with [unless someone is willing to loan or donate such a machine :-)], so trying to test out the driver would probably be a longer process. Another thing I was just thinking about in regards to an IDE driver is how best to fit it into the NetBSD device configuration. I can think of two approaches: one being a separate disk driver with a separate major device number (similar to my now-defunct rzdriver I did for the initial PPI Zeus SCSI), and the other being a driver that simulates a SCSI driver. The first approach is probably easier to implement, but would require creating a different set of devices (or it could completely replace the sddriver code and use the same major number as the scsi disks - but that would not allow use of SCSI controllers). The second approach would be more work since the driver would have to emulate the SCSI commands, but it would allow a more consistent usage of the disk devices. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 12 19:07:46 1994 From: mw@eunet.ch Subject: Re: 5380 SCSI support added! To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1878 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > What now constitutes a "next kernel"? Any changes I pass on to Chris > Hopps will be merged into the sun-lamp current tree, so will be included > in any kernels created from that tree. Is Markus or someone going to be > creating kernels from the sun-lamp tree and making them available? I took a dump of our sunlamp mirror Friday, and am already running a "current" kernel. Now, gcc 2.5.8 is compiling, and if all goes well (shared libraries seem to have changed a bit) I'll have a new bin-dist soon. Including a kernel binary, of course, for those that hate to compile their kernels themselves. > Another thing I was just thinking about in regards to an IDE driver is > how best to fit it into the NetBSD device configuration. I can think of > two approaches: one being a separate disk driver with a separate major > device number (similar to my now-defunct rzdriver I did for the initial > PPI Zeus SCSI), and the other being a driver that simulates a SCSI > driver. The first approach is probably easier to implement, but would > require creating a different set of devices (or it could completely > replace the sddriver code and use the same major number as the scsi > disks - but that would not allow use of SCSI controllers). The second > approach would be more work since the driver would have to emulate the > SCSI commands, but it would allow a more consistent usage of the disk > devices. Hm.. I know ADos chose the second approach, confusing all those 1200 users into thinking they DID have a scsi controller nevertheless.. I'd say, if you CAN fit it into the scsi driver neatly, it would probably be a neat thing, however, all the other *ix's I know have a separate driver for this. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 12 19:14:51 1994 From: mw@eunet.ch Subject: Re: Lockups under heavy disk access To: sgberg@charon.bloomington.in.us Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 910 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > I have these problems with my tape drive, both under NetBSD and > AmigaDOS. The problem is due to noise in my lines. I never managed > to fix the problem. The external cable is three feet long and > shielded, both internal and external devices are properly terminated > at the end. As far as I can see I didn't break any rules, but I still > have problems. Part of the reason is my 040 accelerator which puts a > higher load on my SCSI bus (since it can access the controller > faster). If it's a noisy SCSI bus, you could try to fix the problem by using an active terminator, instead of the common passive one. Slightly more expensive, but could possibly help your system. I hope you don't run with synchronous xfer on that system... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Feb 12 19:36:34 1994 Subject: How best to keep up with development? From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu What's the best way for me to maintain my BSD system to my satisfaction given the current software distribution scheme? Details: - Berkeley and University of Toronto are both directly connected to NSFNet. That means that FTP to/from sun-lamp is DAMN fast, and a lot less stressful on the net than FTP to eunet.ch. If the Amiga kernel source is mirrored reasonably well (i.e. no more than 1 or 2 day slop) then the Net Gods would much prefer that I sponge from sun-lamp. If I am interested in getting Amiga-specific stuff (such as the latest Amiga X server), would I be better off going to eunet? I am assuming that no more releases of bsdsyssrc.xxx.tar.gz will be forthcoming. - Is there an easy way for me to find out what's changed with each kernel source update? For example, a release that fixes a few '040 bugs is not worth my time building, although it will be for other people. I'd rather not build something that gives me less functionality (such as .744 - I use .730 for development since I can use GDB with it). I don't have the disk space to maintain a complete (kernel/bin/usrbin) source tree. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Feb 12 20:08:26 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Problems compiling sun-lamp sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I've just finished grabbing the 6 Feb sources from sun-lamp. I've replaced my /usr/include files with the ones from these sources and when I try to compile the libraries with gcc-2.5.8 I keep getting the following types of errors: ===> c++ cc -O -DLIBC_SCCS -fpic -c c++rt0.c ld: internal error:wrong number of symbols (7) written into output file, should be 5 c++rt0.o.___dtors c++rt0.o._initialized.6 Does anyone have a fix for these? (Before I start digging...:-( ) -SR From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 12 22:54:34 1994 From: leland@wacky.acet.org (Robert Leland - PSI) To: sjr@zombie.ncsc.mil Subject: Re: Problems compiling sun-lamp sources Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu Last time I heard g++ didn't get along with shared libraries. Weather it was the linker, which I believe is the case and also the debugger I am not sure. maybe linking -static would fix your problem. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Feb 12 22:56:07 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Problems compiling sun-lamp sources To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 810 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > I've just finished grabbing the 6 Feb sources from sun-lamp. I've > replaced my /usr/include files with the ones from these sources > and when I try to compile the libraries with gcc-2.5.8 I keep > getting the following types of errors: > > ===> c++ > cc -O -DLIBC_SCCS -fpic -c c++rt0.c > ld: internal error:wrong number of symbols (7) > written into output file, should be 5 > c++rt0.o.___dtors > c++rt0.o._initialized.6 > > Does anyone have a fix for these? (Before I start digging...:-( ) You must have missed my message, don't use the 2.5.8 I released to ftp.eunet.ch! Very bad things could result. Markus will be releaseing a version in a few days, I personnally use the 245 that comes with the distribution as it needs to be tested and doesn't eed to be fixed. > > -SR Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 00:04:43 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: How best to keep up with development? To: dej@eecg.toronto.edu (David Jones) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 984 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > - Is there an easy way for me to find out what's changed with each > kernel source update? For example, a release that fixes a few '040 > bugs is not worth my time building, although it will be for other > people. I'd rather not build something that gives me less functionality > (such as .744 - I use .730 for development since I can use GDB with it). Subscribe to source-changes@sun-lamp.cs.berkeley.edu, Every time a cvs commit is done you will get a small message about it with the note from the developer. If you are not interested in common stuff, then setup a filter and anything that doesn't have amiga in the sbuject line you toss. > I don't have the disk space to maintain a complete (kernel/bin/usrbin) > source tree. Use sup to bring the stuff to your local univ. then whatever to get it to your house. You can even setup a private sup database for yourself. > David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Feb 13 01:13:15 1994 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: 5380 SCSI support added! Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <199402121800.TAA09464@eunet.ch> mw@eunet.ch writes: > Hm.. I know ADos chose the second approach, confusing all those 1200 users > into thinking they DID have a scsi controller nevertheless.. I'd say, if > you CAN fit it into the scsi driver neatly, it would probably be a neat thing, > however, all the other *ix's I know have a separate driver for this. ...including NetBSD/i386. They have seperate sd (scsi) and wd (MFM/RLL/ESDI/IDE) drivers. Also, I think NetBSD/hp300 has a hd (HPIB-interfaced) driver :-) -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga@sun-lamp.cs.berkeley.edu Sun Feb 13 01:42:15 1994 From: Olaf Seibert To: NetBSD-amiga@cbmuucp.commodore.com, tsarna@endicor.com Subject: Re: 5380 SCSI support added! Sender: owner-amiga@sun-lamp.cs.berkeley.edu > ...including NetBSD/i386. They have seperate sd (scsi) and wd > (MFM/RLL/ESDI/IDE) drivers. Also, I think NetBSD/hp300 has a hd > (HPIB-interfaced) driver :-) If we copy that, we can finally connect our 2040 disks to our BSD machines! :-) -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ I can bicycle on both sides of the road - rhialto@mbfys.kun.nl From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 04:44:56 1994 From: luebberw@lp.musc.edu To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Building sun-lamp sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Well, I was successful in building a kernel from the files at sun-lamp but, alas, it doesn't even give me the initial greeting. I used gcc 2.5.8, which is what I used for bsdsyssrc744 and it worked wonderfully. What was the reason that 2.5.8 does not work building a kernel? Mine worked just fine on 744. Anyway, in sys/arch/amiga/conf/files.amiga, aren't there a bunch of files missing? What happened to all the *.s files in sys/lib/libkern/m68k? Why is fpsp in m68k and not in amiga? Just wondering...:) R. Luebbert From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 05:32:36 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: How best to keep up with development? Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9402122141.AA09957@emunix.emich.edu> chopps@emunix.emich.edu (Chris Hopps) writes: > > - Is there an easy way for me to find out what's changed with each > > kernel source update? For example, a release that fixes a few '040 > > Subscribe to source-changes@sun-lamp.cs.berkeley.edu, Every time a > cvs commit is done you will get a small message about it with the note > from the developer. If you are not interested in common stuff, then > setup a filter and anything that doesn't have amiga in the sbuject > line you toss. source-changes can be massive information overload without filtering, and many people are not in a position to filter mail easily. Other might like to recieve one condensed report instead of many many tiny messages. For this reason, I've hacked up a little script to monitor source-changes and post a digest of each weeks's amiga and generic-m68k changes to the amiga list once a week. I'll start it next friday, if there are no objections. (I still think noting amiga-specific changes in doc/CHANGES or arch/amiga/doc/CHANGES would also be a good idea, though). -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 06:53:15 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: How best to keep up with development? To: tsarna@endicor.com (Ty Sarna) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 962 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > source-changes can be massive information overload without filtering, > and many people are not in a position to filter mail easily. Other > might like to recieve one condensed report instead of many many tiny > messages. For this reason, I've hacked up a little script to monitor > source-changes and post a digest of each weeks's amiga and generic-m68k > changes to the amiga list once a week. I'll start it next friday, if > there are no objections. Objections? No way, thanks alot. This will help people that ar not setup to filter the list (or even handle the raw input.) > (I still think noting amiga-specific changes in doc/CHANGES or > arch/amiga/doc/CHANGES would also be a good idea, though). I will start using a arch/amiga/doc/CHANGES file. good idea (I didn't want to make notes specific to the AMIGA like ("massive cleanup" in the general CHANGES FILE) > Ty Sarna "As you know, Joel, children have always looked Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 07:50:59 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Building sun-lamp sources To: luebberw@lp.musc.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1221 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > Well, I was successful in building a kernel from the files at sun-lamp > but, alas, it doesn't even give me the initial greeting. My first guess is that you have not yet gotten the loadbsd-current.gz from ftp.eunet.ch which is required (and from now on checks the kernel boot verion number so that this doesn't happen anymore) My second guess would be that the times on your files are screwed up. Try rmoeveing *all* objects and build a new kernel. > > I used gcc 2.5.8, which is what I used for bsdsyssrc744 and it worked > wonderfully. What was the reason that 2.5.8 does not work building a kernel? > Mine worked just fine on 744. Try the first 2 I think one of those will fix things. > > Anyway, in sys/arch/amiga/conf/files.amiga, aren't there a bunch > of files missing? What happened to all the *.s files in sys/lib/libkern/m68k? > Why is fpsp in m68k and not in amiga? There aren't any files missing you need the new config to correctly fetch things for you like it needs to scan arch/m68k/conf/file.m68k. the config on sun-lamp should build out of the box for you. *remeber* link static since you choose to use 2.5.8 Becuase fpsp is code for Moto 040's not amigas. > R. Luebbert Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 09:39:15 1994 From: Tim Newsham Subject: sup, downloading new code, etc.. To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I just setup 'sup' on this sun (my net access point) and got it to work to sup the 'ksrc-common' and 'ksrc-amiga' distributions. I was wondering if anyone has some good tips on this. I dont have networking setup between my home and my net access. I will be sup'ing files periodically to this sun system and trying to download the code and building new kernels at home. What is a good way to do this? I would like to only download those files that are newly sup'ed each time (I realize this is what sup itself does but unfortunately I cant network and run sup from home because I have but a 2400 baud modem). Does anyone have any pointers/tips on this? Thanx... Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 12:11:04 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sup, downloading new code, etc.. To: newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 839 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > Hi, > I just setup 'sup' on this sun (my net access point) and got it > to work to sup the 'ksrc-common' and 'ksrc-amiga' distributions. I > was wondering if anyone has some good tips on this. I dont have > networking setup between my home and my net access. I will be sup'ing > files periodically to this sun system and trying to download the > code and building new kernels at home. What is a good way to do > this? I would like to only download those files that are newly > sup'ed each time (I realize this is what sup itself does but > unfortunately I cant network and run sup from home because I have > but a 2400 baud modem). Does anyone have any pointers/tips on > this? Thanx... Hmm, either a shell script that judicously uses "find" or maybe a perl script. > Tim N. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 18:47:33 1994 From: chammer@HRZ.Uni-Bielefeld.DE Subject: How to build shared libs? To: chopps@emunix.emich.edu (Chris Hopps) (Chris Hopps) Cc: newsham@uhunix.uhcc.Hawaii.Edu, amiga-dev@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I just wonder how i can build shared libs with ar. I would like to build a shared tiff,tk,tcl, etc. library. Where can I get a manpage explaining that and where can i get a ar doing it? Is there something bad in changing the -O in /usr/share/mk/sys.mk to -O2 -m68030 -m68881 ? ciao Carsten -- Carsten Hammer Schwindstr. 7 33615 Bielefeld Fakultaet fuer Physik D4-139 chammer@POST.uni-bielefeld.de From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Feb 13 19:02:30 1994 From: chammer@HRZ.Uni-Bielefeld.DE Subject: 2024 works with 640x800, can i get more? To: sbusko@cap.gwu.edu Cc: amiga-x@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Hi, Is there a way to binpatching the 730er kernel to do 1024x1024 or 1024x800? I did get 640x800 working by binpatching _ite_default_height to 800 but 1024x1024 and 1024x800 doesnt work for me that way... I even tried 1008 and _ite_default_depth 1=> i only get rubbish on my monitor when i try. thanks, Carsten -- Carsten Hammer Schwindstr. 7 33615 Bielefeld Fakultaet fuer Physik D4-139 chammer@POST.uni-bielefeld.de From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Feb 13 19:16:10 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: 2024 works with 640x800, can i get more? To: chammer@HRZ.Uni-Bielefeld.DE Cc: sbusko@cap.gwu.edu, amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 745 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > Hi, > Is there a way to binpatching the 730er kernel to do 1024x1024 or 1024x800? > I did get 640x800 working by binpatching _ite_default_height to 800 but > 1024x1024 and 1024x800 doesnt work for me that way... > I even tried 1008 and _ite_default_depth 1=> i only get rubbish on my > monitor when i try. It doesn't support 1008. You need to either get sources from sun lamp and compile a new kernel or wait for markus to release a new kernel (which should not be too long from now.) The 2024 modes where cleaned up and made functional after 744. However I never got 1024x1024 to work to my satisfaction and I would not recommend binpatching it to boot into 1024x1024. My kernel boots into 1024x800x1. > thanks, > Carsten Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 19:20:27 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: How to build shared libs? To: chammer@HRZ.Uni-Bielefeld.DE Cc: chopps@emunix.emich.edu, newsham@uhunix.uhcc.Hawaii.Edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 744 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Hi, > I just wonder how i can build shared libs with ar. I would like to > build a shared tiff,tk,tcl, etc. library. Where can I get a manpage > explaining that and where can i get a ar doing it? > Is there something bad in changing the -O in /usr/share/mk/sys.mk to -O2 > -m68030 -m68881 ? I don't know about the 68030 thats untested. I compile with -O2 though. As far as shared libs go, have you looked at the berkely make system? It makes things fairly simple. If your /usr/share/mk files are up to date you should be able to construct a file as so (see below) and it will build static, static profiled and shared versions of "mylib". --- LIB= mylib SRCS=a.c b.c c.c d.c e.c .include --- > ciao > Carsten Chris. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Feb 13 19:46:29 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: 2024 works with 640x800, can i get more?" (Feb 13, 1:08pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chopps@emunix.emich.edu (Chris Hopps), chammer@HRZ.Uni-Bielefeld.DE Subject: Re: 2024 works with 640x800, can i get more? Cc: sbusko@cap.gwu.edu, amiga-x@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Feb 13, 1:08pm, Chris Hopps wrote: > It doesn't support 1008. You need to either get sources from sun lamp > and compile a new kernel or wait for markus to release a new kernel > (which should not be too long from now.) The 2024 modes where cleaned > up and made functional after 744. However I never got 1024x1024 to > work to my satisfaction and I would not recommend binpatching it to > boot into 1024x1024. My kernel boots into 1024x800x1. Hm. I never used binpatch to alter the size of my screen, iteconfig works fine for me. My A2024 runs with 1024x1024x1 just fine, even with X. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 19:49:04 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Building sun-lamp sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 12, 11:46pm, Chris Hopps wrote: > > Anyway, in sys/arch/amiga/conf/files.amiga, aren't there a bunch > > of files missing? What happened to all the *.s files in sys/lib/libkern/m68k? > > Why is fpsp in m68k and not in amiga? > > There aren't any files missing you need the new config to correctly > fetch things for you like it needs to scan arch/m68k/conf/file.m68k. > the config on sun-lamp should build out of the box for you. *remeber* > link static since you choose to use 2.5.8 The sys/lib/libkern also expects to find stuff in lib/libc.. - most of the *.S files are found in lib/libc/arch/m68k/*. Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 20:25:06 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: param.h include file problem Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu The "machine/param.h" include file (from sun-lamp 12 Feb) has some problems. There is a "cpu040" variable that does not appear to be defined anywhere. The problem is two-fold: 1. Should cpu.h be included into param.h? 2. What about the "KERNEL" define that protects cpu040 from being defined? This problem shows up when trying to compile the libkvm files. -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 21:19:39 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: param.h include file problem To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 870 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > The "machine/param.h" include file (from sun-lamp 12 Feb) has > some problems. There is a "cpu040" variable that does not > appear to be defined anywhere. The problem is two-fold: > > 1. Should cpu.h be included into param.h? > > 2. What about the "KERNEL" define that protects cpu040 from > being defined? > > This problem shows up when trying to compile the libkvm files. I am aware of this, hopefully I will have the fix in libkvm today. The amiga 040 stuff currently uses a difference Sysseg table and cpu040 is a part of the SEGSHIFT define. libkvm is trying (when looking at a dead kernel) to use SEGSHIFT, and thus references cpu040. The solution (for the present) is to modify libkvm to fetch the cpu040 variable from the dead kernel also. The long term fix is to change the VM system to operate the same under 030's and 040's. > -SR Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 13 22:32:30 1994 From: mw@eunet.ch Subject: Re: How to build shared libs? To: chammer@HRZ.Uni-Bielefeld.DE Cc: chopps@emunix.emich.edu, newsham@uhunix.uhcc.Hawaii.Edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 970 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I just wonder how i can build shared libs with ar. I would like to > build a shared tiff,tk,tcl, etc. library. Where can I get a manpage > explaining that and where can i get a ar doing it? It's not ar, it's ld that creates shared libraries. Check out /usr/share/mk/bsd.lib.mk if you'd like to see how the system libraries are built. > Is there something bad in changing the -O in /usr/share/mk/sys.mk to -O2 > -m68030 -m68881 ? Hm.. slightly dangerous to make this the default, as -O2 will imply -fomit-frame-pointer, which is a somewhat tricky option to have enabled all the time... -m68881 is already the default, and I'd not advise using -mc68030, as it won't give you any additional bonus over the default of -mc68020, but it just might cause gcc to pass the wrong flags to the assembler... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Feb 14 00:44:49 1994 From: DCG9367@tntech.edu Subject: Problems with Retina-X To: amiga-x@sun-lamp.cs.berkeley.edu X-Vms-To: IN%"amiga-x@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I recently got X up and running on my 2000/Gforce-040/4mb-32bit/Retina. I am having two major problems though. 1) I can't seem to get any screen mode other than 640x480 to work right. I changed the Xconfig to several different 8-bit monitor defs that I am using in AmigaDos, but only the 640x480 is stable. The others lose vertical hold and flip around. 2) I always get a blotch of random data in the upper left corner of the screen. It seems to be about 32x120 pixels. Does anyone know what the problem is? Could it be a bad ram chip? I don't see anything wrond in AmigaDos, although I do get strange things when I use XiPaint, especially when my 32-bit memory is running low. One other problem not related to X, but might as well ask, why does NetBSD refuse to work right in my 6MB 16bit ram? It boots to single user mode fine, but as soon as I do a command like "ps" or "df" or anything else, I get a "single user shell terminating" and a screenful of trapsignals. I remeber a while back, someone said that there are problems with the GForce 040, NetBSD, and 16-bit ram. One more question: Does anyone have the "reserved" jumper connections for the GForce-040 and the memory config jumper settings for GVP's 8mb board for the 2000? I have 4 1-mb simms to install and can't get the jumper settings right (I lost the manual:( ) Thanks, David. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 01:07:38 1994 From: niklas@appli.se (Niklas Hallqvist) To: newsham@uhunix.uhcc.Hawaii.Edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sup, downloading new code, etc.. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, everybody, I'm back from the sun (Gran Canaria for one week) and have just read through my mailbox (~300 mail-messages in one week!!!!). I've seen people ask for the ADOSFS, and I'll try to put together a package this week, really!!! It'll be GPL'd and readonly though, as I've done nothing new for the last couple of months. >>>>> "Tim" == Tim Newsham writes: Tim> Hi, I just setup 'sup' on this sun (my net access point) and got Tim> it to work to sup the 'ksrc-common' and 'ksrc-amiga' Tim> distributions. I was wondering if anyone has some good tips on Tim> this. I dont have networking setup between my home and my net Tim> access. I will be sup'ing files periodically to this sun system Tim> and trying to download the code and building new kernels at home. Tim> What is a good way to do this? I would like to only download Tim> those files that are newly sup'ed each time (I realize this is Tim> what sup itself does but unfortunately I cant network and run sup Tim> from home because I have but a 2400 baud modem). Does anyone Tim> have any pointers/tips on this? Thanx... Tim N. I compiled sup for NetBSD-amiga today and did a: tredir 871 sun-lamp.cs.berkeley.edu:871 and sup works almost good over term, the only problem I've had seems to be term-related, dropping connections unnecessarily, although I can't say it for sure. As term will work allright over a 2400 line you can always go that way. Good luck! Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 21:35:47 1994 Subject: Re: ADOSFS and GPL To: amiga-dev@sun-lamp.cs.berkeley.edu From: Frank "Crash" Edwards Organization: Edwards & Edwards Consulting, Palm Harbor, FL X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1389 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Niklas Hallqvist sayeth: >I've >seen people ask for the ADOSFS, and I'll try to put together a package >this week, really!!! It'll be GPL'd and readonly though, as I've done >nothing new for the last couple of months. Well, I've got a question. This has come up before, but I never understood the rationale. Last time, I was told "NetBSD can't have GPL'd code" but nobody said why. I'd like to know why. It seems to me that the GPL guarantees that source code will always be available. If NetBSD has this same philosphy, what's the problem? If it doesn't, why not? [Perhaps someone could post the NetBSD version of the GPL? Then I could compare them myself...] >Niklas Hallqvist Phone: +46-(0)31-40 75 00 Sorry to bring this up again. Please take it offline (ie, email) if you think there's little or no interest in the rest of this group. Heck, if I knew that the NetBSD wasn't going to restrict the code somewhere down the line, maybe I'd finish the read/write stuff myself? I've been thinking about trying out NetBSD... ;-) PS: I'm going out of town for a few days, but I'll make one last check in my mailbox before I leave (Tuesday afternoon). Thanks! -- Frank "Crash" Edwards Edwards & Edwards Consulting Voice: 813/786-3675 Unix/AIX & OS/2: Training, Programming, and SysAdmin Data/Fax: 813/787-3675 crash@azhrei.EEC.COM; inquiries to info@azhrei.EEC.COM From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 22:12:18 1994 From: Tim Newsham Subject: graphics To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Does anyone have example code of how to do graphics under Amiga-NetBSD going through the device files in /dev? I would like to do some simple graphics plotting without running X, I dont mind working at a low level (w/ bitmaps). Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 22:24:35 1994 From: rhealey@aggregate.com Subject: Audio and Floppy drivers To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 184 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Anybody get anywhere with audio or floppy drivers? I saw the graphics cc_audio.c device code had some audio support but no apparent way to get at it outside of the kernel. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 22:47:32 1994 From: mw@eunet.ch Subject: Re: ADOSFS and GPL To: crash@azhrei.eec.com (Frank "Crash" Edwards) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 4147 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Well, I've got a question. This has come up before, but I never > understood the rationale. Last time, I was told "NetBSD can't have > GPL'd code" but nobody said why. > > I'd like to know why. It seems to me that the GPL guarantees that > source code will always be available. If NetBSD has this same > philosphy, what's the problem? If it doesn't, why not? [Perhaps > someone could post the NetBSD version of the GPL? Then I could > compare them myself...] Here's an example copyright header (sys/kern/tty.c): /*- * Copyright (c) 1982, 1986, 1990 The Regents of the University of California. * Copyright (c) 1991 The Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * So, the most important difference is that you can do "almost anything" with the source as long as you give proper credit. Under GPL, you're *forced* to disclose any sources you develop based on GPL sources, if you'd like to distribute your product, possibly SELL your product. Introducing just one GPL source into the kernel would *force* you to distribute source to anything you develop on the kernel, even if you just plain include and don't change that GPL source. The BSD sources have a very liberal copyright, and I don't want to restrict them all of a sudden to GPL conditions. Things look slightly different when talking about applications to go into the system. They're closed "objects" by themselves. Using for example gcc as the system compilier doesn't force you to also distribute sources for your commercial application FOOBAR you'd like to distribute with the system. > Heck, if I knew that the NetBSD wasn't going to restrict the code > somewhere down the line, maybe I'd finish the read/write stuff > myself? I've been thinking about trying out NetBSD... ;-) Grin, give it a try! There could EVEN be an alternate solution to this problem! NetBSD knows about loadable kernel modules (LKM). Implementing this filesystem as an LKM file system, there wouldn't be a fixed link between the kernel and the object files. Both, the kernel and the object files of the filesystem would be distributable seperately. That way, I think, the filesystem code could remain GPLd without making the kernel itself GPL. Well, I'm no laywer... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 23:20:56 1994 Subject: Re: ADOSFS and GPL From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > There could EVEN be an alternate solution to this problem! NetBSD knows > about loadable kernel modules (LKM). Implementing this filesystem as an LKM > file system, there wouldn't be a fixed link between the kernel and the > object files. Both, the kernel and the object files of the filesystem would > be distributable seperately. That way, I think, the filesystem code could > remain GPLd without making the kernel itself GPL. Well, I'm no laywer... Although no precedent has been set, the FSF takes a dim view of anyone using techniques such as this to "work around" the GPL. The FSF considers pretty well ALL dynamic link libraries to be equivalent to statically linked libs. This means that using a dynamic loading technique does not exempt you from the GPL requirements. And LKM is, after all, a sort of dynamic loader. Consider this: If I write a library libgpled.a, then does it make sense to have a statically linked foo forced under the GPL and to have a dynamically linked foo (a separate binary) not under the GPL? The best advice I can give is to ask someone at the FSF, by email, about what you plan to do. Be specific. The FSF will not "rule" on general cases, nor will they rule on gnu.misc.discuss. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 23:41:13 1994 From: rhealey@aggregate.com Subject: Re: ADOSFS and GPL To: dej@eecg.toronto.edu (David Jones) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1079 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > The best advice I can give is to ask someone at the FSF, by email, about > what you plan to do. Be specific. The FSF will not "rule" on general > cases, nor will they rule on gnu.misc.discuss. > Or skip GPL altogether and just release the code as BSD type license. WHY go through all the bother to make sure it's given the FSF brand of approval/blessing? What a pain... Frank was the author of the SVR4 AMIX read-only driver. He chose to release the AMIX driver GPL. If he loads up NetBSD he has the option to release a NetBSD version non GPL'd, which I hope he does. The other individual did alot of work to adapt SVR4 VFS code to NetBSD's VFS. If he and Frank get together we could possibly have a non-GPL'd ADOS filesystem driver that could be put in to the main sun-lamp tree. Frank did ALOT of hard work in writing the original AMIX driver, the other gentleman did alot of hard work converting it to NetBSD. Hopefully both can be convinced that a BSD license and accolades from their Amiga peers/fans will be enough for all their hard work. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 23:45:38 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Audio and Floppy drivers" (Feb 14, 3:17pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: rhealey@aggregate.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Audio and Floppy drivers Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 14, 3:17pm, rhealey@aggregate.com wrote: > Subject: Audio and Floppy drivers > > Anybody get anywhere with audio or floppy drivers? I saw the > graphics cc_audio.c device code had some audio support but no > apparent way to get at it outside of the kernel. Well well :-) I have looked at the audio device, but i wasn't sure where to start. Get the files bsd_audio.c bsd_audioreg.h bsd_audiovar.h from sun-lamp in the sparc/dev archive, also get sox to look at the ulaw-to-8-bit-converter. Just one problem: Amiga has 8Bit Sound, Sparc has 14Bit ... -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 00:38:47 1994 From: hooper@gdls.com (Chris Hooper) To: amiga-dev@sun-lamp.cs.berkeley.edu, dej@eecg.toronto.edu Subject: Re: ADOSFS and GPL Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 14 18:15:17 1994 Return-Path: Received: from gdls.com by vangogh (4.1/SMI-4.1) id AA28850; Mon, 14 Feb 94 18:15:15 EST Received: from sun-lamp.cs.berkeley.edu (sun-lamp.CS.Berkeley.EDU [128.32.138.88]) by gdls.com (8.6.4/8.6.4) with ESMTP id SAA04186 for ; Mon, 14 Feb 1994 18:15:14 -0500 Received: from localhost (mailman@localhost) by sun-lamp.cs.berkeley.edu (8.6.5/8.6.5) id OAA18462 for amiga-dev-outgoing; Mon, 14 Feb 1994 14:01:10 -0800 Received: from picton.eecg.toronto.edu (picton.eecg.toronto.edu [128.100.10.141]) by sun-lamp.cs.berkeley.edu (8.6.5/8.6.5) with SMTP id OAA18448 for ; Mon, 14 Feb 1994 14:01:00 -0800 Received: by picton.eecg.toronto.edu id <19050>; Mon, 14 Feb 1994 17:05:07 -0500 Subject: Re: ADOSFS and GPL From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu Date: Mon, 14 Feb 1994 17:04:55 -0500 In-Reply-To: <199402142135.WAA15556@eunet.ch>; from "mw@eunet.ch" at Feb 14, 94 4:35 pm X-Mailer: ELM [version 2.3 PL11] Message-Id: <94Feb14.170507est.19050@picton.eecg.toronto.edu> Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Precedence: bulk Status: R >> object files. Both, the kernel and the object files of the filesystem would >> be distributable seperately. That way, I think, the filesystem code could ~~~~~~~~~~~ >> remain GPLd without making the kernel itself GPL. Well, I'm no laywer... > >Although no precedent has been set, the FSF takes a dim view of anyone using >techniques such as this to "work around" the GPL. The FSF considers pretty >well ALL dynamic link libraries to be equivalent to statically linked libs. > >This means that using a dynamic loading technique does not exempt you from >the GPL requirements. And LKM is, after all, a sort of dynamic loader. I think you're missing the point that Markus made. If you write a driver and distribute it separately from the base NetBSD distribution, there's no way it could be called "part" of NetBSD. Otherwise, what would stop me from taking it a step further... ie: I write an application with totally bogus copyright restrictions. It happens to run under SunOS. *Poof* Suddenly all distributions of SunOS are bound by my copyright because my program runs under SunOS? I don't think so. :) - Chris Hooper Computer Sciences Corporation - System Support Engineer at hooper@gdls.com General Dynamics [Sterling Heights, MI] (810) 825-5061 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 00:56:35 1994 From: mw@eunet.ch Subject: Re: ADOSFS and GPL To: dej@eecg.toronto.edu (David Jones) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2530 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Although no precedent has been set, the FSF takes a dim view of anyone using > techniques such as this to "work around" the GPL. The FSF considers pretty > well ALL dynamic link libraries to be equivalent to statically linked libs. Sorry, but in that case I'll have to read their COPYRIGHT file, and I can't find that in our specific case of LKMs they'd have any right to reserve GPL upon the kernel, just because someone had the idea of creating a completely independant set of object files, linking them together (forming a GPLd binary) and then - what an outrageous idea - to specifying them as argument to modload. The way I understand it: the BSD kernel by itself is a standalone product, it doesn't need any specific LKM modules to be operating, nor will it ever be distributed TOGETHER with such (GPLd) LKMs. Distributing a separate thing, that just happens to work with this kernel, can't by all means change the copyright status of that independant object!? Not even with US laws :-) > This means that using a dynamic loading technique does not exempt you from > the GPL requirements. And LKM is, after all, a sort of dynamic loader. Yes and no.. dynamic loaders impose a stricter binding between the dynamic library and the application. Furthermore, you can't usually run applications linked dynamically without those dynamic libraries. You CAN run the kernel without any LKMs just fine. > Consider this: If I write a library libgpled.a, then does it make sense to > have a statically linked foo forced under the GPL and to have a dynamically > linked foo (a separate binary) not under the GPL? We get a bit down to hairy details here.. I'd say, a SunOS/BSD style dynamic library would still be GPLd, an AmigaDOS shared library wouldn't. BTW: that's exactly the reason I made ixemul.library a) shared, b) put it under GPL. I explicitly explained in the docs that this does NOT cause any programs using it to be GPLd, since I declared the glue-functions PD. There are no glue functions needed for LKMs. > The best advice I can give is to ask someone at the FSF, by email, about > what you plan to do. Be specific. The FSF will not "rule" on general > cases, nor will they rule on gnu.misc.discuss. Well, the GPL text is public, if it's not in there, it's irrelevant what anyone at FSF thinks about it. I think the case is pretty clear here. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 01:12:24 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: ADOSFS and GPL Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <94Feb14.170507est.19050@picton.eecg.toronto.edu> David Jones writes: > Although no precedent has been set, the FSF takes a dim view of anyone using > techniques such as this to "work around" the GPL. The FSF considers pretty > well ALL dynamic link libraries to be equivalent to statically linked libs. > > This means that using a dynamic loading technique does not exempt you from > the GPL requirements. And LKM is, after all, a sort of dynamic loader. By that logic, so is the kernel. I'm sure Sun/HP/DEC/etc will be rather upset when the find out FSF is claiming their kernels are GPLed, since folks have "dynamicly loaded" gcc into them. (assuming that you're correct and they do take this stance) > The best advice I can give is to ask someone at the FSF, by email, about > what you plan to do. Be specific. The FSF will not "rule" on general > cases, nor will they rule on gnu.misc.discuss. If this is actually true, it's more reason to avoid GPL code entirely. In practice, Berkeley-style licenses seem to really be much more free. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 01:35:58 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Audio and Floppy drivers To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1632 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Anybody get anywhere with audio or floppy drivers? I saw the > graphics cc_audio.c device code had some audio support but no > apparent way to get at it outside of the kernel. > > -Rob > I'm not sure about the audio drivers but I am working on a floppy driver. I have it kind of working (will read data most of the time) but its in pretty rough shape right now. I had asked mw (did you get my mail?) and ... (can't remember who else) for some floppy driver code someone else has done. I was hoping looking at someone elses code would help me see whats wrong with mine. No word back yet. The status of the driver right now is: - it will read (not write) tracks properly sometimes - it is just a character device for now - the millisecond delay code is a loop (ick!) I have code written for writing but am not worrying about it for now. Tracks are only read properly once out of every five or so tries (I think it is something to do with the sync not working). The driver is a character device now because I don't know netbsd well and it seemed easier than a block device. The millisecond timer could be done using one of the cia timers but I haven't bothered yet. +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 01:54:57 1994 Subject: Re: ADOSFS and GPL To: amiga-dev@sun-lamp.cs.berkeley.edu From: Frank "Crash" Edwards Organization: Edwards & Edwards Consulting, Palm Harbor, FL X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7004 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu mw@eunet.ch sayeth: >I said: >> Well, I've got a question. This has come up before, but I never >> understood the rationale. Last time, I was told "NetBSD can't have >> GPL'd code" but nobody said why. >> >> I'd like to know why. It seems to me that the GPL guarantees that >> source code will always be available. If NetBSD has this same >> philosphy, what's the problem? If it doesn't, why not? [Perhaps >> someone could post the NetBSD version of the GPL? Then I could >> compare them myself...] > >Here's an example copyright header (sys/kern/tty.c): >/*- > * Copyright (c) 1982, 1986, 1990 The Regents of the University of California. > * Copyright (c) 1991 The Regents of the University of California. > * All rights reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in the > * documentation and/or other materials provided with the distribution. > * 3. All advertising materials mentioning features or use of this software > * must display the following acknowledgement: > * This product includes software developed by the University of > * California, Berkeley and its contributors. > * 4. Neither the name of the University nor the names of its contributors > * may be used to endorse or promote products derived from this software > * without specific prior written permission. > * > [disclaimer of no warranty] > >So, the most important difference is that you can do "almost anything" with >the source as long as you give proper credit. Under GPL, you're *forced* >to disclose any sources you develop based on GPL sources, if you'd like >to distribute your product, possibly SELL your product. Introducing just >one GPL source into the kernel would *force* you to distribute source >to anything you develop on the kernel, even if you just plain include and >don't change that GPL source. The BSD sources have a very liberal copyright, >and I don't want to restrict them all of a sudden to GPL conditions. That's not how I read the GPL. Quoted from Section 2: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." The rest of the NetBSD kernel is most definately an "independent and separate work" since the AmigaDOS VFS is merely an add-on; an option. The rest of the kernel is not "part of a whole which is a work based on the Program" since the kernel is a self-contained program in it's own right and does not require nor even suggest the use of the ADOS VFS. "Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program." Exactly. "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." A little bit different from the first paragraph since this one is limited strictly to distribution media, but this certainly spells out that the kernel could not be considered covered by the GPL just because the ADOS VFS was. >Things look slightly different when talking about applications to go >into the system. They're closed "objects" by themselves. Using for example >gcc as the system compilier doesn't force you to also distribute sources >for your commercial application FOOBAR you'd like to distribute with >the system. Agreed. This has been discussed quite a bit in gnu.* groups. >> Heck, if I knew that the NetBSD wasn't going to restrict the code >> somewhere down the line, maybe I'd finish the read/write stuff >> myself? I've been thinking about trying out NetBSD... ;-) > >Grin, give it a try! Perhaps. How do I know that the source will be available tomorrow? I don't. (I'm not suggesting that anyone currently developing NetBSD would conspire to remove the source from the airwaves, merely that I could get "hooked" into an OS that started out "free" and then changes so that only binaries are available.) >There could EVEN be an alternate solution to this problem! NetBSD knows >about loadable kernel modules (LKM). Implementing this filesystem as an LKM >file system, there wouldn't be a fixed link between the kernel and the >object files. Both, the kernel and the object files of the filesystem would >be distributable seperately. That way, I think, the filesystem code could >remain GPLd without making the kernel itself GPL. Well, I'm no laywer... Yes, this looks feasible also. In fact, since this solves two problems at once, ie. the fear of the GPL and the memory consumption of the kernel, it would seem the ideal solution. Then the ADOS VFS could simply be appended to whatever distribution media was used. Since the code is around 150K, its bulk is not a mitigating factor. The biggest problem is the line in the GPL about "3 years". There's a clause that says that source needs to be available for 3 years from the time that a binary is offered. But what happens to an ftp machine that goes offline, never to return? Is the company that supported that machine liable for the GPL if they had gnu binaries on board? I would probably change the wording of the GPL to state that the source must be available during the same time frame that the binary is. So if you decide you're running out of disk space, you delete the binary first (users can always recompile). If you still need space, you delete the source after arranging with a mirror site to pick up a recent copy. >-Markus Additional comments? (Since my girlfriend has ftp access now, I think I'll graba copy of NetBSD in the next week or two and see about helping on the ADOS VFS work. Niklaus, what do you think about a collaboration? :-) -- Frank "Crash" Edwards Edwards & Edwards Consulting Voice: 813/786-3675 Unix/AIX & OS/2: Training, Programming, and SysAdmin Data/Fax: 813/787-3675 crash@azhrei.EEC.COM; inquiries to info@azhrei.EEC.COM From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 04:04:48 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu Subject: Thoughts on updated binary distribution Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm in the process of attempting to rebuild the entire system from the 12 Feb sources from sun-lamp. I've run into some problems and would like to offer the following suggesions: 1. The files in /bin and /usr/bin should be the ones from sun-lamp (and not links to other places). 2. /usr/bin/cc should be the sun-lamp version. It would be possible to have a newer version of the GNU C compiler in /usr/gnu/bin. Unless someone beats me to it, or tells me that they plan on doing it, I'll upload new binaries to eunet when I get a system compiled that can rebuild itself. I'm not sure that I'm willing to do this on a reoccuring basis, but hopefully after this build, the next one will be easier. I was rather concerned to find out how "far behind" sun-lamp the 720 binaries were. As an aside, once I get my system rebuilt, I'm planning on uploading the 2nd GNU binaries update. Comments on #1 and #2? -SR From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 09:26:28 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: Shared lib problems...? From: jefF rizzO Sender: owner-amiga@sun-lamp.cs.berkeley.edu After beating my head against this for two days, re-reading the FAQ several times, and looking through two weeks of this mailing list, I'm ready to ask for a little help getting NetBSD-Amiga up on MY amiga. Here's the symptoms: Virtually all the files in /usr/bin, and many others, refuse to run, giving me 'trapsignal (various numbers)', and either "floating point exception" or "bus error", or possibly some other (related) message. It seems to me that I'm having a shared-library related problem. The question is, what have I forgotten to do??? I have the /usr/lib and /usr/libexec archives, and the updated bash, make, and ps, and am running vmunix.744. Is there something else? Here's my setup: A2000, ECS Agnus & Denise GVP G-Force '040 accelerator with 4 meg Seagate ST41200N 1.2G drive Also, 'reboot' and 'reboot.amiga' don't seem to work for me. I read the suggestion of someone (the name escapes me now, sorry) with a G-Force '030 who suggested using 'gvpcpuctrl NOFASTROM', but it doesn't seem to work for me. Any suggestions? Thanks in advance... I can hardly wait to have NetBSD functional. +jeff From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 10:57:20 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Shared lib problems...? To: riz@netcom.com (jefF rizzO) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 368 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Here's the symptoms: > Virtually all the files in /usr/bin, and many others, refuse to run, giving > me 'trapsignal (various numbers)', and either "floating point exception" or Hmm, your running everything from the rchive and didn't compile something like ld and friends? If you have recompiled ld.so with a bad compiler then things like this will happen. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 11:06:58 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, pepersb@cuug.ab.ca Subject: Re: Audio and Floppy drivers Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu pepersb@cuug.ab.ca (Brad Pepers) wrote: > I'm not sure about the audio drivers but I am working on a floppy > driver. I have it kind of working (will read data most of the time) > but its in pretty rough shape right now. I had asked mw (did you > get my mail?) and ... (can't remember who else) for some floppy > driver code someone else has done. I was hoping looking at someone > elses code would help me see whats wrong with mine. No word back yet. I don't know if it would be of any help, but you could take a look at my messydisk.device, part of MSH 1.30 (available from aminet ftp sites). It uses trackdisk for stuff like seeking, but it does (under 1.3) its own disk DMA, which works fine. It then proceeds to do its own pc-style MFM decoding, so for Amiga format disk you'd have to do that somewhat different. If you're interested, I could contribute some twice as fast MFM encoding/decoding functions, the same as those in the commercial edition of MSH, and miscellaneous small bug fixes. > Tracks are only read properly once out of every five or so tries (I > think it is something to do with the sync not working). The wordsync is used in MSH, and its use is rather simple. Just put the sync word in the DSKSYNC register and set the WORDSYNC bit in the appropriate control register. That's all there is to it. But be sure to request a read of about (1 track + 1 sector), because the first sector you get might be incomplete (there is a sync after the sector header, at least in pc formats, so you might have a whole sector without its identification). -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ There are no lemurs in this post rhialto@mbfys.kun.nl From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 11:18:18 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: Re: 5380 SCSI support added! To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1094 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Don't expect as quick a response on an IDE driver as I was able to do > with the 5380 driver. I have a homebuilt 5380 board to test with, and > several years of experience working on the driver for that board, so it > was quite easy to get the 5380 driver working. I don't have much > experience with programming an IDE driver (I did try to do that on my > A1000 scsi board, but wasn't very sucessful getting it to work right). I > also don't have an A1200 or A4000 to test a driver with [unless someone > is willing to loan or donate such a machine :-)], so trying to test out > the driver would probably be a longer process. I don't know if it would help you anything, but I have some sources for an IDE-Device for the Amiga. If you want it, I could send it to you. > Michael Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo-----------------+ | Tobias Abt | | email: Tobias.Abt@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +-----------------------------------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 11:47:40 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, dej@eecg.toronto.edu Subject: Re: ADOSFS and GPL Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu David Jones wrote: > Although no precedent has been set, the FSF takes a dim view of anyone using > techniques such as this to "work around" the GPL. The FSF considers pretty > well ALL dynamic link libraries to be equivalent to statically linked libs. It seems that not enough people are aware of the Library Public License, called COPYING.LIB on most gnu ftp sites. I quote from the preamble: For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights. > This means that using a dynamic loading technique does not exempt you from > the GPL requirements. And LKM is, after all, a sort of dynamic loader. It can be argued that a dynamically linked executable is in fact exactly "complete object files", which can be "relink[ed] with the library, after making changes to the library and recompiling it." Which brings me to the question of whether it is possible to create a statically linked executable from a dynamically linked one. I would think so, but possibly not with current utilities. A quick try on Linux on a pc didn't give any satisfactory results. And if this is really impossible, you can distribute a binary pre-linked (ld -r), and have the installation procedure link the final executable (static or dynamic, per the user's choice). And personally, I don't find the concept of the GPL that bad. Most of my recent AmigaOS software is GPLed, just because it is (supposed to be) a discouraging restriction for people who want to make money off my personal efforts. And if I like, I can always re-release my software with less severe restrictions. The other way around is impossible: a package with no distribution limitations will always remain distributable without limitations, so re-releasing it more strictly will only have the effect that people stick to using the older one. -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ There are no lemurs in this post rhialto@mbfys.kun.nl From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 12:21:42 1994 From: niklas@appli.se (Niklas Hallqvist) To: crash@azhrei.eec.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: ADOSFS and GPL Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu When it comes to LKMs, aren't they just for providing device drivers? Loadable FSs, or even user-level ones (HURD's translators) is a nice thought, but it isn't necessary unless you care for speed. One can always write a user level FS with a NFS server RPC interface (automounters do this I believe). Frank, I'll soon be uploading the NetBSD ADOSFS code anyway, you can snatch it then and work away on r/w support if you want to. Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 14:03:40 1994 From: Arthur Hoffmann Subject: sup where? how? To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 269 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi Where can I get sup? I tried supp.tar.gz from mach.cs.mtu.edu, but it doesn't compile on my machine. (lots of conflicting type errors). Is there another sup or do I need to change the sources? Thanks. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 14:42:29 1994 From: niklas@appli.se (Niklas Hallqvist) To: rms@gnu.ai.mit.edu Cc: crash@azhrei.eec.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu [ Richard, would you like to make a ruling on a GPL matter for us? As you well know, the BSD type of Copyright is very liberal, even allowing hiding source as long as you give credits where they are due. Currently the Amiga NetBSD porting group have a dispute. Our problem is that we're sitting on a filesystem implementation written under GPL protection and we don't know if it's possible to incorporate this filesystem code into the main NetBSD repository at Berkeley without applying GPL to all of the NetBSD kernel source. One point being made below is that as it's installed by a compile time option, NetBSD as a whole cannot be regarded as work based on this code, thus the FS code cannot force GPL onto the other parts of the kernel. Is this so? What if a binary kernel with the FS code in it were to be distributed, would it be sufficient to provide the FS code in source form and a pointer to where the rest of NetBSD can be found? I suspect this is borderline. In the discussion below there's also a dispute whether or not GPLd LKMs (loadable kernel modules) would mean anything to the kernel copyright. I'd say no, but if you would make a ruling, we'd appreciate it. Thanks. - Niklas Hallqvist ] Subject: Re: ADOSFS and GPL To: amiga-dev@sun-lamp.cs.berkeley.edu Date: Mon, 14 Feb 1994 19:11:33 -0500 (EST) From: Frank "Crash" Edwards In-Reply-To: <199402142135.WAA15556@eunet.ch> from "mw@eunet.ch" at Feb 14, 94 10:35:40 pm Organization: Edwards & Edwards Consulting, Palm Harbor, FL X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7004 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Precedence: bulk mw@eunet.ch sayeth: >I said: >> Well, I've got a question. This has come up before, but I never >> understood the rationale. Last time, I was told "NetBSD can't have >> GPL'd code" but nobody said why. >> >> I'd like to know why. It seems to me that the GPL guarantees that >> source code will always be available. If NetBSD has this same >> philosphy, what's the problem? If it doesn't, why not? [Perhaps >> someone could post the NetBSD version of the GPL? Then I could >> compare them myself...] > >Here's an example copyright header (sys/kern/tty.c): >/*- > * Copyright (c) 1982, 1986, 1990 The Regents of the University of California. > * Copyright (c) 1991 The Regents of the University of California. > * All rights reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in the > * documentation and/or other materials provided with the distribution. > * 3. All advertising materials mentioning features or use of this software > * must display the following acknowledgement: > * This product includes software developed by the University of > * California, Berkeley and its contributors. > * 4. Neither the name of the University nor the names of its contributors > * may be used to endorse or promote products derived from this software > * without specific prior written permission. > * > [disclaimer of no warranty] > >So, the most important difference is that you can do "almost anything" with >the source as long as you give proper credit. Under GPL, you're *forced* >to disclose any sources you develop based on GPL sources, if you'd like >to distribute your product, possibly SELL your product. Introducing just >one GPL source into the kernel would *force* you to distribute source >to anything you develop on the kernel, even if you just plain include and >don't change that GPL source. The BSD sources have a very liberal copyright, >and I don't want to restrict them all of a sudden to GPL conditions. That's not how I read the GPL. Quoted from Section 2: "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it." The rest of the NetBSD kernel is most definately an "independent and separate work" since the AmigaDOS VFS is merely an add-on; an option. The rest of the kernel is not "part of a whole which is a work based on the Program" since the kernel is a self-contained program in it's own right and does not require nor even suggest the use of the ADOS VFS. "Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program." Exactly. "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." A little bit different from the first paragraph since this one is limited strictly to distribution media, but this certainly spells out that the kernel could not be considered covered by the GPL just because the ADOS VFS was. >Things look slightly different when talking about applications to go >into the system. They're closed "objects" by themselves. Using for example >gcc as the system compilier doesn't force you to also distribute sources >for your commercial application FOOBAR you'd like to distribute with >the system. Agreed. This has been discussed quite a bit in gnu.* groups. >> Heck, if I knew that the NetBSD wasn't going to restrict the code >> somewhere down the line, maybe I'd finish the read/write stuff >> myself? I've been thinking about trying out NetBSD... ;-) > >Grin, give it a try! Perhaps. How do I know that the source will be available tomorrow? I don't. (I'm not suggesting that anyone currently developing NetBSD would conspire to remove the source from the airwaves, merely that I could get "hooked" into an OS that started out "free" and then changes so that only binaries are available.) >There could EVEN be an alternate solution to this problem! NetBSD knows >about loadable kernel modules (LKM). Implementing this filesystem as an LKM >file system, there wouldn't be a fixed link between the kernel and the >object files. Both, the kernel and the object files of the filesystem would >be distributable seperately. That way, I think, the filesystem code could >remain GPLd without making the kernel itself GPL. Well, I'm no laywer... Yes, this looks feasible also. In fact, since this solves two problems at once, ie. the fear of the GPL and the memory consumption of the kernel, it would seem the ideal solution. Then the ADOS VFS could simply be appended to whatever distribution media was used. Since the code is around 150K, its bulk is not a mitigating factor. The biggest problem is the line in the GPL about "3 years". There's a clause that says that source needs to be available for 3 years from the time that a binary is offered. But what happens to an ftp machine that goes offline, never to return? Is the company that supported that machine liable for the GPL if they had gnu binaries on board? I would probably change the wording of the GPL to state that the source must be available during the same time frame that the binary is. So if you decide you're running out of disk space, you delete the binary first (users can always recompile). If you still need space, you delete the source after arranging with a mirror site to pick up a recent copy. >-Markus Additional comments? (Since my girlfriend has ftp access now, I think I'll graba copy of NetBSD in the next week or two and see about helping on the ADOS VFS work. Niklaus, what do you think about a collaboration? :-) -- Frank "Crash" Edwards Edwards & Edwards Consulting Voice: 813/786-3675 Unix/AIX & OS/2: Training, Programming, and SysAdmin Data/Fax: 813/787-3675 crash@azhrei.EEC.COM; inquiries to info@azhrei.EEC.COM From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 15:15:22 1994 X400-Originator: /dd.id=1619692/g=hamish/i=hi/s=macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.624:15.01.94.14.04.09] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Audio and... From: "hamish (h.i.) macdonald" To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: pepersb@cuug.ab.ca Subject: Re: Audio and Floppy drivers Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> pepersb@cuug.ab.ca (Brad Pepers) wrote: >> I had asked mw (did you get my mail?) and ... (can't remember who >> else) for some floppy driver code someone else has done. I was >> hoping looking at someone elses code would help me see whats wrong >> with mine. No word back yet. As of 0.07, the Linux floppy driver seems pretty reliable for reading/writing ADOS format disks. You might want to use it as a reference. Like Brad's driver, it is currently using a delay loop for the track stepping and various other timings. Like him, I want to change it to use the cia timers, and also change it to be completely interrupt driven. One other thing I hate about it is that every time a block is written, it writes the track to the disk. This can make large writes really slow. I'd like to put in some sort of 10-20ms delayed write mechanism, but I'm a little bit worried about the interactions with "sync". From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 16:40:25 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Shared lib problems...? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 15, 12:09am, jefF rizzO wrote: > Here's the symptoms: > Virtually all the files in /usr/bin, and many others, refuse to run, giving > me 'trapsignal (various numbers)', and either "floating point exception" or > "bus error", or possibly some other (related) message. It seems to me that > I'm having a shared-library related problem. The question is, what have I > forgotten to do??? I have the /usr/lib and /usr/libexec archives, and the > updated bash, make, and ps, and am running vmunix.744. Is there something > else? > > Here's my setup: > A2000, ECS Agnus & Denise > GVP G-Force '040 accelerator with 4 meg ^^^ I think you need an updated /usr/libexec/ld.so (or patch the one you have). The one originally distributed in the /usr/libexec archive doesn't have the cache control needed to run on the '040. I don't know if a patched version or an updated version is available anywhere. I can send you the patches to fix the old ld.so if you want. > Also, 'reboot' and 'reboot.amiga' don't seem to work for me. I read the The reboot on the '040 doesn't work in kernels up to vmunix.744. I changed the reboot code to work on my PPI Zeus card, and the changes should be in the current sources. When someone creates a new kernel, that fix should be in there. I don't know if it will work with the G-Force '040 though. Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 17:03:18 1994 From: Paul Yadlowsky X-Mailer: Z-Mail (2.1.4 02apr93) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: 4mm DAT driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I have an Archive Python 4mm DAT drive interfaced to my Amiga 3000 with the stock A3000 SCSI controller. This drive works fine with gnutar or AmiBack from AmigaDos. When I load NetBSD I get the following message: st0: ARCHIVE Python 25601-XXX rev st0: unsupported tape drive st0 at a3000scsi0, slave 5 The NetBSD FAQ says to ignore the 'unsupported tape drive' message. The system seems to recognize that the drive is an Archive Python and is attached to scsi device 5; this is correct. So why do I get the following message when I try to access this drive with tar. tar: can't open /dev/rst0: Input/output error Please note the /dev/rst0 does exist. Do I need a different driver for this tape drive? If so, has anyone else already written such a driver and is he/she willing to share it with me? If this is the case, can you tell me how to incorporate this driver into the system? Thanks, -Paul -- Paul Yadlowsky ITC-Academic Computing Health Sciences psy@galen.med.Virginia.EDU University of Virginia (804) 924-2846 (office) Health Sciences Center (804) 982-4030 (fax) Hospital West, Room 3001 Charlottesville, VA 22908 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 17:36:58 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sup where? how? To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 381 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Hi > Where can I get sup? I tried supp.tar.gz from mach.cs.mtu.edu, but it > doesn't compile on my machine. (lots of conflicting type errors). Is > there another sup or do I need to change the sources? Sup is available on most of su-lamps mirrors and sun-lamp in ready to compile form. NetBSD-current/tar_files/othersrc/sup.tar.gz or something like that. > Arthur. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 17:52:42 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: ADOSFS and GPL To: rhialto@mbfys.kun.nl (Olaf Seibert) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, dej@eecg.toronto.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1045 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > It can be argued that a dynamically linked executable is in fact > exactly "complete object files", which can be "relink[ed] with the > library, after making changes to the library and recompiling it." Hmm I don't know much about the GPL however I can tell you that LKM's might as well be executables. If LKM's are covered by the GPL then the GPL is broke. An LKM is loaded just like a binary, it passes some stuff to the kernel to let the kernel know how to call it. Sounds like a executable with an exec header to me. > And personally, I don't find the concept of the GPL that bad. Most of > my recent AmigaOS software is GPLed, just because it is (supposed to > be) a discouraging restriction for people who want to make money off my > personal efforts. And if I like, I can always re-release my software The GPL does no such thing. On the amiga where the practice of not selling source abounds in the commercial market, the GPL happens to seem to have this side affect. However Many companies sell GNU software. > -Olaf. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 17:56:39 1994 From: rhealey@aggregate.com Subject: ender: owne To: chopps@emunix.emich.edu (Chris Hopps) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 888 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Hi > > Where can I get sup? I tried supp.tar.gz from mach.cs.mtu.edu, but it > > doesn't compile on my machine. (lots of conflicting type errors). Is > > there another sup or do I need to change the sources? > > Sup is available on most of su-lamps mirrors and sun-lamp in ready to > compile form. NetBSD-current/tar_files/othersrc/sup.tar.gz or > something like that. > Note that sup will not easily compile on SysV derived systems. It's an easy port only to BSD derived systems. Many may say so what but this presents a problem for people who's Internet connected system is SVR4 or SysV based. It would be nice if sup was ANSIified and an SV port was done so it worked more universally. ALOT of NetBSD folk can't put their machines directly on the Net so sup does them little good if it can't be compiled on the Internet connected machine they CAN get to. B^(. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 18:10:18 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) To: niklas@appli.se Cc: crash@azhrei.eec.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I would probably change the wording of the GPL to state that the source must be available during the same time frame that the binary is. If by "available" you mean ftp, this is *already* the case in the current GPL. Please reread those paragraphs carefully and check what situations they apply to. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 18:15:01 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) To: niklas@appli.se Cc: crash@azhrei.eec.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Our problem is that we're sitting on a filesystem implementation written under GPL protection and we don't know if it's possible to incorporate this filesystem code into the main NetBSD repository at Berkeley without applying GPL to all of the NetBSD kernel source. You don't need to change the terms for the other kernel files. The fact that one file is covered by the GPL can never force you to apply the GPL to some other file written entirely by you. If you copy the GPL-covered code, then the GPL has to cover the file that it was copied to. In general, anyone distributing a kernel binary must obey the conditions for each source file used. If one of the source files is covered by the GPL, that brings in the requirement to make available complete source for that binary, including the files that are not covered by the GPL. I don't believe it makes any difference how the linking is done-- whether it is static or dynamic. If someone distributes a kernel binary that is meant to have a particular GPL-covered module linked into it, that is one program, so the whole kernel source must be provided. If the kernel binary isn't meant to have a module linked in with it, and some user decides to link it in, then only that user is responsible for the decision, so the kernel binary distributor cannot have any responsibilities as a consequence. Legally, you're not required to use the GPL except on files that contain copied GPL-covered code. However, as a practical matter, it would be better for you to use the GPL wherever you can, since that will ensure people who make changes actually release them as free software. If you permit changes to be proprietary, you will again and again find yourself in the position of trying to catch up with proprietary changes. Cooperation should be a two-way street; if someone wants to be part of the community, he should contribute when he has an opportunity. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 18:33:51 1994 From: leland@wacky.acet.org (Robert Leland - PSI) To: hoffmann@it.ntu.edu.au, chopps@emunix.emich.edu Subject: Re: sup where? how? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Hi > > Where can I get sup? I tried supp.tar.gz from mach.cs.mtu.edu, but it > > doesn't compile on my machine. (lots of conflicting type errors). Is > > there another sup or do I need to change the sources? > > Sup is available on most of su-lamps mirrors and sun-lamp in ready to > compile form. NetBSD-current/tar_files/othersrc/sup.tar.gz or > something like that. > Wouldn't you also need a version > > Arthur. > > Chris. > From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 18:39:05 1994 From: leland@wacky.acet.org (Robert Leland - PSI) To: amiga-dev@sun-lamp.cs.berkeley.edu, psy@sanger.med.virginia.edu Subject: Re: 4mm DAT driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I have an Archive Python 4mm DAT drive interfaced to my > Amiga 3000 with the stock A3000 SCSI controller. This > drive works fine with gnutar or AmiBack from AmigaDos. > When I load NetBSD I get the following message: > > st0: ARCHIVE Python 25601-XXX rev > st0: unsupported tape drive > st0 at a3000scsi0, slave 5 > > The NetBSD FAQ says to ignore the 'unsupported tape drive' message. > The system seems to recognize that the drive is an Archive Python > and is attached to scsi device 5; this is correct. So why do > I get the following message when I try to access this drive with > tar. Ah, get the kernel incoming/vmunix-tape.tar.gz and the incoming/README.vmunix-tape file. This kernel has, and the next released one will also, a patachable variable called pretend_tobe_mt or something like that. You can select what tape drive you want you tape to act like. Try and see if it will behave like a 8mm DAT drive. Complete details are in the README files. > > tar: can't open /dev/rst0: Input/output error > > Please note the /dev/rst0 does exist. Do I need a different > driver for this tape drive? If so, has anyone else already > written such a driver and is he/she willing to share it with > me? If this is the case, can you tell me how to incorporate this > driver into the system? If it works I can patch the new st.c that is on sun-lamp for you or you can do it youself! Patches to the 744 st.c will definately not work, as Michael Hitch went to a data driven tables. > > Thanks, > -Paul > -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 19:25:52 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: ender: owne To: rhealey@aggregate.com Cc: chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 507 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Sup is available on most of su-lamps mirrors and sun-lamp in ready to > > compile form. NetBSD-current/tar_files/othersrc/sup.tar.gz or > > something like that. > > > Note that sup will not easily compile on SysV derived systems. It's > an easy port only to BSD derived systems. Many may say so what but > this presents a problem for people who's Internet connected system > is SVR4 or SysV based. Well for the time being sup compiles fine on NetBSD and so does term... *grin* > -Rob Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 19:29:43 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sup where? how? To: leland@wacky.acet.org (Robert Leland - PSI) Cc: hoffmann@it.ntu.edu.au, chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 330 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Sup is available on most of su-lamps mirrors and sun-lamp in ready to > > compile form. NetBSD-current/tar_files/othersrc/sup.tar.gz or > > something like that. > > > Wouldn't you also need a version I don't understand this question. Sup is in the NetBSD source tree no version numbers needed, grab from current. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 19:41:36 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: ADOSFS and GPL Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9402151055.AA15424@liza.appli.se> niklas@appli.se (Niklas Hallqvist) writes: > When it comes to LKMs, aren't they just for providing device drivers? > Loadable FSs, or even user-level ones (HURD's translators) is a nice > thought, but it isn't necessary unless you care for speed. One can The current LKM implementationallows for loadable device drivers, filesystems, system calls, executable file formats, and "other". There's no reason NOT to take advantage of the speed of LKM vs local NFS server, and since ADOSFS is written for a vfs interface, it'd be a lot of work to convert it to an NFS interface. However, it can be converted to a LKM with very little effort -- look in /usr/share/misc/lkm (I think), which includes an example conversionof an older version of kernfs to a LKM. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 20:10:30 1994 Subject: Re: GPL To: rms@gnu.ai.mit.edu (Richard Stallman) From: Frank "Crash" Edwards Cc: amiga-dev@sun-lamp.cs.berkeley.edu Organization: Edwards & Edwards Consulting, Palm Harbor, FL X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1673 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu [Please note that I've added the mailinglist to the Cc: line.] Richard Stallman sayeth: > I would probably change the wording of the GPL to state that the > source must be available during the same time frame that the binary > is. > >If by "available" you mean ftp, this is *already* the case in >the current GPL. Please reread those paragraphs carefully and >check what situations they apply to. Oops; out of context. In the preceding paragraph I stated that I thought the "3 year" clause was a little too long-term. I was going to simply the matter by using a different approach: if you *currently* have the binary, you must also have the source. That allows sites that come under a space constraint to delete the binary. If space is still a problem, delete the source. But they aren't legally bound to make the source available for another 3 years. (Heck, I know businesses that don't keep backups that long.) I should have said, "the source must be available *only* during the same time frame that the binary is." My apologies for any confusion. I certainly agree with the intent of the GPL (which is why my filesystem implementation is covered by it) but by the same token I don't wish to make the distribution of the package such a burden that site administrators will be afraid to carry it! What good is the GPL if individual sites are afraid of the legalities to the point where my code never makes there in the first place?! -- Frank "Crash" Edwards Edwards & Edwards Consulting Voice: 813/786-3675 Unix/AIX & OS/2: Training, Programming, and SysAdmin Data/Fax: 813/787-3675 crash@azhrei.EEC.COM; inquiries to info@azhrei.EEC.COM From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 20:24:54 1994 From: Hubert Feyrer Subject: /etcnetstart & SLIP/PPP To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1266 Sender: owner-amiga@sun-lamp.cs.berkeley.edu There have been rumours that the /etc/netstart distributed with the rootfs_720 doesn't work with point-to-point-devices as SLIP and PPP. The problem is, that when ifconfig'ing the device, the remote IP-number must be the last on the line! (I don't know if this is a bug in /etc/netstart or in ifconfig...). So, the following lines in /etc/netstart must be changed from cmd="ifconfig $1 $af $name " if [ "${dt}" = "dest" ]; then cmd="$cmd $dtaddr"; fi if [ -n "$mask" ]; then cmd="$cmd netmask $mask"; fi if [ -n "$bcaddr" ]; then cmd="$cmd broadcast $bcaddr"; fi cmd="$cmd $extras" into cmd="ifconfig $1 $af $name " if [ -n "$mask" ]; then cmd="$cmd netmask $mask"; fi if [ -n "$bcaddr" ]; then cmd="$cmd broadcast $bcaddr"; fi cmd="$cmd $extras" if [ "${dt}" = "dest" ]; then cmd="$cmd $dtaddr"; fi Everything should work then. Regards, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf ========================================================================== From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 21:04:44 1994 From: Alan Bair Subject: Re: /etcnetstart & SLIP/PPP To: hubert.feyrer@rrzc1.rz.uni-regensburg.de (Hubert Feyrer) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > There have been rumours that the /etc/netstart distributed with the > rootfs_720 doesn't work with point-to-point-devices as SLIP and PPP. > > The problem is, that when ifconfig'ing the device, the remote > IP-number must be the last on the line! (I don't know if this is a bug > in /etc/netstart or in ifconfig...). Sounds like a bug in /etc/netstart, since when I built the rootfs_720, I used the latest (at that time) /etc from sun-lamp. The only changes I made were to set some of the variables to stop the running of any network related tools so it would be easier for non-networked users to run. > > So, the following lines in /etc/netstart must be changed from > > cmd="ifconfig $1 $af $name " > if [ "${dt}" = "dest" ]; then cmd="$cmd $dtaddr"; fi > if [ -n "$mask" ]; then cmd="$cmd netmask $mask"; fi > if [ -n "$bcaddr" ]; then cmd="$cmd broadcast $bcaddr"; fi > cmd="$cmd $extras" > > into > cmd="ifconfig $1 $af $name " > if [ -n "$mask" ]; then cmd="$cmd netmask $mask"; fi > if [ -n "$bcaddr" ]; then cmd="$cmd broadcast $bcaddr"; fi > cmd="$cmd $extras" > if [ "${dt}" = "dest" ]; then cmd="$cmd $dtaddr"; fi > > Everything should work then. > > > Regards, > > Hubert > > =============== Hubert Feyrer ============================================ > Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 > Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 > Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf > ========================================================================== > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 21:12:13 1994 From: mw@eunet.ch (Markus Wild) Subject: Re: ender: owne To: rhealey@aggregate.com Cc: chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 600 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Note that sup will not easily compile on SysV derived systems. It's > an easy port only to BSD derived systems. Many may say so what but > this presents a problem for people who's Internet connected system > is SVR4 or SysV based. I bet this is because SVR4 TLI-based socket emulation sucks DEEP.. I'll try to look at it, and give it a try at POSIXification, but I'll certainly not even think at touching anything TLIy, eak... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 21:53:44 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "RMS" == Richard Stallman writes: RMS> You don't need to change the terms for the other kernel files. RMS> The fact that one file is covered by the GPL can never force you RMS> to apply the GPL to some other file written entirely by you. If RMS> you copy the GPL-covered code, then the GPL has to cover the file RMS> that it was copied to. Well... this is a definite ruling, so what should I do? Send of my patches to Chris for inclusion at sun-lamp? Make a stand-alone package just for those of the users who compile their own kernels? I prefer the former. Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 15 22:59:47 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) To: crash@azhrei.eec.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: GPL Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I certainly agree with the intent of the GPL (which is why my filesystem implementation is covered by it) but by the same token I don't wish to make the distribution of the package such a burden that site administrators will be afraid to carry it! I don't understand why you think it IS a burden--I suspect you're misunderstanding the current requirements. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 23:02:18 1994 From: windiba@server.uwindsor.ca (Chris Windibank) Subject: NetBSD history ? To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu If anyone cares to enlighten me with the history behind this distribution of NetBSD I would apreciate it very much. I have been reading The Design and Imlementation of The 4.3BSD Unix Operating System and I have seen the posting about this being 4.4BSD. Does this mean that this release is just a continuation of what was done in 4.3 to correct some of 4.3's deficiencies or is this a totally new beast seperate from the 4.3BSD release ? Any information would be helpful. Chris From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 23:09:48 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: sup where? how? Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > Sup is available on most of su-lamps mirrors and sun-lamp in ready to > > > compile form. NetBSD-current/tar_files/othersrc/sup.tar.gz or > > > something like that. Great ! I hate to sound like a total thickie but what is this sup thing that you're all talking about ? +-------------------------------+--------------------------+ ! John Shardlow | "I seem to be having ! ! john@iceberg.demon.co.uk | tremendous difficulty ! ! jshardlow@micrognosis.co.uk | with my lifestyle" ! ! | - Arthur Dent ! +-------------------------------+--------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 15 23:26:37 1994 From: leland@wacky.acet.org (Robert Leland - PSI) To: leland@wacky.acet.org, chopps@emunix.emich.edu Subject: Re: sup where? how? Cc: hoffmann@it.ntu.edu.au, amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > Sup is available on most of su-lamps mirrors and sun-lamp in ready to > > > compile form. NetBSD-current/tar_files/othersrc/sup.tar.gz or > > > something like that. > > > > > Wouldn't you also need a version > > I don't understand this question. Sup is in the NetBSD source tree no > version numbers needed, grab from current. > This was an aborted messaage :-}, my mailer died and decided to send the message. I was actually going to say that if you need the supserver running also that you probably need to get the real crypt, but I wasn't sure of that so I decided not to send the message, hence an abort. > Chris. > -Rob From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Feb 16 00:12:12 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu Subject: FAQ.netbsd.X available Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu SSIA: FAQ for NetBSD-Amiga X window is available on eunet and Regensburg. Will be moved to the DOCS directory soon, i hope. Mail me all bugs, errors and complaints. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 16 00:19:15 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu Subject: FAQ.netbsd.X available Sender: owner-amiga@sun-lamp.cs.berkeley.edu SSIA: FAQ for NetBSD-Amiga X window is available on eunet and Regensburg. Will be moved to the DOCS directory soon, i hope. Mail me all bugs, errors and complaints. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 16 00:59:07 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "/etcnetstart & SLIP/PPP" (Feb 15, 8:10pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Hubert Feyrer , amiga@sun-lamp.cs.berkeley.edu Subject: Re: /etcnetstart & SLIP/PPP Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 15, 8:10pm, Hubert Feyrer wrote: > Subject: /etcnetstart & SLIP/PPP > There have been rumours that the /etc/netstart distributed with the > rootfs_720 doesn't work with point-to-point-devices as SLIP and PPP. be also sure you removed files like 'hostname.bah.EXAMPLE' or 'hostname.old' as the script will try to read them. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 01:00:19 1994 From: niklas@appli.se (Niklas Hallqvist) To: fnf@fishpond.cygnus.com Cc: rms@gnu.ai.mit.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu [ I'm sorry going on about these legal matters in a dev group, but I think it *is* of big importance being able to use GPLd work in the NetBSD kernel. If you disagree, just say so... --Niklas ] >>>>> "Fred" == Fred Fish writes: RMS> You don't need to change the terms for the other kernel files. RMS> The fact that one file is covered by the GPL can never force you RMS> to apply the GPL to some other file written entirely by you. If RMS> you copy the GPL-covered code, then the GPL has to cover the file RMS> that it was copied to. Niklas> Well... this is a definite ruling, so what should I do? Send of Niklas> my patches to Chris for inclusion at sun-lamp? Make a stand-alone Niklas> package just for those of the users who compile their own kernels? Niklas> I prefer the former. Fred> Hmm, I think you may have misinterpreted the response. When Fred> taken in context with the paragraph that follows it, it says to Fred> me "the existance of a file covered under the GPL cannot force Fred> you to cover your own file under the GPL, but if you compile and Fred> link it with your own file *then* you must change your file to Fred> also be covered under the GPL, if you distribute the resulting Fred> binary". The paragraph following the one I cited was: In general, anyone distributing a kernel binary must obey the conditions for each source file used. If one of the source files is covered by the GPL, that brings in the requirement to make available complete source for that binary, including the files that are not covered by the GPL. Here RMS says nothing about that the files not under GPL originally will be forced to be GPLd after a binary release. He says "make available complete source" which is in fact easiest done providing a pointer to some FTP sites carrying NetBSD. The sole problem I can think of is: Do we need to archive snapshots of the sources when we make binary releases? Fred> Basically I think it boils down to the fact that GPL and non-GPL Fred> source files can be intermixed, and distributed as source files, Fred> without any requirements to GPL the entire source base. But as Fred> soon as anyone makes and distributes a binary that includes the Fred> GPL file, they must also distribute the other source files under Fred> the GPL. What do you say, Richard? Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Feb 16 02:18:13 1994 From: DCG9367@tntech.edu Subject: Retina.library v8? To: amiga-x@sun-lamp.cs.berkeley.edu X-Vms-To: IN%"amiga-x@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I hate to put this here, but I can't get a response elsewhere. A friend of mine purchased ADPro V2.5, he has a 2000, Opalvision, and a Retina. ADPro requires retina.library vers 8. I have thought about getting the new ADPro but it will be useless (to me:) ) if I can't use my $500 video card with it. I have a 2000/GForce040/Retina and was wondering where I can get the new Retina software? Does MacroSystems have an FTP site? I wish that companies would let their registered users know when new software comes out for their videocards. Ive seen Merlin updates everywhere on aminet, why can't others do the same? If it is legal, could some one please send me the updated Retina Software (eg. libraries, new WB emul if one, etc..)? Getting them from MacroSystems by phone (if they will do it) could take a month or so. David. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 02:29:08 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3003 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > [ I'm sorry going on about these legal matters in a dev group, but I > think it *is* of big importance being able to use GPLd work in the > NetBSD kernel. If you disagree, just say so... --Niklas ] I took RMS out of the cc: list becuase I didn't want to sound insulting and sending him this could be seen that way. NetBSD developers seem to have a *very* strong belief in there own standard Copyright. From talking to other developers what I surmise is this: There will *never* be any GPL code in the kernel. If your trying to figure out the legalities and possibility behind including GPL code directly in the kernel, don't. It probably will never happen. Even if it is surmised that it could be allowed. However as someone pointed out (I think I did to someone but maybe not on the list) The ADOSFFS could be done as an LKM, as then it would be just another binary and could be distributed seperately (or possible in the /usr/src/gnu/* drawer of the netbsd ditrib which gets archived seperately) I think the LKM approach is good and could be done right away. Later maybe someone could re-write the GPL sections of the code and have it move into the main source distribution. I understand the reason behind keeping the GPL on the code. I personally do not object to the BSD standard copyright which basically gives anyone the right to do anything with my code except sue me. Sure someone my take my code and distribute it in binry form only, however tht will never take my code *out* of distribution, no one can do that. For a good example look at byacc, you could compile byacc and sell it if you wanted (and maybe someone has) but you don't see the source to byacc going away. Byacc happens to be an excelent example becuase of the legalities behind Bison (not sure if these have been resolved yet but it was a big deal at one time) You write a parser and use byacc to generate code for it, now your perfectly safe to do anything you want with your parser. The way I see it is this: There are 2 parts to this file system, the NetBSD part and the AmigaDOS part. For the NetBSD part there are numerous examples of file systems. For the ADOS part we have this not so good book "The AmigaDOS Manual" which gives enough info to construct that part. I am sure we can completely curcumvent the GPL thing by just writing those parts from scratch. Its almost ironic, the main reason I belive Frank wishes to keep the source GPL'd is to help people like us. Lets read his source and rewrite it. That way the GPL doesn't need to go and we don't get the GPL. *NOTE* rewriting does not mean copying, I belive that current copyright laws require that if you use a copyrighted source as a guide you must not have it available while using what you learned to author similar code. This means you don't get to load Frank's code into the editor while you are writing stuff that Frank did (or if you print it out you must put it away). It all sounds so silly sometimes. > Niklas Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 04:23:22 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9402152041.AA28382@della.appli.se> niklas@appli.se (Niklas Hallqvist) writes: > Well... this is a definite ruling, so what should I do? Send of my patches > to Chris for inclusion at sun-lamp? Make a stand-alone package just for those > of the users who compile their own kernels? I prefer the former. Make it stand alone. I personally would prefer to see it as an LKM, even if it was Berkeley-copyright. ADOSFS isn't something needed for booting, so it would be nice to be able to load it when I want it without having to build a new kernel, and leave it out when I don't need it, and save memory. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 05:07:21 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9402152041.AA28382@della.appli.se> niklas@appli.se (Niklas Hallqvist) writes: > Well... this is a definite ruling, so what should I do? Send of my patches > to Chris for inclusion at sun-lamp? Make a stand-alone package just for those > of the users who compile their own kernels? I prefer the former. Make it stand alone. I personally would prefer to see it as an LKM, even if it was Berkeley-copyright. ADOSFS isn't something needed for booting, so it would be nice to be able to load it when I want it without having to build a new kernel, and leave it out when I don't need it, and save memory. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 05:44:34 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) To: niklas@appli.se Cc: fnf@fishpond.cygnus.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Fred> Hmm, I think you may have misinterpreted the response. When Fred> taken in context with the paragraph that follows it, it says to Fred> me "the existance of a file covered under the GPL cannot force Fred> you to cover your own file under the GPL, but if you compile and Fred> link it with your own file *then* you must change your file to Fred> also be covered under the GPL, if you distribute the resulting Fred> binary". No, this is NOT the case. The terms for use of a collection of files are NOT the same as the terms for any one file. If you wish to understand, you need to start making this distinction. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 05:46:53 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) To: niklas@appli.se Cc: fnf@fishpond.cygnus.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: [crash@azhrei.eec.com: Re: ADOSFS and GPL] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Here RMS says nothing about that the files not under GPL originally will be forced to be GPLd after a binary release. He says "make available complete source" which is in fact easiest done providing a pointer to some FTP sites carrying NetBSD. This suffices if FTP is the way you distribute the binary. (Provided you make *sure* the source is available as long as the binary is available.) If you distribute the binary on CDROM or tape, there are different requirements--see the GPL for details. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 06:31:33 1994 From: "Eduardo E. Horvath eeh@btr.com" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Where do I get a config for the sun-lamp kernel? Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I am trying to compile a kernel I got from sun-lamp. Where do I get a config that works with that kernel? MW said that he has a new config, and that it has been uploaded to euenet. The only new config I found was in incoming, but whenever I try to extract it, gzip complains that it is encoded, and that I need a newer version of gzip. What's going on? What DO I need to compile a new sun-lamp kernel? :r .signature From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 16 12:01:48 1994 From: Michael Kofod To: amiga@sun-lamp.cs.berkeley.edu Subject: SCSI-controller? X-Charset: ASCII X-Char-Esc: 29 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I finally decided to try out NetBSD yesterday, but it did not like booting from my BOIL-SCSI controller.. I have been thinking of getting a new SCSI controller, and would like some advice on which would be the best SCSI controller to run NetBSD from. I have an Amiga 4000 with 68040, and I have therefore been thinking of getting either a A4091 or a A2091 with 2Mb ram.. Which would be the best choice from a NetBSD viewpoint? How about the GVP series II? Does anybody have some experience with running NetBSD on A4000 from one of those? Please help.. I'm desperat to get NetBSD up running :-) /Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 16 12:36:38 1994 From: Olaf Seibert To: chopps@emunix.emich.edu, rhialto@mbfys.kun.nl Subject: Re: ADOSFS and GPL Cc: amiga-dev@sun-lamp.cs.berkeley.edu, dej@eecg.toronto.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu chopps@emunix.emich.edu (Chris Hopps) wrote: > [Olaf Rhialto Seibert, i.e., me, wrote:] > > It can be argued that a dynamically linked executable is in fact > > exactly "complete object files", which can be "relink[ed] with the > > library, after making changes to the library and recompiling it." > > Hmm I don't know much about the GPL however I can tell you that LKM's > might as well be executables. If LKM's are covered by the GPL then Note that I'm talking here about dynamically linked executables (which need some LGPL-ed library), not about LKMs which are themselves covered by the GPL. The cases may be somewhat similar, but aren't. > > And personally, I don't find the concept of the GPL that bad. Most of > > my recent AmigaOS software is GPLed, just because it is (supposed to > > be) a discouraging restriction for people who want to make money off my > > personal efforts. And if I like, I can always re-release my software > > The GPL does no such thing. On the amiga where the practice of not > selling source abounds in the commercial market, the GPL happens to > seem to have this side affect. However Many companies sell GNU software. I suppose that those companies really sell the support and/or the media on which the software comes, and throw in the actual software for free. If not, their clients are rather stupid to pay for something that's can be had for free. But for the support they certainly deserve to be paid. > > -Olaf. > Chris. -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ There are no lemurs in this post rhialto@mbfys.kun.nl From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 16 14:42:17 1994 From: dvb@ssd.kodak.com (Dave Blaszyk) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: sup Content-Length: 637 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have compiled a version of 'sip' for Solaris 1.x and 2.x, under Solaris 1.1. They have a "binary" compatability mode that allowed me to compile this under 1.x, while still being able to run under SunOS, Solaris 1.x and Solaris 2.x. I have been using this for about 2 weeks, with no apparent problems. If there is any interest, I guess I could place this in an area that people can get to. Any suggestions? /-// \\-\Dave Blaszyk e-mail : dvb@ssd.kodak.com /-//\ /\\-\(716) 253-7953 mail : Eastman Kodak ///d// \\v// \\b\\\ C Plant, Bldg. 10 MC 39011 \\\// \// \\/// Rochester, New York 14620 From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 16 15:33:57 1994 From: Matthias Kirschnick Subject: FAQ.netbsd.X available via WWW To: amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1104 Sender: owner-amiga@sun-lamp.cs.berkeley.edu In our previous episode, Markus Illenseer said: > SSIA: FAQ for NetBSD-Amiga X window is available on eunet and > Regensburg. Will be moved to the DOCS directory soon, i hope. > > Mail me all bugs, errors and complaints. > > -- > Markus Illenseer > This FAQ is available via WWW, too! Try: http://www.informatik.uni-erlangen.de/IMMD-IV/Persons/kirschni/NetBSD-Amiga/index.html Matthias ------------------------------------------------------------------------------ Dipl.-Inf. Matthias Kirschnick Phone: 49 9131 85 8027 IMMD IV, Universitaet Erlangen-Nuernberg Fax1: 49 9131 85 8732 Martensstrasse 1; D-91058 Erlangen Fax2: 49 9131 39 388 kirschnick@immd4.informatik.uni-erlangen.de http://www.informatik.uni-erlangen.de/IMMD-IV/Persons/kirschni/ ------------------------------------------------------------------------------ "Es geht auch anders, aber so geht es auch!" "You can do this differently, but you can also do it like this!" (Lotti Huber) From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Feb 16 17:22:45 1994 From: Matthias Kirschnick Subject: FAQ.netbsd.X available via WWW To: amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1104 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu In our previous episode, Markus Illenseer said: > SSIA: FAQ for NetBSD-Amiga X window is available on eunet and > Regensburg. Will be moved to the DOCS directory soon, i hope. > > Mail me all bugs, errors and complaints. > > -- > Markus Illenseer > This FAQ is available via WWW, too! Try: http://www.informatik.uni-erlangen.de/IMMD-IV/Persons/kirschni/NetBSD-Amiga/index.html Matthias ------------------------------------------------------------------------------ Dipl.-Inf. Matthias Kirschnick Phone: 49 9131 85 8027 IMMD IV, Universitaet Erlangen-Nuernberg Fax1: 49 9131 85 8732 Martensstrasse 1; D-91058 Erlangen Fax2: 49 9131 39 388 kirschnick@immd4.informatik.uni-erlangen.de http://www.informatik.uni-erlangen.de/IMMD-IV/Persons/kirschni/ ------------------------------------------------------------------------------ "Es geht auch anders, aber so geht es auch!" "You can do this differently, but you can also do it like this!" (Lotti Huber) From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 16 21:02:50 1994 From: mw@eunet.ch Subject: Re: SCSI-controller? To: v17@aarhues.dk (Michael Kofod) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1246 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > I finally decided to try out NetBSD yesterday, but it did not like > booting from my BOIL-SCSI controller.. What a biiiig surprise :-)) > I have an Amiga 4000 with 68040, and I have therefore been thinking of > getting either a A4091 or a A2091 with 2Mb ram.. Which would be the best > choice from a NetBSD viewpoint? How about the GVP series II? Does > anybody have some experience with running NetBSD on A4000 from one of > those? Hm, 4091 would probably be the best choice, but it's not (yet?) supported under NetBSD. We do have similar drivers, so supporting it shouldn't probably be too hard. The A2091 is supported, as are the GVP-II series. However, the later really suck, at least that's the impression I got from problem reports. First, GVP seems to think it's nice to use same product IDs for all sorts of different boards, second, serial port performance drops dead if you try to do DMAs larger than 512 byte or so.. There is also support for a ZEUS controller, don't ask me any details about that one, I just know it must exist because we got a driver for it:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 17 01:19:20 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 1.18) X-Charset: iso-8859-1 From: lkv@mania.robin.de (Lutz Vieweg) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Audio and Floppy drivers Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi Markus Illenseer, on Feb 14 you wrote: > Get the files > bsd_audio.c bsd_audioreg.h bsd_audiovar.h > > from sun-lamp in the sparc/dev archive, > Just one problem: Amiga has 8Bit Sound, Sparc has 14Bit ... Hmm... this sounds as if it were sensible to write an audio-device for third-party sound cards such as I have... the more I think of it, the more I like the idea of having a sun-sparc-compatible /dev/audio... :) cu, Lutz Vieweg From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 17 04:04:50 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: SCSI-controller? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 16, 5:52pm, mw@eunet.ch wrote: > > I have an Amiga 4000 with 68040, and I have therefore been thinking of > > getting either a A4091 or a A2091 with 2Mb ram.. Which would be the best > > choice from a NetBSD viewpoint? How about the GVP series II? Does > > anybody have some experience with running NetBSD on A4000 from one of > > those? > > Hm, 4091 would probably be the best choice, but it's not (yet?) supported > under NetBSD. We do have similar drivers, so supporting it shouldn't probably I could probably add the 4091 support easily if I knew the offset of the 53C710 registers, and knew the correct values to program the 53C710. Also, NetBSD doesn't currently have any provisions for Zorro III devices, but that should be very easy to add. > do DMAs larger than 512 byte or so.. There is also support for a ZEUS > controller, don't ask me any details about that one, I just know it must > exist because we got a driver for it:-) The Zeus controller is the onboard Fast SCSI-2 controller (also using the 53C710) on the Progressive Peripherals Inc Zeus 68040 accelerator board. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 17 10:47:11 1994 From: Olaf Seibert To: amiga@sun-lamp.cs.berkeley.edu, v17@aarhues.dk Subject: Re: SCSI-controller? Sender: owner-amiga@sun-lamp.cs.berkeley.edu Michael Kofod wrote: > I finally decided to try out NetBSD yesterday, but it did not like > booting from my BOIL-SCSI controller.. For the record: I also have a BOIL3 scsi controller (in my 2000, not in my 4000). It is basically the hardware of a Supra Wordsync (aside: I thought that word was trademarked by commodore, or somesuch) with different firmware (it now supports autobooting and RigidDisk Blocks, and a harddisk password, for instance). The reasons why I haven't tried it in my 4000 yet are 1. the 105M disk with it is full, and I can't just swap disks with the 4000 because they are IDE; (if I really must I could back it up to the empty space on my 326M disk, though) 2. I tried a A2630 of a friend in my 2000 and it didn't like the BOIL card. Removing either from the machine, or running the A2630 in 68000 mode, made it work, otherwise just blank screen. I've presumed that they just programmed their stuff incompatible with a '030 (despite their mentioning them in the user manual) so I never tried it in my 4000. -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ There are no lemurs in this post rhialto@mbfys.kun.nl From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu Feb 17 10:52:32 1994 From: mw@eunet.ch Subject: Re: Problems with Retina-X To: DCG9367@tntech.edu Cc: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 986 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > 1) I can't seem to get any screen mode other than 640x480 to work right. > I changed the Xconfig to several different 8-bit monitor defs that > I am using in AmigaDos, but only the 640x480 is stable. The others > lose vertical hold and flip around. You did specify depth-8? Just asking because I use depth-4 usually when working with ados. > 2) I always get a blotch of random data in the upper left corner of the > screen. It seems to be about 32x120 pixels. Does anyone know what > the problem is? Could it be a bad ram chip? I don't see anything > wrond in AmigaDos, although I do get strange things when I use > XiPaint, especially when my 32-bit memory is running low. > Nah, that's the sprite.. Xretina seems to enable it, but doesn't further set it up, or even support. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 17 12:23:47 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Audio and Floppy drivers" (Feb 15, 11:01am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: lkv@mania.robin.de, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Audio and Floppy drivers Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 15, 11:01am, Lutz Vieweg wrote: > Hmm... this sounds as if it were sensible to write an audio-device > for third-party sound cards such as I have... the more I think of > it, the more I like the idea of having a sun-sparc-compatible > /dev/audio... :) Which card you speaking of? Would be a nice idea to have the Rockwell (?) chip of the Sparc in an Amiga anyway :) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 17 13:59:10 1994 From: v17@aarhues.dk To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Subject: Re: SCSI-controller? Cc: amiga@sun-lamp.cs.berkeley.edu <9402170250.AA29406@gemini.oscs.montana.edu> X-Mts: smtp X-Charset: ASCII X-Char-Esc: 29 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >> Hm, 4091 would probably be the best choice, but it's not (yet?) supported >> under NetBSD. We do have similar drivers, so supporting it shouldn't probably > I could probably add the 4091 support easily if I knew the offset of > the 53C710 registers, and knew the correct values to program the 53C710. > Also, NetBSD doesn't currently have any provisions for Zorro III devices, > but that should be very easy to add. Please keep me posted on your progress, A4091 is really my preferred choice of a new SCSI controller.. If I can get my hands on one :-) >> do DMAs larger than 512 byte or so.. There is also support for a ZEUS >> controller, don't ask me any details about that one, I just know it must >> exist because we got a driver for it:-) > The Zeus controller is the onboard Fast SCSI-2 controller (also using > the 53C710) on the Progressive Peripherals Inc Zeus 68040 accelerator > board. Anybody knows anyone who want's to swap their A3000 with a PPZeus 040 for my A4040?? :-) /Michael From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 17 17:06:30 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: SCSI-controller? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 17, 10:24am, Olaf Seibert wrote: > Michael Kofod wrote: > > I finally decided to try out NetBSD yesterday, but it did not like > > booting from my BOIL-SCSI controller.. > > For the record: I also have a BOIL3 scsi controller (in my 2000, not > in my 4000). It is basically the hardware of a Supra Wordsync (aside: > I thought that word was trademarked by commodore, or somesuch) > with different firmware (it now supports autobooting and RigidDisk > Blocks, and a harddisk password, for instance). If the BOIL3 scsi controller uses the 5380 chip like the Supra Wordsync, it shouldn't be too hard to add support for it on NetBSD. I have a Supra Wordsync in a second machine that I was able to boot NetBSD with. The Supra support is rather elementry at the momement, but I am still working in it. I can add support for other 5380-type controllers with just a little basic information (although it's sometimes hard to come by). I need to know the Manufacturer and Product codes of the board, the locations of the 5380 registers (relative to the start of the board address), and optionally any available information on psuedo-DMA access used by the board (or information on real DMA if the board uses it). Michael From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 17 17:21:14 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: SCSI-controller? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 17, 1:17pm, v17@aarhues.dk wrote: > >> do DMAs larger than 512 byte or so.. There is also support for a ZEUS > >> controller, don't ask me any details about that one, I just know it must > >> exist because we got a driver for it:-) > > > The Zeus controller is the onboard Fast SCSI-2 controller (also using > > the 53C710) on the Progressive Peripherals Inc Zeus 68040 accelerator > > board. > > Anybody knows anyone who want's to swap their A3000 with a PPZeus 040 > for my A4040?? :-) The PPI Zeus is only for the A2000, but PPI also made a couple of 040 board for the A3000 (the Mecury was the second one). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 18 10:55:11 1994 From: Alain Chofardet Subject: Emacs To: amiga@sun-lamp.cs.berkeley.edu (Mailing List NetBSD) Mailer: Elm [revision: 72.14] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi. I'd like to reach the person who compiled Emacs for NetBSD. I have some questions to ask him (her, maybe ? ... No hopes). Thanks for answering directly to chofarde@scinfo.u-nancy.fr Alain. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 18 11:38:19 1994 From: Olaf Seibert To: amiga@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: SCSI-controller? Sender: owner-amiga@sun-lamp.cs.berkeley.edu osymh@gemini.oscs.montana.edu (Michael L. Hitch) wrote: > If the BOIL3 scsi controller uses the 5380 chip like the Supra Wordsync, > it shouldn't be too hard to add support for it on NetBSD. I have a Supra > Wordsync in a second machine that I was able to boot NetBSD with. The > Supra support is rather elementry at the momement, but I am still working > in it. I can add support for other 5380-type controllers with just a > little basic information (although it's sometimes hard to come by). I > need to know the Manufacturer and Product codes of the board, the locations > of the 5380 registers (relative to the start of the board address), and > optionally any available information on psuedo-DMA access used by the board > (or information on real DMA if the board uses it). Manufacturer and product code are simple: the same as an original wordsync: SysInfo tells me that I have a wordsync; the text on the card tells me it's a wordsync, and the manual tells me that the hardware is a wordsync. The only difference (though an important one from a user- interface point of view) is the EPROM that's on it. And the installation software. But I presume that both of those are completely irrelevant, since we're going to bang on the hardware. I would therefore presume that from a NetBSD point of view, the BOIL is indistinguishable from a 'real' wordsync. Now if you would get the wordsync to work, I'll have to decide if I want to use my 2000 diskless until IDE support magically appears. On the other hand, IDE support might get there quicker since I'll be able so spend some time on it (not as much as I'd like probably, though). And I'll be able to copy the whole 105M on the wordsync to the big ide disk, and use ParNFS to serve the 2000 ... yes, this seems like a good idea! > Michael -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ There are no lemurs in this post rhialto@mbfys.kun.nl From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 18 14:08:49 1994 From: v17@aarhues.dk To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: SCSI-controller? X-Mts: smtp X-Charset: ASCII X-Char-Esc: 29 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 17 1994, Michael L. Hitch wrote: > > For the record: I also have a BOIL3 scsi controller (in my 2000, not > > in my 4000). It is basically the hardware of a Supra Wordsync (aside: > > I thought that word was trademarked by commodore, or somesuch) > > with different firmware (it now supports autobooting and RigidDisk > > Blocks, and a harddisk password, for instance). > If the BOIL3 scsi controller uses the 5380 chip like the Supra Wordsync, > it shouldn't be too hard to add support for it on NetBSD. I have a Supra > Wordsync in a second machine that I was able to boot NetBSD with. The > Supra support is rather elementry at the momement, but I am still working > in it. I can add support for other 5380-type controllers with just a > little basic information (although it's sometimes hard to come by). I > need to know the Manufacturer and Product codes of the board, the locations > of the 5380 registers (relative to the start of the board address), and > optionally any available information on psuedo-DMA access used by the board > (or information on real DMA if the board uses it). I'll have a look at my Boil controller in the weekend, and email back the chip info. to you, if you want to have a go at it. It would really be nice to avoid getting a new SCSI controller right away.. I'm not sure how to get the register locations, but the Product and Manufactur codes shouldn't take long to find.. The Boil3 doesn't use DMA, and I dont think it has the pseudo DMA of the Supras neither.. If theres any other info that I might suply please let me know.. /Michael From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 18 14:15:24 1994 From: Eric Glanz - Unix Support Subject: Tape drive lockup... To: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: IN%"amiga@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga@sun-lamp.cs.berkeley.edu Now that I finally got NetBSD up, my tape drive seems to lock up for no apparent reason. What happens is, while using tar to extract files from the tape, the rive seems to never let go of the scsi bus after a while of usage. I upgraded to a rev 8 scsi chip thinking that this would solve the problem, but it did not. BTW - The tape drive works fine on the AmigaDOS side. Here is my hardware configuration: A3000T 5 meg ram Tandberg TDC3600 tape drive 200 meg hitachi dk312c HD Any ideas? --Eric Glanz From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Feb 18 15:44:55 1994 From: "Andreas E. Heitmann" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Floptical support Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi BSDers ! I just hacked a patch to make Floptical drives usable under NetBSD. Currently this is tested with the IOMEGA Io20S Floptical, but it should work with the Insite Floptical, too. It works by requesting the vendor page 0x2E with the MODE_SENSE command to unlock the drive (make it writable) and rezeroing it before the first READ command takes place. The patches are for the #744 versions of files sd.c and scsi.c. I added routines for requesting a a mode page and to issue a REWIND command to a unit (did you ever rewind your harddisk ? ;)) There is also some debug code left in the functions, you can leave it out. To try the patch with the Insite Floptical, you have to fix the vendor and device IDs in sdinit.c, because I don't know them for the Insite. If you have a Insite Floptical, please report back these IDs. Ok, here we go... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% *** sd.c Sun Jan 16 15:11:44 1994 --- /usr/src/sys/arch/amiga/dev/sd.c Fri Feb 18 05:30:30 1994 *************** *** 79,84 **** --- 79,85 ---- extern int sdioctl (dev_t dev, int cmd, caddr_t data, int flag, struct proc *p); extern int sdsize (dev_t dev); extern int sddump (dev_t dev); + extern int scsi_unlock_floptical(int ctlr, int slave, int unit); static int sdident (struct sd_softc *sc, struct amiga_device *ad); static void sdlblkstrat (register struct buf *bp, register int bsize); static int sderror (int unit, register struct sd_softc *sc, register struct amiga_device *am, int stat); *************** *** 352,357 **** --- 353,377 ---- sc->sc_blks <<= sc->sc_bshift; } sc->sc_wpms = 32 * (60 * DEV_BSIZE / 2); /* XXX */ + + + /* unlock FLOPTICAL */ + + if (!bcmp(&sc->sc_idstr[0],"IOMEGA",6) && + !bcmp(&sc->sc_idstr[8],"Io20S",5)) { + int stat; + + printf("Floptical drive detected, trying to unlock..."); + stat=scsi_unlock_floptical(ctlr,slave,unit); + if(stat!=0) { + printf("unlock failed: %d\n",stat); + sderror(unit,sc,sc->sc_ad,stat); + } + else { + printf("success.\n"); + } + } + scsi_delay(0); return(inqbuf.type); failed: *************** *** 424,430 **** { if (scsi_tt_read (ad->amiga_ctlr, ad->amiga_slave, sc->sc_punit, (char *) block, DEV_BSIZE, bnum, sc->sc_bshift)) - /* read error on block */ goto no_rdb; if (rdb->rdb_ID == IDNAME_RIGIDDISK) --- 444,449 ---- *************** *** 827,833 **** printf("sd%d: scsi sense class %d, code %d", unit, sp->class, sp->code); if (sp->class == 7) { ! printf(", key %d", sp->key); if (sp->valid) printf(", blk %d", *(int *)&sp->info1); switch (sp->key) { --- 846,857 ---- printf("sd%d: scsi sense class %d, code %d", unit, sp->class, sp->code); if (sp->class == 7) { ! printf(", key %d",sp->key); ! if(sp->len>=6) { ! printf(", sensecode %d, sensequal %d", ! (sdsense[unit].sense)[12], ! (sdsense[unit].sense)[13]); ! } if (sp->valid) printf(", blk %d", *(int *)&sp->info1); switch (sp->key) { %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% *** scsi.c Sat Jan 1 16:52:19 1994 --- /usr/src/sys/arch/amiga/dev/scsi.c Fri Feb 18 05:20:01 1994 *************** *** 77,84 **** static int scsiicmd (struct scsi_softc *dev, int target, u_char *cbuf, int clen, u_char *buf, int len, u_char xferphase); static void finishxfer (struct scsi_softc *dev, register volatile sbic_padded_regmap_t *regs, int target); static int check_dma_buf (char *buffer, u_long len); - /* * SCSI delays * In u-seconds, primarily for state changes on the SPC. --- 77,85 ---- static int scsiicmd (struct scsi_softc *dev, int target, u_char *cbuf, int clen, u_char *buf, int len, u_char xferphase); static void finishxfer (struct scsi_softc *dev, register volatile sbic_padded_regmap_t *regs, int target); static int check_dma_buf (char *buffer, u_long len); + static int scsi_mode_sense(int ctlr, int slave, int unit, int page, u_char *buf, unsigned len); + static int scsi_rezero_unit(int ctlr, int slave, int unit); /* * SCSI delays * In u-seconds, primarily for state changes on the SPC. *************** *** 186,192 **** } /* default to not inhibit sync negotiation on any drive */ ! u_char inhibit_sync[NSCSI][8] = { 1, 1, 1, 1, 1, 1, 1 }; /* initialize, so patchable */ int scsi_no_dma = 0; #ifdef DEBUG --- 187,193 ---- } /* default to not inhibit sync negotiation on any drive */ ! u_char inhibit_sync[NSCSI][8] = { 1, 1, 1, 1, 0, 0, 0 }; /* initialize, so patchable */ int scsi_no_dma = 0; #ifdef DEBUG *************** *** 1291,1296 **** --- 1292,1322 ---- } int + scsi_mode_sense(ctlr, slave, unit, page, buf, len) + int ctlr, slave, unit; + int page; + u_char *buf; + unsigned len; + { + register struct scsi_softc *dev = &scsi_softc[ctlr]; + static struct scsi_cdb6 cdb = { CMD_MODE_SENSE }; + cdb.lun = unit; /* we do not disable the block descriptor */ + cdb.lbam= page; + cdb.len = len; + return (scsiicmd(dev, slave, (u_char *)&cdb, sizeof(cdb), buf, len, DATA_IN_PHASE)); + } + + int + scsi_rezero_unit(ctlr, slave, unit) + int ctlr, slave, unit; + { + register struct scsi_softc *dev = &scsi_softc[ctlr]; + static struct scsi_cdb6 cdb = { CMD_REWIND }; + cdb.lun = unit; + return (scsiicmd(dev, slave, (u_char *)&cdb, sizeof(cdb), (char *)0,0, STATUS_PHASE)); + } + + int scsi_immed_command(ctlr, slave, unit, cdb, buf, len, rd) int ctlr, slave, unit; struct scsi_fmt_cdb *cdb; *************** *** 1303,1308 **** --- 1329,1412 ---- return (scsiicmd(dev, slave, (u_char *) cdb->cdb, cdb->len, buf, len, rd != 0? DATA_IN_PHASE : DATA_OUT_PHASE)); } + + /* + * scsi_unlock_floptical() + * + * Unlocks a floptical drive by reading the vendor + * mode page 0x2e (floptical page). In addition a rezero + * unit command is issued, because the first READ command + * fails with a "Servo Hardware Fault" error + * (ASC=2,ASCQ=0). The rezero command will also fail, but + * now we can ignore it. + */ + int + scsi_unlock_floptical(ctlr, slave, unit) + int ctlr; + int slave; + int unit; + { + struct mp_header_s { + u_char mode_data_length; + u_char media_type; + u_char block_descriptor_length; + }; + + struct mp_descriptor_s { + u_char reserved[4]; + u_char block_length[4]; + }; + + struct floppage_s { + u_char reserved1:1, + pagecode:7; + u_char len; + u_char reserved2; + u_char hamheads; + u_char secpertrack; + u_short bytespersector; + u_short hamcyls; + u_char reserved3:4, + ejm:1, + reserved4:2, + nhf:1; + u_char idstr[13]; + u_char reserved5[6]; + }; + + struct sense_return_s { + struct mp_header_s mp_header; + struct mp_descriptor_s mp_descriptor; + struct floppage_s floppage; + } sr; + + int stat; + + stat=scsi_mode_sense(ctlr,slave,unit,0x2e,(u_char *)&sr,sizeof(sr)); + + #ifdef DEBUG + if(stat==0) { /* print some information in the floptical page */ + printf("Floptical information\n"); + printf("Page code : %d\n",sr.floppage.pagecode); + printf("Page length : %d\n",sr.floppage.len); + printf("Number of HAM heads: %d\n",sr.floppage.hamheads); + printf("Sectors per Track : %d\n",sr.floppage.secpertrack); + printf("Data Bytes/Sector : %d\n",sr.floppage.bytespersector); + printf("Number of HAM cyls : %d\n",sr.floppage.hamcyls); + printf("Eject Motor : %d\n",sr.floppage.ejm); + printf("Non-HAM format : %d\n",sr.floppage.nhf); + printf("IdString : %s\n",sr.floppage.idstr); + } + #endif + + if(stat==0) { + stat=scsi_rezero_unit(ctlr,slave,unit); + if(stat==2) stat=0; /* explicitly ignore servo fault errors */ + } + return stat; + } + + /* * The following routines are test-and-transfer i/o versions of read/write %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% That's it. Bye, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 18 15:58:23 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Tape drive lockup..." (Feb 18, 12:10am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Eric Glanz - Unix Support , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Tape drive lockup... Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 18, 12:10am, Eric Glanz - Unix Support wrote: > Any ideas? Not really, other than that tape drives _do_ lock the scsi-bus, but you are right, they should release the bus after having rewinded the tape. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 18 17:05:08 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: SCSI-controller? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 18, 11:14am, Olaf Seibert wrote: > Manufacturer and product code are simple: the same as an original > wordsync: SysInfo tells me that I have a wordsync; the text on the card > tells me it's a wordsync, and the manual tells me that the hardware is > a wordsync. The only difference (though an important one from a user- In that case, I would guess that the product code is 12? My Wordsync has a product code of 12 and I am able to read from the disk with NetBSD. I haven't added the psuedo-DMA stuff to the Supra driver yet, but will probably do that this weekend. That should speed up access considerably. > interface point of view) is the EPROM that's on it. And the installation > software. But I presume that both of those are completely irrelevant, > since we're going to bang on the hardware. I would therefore presume > that from a NetBSD point of view, the BOIL is indistinguishable from > a 'real' wordsync. If the 5380 registers are at the same location, and the pseudo-DMA works the same way, then it should work find with my driver. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 18 22:04:31 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: 744 kernel re-compilation To: amiga@sun-lamp.cs.berkeley.edu (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 451 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello, could someone send me the compilation instructions that guided to compile 744 kernel sources? I compiled the kernel once succesfully (and that is the kernel that I am currently running), but I did some modifications and can't get a working kernel anymore. At least a file amiga/trap.c needs a define SYS_sun_sigreturn, but what was the correction for this (I need SunOS emulation). I am also hoping to compile a kernel for gdb-4.11.. ++Tero From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 19 00:10:53 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: 744 kernel re-compilation To: tero.manninen@oulu.fi (Tero Manninen) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1936 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > could someone send me the compilation instructions that guided to compile > 744 kernel sources? I compiled the kernel once succesfully (and that is the > kernel that I am currently running), but I did some modifications and can't > get a working kernel anymore. At least a file amiga/trap.c needs a define > SYS_sun_sigreturn, but what was the correction for this (I need SunOS > emulation). I am also hoping to compile a kernel for gdb-4.11.. I finally managed to compile a 744 kernel (don't froget Chris Hopps patch). What I did about the SYS_sun_sigreturn was go into the file sys/compat/sunos/syscalls.master and change "sigreturn" to "sun_sigreturn". Then to make the cange work, type: sh makesyscalls.sh syscalls.master On a slightly different matter, I SUP'ed the latest kernel sources from sun-lamp, and after considerable effort managed to get them to compile and link. I was extremely annoyed to discover that both the retina and tiga drivers (Ha!) are hard wired into ite.c. There is also a typo in sd.c, where MAKEBOOTDEV is spelled "MAKEBOOTOADEV". Most of the .S files in /sys/lib/libkern/m68k are missing. Finally, I discovered that the kernel will not boot on my machine. It will not even try to boot. All I get is a blank gray screen. What's going on with the sources on sun-lamp? I would like to do some development work on the kernel, so I can add some features to my X server. However, the alegedly latest sources just don't work. I 744 already has several patches generated against it by several different people. If I start doing this too, integrating all the patches together will be a nightmare. How are we going to handle this? Where do I get a current baseline to start working from? ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 19 02:14:28 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: 744 kernel re-compilation To: eeh@btr.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: tero.manninen@oulu.fi, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1596 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > On a slightly different matter, I SUP'ed the latest kernel sources > from sun-lamp, and after considerable effort managed to get them to Compiles out-of-the-box, over here. > compile and link. I was extremely annoyed to discover that both the > retina and tiga drivers (Ha!) are hard wired into ite.c. There is It has always been this way. > also a typo in sd.c, where MAKEBOOTDEV is spelled "MAKEBOOTOADEV". Yes I caught that too. > Most of the .S files in /sys/lib/libkern/m68k are missing. Finally, I No they are not, the're in lib/lib/arch/m68k. > discovered that the kernel will not boot on my machine. It will not > even try to boot. All I get is a blank gray screen. What's going on > with the sources on sun-lamp? Your running with an old loadbsd I posted more than once about this. Whats going on with the sources on sun-lamp, is development, if you wish to be annoyed it should be entirely with yourself for not keeping track of the moving target. > I would like to do some development work on the kernel, so I can add > some features to my X server. However, the alegedly latest sources > just don't work. I 744 already has several patches generated against > it by several different people. If I start doing this too, > integrating all the patches together will be a nightmare. How are we > going to handle this? Where do I get a current baseline to start > working from? You seem like you have an atituede, is this this case or am I misreading you? If its atitude you've got then cool down and fix *your* mistakes. > Eduardo Horvath eeh@btr.com Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 19 02:27:50 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: 744 kernel re-compilation Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 18, 7:56pm, Chris Hopps wrote: > > Most of the .S files in /sys/lib/libkern/m68k are missing. Finally, I > > No they are not, the're in lib/lib/arch/m68k. Ummm... how about lib/libc/arch/m68k? Michael From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 19 09:02:04 1994 From: "William J. Coldwell" To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: 744 kernel re-compilation Sender: owner-amiga@sun-lamp.cs.berkeley.edu Begin forwarded message: In this corner: chopps@emunix.emich.edu (Chris Hopps) [Eduardo said:] >> discovered that the kernel will not boot on my machine. It will not >> even try to boot. All I get is a blank gray screen. What's going on >> with the sources on sun-lamp? >Your running with an old loadbsd I posted more than once about this. The date of the one on sun-lamp in the ~/stand/loadbsd is Feb 11.. you should be building this one, I believe, and it should always contain the latest working one. >Whats going on with the sources on sun-lamp, is development, if you >wish to be annoyed it should be entirely with yourself for not keeping >track of the moving target. Generally though, the latest version that is checked in, should work.. Any patches, should be applied to the source tree as soon as possible so that we don't have multiple versions being created, and so-and-so doesn't have patch x, so they post here asking the same questions. The only way this is going to happen, is if people get patches to Chris as soon as verified. For the record though, Chris has done a wonderful job of keeping sun-lamp archives up to date. -- William J. Coldwell | Intel Corp. CPD-Mobile | "Get Warped!" billc@cryo.rain.com | billc@elite.intel.com | Warp Engine: Macrosystems US Cryogenic Software | Work(4), !(speak(4)) | 040@40, SCSI2, 128M@4/2/2/2 From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 19 18:01:58 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: 744 kernel re-compilation Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 18, 11:47pm, "William J. Coldwell" wrote: > > Begin forwarded message: > > In this corner: chopps@emunix.emich.edu (Chris Hopps) ... > >Whats going on with the sources on sun-lamp, is development, if you > >wish to be annoyed it should be entirely with yourself for not keeping > >track of the moving target. > > Generally though, the latest version that is checked in, should work.. Any > patches, should be applied to the source tree as soon as possible so that we > don't have multiple versions being created, and so-and-so doesn't have patch > x, so they post here asking the same questions. The only way this is going > to happen, is if people get patches to Chris as soon as verified. There is also this little disclaimer in the README.sup file: --- IMPORTANT!! Be aware that the current release is simply a snapshot of the daily state of NetBSD development and is not guaranteed to build (or even work) - use at your own risk ! Stable releases of NetBSD are available via SUP. Instructions are included with the release announcement. --- I'm not certain what the stable release of NetBSD is, but I would guess that it's the 0.8 and 0.9 releases. > For the record though, Chris has done a wonderful job of keeping sun-lamp > archives up to date. I'll second that. I suspect it's a lot of work, particularly the task of getting all the work we've done merged into the sun-lamp stuff initially. Trying to keep the amiga tree up to date with any changes in the rest of the kernel could take some effort at times. I hope Chris can keep up the good work. Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Feb 19 19:55:18 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 1.18) X-Charset: iso-8859-1 From: lkv@mania.RoBIN.de (Lutz Vieweg) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Audio and Floppy drivers Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi Markus Illenseer, on Feb 17 you wrote: > On Feb 15, 11:01am, Lutz Vieweg wrote: > > Hmm... this sounds as if it were sensible to write an audio-device > > for third-party sound cards such as I have... the more I think of > > it, the more I like the idea of having a sun-sparc-compatible > > /dev/audio... :) > > Which card you speaking of? Oh, can't you guess it? :) - It's the Toccata from MacroSystem, of course... (using the SoundPort[TM] chip from Analog Devices). But of course this device is currently only an idea of mine, I won't start it before the Retina Z3 drivers are up and running. cu, Lutz Vieweg From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 19 21:24:46 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com [note: this is the first post from this service, and there were a few problems getting it set up right. Plus, I had /var fill up, causing some messages to get dropped on the floor, and then the machine was down for a bit and missed the cron job, so I had to run the weekly program manually... I hope it'll work a little better next week :-> --Ty] --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev/grf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev/grf Removed Files: grf_bitmap.h grf_colormap.h grf_draw.h grf_mode.c grf_mode.h grf_monitor.c grf_monitor.h grf_types.h grf_view.c grf_view.h grfcc.c Log Message: relocated to dev/grfabs{.c,_reg.h} files. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev/grf/grf_cc In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev/grf/grf_cc Removed Files: grf_cc_a2024_mode.c grf_cc_custom.h grf_cc_global.c grf_cc_h_mode.c grf_cc_hdl_mode.c grf_cc_hl_mode.c grf_cc_mode.c grf_cc_pal_a2024_mode.c grf_cc_ph_mode.c grf_cc_phdl_mode.c grf_cc_phl_mode.c grf_cc_priv.h grf_cc_view.c grf_ccc.c Log Message: relocated into dev/grfabs_cc{.c,glb.c,reg.h} files. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/conf Modified Files: Makefile.amiga files.amiga Log Message: chnaged to handle new (and removed) files. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: a2091dma.c a3000dma.c event.c grf.c grf_cc.c grf_rt.c grf_tg.c gvp11dma.c if_le.c ite.c ite_cc.c ite_rt.c kbd.c kbdmap.c ms.c par.c rtclocka.c rtclockb.c scsi.c scsidefs.h sd.c ser.c siop.c st.c view.c viewioctl.h Added Files: grfabs.c grfabs_cc.c grfabs_ccglb.c grfabs_ccreg.h grfabs_reg.h Log Message: cleaned up include's relocated grf/* stuf to grfabs*. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/doc In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/doc Added Files: CHANGES Removed Files: README.CHOPPS-CONSOLE README.CHOPPS-CONSOLE2 Log Message: added local CHANGES file for things that would not interest NetBSD in general. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/sys In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/sys Modified Files: disklabel.h Log Message: Changed amiga MAXPARTITIONS to 16. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/amiga Modified Files: Locore.c amiga_init.c autoconf.c cc.c cc.h cia.c clock.c cons.c disksubr.c dkbad.c dlists.c genassym.c locore.s machdep.c mem.c pmap.c swapgeneric.c sys_machdep.c trap.c vm_machdep.c Removed Files: cc_2024.c cc_2024.h cc_audio.c cc_audio.h cc_blitter.c cc_blitter.h cc_chipmem.c cc_chipmem.h cc_copper.c cc_copper.h cc_types.h cc_vbl.c cc_vbl.h pte.h Log Message: merged most cc_* (all but one) into cc.c and cc.h, cleaned up include. removed local pte.h use machine/pte.h --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/lib/libkvm In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/lib/libkvm Modified Files: Makefile kvm.c Log Message: temporary additional lookup of cpu040 for amiga's until new kvm stuff or new amiga 040 VM stuff. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: st.c Log Message: moved n "}" outside of conditional DEBUG --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/sbin/reboot In directory sun-lamp.cs.berkeley.edu:/usr/src/sbin/reboot Modified Files: reboot_amiga.8 reboot_hp300.8 reboot_i386.8 reboot_mac68k.8 reboot_sparc.8 Log Message: U* to NetBSD, as appropriate --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/conf Modified Files: Makefile.amiga files.amiga Log Message: modified to use generic cons. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/doc In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/doc Modified Files: CHANGES Log Message: latest changes indicated. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/include Modified Files: vmparam.h Log Message: amiga now has USRSTACK at 0x0e000000 for further sun compat. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/amiga Modified Files: color.h conf.c Added Files: kdassert.h Removed Files: cons.c cons.h Log Message: modified to use generic cons, added kernel assert macro. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: grf.c grf_rt.c grfabs_ccglb.c ite.c ite_cc.c ite_rt.c ite_tg.c itevar.h kbd.c ser.c view.c Log Message: modified to use generic cons. (and some grf defs changed) --------------------------------- From: deraadt@fsa.ca (Theo Deraadt) > amiga now has USRSTACK at 0x0e000000 for further sun compat. I don't get why this is needed. Please explain. --------------------------------- From: chopps@emunix.emich.edu (Chris Hopps) > > > amiga now has USRSTACK at 0x0e000000 for further sun compat. > > I don't get why this is needed. Please explain. Ask Markus its his change, I didn't argue about it much becuase for the most part it is cosmetic. Chris. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: sd.c Log Message: fix typo. --------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Sun Feb 20 22:24:29 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "This week's NetBSD/amiga changes" (Feb 19, 1:31pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 19, 1:31pm, Operator wrote: > Subject: This week's NetBSD/amiga changes [...] Do i understand it correctly that the most up-to-date kernel sources can be found on sun-lamp then? All Amiga-specific changes incorporated/added? -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 21 01:26:24 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Looking for new kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm trying to build a new kernel from the 19 Feb sun-lamp sources. It compiles "correctly", but when I do a "cp vmunix /dev/reload", all I get is a grey screen. I'm using the loadbsd-current from eunet. [This is with the 19 Feb version of everything; cc, ld, sh, ...] Can someone point me in a direction for where I can look for the problem, or better yet, upload a new "generic" kernel to eunet? [I know that at least Chris Hopps is working on this....] Thanks, -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 21 02:02:42 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Looking for new kernel To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1307 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I'm trying to build a new kernel from the 19 Feb sun-lamp sources. > > It compiles "correctly", but when I do a "cp vmunix /dev/reload", > all I get is a grey screen. I'm using the loadbsd-current from > eunet. [This is with the 19 Feb version of everything; cc, ld, sh, ...] I compiled you A3000 and also cannot cp vmunix /dev/reload. However I am able to boot this kernel if I loadbsd it. > Can someone point me in a direction for where I can look for the > problem, or better yet, upload a new "generic" kernel to eunet? > [I know that at least Chris Hopps is working on this....] Yes I looked at the (significant amount BTW) of options that I had compared with yours since my /dev/reload works. Here is the list of options I have and you don't (in A3000) the list is sorted in the order in which I think problems may arise, i.e. the first one is most suspect: DEBUG PANICWAIT NFS NFSSERVER NFSCLIENT ISOFS FDESC PORTAL BANKDEVPAGER GRF GRF_OCS GRF_PAL GRF_A2024 GRF_CUSTOM_CHIP_MODES (I don't know if I ever used this) HAVE_USL_UFS (I am gonna grep this to see if its even neeeded) LKM (I know this isn't it, becuase I just added it) Note though that I use the old ld to link my kernels and am unaware if the new one works. (kernel-ld on my system is ld.old from the last bin dist) Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 21 10:04:57 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Strange kernel problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I've built both a kernel derived from the 940213 sources at sun-lamp as well as one from 940220. Both behave well at first, but after some time, presumably after a certain amount of paging (I still run in 4MB!), all I can do is to execute bash internal commands. Every other command results in "ls: is a directory" type of messages. I haven't seen anything on current-users so I suspect it's Amiga-specific (or do all PC NetBSDers have a reasonable amount of memory?). Has anoyone tried late versions on low-mem Amigas? Typically starting emacs and stopping it (C-z) is enough to start this behaviour (well, I have never succeeded to do this anyway). There does not seem to be memory corruption going on, all in-core images run fine, it's just that I cannot start any new programs. Another note: as soon as I can get to compile a new kernel, I'll try my ADOSFS as a LKM, it really seems dead simple!! BTW those of you who use late sun-lamp code *need* to recompile disklabel & newfs again as MAXPARTITIONS has changed once more. Apart from my problems, it's great that we're on sun-lamp now, thanks Chris! Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 21 11:02:52 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Strange kernel problems To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1565 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I've built both a kernel derived from the 940213 sources at sun-lamp > as well as one from 940220. Both behave well at first, but after some > time, presumably after a certain amount of paging (I still run in 4MB!), > all I can do is to execute bash internal commands. Every other command > results in "ls: is a directory" type of messages. I haven't seen anything > on current-users so I suspect it's Amiga-specific (or do all PC NetBSDers > have a reasonable amount of memory?). Has anoyone tried late versions on > low-mem Amigas? Typically starting emacs and stopping it (C-z) is enough > to start this behaviour (well, I have never succeeded to do this anyway). > There does not seem to be memory corruption going on, all in-core images > run fine, it's just that I cannot start any new programs. Hmm, I don't know but I am beginning to think that maybe the later model gcc's (2.5.x) do something more with the kernel when compiled with -02, try and change that to -O only and see if that clears anything up. I run with 2.4.5 all the time now so I can't check. > Another note: as soon as I can get to compile a new kernel, I'll try my > ADOSFS as a LKM, it really seems dead simple!! Yeah I looked at the syscall stuf it seemed to work pretty cleanly. Really looking forward to ADOSFS. :^) Thanks! > BTW those of you who use late sun-lamp code *need* to recompile disklabel > & newfs again as MAXPARTITIONS has changed once more. Right, I don't think anyone relized that 32 partitions made the disklabel struct 660 bytes :^) > Niklas Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 21 19:52:20 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Bug-Reports To: s_grau@ira.uka.de (Guenther Grau) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 533 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > As you can see, there are different groups. Maybe we have to > create a new group for port-amiga, for Amiga-specific bugs, but > the rest should work just fine. IMHO it is very important to keep > track of all the bugs, because sometimes I don't know if a certain > bug is already fixed or if it is still existant. > > What do you think about this? I will look into if we need to set anything up. It would be great I think to have an port-amiga section in the bugs list. > Guenther (s_grau@ira.uka.de, Maeuschen@irc) Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 21 20:07:34 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Strange kernel problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 21, 9:54am, Niklas Hallqvist wrote: > BTW those of you who use late sun-lamp code *need* to recompile disklabel > & newfs again as MAXPARTITIONS has changed once more. I think programs that rely on knowing the location of the top of the user stack (USRSTACK) need to be recompiled, also. Two specific examples are nfsd and ps. Nfsd tries to modify the command line arguments and ps is getting the command line arguements. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 21 20:36:43 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Bug-Reports From: Guenther Grau Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, now that the reintegration of the changes to the Amiga-tree back into the NetBSD-current sources is done on a regular basis (a BIG thanx to Chris Hopps for that :-) I think, that we should also use the netbsd-bugs list, so that everybody can get the current-bug list from gnats@sun-lamp.cs.berkeley.edu (if this address is still valid). Here is a recent output: Date: Thu, 17 Feb 1994 05:20:35 -0800 From: Bugs Galore Message-Id: <199402171320.FAA19141@sun-lamp.cs.berkeley.edu> To: Guenther Grau Subject: query-pr output [--summary] 5 kern-bug kern open serious medium net getgroups/setgroups system call should use gid_t * for gidset type. 6 kern-bug kern open serious medium net chown system call uses uid_t, gid_t args while fchown still uses ints. 10 jtc lib open non-criti low net There are no manual pages for the yp clients. 13 jtc lib analyzed serious medium net getopt(3) should handle wide characters intelligently 20 gnats-ad lib open non-criti low net div_t and ldiv_t types should be moved to 31 gnats-ad kern open serious medium net Need sysconf() 32 gnats-ad kern open serious medium net Need pathconf() & fpathconf() 39 gnats-ad bin open critical low net xntp tries to locate all interfaces, but structure changed 41 gnats-ad kern open non-criti low net The old PS/2 mouse driver is buggy. Replace! 49 gnats-ad lib open non-criti low net Curses documentation placed wrong 66 gnats-ad port-i38 feedback serious medium net Need to merge SMC8216 support into ed device driver 67 mycroft lib analyzed non-criti low net addch in curses lib is not returning ERR 68 gnats-ad kern open serious medium net call through null function ptr in kernel confuses ddb 84 gnats-ad kern open critical high net way MULTICAST is being defined for ISO is broken 89 gnats-ad port-mac open non-criti low net Should make /dev/{modem,printer} 93 gnats-ad bin open non-criti medium net need to upgrade xntpd to current version, would fix bug #39 94 gnats-ad kern open non-criti low net kernel global tickadj should be smaller. 98 gnats-ad kern open serious medium net Semi-hack change to allow diagnosis of call through 0 faults. 99 gnats-ad port-i38 feedback serious medium net promiscuous mode doesn't work with (relatively) new if_ed 105 gnats-ad bin open critical high net usr.bin/mail does not obey the spool file locking protocol 106 jtc misc analyzed serious medium net pwd_mkdb fails due to hard coded paths used 109 gnats-ad kern open serious medium net msdosfs truncates files 110 jtc lib feedback serious medium net re_comp/re_exec in libcompat don't work 112 gnats-ad port-i38 open serious medium net /dev/sound with SBPRO hangs 113 gnats-ad kern feedback serious medium net mmapping /dev/vga returns EINVAL 117 gnats-ad lib feedback non-criti medium net setmode(3) doesn't work 118 gnats-ad port-i38 open critical high net non-SCSI (AT/IDE style) hard disks get badly corrupted at times. 123 gnats-ad bin suspended non-criti medium net awk dumps core on empty command string 126 gnats-ad bin open non-criti medium net compiling wd.c with optimizations can cause cc1 crash 127 gnats-ad port-i38 open critical medium net npx driver's resets may hang some systems 130 gnats-ad misc feedback non-criti low net termcap database build with output redirected fails As you can see, there are different groups. Maybe we have to create a new group for port-amiga, for Amiga-specific bugs, but the rest should work just fine. IMHO it is very important to keep track of all the bugs, because sometimes I don't know if a certain bug is already fixed or if it is still existant. What do you think about this? Guenther (s_grau@ira.uka.de, Maeuschen@irc) P.S.: While I am at it, I have uploaded new versions of the projects and the wish-list. Please send any comments, complaints or whatever to me. Please also report on what projects you are working to avoid people working on the same project without knowing from each other. Thanx From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 00:35:59 1994 From: luebberw@lp.musc.edu To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Compiling Sun-Lamp Sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I am using GCC 2.5.8 to compile the 021994 sun-lamp sources. I am setting the flag -static as suggested by Marcus. Everything compiles just jim-dandy until the kernel is built, and then I get: locore.s: String table error or something like that. Anyone else had this problem? I am using the new config and the "AMIGA" configuration file in sys/arch/amiga/conf. Compiling without -static using 2.5.8 does NOT generate the problem, but then again, the kernel doesn't load with a cp vmunix /dev/reboot. Yes, I AM using the new loadbsd. R. Luebbert From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 01:36:48 1994 From: Bob Slawson To: chopps@emunix.emich.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Looking for new kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: chopps@emunix.emich.edu (Chris Hopps) > Date: Sun, 20 Feb 1994 19:54:12 -0500 (EST) > Note though that I use the old ld to link my kernels and am unaware if > the new one works. (kernel-ld on my system is ld.old from the last bin dist) loadbsd rejects any kernel I've built with a recent link editor (with LD=ld -Bstatic in the Makefile). I noticed that `file netbsd' linked with `ld -Bstatic -n ....' returns (this is from memory) NetBSD/m68k pure executable binary whereas when linked with ld.old from the 720 usr.bin old sun-2 pure executable binary `file vmunix.744' also returns "old sun-2 ..." Is there a deep reason why this anachronism is necessary? Are there differences other than the magic numbers? I think it would be convenient to be able to use a current link editor when building kernels rather than keeping a single purpose one around. Robert W. Slawson Dept. of Astronomy, Univ. of Western Ontario, Astronomy is looking up... London, Ontario N6A 3K7 CANADA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 03:22:14 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Compiling sun-lamp sources. To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1058 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu This is a note to all devlopers that are compiling sun-lamp sources. I have switched the amiga kernel linking over to the new ld, you will need an ld that is fairly current if you wish your symbols to not be stripped (it was a bug that was fixed a little while back). the sizeof the struct disklabel changed a little while back so "newfs" and "disklabel" need recompiling. The position of the stack changed so all programs that referece USRSTACK need to be recompiled like ps, w, nfsd, gdb... Yell at Markus about this one :^) As a treat anyone running X can stop redirecting it, I fixed the MMU fault bug. A final note, I try as hard as I can to keep the sources compiling and generating "working" kernels. however I also am chaning the sources everyday adding users patches and my own modifications. If your kernel doesn't run, don't jump into elm and mail me about it, try and figure out whats wrong. If that fails you can post something to the list. Remember the sources you sup are only a snapshot of a costantly moving target. Thanks, Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 03:40:28 1994 Subject: Sup where? (fwd) From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In which directory would I find the source code for sup on sun-lamp? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 03:45:08 1994 Subject: Floptical patches From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I tried the floptical patches posted earlier. Some notes: I have the Insite version. Product ID is "INSITE I325VM". I think that all flopticals have "FLOPTICAL" at sc_idstr[24]. It i unclear what additional functionality the patches give me. I unlock the floptical from AmigaDOS mode. I then boot NetBSD. I find that access to the floptical works fine except that I get a sense error immediately after the media is changed. The patch removes the need to unlock from the AmigaDOS side, but it does not appear to do anything else. Is there something I'm missing? Also, inhibit_sync was patched to clear the last 3 SCSI drives. Good thing I caught that - otherwise my system would lock up. I have a PROTO 3393. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 04:02:53 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Sup where? (fwd) To: dej@eecg.toronto.edu (David Jones) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 202 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > In which directory would I find the source code for sup on sun-lamp? It is in the othersrc/ directory. > David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 08:37:13 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Floppy questions To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1441 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I have a working (read-only) floppy device now. It hasn't been tested much but it seems to be working. It is based on some floppy code I wrote a while ago and the i386 floppy code. I am looking now to try some neat stuff with it like newfs/disklabel/... How does everyone think disklabels should be done? I was thinking to either make a fake one for the whole drive as one partition or actually write out the label to sector 0. How close is the AFFS to being released? Since I can't write to the floppy I'm stuck right now as an AFFS disk. Also what all do I need to do to work towards a bootable floppy system? And finally, as I don't understand the controller/slave setup properly - the device driver is a bit odd. It is configured as: device fp0 at manafacturer 1 product 10 I used fp instead of fd since there is already an fd device. I added the builtin product #10 for my device. Hopefully when I release this someone who understands netbsd better can clean things up a bit... +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 11:01:12 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Compiling sun-lamp sources. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu FYI, I recompiled my sun-lamp based kernel with -O using 2.5.8 GCC but I still got the weird "ls: is a directory" type of messages after a while (although a longer while than before). I have the following questions/requests: A. Has anybody compiled a recent sun-lamp kernel with 2.5.8 and ld.old? Did you do anything special? B. Could people stress their machines to the point the systems start to thrash (start several concurrent compilations and some emacses) and check that the kernel works ok. For those of you still running 744, don't bother, I know that works. C. Is there any point in trying to use the kernel debugger? I know the disassembler cannot work, but otherwise? Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 11:04:34 1994 From: niklas@appli.se (Niklas Hallqvist) To: pepersb@cuug.ab.ca Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floppy questions Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Brad" == Brad Pepers writes: Brad> How close is the AFFS to being released? Since I can't write to Brad> the floppy I'm stuck right now as an AFFS disk. It was and is very close... In fact I had reserved time off from my family the recent weekend for this, but then my kernel started to give me problems and I spent time on that instead. I think I'll do two releases, one for those of you that *really* want it bad, can compile your own kernel and resolve patch conflicts yourself, and one *real* LKM binary+source release sometime later. The former I'll try to get out tonight, I really feel bad about the delay, I do apologize... Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 13:26:22 1994 From: "Andreas E. Heitmann" To: dej@eecg.toronto.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floptical patches Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi ! (I'm the guy who posted the patches for the floptical) >>>>> "David" == David Jones writes: David> The patch removes the need to unlock from the AmigaDOS David> side, but it does not appear to do anything else. Is there David> something I'm missing? The unlocking of the drive is indeed the main functionality of the patch. The drive lock will be a problem when the booting routines for NetBSD are finished or you if don't want to visit AmigaDOS after powering up. The patch also does a rezero_unit to intercept the error resulting from the first read access to the floptical. The IOMEGA didn't work after unlocking the drive, because the RDB was unreadable for this reason. When I unlocked the drive and issued a rezero_unit, everything worked. Maybe this is not necessary for the INSITE drive. David> Also, inhibit_sync was patched to clear the last 3 SCSI David> drives. Good thing I caught that - otherwise my system David> would lock up. I have a PROTO 3393. Sorry, I forgot to remove that from the patches. It's just the default setup for my system. Greetings, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 14:17:46 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Compiling sun-lamp sources." (Feb 22, 9:41am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: niklas@appli.se (Niklas Hallqvist), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Compiling sun-lamp sources. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 22, 9:41am, Niklas Hallqvist wrote: > C. Is there any point in trying to use the kernel debugger? I know the > disassembler cannot work, but otherwise? Sorry, haven't compiled sun-lamp kernel yet, but this point buggers me, too. Currently trying to write a driver for the A2060 Arcnet and all i get is a MMU-Panic yet, i wonder if there is any way to debug a kernel without having to recompile it every 5 minutes after adding a printf() somewhere. -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Feb 22 15:05:30 1994 From: Paul Yadlowsky X-Mailer: Z-Mail (2.1.4 02apr93) To: amiga-x@sun-lamp.cs.berkeley.edu Subject: tcl/tk on Amiga-NetBSD X11R5 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu The following is a message I posted to comp.lang.tcl in hopes of getting some help with an X problem on my Amiga (NetBSD 744, X11R5). So far, no one has responded to my request for advice. For those not familiar with tcl/tk, it is an X toolkit developed by John Ousterhout at the University of California at Berkeley. If any of you have any ideas as how I might go about fixing this problem I would appreciate hearing from you. Please note that other people who have tried to run tcl/tk under Amiga-NetBSD are having the same problem. -Paul I currently have tcl/tk working (almost) on an Amiga 3000 running the NetBSD operating system (BSD unix, X11R5). Tk does everything as expected with one major exception; it does not display text. The windows, buttons, menus all look and work fine --- they just don't show their text. I've poked around in the tk code and have found the calls to XDrawString that should be generating these strings. I've added printf statements to check the arguments and the arguments of these calls to XDrawString appear to be correct. Any ideas what might be going wrong? Please note that other programs such as xman and xcalc are working fine, labels and all. This leads me to believe that the X server is working fine. -- Paul Yadlowsky ITC-Academic Computing Health Sciences psy@galen.med.Virginia.EDU University of Virginia (804) 924-2846 (office) Health Sciences Center (804) 982-4030 (fax) Hospital West, Room 3001 Charlottesville, VA 22908 From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Feb 22 17:01:13 1994 From: "Andreas E. Heitmann" To: psy@sanger.med.virginia.edu Cc: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: tcl/tk on Amiga-NetBSD X11R5 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu >>>>> "Paul" == Paul Yadlowsky writes: Paul> I currently have tcl/tk working (almost) on an Amiga 3000 Paul> running the NetBSD operating system (BSD unix, X11R5). Tk Paul> does everything as expected with one major exception; it Paul> does not display text. The windows, buttons, menus all look Paul> and work fine --- they just don't show their text. I've Paul> poked around in the tk code and have found the calls to Paul> XDrawString that should be generating these strings. I've Paul> added printf statements to check the arguments and the Paul> arguments of these calls to XDrawString appear to be Paul> correct. Any ideas what might be going wrong? Please note Paul> that other programs such as xman and xcalc are working fine, Paul> labels and all. This leads me to believe that the X server Paul> is working fine. Hi ! I compiled tcl/tk and XF and didn't observe the problem you have. All Strings are drawn correctly. I'm using the Retina X-server in the 256 color mode. But with Tcl/Tk another problem showed up: when Tcl/Tk wants to lookup a color from the color database, only color names which are completely lowercase are recognized. Color names with uppercase letters are "unknown" and give me an error message. Is this a bug in my color DB, or a bug in the server ? bye, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) "Don't give me any of that intelligent life stuff. Find me something I can blow up." Lt. Doolittle, _Dark Star_ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 17:42:54 1994 From: leland@wacky.acet.org (Robert Leland - PSI) Subject: Re: Compiling sun-lamp sources. Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > On Feb 22, 9:41am, Niklas Hallqvist wrote: > > C. Is there any point in trying to use the kernel debugger? I know the > > disassembler cannot work, but otherwise? > > Sorry, haven't compiled sun-lamp kernel yet, but this point buggers me, too. > Currently trying to write a driver for the A2060 Arcnet and all i get is > a MMU-Panic yet, i wonder if there is any way to debug a kernel without > having to recompile it every 5 minutes after adding a printf() somewhere. Well if you have two machines you could try debugging it using the serial port and KGDB (gdb -k). I have done this on i386 machines but not the Amiga. I am not sure if any special code needs to go into the serial driver for this it works well. Has any one ddone this yet. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 17:52:38 1994 From: leland@wacky.acet.org (Robert Leland - PSI) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Compiling sun-lamp sources. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > FYI, I recompiled my sun-lamp based kernel with -O using 2.5.8 GCC Ditto > A. Has anybody compiled a recent sun-lamp kernel with 2.5.8 and ld.old? > Did you do anything special? No. Just made sure that I had a current version of /usr/src/lib installed also. And moved ld to kernel-ld. > > B. Could people stress their machines to the point the systems start to > thrash (start several concurrent compilations and some emacses) and > check that the kernel works ok. For those of you still running > 744, don't bother, I know that works. I keep getting bus errors (Signal 10) when trying to recompile during I believe linking phase, but I am not sure, for libc.a. I haven't been able to track the problem down yet. Separate question: What do I need to do to be able to rebuild a usable ld? Right now I am using the last distributed ld. The one I build complains about wrong Archetecture. The new ld.so seems to work ok, I run the shared X, just the static ld seems muffed. More questions than answers @-)! -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 21:09:43 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Floppy questions Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9402220726.AA02718@sun> pepersb@cuug.ab.ca (Brad Pepers) writes: > now to try some neat stuff with it like newfs/disklabel/... How > does everyone think disklabels should be done? I was thinking to > either make a fake one for the whole drive as one partition or > actually write out the label to sector 0. I would just fake up a disklabel for the whole disk. I don't think it makes sense to partition a floppy. > And finally, as I don't understand the controller/slave setup > properly - the device driver is a bit odd. It is configured as: > > device fp0 at manafacturer 1 product 10 > > I used fp instead of fd since there is already an fd device. I > added the builtin product #10 for my device. Pruduct #2 was already reserved for floppies. The commented-out entry in the original config files was: #master floppy0 at manufacturer 1 product 2 I don't knowthat a master/slaves design is strictly needed, but it could be useful for supporting multiple disk formats (eg amiga-style 880K, dos-style 720K MFM, etc). -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 22:27:39 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Looking for new kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 21, 7:23pm, Bob Slawson wrote: > loadbsd rejects any kernel I've built with a recent link editor > (with LD=ld -Bstatic in the Makefile). I noticed that > > `file netbsd' linked with `ld -Bstatic -n ....' returns > (this is from memory) > > NetBSD/m68k pure executable binary > > whereas when linked with ld.old from the 720 usr.bin > > old sun-2 pure executable binary > > `file vmunix.744' also returns "old sun-2 ..." > > Is there a deep reason why this anachronism is necessary? Are there > differences other than the magic numbers? I think it would be > convenient to be able to use a current link editor when building > kernels rather than keeping a single purpose one around. The kernel is not a demand-paged executable, which is what the standard 'ld' will generate. The first page of a demand-paged executable is linked to address 0x2000. The kernel has to be linked so that the first byte of the code segment is linked at 0. Loadbsd and the /dev/reload magic expect this, so you need the ld.old to create the kernel executable. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Feb 22 22:29:12 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Compiling sun-lamp sources. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 21, 9:19pm, Chris Hopps wrote: > This is a note to all devlopers that are compiling sun-lamp sources. ... > The position of the stack changed so all programs that referece > USRSTACK need to be recompiled like ps, w, nfsd, gdb... Yell at > Markus about this one :^) Or you can do like I did and locate where the stack is referenced and patch it :-). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 22 23:12:03 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Networking... To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've gotten NetBSD running, but I am having problems getting the networking setup. I am hooked up to a network with a CBM 2065 card, and am able to ping out but I end up getting duplicate packets sent back from both the pinged site and my site. Which files in /etc do I need to change? # /etc/hostname.le0 inet reality 255.255.255.0 128.101.236.254 -trailers dest 128.101.236.254 # /etc/resolv.conf domain cs.umn.edu. nameserver 128.101.101.101 # /etc/mygate 128.101.236.254 # /etc/myname reality Thanks... Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Tue Feb 22 23:58:11 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: Networking... To: garion@mermaid.micro.umn.edu (Ron Roskens) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Ron Roskens wrote: > I've gotten NetBSD running, but I am having problems getting the > networking setup. I am hooked up to a network with a CBM 2065 card, > and am able to ping out but I end up getting duplicate packets sent > back from both the pinged site and my site. Which files in /etc do I > need to change? > I found out what my problem was: broadcast 128.101.236.254 ^^^ --> 255 Ron From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 23 03:27:00 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Networking... Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <199402222145.AA09933@mermaid.micro.umn.edu> garion@mermaid.micro.umn.edu (Ron Roskens) writes: > I've gotten NetBSD running, but I am having problems getting the > networking setup. I am hooked up to a network with a CBM 2065 card, [...] > > # /etc/hostname.le0 > inet reality 255.255.255.0 128.101.236.254 -trailers ^^^ .255? > dest 128.101.236.254 You don't need a destination for ethernet, only for point-to-point links like slip or ppp. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 23 03:35:05 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm trying to compile some programs and they happen to include dirent.h which upon compiling complains about a parse error at the point where it defines the struct dircent. Is there an updated version? or do I just need a newer version of gcc? ( currently v2.5.6 ) Thanks, Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 23 05:48:37 1994 From: Hubert Feyrer Subject: Re: Networking... To: garion@mermaid.micro.umn.edu (Ron Roskens) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1034 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > # /etc/hostname.le0 > inet reality 255.255.255.0 128.101.236.254 -trailers > dest 128.101.236.254 > # /etc/mygate > 128.101.236.254 Besides the mentioned destination address (which is only for point to point devices), there might be another problem as your ip-address seems to be the same as your gateway. Is you machine its own gateway? ;-) By the way, I've hooket up my machine the same way, and I get an uptime of "up 6 days, 12:29" 'till now. This is really amazing: I've got also a Univel-box (Novell-SVR4), which crashes all the time. I'm soooo amazed by NetBSD! I love it, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Feb 23 10:28:13 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Gdb To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 98 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I belive that I have got sun-lamp's gdb working all interested sup'ers give it a try. :^) Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 23 12:56:07 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Sup from mirror sites? Which, if any? Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I am currently supping the kernel sources from sun-lamp, because I haven't found a mirror site that also has a sup server. Is this because I haven't been looking good enough? Sup from sun-lamp is rather slow, and I wouldn't mind a day delay in the newest source versions in order to reduce the load on sun-lamp. And since the mirrors also sup from sun-lamp, lots of network traffic is being duplicated. -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ There are no lemurs in this post rhialto@mbfys.kun.nl From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 23 13:12:00 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Looking for new kernel To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 801 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Is there a deep reason why this anachronism is necessary? Are there > > differences other than the magic numbers? I think it would be > > convenient to be able to use a current link editor when building > > kernels rather than keeping a single purpose one around. > > The kernel is not a demand-paged executable, which is what the > standard 'ld' will generate. The first page of a demand-paged > executable is linked to address 0x2000. The kernel has to be linked so > that the first byte of the code segment is linked at 0. Loadbsd and the > /dev/reload magic expect this, so you need the ld.old to create the > kernel executable. Of course -n which we always had requests an NMAGIC file, however the new ld was still linking at 0x2000... -T 0 took care of that. :^) > Michael Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 23 18:16:44 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: GCC 2.4.5 didn't help me :-( Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 23, 5:39pm, Niklas Hallqvist wrote: > My kernel problems with recent sun-lamp code persists when compiling with > 2.4.5. I conclude the problems are generic for low-mem systems. Are thera > anyone else running -current on 4 MBs? I've been compiling with 2.5.6 (I think that's the version I'm using) and run into a situation that seems very similar, except that it occurs when trying to start up multi-user mode. I get a large number of error messages about things being directories and other errors. What's very interesting about this is that I used the same kernel on a 16M system and didn't see any problems with it, but when I tried to boot it on an 8M system, it failed. Using my -m option on loadbsd to adjust the memory size, I found that using -m8000 (8000K bytes), NetBSD would load and run. Increasing the memory to -m9000, it was still failing, but when I increased it to -m10240 (10M), it seemed to run fine again. I haven't done any extensive testing, but my second system was able to compile an earlier version of the kernel when I booted with the -m8000. I also ran the Xmono server a while on this system and things seemed to be working OK. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 23 19:14:09 1994 From: Niklas Hallqvist To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: ADOSFS uploaded X-Charset: LATIN1 X-Char-Esc: 29 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu ftp.eunet.ch:/pub/amigabsd/incoming/adosfs.tar.gz Later when moved, possibly in contrib/bsd??? Hackers only release! read README before trying it out. Excuse me for the delay (1/2 a year, isn't it?). I plan a LKM release as soon as I get a working kernel based on sun-lamp. Niklas Niklas Hallqvist nh@cd.chalmers.se (at school) niklas@appli.se (at work) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 23 19:38:20 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: GCC 2.4.5 didn't help me :-( Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu My kernel problems with recent sun-lamp code persists when compiling with 2.4.5. I conclude the problems are generic for low-mem systems. Are thera anyone else running -current on 4 MBs? Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 23 20:32:24 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: GCC 2.4.5 didn't help me :-( To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 959 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > My kernel problems with recent sun-lamp code persists when compiling with > 2.4.5. I conclude the problems are generic for low-mem systems. Are thera > anyone else running -current on 4 MBs? Some real interesting info would be: what your shell limits are (full info) probably 2M stack 32M data etc.. what the size of your swap area is. i.i. what size is you sdNb? what hardware do you have in your system? Any 16bit RAM? perhaps a nasty supraRAM card? (I have my doubts as to exatcly who is responsible for my problems with supraRAM either GVP accelerator or SupraRAM...) If you have 16 bit RAM cards, try and pull them and see what happens.. Yes even though your not useing them. My system has been stable ever since I removed my supraRAM card that I wasn't useing in NetBSD. Also perhaps your swap area is not large enough? I really want to get your system running as I know exactly how it feels to be in your posistion. > Niklas Chris. From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Feb 23 21:21:48 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "tcl/tk on Amiga-NetBSD X11R5" (Feb 22, 8:54am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Paul Yadlowsky , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: tcl/tk on Amiga-NetBSD X11R5 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Feb 22, 8:54am, Paul Yadlowsky wrote: > show their text. I've poked around in the tk code and have found > the calls to XDrawString that should be generating these strings. > I've added printf statements to check the arguments and > the arguments of these calls to XDrawString appear to be correct. > Any ideas what might be going wrong? Please note that other programs > such as xman and xcalc are working fine, labels and all. This leads > me to believe that the X server is working fine. I've been using tk/tcl, too (see tk/tcl -FAQ :-), and i solved the problem telling 'wish' to use a black foreground (-fg black). The problem is still valid for external shell-script using tk/tcl, i haven't found any solution yet to tell tk/tcl in any global way to use other colors. The problem is the monochrome- X server, not the X lib nor tk/tcl. -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Feb 23 21:26:31 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: tcl/tk on Amiga-NetBSD X11R5" (Feb 22, 4:36pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: tcl/tk on Amiga-NetBSD X11R5 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Feb 22, 4:36pm, "Andreas E. Heitmann" wrote: > I compiled tcl/tk and XF and didn't observe the problem you have. All > Strings are drawn correctly. I'm using the Retina X-server in the 256 > color mode. That's what i thought, the X server is the bugger. It seems to me that the Xmono X server tries to map all colors to black and white, and somewhere it still believes it is a color server. > But with Tcl/Tk another problem showed up: when Tcl/Tk wants to lookup > a color from the color database, only color names which are completely > lowercase are recognized. Color names with uppercase letters are > "unknown" and give me an error message. Is this a bug in my color DB, > or a bug in the server ? I thibk this is a bug in your database. try out 'XRainBow' or 'xcolor' to check (can both be found on your loveable ftp server). -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Feb 23 21:39:53 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Compiling sun-lamp sources." (Feb 22, 11:28am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: leland@wacky.acet.org (Robert Leland - PSI) Subject: Re: Compiling sun-lamp sources. Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 22, 11:28am, Robert Leland - PSI wrote: > Well if you have two machines you could try debugging it using the serial > port and KGDB (gdb -k). I have done this on i386 machines but not the Amiga. > I am not sure if any special code needs to go into the serial driver for this > it works well. Has any one ddone this yet. Guess what :-) I do have two machines here (Amigas), as i want to write the A2060 driver. Where can i get the KGB, err, GPU, KGDB :) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 24 03:10:49 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: GCC 2.4.5 didn't help me :-( To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1009 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > My kernel problems with recent sun-lamp code persists when compiling with > 2.4.5. I conclude the problems are generic for low-mem systems. Are thera > anyone else running -current on 4 MBs? I'm running on a 4MB system. I'm also using 2.5.6 (I think). I find that I get very strange results. I managet to get a bootable kernel ever other compile or so. Problems ranged from a blank gray screen, to init dying from a trapsignal, to the latest version where init just dies. The only soution I can suggest is don't compile with -O2, and if a kernel fails, delete all the .o files and try again. I fand that after re-compiling the whole thing, the kernel will sometimes work. BTW, I do run mkdep on a kernel before I start compiling. I'm getting the impression that mkdep may just be broken. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Feb 24 04:12:26 1994 From: Arthur Hoffmann Subject: Re: GCC 2.4.5 didn't help me :-( To: eeh@btr.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1669 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > > My kernel problems with recent sun-lamp code persists when compiling with > > 2.4.5. I conclude the problems are generic for low-mem systems. Are thera > > anyone else running -current on 4 MBs? > > I'm running on a 4MB system. I'm also using 2.5.6 (I think). I find > that I get very strange results. I managet to get a bootable kernel > ever other compile or so. Problems ranged from a blank gray screen, > to init dying from a trapsignal, to the latest version where init just > dies. The only soution I can suggest is don't compile with -O2, and > if a kernel fails, delete all the .o files and try again. I fand that > after re-compiling the whole thing, the kernel will sometimes work. > > BTW, I do run mkdep on a kernel before I start compiling. I'm getting > the impression that mkdep may just be broken. > > ========================================================================= > Eduardo Horvath eeh@btr.com > ..!{decwrl,mips,fernwood}!btr!eeh > "Trust me, I am cognizant of what I am doing." - Hammeroid > > > I am not so sure if it is related to your system being 4M, I have tried to compile the sun-lamp kernel on my A3000 16M (fast) and I only get a grey screen when loadbsd'ing vmunix.(loadbsd is the latest on eunet) I'm using gcc2.5.8, ld.old and -O optimization. (O2 caused heaps of undefined stuff when the compile was finished.) I also do a make depend and I also tried to erase the whole ...../compile/ATZE directory and doing a new config ATZE every time I did a sup to sun-lamp. Also I did a make clean in /usr/src/sys/lib/libkern. Any clues? Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 24 06:52:48 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu Subject: New binaries uploaded Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've just finished uploading a new set of binaries built from the 19 Feb 94 version of the sun-lamp sources to incoming on ftp.eunet.ch (actually, all but usr.share but it's on its way). Please read the README file first! Also, I've uploaded an A3000 kernel (vmunix) built from the same sources. Enjoy, -SR From owner-amiga@sun-lamp.cs.berkeley.edu Thu Feb 24 23:19:57 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: groff and man To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I cant read any unformatted man pages (/usr/share/man/man*/*). I tried using nroff -man file.1|more to look through it and it turns out that groff doesnt have everything it needs (cant find DESC). Where do I get the files I need to have nroff/groff work properly and to get man to work properly? Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 25 02:09:00 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: groff and man To: newsham@uhunix.uhcc.Hawaii.Edu Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 570 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > Hi, > I cant read any unformatted man pages (/usr/share/man/man*/*). I > tried using nroff -man file.1|more to look through it and it turns out > that groff doesnt have everything it needs (cant find DESC). Where > do I get the files I need to have nroff/groff work properly and to > get man to work properly? Well I can tell you two things neitheeer will help you too much though probably. 1) it works over here (sun-lamp standard distrib) 2) proper usage should probably be "nroff -mandoc file.1 |more" > Tim N. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Feb 25 03:23:06 1994 Subject: Sup releases From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu OK, I think I might have sup built for the sun4's here at school. I had to butcher the Makefile majorly to get it to compile. In any case, what's the name of the releases required to build the Amiga kernel and binaries? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Feb 25 04:34:06 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Sup releases To: dej@eecg.toronto.edu (David Jones) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 455 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > In any case, what's the name of the releases required to build the Amiga > kernel and binaries? # get this and read README.sup. current release=doc # This is the main source for bins and kernels. current release=src current release=ksrc-common current release=ksrc-amiga # if in the US only. current release=security # optional. current release=games current release=regress current release=othersrc don't forget to specify use-rel-suffix. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Feb 25 19:01:30 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Password Problem Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I currently ran into the problem that all programms which need to lookup for password entries, such as xlock, xgone and xnlock don't work when shadow passwords are enabled. I've been looking into my mail-record but haven't found any hint about that. I link with -lcrypt which normally should do the trick, alas it doesn't... Anyone? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 25 19:45:35 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/amiga Modified Files: conf.c Log Message: fixed cmopile warns with LKM enabled. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: st.c Log Message: changes to support Python tape drive. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: device.h ite.c scsi.c sd.c siop.c Log Message: fixed a couple minor bugs in con code for ite. added floptical support in sd.c (based on patch from Andreas E. Heitman). --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: ite.c Log Message: toss chars instead of outputing when in GRF mode. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/doc In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/doc Modified Files: CHANGES Log Message: note change to ite.c and that X runs with no redirection and no MMU failt now. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/etc/etc.amiga Modified Files: MAKEDEV ttys Log Message: fixed up to be current --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/share/man/man8 In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/manpages/man8 Modified Files: Makefile Log Message: added man8.amiga. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/share/man/man8/man8.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/manpages/man8/man8.amiga Added Files: MAKEDEV.8 Makefile Log Message: added amiga specific MAKEDEV manpage. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/share/man/man8/man8.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/manpages/man8/man8.amiga Log Message: Directory /b/source/CVS/src/share/man/man8/man8.amiga added to the repository --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/conf Modified Files: Makefile.amiga Log Message: kernel now linked with dist ld. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/amiga Modified Files: clock.c locore.s Log Message: amiga now uses PROF and uses m68k/asm.h in locore.s --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/sys/arch/mac68k/mac68k In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/mac68k Added Files: fpu.c Log Message: Rudimentary, experimental fpu emulator. Needs lots o' work before it can move to m68k or even be useful for more than testing purposes... --------------------------------- From: Herb Peyerl Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/c/users/hpeyerl/norm/src/sys/arch/amiga/include Modified Files: param.h Log Message: Move some arch dependant stuff in here. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/gnu/usr.bin/gdb/gdb/arch/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/gdb/gdb/arch/m68k Modified Files: nm.h tm.h Log Message: removed arch dependent values. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/gnu/usr.bin/gdb/bfd/arch/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/gdb/bfd/arch/m68k Modified Files: sysdep.h Log Message: fix core-file-failing-signal, and remove arch dependent values. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/include Modified Files: vmparam.h Log Message: added KUSER_AREA for gdb like things. removed HIGHPAGES --------------------------------- From: Adam Glass Update of /b/source/CVS/src/sys/arch/sun3/sun3 In directory sun-lamp.cs.berkeley.edu:/c/users/glass/src/sun3/src/sys/arch/sun3/sun3 Modified Files: autoconf.c conf.c cons.c genassym.c isr.c locore.s m68k.s machdep.c pmap.c sun3_startup.c trap.c trap.s vm_machdep.c Log Message: boots, presents shell prompt, and doesn't crash immediately --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/amiga Modified Files: genassym.c Log Message: mirror removal of HIGHPAGES and addition of KUSER_AREA to vmparam.h --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/include Modified Files: param.h Log Message: add some very usefull debug stuff to spl inline macros. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga Modified Files: Makefile Log Message: Makefile should now properly make tags, and not error on install. --------------------------------- From: Paul Mackerras Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/d/users/paulus/src/sys/kern Modified Files: subr_mcount.c Log Message: Add da30 to the conditionals for m68k code. (Maybe this should become #if defined(m68k).) --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/kern Modified Files: subr_mcount.c Log Message: hp300||amiga||da30 -> m68k --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/conf Modified Files: Makefile.amiga Log Message: change -O2 back to -O, may be inappropriate with some versions of gcc. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/conf Modified Files: files.amiga Log Message: added files for option ADOSFS. --------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Fri Feb 25 19:58:27 1994 From: Eric Glanz - Unix Support Subject: Re: Lockups under heavy disk access To: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: IN%"amiga@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga@sun-lamp.cs.berkeley.edu I was having the same locking problems with my tape drive and hard drive. I updated to a rev 8 SCSI chip, and that fixed the bus locking with the tape drive under AmigaDOS and NetBSD, but I eventually had to ditch the drive that I was using for BSD. I just could not get it to work, it kept locking the SCSI bus. When I switched to another drive, everything worked fine. FYI - The drive that I could not get working was a 200 Meg Hitachi DK312c. Hope this helps! --Eric Glanz Unix Support University of Wisconsin - Platteville From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 26 00:11:36 1994 To: amiga@sun-lamp.cs.berkeley.edu Cc: markus@TechFak.Uni-Bielefeld.DE Subject: Re: Password Problem From: Rick Chavez Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) > > I currently ran into the problem that all programms which need to > lookup for password entries, such as xlock, xgone and xnlock don't work > when shadow passwords are enabled. > > I've been looking into my mail-record but haven't found any hint about > that. I link with -lcrypt which normally should do the trick, alas > it doesn't... Try setting the SUID bit on the executable and make it owned by root. # chown root xlock # chmod 4755 xlock In shadow password schemes the system call "getpwent" returns the '*' found in /etc/passwd, except it will return the real password entry if you are root. Most of these programs use this system call. If you have a program that directly accesses /etc/passwd then you're out of luck. ------------------------------------------------------------------------------ Rick Chavez chavez@convex.com Convex Computer Corp. (214) 497-3058 ------------------------------------------------------------------------------ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Feb 26 16:26:52 1994 From: Hubert Feyrer Subject: Re: Password Problem To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 596 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Just an idea: does getpwent() return the encrypted pw when run as root, or only a star, as stored in /etc/passwd? Maybe putting the progs setuid root helps? Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Feb 26 18:45:16 1994 From: rhealey@aggregate.com Subject: X libs linked with new linker? To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 135 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Has anybody remade the dynamic X librarys with the new linker so those damn ld relocation messages will shut the fork() up? -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Sat Feb 26 20:26:35 1994 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: amiga@sun-lamp.cs.berkeley.edu From: mykes@shell.portal.com (Mike Schwartz) Subject: wangdat tape drive Sender: owner-amiga@sun-lamp.cs.berkeley.edu I installed netbsd on a friend's A2000 + GVP 030 plus conner 1.6G drive and had no problems with it.... There's still some tweaking to do with X and config files, but I was able to unpack all the tar.gz files and partition the drive and so on. However, he has a wangdat dat tape drive and when we tried to put it on the scsi bus, netbsd locked up at boot time just after printing/identifying the Wangdat. The kernel reported: jump to $0 and resets. Is there a solution to this? From owner-amiga@sun-lamp.cs.berkeley.edu Sun Feb 27 02:27:22 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Console size To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Is there a way to expand the oversize on the screen? I'm stuck with a mono-multisync and I'd like to use a larger screen size than the standard 640x400. So what bits to I need to tweek on the kernal? Also, along the same lines, how hard would it be to have NetBSD open the console screen into the Productivity mode? I would assume this would allow a screen size of at least 800x600 +overscan and would be allowable for a usable size screen in X. Ron Roskens From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 27 09:59:50 1994 From: niklas@appli.se (Niklas Hallqvist) To: newsham@uhunix.uhcc.Hawaii.Edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: adosfs Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Tim" == newsham writes: Tim> % mount -t adosfs -o ro /dev/sd6f /mnt Tim> mount: Invalid argument /dev/sd6f is not an AmigaDOS partition, that's your problem, see below! Tim> I havent upgraded my mount program yet meaning I still have the Tim> version from the 720 rootfs. Is this my problem? Don't think so. Tim> Another thing I dont understand.. what is the mapping of Tim> partitions to /dev/sd?? names? As I understood it they were Tim> calculated as the filesystem type, ie BSDR = /dev/sd?a BSDD = Tim> /dev/sd?d, BSDF = /dev/sd?f etc. Now an amigados filesystem will Tim> not have any of these names! So, how do I specify partition and Tim> scsi device? Do I specify the whole drive? (/dev/sd?c)? The current partioning scheme consists of two models merged into one. BSD partitions which are identified by their filesystem type, and Non- BSD partitions identified by their order on the disk. If we take a look at the minor device number bits, we se how this is solved: 7 6 5 4 3 2 1 0 b = partition bank, d = SCSI ID, p = partition b b i i i p p p Ordinary BSD partitions use bank 0, others 1-3 (although a recent change by Chris Hopps made bank 2 & 3 unavailable, which isn't a problem unless you have more than eight ADOS partitions on a single disk). There are two naming conventions for the NonBSD partitions: either my ad hoc naming which I've kept to my self, and the more logical extension of the usual naming proposed by Michael Hitch. Partition My name Michael's name 0 sd?p0 sd?i 1 sd?p1 sd?j ... To see why MH's naming is more intuituive, run this command for a disk where you have at least one ADOS partition: disklabel /dev/sd?c Note this only runs OK if your disklabel binary is in sync with your kernel. OK, as an example, suppose you have two ADSOSFS partitions on your disk at SCSI ID 3. These commands create the necessary nodes: mknod /dev/sd3i b 4 88 mknod /dev/sd3j b 4 89 mknod /dev/rds3i c 8 88 mknod /dev/rds3j c 8 89 88 is 64 (bank 1) + 24 (ID 3) + 0 (first partition)! Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 27 16:29:07 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: adosfs vs. sun-lamp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu If you apply the adosfs patches to a current sun-lamp you have to either takeout the adosfs files from sys/conf/files or from sys/arch/amiga/conf/files.amiga. I don't care what you do, but if you don't do any of these you'll get an error from config. Niklas PS. If someone wants to work on this package, contact me and I'll provide info & coordination. Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Feb 27 18:27:08 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: adosfs vs. sun-lamp To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 498 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > If you apply the adosfs patches to a current sun-lamp you have to > either takeout the adosfs files from sys/conf/files or from > sys/arch/amiga/conf/files.amiga. I don't care what you do, but > if you don't do any of these you'll get an error from config. > > Niklas I am really sorry about this, I have all the diffs applied (by hand) on my local source tree at sun-lamp, however I was told to wait while everyone else argued over them. Otherwise they would all be in there now. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 00:09:57 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Floppy driver To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1324 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Here is more status info on the floppy driver. It now works well enough for adosfs to work on it. I can mount my amiga floppies and copy files from them. Here is what I haven't done: 1. Really test things with multiple tasks making requests 2. Make code robust to handle disk changes and write errors 3. Test out write code fully (need a writeable filesystem) 4. Handle disk labels enough to get newfs to work I have been cleaning the code up and its not too bad right now. The track writing code is still being worked on but it does work in some simple cases I tried. My plan now is to finish cleaning up the write code and implement disk labels. Then I can try newfs on it and get a read/write fs. I would also like to look at handling msdos disks. Maybe someone could send me info on msdos disks or after the code is released they can add in msdos disk handling. +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 02:16:20 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: Floppy driver To: pepersb@cuug.ab.ca (Brad Pepers) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Brad Pepers wrote: > > stuff on adosfs deleted. > > I would also like to look at handling msdos disks. Maybe someone > could send me info on msdos disks or after the code is released > they can add in msdos disk handling. > If I'm not mistaken there already is support for the msdos file system in the form of a gnu msdos file system. Maybe it would be better to try to work the code to be able to handle that instead of trying to totally rewrite the msdos fs. Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Mon Feb 28 04:32:17 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu Subject: Questions about new binaries on eunet Sender: owner-amiga@sun-lamp.cs.berkeley.edu Well, I've heard nothing since I've uploaded the new set of binaries to eunet. Has anybody tried them out? [Does anybody care? :-] -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 05:17:30 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy driver To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1330 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > >From the reaches of cyberspace, Brad Pepers wrote: > > > > stuff on adosfs deleted. > > > > I would also like to look at handling msdos disks. Maybe someone > > could send me info on msdos disks or after the code is released > > they can add in msdos disk handling. > > > > If I'm not mistaken there already is support for the msdos file system > in the form of a gnu msdos file system. Maybe it would be better to > try to work the code to be able to handle that instead of trying to > totally rewrite the msdos fs. > > Ron Roskens > I was talking about a lower level than the filesystem. MSDOS disks are formatted in a different way and all the track/sector information is different. The low level disk reading code has to be changed first so that it can even find any data on MSDOS disks. Once that is working the msdos filesystem that comes with netbsd can be used. +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 05:33:45 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Floppy driver Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <199402280108.AA20831@mermaid.micro.umn.edu> garion@mermaid.micro.umn.edu (Ron Roskens) writes: > From the reaches of cyberspace, Brad Pepers wrote: > > I would also like to look at handling msdos disks. Maybe someone > > could send me info on msdos disks or after the code is released > > they can add in msdos disk handling. > > If I'm not mistaken there already is support for the msdos file system > in the form of a gnu msdos file system. Maybe it would be better to > try to work the code to be able to handle that instead of trying to > totally rewrite the msdos fs. Yes, NetBSD has a msdos filesystem (not GNU copyrighted). What Brad is talking about though is supporting the MSDOS raw disk layout in his driver. Otherwise, you'll only be able to read msdos disks formatted for Amiga 880K format, which is pretty useless. -- Ty Sarna "As you know, Joel, children have always looked tsarna@endicor.com up to cowboys as role models. And vice versa." From owner-amiga@sun-lamp.cs.berkeley.edu Mon Feb 28 06:06:30 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: LoadBSD To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Am I missing something somewhere? I'm trying to use the ados command loadbsd with the option -a to boot into multiuser mode, but It always reboots the system back into ados. When I do use the command it says all the stuff about the system and then says "Automatic Reboot in progress." then reboots the system back. Also, does anyone know how to write a ados script to wait a certain time period and if theres interaction, it breaks, otherwise continues on. ie: if return is pressed start ados, otherwise boot into NetBSD... Thanks, Ron Roskens From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 06:41:30 1994 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: garion@mermaid.micro.umn.edu (Ron Roskens), pepersb@cuug.ab.ca (Brad Pepers) From: mykes@shell.portal.com (Mike Schwartz) Subject: Re: Floppy driver Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu At 7:08 PM 2/27/94 -0600, Ron Roskens wrote: >>From the reaches of cyberspace, Brad Pepers wrote: >> >> stuff on adosfs deleted. >> >> I would also like to look at handling msdos disks. Maybe someone >> could send me info on msdos disks or after the code is released >> they can add in msdos disk handling. >> > >If I'm not mistaken there already is support for the msdos file system >in the form of a gnu msdos file system. Maybe it would be better to >try to work the code to be able to handle that instead of trying to >totally rewrite the msdos fs. > >Ron Roskens Handling MS-DOS disks doesn't mean the filesystem. The IBM PCs have a Western Digital floppy controller chip that writes sectors to floppy disk differently than the amiga OS does. Fortunately, the Amiga hardware is capable of reading and writing data compatible with the Western Digital controller, but it's a radically different program to do so. In other words, take that amigaOS compatible floppy driver sources and you can only use the motor on/off and head stepping code. The entire rest of the driver needs brand new and custom code to read the WD controller format. I actually had code to read/write the WD controller format, as well as code to read write trackdisk.device format. I have found the trackdisk format code and even translated it to C and sent it to mtk. I'm not much interested in hacking kernels as other people are - my hopes were that either mtk or someone mtk found might be willing to work with the code. I offer to send anyone the assembly version of the trackdisk format code - it uses the blitter for mfm encoding and decoding and has some non-traditional (but superior) features to traditional trackdisk devices (unix or amigados). For example, my routines search the drives for a specific disk instead of requiring that specific disk to be in a specific drive. In other words, you can do a dir on the floppy, eject it and put it in another drive and do dir again and the software finds the floppy in the new drive... I'd offer the MS-DOS (actually Atari ST, but same difference) format routines in assembly, but I haven't been able to find them :( From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 07:39:42 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: More floppy info To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1539 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Well this has been a good evening 8^) I have the floppy driver cleaned up. It seems to be doing read and write properly. I have it set up to hack together a disk label so I can now do newfs on it. This creates a valid ufs type filesystem on the disk - and it works!!! Pretty much everything is hunky-dory now. Guess I better find out what all I've changed and upload the driver and diffs. This was all done on the 744 kernel sources so I hope it will fit into the current sources. May need some manual changes... One problem. The filesystem does things in 2048 byte blocks. I break this down into 512 byte (sector) blocks. But I don't want to write to the floppy driver on every write. So I keep one track in a buffer and only write out the data when the track is needed for another track. But this may be a problem when the filesystem is unmounted as the write won't get done. I've got some debug code in now to try and cause the problem to happen and I'm planning to check in the close() code to see if the track buffer is dirty and write it if so. Is there a better way to do this? +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 12:58:09 1994 From: niklas@appli.se (Niklas Hallqvist) To: osymh@gemini.oscs.montana.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Strange kernel problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Michael" == Michael L Hitch writes: Michael> On Feb 21, 9:54am, Niklas Hallqvist wrote: >> I've built both a kernel derived from the 940213 sources at >> sun-lamp as well as one from 940220. Both behave well at first, >> but after some time, presumably after a certain amount of paging (I >> still run in 4MB!), all I can do is to execute bash internal >> commands. Every other command results in "ls: is a directory" type >> of messages. I haven't seen anything on current-users so I suspect >> it's Amiga-specific (or do all PC NetBSDers have a reasonable >> amount of memory?). Has anoyone tried late versions on low-mem >> Amigas? Typically starting emacs and stopping it (C-z) is enough >> to start this behaviour (well, I have never succeeded to do this >> anyway). There does not seem to be memory corruption going on, all >> in-core images run fine, it's just that I cannot start any new >> programs. Michael> Try out this fix and see if it helps any. It has fixed the Michael> problem I was having with the 940219 kernel. I finally Michael> tracked it down when I created a kernel that would give me a Michael> "init died" panic every time I tried to boot it. If I varied Michael> the memory size, I could get it to run with no problem. I LOVE YOU! How on earth did you find this one, step by step? I was really going crazy... How can I return this favour? Do you have any pet peeves which you ain't got time to fix yourself? Not that I got that much time but I'd like to return something :-) I'd almost trade Sweden's olympic hockey gold medal for this :-) To everyone: Are there any clear evidence that -O2 is bad? I believe Chris took it out just in case. And I wonder: Why didn't the copyinstr bug hit harder? It was *really* evil! OK, now for ADOSFS LKM... I here people are successfull with the hacker release. If just Chris applies the mount.h patch so we can get the MNT_ constant reserved... Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 12:58:29 1994 From: Olaf Seibert To: garion@mermaid.micro.umn.edu, mykes@shell.portal.com, pepersb@cuug.ab.ca Subject: Re: Floppy driver Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu mykes@shell.portal.com (Mike Schwartz) wrote: > I'd offer the MS-DOS (actually Atari ST, but same difference) format > routines in assembly, but I haven't been able to find them :( Drat! They removed my MSH stuff from aminet! Anyway, again I offer my MSH code (in assembly) for use; even the faster version that has never been published in source code before. -Olaf. -- ___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96 \X/ There are no lemurs in this post rhialto@mbfys.kun.nl From owner-amiga@sun-lamp.cs.berkeley.edu Mon Feb 28 14:09:10 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Questions about new binaries on eunet" (Feb 27, 10:14pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Stephen J. Roznowski" , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Questions about new binaries on eunet Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Feb 27, 10:14pm, "Stephen J. Roznowski" wrote: > Subject: Questions about new binaries on eunet > > Well, I've heard nothing since I've uploaded the new set of binaries > to eunet. Has anybody tried them out? [Does anybody care? :-] Well, actually i have tried them out, but i haven't finished the installation yet. So far it looks good, although i get some trapsignals/coredumps from /usr/sbin/ programms. I keep you informed. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 14:28:42 1994 From: niklas@appli.se (Niklas Hallqvist) To: pepersb@cuug.ab.ca Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floppy driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Brad" == Brad Pepers writes: Brad> Here is more status info on the floppy driver. It now works well Brad> enough for adosfs to work on it. I can mount my amiga floppies Brad> and copy files from them. Here is what I haven't done: Nice to hear that! Brad> 4. Handle disk labels enough to get newfs to work Don't forget, You still need to recognize ADOS disks without real disklabels. It's easy, but don't forget it. Brad> My plan now is to finish cleaning up the write code and Brad> implement disk labels. Then I can try newfs on it and get a Brad> read/write fs. Fun! Great work! Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 16:18:05 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Strange kernel problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Feb 28, 11:51am, Niklas Hallqvist wrote: > >>>>> "Michael" == Michael L Hitch writes: > > Michael> Try out this fix and see if it helps any. It has fixed the > Michael> problem I was having with the 940219 kernel. I finally > Michael> tracked it down when I created a kernel that would give me a > Michael> "init died" panic every time I tried to boot it. If I varied > Michael> the memory size, I could get it to run with no problem. > > I LOVE YOU! > > How on earth did you find this one, step by step? I was really going crazy... I first ran into the problem when I was just getting the 5380 driver code working on my homebuilt SCSI board. It would panic with "init died" when trying to start /sbin/init. I tried to figure out what what going on, but didn't spend too much time at it. When I configured all the SCSI drivers, the problem went away. Then, when the 940219 kernel came out, I had problems similar to yours when I tried to run it on an 8M system. The same kernel ran fine on my other system with 16M, but failed in the same way if I restricted the memory to 8M. It would get lots of errors on files when I tried to start up multi-user mode. This last weekend, I updated to the latest sources and was checking to see if the problem still existed. I found that 8M (8192K) would run fine, but when I reduced the memory to 7500K, it started failing. With 6500K, I got the "init died" panic - so I figured the two problems were related. The final straw came when I generated a kernel that would give me the panic when booting on a 16M system: 16384K would panic, but 16351K would run fine. At that point I decided I had to figure out what the problem was. After the panic, I rebooted AmigaDOS and looked at the kernel stack (my AmigaDOS startup doesn't add the 32 bit memory, so I can examine all the NetBSD memory from AmigaDOS; I've even got a little program that lets me examine the memory using virtual addresses). From the stack, it appeared that the execve of /sbin/init was failing, so I started putting printf statements in the execve routine to determine what error was occurring. Once I had narrowed it down to an error return from copyinstr, I started looking closely at that routine. It took me quite a while to figure out why it was returning an "error" code of 0x0004000. That turned out to be the maximum length of the string to copy. The gas bug that doesn't handle branch instructions properly resulted in that bogus return value. > To everyone: Are there any clear evidence that -O2 is bad? I believe Chris > took it out just in case. And I wonder: Why didn't the copyinstr bug hit > harder? It was *really* evil! I haven't noticed any problems with the kernel using the -O2 option (this is with the 2.5.6 version of gcc). Any problems I've had were all contributed to other bugs in the code. One bug only showed up with the -O2 option though. I originally thought it might be the optimization that caused the problem, but the real problem was an extraneous reference to an uninitialized variable. The copyinstr bug only hit if the destination address had the low 16 bits of the address zero. The size of available memory had a significant impact on when that would occur. In your case, you had to run quite a while before it occurred. I happened to get "lucky" and have it occur when trying to start init, or when starting multi-user mode. I think if gas had assembled the branch instruction correctly, it would have worked better, although not correctly. The incorrect code probably would have failed under certain conditions, depending upon the maximum length of the copy and upon the actual length of the string. Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 17:49:28 1994 From: rhealey@aggregate.com Subject: Re: Floppy driver To: mykes@shell.portal.com (Mike Schwartz) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1009 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Handling MS-DOS disks doesn't mean the filesystem. The IBM PCs have a Western > Digital floppy controller chip that writes sectors to floppy disk differently > than the amiga OS does. Fortunately, the Amiga hardware is capable of > reading and writing data compatible with the Western Digital controller, > but it's a > radically different program to do so. In other words, take that amigaOS > compatible floppy driver sources and you can only use the motor on/off and > head stepping code. The entire rest of the driver needs brand new and > custom code to read the WD controller format. > The AMIX floppy driver used tables of some sort and the same low level routines to write Amiga vs IBM format, both low and high, 1.44M, density. That might be an angle to look at... It also used a user mode process to do stuff that looks alot like what trackdisk does and had a weird ioctl interface that only that user mode daemon used. It appears the user mode daemon was used for writes only. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 19:45:59 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy driver To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1273 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I was talking about a lower level than the filesystem. MSDOS disks are > > formatted in a different way and all the track/sector information is > > different. The low level disk reading code has to be changed first > > so that it can even find any data on MSDOS disks. Once that is working > > the msdos filesystem that comes with netbsd can be used. > > Just as an aside - have you thought about looking at the PC0: driver > to see how Amiga resolved those differences? > > - Eric I think I know how to do it. There will be a bit or two in the minor # which tells the driver what type of disk it is. Then the code that does the track decoding can be different. What I'm not sure of though is if the MSDOS disk ca be handled in the same way as the amiga (on a track basis - not by sector). +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 20:02:01 1994 Subject: Re: Floppy driver From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I think I know how to do it. There will be a bit or two in the minor # > which tells the driver what type of disk it is. Then the code that does > the track decoding can be different. What I'm not sure of though is if > the MSDOS disk ca be handled in the same way as the amiga (on a track > basis - not by sector). Best to do the following with minor device #: DPUU D = density: 0=low (720/880) 1=high (1.44/1.76) P = PC? 0=amiga (880/1.76) 1=pc (720/1.44) U = unit (0-3) PC and Amiga formats both use MFM with 0x4489 as the sync pattern. The track I/O code can be shared. The sector decode code cannot. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 20:12:55 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy driver To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 815 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Brad> 4. Handle disk labels enough to get newfs to work > > Don't forget, You still need to recognize ADOS disks without real disklabels. > It's easy, but don't forget it. I have it working both ways now. I have a newfs formatted floppy in drive 0 and mounted. I also have an amiga formatted floppy in drive 1 mounted using adosfs (works great!). > Niklas > +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 20:21:00 1994 From: David L Miller Subject: Re: Floppy driver To: David Jones Cc: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Mon, 28 Feb 1994, David Jones wrote: > > I think I know how to do it. There will be a bit or two in the minor # > > which tells the driver what type of disk it is. Then the code that does > > the track decoding can be different. What I'm not sure of though is if > > the MSDOS disk ca be handled in the same way as the amiga (on a track > > basis - not by sector). > > Best to do the following with minor device #: > > DPUU > > D = density: 0=low (720/880) 1=high (1.44/1.76) > P = PC? 0=amiga (880/1.76) 1=pc (720/1.44) > U = unit (0-3) > Is it possible to leave expansion room for 2.88/3.52MB floppies? --DLM |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) University of Washington, Networks & Distributed Computing 4545 15th Ave NE, Seattle WA 98105, USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 20:31:29 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy driver To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1683 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I think I know how to do it. There will be a bit or two in the minor # > > which tells the driver what type of disk it is. Then the code that does > > the track decoding can be different. What I'm not sure of though is if > > the MSDOS disk ca be handled in the same way as the amiga (on a track > > basis - not by sector). > > Best to do the following with minor device #: > > DPUU > > D = density: 0=low (720/880) 1=high (1.44/1.76) > P = PC? 0=amiga (880/1.76) 1=pc (720/1.44) > U = unit (0-3) The density bit is not needed since the drive can be probed to find that out. Also the PC/amiga could be probed as well (read a track and try to decode using both methods - whichever one works is the proper type). But I think I'll use a bit for this since the track format probe would take a while. > PC and Amiga formats both use MFM with 0x4489 as the sync pattern. The > track I/O code can be shared. The sector decode code cannot. Yes I think I will be able to do this by only writing two new routines which handle sector <-> raw track for msdos type tracks. > -- > David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto > email: dej@eecg.utoronto.ca, finger for more info/PGP public key > +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 21:56:19 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy driver To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 883 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Is it possible to leave expansion room for 2.88/3.52MB floppies? > > --DLM Can you get 2.88/3.52 MB floppies for the amiga? How do they work? > |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 > |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) > University of Washington, Networks & Distributed Computing > 4545 15th Ave NE, Seattle WA 98105, USA +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 22:05:53 1994 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: niklas@appli.se (Niklas Hallqvist), pepersb@cuug.ab.ca From: mykes@shell.portal.com (Mike Schwartz) Subject: Re: Floppy driver Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu At 12:43 PM 2/28/94 +0000, Niklas Hallqvist wrote: >>>>>> "Brad" == Brad Pepers writes: > >Brad> Here is more status info on the floppy driver. It now works well >Brad> enough for adosfs to work on it. I can mount my amiga floppies >Brad> and copy files from them. Here is what I haven't done: > >Nice to hear that! > >Brad> 4. Handle disk labels enough to get newfs to work > >Don't forget, You still need to recognize ADOS disks without real disklabels. >It's easy, but don't forget it. > >Brad> My plan now is to finish cleaning up the write code and >Brad> implement disk labels. Then I can try newfs on it and get a >Brad> read/write fs. > >Fun! > >Great work! > >Niklas I have a bit of advise here. When I wrote MS-DOS or AmigaOS formatted floppies with my own drivers, I wrote two sectors on track 40 of the floppy to fool amigaos into thinking that the disk was indeed an AmigaOS disk but that it was 100% full. My reasoning was that when someone sticks a disk in the drive and sees a bad volume reported by amigaos, they'd consider formatting it to use it :-) With the 100% full (fill BAM sector with 0xffff), they saw the disk was valid and could not use DOS or some other program to write on the disk. What was involved was to use ADos to format a blank floppy then use a sector editor to dump track 40 sectors 0 and 1 and see for yourself what the format is. To add an ADOS disk label, there was an offset into sector 0 for a count+string (not null terminated) and a checksum. Sector 1 is the bam and should be all 0xffff. My floppy disk drivers would automatically skip writing or reading data from these two "magic" sectors. You also have to deal with track 0, where the boot sector goes. Otherwise ADOS will not see it is a valid dos disk. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 22:09:41 1994 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: pepersb@cuug.ab.ca (Brad Pepers), amiga-dev@sun-lamp.cs.berkeley.edu From: mykes@shell.portal.com (Mike Schwartz) Subject: Re: Floppy driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu At 11:40 AM 2/28/94 -0700, Brad Pepers wrote: > >> > I was talking about a lower level than the filesystem. MSDOS disks are >> > formatted in a different way and all the track/sector information is >> > different. The low level disk reading code has to be changed first >> > so that it can even find any data on MSDOS disks. Once that is working >> > the msdos filesystem that comes with netbsd can be used. >> >> Just as an aside - have you thought about looking at the PC0: driver >> to see how Amiga resolved those differences? >> >> - Eric > >I think I know how to do it. There will be a bit or two in the minor # >which tells the driver what type of disk it is. Then the code that does >the track decoding can be different. What I'm not sure of though is if >the MSDOS disk ca be handled in the same way as the amiga (on a track >basis - not by sector). > No you can't treat an MS-DOS disk as you would an ADOS disk. If my memory serves correct - and forgive me if it doesn't - we're going back at least 3 years :-) What I remember having to do was to turn on DMA on a sector by sector basis. And I think that the WD chip writes a magic MFM word (DSKSYN byte) before each sector. And I think that ADOS writes out even and odd bits to separate memory chunks (after you read in a track) but the WD chip does not - hence your blitter MFM encode/decode are radically different. I also remember that I had to determine wheter the DMA to be started was indeed for the sector I wanted. It would obviously help to get a DOS formatted floppy and examine it. >+----------------------------Ren & Stimpy--------------------------------+ >| "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | >| cheese. And you're the lemon merchant. Get it? And he knows it. That's | >| why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | >| loose the marmosets on us! Don't worry, little missy! I'll save you!" | >+------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 22:45:01 1994 X400-Originator: /dd.id=1619692/g=hamish/i=hi/s=macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.324:28.01.94.21.27.26] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Floppy dr... From: "hamish (h.i.) macdonald" To: pepersb@cuug.ab.ca Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floppy driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >> PC and Amiga formats both use MFM with 0x4489 as the sync pattern. >> The track I/O code can be shared. The sector decode code cannot. >>>>> Brad wrote: pepersb> Yes I think I will be able to do this by only writing two new pepersb> routines which handle sector <-> raw track for msdos type pepersb> tracks. I think that MSDOS tracks have to be written aligned to the index sync pulse. The MSH code triggers write DMA start on the occurence of an index sync interrupt (Flag interrupt on CIA B, interrupt level 6). From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 23:31:28 1994 Subject: Re: Floppy driver From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > No you can't treat an MS-DOS disk as you would an ADOS disk. If my memory > serves correct - and forgive me if it doesn't - we're going back at least 3 > years :-) What I remember having to do was to turn on DMA on a sector by > sector basis. And I think that the WD chip writes a magic MFM word (DSKSYN > byte) before each sector. And I think that ADOS writes out even and odd > bits to separate memory chunks (after you read in a track) but the WD chip > does not - > hence your blitter MFM encode/decode are radically different. I also remember > that I had to determine wheter the DMA to be started was indeed for the > sector I wanted. It would obviously help to get a DOS formatted floppy and > examine it. Paula has a signal called DSKSYNC. When this is set, Paula will wait for the 0x4489 sync word (common to MS-DOS and Amiga floppies) before starting DMA. Both Amiga and MS-DOS formats start each sector with a sync word. In both cases, it is best to enable DSKSYNC and do DMA for a full track (actually, a little more). Then use software-based functions to pick the data apart. For writing MS-DOS floppies, I'd take the trackdisk approach: buffer a whole track and rewrite all sectors at once. Block-level writing is too CPU-intensive on the Amiga. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 23:33:31 1994 From: Alan Bair Subject: Re: Floppy driver To: mykes@shell.portal.com (Mike Schwartz) Cc: niklas@appli.se, pepersb@cuug.ab.ca, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Mike Schwartz writes: > > I have a bit of advise here. When I wrote MS-DOS or AmigaOS formatted > floppies with my own drivers, I wrote two sectors on track 40 of the floppy > to fool amigaos into thinking that the disk was indeed an AmigaOS disk but > that it was 100% full. My reasoning was that when someone sticks a disk in > the drive and sees a bad volume reported by amigaos, they'd consider > formatting it to use it :-) With the 100% full (fill BAM sector with > 0xffff), they saw the disk was valid and could not use DOS or some other > program to write on the disk. > > What was involved was to use ADos to format a blank floppy then use a > sector editor to dump track 40 sectors 0 and 1 and see for yourself what > the format is. To add an ADOS disk label, there was an offset into sector > 0 for a count+string > (not null terminated) and a checksum. Sector 1 is the bam and should be all > 0xffff. My floppy disk drivers would automatically skip writing or reading > data from these two "magic" sectors. > > You also have to deal with track 0, where the boot sector goes. Otherwise > ADOS will not see it is a valid dos disk. > If bad blocks are supported for floppies under NetBSD, the special ADOS blocks could be marked as bad to avoid requiring special code to skip them. This could be setup when the disk is formated under NetBSD, though then the foramting program would need the special processing code, which could be an option. Also, it may be nice to put an ADOS name like "NetBSD_floppy" to make it easy to know what kind of disk this is on the ADOS side. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Feb 28 23:38:13 1994 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Alan Bair From: mykes@shell.portal.com (Mike Schwartz) Subject: Re: Floppy driver Cc: niklas@appli.se, pepersb@cuug.ab.ca, amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu At 4:05 PM 2/28/94 -0600, Alan Bair wrote: >Mike Schwartz writes: >> >> I have a bit of advise here. When I wrote MS-DOS or AmigaOS formatted >> floppies with my own drivers, I wrote two sectors on track 40 of the floppy >> to fool amigaos into thinking that the disk was indeed an AmigaOS disk but >> that it was 100% full. My reasoning was that when someone sticks a disk in >> the drive and sees a bad volume reported by amigaos, they'd consider >> formatting it to use it :-) With the 100% full (fill BAM sector with >> 0xffff), they saw the disk was valid and could not use DOS or some other >> program to write on the disk. >> >> What was involved was to use ADos to format a blank floppy then use a >> sector editor to dump track 40 sectors 0 and 1 and see for yourself what >> the format is. To add an ADOS disk label, there was an offset into sector >> 0 for a count+string >> (not null terminated) and a checksum. Sector 1 is the bam and should be all >> 0xffff. My floppy disk drivers would automatically skip writing or reading >> data from these two "magic" sectors. >> >> You also have to deal with track 0, where the boot sector goes. Otherwise >> ADOS will not see it is a valid dos disk. >> > >If bad blocks are supported for floppies under NetBSD, the special ADOS >blocks could be marked as bad to avoid requiring special code to skip them. >This could be setup when the disk is formated under NetBSD, though then the >foramting program would need the special processing code, which could be an >option. Also, it may be nice to put an ADOS name like "NetBSD_floppy" to >make it easy to know what kind of disk this is on the ADOS side. > Sounds like the hard way to do things... However, to label the disk, there's an offset as I mentioned in sector 0 of track 40 where you can put any label you want. You need to checksum the track and store it in the right offset as well. > >-- >Alan Bair MCTG AMCU DSCS >Motorola, Inc. (Design Software & >Mail Stop OE-320 Computer Services) >6501 William Cannon Dr. West (512) 891-2336 >Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com