From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 1 02:27:53 1994 From: Steve Parkinson Subject: More installation woes. To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1156 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Phew! 1) I kind of got my newfs problems sorted out. It seems it did all its stuff, then crashed right at the end, so I ran "fsck /dev/rsd0d", and it fixed it all up. 2) But I've been having a tar-nightmare, trying to install /usr/bin/, usr/lib, and /usr/sbin from my scratch /dev/rsd0e partition. a) first problem was a tar panicing with a virtual memory problem after a few files. I decided I needed to mount /tmp, and to do that I had to newfs it. .. well eventually it worked. b) next problem.. tar extracts 30 or so files, then panics with a wide variety of messages, including: pos=1;i=16;fs=/usr panic:alloccgblk: can't find block in cyl vm_fault(11c000,409000,1,0)->1 type 8 , code[mmu,,ssw]:545 (v = 40b302) panic: kmem_alloc: kmem_map too small (should wait) panic: holdreve (SP?) holdent panic: allocbuf:desired size is zero panic: vref used where vget required panic: pmap_remove: PA not in PV_tab (these were all in seperate sessions) Still, I just kept installing, and fsck'ing after the crashes, and everything seems to be in place now. I now have to find ld.so, which everything seems to want! Steve From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 1 10:13:36 1994 From: Max Leung Subject: Re: Problem with serial I/O with GVP To: amiga@sun-lamp.cs.berkeley.edu 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 Mar 1994, Max Leung wrote: > I installed the latest generic kernal (vmunix.generic.940325), and now > find that whenever there is disk activity, serial I/O gets mangled! > > This never happened with the 744 kernel (with DMA off). > > When I turn off DMA, the serial I/O doesn't get mangled as much. With DMA > enabled, I get download errors every 4 or 5 K. Seems like when rz flushes > the data to disk, the corresponding disk I/O corrupts the serial line. > > This sounds like the infamous GVP-controller-trashes-serial-I/O-because-its- > priority-is-too-high bug I've seen on the AmigaDOS side. > > Is there a way I can fix this, without recompiling the kernal? > > (I have an old GVP-Combo, 22 MHz, 13 megs of 32bit RAM, in an A2000 with > 1 meg chip. The only other board I have in it is the A2232 serial I/O > board, which does nothing under NetBSD. :-) ) I tried turning off everything, including setting _gvp11_dmamask to 4K (instead of 64K), turning off the gvp bounce buffer, and turning of scsi dma, but I still have serial I/O problems? Is there a fix? Please help! I haven't got a response to the above message. I'm wondering if anyone is receiving it... I'd really like to get serial transfers to work. Otherwise, I can't use Term nor can I use my Amiga as an X server for remote clients! > > Thanks, > Max Leung > > --------------------- > mleung@ee.ualberta.ca > From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 1 10:44:29 1994 From: Max Leung Subject: Re: Problem with serial I/O with GVP To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Mon, 28 Mar 1994, Max Leung wrote: > I installed the latest generic kernal (vmunix.generic.940325), and now > find that whenever there is disk activity, serial I/O gets mangled! > > This never happened with the 744 kernel (with DMA off). > > When I turn off DMA, the serial I/O doesn't get mangled as much. With DMA > enabled, I get download errors every 4 or 5 K. Seems like when rz flushes > the data to disk, the corresponding disk I/O corrupts the serial line. > > This sounds like the infamous GVP-controller-trashes-serial-I/O-because-its- > priority-is-too-high bug I've seen on the AmigaDOS side. > > Is there a way I can fix this, without recompiling the kernal? > > (I have an old GVP-Combo, 22 MHz, 13 megs of 32bit RAM, in an A2000 with > 1 meg chip. The only other board I have in it is the A2232 serial I/O > board, which does nothing under NetBSD. :-) ) I tried turning off everything, including setting _gvp11_dmamask to 4K (instead of 64K), turning off the gvp bounce buffer, and turning of scsi dma, but I still have serial I/O problems? Is there a fix? Please help! I haven't got a response to the above message. I'm wondering if anyone is receiving it... I'd really like to get serial transfers to work. Otherwise, I can't use Term nor can I use my Amiga as an X server for remote clients! > > Thanks, > Max Leung > > --------------------- > mleung@ee.ualberta.ca > From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Apr 1 11:10:56 1994 From: Philippe BRAND Subject: Re: Various ECS X-servers To: oster@skdad.usask.ca (Greg Oster) Cc: amiga-x@sun-lamp.cs.berkeley.edu (NetBSD Liste) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 633 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Greg Oster writes: > I don't know if you've uploaded the new version or not, but if you > have, where did you put it? (I'm dying to get ahold of it, and I can't > seem to track it down anywhere...) If you havn't uploaded it, could > you please do so when you have the time? The 5x speed increase would > make the color version much more usable... I feel very sorry but: - There're still some weird bugs in it so my friend's gonna work on it this week-end. - I've just bought a new house so expect a little delay. I hope to release it next week. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Co-Sysop 2:320/104.21 From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Apr 1 15:48:24 1994 From: William J Coldwell To: amiga-x@sun-lamp.cs.berkeley.edu Subject: XRetinaZ2 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Ok, what's the magic secret to getting past the "Can't find screen" error? I am able to run Xmono, so is this something that has to do with that fact that I'm trying to run X on the same "screen" as the kernel is on? -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 1 16:18:25 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: Building elm Sender: owner-amiga@sun-lamp.cs.berkeley.edu I wasn't sure if this should go to amiga-dev but its not to do with development of NetBSD itself so I figured it should be posted here. I'm trying to build elm (the Electronic Mail agent) on my NetBSD system. I have the 720 rootfs and binaries at present with some of the binary updates. I tried to build elm a few days ago and I got three link errors. All the compilation went smoothly. I installed X11R5 after this and the next time I tried to link I only got a single link error. I think this is due to an updated libc.a in the X11R5 distribution. The single link error is:- Undefined symbol _pathconf referenced from text segment. (Or something like that). On the Suns at work _pathconf is in libc . Do we have a newer libc anywhere which has this pathconf routine ? If I can get this thing built then I'll upload it to ftp.eunet.ch. Thanks for any help. +-------------------------------+--------------------------+ ! 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-dev@sun-lamp.cs.berkeley.edu Fri Apr 1 19:01:41 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Problem with serial I/O with GVP To: mleung@ee.ualberta.ca (Max Leung) Cc: amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1501 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > > On Mon, 28 Mar 1994, Max Leung wrote: > > > I installed the latest generic kernal (vmunix.generic.940325), and now > > find that whenever there is disk activity, serial I/O gets mangled! > > > > This never happened with the 744 kernel (with DMA off). > > > > When I turn off DMA, the serial I/O doesn't get mangled as much. With DMA > > enabled, I get download errors every 4 or 5 K. Seems like when rz flushes > > the data to disk, the corresponding disk I/O corrupts the serial line. > > > > This sounds like the infamous GVP-controller-trashes-serial-I/O-because-its- > > priority-is-too-high bug I've seen on the AmigaDOS side. > > > > Is there a way I can fix this, without recompiling the kernal? > > > > (I have an old GVP-Combo, 22 MHz, 13 megs of 32bit RAM, in an A2000 with > > 1 meg chip. The only other board I have in it is the A2232 serial I/O > > board, which does nothing under NetBSD. :-) ) > > I tried turning off everything, including setting _gvp11_dmamask to 4K > (instead of 64K), turning off the gvp bounce buffer, and turning of scsi > dma, but I still have serial I/O problems? Is there a fix? > > Please help! I haven't got a response to the above message. I'm wondering > if anyone is receiving it... > > I'd really like to get serial transfers to work. Otherwise, I can't use > Term nor can I use my Amiga as an X server for remote clients! > > > > > Thanks, > > Max Leung > > > > --------------------- > > mleung@ee.ualberta.ca > > > > From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 1 20:32:03 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Problem with serial I/O with GVP To: mleung@ee.ualberta.ca (Max Leung) Cc: amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1501 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > > On Mon, 28 Mar 1994, Max Leung wrote: > > > I installed the latest generic kernal (vmunix.generic.940325), and now > > find that whenever there is disk activity, serial I/O gets mangled! > > > > This never happened with the 744 kernel (with DMA off). > > > > When I turn off DMA, the serial I/O doesn't get mangled as much. With DMA > > enabled, I get download errors every 4 or 5 K. Seems like when rz flushes > > the data to disk, the corresponding disk I/O corrupts the serial line. > > > > This sounds like the infamous GVP-controller-trashes-serial-I/O-because-its- > > priority-is-too-high bug I've seen on the AmigaDOS side. > > > > Is there a way I can fix this, without recompiling the kernal? > > > > (I have an old GVP-Combo, 22 MHz, 13 megs of 32bit RAM, in an A2000 with > > 1 meg chip. The only other board I have in it is the A2232 serial I/O > > board, which does nothing under NetBSD. :-) ) > > I tried turning off everything, including setting _gvp11_dmamask to 4K > (instead of 64K), turning off the gvp bounce buffer, and turning of scsi > dma, but I still have serial I/O problems? Is there a fix? > > Please help! I haven't got a response to the above message. I'm wondering > if anyone is receiving it... > > I'd really like to get serial transfers to work. Otherwise, I can't use > Term nor can I use my Amiga as an X server for remote clients! > > > > > Thanks, > > Max Leung > > > > --------------------- > > mleung@ee.ualberta.ca > > > > From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 1 21:08:37 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: Building elm To: john@iceberg.demon.co.uk Cc: 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: 1060 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, John Shardlow wrote: > > I'm trying to build elm (the Electronic Mail agent) on my NetBSD > system. I have the 720 rootfs and binaries at present with some of > the binary updates. > > I tried to build elm a few days ago and I got three link errors. All > the compilation went smoothly. > > I installed X11R5 after this and the next time I tried to link I only > got a single link error. I think this is due to an updated libc.a in the > X11R5 distribution. > > The single link error is:- > > Undefined symbol _pathconf referenced from text segment. (Or something > like that). I tried to compile elm and got to the same position your at. I looked into the header files to determine what was happening. Further examination revealed that in the header file /usr/include/unistd.h: long pathconf __P((const char *, int)); /* not yet */ I would take this to mean that this function has not yet been added to the kernel. I too would like to get elm running on my machine, it's a lot nicer to use than mail. Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 2 00:22:47 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/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: csa12gdma.c mlhdma.c supradma.c Log Message: move HIST out of DEBUG conditional. --------------------------------- 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: moved everything over to sys/queue.h, from dlists.[ch] --------------------------------- 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 Removed Files: dlists.c dlists.h Log Message: moved everything over to sys/queue.h, from dlists.[ch] --------------------------------- 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: grfabs.c grfabs_cc.c grfabs_ccglb.c grfabs_ccreg.h grfabs_reg.h Log Message: dlists.h ==> sys/queue.h --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/lib/csu/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/csu/m68k Modified Files: crt0.c Log Message: no more MAP_FILE --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/lib/csu/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/csu/m68k Modified Files: crt0.c Log Message: explicit cast off mmap offset to off_t --------------------------------- 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 ser.c supradma.c Log Message: some scsi changes, 4M system hack, and a boot messgae addition. from Michael Hitch. --------------------------------- 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: autoconf.c machdep.c pmap.c Log Message: some scsi changes, 4M system hack, and a boot messgae addition. from Michael Hitch. --------------------------------- 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: cc not gcc, cpp not /lib/cpp -traditional --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/lib/libc/arch/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/lib/libc/arch/m68k Added Files: Makefile.inc Log Message: Need for copy-to-libkern-machdep in ../../Makefile --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/lib/libkern/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/lib/libkern/m68k Added Files: DEFS.h SYS.h bcmp.S bzero.S ffs.S htonl.S htons.S ntohl.S ntohs.S strcat.c strcmp.S strcpy.S strlen.S strncmp.S strncpy.S Log Message: copied over so lib/libc/arch not needed to build kernel. --------------------------------- 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: machdep.c Log Message: remove dlists.h oops. --------------------------------- 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_cc.c ite_cc.c ser.c view.c Log Message: remove dlists.h oops. --------------------------------- From: Charles Hannum Update of /b/source/CVS/src/lib/libc/arch/m68k/sys In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/lib/libc/arch/m68k/sys Added Files: lseek.S Log Message: Set d1 to -1 before cerror. --------------------------------- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Apr 2 01:03:06 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Make gives trapsignal Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I have been compiling kernel sources supped 940331, running a kernel from 940325 sources. My binaries are still 940219. When make wants to recursively make the kern library, i.e. making sure kern library is up to date I get trapsignal(1477, 11, -1, ffffffff, 2066c26) and make quits on error code 139. (128 + 11=SIGSEGV). Leaving this step out, and proceeding to link regardless, produces a "working" kernel (except that by now I've seen so many bugs reported about it that I will wait a bit before installing a new kernel.) A kernel from a week earlier didn't have this problem, and this was the first time I've seen it at all. PROCESSOR: CPU 68040/68882fpu CUSTOM CHIPS: AA PAL Alice (id=$0023), AA Lisa (id=$00F8) VERS: Kickstart version 39.106, Exec version 39.47, Disk version 39.29 RAM: Node type $A, Attributes $505 (FAST), at $7800000-$7FFFFFF (8.0 meg) Node type $A, Attributes $703 (CHIP), at $1000-$1FFFFF (~2.0 meg) BOARDS: Board + ROM (HD?) (unidentified): Prod=1056/12($420/$C) (@$E90000 64K) Unrelated, in amiga/machdep.c, I would propose one small change: add the indicated 'else'., identifycpu() { /* there's alot of XXX in here... */ printf ("AMIGA/"); if (is_a4000 ()) printf ("A4000"); /* XXX XXX */ >>>> else if (is_a3000 ()) printf ("A3000"); /* XXX */ else printf ("A2000"); -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 4 01:14:36 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: X11R5 dist To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I am having trouble installing new X apps on my system. It seems that whenever I build an X app it crashes with a segmentation fault (ktrace on one example gave a coredump after gethostname which wasnt in the source of the program itself). Whenever I install a precompiled binary however things work just great (ie. xdvi from the contrib directory). I'm not sure what is wrong but I suspect the libraries since the segmentation violation is happening at a point not in the source file. I do have GVP 16 bit ram in use but I am using a fixed assembler and the correct options for GCC to not use the bit operations. Possibly some of the X libs have problems with GVP 16 bit ram? (but if they do then why do the binaries I get run fine?). Some programs I have tried to compile include ghostscript and xdvi. Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 01:35: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-dev@sun-lamp.cs.berkeley.edu Subject: Re: Make gives trapsignal Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 2, 12:05am, Olaf Seibert wrote: > I have been compiling kernel sources supped 940331, running a kernel > from 940325 sources. My binaries are still 940219. > > When make wants to recursively make the kern library, i.e. > > making sure kern library is up to date > > I get > > trapsignal(1477, 11, -1, ffffffff, 2066c26) > > and make quits on error code 139. (128 + 11=SIGSEGV). Having just run into the same thing, I think your make binary is a bit older than the /usr/share/mk files. I fought this for several hours and finally restored an old /usr/share/mk directory. That allowed me to finish building the kernel. I then checked the version of make I was using and found I was building it from older sources. > Unrelated, in amiga/machdep.c, I would propose one small change: > add the indicated 'else'., > > identifycpu() > { > /* there's alot of XXX in here... */ > > printf ("AMIGA/"); > > if (is_a4000 ()) > printf ("A4000"); /* XXX XXX */ > >>>> else if (is_a3000 ()) > printf ("A3000"); /* XXX */ > else > printf ("A2000"); I already found that earlier last week :-). 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 Apr 4 02:51:08 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Make gives trapsignal Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu osymh@gemini.oscs.montana.edu (Michael L. Hitch) wrote: > Having just run into the same thing, I think your make binary is a > bit older than the /usr/share/mk files. I fought this for several hours > and finally restored an old /usr/share/mk directory. That allowed me to > finish building the kernel. I then checked the version of make I was > using and found I was building it from older sources. That must be the case. That's what happens if you carefully follow instructions and install the bsd.*.mk files ;-) Fortunately I have enough common sense not to follow the inctructions and install all new /usr/include/sys/* files, too. (But I did check, and indeed no kernel sources depend on /usr/include/sys/*.) I'll get the old ones back now. [fix for kernel printing A4000A2000 when booting] > I already found that earlier last week :-). Good, it was getting silly *grin*. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 04:37:02 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Binary releases and 64 bit off_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Now that NetBSD has converted to 64 bit off_ts, what should be done about binary releases? I'm in the process of building a new binary release, but if I understand the "current" mailing list correctly, almost everything else needs to be updated at about the same time. We are going to need a new X11 stuff, etc. [in addition to a new 64 bit root_fs for people starting out] Can we formulate a plan on all this stuff? -SR From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 4 05:01:13 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Binary releases and 64 bit off_t Sender: owner-amiga@sun-lamp.cs.berkeley.edu Now that NetBSD has converted to 64 bit off_ts, what should be done about binary releases? I'm in the process of building a new binary release, but if I understand the "current" mailing list correctly, almost everything else needs to be updated at about the same time. We are going to need a new X11 stuff, etc. [in addition to a new 64 bit root_fs for people starting out] Can we formulate a plan on all this stuff? -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 05:01:37 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, sjr@zombie.ncsc.mil Subject: Re: Binary releases and 64 bit off_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu SR wrote: > Now that NetBSD has converted to 64 bit off_ts, what should > be done about binary releases? Well, we know that the new kernel runs the old binaries, but the new binaries don't run on the old kernel. So before releasing new binaries, release the kernel first, and perhaps allow some time to shake the bugs out. Apparently, the binaries from the first week after the change aren't in too good a shape yet, and I would prefer this to be fixed first. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 4 05:16:27 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, sjr@zombie.ncsc.mil Subject: Re: Binary releases and 64 bit off_t Sender: owner-amiga@sun-lamp.cs.berkeley.edu SR wrote: > Now that NetBSD has converted to 64 bit off_ts, what should > be done about binary releases? Well, we know that the new kernel runs the old binaries, but the new binaries don't run on the old kernel. So before releasing new binaries, release the kernel first, and perhaps allow some time to shake the bugs out. Apparently, the binaries from the first week after the change aren't in too good a shape yet, and I would prefer this to be fixed first. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 06:49:57 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Binary releases and 64 bit off_t To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 697 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Now that NetBSD has converted to 64 bit off_ts, what should > be done about binary releases? > > I'm in the process of building a new binary release, but if I > understand the "current" mailing list correctly, almost > everything else needs to be updated at about the same time. > > We are going to need a new X11 stuff, etc. [in addition to > a new 64 bit root_fs for people starting out] > > Can we formulate a plan on all this stuff? Just hold off on releasing any bins or kernels for now. I need to make nesc. changes to the kernel to support all this and I have got to test it too. I have the changes mostly done but I have to rebuild alot of my system to test it. > -SR Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 4 07:10:36 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Binary releases and 64 bit off_t To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 697 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Now that NetBSD has converted to 64 bit off_ts, what should > be done about binary releases? > > I'm in the process of building a new binary release, but if I > understand the "current" mailing list correctly, almost > everything else needs to be updated at about the same time. > > We are going to need a new X11 stuff, etc. [in addition to > a new 64 bit root_fs for people starting out] > > Can we formulate a plan on all this stuff? Just hold off on releasing any bins or kernels for now. I need to make nesc. changes to the kernel to support all this and I have got to test it too. I have the changes mostly done but I have to rebuild alot of my system to test it. > -SR Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 12:31:07 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: Kernel Sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I recently tried to get the new sources from ftp.eunet.ch doing a 'get sys.tar.Z' in the source archive there. (does this tar-file include all softlinks and protections?) It looks like some significant files are missing there, for example i couldn't run a (succesfull) 'config GENERIC' because the /usr/src/conf/files and /usr/src/arch/amiga/conf/files.amiga and the makefile were missing (or had length of 0). I tried to use the old files i had from a (very) old distribution, but then the compiler failed on the first 'make depend' already yields /usr/lib/crt0.o: Undefined symbol _main referenced from text segment for the file genassym.c (first file ever referenced in Makefile). Any clues? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 4 19:39:59 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: disk label failure To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 405 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Info: A3000, superkickstart machine, 200M & 80M HDs, 8M Fast, 1M chip Kernel: 3/19/94 source Binaries: 3/19/94 source When my systems boots up, I am getting an error when it tries to create the mfs partion. The error states that it is having a problem identifying the disk type of the drive. Do I need a new /etc/disktab file? If so could someone mail their copy to me? Thanks, Ron Roskens From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 20:23:38 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Kernel Sources" (Apr 4, 11:28am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: markus@techfak.uni-bielefeld.de (Markus Illenseer), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Kernel Sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 4, 11:28am, Markus Illenseer wrote: > Subject: Kernel Sources > I recently tried to get the new sources from ftp.eunet.ch doing > a 'get sys.tar.Z' in the source archive there. > (does this tar-file include all softlinks and protections?) Ok, i got the sources from somewhere else, ftp.eunet.ch definitely has some problems with the NetBSD-current tree, Markus? Now i am running into the standard problems :-} Where does ntohs.c hide? I know it's generated somehow in the libkern/m68k - but why isn't it created for me? Do i miss this infamous ARCHIVE=m68k flag? (gna, this makes me somewhat impatient :-) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 21:16:11 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Kernel Sources To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: markus@techfak.uni-bielefeld.de, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 509 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Now i am running into the standard problems :-} > Where does ntohs.c hide? I know it's generated somehow in the > libkern/m68k - but why isn't it created for me? Do i miss this > infamous ARCHIVE=m68k flag? (gna, this makes me somewhat impatient :-) sounds like your binaries are quite old. you probably should remake config make then try again. Or upgrade to the latest binary release available on ftp.eunet.ch or should be on mirrors of sun-lamp's binary distributions. > Markus Illenseer Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 21:41:02 1994 From: mw@eunet.ch Subject: Re: Binary releases and 64 bit off_t To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 956 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Now that NetBSD has converted to 64 bit off_ts, what should > be done about binary releases? Well, although this might sound evil, I'd like to make the serious vote: *don't* go 64bit! This is one of the (few) pets taken over from 4.4 that *I* don't want in NetBSD. Now, what are we going to do? I simply don't think voluntarily introducing a MAJOR compatibility drawback to older software (on both the source and binary levels) is a bad thing, more so since this introduction doesn't give us anything new in exchange. Why should anyone need 64bit file sizes on a system like the amiga? Why do you want quad-arithmetic all over the place, for nothing? This is not really meant to be a flame, but it probably is.. (BTW: just because it's in 4.4 is no reason for me to not question 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@sun-lamp.cs.berkeley.edu Mon Apr 4 21:54:52 1994 From: mw@eunet.ch Subject: Re: Binary releases and 64 bit off_t To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 956 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Now that NetBSD has converted to 64 bit off_ts, what should > be done about binary releases? Well, although this might sound evil, I'd like to make the serious vote: *don't* go 64bit! This is one of the (few) pets taken over from 4.4 that *I* don't want in NetBSD. Now, what are we going to do? I simply don't think voluntarily introducing a MAJOR compatibility drawback to older software (on both the source and binary levels) is a bad thing, more so since this introduction doesn't give us anything new in exchange. Why should anyone need 64bit file sizes on a system like the amiga? Why do you want quad-arithmetic all over the place, for nothing? This is not really meant to be a flame, but it probably is.. (BTW: just because it's in 4.4 is no reason for me to not question 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 Mon Apr 4 22:52:18 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Binary releases and 64 bit off_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu reply to amiga-dev only please. Markus Wild spoketh: >Well, although this might sound evil, I'd like to make the serious >vote: *don't* go 64bit! This is one of the (few) pets taken over from >4.4 that *I* don't want in NetBSD. Now, what are we going to do? I simply >don't think voluntarily introducing a MAJOR compatibility drawback to >older software (on both the source and binary levels) is a bad thing, more >so since this introduction doesn't give us anything new in exchange. Why >should anyone need 64bit file sizes on a system like the amiga? Why do >you want quad-arithmetic all over the place, for nothing? This is not >really meant to be a flame, but it probably is.. (BTW: just because it's >in 4.4 is no reason for me to not question it...) As an option, this is fine, as a default, I don't think that would be a good idea. Growing the kernel size, plus making it slower, is not that good of a "benefit". Since a lot of the machines that we want to eventually support do not have an FPU, this would make it viciously slower (it's bad enough that the current binaries are compiled for the FPU (to the best of my knowledge), which I think shouldn't be since they are the default binaries, but that's my own nit). Basically, I want to keep the general attitude of "you do with your own kernel and binaries what you want", but for the default stuff, it should be small, fast, and not require a lot to get it going. Does this seem too dictatorial? -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 4 23:14:25 1994 From: mw@eunet.ch Subject: Re: Binary releases and 64 bit off_t To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1165 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > as an option, this is fine, as a default, i don't think that would be a good > idea. growing the kernel size, plus making it slower, is not that good of a > "benefit". since a lot of the machines that we want to eventually support do make 64bit an option, and i'm all for it. default should be no 64bit, agreed. > not have an fpu, this would make it viciously slower (it's bad enough that > the current binaries are compiled for the fpu (to the best of my knowledge), > which i think shouldn't be since they are the default binaries, but that's my hm.. is there a full fpu-emulator available yet? i thought we're still running in fpu-only mode, not? > your own kernel and binaries what you want", but for the default stuff, it > should be small, fast, and not require a lot to get it going. does this seem > too dictatorial? hm, default == small also means not all available drivers are included. i'd say, "small" is an attribute for custom made kernels, too. otherwise, ok. -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 Apr 4 23:44:33 1994 From: rhealey@aggregate.com Subject: Re: Binary releases and 64 bit off_t 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: 2480 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Markus Wild spoketh: > >Well, although this might sound evil, I'd like to make the serious > >vote: *don't* go 64bit! This is one of the (few) pets taken over from > >4.4 that *I* don't want in NetBSD. Now, what are we going to do? I simply > >don't think voluntarily introducing a MAJOR compatibility drawback to > >older software (on both the source and binary levels) is a bad thing, more > >so since this introduction doesn't give us anything new in exchange. Why > >should anyone need 64bit file sizes on a system like the amiga? Why do > >you want quad-arithmetic all over the place, for nothing? This is not > >really meant to be a flame, but it probably is.. (BTW: just because it's > >in 4.4 is no reason for me to not question it...) > > As an option, this is fine, as a default, I don't think that would be a good > idea. Growing the kernel size, plus making it slower, is not that good of a > "benefit". Since a lot of the machines that we want to eventually support do > not have an FPU, this would make it viciously slower (it's bad enough that > the current binaries are compiled for the FPU (to the best of my knowledge), > which I think shouldn't be since they are the default binaries, but that's my > own nit). Basically, I want to keep the general attitude of "you do with > your own kernel and binaries what you want", but for the default stuff, it > should be small, fast, and not require a lot to get it going. Does this seem > too dictatorial? > The > 2G drives are rapidly coming down in price. I can see within a year where it would be possible to need such a thing. As far as size bloat, how about waiting to see what it actually is? Not everything uses off_t type... Let's see what the actual result is before throwing it out. I personally am against changing the default on something this fundemental vs the other NetBSD ports. This is supposed to be NetBSD after all. Will we also not add in the other 4.4 changes that all the other ports will have (and will no doubt add bloat to the kernel)? If it's to be called NetBSD then it should have all the features and functions that all the other ports have. If not then start a new BSD, like the FreeBSD and 386BSD people have. Maybe we should just call a spade a spade and remove the amiga section from NetBSD and create our own version of BSD? If this port isn't going to integrate the NetBSD code in all the other ports then why call it NetBSD? -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 4 23:44:38 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: Offer from Macrosystem Development Sender: owner-amiga@sun-lamp.cs.berkeley.edu So, I was calling up Macrosystem Dev to ask them what pricing my "friends" could get (cause we all know I don't have any ;-)) on a Warp Engine, and was frankly, knock off my feet... Since NetBSD-Amiga supports the Retina Z2, Retina Z3, and the Warp Engine, they were willing to cut everyone here a deal. If you use NetBSD-Amiga, they'll give you a 1 board only price of: $600 Base Warp Engine (no 040, supply your own) $825 25MHz Warp Engine $980 33MHz Warp Engine $1150 40MHz Warp Engine Prices are US dollars, and boards come with no RAM. Warp Engine is a 3000/4000 series CPU slot accelerator with a SCSI-2 controller, and a high speed memory controller. Up to 128M on the 4000 version, and 64M on the 3000 version. The Warp Engine doesn't care about your Buster, DMAC, motherboard rev, and, get this... it'll even run AmigaOS should you want to... nahhhh.. NetBSD rules. MacroSystem Development: (810) 347-3332 -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 00:25:58 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Binary releases and 64 bit off_t Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9404041928.AA00306@icecube.cryogenic.com> billc@iceCuBE.cryogenic.com writes: > Markus Wild spoketh: > >Well, although this might sound evil, I'd like to make the serious > >vote: *don't* go 64bit! This is one of the (few) pets taken over from > >4.4 that *I* don't want in NetBSD. Now, what are we going to do? I simply > >don't think voluntarily introducing a MAJOR compatibility drawback to > >older software (on both the source and binary levels) is a bad thing, more But Markus, there is no binary compatibility problem. Yes, there were a few teething problems within NetBSD itself (it is an alpha release, after all!), but once those were fixed userland binaries compiled months ago continue to work just fine. Yes, a few programs that make bad assumptions may need source changes before they get rebuilt, but this is no excuse. Should NetBSD go to 14-char filenames to preserve compatibility with programs that made bad V7-based assumptions? I don't want to be shackled forever to the past. > >so since this introduction doesn't give us anything new in exchange. Why It *does* give us things in exchange! > >should anyone need 64bit file sizes on a system like the amiga? Why do I think this is really short-sighted. Nobody will ever need >4GB files and disks (remember that off_t effects disk and partition size limits too!) on the Amiga just like nobody will ever need more than 640K ram, more that 32M partitions, and just like nobody will ever to use a disk with more than 1000 cyls. 4GB+ disks are availible *today*. There are already people using 2.5GB disks on the Amiga with NetBSD, maybe even larger. There is no reason why they shouldn't be able to use 11GB disks that are availible today right now. There are already AmigaDOS users bumping that OS's 4GB limits too. Also consider that NetBSD/amiga users might want to mount remote filesystems and operate on >4GB files there (databases, for example). I don't see how this can be described as "for nothing", or a future concern. This is a real issue now. > >really meant to be a flame, but it probably is.. (BTW: just because it's > >in 4.4 is no reason for me to not question it...) This reply isn't meant to be a flame either... but I do think it is an important issue. Also, I agree that 4.4 isn't the issue. I would be pushing for 64 bit off_t's even if 4.4 didn't have them :-) > As an option, this is fine, as a default, I don't think that would be a good It can't easily be made an option. 32 bit off_t binaries can run on 64 bit kernels fine, but not vice-versa... also, I think binary compatibility with other 68k NetBSDs is important. > idea. Growing the kernel size, plus making it slower, is not that good of a Without any hard numbers on the performance impact, attacking the feature because it MIGHT be slow is a bad idea... History has shown that programmers are completely unreliable in determining performace impacts of various changes, which is why profiling was born. I would like to see some benchmarks for 32bit vs 64 bit kernels before any decision is made. So far, though, I haven't heard anyone on current-users complain about ay speed losses. > "benefit". Since a lot of the machines that we want to eventually support do > not have an FPU, this would make it viciously slower (it's bad enough that Huh? The FPU isn't used for quad_t's. quad_t's are implemented by gcc as a pair of longs, not as a double. (although off_t as a double is an interesting concept... does that mean you could lseek(fd, bitnumber/8.0, SEEK_SET) for bit adressing of files? :->) > the current binaries are compiled for the FPU (to the best of my knowledge), > which I think shouldn't be since they are the default binaries, but that's my > own nit). Basically, I want to keep the general attitude of "you do with Well, in reality virtually every accelerated Amiga with a MMU has an FPU, so it's not as bad as if NetBSD/i386 required a FPU... > your own kernel and binaries what you want", but for the default stuff, it > should be small, fast, and not require a lot to get it going. Does this seem > too dictatorial? If it were that easy it might not be too bad, but it's not just something you can make optional easily... see above. If the default were 32-bit, it would make it almost impossible for people to set up 64-bit systems. At that point, it'd almost be like two different architectures, and since disks are getting steadily bigger the change is bound to be made back to 64 bit sooner or later. Probably sooner. (come to think of it, isn't of_t signed? That would make the 32 bit limit 2GB, not 4GB...) -- 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 Apr 5 00:31:20 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Binary releases and 64 bit off_t To: mw@eunet.ch Cc: 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 > > > as an option, this is fine, as a default, i don't think that would be a good > > idea. growing the kernel size, plus making it slower, is not that good of a > > "benefit". since a lot of the machines that we want to eventually support do > make 64bit an option, and i'm all for it. default should be no 64bit, agreed. we cannot make sizeof(off_t) an option. What a headache helping users that would be, not to mention what the kernel would look like when you finished adding support for conditionally different sized paramter lists for syscalls. Anyway, I don't feel 100% good about the switch however it also just doesn't have this big impact that you guys are implying. Regardless NetBSD amiga will continue to remain compatible with all the other ports so if you want this changed you should take it up in one of the more generic NetBSD groups. BTW You know alot of amiga developers *2* years ago were working with C= on ideas on how to allow file offsets >2M. They felt is was worthwhile for amiga's. Feel lucky its much easier for us to make the change. (People like Randal Jesup and other Amiga personnel and developers like Joanne Dow.) In the end its a smart change, don't ever let yourself forget the 640k barrier. :^) > -Markus Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 00:52:49 1994 From: rhealey@aggregate.com Subject: Floppy driver 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: 2178 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Has there been any progress on getting a mostly working floppy driver in to the main source tree? At least something would be better than what we have now. Additionally, anybody have the programming info on the RAMDAC used in the A2410 card? I have the 340x0 programming and reference guides thanks to TI generousity, and 50 minutes on the phone trying to convince them that I wasn't interested in their newest wiz-bang graphics controller that replaces the 340x0 line... It looks like a text display wouldn't be too bad but you'd have to write a full blown GM for graphics mode and that would add ~64k to the kernel; OUCH! More likely is you'd run an ioctl and squirt the code down to the board only when you needed it thus saving kernel memory for more important things. Can the RAMDAC support the 16 bit deep bitblane capability of the 340x0? It would be cool to have a 64K color X server! Apparently the 340x0 can handle 1,2,4,8 and 16 bits deep in the same number of read/write cycles so 64K mode might even be spunky! While I'm rambling, I was able to mount the NetBSD partitions under AmigaUNIX read only. Any idea if I will nuke the BSD file system if I mount them read/write and let AMIX scribble on them? Device nodes look bizarre due to the weird bit allocation for major/minor on SVR4 but everything else seems to be OK. Also, for those that might still be running AmigaUNIX. You can bump the number of supported partitions from 8 to 16 by editing /usr/sys/amiga/alien/sd.h and changing the sdpart macro mask from 07 to 0xf. For prettyness sake you may want to edit the scsi printf's in sdpart.c and dd.c to change the partition field from %d to %x to keep the values 0-f in device names. I have 14 partitions on my disk to cover AmigaUNIX, ADOS and NetBSD. As far as device nodes go you can change in to /dev/{r}dsk/c?d1s? and rename them to c?d0s{8-f}. I think they originally intended to use the high bit for multiple drives on the same target but never got around to actually doing it. Finally, anybody working on a workable audio device? A mute Amiga is a sad Amiga... It needs to sing every once in a while! B^). -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 01:11:13 1994 From: mw@eunet.ch Subject: Re: Binary releases and 64 bit off_ty To: rhealey@aggregate.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2519 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > The > 2G drives are rapidly coming down in price. I can see within a > year where it would be possible to need such a thing. Hey, even if so, wouldn't you rather make several partitions on such a drive? Anyway, I still think this HAS to be an option, only a (small) minority of our user base will ever face such decisions... > As far as size bloat, how about waiting to see what it actually is? > Not everything uses off_t type... Actually, for me it's even more an issue of software compatibility (I'm not even talking binary compatibility for a change:-)), the current system is very handy to compile all sorts of available sources, without having to dwelve into each and every source file to "fix" some incompatibilities (howdy solaris 2...). I don't want to lose this state. This (my) goal *might* be contrary to goals of other NetBSD communities. > Let's see what the actual result is before throwing it out. Sure, just make the extension conditional... > I personally am against changing the default on something this > fundemental vs the other NetBSD ports. This is supposed to be I don't rate it THAT fundamental, it is one aspect of 4.4, nothing more. > NetBSD after all. Will we also not add in the other 4.4 changes > that all the other ports will have (and will no doubt add bloat to > the kernel)? If it's to be called NetBSD then it should have all the My opinion here is: look at each feature, rate its usefulnes, what will it add to the system, what are the drawbacks. If the pros outweight the cons, go for it, if not, nuke it. I don't care VERY much about the name of the resulting system, I think it would be nice if we could continue the very close relationship to the other ports, but I (with my very own personal kernel :-)) will probably go my own way if NetBSD was to develop unconditionally into 4.4. Since we have source to all systems, this decision doesn't look as tough to make as if we'd be on a binary-only dependency. > features and functions that all the other ports have. If not then > start a new BSD, like the FreeBSD and 386BSD people have. That would be the easiest solution, but I'm optimistic for now that perhaps there is a less drastic solution? Easy solutions are rarely optimal. I'll be away for the next 4 weeks, I'll try to read some mail during that time, but I can't guarantee. -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 Apr 5 01:19:12 1994 From: mw@eunet.ch Subject: Re: Binary releases and 64 bit off_t To: chopps@emunix.emich.edu (Chris Hopps) Cc: mw@eunet.ch, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 948 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > we cannot make sizeof(off_t) an option. What a headache helping users that > would be, not to mention what the kernel would look like when you finished > adding support for conditionally different sized paramter lists for syscalls. Eh, it's a one-time decision before you build your kernel, after that, sizeof(off_t) will give what it's supposed to, either 4 or 8. As for syscalls, the table is generated automatically, shouldn't be too hard to telling it to watch this option. Don't panic here, it's not something that is changing all over the place, and using "off_t" everwhere where it's supposed to be used (you'll HAVE to watch for this anyway with 8 byte off_t's) everything should continue to work just as well if you're saying off_t is 4 byte, not 8. Never mind :-) -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 Apr 5 01:23:29 1994 From: mw@eunet.ch Subject: Re: Floppy driver To: rhealey@aggregate.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 867 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > While I'm rambling, I was able to mount the NetBSD partitions under > AmigaUNIX read only. Any idea if I will nuke the BSD file system if > I mount them read/write and let AMIX scribble on them? Device nodes > look bizarre due to the weird bit allocation for major/minor on > SVR4 but everything else seems to be OK. Safest thing would probably be to convert the filesystems "fsck -c" before moving them. Owner/group info and device node information is stored at different places, so although Amix would probably be able to find the information on the BSD filesystem (because it's stored at the "traditional" place), the oposite is almost certainly not true. Why don't you export it with NFS? -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 Apr 5 01:34:51 1994 From: rhealey@aggregate.com Subject: Re: Binary releases and 64 bit off_ty To: mw@eunet.ch 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: 2957 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > The > 2G drives are rapidly coming down in price. I can see within a > > year where it would be possible to need such a thing. > > Hey, even if so, wouldn't you rather make several partitions on such a drive? > Anyway, I still think this HAS to be an option, only a (small) minority of > our user base will ever face such decisions... > Large database applications would require > 2G filesystems... > > Let's see what the actual result is before throwing it out. > Sure, just make the extension conditional... > As Chris pointed out this would require ALOT of changes in areas outside the amiga tree to support. It would be difficult to get such changes in to the non-Amiga area of the tree. > > I personally am against changing the default on something this > > fundemental vs the other NetBSD ports. This is supposed to be > I don't rate it THAT fundamental, it is one aspect of 4.4, nothing more. > Actually, changing the size off off_t does impact alot of areas all over the OS tree. It's non-trivial to have #ifdef's in all sorts of places, the main maintainers would probably disagree with the attempt. If all the other ports can handle it why not us? > My opinion here is: look at each feature, rate its usefulnes, what > will it add to the system, what are the drawbacks. If the pros > outweight the cons, go for it, if not, nuke it. I don't care VERY much > about the name of the resulting system, I think it would be nice if we > could continue the very close relationship to the other ports, but I > (with my very own personal kernel :-)) will probably go my own way if > NetBSD was to develop unconditionally into 4.4. Since we have source to > all systems, this decision doesn't look as tough to make as if we'd be on > a binary-only dependency. > I guess this is where the biggest difference is. I see it as being more important that the Amiga port match the other netbsd ports as closely as possible so we can use as much of the goodies ported to NetBSD as possible. By picking and choosing features we then have to create our own setup for various pd packages, i.e. a touch of NetBSD, a smidgin' of SunOS m68k, a pinch of 4.3, a dab of 4.4 and a sprinkling of ???. I'd rather do a configure netbsd than have to tweek the gobs of net software for this feature left out and this one changed slightly. You could always use the netbsd config as a base but why bother changing it from netbsd? Seems a waste of effort when there are better things to do then add special case ifdefs, only for Amiga, over the kernel, library and bin sources. As Ty said, let's see how bad performance really gets. The 386 FPUless guys aren't bitching about crappy performance so that might not be an issue on smaller Amiga setups. It would also be interesting to see if the kernel could handle both sizes as is claimed by the core BSD team. I.e. program for 64 bit but still be able to run old 32 bit code. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 02:08:01 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Binary releases and 64 bit off_ty Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <199404042205.AAA03279@eunet.ch> mw@eunet.ch writes: > Hey, even if so, wouldn't you rather make several partitions on such a drive? I wouldn't... Besides, what happens to /dev/sdXc on such a drive? > Anyway, I still think this HAS to be an option, only a (small) minority of > our user base will ever face such decisions... I think that minority is a lot larger than you realize. For one thing, NetBSD is going to attract power users... it demands a lot of memory, reasonably fast processor, and disk to begin with, and people who will spend for that are likely to spend for big disks as well, especially with the prices on them plummeting like they are. That minority will get even larger with time. I have been running NetBSD on a system with a >2GB disk for several months now. I haven't used the last partiton (the one over 2GB yet), because I didn;'t want to trash anything else. I've been running a sun3 with a 1G disk for about two years. This isn't a rare and unusual thing to do, nor am I a wealthy hacker with lots of bucks to blow on luxuries... > Actually, for me it's even more an issue of software compatibility > (I'm not even talking binary compatibility for a change:-)), the > current system is very handy to compile all sorts of available > sources, without having to dwelve into each and every source file to > "fix" some incompatibilities (howdy solaris 2...). I don't want to But the off_t change doesn't seem to be that big a deal in reality... certainly no worse than the sys_errlist change or a slew of other things that have changed in NetBSD. Besides which, many commercial unicen either already have gone or are going this way, so it'll soon be the norm, and all the free software out there will migrate to it. Shoot, not that long from now, *not* having big off_t's could cause portability problems! > Sure, just make the extension conditional... Do you have a way to actually do this? Cleanly? I think the changes needed to support both would probably add more bloat than just going 64bit. > > I personally am against changing the default on something this > > fundemental vs the other NetBSD ports. This is supposed to be > > I don't rate it THAT fundamental, it is one aspect of 4.4, nothing more. Yes, but if every other port goes to big off_t's, it WILL be a fundamental difference between ports that will cause no end of headaches. I think losing compatibility with the rest of NetBSD is far worse than any of the disadvantages, real or immagined, of the off_t change. There are all little things each of us dislikes about NetBSD, and nobody's going to get their own way every time. However, I'm willing to live with the results rather than having a hundred different variants. FreeBSD vs NetBSD is already enough of a mess, let's not make it worse. If you really hate 64 bit off_t's, then bring it up on current-users. If it's bad for the amiga, it's surely just as bad for the other ports, no? Heck, the speed impact should be worse on the i386 since they have fewer general purpose registers to use. Whatever the final decision of NetBSD as a whole, though, I think we should live with it. (And another question.. how come those of you who are opposed to the off_t change aren't protesting the uid_t/gid_t changes as well? Surely they have a similar effect.) -- 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 Apr 5 02:08:51 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: possible bug 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 encountered some pretty strange behaviour. I was copying files over from my /usr onto a new partition to make a bigger /usr partition. The new partition had a single directory named 'local'. The old partition had a symbolic link 'local' pointing to the new partition. I then did a 'cp -R * /mnt' from the old /usr partition where 'mnt' was my new partition. The symlink 'local' over-wrote my old directory local (to my suprise). When I rebooted the machine and fsck ran through it barfed on my new /usr partition. I had to run fsck through manually to fix the problem. The old 'local' directory appeared in the lost+found directory. It appears that the symlink replaced the old entry in the directory without touching the old inode or directory. I dont have any "trash" partitions to try to repeat this problem on and haven't looked through the filesystem sources yet. Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 05:01:32 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Binary releases and 64 bit off_ty Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Two issues, #1 off_ty, #2 FPU default. 1) My stance on this is based on the fact that what we have works, and that adding something like this could change it. Wait a sec, read on first, count to 10, breathe deep. I want this marked as a base, and that this base is what we give out _until_ we get these other issues (stability, impact, etc) resolved. Does this sound unreasonable? I want to see the proliferation of NetBSD-Amiga, and I don't see this happening until we can at least give the illusion that we're not at each other's throats over "religious" issues. When we're still getting unexplained panics, and reliability problems, we're going to add in low level changes? I'm all for Rambo hacking, but we need to make sure that the newbie user isn't a casualty of this. 2) Thinking that most every CPU with an MMU has an FPU, is not reasonable. Just to quote a few, Mega Midget Racers (25-33MHz 030, 881/2 option), Derringer (25-50MHz 030, 881/2 option), Twelve Gauge (33-50MHz 030, 881/2 option), MBX1200 (25-50MHz 030, 881/2 option), a couple of the 50MHz German boards for the 3000 only has an 030. They don't make a 50MHz MMUless 030, so that counts for a pretty large number of people capable of running NetBSD-Amiga, but not if the binaries require an FPU. This spans 1000s-3000s, since Commodore decided that the 4000/30 is a wussy little EC part. There's the GVP boards for the 2000, though I can't recall if they offered the FPU as an option or not. The 3000, and the 2500 machines (2620/2630) came with FPUs as default. I can see no reason why someone with the adequate CPU, memory, and harddrive space shouldn't be allowed to run NetBSD on an A1000, just because they don't have an FPU. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 5 06:54:09 1994 From: Arthur Hoffmann Subject: DEL key.... how to ? 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: 253 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I was just wondering if someone knows how I can use the DEL key as a DEL key, rather than as a backspace key? thanks Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@nutmeg.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 07:13:45 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Binary releases and 64 bit off_t Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9404050113.AA00552@icecube.cryogenic.com> billc@iceCuBE.cryogenic.com writes: > Two issues, #1 off_ty, #2 FPU default. That should be "off_t". I think "off_ty" happened when I hit y at the subject instead of confirmation prompts. You might say it was a TYpo. :-> (double pun!) > 1) My stance on this is based on the fact that what we have works, and that > adding something like this could change it. Wait a sec, read on first, count > to 10, breathe deep. I want this marked as a base, and that this base is Well, -current is, by nature, constantly changing, and it will continue to do so. There are many major changes ahead before 1.0 happens, some of which will doubtless cause more trouble than the off_t change. (eg, I'm sure all hell is going to break loose when 4.4-Lite arrives...) > When we're still getting unexplained panics, and reliability problems, we're > going to add in low level changes? I'm all for Rambo hacking, but we need to > make sure that the newbie user isn't a casualty of this. I'm not sure here wether you're pro- or anti- off_t changes here. If you want to preserve the status quo, at least for now, that imples you want to *keep* the off_t change, at least for now. The change has already been made, attempting to undo it or make it optional will only add to the instability. It's wonderful that the Amiga port is now being maintained on sun-lamp, is current with -current, etc. I think it would be a bad idea to diverge again and losse these advantages. It also means more work when someone decides to sync up with -current again. > 2) Thinking that most every CPU with an MMU has an FPU, is not reasonable. Note that I didn't say it was OK, just that it wasn't as bad an assumption on the Amiga as for other plaforms (like the 386, where almost nobody has 387's, and many 486's are 486sx's) > part. There's the GVP boards for the 2000, though I can't recall if they > offered the FPU as an option or not. The 3000, and the 2500 machines The FPU was not an option on those boards, as far as I know... it was standard equipment. > (2620/2630) came with FPUs as default. I can see no reason why someone with > the adequate CPU, memory, and harddrive space shouldn't be allowed to run > NetBSD on an A1000, just because they don't have an FPU. I agree. I also see no reason why someone with large drives shouldn't be allowed to use them as well :-). (Heck, percentagewise the no-FPU minority is shrinking while the big-disk minority is growing!) -- 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 Tue Apr 5 09:40:15 1994 From: Calvin Chu Subject: questions To: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu WaitForSomething(): select: errno=35 Apr 4 20:39:23 hamburger /netbsd: ser0: silo overflow Why is WaitForSomething() (and what is it?) what is a silo overflow? o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' di Michigan! Va blu!!!!!!!!!!!!! """""""""""""""""""""""""""" Finger for PGP Public Key Block and Fingerprint From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 12:30:07 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Binary releases and 64 bit off_t" (Apr 4, 3:12pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Binary releases and 64 bit off_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 4, 3:12pm, rhealey@aggregate.com wrote: > Maybe we should just call a spade a spade and remove the amiga section > from NetBSD and create our own version of BSD? If this port isn't going > to integrate the NetBSD code in all the other ports then why call it > NetBSD? I don't think this would be a good idea! This would remove all the benefits we have (there are!) from beeing inside the NetBSD-tree - finally something where the Amiga is incorporated in, and you want to hide this away? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 5 13:27:28 1994 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Offer from Macrosystem Development" (Apr 4, 1:09pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: billc@icecube.cryogenic.com, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Offer from Macrosystem Development Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 4, 1:09pm, William J Coldwell wrote: > $825 25MHz Warp Engine Interesting price! Beats almost everything i know, even 3640 is at 850$US (w/o SCSI). > Prices are US dollars, and boards come with no RAM. uses Motherboard-RAM i hope. > MacroSystem Development: (810) 347-3332 That is Macrosysems US? Macrosystems Germany doesn't advertise for such boards, hey have but VLab, Retina Z2/BLT, Toccata and Maestro - no CPU board yet. Any reviews/tests avail for this board? -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 14:45:55 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Binary releases and 64 bit off_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >That should be "off_t". I think "off_ty" happened when I hit y at the I think it became subliminal to have your name it it at some point. Good work. ;-) >> 1) My stance on this is based on the fact that what we have works, and >>that adding something like this could change it. [...] I want this marked >>as a base >Well, -current is, by nature, constantly changing, and it will continue Right, that's not the problem. I expect those that are up and running can go off and get the -current stuff.. I'm concerned with those that are more than willing to run NBSD, but can't because of our own self-imposed restrictions. >> When we're still getting unexplained panics, and reliability problems, >>we're going to add in low level changes? I'm all for Rambo hacking, but we >>need to make sure that the newbie user isn't a casualty of this. >I'm not sure here wether you're pro- or anti- off_t changes here. I am neither because I really don't care whether future kernels have it or not (He's waffling!). What I do care about is that there isn't a -stable, a solid working base that gets the problems that we are having fixed, before something major is added (incidently I was bitten by the syserrorlist being changed, compiling IRC.. thought it was pretty strange). Basically, we don't have something that we can say "Yep, burn this puppy on CDROM, and ship it." or "Hey Fred, here's 10 disks for a special NetBSD-Amiga distribution for ya!", and this is a stage that I really really want to see happen. >> 2) Thinking that most every CPU with an MMU has an FPU, is not reasonable. >Note that I didn't say it was OK, just that it wasn't as bad an >assumption on the Amiga as for other plaforms (like the 386, where >almost nobody has 387's, and many 486's are 486sx's) My mistake, I took it that way. >>I can see no reason why someone >with the adequate CPU, memory, and >>harddrive space shouldn't be allowed to >run NetBSD on an A1000, just >>because they don't have an FPU. >I agree. I also see no reason why someone with large drives shouldn't >be allowed to use them as well :-). (Heck, percentagewise the no-FPU >minority is shrinking while the big-disk minority is growing!) I respectfully disagree, and I've stated why, but let's not beat a dead FPU. I'll toss in the idea of thinking about the # of 2000s, 500s and 1200s out there, to the 3000s and 4000s. Again, I'm advocating the low-midend Amiga user here, the one with the 100-300M drive, on the souped up Amiga 500 with the 1084 monitor who wants to dabble in "unix". I think we have "power users" covered with the current kernels. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 5 15:15:49 1994 From: William J Coldwell To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: Offer from Macrosystem Development Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu ill writes: > uses Motherboard-RAM i hope. 4-32M 72pin SIMMs. 80ns@25, 70ns@33, 60ns@40MHz, with a jumper for a waitstate should you want to use a slower stick at a higher speed. Pretty much, pull your memory off of your 4000/40 and put it on the board. >> MacroSystem Development: (810) 347-3332 > That is Macrosysems US? Macrosystems Germany doesn't advertise for >such boards, hey have but VLab, Retina Z2/BLT, Toccata and Maestro - >no CPU board yet. That's correct, it has nothing to do with Macrosystems Germany. This offer is only valid through Macrosystem Development (a division of Macrosystem US). > Any reviews/tests avail for this board? anonftp ftp.cryogenic.com /pub/incoming/warp.lha for benchmark tests results. No reviews available yet, as it takes a while for reviews to hit the 'zines. Please follow-up any additional questions to me in e-mail or with Macrosystem Development, so that we don't turn this list into a commercial issue (which is probably starting to happen in this case). -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 5 15:45:40 1994 From: Markus Landgraf To: amiga-x@sun-lamp.cs.berkeley.edu Subject: xbsdcc[24]: resolution fixed ? Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Hi, this weekend I tried to get the xbsdcc color Xserver running on my A2024. It worked well but only in PAL resolution (640x566). There was no way to tell the server to use 1024x1024x2, like the old Xamiga server. To get the old Xamiga server running with 1024x1024x2, I had to modify the view default sizes is src/sys/arch/amiga/dev/view.c and to recompile the kernel. So the default resolution for opening a /dev/view is set correctly, this leads to the assumption that the new X servers xbsdcc force the resolution to be the hardcoded value 640x566. Is there a way to change the resolution for these servers ? ------------------------------------------------------------------------------ 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-dev@sun-lamp.cs.berkeley.edu Tue Apr 5 19:21:40 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Binary releases and 64 bit off_ty" (Apr 5, 12:05am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: mw@eunet.ch, rhealey@aggregate.com Subject: Re: Binary releases and 64 bit off_ty Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 5, 12:05am, mw@eunet.ch wrote: > I'll be away for the next 4 weeks, I'll try to read some mail during that > time, but I can't guarantee. Warm greetings to all our friends in the US :-) Try convince Fred Fish to use IRC, make a photo of Guardian juggling with 9 balls and destroy the FreeBSD-master CD at Walnut *grin*. Oops, back to NetBSD. -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 5 19:42:27 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "xbsdcc[24]: resolution fixed ?" (Apr 5, 2:14pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Markus Landgraf , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: xbsdcc[24]: resolution fixed ? Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 5, 2:14pm, Markus Landgraf wrote: > Subject: xbsdcc[24]: resolution fixed ? > Hi, Time to update the X FAQ... > this weekend I tried to get the xbsdcc color Xserver running on my > A2024. It worked well but only in PAL resolution (640x566). There was > no way to tell the server to use 1024x1024x2, like the old Xamiga > server. To get the old Xamiga server running with 1024x1024x2, I had > to modify the view default sizes is src/sys/arch/amiga/dev/view.c and > to recompile the kernel. So the default resolution for opening a > /dev/view is set correctly, this leads to the assumption that the new > X servers xbsdcc force the resolution to be the hardcoded value > 640x566. Brr. Ever heard of iteconfig? This nifty programm changes the size and the colors of the console _online_. No need to compile your own kernel or to use binpatch! This way it is easy to change the comsole size from 640x480 (NTSC/PAL) to 1024x1024 for A2024. The new xbsdcc X servers don't read the size of the console and open a hard-coded screen, as you remarked already. You need to patch the server. Get a binary editor (heck, even the vi does it) and look for the (binary) value 640 (0x280 ?) and change it into 1024. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 5 20:09:58 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "questions" (Apr 5, 2:12am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Calvin Chu , NetBSD-Amiga List Subject: Re: questions Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 5, 2:12am, Calvin Chu wrote: > Subject: questions > WaitForSomething(): select: errno=35 > Apr 4 20:39:23 hamburger /netbsd: ser0: silo overflow > > Why is WaitForSomething() (and what is it?) > > what is a silo overflow? Serial line overflow on device ser0, and WaitForSomething() waits for something on the serial line , duh. If you want some more specific answers, please send us more details. (when, where, what) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 5 20:11:51 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "DEL key.... how to ?" (Apr 5, 1:08pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Arthur Hoffmann , amiga@sun-lamp.cs.berkeley.edu Subject: Re: DEL key.... how to ? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 5, 1:08pm, Arthur Hoffmann wrote: > Subject: DEL key.... how to ? > Hi, > I was just wondering if someone knows how I can use the DEL key as > a DEL key, rather than as a backspace key? loadkmap or xmodmap (loadkmap is in /usr/src/sys/arch/amiga/stand, xmodmap comes with X11) -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 5 21:32:02 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: xbsdcc[24]: resolution fixed ? To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: landgraf@crunch.ikp.physik.th-darmstadt.de, amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1002 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > Brr. > Ever heard of iteconfig? This nifty programm changes the size and > the colors of the console _online_. No need to compile your own > kernel or to use binpatch! This way it is easy to change the > comsole size from 640x480 (NTSC/PAL) to 1024x1024 for A2024. When the next set of bins come out iteconfig will be in /usr/sbin :^) and man iteconfig will produce something. > The new xbsdcc X servers don't read the size of the console and open > a hard-coded screen, as you remarked already. You need to patch the > server. Get a binary editor (heck, even the vi does it) and look > for the (binary) value 640 (0x280 ?) and change it into 1024. Won't work the server will die. I posted a while ago but the person missed it (pretty easy it was back when the servers where released) that 2024 people are basically SOL becuase the xbsdcc servers don't give the user full enough control over the view. Hopefully in a future release this will be resolved. > Markus Illenseer Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 6 00:23:21 1994 From: Calvin Chu Subject: Re: questions To: Markus Illenseer Cc: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Tue, 5 Apr 1994, Markus Illenseer wrote: > > Why is WaitForSomething() (and what is it?) > > > > what is a silo overflow? > > Serial line overflow on device ser0, and WaitForSomething() waits > for something on the serial line , duh. I get more WaitForSomething()'s than the silo overflows. In fact, I only got two overflows in the past 3 days, and I have no idea what caused it. WaitForSomething() comes up in groups of 3 and 4.. I'm running X over PPP, if that helps at all. The exact error(s) look like this: WaitForSomething(): select: errno=35 WaitForSomething(): select: errno=35 WaitForSomething(): select: errno=35 o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' di Michigan! Va blu!!!!!!!!!!!!! """""""""""""""""""""""""""" Finger for PGP Public Key Block and Fingerprint From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 04:20:55 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: ADOSFS LKM Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Boy, was it easy to make the ADOSFS a LKM. If I don't count compile times and reboot time, I guess I spent no more than 10 minutes. I'll provide a new package tomorrow for the daring. Chris, why haven't you installed the sys/mount.h (and sys/malloc.h) patch? We need to reserve a number for MOUNT_ADOSFS in order to make a LKM distr usable for people who can't compile their own kernels. And yes, option LKM must be added to the GENERIC configs. It's be nice if this gets done before the next kernel binary distr. Niklas PS. I *want* the GCC configuration files. I'm building a cross compilation environment on my Power PC system. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 6 04:42:45 1994 X-Mailer: DUUCPv1.17b X-Reader: GRn2.0k From: barnhill@zinder.do.open.de (Larry Barnhill) To: amiga@sun-lamp.cs.berkeley.edu Subject: re-Offer from Macrosystem Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Mon, 4 Apr 94 13:09:17 -0700, William J Coldwell said: >So, I was calling up Macrosystem Dev to ask them what pricing my "friends" >could get (cause we all know I don't have any ;-)) on a Warp Engine, and was >frankly, knock off my feet... [ ----- ] >MacroSystem Development: (810) 347-3332 Sir, could you please include the mailing address or net address of Macrosystem Development? I would like to contact them to place an order. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software ---- barnhill@zinder.do.open.de ( L. Barnhill ) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 05:05:34 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, niklas@appli.se Subject: Re: ADOSFS LKM Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Boy, was it easy to make the ADOSFS a LKM. If I don't count compile > times and reboot time, I guess I spent no more than 10 minutes. > I'll provide a new package tomorrow for the daring. Chris, why > haven't you installed the sys/mount.h (and sys/malloc.h) patch? > We need to reserve a number for MOUNT_ADOSFS in order to make a > LKM distr usable for people who can't compile their own kernels. > > And yes, option LKM must be added to the GENERIC configs. It's > be nice if this gets done before the next kernel binary distr. The vmunix.generic-YYMMDD files that I upload to ftp.eunet.ch have LKM as an option. -SR From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 6 09:37:03 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: 940319 binaries To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I just (finally) upgraded the binaries on my system with the 940319 binaries from eunet. I'm still running a 744 kernel for the time being. I've noticed two problems so far though: o mfs doesn't mount properly now. An IOCTL error occurs. o when I login the tty is set at -echoe so my erase characters show up visibly until I stty echoe. Is the mfs problem due to my /usr/sbin and kernel mismatch? (Will this go away as soon as I upgrade kernels?). Also telnet still reports an ioctl error trying to set the TOS. I thought the 744 kernel had the proper changes for this already and that the new binaries worked fine (this problem came in with an ioctl change between 720 and 744 kernels as I remember it). thanx... Tim N. From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Apr 6 11:10:01 1994 From: Markus Landgraf To: markus@techfak.uni-bielefeld.de Cc: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: xbsdcc[24]: resolution fixed ? Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu >>>>> "Markus" == Markus Illenseer writes: Markus> On Apr 5, 2:14pm, Markus Landgraf wrote: >> Subject: xbsdcc[24]: resolution fixed ? Hi, Markus> Time to update the X FAQ... >> this weekend I tried to get the xbsdcc color Xserver running on >> my A2024. It worked well but only in PAL resolution >> (640x566). There was no way to tell the server to use >> 1024x1024x2, like the old Xamiga server. To get the old Xamiga >> server running with 1024x1024x2, I had to modify the view >> default sizes is src/sys/arch/amiga/dev/view.c and to recompile >> the kernel. So the default resolution for opening a /dev/view >> is set correctly, this leads to the assumption that the new X >> servers xbsdcc force the resolution to be the hardcoded value >> 640x566. Markus> Brr. Ever heard of iteconfig? This nifty programm Markus> changes the size and the colors of the console Markus> _online_. No need to compile your own kernel or to use Markus> binpatch! This way it is easy to change the comsole size Markus> from 640x480 (NTSC/PAL) to 1024x1024 for A2024. This is true for /dev/grf0, but /dev/view is a bitmap orientated device, it opens a bitmap with the desired size. So the application, the Xserver in this case, dictates the resolution. But, to be sure, I tried to change the resolution with iteconfig and used the old Xamiga server. The result was, starting from a 1024x1024 console the Xserver switched back to 640x400, the default size of the views, of course. Markus> The new xbsdcc X servers don't read the size of the Markus> console and open a hard-coded screen, as you remarked Markus> already. You need to patch the server. Get a binary editor Markus> (heck, even the vi does it) and look for the (binary) Markus> value 640 (0x280 ?) and change it into 1024. Thank You. This I will try next. ------------------------------------------------------------------------------ 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-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 13:38:13 1994 From: chammer@hrz.uni-bielefeld.de Subject: some minor problems To: amiga-dev@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, My DAT streamer now works with the 744-kernel (later kernels don't work, unfortunately) Only all multitasking stops while rewinding. Then there is still a problem with key-repeating while working with the streamer or the cdrom. Is there anywhere a not "devtofiled" version of the rootfs? I have some problems where to put some commands(where should there be the xdm start command? where is a version of xdm that works "with" passwords?) and it would be nice to have a example of a rootfs to look at. Is it ok that system hangs if there occurs the following "user error"?: I mount a cd and go somewhere in their tree. Then i take it out and insert another cd without unmounting and mounting it. Now I do a cd somewhere to a directorie on the cd that is not in the cdrom and the system hangs immedeatly.? ciao Carsten PS: it seems to me as if the file sys/arch/m68k/m68k/process_machdep.c on ftp.uni-regensburg in the netbsd-current tree is crippled. -- Carsten Hammer Schwindstr. 7 33615 Bielefeld Fakultaet fuer Physik D4-139 chammer@POST.uni-bielefeld.de From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 17:13:14 1994 From: danny@astro.rug.nl Subject: Re: Binary releases and 64 bit off_ty To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 936 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu William J. Coldwell wrote: > resolved. Does this sound unreasonable? I want to see the proliferation of > NetBSD-Amiga, and I don't see this happening until we can at least give the > illusion that we're not at each other's throats over "religious" issues. [ VISIONARY MODE ON ] Maybe I'm wrong, but my opinion is that NetBSD-Amiga is kept alive (and has come to life) mainly by those people that were interested in porting Mach and eventually The Hurd. Just as any work on AmigaMach has stopped in favour of NetBSD, I think (not fear |{) that everybody that is working will be satisfied with a NetBSD that is stable enough to port (or develop for) Mach & The Hurd. Religious issues or not, as work on The Hurd is progressing more and more rapidly NetBSD-Amiga may become nothing more than a tool faster than anyone can imagine at this moment. [ VISIONARY MODE OFF ] Danny From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 18:12:53 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Binary releases and 64 bit off_ty To: danny@astro.rug.nl Cc: billc@iceCuBE.cryogenic.com, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1090 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I, at least, am not working on NetBSD-Amiga so as to directly facilitate later developement of Mach or Hurd. It'll be nice for whoever if it helps. I personally have my doubts that Hurd will ever run on even the above average amiga (run in this context means usable). I, however, fail to understand why this discussion continues on this list. I guess maybe everyone didn't understand---NetBSD-Amiga will remain NetBSD-Amiga. off_t *has* been changed across the board (all ports for at least 2 weeks now) If you *really* want to change this (I don't..) you are going to have to convince NetBSD (not simply amiga) to do so. If you succeed in this then NetBSD-Amiga along with all the other ports will change back. (not likekly to happen) The off_t IMO is a good thing when all is said and done. I think maybe all involved have not considered (even though Ty pointed it out) off_t limits the size of the disk (not only fs's and files) that you can mount under NetBSD. Would you have the maximum HD size be <=2G? I think thats lacking right now let alone in the next year. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 19:23:17 1994 From: rhealey@aggregate.com Subject: Re: ADOSFS LKM 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: 935 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Boy, was it easy to make the ADOSFS a LKM. If I don't count compile > times and reboot time, I guess I spent no more than 10 minutes. That's GREAT news! > I'll provide a new package tomorrow for the daring. Chris, why > haven't you installed the sys/mount.h (and sys/malloc.h) patch? Those appear to be outside the Amiga tree so I image Chris has to talk to the core development team first and get their OK to mess with stuff outside of the Amiga port... > PS. I *want* the GCC configuration files. I'm building a cross > compilation environment on my Power PC system. > Yes, it would be nice to have them! By the way, you doing a PPC NetBSD port!?!?! I have some salivating coworkers that would probably like to talk to you if you do. I've got 2 more years left on my Ami before I chuck it for something else, probably a PrEP PPC or maybe a SPARC if they can get the price/performance up to a decent level. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 19:25:07 1994 From: rhealey@aggregate.com Subject: Re: Binary releases and 64 bit off_ty To: danny@astro.rug.nl 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: 1896 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > William J. Coldwell wrote: > > resolved. Does this sound unreasonable? I want to see the proliferation of > > NetBSD-Amiga, and I don't see this happening until we can at least give the > > illusion that we're not at each other's throats over "religious" issues. > > [ VISIONARY MODE ON ] > Maybe I'm wrong, but my opinion is that NetBSD-Amiga is kept alive (and > has come to life) mainly by those people that were interested in porting > Mach and eventually The Hurd. > Just as any work on AmigaMach has stopped in favour of NetBSD, I think (not > fear |{) that everybody that is working will be satisfied with a NetBSD > that is stable enough to port (or develop for) Mach & The Hurd. > Religious issues or not, as work on The Hurd is progressing more and more > rapidly NetBSD-Amiga may become nothing more than a tool faster than > anyone can imagine at this moment. > [ VISIONARY MODE OFF ] > Enter soapbox mode: Why would anyone want to use a system from FSF? They have a long track record of only going 90% or so of the way and the rest is left as an excercise to the end user... They also would put a much more restricted license on the use of the software. i.e. I don't want any work I'm doing to be restricted in any way. Mach and The Hurd are probably dead ends anyways. FSF has been talking about the Hurd, or it's predicessors, for almost a decade now and so far that's all it's been; talk. At least NetBSD is here now and is going to be reasonably close to the industry standard API's. Best of all I can use the code any way I choose with no restrictions. NetBSD will be more of a viable OS than Hurd will ever be. Already many small companys are thinking of ports to it. I have yet to hear any indications The Hurd will have any sort of commercial support. End soapbox mode: -Rob #include Speaking for myself only of course. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 6 19:38:14 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: NetBSD won't boot after upgrade from 1mb chip to 2mb chip From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hai, I've recently upgraded my chip mem from 1 to 2 mb. Now NetBSD won't boot anymore. It stops after checking for the real time clock. If I remove the 1mb card it works. Does anyone know if there is a patch for this ? My system is an A500 plus with the GForce '030 Combo. Before the chipmem upgrade it worked okay. PS: AmigaDOS cannot find my battery backed up clock anymore also. John From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 19:42:27 1994 From: Hubert Feyrer To: amiga-dev@sun-lamp.cs.berkeley.edu, danny@astro.rug.nl Subject: Re: Binary releases and 64 bit off_ty Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I can only speak for myself, but with me it was the other way round: I got interested in Mach as it was promised to get _some_ kind of unix on my Amiga. Having NteBSD running, I'm quite happy with it. Haven't seen Mach/the Hurd yet. Regards, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 21:47:30 1994 From: niklas@appli.se (Niklas Hallqvist) To: rhealey@aggregate.com Cc: danny@astro.rug.nl, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Binary releases and 64 bit off_ty Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Rob" == rhealey writes: >> William J. Coldwell wrote: > resolved. Does this sound >> unreasonable? I want to see the proliferation of > NetBSD-Amiga, >> and I don't see this happening until we can at least give the > >> illusion that we're not at each other's throats over "religious" >> issues. >> >> [ VISIONARY MODE ON ] Maybe I'm wrong, but my opinion is that >> NetBSD-Amiga is kept alive (and has come to life) mainly by those >> people that were interested in porting Mach and eventually The >> Hurd. Just as any work on AmigaMach has stopped in favour of >> NetBSD, I think (not fear |{) that everybody that is working will >> be satisfied with a NetBSD that is stable enough to port (or >> develop for) Mach & The Hurd. Religious issues or not, as work on >> The Hurd is progressing more and more rapidly NetBSD-Amiga may >> become nothing more than a tool faster than anyone can imagine at >> this moment. [ VISIONARY MODE OFF ] >> Rob> Enter soapbox mode: Rob> Why would anyone want to use a system from FSF? They have a Rob> long track record of only going 90% or so of the way and the rest Rob> is left as an excercise to the end user... They also would put a Rob> much more restricted license on the use of the software. i.e. I Rob> don't want any work I'm doing to be restricted in any way. Rob> Mach and The Hurd are probably dead ends anyways. FSF has been Rob> talking about the Hurd, or it's predicessors, for almost a decade Rob> now and so far that's all it's been; talk. At least NetBSD is Rob> here now and is going to be reasonably close to the industry Rob> standard API's. Best of all I can use the code any way I choose Rob> with no restrictions. Rob> NetBSD will be more of a viable OS than Hurd will ever Rob> be. Already many small companys are thinking of ports to it. I Rob> have yet to hear any indications The Hurd will have any sort of Rob> commercial support. Rob> End soapbox mode: Please, please, keep religion out of this group. Although I have strong opinions on this matter, I don't want to see a discussion here! We could easily start another group for netbsd vs. mach/hurd or any other OS if it's necessary. However tech-discussions and technical comparisions of OSs I'd think well can go here, but not religous statements. Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 6 21:51:45 1994 From: niklas@appli.se (Niklas Hallqvist) To: rhealey@aggregate.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: ADOSFS LKM Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Rob" == rhealey writes: >> PS. I *want* the GCC configuration files. I'm building a cross >> compilation environment on my Power PC system. >> Rob> Yes, it would be nice to have them! By the way, you doing a Rob> PPC NetBSD port!?!?! I have some salivating coworkers that would Rob> probably like to talk to you if you do. I've thought about it, but really I have no more time to spend, so I have put such plans aside. AIX is quite nice even though it is proprietary. Besides, this PowerPC system is for everyday commercial work, so it has to have to be bootable when the morning comes. You just can't be sure of such things if you mess with OS dev. unless you have separate disks. No, spare time will go into G++ and the GNU PowerPC toolchain, and then NetBSD-Amiga as a third project. OK, I'll start packaging the LKM adosfs version now, it should be out in an hour or so. Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 00:07:38 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "NetBSD won't boot after upgrade from 1mb chip to 2mb chip" (Apr 6, 4:42pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , amiga@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD won't boot after upgrade from 1mb chip to 2mb chip Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 6, 4:42pm, John Vrolijk wrote: > Hai, I've recently upgraded my chip mem from 1 to 2 mb. > Now NetBSD won't boot anymore. It stops after checking for > the real time clock. Had upgraded my A2000 to 2MB Chip, too, and never had any problems. > PS: AmigaDOS cannot find my battery backed up clock anymore also. I guess this is the problem, it's a hardware problem i fear. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Apr 7 00:28:41 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: LKM-adosfs.shar Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu OK here it is! Note that you need to be able to compile your own kernel for now. This will go away, once sun-lamp sources has allocated a MOUNT_ADOSFS value in sys/mount.h (and some malloc tags in sys/malloc.h). You also need the original adosfs.tar.gz distr from ftp.eunet.ch. Enjoy, Niklas # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # README.LKM # Makefile # adosfsmod.c # echo x - README.LKM sed 's/^X//' >README.LKM << 'END-of-README.LKM' XThese instructions presumes you can compile your own kernel as Xthe core source don't yet have MOUNT_ADOSFS in sys/mount.h, Xmeaning binary kernel distributions are not ready for the XLKM ADOSFS. Hopefully this changes soon, and then new Xinstallation instructions will be available. X XIn order to make your ADOSFS a loadable kernel module, you have Xto do this: X XI Install kernel-resident ADOSFS, available in a separate X package, the way the README in that package states. X Don't recompile the kernel yet! X XII Remove the options ADOSFS (and ADOSFSDEBUG, if you had it) X from your config file. Make sure options LKM is in there. X XIII do a config, make depend (important!) and a make of the X kernel. You may as well boot it now. X XIV Enter the adosfs directory, and copy the following files X there: X X Makefile X adosfsmod.c X XV make X XVI try it out by typing: "make load" X Note: the kernel code contains lots of debug statements, X don't bother, unless something seems wrong. X XVII Check it's loaded via "modstat" X XVIII Try mounting an ADOS partition as per the original instructions X from the kernel-resident distribution. X XIX Try unloading, by unmounting all ADOSFS partitions and do X "make unload" X END-of-README.LKM echo x - Makefile sed 's/^X//' >Makefile << 'END-of-Makefile' XCFLAGS= -O2 -I.. -I../sys -DKERNEL -DADOSFS -DADOSFSDEBUG XOBJS= adosfs_anode.o adosfs_blocks.o adosfs_util.o \ X adosfs_vfsops.o adosfs_vnops.o adosfsmod.o X Xadosfs.o: $(OBJS) X $(LD) -r -o $@ $(OBJS) X Xload: X modload -o adosfs -eadosfsmod adosfs.o X Xunload: X modunload -n adosfs END-of-Makefile echo x - adosfsmod.c sed 's/^X//' >adosfsmod.c << 'END-of-adosfsmod.c' X/* X * adosfsmod.c X * X * 01 Apr 94 Niklas Hallqvist X * X * adapted from: kerfsmod.c by X * X * 05 Jun 93 Terry Lambert Original X * X * Copyright (c) 1993 Terrence R. Lambert. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * 3. All advertising materials mentioning features or use of this software X * must display the following acknowledgement: X * This product includes software developed by Terrence R. Lambert. X * 4. The name Terrence R. Lambert may not be used to endorse or promote X * products derived from this software without specific prior written X * permission. X * X * THIS SOFTWARE IS PROVIDED BY TERRENCE R. LAMBERT ``AS IS'' AND ANY X * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE TERRENCE R. LAMBERT BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X * X * $Id: adosfsmod.c,v 1.1 1994/04/04 17:25:39 root Exp $ X */ X#if 0 X#include X#include "sys/param.h" X#include "sys/ioctl.h" X#endif X#include "sys/systm.h" X#include "sys/conf.h" X#include "sys/mount.h" X#include "sys/exec.h" X#include "sys/lkm.h" X#if 0 X#include X#include "sys/file.h" X#include "sys/errno.h" X#endif X X/* X * This is the vfsops table from /sys/miscfs/adosfs/adosfs_vfsops.c X */ Xextern struct vfsops adosfs_vfsops; X X/* X * Currently, the mount system call is broken in the way it operates X * and the vfssw[] table does not have a character string identifier X * for the file system type; therefore, to remount a file system after X * it has been mounted in the first place, the offset into the table X * must be the same; this will be corrected in future patches, but X * not right now. At the same time the fstab format will need to X * change to allow definition without mount of file systems. X * X * The flags field is a parameter to the init; this could be used to X * change the file system operation: for instance, in ISOFS, this X * could be used to enable/disable Rockridge extensions. X */ XMOD_VFS("adosfs",MOUNT_ADOSFS,0,&adosfs_vfsops) X X/* X * This function is called each time the module is loaded. Technically, X * we could have made this "nosys" in the "DISPATCH" in "adosfsmod()", X * but it's a convenient place to kick a copyright out to the console. X */ Xstatic int Xadosfsmod_load( lkmtp, cmd) Xstruct lkm_table *lkmtp; Xint cmd; X{ X if( cmd == LKM_E_LOAD) { /* print copyright on console*/ X printf( "\nLoaded AmigaDOS file system\n"); X printf( "Copyright (c) 1994 Niklas Hallqvist\n"); X printf( "All rights reserved.\n"); X printf( "\nLoader stub and module loader is\n"); X printf( "Copyright (c) 1993\n"); X printf( "Terrence R. Lambert\n"); X printf( "All rights reserved\n"); X } X X return( 0); X} X X X/* X * External entry point; should generally match name of .o file. The X * arguments are always the same for all loaded modules. The "load", X * "unload", and "stat" functions in "DISPATCH" will be called under X * their respective circumstances unless their value is "nosys". If X * called, they are called with the same arguments (cmd is included to X * allow the use of a single function, ver is included for version X * matching between modules and the kernel loader for the modules). X * X * Since we expect to link in the kernel and add external symbols to X * the kernel symbol name space in a future version, generally all X * functions used in the implementation of a particular module should X * be static unless they are expected to be seen in other modules or X * to resolve unresolved symbols alread existing in the kernel (the X * second case is not likely to ever occur). X * X * The entry point should return 0 unless it is refusing load (in which X * case it should return an errno from errno.h). X */ Xadosfsmod( lkmtp, cmd, ver) Xstruct lkm_table *lkmtp; Xint cmd; Xint ver; X{ X DISPATCH(lkmtp,cmd,ver,adosfsmod_load,nosys,nosys) X} X X X/* X * EOF -- This file has not been truncated. X */ END-of-adosfsmod.c exit From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 17:28:09 1994 From: mbeausej@qc.bell.ca (michel beausejour) To: amiga@sun-lamp.cs.berkeley.edu Subject: a2065 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I have bought a used a2065 for my a3000 ,running netbsd. I'am trying to hook up my 3000 and my 1200.(i have the I-card for the 1200).My setup is not working and i'm looking for the jumpers information of the 2065,i have no information for that card.There is a bunch of jumpers and i suspect that may be my problem cause when i boot NetBSD it detect the card and the ethernet address.The coax cable has been proved ok and both terminators(50 ohm).On the A1200 the I-card has 2 leds (one is actvity and the other is good link) both are not lit. So it seems that my connection is bad.The I-card is new so i suspect the setup of the 2065. Thanks, Michel Beausejour mbeausej@qc.bell.ca From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 17:38:32 1994 From: Douglas Slotta Subject: Rebuilding the rootfs. To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1252 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello, I am using an Amiga 3000 with the 720 rootfs and the 940319 kernal and binaries. I am trying to rebuild according to the instructions. When I get to the line 'tar clfp - | (cd /newroot ; tar xvlfp - )' I get a broken pipe. Any idea what is wrong? Also, the 940319 binaries seem to be missing several libraries, beside the *crypt* ones, such as libc.so.1.1. I wa lucky enough to have the old 720 binaries around to replace it. And finally, I have been having a problem with a thin red vertical line that appears about 2/3rds of the screen from the left side. This happens about every 3 or 6 times I boot NetBSD from AmigaDOS. I have not been able to reproduce this at will, so I can't give any more information. Has anyone else seen this? Thank you for your time. -- ____ __ / __ \ / / Down with categorical imperatives! / / / /______ __ __ ______ / / ______ ______ Anarchy rules! / / / // __ // / / / / _ // / / __ // ____/ Drawing on my fine / /_/ // /_/ // /_/ / / /_/ // /_ / __ /_\__ / command of language, /_____//_____//_____/ _\__ //___//_/ /_//_____/ I said nothing. dslotta@gauss.onu.edu/_____/ Dyslexics of the world, untie! From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 18:48:09 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "a2065" (Apr 7, 8:18am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: mbeausej@qc.bell.ca (michel beausejour), amiga@sun-lamp.cs.berkeley.edu Subject: Re: a2065 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 7, 8:18am, michel beausejour wrote: > Subject: a2065 > Hi, > I have bought a used a2065 for my a3000 ,running netbsd. I'am trying to hook up my 3000 > and my 1200.(i have the I-card for the 1200).My setup is not working and i'm looking for Um, can you do a 'CR' every and so 70 chars please? There are NO (!) jumpers to set on the A2065 in order to make the card work under NetBSD. I suspect that your setup is wrong, check ifconfig and the netmask... -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 20:11:24 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Rebuilding the rootfs." (Apr 7, 8:27am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Douglas Slotta , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Rebuilding the rootfs. Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 7, 8:27am, Douglas Slotta wrote: > And finally, I have been having a problem with a thin red vertical > line that appears about 2/3rds of the screen from the left side. This > happens about every 3 or 6 times I boot NetBSD from AmigaDOS. I have > not been able to reproduce this at will, so I can't give any more > information. Has anyone else seen this? That's the mousepointer. This bug is known, but has never been fixed. Occurs only on ECS-Console. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 21:08:20 1994 From: Hubert Feyrer To: amiga@sun-lamp.cs.berkeley.edu, dslotta@gauss.onu.edu Subject: Re: Rebuilding the rootfs. Sender: owner-amiga@sun-lamp.cs.berkeley.edu > When I > get to the line 'tar clfp - | (cd /newroot ; tar xvlfp - )' ^^^ There seems a '/' missing in between here. :) Besides that, it should copy over all files and give you another broken pipe after the last file is copied, but you can ignore that one. < And finally, I have been having a problem with a thin red vertical > line that appears about 2/3rds of the screen from the left side. This This are the remainings of the mouse-cursor. The line appears as the mouse-sprite isn't disabled propperly. Just ignore it! Hope this helps, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 22:38:43 1994 From: drahn@pacific.urbana.mcd.mot.com (Dale Rahn) Subject: Re: a2065 To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1419 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Markus Illenseer writes: > On Apr 7, 8:18am, michel beausejour wrote: > > Subject: a2065 > > Hi, > > I have bought a used a2065 for my a3000 ,running netbsd. I'am trying to hook up my 3000 > > and my 1200.(i have the I-card for the 1200).My setup is not working and i'm looking for > > Um, can you do a 'CR' every and so 70 chars please? > I had a problem with my a2065 on my A3000 similar to this, It worked fine under AmigaDos/AmiTCP, but would only pick up packets under NetBSD-amiga when a key was pressed (shift worked quite well). This was when I had the card in the next to bottom slot of the daughter board. I tried reseating the daughterboard and the ethercard several times with no success, I finally moved the card to the bottom slot (which should not matter under Zorro II/III), and the card started functioning fine under NetBSD-amiga and AmiTCP. I did have the strange instance that under AmigaDos the pings to my other machine NetBSD-i386, would increase in delay to nearly 100ms then go back to 30 or so, 30, 36, 45, 53, ... 80, 88, 95, 20, .... then After I moved the card, I now have 2-4 ms delay in ping packets in both AmiTCP and NetBSD-amiga. ------------------------------------------------------------------------ Dale Rahn, Languages and Tools drahn@urbana.mcd.mot.com Motorola, MCG, Urbana Design Center 1101 E. University Ave, Urbana, IL 61801 (217) 384-8585 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Apr 7 22:56:58 1994 From: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) Subject: kvm_netbsd & kernel probs... To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4249 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello all, What's the deal with the current kvm_mkdb program? The latest one (from the 0319 binaries) combined with the latest (0325) kernel still gives me: kvm_mkdb: /netbsd: corrupted string table: Inappropriate file type or format when I run it (or when it gets run during the boot to multi-user mode). Also, a new message has hit my screen in the last several days (this is also with the 0325 kernel). Sometimes when I run a program (and it doesn't have to be a particularly large one, and it isn't with one single program every time; no pattern here) I get the following: Apr 1 14:34:31 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d690 (256) Apr 1 14:34:32 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d758 (256) Apr 1 14:34:32 a4000 /netbsd: swap_pager_io: wait on swbuf for 12dd70 (256) Apr 1 14:34:32 a4000 /netbsd: swap_pager_io: wait on swbuf for 12dfc8 (256) Apr 1 14:34:32 a4000 /netbsd: swap_pager_io: wait on swbuf for 12dc80 (256) Or, how about this sequence: Apr 1 21:37:41 a4000 /netbsd: swap_pager_io: wait on swbuf for 12af30 (256) Apr 1 21:37:41 a4000 /netbsd: swap_pager_io: wait on swbuf for 12ba20 (256) Apr 1 21:37:42 a4000 /netbsd: swap_pager_io: wait on swbuf for 12ce70 (256) Apr 1 21:37:42 a4000 /netbsd: swap_pager_io: wait on swbuf for 12a3a0 (256) Apr 1 21:37:42 a4000 /netbsd: swap_pager_io: wait on swbuf for 12c9e8 (256) Apr 1 21:37:43 a4000 /netbsd: swap_pager_io: wait on swbuf for 12c1a0 (256) Apr 1 21:37:43 a4000 /netbsd: swap_pager_io: wait on swbuf for 12de60 (256) Apr 1 21:37:43 a4000 /netbsd: swap_pager_io: wait on swbuf for 12f8a0 (256) Apr 1 21:37:44 a4000 /netbsd: swap_pager_io: wait on swbuf for 12f1e8 (256) Apr 1 21:37:44 a4000 /netbsd: swap_pager_io: wait on swbuf for 12c948 (256) Apr 1 21:37:44 a4000 /netbsd: swap_pager_io: wait on swbuf for 12a738 (256) Apr 1 21:37:44 a4000 /netbsd: swap_pager_io: wait on swbuf for 12a378 (256) Apr 1 21:37:45 a4000 /netbsd: swap_pager_io: wait on swbuf for 12bd90 (256) Apr 1 21:37:45 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d960 (256) Apr 1 21:37:45 a4000 /netbsd: swap_pager_io: wait on swbuf for 12a8a0 (256) Apr 1 21:37:45 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d000 (256) Apr 1 21:37:46 a4000 /netbsd: swap_pager_io: wait on swbuf for 130138 (256) Apr 1 21:37:46 a4000 /netbsd: swap_pager_io: wait on swbuf for 12f350 (256) Apr 1 21:37:46 a4000 /netbsd: swap_pager_io: wait on swbuf for 12cb78 (256) Apr 1 21:37:46 a4000 /netbsd: swap_pager_io: wait on swbuf for 12b598 (256) Apr 1 21:37:47 a4000 /netbsd: swap_pager_io: wait on swbuf for 12b408 (256) Apr 1 21:37:47 a4000 /netbsd: swap_pager_io: wait on swbuf for 12c830 (256) Apr 1 21:37:47 a4000 /netbsd: swap_pager_io: wait on swbuf for 12b4a8 (256) Apr 1 21:37:48 a4000 /netbsd: swap_pager_io: wait on swbuf for 12afa8 (256) Apr 1 21:37:48 a4000 /netbsd: swap_pager_io: wait on swbuf for 12ac38 (256) Apr 1 21:37:48 a4000 /netbsd: swap_pager_io: wait on swbuf for 12cbc8 (256) Apr 1 21:37:48 a4000 /netbsd: swap_pager_io: wait on swbuf for 12ee78 (256) Apr 1 21:37:49 a4000 /netbsd: swap_pager_io: wait on swbuf for 12b778 (256) Apr 1 21:37:49 a4000 /netbsd: swap_pager_io: wait on swbuf for 12b110 (256) Apr 1 21:37:49 a4000 /netbsd: swap_pager_io: wait on swbuf for 12c3d0 (256) Apr 1 21:37:50 a4000 /netbsd: swap_pager_io: wait on swbuf for 12dc80 (256) Apr 1 21:37:50 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d2f8 (256) Apr 1 21:37:50 a4000 /netbsd: swap_pager_io: wait on swbuf for 12b098 (256) Apr 1 21:37:51 a4000 /netbsd: swap_pager_io: wait on swbuf for 12e8b0 (256) Apr 1 21:37:51 a4000 /netbsd: swap_pager_io: wait on swbuf for 12e6d0 (256) Apr 1 21:37:51 a4000 /netbsd: swap_pager_io: wait on swbuf for 12af08 (256) Apr 1 21:37:52 a4000 /netbsd: swap_pager_io: wait on swbuf for 12a7d8 (256) Apr 1 21:37:52 a4000 /netbsd: swap_pager_io: wait on swbuf for 12e450 (256) Apr 1 21:37:52 a4000 /netbsd: swap_pager_io: wait on swbuf for 12b7f0 (256) Apr 1 21:37:52 a4000 /netbsd: swap_pager_io: wait on swbuf for 12de88 (256) Apr 1 21:37:53 a4000 /netbsd: swap_pager_io: wait on swbuf for 130688 (256) I don't think this output is of much use to you, but what does it mean? Regards, Patrick. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 7 23:16:35 1994 From: Entity Subject: Re: Rebuilding the rootfs. To: Hubert Feyrer Cc: amiga@sun-lamp.cs.berkeley.edu, dslotta@gauss.onu.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Thu, 7 Apr 1994, Hubert Feyrer wrote: > < And finally, I have been having a problem with a thin red vertical > > line that appears about 2/3rds of the screen from the left side. This > > This are the remainings of the mouse-cursor. The line appears as the > mouse-sprite isn't disabled propperly. Just ignore it! er.. why not just fix it instead of ignoring it? :) The problem is disabling the sprite while DMA is still fetching it, and the data word is left in sprxdat. Since it isn't cleared, the pattern repeats down the screen. Ways to fix it are a) disable DMA during vertical blank b) clear out sprite data word c) in copperlist, have sprite pointers point to a NULL longword in CHIP. __ __ /// entity@io.org (NTT@IRC)/[CCCAN!] \\\ /// becker.gts.org!nsq!entity entity@nixie.aus.org HYBRID DEVELOPMENTS entity@spiff.ai.mit.edu arahman@nyx.cs.du.edu From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 8 03:43:06 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu, dslotta@austin.onu.edu Subject: Re: Rebuilding the rootfs. Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Also, the 940319 binaries seem to be missing several libraries, beside > the *crypt* ones, such as libc.so.1.1. I wa lucky enough to have the > old 720 binaries around to replace it. Doesn't anybody read the accompanying README? [libcrypt is documented there] lib.so.1.1 is an old library and anything that relies on it should be recompiled. -SR From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 8 04:09:29 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: kvm_netbsd & kernel probs... To: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1004 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Patrick Vervoorn wrote: > > Hello all, > > What's the deal with the current kvm_mkdb program? The latest one (from the > 0319 binaries) combined with the latest (0325) kernel still gives me: > > kvm_mkdb: /netbsd: corrupted string table: Inappropriate file type or > format > > when I run it (or when it gets run during the boot to multi-user mode). > > Also, a new message has hit my screen in the last several days (this is > also with the 0325 kernel). Sometimes when I run a program (and it doesn't > have to be a particularly large one, and it isn't with one single program > every time; no pattern here) I get the following: > > Apr 1 14:34:31 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d690 (256) > > I don't think this output is of much use to you, but what does it mean? Actually, that message does mean a lot. Simply put, the kernel was compiled with the DEBUG option. It happens on my 3000 but I haven't had any problems from it. Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 8 04:40:36 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 (NetBSD - Amiga) Subject: Re: kvm_netbsd & kernel probs... Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 7, 4:32pm, Ron Roskens wrote: > >From the reaches of cyberspace, Patrick Vervoorn wrote: > > .... > > Also, a new message has hit my screen in the last several days (this is > > also with the 0325 kernel). Sometimes when I run a program (and it doesn't > > have to be a particularly large one, and it isn't with one single program > > every time; no pattern here) I get the following: > > > > Apr 1 14:34:31 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d690 (256) > > > > I don't think this output is of much use to you, but what does it mean? > > Actually, that message does mean a lot. Simply put, the kernel was compiled > with the DEBUG option. It happens on my 3000 but I haven't had any problems > from it. It's from a DEBUG flag in vm/swap_pager.c that seems to have been added sometime since December. It looks like it occurs when a swap buffer is needed and none are available. I've only seen it when I run on a 4MB system - probably because more swapping occurs then and there will be fewer swap buffers available because of the small amount of memory. You can disable it by binpatching _swpagerdebug to 0. Michael From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 8 04:53:36 1994 From: Hubert Feyrer To: amiga@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de Subject: Re: a2065 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > There are NO (!) jumpers to set on the A2065 in order to make the card > work under NetBSD. I suspect that your setup is wrong, check ifconfig > and the netmask... There are quite some jumpers on the a2065 which can be put wrong to NetBSD not operate with the card any more. For example, you can switch between BNC and AUI-port, which I had to do to get my card work with thick wire ethernet (That's the big jumper which covers several pins). Sorry I don't have my specs ready, but there _are_ some jumpers you can try setting! Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 8 10:15:49 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: kvm_netbsd & kernel probs... To: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) Cc: amiga-dev@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: 399 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Apr 1 14:34:31 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d690 (256) > Apr 1 14:34:32 a4000 /netbsd: swap_pager_io: wait on swbuf for 12d758 (256) The kernel you're running must have been compiled with DEBUG defined, and swpagerdebug in sys/vm/swap_pager.c is non-zero, so you get this stuff, I think when you are using mfs for /tmp. You should be able to binpatch swpagerdebug to 0. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 8 16:07:17 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: kvm_netbsd & kernel probs... To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 770 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Michael L. Hitch wrote: [stuff deleted about swap_pager_io error message] > > It's from a DEBUG flag in vm/swap_pager.c that seems to have been added > sometime since December. It looks like it occurs when a swap buffer is needed > and none are available. I've only seen it when I run on a 4MB system - > probably because more swapping occurs then and there will be fewer swap > buffers available because of the small amount of memory. You can disable it > by binpatching _swpagerdebug to 0. I'd have to wonder about that because I have 8M Fast Ram and a 30M swap partition. It doesn't happen all that frequently that I've noticed mainly when more than one person is logged into the machine. or during some heavy compiling Ron From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 8 20:28:59 1994 From: Calvin Chu Subject: Re: 940319 binaries To: newsham@uhunix.uhcc.hawaii.edu Cc: NetBSD-Dev Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Tue, 5 Apr 1994 newsham@uhunix.uhcc.Hawaii.Edu wrote: > Hi, > I just (finally) upgraded the binaries on my system with the > 940319 binaries from eunet. I'm still running a 744 kernel for > the time being. I've noticed two problems so far though: > > o mfs doesn't mount properly now. An IOCTL error occurs. I'm having no problems with mfs.. I'm running the same configuration as you. > o when I login the tty is set at -echoe so my erase characters > show up visibly until I stty echoe. This doesn't happen to me. > Is the mfs problem due to my /usr/sbin and kernel mismatch? (Will > this go away as soon as I upgrade kernels?). I'm having difficulty with any kernals >744 I don't know why. > Also telnet still reports an ioctl error trying to set the TOS. I > thought the 744 kernel had the proper changes for this already and > that the new binaries worked fine (this problem came in with an > ioctl change between 720 and 744 kernels as I remember it). Yeah, I thought the same thing, but apparantly the 940319 binaries are still incorrectly compiled? When I boot with the 940325 kernel, this is exactly what happens on my screen, can somebody out there give me a clue, because I can't figure it out: NetBSD 0.9a (GENERIC) #0: Sat Mar 26 06:47:37 EST 1994 sjr@istari:/usr/local/src/NetBSD-current/sys/arch/amiga/compile/GENERIC real mem = 8388608 avail mem = 5529600 using 64 buffers containing 524288 bytes of memory 3 Amiga memory segments segment 0 at 08c00000 size 00800000 segment 1 at 00200000 size 00200000 segment 2 at 00000000 size 00100000 Zorro II memory mapped at 01bfc000-01dfc000 Realtime clock A2000 rtclock 0 [1/9] par0 [1/6] grf0: 640x400 4 color custom chips display grf0 [1/7] ser0 [1/3] dma0: a2091dma a2091scsi: dma bounce buffer at 01dec000 scsi0: scsi id 7 a2091scsi0 [514/3] sd0: FUJITSU M2614S rev C101, 356178 512 byte blocks sd0 at a2091scsi0, slave 0 sd3: QUANTUM P105S 910-10-94x rev, 205075 512 byte blocks sd3 at 2091scsi0, slave 3 sd6: MAXTOR 7345-SCSI rev 0960, 675484 512 byte blocks sd6 at 2091scsi0, slave 6 changing root device to sd6a trapsignal(3, 11, 158268, 26a3c, 18048) Apr 6 16:40:57 init: fatal signal: segmentation fault trapsignal(5, 11, 158268, 26a3c, 18048) Apr 6 16:41:31 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. trapsignal(7, 11, 158268, 26a3c, 18048) Apr 6 16:41:33 init: fatal signal: segmentation fault trapsignal(9, 11, 158268, 26a3c, 18048) Apr 6 16:42:05 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. trapsignal(11, 11, 158268, 26a3c, 18048) Apr 6 16:42:07 init: fatal signal: segmentation fault trapsignal(13, 11, 158268, 26a3c, 18048) Apr 6 16:42:42 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. trapsignal(15, 11, 158268, 26a3c, 18048) Apr 6 16:43:14 init: fatal signal: segmentation fault trapsignal(17, 11, 158268, 26a3c, 18048) Apr 6 16:43:48 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. trapsignal(19, 11, 158268, 26a3c, 18048) Apr 6 16:43:51 init: fatal signal: segmentation fault trapsignal(21, 11, 158268, 26a3c, 18048) Apr 6 16:44:25 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. trapsignal(23, 11, 158268, 26a3c, 18048) Apr 6 16:44:57 init: fatal signal: segmentation fault trapsignal(25, 11, 158268, 26a3c, 18048) Apr 6 16:45:00 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode. trapsignal(27, 11, 158268, 26a3c, 18048) Apr 6 16:45:34 init: fatal signal: segmentation fault From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Apr 9 01:52:28 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Blitting To: amiga-x@sun-lamp.cs.berkeley.edu 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 I have good news and bad news. The good news is that I have implemented both blit and line ioctls. The bad news is I can't test them. I'm using the latest kernel (OK, 2 days old) and the latest includes, but I don't have room to compile the latest compler, linker, or libraries. I updated the views.c program so it will compile properly, and it seems to work fine, except whenever it attempts to access the mmap()'ed video buffer, it segfaults. I tried it under gdb, and it seems to be getting a valid pointer back from mmap(), but whenever I use the pointer I get a segv. Any suggestions? Also, does anyone have a version of emacs that runs under the latest kernel? In the one I'm using (*really* _*really*_ old) select() doesn't work right, so it keeps thinking it's getting lots and lots of '\0's. ========================================================================= 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 Apr 9 01:59:11 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/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/src/sys/arch/amiga/dev Modified Files: grf.c Log Message: no more MAP_FILE --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/lib/libc/arch/m68k/sys In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/libc/arch/m68k/sys Modified Files: cerror.S Removed Files: lseek.S Log Message: have cerror DTRT on returns, w.r.t. quads and -1. it needs to be done here (think of syscall(SYS_lseek,...)). also, kill bogus lseek thang. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: trap.c Log Message: cleanup, bring syscall() up to date. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: trap.c Log Message: theo fixed sun_syscall.h so now we unhardcode SUN_SYS_sigreturn. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/usr.sbin/kvm_mkdb In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/usr.sbin/kvm_mkdb Modified Files: nlist.c Log Message: don't think this ever really worked on non hp300 m68k machines. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/usr.sbin In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/usr.sbin Modified Files: Makefile Log Message: add iteconfig for amiga's --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/CVSROOT In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/modules Modified Files: modules Log Message: add iteconfig (amiga) to modules list --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/usr.sbin/iteconfig In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/usr.sbin/iteconfig Added Files: Makefile iteconfig.8 iteconfig.c Log Message: add iteconfig for amiga's --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/lib/csu/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/csu/m68k Modified Files: crt0.c Log Message: new way of invoking mmap. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/stand/iteconfig In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/stand/iteconfig Removed Files: Makefile iteconfig.8 iteconfig.c Log Message: moved to usr.sbin --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: vm_machdep.c Log Message: need to copy current frame pointer (p_regs), very subtle bug as you needed to have a signal pending for a child process that has not yet returned from fork(). fun. --------------------------------- From: Charles Hannum Update of /b/source/CVS/src/sys/arch/hp300/hp300 In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/hp300/hp300 Modified Files: vm_machdep.c Log Message: p_regs fix from amiga. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: ite_rt.c Log Message: allow user to not use their retina board as the console. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: files.amiga Log Message: add floppy. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: autoconf.c conf.c custom.h machdep.c trap.c Log Message: incorpaorated floppy code from Brad Pepers, needs work doesn't work on my machine. more clenaup in trap.c --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: device.h Added Files: fp.c Log Message: added floppy driver from Brad Pepers, doesn't work on my machine, some major cleanup by me no code changes ... yet. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Added Files: fd.c Removed Files: fp.c Log Message: fp -> fd, consistency good. [nameclash bad.] --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: conf.c machdep.c Log Message: fp -> fd, consistency good. [nameclash bad.] --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: files.amiga Log Message: fp -> fd, consistency good. [nameclash bad.] --------------------------------- 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 Modified Files: trap.c Log Message: Some cleanup--largely from amiga/trap.c. "Do" __syscall... --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: sd.c Log Message: fix to floptical code from Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Added Files: disktab fstab.tmp Log Message: zero length place holders for now. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Added Files: Makefile.inc Log Message: build generic and a3000 kernels when making snapshot. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: fd.c Log Message: all amigas ahve internal drive so anything to the contrary is bogus. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: autoconf.c Log Message: fp -> fd from (rhealey@aggregate.com)Z --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: MAKEDEV Log Message: add floppy comment out aconf. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: fd.c Log Message: yuck, there has got to be a better way to derive things and copyright them. --------------------------------- From: Paul Kranenburg Update of /b/source/CVS/src/gnu/usr.bin/ld/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/pk/ld/m68k Modified Files: md.c md.h Log Message: Use machine architecture when examining object files for compatibility. --------------------------------- From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 9 02:10:20 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Blitting To: amiga-x@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I have good news and bad news. The good news is that I have implemented both blit and line ioctls. The bad news is I can't test them. I'm using the latest kernel (OK, 2 days old) and the latest includes, but I don't have room to compile the latest compler, linker, or libraries. I updated the views.c program so it will compile properly, and it seems to work fine, except whenever it attempts to access the mmap()'ed video buffer, it segfaults. I tried it under gdb, and it seems to be getting a valid pointer back from mmap(), but whenever I use the pointer I get a segv. Any suggestions? Also, does anyone have a version of emacs that runs under the latest kernel? In the one I'm using (*really* _*really*_ old) select() doesn't work right, so it keeps thinking it's getting lots and lots of '\0's. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 9 05:31:17 1994 From: Eric Augustine Subject: xlock To: amiga-x@sun-lamp.cs.berkeley.edu (NetBSD-X news-list NetBSD-Amiga-X) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 379 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I have just uploaded with sources a small X utility, err whatever you want to categorize it as. I find it useful and it wasn't present in the binaries I downloaded. It required a few small modifications to get it working properly and I've run it for the past week without any problems. ftp.eunet.ch:/pub/amigabsd/incoming/xlock.tgz I hope you find it of use. - Eric. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 9 08:22:59 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Adosfs sad news To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1039 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Well the reason I have not yet commited the changes to the tree for adosfs is that I was told to wait. Now it appears as if they will not go in. This is the final word from Chris (cgd@sun-lamp.cs.berkeley.edu) he asked me to let him communicate with Frank one last time before this descision was finalized. This has taken place and Frank holds to the GPL so we have to respect that and not include anything relating to the work in the kernel. Tis sad. I don't know much about VFS but I guess when and if I get time to look over the code in the kernel and write a new one I will. Or perhaps someone else will run with this one either way it will probably not be for a while. In the mean time you are free to include Niklas distribution into your own kernel. Sorry, Chris. This is the final word BTW I won't be able to help explain why the few small additions to the kernel cannot be made it is a political descision one in which I was not involved, and one in which I have no power to change. (I do support the descision however) From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 9 11:24:06 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "xlock" (Apr 8, 7:40pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Eric Augustine , amiga-x@sun-lamp.cs.berkeley.edu (NetBSD-X news-list NetBSD-Amiga-X) Subject: Re: xlock Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 8, 7:40pm, Eric Augustine wrote: > I have just uploaded with sources a small X utility, err whatever > you want to categorize it as. I find it useful and it wasn't > present in the binaries I downloaded. It required a few small > modifications to get it working properly and I've run it for the > past week without any problems. Great, i have compiled xlock by myself already, but got problems with the shadow passwords. How did you solve that problem? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 9 11:43:20 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: This week's NetBSD/amiga changes 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: 793 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/dev > In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev > > Modified Files: > fd.c > Log Message: > all amigas ahve internal drive so anything to the contrary is bogus. > > > --------------------------------- For the moment, in my amiga there is no floppy drive. I planned to use that space for a 3rd hard disk, but noticed that A3000 power switch makes that space too low :-( Anyway, there are amigas that have no internal floppy drive :-) ++Tero From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 10 00:27:05 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Blitting To: eeh@btr.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: amiga-x@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1004 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > The bad news is I can't test them. I'm using the latest kernel (OK, 2 > days old) and the latest includes, but I don't have room to compile the > latest compler, linker, or libraries. I updated the views.c program so it > will compile properly, and it seems to work fine, except whenever it > attempts to access the mmap()'ed video buffer, it segfaults. Steve is working on a newer. > I tried it under gdb, and it seems to be getting a valid pointer back > from mmap(), but whenever I use the pointer I get a segv. Any suggestions? Its probably a off_t thing. > Also, does anyone have a version of emacs that runs under the latest > kernel? In the one I'm using (*really* _*really*_ old) select() doesn't > work right, so it keeps thinking it's getting lots and lots of '\0's. Me and theo fixed this last night. Its a bug in tty.c you can wait or fix it yourself look for *(off_t *)data = ttnread... and change that to *(int *)data.. (int tty.c) > Eduardo Horvath eeh@btr.com Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 10 00:27:07 1994 From: niklas@appli.se (Niklas Hallqvist) To: chopps@emunix.emich.edu Cc: amiga@sun-lamp.cs.berkeley.edu Cc: cgd@sun-lamp.cs.berkeley.edu Subject: Re: Adosfs sad news Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "Chris" == Chris Hopps writes: Chris> Well the reason I have not yet commited the changes to the tree Chris> for adosfs is that I was told to wait. Chris> Now it appears as if they will not go in. This is the final Chris> word from Chris (cgd@sun-lamp.cs.berkeley.edu) he asked me to Chris> let him communicate with Frank one last time before this Chris> descision was finalized. This has taken place and Frank holds Chris> to the GPL so we have to respect that and not include anything Chris> relating to the work in the kernel. Huh, I find this very strange. The changes in sys/mount.h and sys/malloc.h are definitely not part of the GPL'd code. Of course they are related to the GPL'd code as they enable the GPL'd code to run, but so are the NetBSD kernel as a whole. I'd like to explain what the patches are, so you can judge for yourself if it is a reasonable decision the core group have made: 1 sys/mount.h I wanted to reserve a MOUNT_ADOSFS value. This would be used by *any* implementation of adosfs, whether GPL'd or not. As it happens, all we have today is an implementation derived from GPL'd code. Is the intention to accept this patch as soon as a totally free implementation exists? Well, we can side step this if we choose another existing MOUNT_* constant to reuse, like MOUNT_PORTAL, but the we cannot run ADOSFS and PORTAL FS at the same time. 2 sys/malloc.h Like in the former case I wanted to reserve two memory tags for use by the existing ADOSFS implementation. I could as easily use any other existing tag. That's it, no more kernel changes is necessary, as the ADOSFS is now an LKM. To me it seems funny the SunOS emulation has been allowed to exist, but theses changes have not. COMPAT_SUNOS enable *true* proprietary programs to run, as opposed to "only" copylefted code. Isn't that awful :-) How about exec* syscalls, they don't seem to prevent GNU programs to run, we'd better throw them away :-) If someone wants to explain the rationale to me, please do. Indeed, I feel somewhat kicked below the belt by this decision. I really tried to enable mere binary users to still use the ADOSFS although it stems from GPLd code. I really thought LKMs was the way to go, but now I see I'd better provide a NFS interface in a user process accessing the raw disk. Well, rewriting the fraction of code which is GPL'd would probably be easier... 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 Sun Apr 10 00:41:38 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Blitting To: eeh@btr.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: amiga-x@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1004 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > The bad news is I can't test them. I'm using the latest kernel (OK, 2 > days old) and the latest includes, but I don't have room to compile the > latest compler, linker, or libraries. I updated the views.c program so it > will compile properly, and it seems to work fine, except whenever it > attempts to access the mmap()'ed video buffer, it segfaults. Steve is working on a newer. > I tried it under gdb, and it seems to be getting a valid pointer back > from mmap(), but whenever I use the pointer I get a segv. Any suggestions? Its probably a off_t thing. > Also, does anyone have a version of emacs that runs under the latest > kernel? In the one I'm using (*really* _*really*_ old) select() doesn't > work right, so it keeps thinking it's getting lots and lots of '\0's. Me and theo fixed this last night. Its a bug in tty.c you can wait or fix it yourself look for *(off_t *)data = ttnread... and change that to *(int *)data.. (int tty.c) > Eduardo Horvath eeh@btr.com Chris. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Apr 10 00:46:00 1994 From: William J Coldwell To: amiga-x@sun-lamp.cs.berkeley.edu Subject: XRetinaZ2 problems. Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu It seems very unstable, in comparison to Xmono. I can make it get trapsignals all over the place, especially when there is scrolling going on. Also, I can't get it to display correctly in any other resolution than 640x480. When I use the default 800x600, or any thing higher, I get either a shifted down display about 1/3 of the screen down, and flickering at like 50Hz or less. If I crank the resolution to say 1024x768, interlaced, it gives me "panels" of garbage. It takes some creativity and luck to manage to get the mouse over the windows so I can type exit.. I also set up a 768x600 mode, which should match the text mode I'm in (besides depth), and it too gives me the shifted down display. Help! These trapsignals make it really hard to use, and the display problem is giving me a headache ;-). Tell me what I'm doing wrong. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 10 01:02:26 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: ADOSFS fix for long uid_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm rebuilding my system to run with the new uid_t, gid_t and off_t and noticed that in the adosfsmount.h file there was an error in the adosfs_quotactl prototype. There is comment at the spot saying what to do... Niklas From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Apr 10 02:05:28 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: XRetinaZ2 problems. To: billc@icecube.cryogenic.com Cc: 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: 770 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > Also, I can't get it to display correctly in any other resolution than > 640x480. When I use the default 800x600, or any thing higher, I get either a > shifted down display about 1/3 of the screen down, and flickering at like > 50Hz or less. If I crank the resolution to say 1024x768, interlaced, it Makes me glad I did my own Retina server while waiting for Olivier's latest version :-) Are you using DefineMonitor on the Amiga side to generate the data for Xconfig (or whatever the file is)? Do you use the Test Image button to verify that your monitor can handle the display? Beyond that, I don't know... the sources were supposed to be available... On another topic, I'm pretty much done with my port of XView 3.2. Is anyone else interested in this stuff? From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Apr 10 08:37:51 1994 From: rhealey@aggregate.com Subject: New X bins for "off_t" kernels To: amiga-x@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: 487 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Is anybody going to cut new versions of the X binarys for the new kernels with 64 bit off_t's and 32 bit uid/gid? I'm especially interested in new versions of the libes, Xmono and xmosaic... Better yet, was the ddx and Imakefiles for xmono and the rest of the smash ever put up on ftp.eunet.ch? I know there are additional problems due to the int vs off_t stuff but it would be nice to have a good starting point. With the A2024's Xmono is the best server available... -Rob From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Apr 10 09:20:12 1994 From: Eric Augustine Subject: _ite symbols in kernel To: amiga-x@sun-lamp.cs.berkeley.edu (NetBSD-X news-list NetBSD-Amiga-X) Cc: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 264 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Just a quick enquiry - is there a list of the _ite_XXX symbols in the kernel someplace? I am trying to alter a few things (like the border colour) and am at a loss as to which I have available to change and what I can change them to... Thanks - - Eric. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 10 09:23:59 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: niklas@appli.se (Niklas Hallqvist), rhealy@aggregate.com Cc: chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu, cgd@sun-lamp.cs.berkeley.edu Subject: Re: Adosfs sad news <9404090921.AA26694@della.appli.se> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Huh, I find this very strange. The changes in sys/mount.h and > sys/malloc.h are definitely not part of the GPL'd code. Of course > they are related to the GPL'd code as they enable the GPL'd code > to run, but so are the NetBSD kernel as a whole. Whether or not those pieces of code are GPL'd is irrelevant to the matter at hand. The problem is not even that the code that they'd enable is under the GPL. The problem is that they are 'support' for code which is not now, and probably will never be in the NetBSD source tree. In the last several months, a policy has slowly been developing: If it's not in the source tree, and likely won't be, don't put in hooks for it. There are several reasons for this, the most prominent being "code cleanliness" and "code maintenance." Regarding cleanliness: Adding unused constants, etc., makes the code harder to understand. I.e. somebody sits down, sees a constant, asks "what is this used for", and finds NOTHING. It's counter-intuitive. Regarding code maintenance: In the future, somebody's going to be maintaining this code. How will *they* know when and if they can delete those constants? If the constants exist for the sole use of something that's not in the source tree, then how are they to determine whether or not to chuck them? Remember, a large part of system maintenance is throwing things away, when that's appropriate. > I'd like to > explain what the patches are, so you can judge for yourself if > it is a reasonable decision the core group have made: I know exactly what the patches are. I've looked at them, verified that they applied to the tree, etc. I also looked at the mount_ command, thought about cleaning it up, etc. (i just did some serious cleaning, improvements to the msdosfs mounting scheme, not that i ever use it -- i have no ms-dos software! 8-) > That's it, no more kernel changes is necessary, as the ADOSFS is now > an LKM. To me it seems funny the SunOS emulation has been allowed to > exist, but theses changes have not. COMPAT_SUNOS enable *true* > proprietary programs to run, as opposed to "only" copylefted code. There's nothing wrong with "proprietary code," and there's nothing wrong with allowing compatibility for it. The fact is, there are a lot of constants and changes that have been related to SunOS support, but it's an *integrated* system -- the SunOS compat code lives in our tree. The ADOSFS wouldn't, and *THAT* is the difference. > If someone wants to explain the rationale to me, please do. See above. > Indeed, > I feel somewhat kicked below the belt by this decision. I really > tried to enable mere binary users to still use the ADOSFS although > it stems from GPLd code. Don't feel hurt by *me* -- if i didn't want you folks to be able to use the code, i wouldn't have bothered spending half an hour to write a piece of mail to the author to try to convince him to let us use it. The fact is, it was up to him, and he made his decision to not change the license terms. But the fact stands that if it's not going to go into our tree, we're not going to add hooks for it. For those of you (or perhaps "the one of you") who thinks that this shows some bias against the amiga: realize that the i386 doesn't have hooks for Bill Methenzen's (spelling?!) i386 math emulator for the same reason. Also realize that it's the reason that e.g. there are a bunch of XXX's empty slots in the i386 device table; the drivers weren't going to go in the tree, so the devsw entries were freed up. The fact is, yes, to large degree, we *are* hard-asses about this sort of stuff, and it pays off in terms of a more consistent, coherent source tree and environment. > Well, rewriting the fraction of code which > is GPL'd would probably be easier... I'd like an ADOSFS file system in the source tree. You'll note that if we gave you the hooks that you claim to 'need', you'd not be at all tempted to write one.... cgd From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 10 09:42:20 1994 From: Eric Augustine Subject: _ite symbols in kernel To: amiga-x@sun-lamp.cs.berkeley.edu (NetBSD-X news-list NetBSD-Amiga-X) Cc: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 264 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Just a quick enquiry - is there a list of the _ite_XXX symbols in the kernel someplace? I am trying to alter a few things (like the border colour) and am at a loss as to which I have available to change and what I can change them to... Thanks - - Eric. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 10 10:11:14 1994 From: Donn Cave X-Sender: donn@carson2.u.washington.edu Subject: Re: Adosfs sad news To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 604 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > ... I really thought LKMs was the way to go, > but now I see I'd better provide a NFS interface in a user process > accessing the raw disk. Well, rewriting the fraction of code which > is GPL'd would probably be easier... Actually, not to be a smart-ass or anything, but it sounds to me like the way to go is a server, in a multi-server/micro-kernel architecture. Classic problem with monolithic kernels. If it were me, I would not sweat it - if people don't want to rebuild their kernel every time they add a new feature, let them run the Hurd or something. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 10 10:55:08 1994 From: Arthur Hoffmann Subject: problems with: kernels Floppys scsi binaries ... To: 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: 2614 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I usually compile my own kernels and some binaries. So far I had no problems with that, but recently I seem to have a slight problem: ps doesn't work with my newer kernels anymore it reports the following: ps: proc size mismatch (got 13846 total, kinfo_proc: 560) compiling a new ps results in nothing... no error, no output?? Also ls -l doesn't seem to work either when compiled under a new kernel here is what it produced till todays kernel ?-------w- 0 15174 512 8589934592 Jan 3 1970 CVS ?--------x 0 13234 161 8589934592 Jan 3 1970 Makefile* ?--------x 0 14752 3230 34359738368 Jan 3 1970 cmp.c* ?--------x 0 13311 785 8589934592 Jan 3 1970 cmp.o* ?--------x 0 12533 2611 25769803776 Jan 3 1970 extern.h* ?--------x 0 12536 63431 1168231104512 Jan 3 1970 ls* ?--------x 0 49576 8749 77309411328 Jan 3 1970 ls.0* ?--------x 0 14720 9388 85899345920 Jan 3 1970 ls.1* ?--------x 0 13352 14030 120259084288 Jan 3 1970 ls.c* ?--------x 0 13280 2808 25769803776 Jan 3 1970 ls.h* ?--------x 0 12664 5723 51539607552 Jan 3 1970 ls.o* ?--------x 0 12928 7566 68719476736 Jan 3 1970 print.c* ?--------x 0 12656 4768 42949672960 Jan 3 1970 print.o* ?--------x 0 13272 2565 25769803776 Jan 3 1970 util.c* ?--------x 0 13408 469 8589934592 Jan 3 1970 util.o* here is what it produced with todays kernel(10.Apr.1994) (ls recompiled) root@atze(48)$ ls -l total 0 Segmentation fault (core dumped) then I do gdb -c ls.core and get: root@atze(50)$ gdb -c ls.core "/home/bin/ls/ls.core" is not a core dump: File truncated (gdb) Any clues? Also there is a problem with the floppy: when I do a newfs /dev/rfd0 I get the following: root@atze(2)$ newfs /dev/rfd0 /dev/rfd0: 1760 sectors in 80 cylinders of 2 tracks, 11 sectors 0.9MB in 5 cyl groups (16 c/g, 0.18MB/g, 64 i/g) super-block backups (for fsck -b #) at: 32, 400, 736, 1104, 1440, newfs: ioctl (WDINFO): Invalid argument newfs: /dev/rfd0: can't rewrite disk label The disk can still be mounted and I can write to it and read from it. (I haven't verified if the info I write to it is valid, I'll do that later) after unmounting and remounting the disk I got a mmufault and the system died on me :( The system can distinguish on startup between HD and DD floppies, but when doing a newfs it treats them all as DD. Can anyone help? At least with the ps problem please. Thanks. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@nutmeg.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 10 11:31:00 1994 From: Arthur Hoffmann Subject: ADOSfs how? To: 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: 2754 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I followed the instructions on how to install the ADosFS on my A3000, but It doesn't work. This is what I did I configured the kernel as mentioned in the README.LKM and rebooted the system. then I did the following: root@atze(8)$ cp Makefile adosfsmod.c /usr/src/sys/adosfs/ root@atze(9)$ cd /usr/src/sys/adosfs/ root@atze(10)$ make cc -O2 -I.. -I../sys -DKERNEL -DADOSFS -DADOSFSDEBUG -c adosfs_anode.c cc -O2 -I.. -I../sys -DKERNEL -DADOSFS -DADOSFSDEBUG -c adosfs_blocks.c cc -O2 -I.. -I../sys -DKERNEL -DADOSFS -DADOSFSDEBUG -c adosfs_util.c cc -O2 -I.. -I../sys -DKERNEL -DADOSFS -DADOSFSDEBUG -c adosfs_vfsops.c cc -O2 -I.. -I../sys -DKERNEL -DADOSFS -DADOSFSDEBUG -c adosfs_vnops.c adosfs_vnops.c:725: warning: initialization of `adosfs_vnodeops.vop_readdir' from incompatible pointer type cc -O2 -I.. -I../sys -DKERNEL -DADOSFS -DADOSFSDEBUG -c adosfsmod.c ld -r -o adosfs.o adosfs_anode.o adosfs_blocks.o adosfs_util.o adosfs_vfsops.o adosfs_vnops.o adosfsmod.o root@atze(11)$ make load modload -o adosfs -eadosfsmod adosfs.o Module loaded as ID 0 root@atze(12)$ modstat Type Id Off Loadaddr Size Info Rev Module Name VFS 0 13 004c2000 0018 4c6108 1 adosfs Then I checked what my adospartition is called by the sysem: root@atze(43)$ disklabel -r sd5 Bad pack magic number (label is damaged, or pack is unlabeled) # /dev/rsd5a: type: SCSI disk: QUANTUM label: some pack flags: bytes/sector: 512 sectors/track: 98 tracks/cylinder: 1 sectors/cylinder: 98 cylinders: 2097 rpm: 0 interleave: 0 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 9 partitions: # size offset fstype [fsize bsize cpg] a: 20678 184828 4.2BSD 1024 8192 0 # (Cyl. 1886 - 2096) c: 205561 0 unused 0 0 # (Cyl. 0 - 2097*) d: 102508 82222 4.2BSD 1024 8192 0 # (Cyl. 839 - 1884) i: 82026 196 ADOS # (Cyl. 2 - 838) Warning, revolutions/minute 0 boot block size 0 super block size 0 partition a: partition extends past end of unit partition c: partition extends past end of unit So I checked in /dev for sd5i for rsd5i and sd5i, since they didn't exist I created them, they look like this: crw-r----- 1 root operator 8, 56 Apr 10 18:03 rsd5i brw-r----- 1 root operator 4, 56 Apr 10 18:03 sd5i Then I did: mkdir /ados mount -t adosfs -o ro /dev/sd5i /ados the result of that was: mount: Device not configured What might the problem be? The minor number (56) for rsd5i|sd5i? Thanks for any help. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@nutmeg.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 10 12:18:43 1994 From: Arthur Hoffmann Subject: scsi problems on A3000 To: 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: 534 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, in the messae befor I forgot to mention: I used to have problems with my machine running the scsi syncronous, so I updated the WD chip to the latest version WD33c93A-PL 00 08 and the problem went away. Recentlsy (the last 2 weeks or so) I started getting the sbic_wait TIMEO @1310 with asr=x0 csr=x41 again. This happens quite randomly (and frequently) to both of my Quantum disks. Any ideas? Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@nutmeg.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 10 23:16:24 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Repost of NONBSD-partitioning explanation, for ADOSFS Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu [ As the questions have come up again, I'm reposting a message made to this list some months ago -Niklas ] >>>>> "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 -- 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 Apr 10 23:19:26 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: problems with: kernels Floppys scsi binaries ... Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 10, 5:44pm, Arthur Hoffmann wrote: > Also there is a problem with the floppy: > > when I do a newfs /dev/rfd0 I get the following: > > root@atze(2)$ newfs /dev/rfd0 > /dev/rfd0: 1760 sectors in 80 cylinders of 2 tracks, 11 sectors > 0.9MB in 5 cyl groups (16 c/g, 0.18MB/g, 64 i/g) > super-block backups (for fsck -b #) at: > 32, 400, 736, 1104, 1440, > newfs: ioctl (WDINFO): Invalid argument > newfs: /dev/rfd0: can't rewrite disk label The WDINFO error is because the fd driver doesn't write the disk label yet. > The disk can still be mounted and I can write to it and read from it. > (I haven't verified if the info I write to it is valid, I'll do that > later) I seem to be able to read from the floppy if it was formatted with AmigaDOS, but I'm having trouble writing to it (with newfs). > after unmounting and remounting the disk I got a mmufault and the > system died on me :( > > The system can distinguish on startup between HD and DD floppies, but > when doing a newfs it treats them all as DD. When the driver builds the disk label in the fdioctl routine, it sets the sector count to 11 and ignores the density. It looks like the fd data structure contains the number of sectors and should be used to set the disk label sector count. 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 Sun Apr 10 23:25:35 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: problems with: kernels Floppys scsi binaries ... To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 808 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu All the problems to me sound like you are recompiling stuff in the wrong order.. You must not also be reading current-users mailing list or you would know about the recent off_t gid_t pid_t changes that would cause all of your problems. basically you should wait for steve to finish his snapshot and grab that or if you want to try and rectifiy your bad enviroment this is the order you should have compiled in make and install make cd share/mk; make install cd kernelbuildarea ; make kernel ; reboot cd include ; make install; cd lib ; make clean ; make ; make install cd gnu/lib ; make clean ; make ; make install make and install ld ad ranlib cd lib ; make clean ; make ; make install cd gnu/lib ; make clean ; make ; make install cd src ; make clean && make .depend && make && make install Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 10 23:29:17 1994 From: niklas@appli.se (Niklas Hallqvist) To: cgd@postgres.berkeley.edu Cc: rhealy@aggregate.com, chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu, cgd@sun-lamp.cs.berkeley.edu Subject: Re: Adosfs sad news Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "Chris" == Chris G Demetriou writes: Niklas> Well, rewriting the fraction of code which is GPL'd would probably Niklas> be easier... Chris> I'd like an ADOSFS file system in the source tree. You'll note Chris> that if we gave you the hooks that you claim to 'need', you'd Chris> not be at all tempted to write one.... You CAN have it in the tree, just put it in the gnu subdir. It is no more a kernel-resident module so it doesn't have to be in sys. I'd like to thank you for the rationale of rejection, it makes sense. My presumptions were that the few lines of patches was related to GPLd code and that you disliked GPL to such a degree, that you wouldn't like to help users of such SW in any way. That was the reason of the sarcastic tone of my message. I'd like to apologize for that. Cleanliness and maintenability are *good* points for your decision. I would like to present an idea which would solve problems like this, still by quite clean and easy-maintained: As there are support for LKM VFSs in *your* tree, would it be possible to register some MOUNT_ values, vnode and malloc tags for anonymous LKMs in general? I believe this is the way LKM devices gets major device numbers assigned. This would enable running *any* new LKM VFS on kernels older than the LKM itself. It would be up to the sysadmin to watch out for number clashes and to the LKM authour to provide means for using different numbers at different load times. To answer your suggestion to start getting rid of the GPL code: I won't rewrite the needed portions af the ADOSFS for quite some while. There's just to much other things on my list of to-dos... :-( I'd be happy to provide guidance to anyone who wants to give it a try though. Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 10 23:41:44 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: sendmail configuration Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have recently been reading the O'Reilly Nutshell handbook on sendmail and I decided to try to create a sendmail.cf for my NetBSD Amiga 3000. The requirements are fairly simple, I connect to the Internet using a PPP connection to Demon Internet in London. I therefore require: 1) Local mail delivered locally. 2) Non-local outgoing mail sent to Demons mailhost. 3) Non-local incoming mail received from Demons mailhost and delivered locally. The client.cf file developed in the book is not exactly what I needed but I modified it as follows and I think this is what I need:- ################################################################### ### ### sendmail.cf file for iceberg.demon.co.uk developed using ### the sendmail Nutshell handbook by O'Reilly & Associates, Inc ### ################################################################### ### Defined macros # The name of the mail hub DRgate.demon.co.uk # The local official domain name DDdemon.co.uk Dj$w.$D # The hub as it is known to the outside world DH$j # Other names I might be called Cw localhost # Whom errors should appear to be from DnMailer-Daemon # The look of the Unix From line. DlFrom $g $d # The characters that separate address components Do.:%@!^=/[] # The default form of the senders address Dq<$g> ### Options # The location of the queue directory OQ/var/spool/mqueue # The location of the aliases file OA/etc/aliases # The location of the statistics file OS/var/log/sendmail.st # The location of the help file OH/usr/share/misc/sendmail.hf # default delivery mode Odbackground # temporary file permissions OF0600 # default UID and GID Ou1 Og1 # Level at which to syslog errors OL9 # Wait for SMTP replies (Give the hub a break) Or1h # default messages to old style OoTrue # Replace unquoted spaces with a dot OB. ### Trusted users T root daemon ### Header declarations HFrom: $q HReceived: by $j id $i; $b H?x?Full-Name: $?x$x$. H?D?Date: $a H?M?Message-Id: <$t.$i@$j> ### Priority definitions Pspecial-delivery=100 Pfirst-class=0 Plist=-30 Pbulk=-60 Pjunk=-100 ### Mailer delivery agent definitions # Mailer to forward all internet mail to the hub machine Mhub, P=[IPC], S=0, R=0, F=xmDFMuCX, A=IPC $h # local and prog mailers Mlocal, P=/usr/libexec/mail.local, F=lsDFMrmn, S=10, R=20/40, A=mail.local $u Mprog, P=/bin/sh, F=lsDFMeu, S=10, R=20/40, D=$z:/, A=sh -c $u ### The Rule Sets S0 select delivery agent R@$+ $#error $: Missing user name R$- $#local $:$1 deliver locally (username) R$-@$w $#local $:$1 deliver locally (username@host) R$-@$=w $#local $:$1 deliver locally (username@othernames) R$-@$=w.$D $#local $:$1 deliver locally (username@host.domain) R$+ $#hub $@$R $:$1 forward to hub S3 pre-processing for all rule sets R$*<>$* $n handle <> error address R$*<$*<$*>$*>$* $2<$3>$4 de-nest brackets R$*<$*>$* $2 basic RFC822 parsing S10 re-write the sender for the hub R$- $@$1@$H user -> user@hub R$-@$w $@$1@$H user@local -> user@hub R$-@$=w $@$1@$H user@othernames -> user@hub R$-@$=w.$D $@$1@$H user@other.domain -> user@hub S1 generic sender re-write (unused) S20 not used yet S40 not used yet ************************************************************************* I have tested this locally and it works fine if I use /usr/bin/mail to send the mail. If I try to send mail using sendmail directly then the mail is delivered but error messages are generated. e.g mail -s test john From john@iceberg.demon.co.uk Sun Apr 10 13:03:16 1994 From: Received: by iceberg.demon.co.uk id NAA00129; Sun, 10 Apr 1994 13:02:54 +0100 Date: Sun, 10 Apr 1994 13:02:54 +0100 Message-Id: <199404101202.NAA00129@iceberg.demon.co.uk> Apparently-To: john Status: RO Hello world! >From Mailer-Daemon@iceberg.demon.co.uk Sun Apr 10 13:03:19 1994 From: Received: by iceberg.demon.co.uk id NAB00129; Sun, 10 Apr 1994 13:03:17 +0100 Date: Sun, 10 Apr 1994 13:03:17 +0100 Message-Id: <199404101203.NAB00129@iceberg.demon.co.uk> To: john Subject: Returned mail: unknown mailer error 136 Status: RO The original message was received at Sun, 10 Apr 1994 13:02:54 +0100 from localhost [127.0.0.1] ----- The following addresses had delivery problems ----- john (unrecoverable error) ----- Transcript of session follows ----- 554 john... unknown mailer error 136 ----- Original message follows ----- From: Received: by iceberg.demon.co.uk id NAA00129; Sun, 10 Apr 1994 13:02:54 +0100 Date: Sun, 10 Apr 1994 13:02:54 +0100 Message-Id: <199404101202.NAA00129@iceberg.demon.co.uk> Apparently-To: john Hello world! >From Mailer-Daemon@iceberg.demon.co.uk Sun Apr 10 13:03:22 1994 From: Received: by iceberg.demon.co.uk id NAC00129; Sun, 10 Apr 1994 13:03:21 +0100 Date: Sun, 10 Apr 1994 13:03:21 +0100 Message-Id: <199404101203.NAC00129@iceberg.demon.co.uk> To: postmaster Subject: Returned mail: unknown mailer error 136 Status: RO The original message was received at Sun, 10 Apr 1994 13:03:17 +0100 from localhost ----- The following addresses had delivery problems ----- john (unrecoverable error) ----- Transcript of session follows ----- 554 john... unknown mailer error 136 ----- No message was collected ----- *************************************************************** Any ideas why this happens ? I have noticed that mail.local returns a fairly random value to the calling shell and maybe this causes it ? BTW, I am using 720 rootfs and binaries. kernel is also 720 or 744 as sendmail crashes under later kernels. +-------------------------------+--------------------------+ ! 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-x@sun-lamp.cs.berkeley.edu Sun Apr 10 23:42:17 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "New X bins for "off_t" kernels" (Apr 10, 12:39am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: rhealey@aggregate.com, amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: New X bins for "off_t" kernels Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 10, 12:39am, rhealey@aggregate.com wrote: > Subject: New X bins for "off_t" kernels > > Is anybody going to cut new versions of the X binarys for the > new kernels with 64 bit off_t's and 32 bit uid/gid? I'm especially > interested in new versions of the libes, Xmono and xmosaic... I guess i'd rather wait for R6 (due to 21. April) :-) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 10 23:50:45 1994 From: Hubert Feyrer Subject: Re: problems with: kernels Floppys scsi binaries ... To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) 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: 736 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > compiling a new ps results in nothing... no error, no output?? In order to get a working ps, you have to recompile libutil as well. > Also there is a problem with the floppy: Ups, have I missed something? Since when is the floppy drive supported?!? Hope this help a bit, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Apr 10 23:51:25 1994 From: Hubert Feyrer To: ahh@netcom.com, amiga-x@sun-lamp.cs.berkeley.edu Subject: XView 3.2 (was: Re: XRetinaZ2 problems) Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > On another topic, I'm pretty much done with my port of XView 3.2. Is > anyone else interested in this stuff? For sure!!! Could you please upload it to ftp.eunet.ch (or if nobody else wants it, into ftp.uni-regensburg.de:/pub/NetBSD/incoming). Thanks, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Apr 10 23:53:12 1994 From: Hubert Feyrer To: amiga-x@sun-lamp.cs.berkeley.edu, rhealey@aggregate.com Subject: Re: New X bins for "off_t" kernels Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > With the A2024's Xmono is the > best server available... Not only for the A2024! To all X-server-woiting wizards: Please don't forget us ECS-folks, I think there are enough people who have no Retina... Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Apr 10 23:54:41 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "_ite symbols in kernel" (Apr 9, 11:38pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Eric Augustine , amiga-x@sun-lamp.cs.berkeley.edu (NetBSD-X news-list NetBSD-Amiga-X) Subject: Re: _ite symbols in kernel Cc: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 9, 11:38pm, Eric Augustine wrote: > Just a quick enquiry - is there a list of the _ite_XXX > symbols in the kernel someplace? I am trying to alter > a few things (like the border colour) and am at a loss > as to which I have available to change and what I can > change them to... Doesn't iteconfig helps you already? Or do you own a Retina? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 10 23:58:26 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "_ite symbols in kernel" (Apr 9, 11:38pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Eric Augustine , amiga-x@sun-lamp.cs.berkeley.edu (NetBSD-X news-list NetBSD-Amiga-X) Subject: Re: _ite symbols in kernel Cc: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 9, 11:38pm, Eric Augustine wrote: > Just a quick enquiry - is there a list of the _ite_XXX > symbols in the kernel someplace? I am trying to alter > a few things (like the border colour) and am at a loss > as to which I have available to change and what I can > change them to... Doesn't iteconfig helps you already? Or do you own a Retina? -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Apr 11 00:04:10 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: XView 3.2 (was: Re: XRetinaZ2 problems) To: Hubert.Feyrer@rz.uni-regensburg.de (Hubert Feyrer) Cc: ahh@netcom.com, 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: 1396 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > Could you please upload it to ftp.eunet.ch (or if nobody else wants > it, into ftp.uni-regensburg.de:/pub/NetBSD/incoming). OK, I have placed the following files in ftp.eunet.ch's software/os/bsd/NetBSD/NetBSD-Amiga/incoming directory: 1041 Apr 10 14:11 xview32-10Apr94.README 1778897 Apr 10 12:49 xview32-10Apr94.tar.gz >From the README file: xview-19Apr94.tar.gz This archive contains the clients, libs, config files, includes, and a few bits of documentation for XView 3.2, an X toolkit that implements the OpenLook user interface. They were built on a system running a kernel from sources retrieved on 23 March 94, and binaries from Stephen Roznowski's 8 March 94 tar files. Sample ldd output: $ ldd /usr/bin/X11/olwm /usr/bin/X11/olwm: -lolgx.3 => /usr/lib/libolgx.so.3.2 (0x204e000) -lXext.5 => /usr/lib/libXext.so.5.0 (0x2058000) -lX11.5 => /usr/lib/libX11.so.5.0 (0x2060000) -lc.4 => /usr/lib/libc.so.4.0 (0x20aa000) The tar file was generated relative to root, and the XView files were compiled with a ProjectRoot of /usr/X11R5, so they will be placed into /usr/X11R5/lib, /usr/X11R5/man, /usr/X11R5/bin, etc. I have included some symbolic links from /usr/lib to /usr/X11R5/lib to make life easier. The best documentation for XView is Dan Heller's XView Programming Manual, published by O'Reilly & Associates, ISBN 0-937175-52-8. Andy Heffernan ahh@netcom.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 00:04:31 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: problems with: kernels Floppys scsi binaries ... Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 10, 5:44pm, Arthur Hoffmann wrote: > Hi, > I usually compile my own kernels and some binaries. So far > I had no problems with that, but recently I seem to have a slight > problem: > ps doesn't work with my newer kernels anymore it reports the > following: > ps: proc size mismatch (got 13846 total, kinfo_proc: 560) > > compiling a new ps results in nothing... no error, no output?? I was having the same problem a few days ago, and even a simple program with just a printf didn't do anything. I finally figured out that I had updated the /usr/include tree, but hadn't updated the libraries yet, so things were out of sync. As soon as I rebuilt libc, programs would print again. I would say the first thing to check is make sure /usr/include and the libraries are up to date and in sync. 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 Apr 11 00:05:04 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "problems with: kernels Floppys scsi binaries ..." (Apr 10, 5:44pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Arthur Hoffmann , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: problems with: kernels Floppys scsi binaries ... Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 10, 5:44pm, Arthur Hoffmann wrote: > I usually compile my own kernels and some binaries. So far > I had no problems with that, but recently I seem to have a slight > problem: > ps doesn't work with my newer kernels anymore it reports the > following: > ps: proc size mismatch (got 13846 total, kinfo_proc: 560) Yes, i encountered the same problem and figured i must recompile 'ps' for the new kernel - seems off_t (64Bit stuff) buggers here already. > compiling a new ps results in nothing... no error, no output?? Got to wait for the whole changes for off_t in the entire tree. I am glad that i was finally able to recompile my own kernel, had to update quite a lot of stuff (new binaries and /usr/share/misc and /usr/share/mk and so on..), and was surprised when finally not even a single error and only 2 warnings were claimed during compilation, keep on the good work Chops! -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 11 00:05:44 1994 From: Hubert Feyrer Subject: ncftp-1.7.2 uploaded 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: 887 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've just uploaded ncftp-1.7.2.tar.gz into /pub/NetBSD-Amiga/incoming on ftp.eunet.ch and ftp.uni-regensburg.de: -rw-r--r-- 1 bsdadmin ftpadmin 79726 Apr 10 17:51 ncftp-1.7.2.tar.gz The archive contains the executable binary (runs fine on my #744-kernel) and a formatted man-page: dusk% tar zvtf ncftp-1.7.2.tar.gz -rwxr-xr-x hubert/wheel 155648 Apr 10 18:47 1994 ncftp -rw-r--r-- hubert/wheel 43196 Apr 10 18:50 1994 ncftp.0 Enjoy! Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 00:15:45 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Status of new binaries Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Since Chris has mentioned this twice.... I'm in the process of building a new set of binaries from the 8 April sources. I'm to the stage where I'm attempting to rebuild the entire tree for the second time. I should be uploading them soon. With this set of binaries, we'll be moving the primary site to sun-lamp (or its mirrors) and the format will be slightly different (actually, like all the other architecture's binaries :-) I'll email after I've uploaded. -SR From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 11 00:32:04 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Status of new binaries Sender: owner-amiga@sun-lamp.cs.berkeley.edu Since Chris has mentioned this twice.... I'm in the process of building a new set of binaries from the 8 April sources. I'm to the stage where I'm attempting to rebuild the entire tree for the second time. I should be uploading them soon. With this set of binaries, we'll be moving the primary site to sun-lamp (or its mirrors) and the format will be slightly different (actually, like all the other architecture's binaries :-) I'll email after I've uploaded. -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 00:33:42 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Status of new binaries" (Apr 10, 5:35pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Stephen J. Roznowski" , amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Status of new binaries Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 10, 5:35pm, "Stephen J. Roznowski" wrote: > With this set of binaries, we'll be moving the primary site > to sun-lamp (or its mirrors) and the format will be slightly > different (actually, like all the other architecture's binaries :-) While you're at it, consider to make the binaries in a way they might be 'binary' compatible to other m68k platforms? And please don't forget libexec and the rest of the network-utils. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 11 00:57:35 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Status of new binaries" (Apr 10, 5:35pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Stephen J. Roznowski" , amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Status of new binaries Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 10, 5:35pm, "Stephen J. Roznowski" wrote: > With this set of binaries, we'll be moving the primary site > to sun-lamp (or its mirrors) and the format will be slightly > different (actually, like all the other architecture's binaries :-) While you're at it, consider to make the binaries in a way they might be 'binary' compatible to other m68k platforms? And please don't forget libexec and the rest of the network-utils. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 01:25:01 1994 From: Hubert Feyrer To: amiga-dev@sun-lamp.cs.berkeley.edu, sjr@zombie.ncsc.mil Subject: Re: Status of new binaries Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > we'll be moving the primary site > to sun-lamp (or its mirrors) ... What do you mean by this? Will ftp.eunet.ch not be the NetBSD-Amiga main-site any longer? Running a mirror, I'd like to be kept up to date on this subject, please! 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 Mon Apr 11 01:27:36 1994 From: rhealey@aggregate.com Subject: Re: Status of new binaries To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: sjr@zombie.ncsc.mil, amiga-dev@sun-lamp.cs.berkeley.edu, 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: 889 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > On Apr 10, 5:35pm, "Stephen J. Roznowski" wrote: > > With this set of binaries, we'll be moving the primary site > > to sun-lamp (or its mirrors) and the format will be slightly > > different (actually, like all the other architecture's binaries :-) > > While you're at it, consider to make the binaries in a way they > might be 'binary' compatible to other m68k platforms? > > And please don't forget libexec and the rest of the network-utils. > Ummm, how about the fact that Sun Lamp is very rarely, if ever, reachable via FTP; as a practical matter... sun-lamp is HEAVILY used and has very low limits on ftp and other services. While it's nice to have stuff on sun-lamp, it will be almost impossible for anybody to actually retrieve binaries via ftp from sun-lamp. At least ftp.eunet.ch isn't ALWAYS busy... Even the mirrors might have a touch time getting in. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 01:31:28 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Status of new binaries To: Hubert.Feyrer@rz.uni-regensburg.de (Hubert Feyrer) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, sjr@zombie.ncsc.mil X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 916 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > > we'll be moving the primary site > > to sun-lamp (or its mirrors) ... > > What do you mean by this? Will ftp.eunet.ch not be the NetBSD-Amiga > main-site any longer? > > Running a mirror, I'd like to be kept up to date on this subject, > please! What it means ins that binary snapshots for amiga will show up on sun-lamp just like all the other systems and in the standard `make snapshot' format. Whether it gets onto ftp.eunet.ch is up to someone else. However I think having ftp.eunet.ch as a main site for amiga specific things is still a good idea, so I hope the snapshot makes it their. There are no US mirrors of eunet. there is a least one UK mirror of sun-lamp along with at least one US mirror. This was only part of the motivation for this switch. Many others include me having immediate access to the amiga's ftp directory; being inline with the rest of the ports etc etc... Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 01:41:29 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Status of new binaries To: rhealey@aggregate.com Cc: markus@techfak.uni-bielefeld.de, sjr@zombie.ncsc.mil, amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 821 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Ummm, how about the fact that Sun Lamp is very rarely, if ever, > reachable via FTP; as a practical matter... sun-lamp is HEAVILY > used and has very low limits on ftp and other services. While > it's nice to have stuff on sun-lamp, it will be almost impossible > for anybody to actually retrieve binaries via ftp from sun-lamp. At > least ftp.eunet.ch isn't ALWAYS busy... Even the mirrors might > have a touch time getting in. Umm, the mirrors that exist now get through fine. I prefer ftp'ing to US sites as well should other US residents.. I get 90k/s to US sites 5k/s to eunet. As I stated before sun-lamp gets mirrored all over the world eunet does not get mirrored to the states. No-one should be trying to ftp to sun-lamp. sup and ftp mirrors exist. try ftp.iastate.edu in (US) > -Rob Chris. From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Apr 11 01:41:48 1994 From: rhealey@aggregate.com Subject: Re: New X bins for "off_t" kernels To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: rhealey@aggregate.com, amiga-x@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: 822 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > On Apr 10, 12:39am, rhealey@aggregate.com wrote: > > Subject: New X bins for "off_t" kernels > > > > Is anybody going to cut new versions of the X binarys for the > > new kernels with 64 bit off_t's and 32 bit uid/gid? I'm especially > > interested in new versions of the libes, Xmono and xmosaic... > > I guess i'd rather wait for R6 (due to 21. April) :-) > R6 won't do us squat bit of good as only the x86 stuff would be in it. It will take a while to port. Meanwhile, anybody who upgrades to -current now will lose all X support. B^(. X uses alot of the OS effected by off_t and uid/gid stuff; hell, the C library alone has gone from 1 to 9 since the last binaries were cut. B^(. While I think R6 will be C0OL, we need new binaries to hold us until Amiga versions of R6 server's can be done. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 11 01:55:50 1994 From: rhealey@aggregate.com Subject: Re: Status of new binaries To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: sjr@zombie.ncsc.mil, amiga-dev@sun-lamp.cs.berkeley.edu, 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: 889 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > On Apr 10, 5:35pm, "Stephen J. Roznowski" wrote: > > With this set of binaries, we'll be moving the primary site > > to sun-lamp (or its mirrors) and the format will be slightly > > different (actually, like all the other architecture's binaries :-) > > While you're at it, consider to make the binaries in a way they > might be 'binary' compatible to other m68k platforms? > > And please don't forget libexec and the rest of the network-utils. > Ummm, how about the fact that Sun Lamp is very rarely, if ever, reachable via FTP; as a practical matter... sun-lamp is HEAVILY used and has very low limits on ftp and other services. While it's nice to have stuff on sun-lamp, it will be almost impossible for anybody to actually retrieve binaries via ftp from sun-lamp. At least ftp.eunet.ch isn't ALWAYS busy... Even the mirrors might have a touch time getting in. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 11 02:06:05 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Status of new binaries To: rhealey@aggregate.com Cc: markus@techfak.uni-bielefeld.de, sjr@zombie.ncsc.mil, amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 821 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Ummm, how about the fact that Sun Lamp is very rarely, if ever, > reachable via FTP; as a practical matter... sun-lamp is HEAVILY > used and has very low limits on ftp and other services. While > it's nice to have stuff on sun-lamp, it will be almost impossible > for anybody to actually retrieve binaries via ftp from sun-lamp. At > least ftp.eunet.ch isn't ALWAYS busy... Even the mirrors might > have a touch time getting in. Umm, the mirrors that exist now get through fine. I prefer ftp'ing to US sites as well should other US residents.. I get 90k/s to US sites 5k/s to eunet. As I stated before sun-lamp gets mirrored all over the world eunet does not get mirrored to the states. No-one should be trying to ftp to sun-lamp. sup and ftp mirrors exist. try ftp.iastate.edu in (US) > -Rob Chris. From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Apr 11 03:11:20 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.x From: tsarna@endicor.com (Ty Sarna) Subject: Re: New X bins for "off_t" kernels Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu In article <9404102257.AA05969@sirius.aggregate.com> rhealey@aggregate.com writes: > > I guess i'd rather wait for R6 (due to 21. April) :-) I believe the day is April 15 (aka Tax Day in the US. BTW, irrelevant tax factoid: I read today where some unfortunate businesses in Russia have found themselves in a 120% tax bracket!!!) > R6 won't do us squat bit of good as only the x86 stuff would be > in it. It will take a while to port. Meanwhile, anybody who Not entirely true... the client side stuff that the X86 Consortium did is supposed to include support for all of NetBSD, not just NetBSD/i386. Ie, imake templates, etc. So the client side should port easily. Obviously the amiga servers woun't be in there, but I wouldn't immagine that will take TOO long to port to R6. > upgrades to -current now will lose all X support. B^(. X uses > alot of the OS effected by off_t and uid/gid stuff; hell, the There are already people (members of the X consortium) running R6 on NetBSD/i386 with 64 bit off_t's, apparently, so I wouldn't worry too much about that at least for R6. > C library alone has gone from 1 to 9 since the last binaries > were cut. B^(. Anyone want to take wagers on how high it will get before NetBSD 1.0? :-) > While I think R6 will be C0OL, we need new binaries to hold us > until Amiga versions of R6 server's can be done. Agreed, though for off_t reasons it might be best to wait a bit for R6. -- 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 Mon Apr 11 03:53:06 1994 Subject: Latest kernel 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, let's see if I got this straight.. My supfile looks like this: current release=doc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp base=/ecl/dej/ftp/netbsd prefix=/ecl/dej/ftp/netbsd backup use-rel-suffix current release=ksrc-common host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp base=/ecl/dej/ftp/netbsd prefix=/ecl/dej/ftp/netbsd backup use-rel-suffix current release=ksrc-amiga host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp base=/ecl/dej/ftp/netbsd prefix=/ecl/dej/ftp/netbsd backup use-rel-suffix I tried to sup today, and got nothing new (the file dates in my directories did not change). I understand that there is a floppy driver, as well as a whole bunch of code for 64-bit off_t support. Questions: 1. Is my supfile correct? I invoke sup with "sup -f supfile". 2. Should there be a floppy driver in what I'm sup'ing? (Hopefully, the latest, if not greatest, sources.) 3. How badly will the 64-bit off_t's break me? Can I run a 64 bit kernel using 32-bit binaries? Meaning, make damn sure the kernel works before upgrading binaries cuz you can't run 64 bit binaries on a 32 bit kernel. Is it true that NONE of the X stuff will work on a 64 bit kernel? What else won't work? If the 32 bit binaries won't work, then how am I supposed to upgrade (other than new rootfs with tar/gzip on it). 4. What's the status on non-buggy, VM-efficient 4/16 color X servers for ECS? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 04:25:39 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Latest kernel 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: 571 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu you can upgrade your kernel without changing your binaries however *do not* install new includes. If you do so you will no longer be able to compile things until you update everything. Aside from that the new kenrel is fully backward compatible including X. However becuase of changes *long* ago old X libs won't allow you to compile anything for X. You have to be one of those lucky people that have room on their HD's to compile a new X environment. Unfortunately I am not one of those people otherwise I would have uploaded new libs and clients long ago. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 05:03:57 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: This week's NetBSD/amiga changes To: tero.manninen@oulu.fi (Tero Manninen) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1678 Sender: owner-amiga-dev@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/dev > > In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev > > > > Modified Files: > > fd.c > > Log Message: > > all amigas ahve internal drive so anything to the contrary is bogus. > > > > > > --------------------------------- > > For the moment, in my amiga there is no floppy drive. I planned to use > that space for a 3rd hard disk, but noticed that A3000 power switch > makes that space too low :-( Anyway, there are amigas that have no > internal floppy drive :-) > > ++Tero > I myself would vote against saying all amigas have an internal drive. There should be absolutely no reason to make such an assumption. The reason for it is the code to get the floppy type isn't working right. I think its a problem with gcc over optimizing the code. I have sent new assembly code to Chris to try out. I hope when this is working the assumptions can be removed. +----------------------------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 Apr 11 07:37:53 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Floppy driver (was: Re: This week's NetBSD/amiga changes) Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9404110211.AA20743@sun> pepersb@cuug.ab.ca (Brad Pepers) writes: > I myself would vote against saying all amigas have an internal drive. There > should be absolutely no reason to make such an assumption. The reason for > it is the code to get the floppy type isn't working right. I think its a > problem with gcc over optimizing the code. I have sent new assembly code > to Chris to try out. I hope when this is working the assumptions can be > removed. I would like to see support for the 1020 5.25" floppy drive -- it's very handy for interchange of MS-DOS floppies with old 5.25" only systems (yes, I know it doesn't do MS-DOS format yet, but someday...). I assume that since the floppy driver doesn't support or care about diskchange (right?) that the only change neccesary would be to add a line to the ID table with the proper information. Hmmm... looking through the Hardware RKM, I can't ind an ID defined for the 5.25" drives, unless it's one of the Reserved values. I guess when I update to the current sources I'll have to see what it ID's as, if anything. If it doesn't ID itself, there will have to be some way for a user program to tell the driver that a drive is present and tell it the various parameters. -- 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 Mon Apr 11 08:40:23 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Latest kernel 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 Sun, 10 Apr 1994, David Jones wrote: > OK, let's see if I got this straight.. > 2. Should there be a floppy driver in what I'm sup'ing? (Hopefully, the > latest, if not greatest, sources.) It's in there all right. I'm just waiting for a config file with it enabled so I can test it out. > 3. How badly will the 64-bit off_t's break me? Can I run a 64 bit kernel > using 32-bit binaries? Meaning, make damn sure the kernel works before > upgrading binaries cuz you can't run 64 bit binaries on a 32 bit kernel. > Is it true that NONE of the X stuff will work on a 64 bit kernel? What > else won't work? If the 32 bit binaries won't work, then how am I > supposed to upgrade (other than new rootfs with tar/gzip on it). off_t is not a problem as long as you: 1) Keep your old 32 bit off_t libraries around 2) Don't upgrade your /usr/includes until you get 64 bit off_t libraries. > 4. What's the status on non-buggy, VM-efficient 4/16 color X servers for > ECS? Be patient. I have the blitter drawing lines just fine. Area blits are still a bit of a problem. ========================================================================= 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 Mon Apr 11 23:12:42 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hey, but you're missing a very important point.. this means that we can support HD floppies now, right? -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 23:15:39 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 <9404111012.AA29654@jade.techfak.uni-bielefeld.de> markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) writes: > In my eyes 5.25" floppy is an anachronism these days - all PCs i have access > to have 3.5" floppies, HD and even ED. You milage may vary of course. Mine does :-). For one thing, old bridgeboards only have 5.25" floppies. Also there are various wierd non-PC machines out there (AT&T 3B1, for example) that can read DOS 5.25" floppies, and it's useful for interchange with them. > I'd rather want to have support for HD-Floppies buildt-in in A4000 and > most 3000. Kids, kids, it's a floorwax *and* a desert topping! :-) You can have both (and HD support is in there, but it's broken). Adding 5.25" support is just a matter of cloning the 3.5" DD line in the ID table and changing a few parameters. -- 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 Mon Apr 11 23:21:30 1994 From: Olaf Seibert To: chopps@emunix.emich.edu, rhealey@aggregate.com Subject: Re: Status of new binaries Cc: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de, sjr@zombie.ncsc.mil Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu chopps@emunix.emich.edu (Chris Hopps) wrote: > sup and ftp mirrors exist. try ftp.iastate.edu in (US) ftp.iastate.edu does not seem to have a sup server - at least not on port 871. I'd love to reduce load on sun-lamp but so far it has been the only sup server that I've seen working. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 23:29:52 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: Latest kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 10, 10:35pm, "Eduardo E. Horvath eeh@btr.com" wrote: > On Sun, 10 Apr 1994, David Jones wrote: > > > OK, let's see if I got this straight.. > > > 2. Should there be a floppy driver in what I'm sup'ing? (Hopefully, the > > latest, if not greatest, sources.) > > It's in there all right. I'm just waiting for a config file with it > enabled so I can test it out. I added: device fd0 at manufacturer 1 product 10 (and had to build a new config, since the one I was using complained about needing a floppy controller entry). 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 Apr 11 23:40:44 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Latest kernel" (Apr 10, 9:23pm) 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: Latest kernel Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 10, 9:23pm, Chris Hopps wrote: > that have room on their HD's to compile a new X environment. Unfortunately > I am not one of those people otherwise I would have uploaded new libs and > clients long ago. Same here, i am seeking for a sponsor for either new harddrive or CD-ROM to be able to compile new X11 binary set :-) Let's see what i can do, isn't it possible to cross-compile stuff and even link on other machines? Or do i miss something? -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 23:57:51 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Floppy driver (was: Re: This week's NetBSD/amiga changes)" (Apr 11, 3:58am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tsarna@endicor.com (Ty Sarna), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 3:58am, Ty Sarna wrote: > I would like to see support for the 1020 5.25" floppy drive -- it's very > handy for interchange of MS-DOS floppies with old 5.25" only systems > (yes, I know it doesn't do MS-DOS format yet, but someday...). I assume [...] In my eyes 5.25" floppy is an anachronism these days - all PCs i have access to have 3.5" floppies, HD and even ED. You milage may vary of course. I'd rather want to have support for HD-Floppies buildt-in in A4000 and most 3000. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 00:09:07 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: Latest kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 1:37pm, Olaf Seibert wrote: > "Eduardo E. Horvath eeh@btr.com" wrote: > > On Sun, 10 Apr 1994, David Jones wrote: > > > OK, let's see if I got this straight.. > > > > > 2. Should there be a floppy driver in what I'm sup'ing? (Hopefully, the > > > latest, if not greatest, sources.) > > > > It's in there all right. I'm just waiting for a config file with it > > enabled so I can test it out. > > I put in > > device fd0 at manufacturer 1 product 10 > > and the kernel reports it when booting. Haven't tried any more though. > I'm not quite sure why there are *two* builtin product codes for > floppies: PROD_BUILTIN_FLOPPY (2) and PROD_BUILTIN_FLOP (10). > The latter seems to be the right one. I think the product 2 was put in originally in anticipation of having floppy support, and was is set up as a controller (as opposed to a device). So you would device the controller as "floppy0" and define the devices connected to the controller (in the same manner as the scsi devices). The current floppy suppport treats the floppy device differently (see autoconf.c), so was given a different product code. I've been playing with the driver a bit, and have gotten it to read fine, but I've had problems when writing to the floppy. I've even built a very minimal boot floppy and booted NetBSD a couple of times using the floppy as the root file system. I had to modify the delay() routine since a 33Mhz 68040 runs a bit faster than the 68030 systems. 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 Apr 12 00:10:38 1994 From: Markus Landgraf To: chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: catman Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu As I tried to compile catman from src/usr.bin/man, I discovered some bugs in the code. The first bug was, there was a segmentation fault when the user didn't specify arguments to the program, secondly the programm tried to reformat _all_ entries in a man subdir, so it produced errors when trying to reformat _subdirs_. Here are my pathes, you may use in on catman.c, if you like. *** catman.c.orig Sat Apr 9 10:37:41 1994 --- catman.c Sat Apr 9 12:46:00 1994 *************** static char rcsid[] = "$Id: catman.c,v 1 *** 42,47 **** --- 42,48 ---- #include #include #include + #include int no_whatis = 0; int just_print = 0; *************** main(argc, argv) *** 90,96 **** if (argc > 1) usage (); ! if (argc == 0) sp = *argv; catman(mp, sp); --- 91,97 ---- if (argc > 1) usage (); ! if (argc == 1) sp = *argv; catman(mp, sp); *************** catman(path, section) *** 115,120 **** --- 116,123 ---- char sysbuf[1024]; char *s; int formatted = 0; + char manpat[6]; + regex_t manre; if (!just_whatis) { for (s = section; *s; s++) { *************** catman(path, section) *** 144,150 **** while ((dp = readdir(dirp)) != NULL) { if (!strcmp(dp->d_name, ".") || !strcmp(dp->d_name, "..")) continue; ! sprintf(manpage, "%s/%s", mandir, dp->d_name); sprintf(catpage, "%s/%s", catdir, dp->d_name); if ((s = strrchr(catpage, '.')) != NULL) --- 147,162 ---- while ((dp = readdir(dirp)) != NULL) { if (!strcmp(dp->d_name, ".") || !strcmp(dp->d_name, "..")) continue; ! sprintf(manpat,".*\\.%c",*s); ! if(regcomp(&manre,manpat,0)==0) ! { ! if(regexec(&manre,dp->d_name,0,0,0)) ! { ! regfree(&manre); ! continue; ! } ! regfree(&manre); ! } sprintf(manpage, "%s/%s", mandir, dp->d_name); sprintf(catpage, "%s/%s", catdir, dp->d_name); if ((s = strrchr(catpage, '.')) != NULL) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 00:15:23 1994 From: Olaf Seibert To: dej@eecg.toronto.edu, eeh@btr.btr.com Subject: Re: Latest kernel Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 11 07:56:11 1994 > Received: from sun-lamp.CS.Berkeley.EDU by augustus.mbfys.kun.nl with SMTP id AA06258 > (5.61/ for rhialto); Mon, 11 Apr 94 07:56:10 +0200 > Received: (from mailman@localhost) by sun-lamp.cs.berkeley.edu (8.6.8/8.6.6) id WAA01057 for amiga-dev-outgoing; Sun, 10 Apr 1994 22:38:01 -0700 > Received: from openlink.openlink.com (openlink.openlink.com [192.132.242.105]) by sun-lamp.cs.berkeley.edu (8.6.8/8.6.6) with SMTP id WAA01049 for ; Sun, 10 Apr 1994 22:37:50 -0700 > Received: from btr.btr.com by openlink.openlink.com with SMTP id AA09455 > (5.67b/IDA-1.5 for ); Sun, 10 Apr 1994 22:39:28 -0700 > Received: by btr.btr.com id AA13088 > (5.67b/IDA-1.5); Sun, 10 Apr 1994 22:35:08 -0700 > Date: Sun, 10 Apr 1994 22:35:07 -0700 (PDT) > Subject: Re: Latest kernel > To: David Jones > Cc: amiga-dev@sun-lamp.cs.berkeley.edu > In-Reply-To: <94Apr10.210420edt.18961@picton.eecg.toronto.edu> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Precedence: bulk > Status: RO > "Eduardo E. Horvath eeh@btr.com" wrote: > On Sun, 10 Apr 1994, David Jones wrote: > > OK, let's see if I got this straight.. > > > 2. Should there be a floppy driver in what I'm sup'ing? (Hopefully, the > > latest, if not greatest, sources.) > > It's in there all right. I'm just waiting for a config file with it > enabled so I can test it out. I put in device fd0 at manufacturer 1 product 10 and the kernel reports it when booting. Haven't tried any more though. I'm not quite sure why there are *two* builtin product codes for floppies: PROD_BUILTIN_FLOPPY (2) and PROD_BUILTIN_FLOP (10). The latter seems to be the right one. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 00:25:59 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, tsarna@endicor.com Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu tsarna@endicor.com (Ty Sarna) > Hmmm... looking through the Hardware RKM, I can't ind an ID defined for > the 5.25" drives, unless it's one of the Reserved values. I guess when I > update to the current sources I'll have to see what it ID's as, if > anything. If it doesn't ID itself, there will have to be some way for a > user program to tell the driver that a drive is present and tell it the > various parameters. There is one defined, I'm sure. Except that the drive id actually means '40 tracks' instead of '135 mm'. The id that says '90 mm' actually means '80 tracks'. Not all external drives seem to get this entirely right, though. One gotcha is that drives that can switch between 40 and 80 track modes only can be switched before a (re)boot of AmigaOS; at least on older versions of AmigaOS. (Newer versions with high-density support query the type on each disk change, and judging from the drive activity light more often as well) To find the 40-track id, look in the Amiga include files; I'm pretty sure it sits next to the 80-track id. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 00:35:44 1994 From: rhealey@aggregate.com Subject: Re: Latest kernel To: rhialto@mbfys.kun.nl (Olaf Seibert) 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: 1673 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I put in > > device fd0 at manufacturer 1 product 10 > > and the kernel reports it when booting. Haven't tried any more though. > I'm not quite sure why there are *two* builtin product codes for > floppies: PROD_BUILTIN_FLOPPY (2) and PROD_BUILTIN_FLOP (10). > The latter seems to be the right one. > At the risk of sounding snotty, the floppy driver wasn't done strictly by the formal book. Technically the driver should have two parts, one the floppy controller (PROD_BUILTIN_FLOPPY) and two the per drive code (PROD_BUILTIN_FLOP). The distinction is subtle... Look at the way a SCSI disk or tape is actually configured and you'll see what I'm taking about. After much fiddling I still can't get the driver to actually work and after comparing the NetBSD and AMIX floppy driver source I get the feeling the NetBSD floppy driver is a first cut and not the polished end product. It's a GREAT first cut! At least someone gave us a base from which to start! THANKS! Whomever you are. With that said, it still doesn't support HD floppy drives or MSDOS format drives. It also isn't in the normal controller/slave model of the NetBSD kernel. Plenty of things for some of us to contribute our efforts to! Now, if someone can contribute a first stab at an audio device we can really start hacking! There is some rudimentory support in the custom chip code but no device interface yet. Oh, anybody redone the 2232 serial card 6502 code so we can FINALLY put the 2232 driver in the source tree? Hmm, with C= in rought shape maybe we can buy the rights to the 6502 assembly code that came with AMIX. But who would one talk to at C= about this? -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 00:45:32 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu oops, I really gotta learn to read someday.. ;-) -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 00:46:30 1994 From: rhealey@aggregate.com Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) To: tsarna@endicor.com (Ty Sarna) 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: 2230 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > In article <9404110211.AA20743@sun> pepersb@cuug.ab.ca (Brad Pepers) writes: > > I myself would vote against saying all amigas have an internal drive. There > > should be absolutely no reason to make such an assumption. The reason for > > it is the code to get the floppy type isn't working right. I think its a > > problem with gcc over optimizing the code. I have sent new assembly code > > to Chris to try out. I hope when this is working the assumptions can be > > removed. > > I would like to see support for the 1020 5.25" floppy drive -- it's very > handy for interchange of MS-DOS floppies with old 5.25" only systems > (yes, I know it doesn't do MS-DOS format yet, but someday...). I assume > that since the floppy driver doesn't support or care about diskchange > (right?) that the only change neccesary would be to add a line to the ID > table with the proper information. > > Hmmm... looking through the Hardware RKM, I can't ind an ID defined for > the 5.25" drives, unless it's one of the Reserved values. I guess when I > update to the current sources I'll have to see what it ID's as, if > anything. If it doesn't ID itself, there will have to be some way for a > user program to tell the driver that a drive is present and tell it the > various parameters. > Another data point: The AMIX floppy driver, which support 720K, 880K, 1.44M formats and ALOT of "magic" and "juju" comments in it and twiggles and frobnicates many mysterious registers above and beyond what the code in -current does. It also has a "helper" process that ends up being a kernel process, i.e. it's a user mode daemon that starts up and does an open on a special device minor that then forces it to remain in kernel mode where it services delay timeouts and other housekeeping functions. My guess it is an attempt to emulate track.device. Anyways, it would appear there are more bits the floppy driver needs to frob in order to work right. Anybody know if any of the old AMIX hackers are still floating around? Maybe they could explain the weirdness in the AMIX floppy driver. The AMIX driver is rock solid and supports both low density and high density drives although it doesn't appear to support 5-1/4". -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 01:07:30 1994 From: Ty Sarna Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Organization: Endicor Technologies, Inc., San Antonio, Texas X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1875 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Cc'ing the list since this is of interest... hope you don't mind Bill. William J Coldwell wrote: > > Got 2.04 RKM:Devices? Pg. 337 > > Amiga: $00000000 > 5.25": $55555555 > Amiga: $00000000 (high density) > None : $FFFFFFFF Interesting! These are inverted from the values RKM:Hardware gives. (see page 371) > Dunno how you're supposed to tell an HD from a normal 3.5"... sigh.. could be > a screw up in the manual. It is and isn't apparently. Since I have every kind of floppy drive on one machine or another, I typed in the program and tried it out. The values above are what it reports. the HD drive reports $00000000 for DD floppies, $AAAAAAAA for HD floppies. If no floppy is inserted, it reports the value of the last floppy, or $00000000 if no floppy was ever inserted this boot. RKM:Hardware reports the exact inverse values, so I guess disk.resource inverts the values before returning them... dunno why... So: 3.5" DD = ~00000000 = FFFFFFFF 3.5" HD = ~AAAAAAAA = 55555555 5.25" = ~55555555 = AAAAAAAA (listed as reserved in RKM:Hardware) None = ~FFFFFFFF = 00000000 ( " " " " " ) Just clone the 3.5" DD entry in the id table, change the number of tracks to 40, set the id to $AAAAAAAA and change the name. Voila! 5.25" support! That's my theory, anyway... :-) Also, I'd have to look at the fd.c source again, but I don't think it does HD mode correctly right now. It needs to re-read the ID whenever the disk changes (which isn't detected, so I guess it has to be done on every track read or write? ewww... Actually, maybe it only needs to be checked on open. Hmm... yeah I think that would work.) Applogies if the driver already does that. -- 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 Apr 12 01:14:01 1994 From: drahn@pacific.urbana.mcd.mot.com (Dale Rahn) Subject: Re: Latest kernel To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: chopps@emunix.emich.edu, dej@eecg.toronto.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1551 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > On Apr 10, 9:23pm, Chris Hopps wrote: > > that have room on their HD's to compile a new X environment. Unfortunately > > I am not one of those people otherwise I would have uploaded new libs and > > clients long ago. > > Same here, i am seeking for a sponsor for either new harddrive or > CD-ROM to be able to compile new X11 binary set :-) > > Let's see what i can do, isn't it possible to cross-compile stuff and > even link on other machines? Or do i miss something? > Like what host??? A few weeks ago I attempted to compile NetBSD-Amiga binaries on NetBSD-i386 but ran into some problems with the "half done" support on some of utilities. (ld) I managed to get gcc/gas/ld all compiled to produce NetBSD-amiga objects but ran into a problem with other necessary utilities to build the entire system. (nm, lorder, ar) I looked at these other programs and saw that they too could be fixed to recognise other byte order architectures but didn't have time. I could make availiable the changes I made and the "hacky" environment I was attempting to build stuff in. I do not claim that everything was working correctly however, My executables did not run on my 720 kernel system (yes very old) and the kernel I built wouldn't do anything never initialized the screen or printed anything on it. ------------------------------------------------------------------------ Dale Rahn, Languages and Tools drahn@urbana.mcd.mot.com Motorola, MCG, Urbana Design Center 1101 E. University Ave, Urbana, IL 61801 (217) 384-8585 From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 12 01:23:45 1994 From: "Dave R. Madsen" Subject: Retina X servers To: amiga-x@sun-lamp.cs.berkeley.edu Cc: madsen@cs.iastate.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I purchased a Retina (the original Zorro II version) last week and while the Retina console works great, I have been having trouble finding an X server that will work with it. First I tried using the xretina.tar.gz package which is on ftp.eunet.ch in contrib/bsd/X11, but that server gives me a segmentation fault immediately after it is executed. I then tried the new XRetinaZ2 archive that was put into incoming. The Xconfig that came with this server defined a screen mode that my monitor was unable to reproduce, so I used DefineMonitor under amigados to create one that should work. This X server starts up fine, but the screen is offset majorly down and to the right and flickers horribly, making it unusable. The new Xconfig that I created is listed below: ; 800x600, 8 bit, 37878 Hz, 60 Hz ID 781859636 FQ 80000000 MD 0 FLG 4 SW 800 SH 600 MW 800 MH 600 HBS 201 HSS 202 HSE 219 HBE 260 HT 259 VBS 601 VSS 602 VSE 612 VBE 628 VT 628 This monitor defination works fine when using the "test" gadget under AmigaDOS, but produces the strange, contorted screen described above when trying to use it with XRetinaZ2. I am using the kernel created by the April 10th tar file of the src/sys tree on sun-lamp. Does anyone have a working X server using the Retina board? If so, what Xconfig and version of the kernel/libraries are you using? I purchased this board specifically for X under netbsd so any help/advice/tips you can give me would be greatly appreciated. Thanks, Dave (madsen@cs.iastate.edu) From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 12 01:25:10 1994 From: rhealey@aggregate.com Subject: Re: New X bins for "off_t" kernels To: tsarna@endicor.com (Ty Sarna) Cc: amiga-x@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: 2000 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > In article <9404102257.AA05969@sirius.aggregate.com> rhealey@aggregate.com writes: > I believe the day is April 15 (aka Tax Day in the US. BTW, irrelevant > tax factoid: I read today where some unfortunate businesses in Russia > have found themselves in a 120% tax bracket!!!) > Nope, April 15th is for the members, the general public has to wait till at least the end of the month. > > R6 won't do us squat bit of good as only the x86 stuff would be > > in it. It will take a while to port. Meanwhile, anybody who > > Not entirely true... the client side stuff that the X86 Consortium did > is supposed to include support for all of NetBSD, not just NetBSD/i386. > Ie, imake templates, etc. So the client side should port easily. > Obviously the amiga servers woun't be in there, but I wouldn't immagine > that will take TOO long to port to R6. > No but that still would leave those of us who want to debug the "off_t" kernel Xless for a few weeks; SHUDDER!!! > > upgrades to -current now will lose all X support. B^(. X uses > > alot of the OS effected by off_t and uid/gid stuff; hell, the > There are already people (members of the X consortium) running R6 on > NetBSD/i386 with 64 bit off_t's, apparently, so I wouldn't worry too > much about that at least for R6. > The client librarys aren't the problem. I've got gobs of patches for X11R5 and off_t stuff the x86 guys cranked out. The trouble is the server. If I install the off_t includes to make the clients the server will hurl on the librarys produced. B^(. > Anyone want to take wagers on how high it will get before NetBSD 1.0? > :-) > Hmmm, imaginary or real part of the number? B^). > > While I think R6 will be C0OL, we need new binaries to hold us > > until Amiga versions of R6 server's can be done. > Agreed, though for off_t reasons it might be best to wait a bit for R6. > But I want my cake, X11, and to eat it to, work on the 64/32/32 kernel and librarys to debug things and clean it up. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 01:40:23 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: Floppy driver (was: Re: This week's NetBSD/amiga changes) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 2:59am, Ty Sarna wrote: > Also, I'd have to look at the fd.c source again, but I don't think it > does HD mode correctly right now. It needs to re-read the ID whenever > the disk changes (which isn't detected, so I guess it has to be done on > every track read or write? ewww... Actually, maybe it only needs to be > checked on open. Hmm... yeah I think that would work.) Applogies if the > driver already does that. I think it does. The open routine calls fd_probe, which re-reads the ID. It also sets the current cylinder to -1, which forces a recalibrate on every open (it took me a while to figure out why the drive recalibrated every time ran dd on it). A rather nasty thing that can happen is that when the ID is read, the drive gets deselected, but doesn't update the drive tables. If the drive motor was turned off, the recalibrate works fine, but if you access the drive before the motor-off timeout occurs, the fd_probe deslects the drive and when the recalibrate tries to seek to track 0, it never sees it because no drive is selected. 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 Apr 12 01:43:16 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) 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: 3658 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Cc'ing the list since this is of interest... hope you don't mind Bill. > > William J Coldwell wrote: > > > > Got 2.04 RKM:Devices? Pg. 337 > > > > Amiga: $00000000 > > 5.25": $55555555 > > Amiga: $00000000 (high density) > > None : $FFFFFFFF > > Interesting! These are inverted from the values RKM:Hardware > gives. (see page 371) > > > Dunno how you're supposed to tell an HD from a normal 3.5"... sigh.. could be > > a screw up in the manual. The four drive types are 00000000, 55555555, AAAAAAAA, and FFFFFFFF. The problem or source of confusing is that this is retrieved using the RDY line which is active low. In at least one place in the manual it says to invert what you get. Other parts of the manual seem to say it is not to be inverted. So the 00000000/FFFFFFFF is for no drive and 880K drives and the 55555555/AAAAAAAA is for 5 1/4 and 1760K drives. Which is which depends on if you invert or not. There is a bug in the current id code that causes it to give different results on different machines. Really odd. I think its a problem with gcc over-optimizing the code or maybe a timing thing. I have sent some code from an operating system I wrote for the amiga that worked better. It was in asm though so it may take Chris a while to get it in the code. > It is and isn't apparently. Since I have every kind of floppy drive on > one machine or another, I typed in the program and tried it out. The > values above are what it reports. the HD drive reports $00000000 for > DD floppies, $AAAAAAAA for HD floppies. If no floppy is inserted, it > reports the value of the last floppy, or $00000000 if no floppy was ever > inserted this boot. > > RKM:Hardware reports the exact inverse values, so I guess disk.resource > inverts the values before returning them... dunno why... See above for why... > So: > > 3.5" DD = ~00000000 = FFFFFFFF > 3.5" HD = ~AAAAAAAA = 55555555 > 5.25" = ~55555555 = AAAAAAAA (listed as reserved in RKM:Hardware) > None = ~FFFFFFFF = 00000000 ( " " " " " ) > > Just clone the 3.5" DD entry in the id table, change the number of > tracks to 40, set the id to $AAAAAAAA and change the name. Voila! 5.25" > support! That's my theory, anyway... :-) Could maybe work.... Tried to make everywhere use the table values. I think the last place was in the ioctl stuff for labels. It is easy to fix. > Also, I'd have to look at the fd.c source again, but I don't think it > does HD mode correctly right now. It needs to re-read the ID whenever > the disk changes (which isn't detected, so I guess it has to be done on > every track read or write? ewww... Actually, maybe it only needs to be > checked on open. Hmm... yeah I think that would work.) Applogies if the > driver already does that. The code reads the id whenever the device is opened so it should work. HD use crashes the system though and I never did figure out why! As for disk changes - I didn't ever get around to trying to capture them. It is left as an exercise to the user! > -- > Ty Sarna "As you know, Joel, children have always looked > tsarna@endicor.com up to cowboys as role models. And vice versa." > +----------------------------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 Apr 12 01:44:07 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Floppy driver (was: Re: This week's NetBSD/amiga changes) To: rhialto@mbfys.kun.nl (Olaf Seibert) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1394 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > There is one defined, I'm sure. Except that the drive id actually > means '40 tracks' instead of '135 mm'. The id that says '90 mm' > actually means '80 tracks'. Not all external drives seem to get this > entirely right, though. One gotcha is that drives that can switch > between 40 and 80 track modes only can be switched before a (re)boot > of AmigaOS; at least on older versions of AmigaOS. (Newer versions > with high-density support query the type on each disk change, and > judging from the drive activity light more often as well) > > To find the 40-track id, look in the Amiga include files; I'm pretty > sure it sits next to the 80-track id. The ids are: 00000000 = no drive 55555555 = 5 1/4 AAAAAAAA = 3 1/2 (HD) FFFFFFFF = 3 1/2 I think this on page 335 of the latest Hardware RKM (this is all from memory - may be way off!) > -Olaf. > -- > ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl +----------------------------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@sun-lamp.cs.berkeley.edu Tue Apr 12 01:44:49 1994 From: Olaf Seibert To: chopps@emunix.emich.edu, rhealey@aggregate.com Subject: Re: Status of new binaries Cc: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de, sjr@zombie.ncsc.mil Sender: owner-amiga@sun-lamp.cs.berkeley.edu chopps@emunix.emich.edu (Chris Hopps) wrote: > sup and ftp mirrors exist. try ftp.iastate.edu in (US) ftp.iastate.edu does not seem to have a sup server - at least not on port 871. I'd love to reduce load on sun-lamp but so far it has been the only sup server that I've seen working. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 01:45:02 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Re: Latest kernel To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1987 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > At the risk of sounding snotty, the floppy driver wasn't done > strictly by the formal book. Technically the driver should have > two parts, one the floppy controller (PROD_BUILTIN_FLOPPY) and > two the per drive code (PROD_BUILTIN_FLOP). The > distinction is subtle... Look at the way a SCSI disk or tape > is actually configured and you'll see what I'm taking about. Yes you are certainly right. When I first started writing the driver I had no idea how NetBSD did such things. I could probably change it now that I understand NetBSD internals better but I have no time! > After much fiddling I still can't get the driver to actually work > and after comparing the NetBSD and AMIX floppy driver source I get the > feeling the NetBSD floppy driver is a first cut and not the polished > end product. It is not polished. I was waiting to polish it off but never had a chance. I decided to make it available anyways in the hopes that others could clean it up. It did work fine on my system with an old kernel so it shouldn't take to long to get it working in the current kernel. My thanks to Chris for doing this for me! > It's a GREAT first cut! At least someone gave us a base from which > to start! THANKS! Whomever you are. With that said, it still doesn't > support HD floppy drives or MSDOS format drives. It also isn't in > the normal controller/slave model of the NetBSD kernel. Plenty of > things for some of us to contribute our efforts to! Thanks! I hope it starts working for everyone soon! > -Rob > +----------------------------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 Apr 12 01:59:08 1994 From: rhealey@aggregate.com Subject: ddb problems 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: 275 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Has anybody else had the problem with ddb where when you trigger it with L-Amiga-Alt-F10 and then continue, the keyboard no longer works and generates random dribble for keys pressed? VERY frustrating... This is with the last sup before 64 off_t stuff went in. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 03:55:37 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 <9404112221.AA01292@sun> pepersb@cuug.ab.ca (Brad Pepers) writes: > The ids are: > 00000000 = no drive > 55555555 = 5 1/4 > AAAAAAAA = 3 1/2 (HD) > FFFFFFFF = 3 1/2 > > I think this on page 335 of the latest Hardware RKM (this is all from > memory - may be way off!) The numbers look correct, though in no place that I could find in the Hardware RKM does it list every ID all together. Also, it keeps referring to 3.25" drives in the Hardware RKM :-) The RKM:Devices is somewhat better, but the docs on floppy IDs are pretty poor and disorganized :-( -- 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 Apr 12 06:20:16 1994 From: Arthur Hoffmann Subject: Re: ddb problems To: rhealey@aggregate.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: 551 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > Has anybody else had the problem with ddb where when you trigger > it with L-Amiga-Alt-F10 and then continue, the keyboard no > longer works and generates random dribble for keys pressed? VERY > frustrating... This is with the last sup before 64 off_t stuff > went in. > > -Rob > Yes, I encountered the same behaviour, the way around it is to press L-Amiga-Alt-F1 (I think) This will restore your keyboard. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 06:49:31 1994 Subject: Loadbsd V2 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 The latest kernel requires version 2 of loadbsd. Is this correct? I tried compiling the code in /aya/arch/amiga/stand/loadbsd, but GCC gurued my system on the ADOS side! I think this is the first time I've used GCC since I've upgraded to V40 kickstart. Has anybody else had a problem with this? Is there a V2 _binary_ that I could snarf? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 12 07:04:52 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: niklas@appli.se (Niklas Hallqvist) Cc: rhealy@aggregate.com, chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Adosfs sad news <9404101408.AA01342@della.appli.se> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu > You CAN have it in the tree, just put it in the gnu subdir. It is no > more a kernel-resident module so it doesn't have to be in sys. it is kernel code; any claim that it's not is silly. It's a VFS. that's kernel code. putting a VFS anyplace other than sys would be silly. we've held the policy of "no GPL'd kernel code" forever. Not only that, we've kept an ABSOLUTE MINIMUM of GPL'd code in the tree -- the only exceptions are where: (1) the GPL'd code was shipped with net/2, is considered "traditionally available in BSD systems", is necessary to build the system. (FYI: 'chess' is one of the former, 'uucp', 'diff', and 'rcs' are examples of the second, and compiler tools bc, etc. are examples of the latter.) (2) it's necessary for the 'suggested' installation procedure (e.g. gzip) > As there are support for LKM VFSs in *your* tree, would it be possible > to register some MOUNT_ values, vnode and malloc tags for anonymous > LKMs in general? you don't necessarily need per-fs malloc tags -- all of the fs's used M_TEMP until i broke them out... However, re: MOUNT_XXX for vfs's: The problem is that the mount program demands a constant at compile-time, etc. I think it's *wrong* to have a mount_foo program that *doesn't*; i.e. mount programs shouldn't have to worry about the LKM "temporary slot" case, and no mount program that does will go inthe tree. (i.e. for a mount program to go in the tree, it must have a 'real' MOUNT_ constant...) In general, a better way to do it *is* appropriate. I'm not yet sure what that 'better way' is, but i *don't* think it's a few MOUNT_LKM entries... (That also introduces the problem of what to do with fs's that already have assigned numbers, etc...) Finally, there is the fact that you're asking me to make significant changes to support GPL'd code, which i personally am completely disinclined to do. The author of the ADOSFS didn't care about our needs, and it's not my job to cater to his whim. chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 07:43:50 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Binary releases and 64 bit off_t Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9404051105.AA00398@icecube.cryogenic.com> billc@iceCuBE.cryogenic.com writes: > not (He's waffling!). What I do care about is that there isn't a -stable, a > solid working base that gets the problems that we are having fixed, before > something major is added (incidently I was bitten by the syserrorlist being > changed, compiling IRC.. thought it was pretty strange). Basically, we don't > have something that we can say "Yep, burn this puppy on CDROM, and ship it." Well, the trouble is that the Amiga port wasn't stable when 0.9 happened, so now we have to wait until 1.0 for an official stable release. Also note that *nobody* is going to be distributing NetBSD or any other Net/2 derived system until the USL-tainted stuff gets replaced with 4.4-Lite. (this IS an issue, too. Don't believe for a second that USL will be understanding about this... They are actively contacting various Net/2 distributers right now and demanding that they cease and desist... I know Walnut Creek was contacted about their FreeBSD CDROM, as was some company selling a disc with NetBSD 0/9/i386 on it). We're actually lucky they haven't (yet?) bitched about the *BSD -currents being availible. See comp.unix.bsd for detail... basicly all the *BSDs are on thin ice until they can replace the USL code with 4.4-Lite's stuff. > or "Hey Fred, here's 10 disks for a special NetBSD-Amiga distribution for > ya!", and this is a stage that I really really want to see happen. Couldn't happen now even if it was stable, thanks to USL. I'm sure Fred doesn't have deep enough pockets to want to risk attracting attention from USL's lawyers. (and I think 10 disks is underestimating the size of even a minimal distribution ;->) > I respectfully disagree, and I've stated why, but let's not beat a dead FPU. No, again, I support supporting no-FPU users (shoot, it's in my interests to). I just don't think it's the #1 priority right now... of course, anybody is free to work on whatever they want. > I'll toss in the idea of thinking about the # of 2000s, 500s and 1200s out > there, to the 3000s and 4000s. Again, I'm advocating the low-midend Amiga > user here, the one with the 100-300M drive, on the souped up Amiga 500 with Hey, I'm 50% a low-midend user too :-) One of the two systems I run NetBSD on is a 2500/20, which AFAIK is the slowest Amiga that can run NetBSD (it does have an FPU, though). Besides, I don't even have one of them thar super-fast 40MHz '040 systems like you do ;-) -- 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-x@sun-lamp.cs.berkeley.edu Tue Apr 12 09:38:03 1994 From: Mike Lorant Subject: /dev/view00 and /dev/view01 To: amiga-x@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu NetBSD Gurus, Im attempting to set up colour for xwindows and am having a bit of a problem. I have found out that the reason it isnt working is because of not having the devices /dev/view00 and /dev/view01. I was told that someone on the mailing list might be able to help. Well if you can, what do i do :) Thanks... Michael Lorant +----------------+==========================+-----------------------+-----+ |*Michael Lorant | X-Comm Development Team | Nick : Dense | Ren \ | Edward Lawford | mikel@extro.ucc.su.OZ.AU | Channel : Amiga | and \ | William Waring | "XPect the Best" | : Aussies | Stimpy \ +----------------+==========================+-----------------------+---------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 09:50:25 1994 From: niklas@appli.se (Niklas Hallqvist) To: rhialto@mbfys.kun.nl Cc: chopps@emunix.emich.edu, rhealey@aggregate.com, amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de, sjr@zombie.ncsc.mil Subject: Re: Status of new binaries Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Olaf" == Olaf Seibert writes: Olaf> chopps@emunix.emich.edu (Chris Hopps) wrote: >> sup and ftp mirrors exist. try ftp.iastate.edu in (US) Olaf> ftp.iastate.edu does not seem to have a sup server - at least Olaf> not on port 871. I'd love to reduce load on sun-lamp but so far Olaf> it has been the only sup server that I've seen working. Try arcturus.cs.chalmers.se, it ought be working. I haven't switched over to it yet so I don't know for sure. Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 12 10:36:54 1994 From: niklas@appli.se (Niklas Hallqvist) To: rhialto@mbfys.kun.nl Cc: chopps@emunix.emich.edu, rhealey@aggregate.com, amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de, sjr@zombie.ncsc.mil Subject: Re: Status of new binaries Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "Olaf" == Olaf Seibert writes: Olaf> chopps@emunix.emich.edu (Chris Hopps) wrote: >> sup and ftp mirrors exist. try ftp.iastate.edu in (US) Olaf> ftp.iastate.edu does not seem to have a sup server - at least Olaf> not on port 871. I'd love to reduce load on sun-lamp but so far Olaf> it has been the only sup server that I've seen working. Try arcturus.cs.chalmers.se, it ought be working. I haven't switched over to it yet so I don't know for sure. Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 13:15:43 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Latest kernel" (Apr 11, 4:49pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: drahn@pacific.urbana.mcd.mot.com (Dale Rahn), markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: Latest kernel Cc: chopps@emunix.emich.edu, dej@eecg.toronto.edu, amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 4:49pm, Dale Rahn wrote: > > Let's see what i can do, isn't it possible to cross-compile stuff and > > even link on other machines? Or do i miss something? > > > Like what host??? Sparc/Alpha/whatever - where i have place :-) I thought it was sufficient to add the -mc68020 flag to gcc/gas, but maybe i am too, hm, (heck, my english) impulsiv... -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 13:23:04 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Latest kernel" (Apr 11, 12:14pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Latest kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 12:14pm, Michael L. Hitch wrote: > > device fd0 at manufacturer 1 product 10 I tried this yesterday and remarked that it looks i don't have all the required code in ../arch/amiga/dev although my sources from NetBSD-current are from April 8. Are all changes incorporated ? What am i missgin? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 12 13:23:24 1994 From: niklas@appli.se (Niklas Hallqvist) To: cgd@postgres.Berkeley.EDU Cc: rhealy@aggregate.com, chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Adosfs sad news Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "Chris" == Chris G Demetriou writes: >> As there are support for LKM VFSs in *your* tree, would it be >> possible to register some MOUNT_ values, vnode and malloc tags for >> anonymous LKMs in general? Chris> you don't necessarily need per-fs malloc tags -- all of the Chris> fs's used M_TEMP until i broke them out... OK, this is fine, I'll go this way. Chris> However, re: MOUNT_XXX for vfs's: The problem is that the mount Chris> program demands a constant at compile-time, etc. I think it's Chris> *wrong* to have a mount_foo program that *doesn't*; i.e. mount Chris> programs shouldn't have to worry about the LKM "temporary slot" Chris> case, and no mount program that does will go inthe tree. Chris> (i.e. for a mount program to go in the tree, it must have a Chris> 'real' MOUNT_ constant...) Not every LKM VFS, or even most of them, should be required to be part of the tree IMO. In order to encourage LKM usage a method to provide table slots for such (private) VFSs ought to be provided. Would you, Chris, seriously vote against such support, if well designed? If so, I'll rest my case, and also suggest LKM VFS be taken out of the kernel as it's kind of useless, only letting a few VFSs almost always statically linked anyway, be loaded. Cleanliness rules, no? Chris> In general, a better way to do it *is* appropriate. I'm not Chris> yet sure what that 'better way' is, but i *don't* think it's a Chris> few MOUNT_LKM entries... (That also introduces the problem of Chris> what to do with fs's that already have assigned numbers, Chris> etc...) When I wrote my proposal, I thought about suggesting some type of registration service, but I didn't as I did not have the time to think it through. I agree with you that another way is appropriate. The same holds for entries in then [bc]devsw structures. Chris> Finally, there is the fact that you're asking me to make Chris> significant changes to support GPL'd code, which i personally Chris> am completely disinclined to do. The author of the ADOSFS Chris> didn't care about our needs, and it's not my job to cater to Chris> his whim. This is partly true, but I find it strange that you don't want to solve a *real* problem, just beacuse the first code to hit it were GPL'd. In spite of this, I'd like to say that I respect your views, even though I disagree with them. I will not struggle to turn this into a religous issue, but rather try to reach a clean and maintable solution. The question at hand is: If someone came up with a general, well designed (in your opinion, that is) solution, would you accept it, *although* no existing VFS used it? If not, there's a hen and egg problem. Hmm, for now I'll probably use some MOUNT_ value not used in the GENERIC config of the amiga tree in order to enable binary users to use the package anyhow. I guess MOUNT_MSDOS would be OK. Yeah, this is cheating, I know... Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 13:29:54 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Loadbsd V2" (Apr 11, 11:58pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: David Jones , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Loadbsd V2 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 11:58pm, David Jones wrote: > Subject: Loadbsd V2 > The latest kernel requires version 2 of loadbsd. Is this correct? Yes! > problem with this? Is there a V2 _binary_ that I could snarf? Uh, yes, something like loadbsd-1994-0x-04.gz :-) -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 12 13:51:45 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Retina X servers" (Apr 11, 12:58pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Dave R. Madsen" , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Retina X servers Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 11, 12:58pm, "Dave R. Madsen" wrote: > Subject: Retina X servers > > I purchased a Retina (the original Zorro II version) last week and > while the Retina console works great, I have been having trouble > finding an X server that will work with it. Although i am the maintainer of the NetBSD-Amiga X-FAQ i cannot help you, because i don't onw a Retina and can't check it. Anybody willing to help me and write a simple guide 'how to start X on Retina?' ? -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 12 14:18:03 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "/dev/view00 and /dev/view01" (Apr 12, 4:04pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Mike Lorant , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: /dev/view00 and /dev/view01 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 12, 4:04pm, Mike Lorant wrote: > Im attempting to set up colour for xwindows and am having a bit > of a problem. I have found out that the reason it isnt working is because > of not having the devices /dev/view00 and /dev/view01. I was told that > someone on the mailing list might be able to help. Well if you can, what > do i do :) Thanks... What for am i writing FAQs? ftp.eunet.ch /pub/NetBSD-Amiga/DOCS/* -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 14:37:28 1994 From: Olaf Seibert To: hoffmann@it.ntu.edu.au, rhealey@aggregate.com Subject: Re: ddb problems Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Arthur Hoffmann > > > Has anybody else had the problem with ddb where when you trigger > > it with L-Amiga-Alt-F10 and then continue, the keyboard no > > longer works and generates random dribble for keys pressed? VERY > > frustrating... This is with the last sup before 64 off_t stuff > > went in. > > > > -Rob > > > Yes, I encountered the same behaviour, the way around it is to press > L-Amiga-Alt-F1 (I think) This will restore your keyboard. I guessed that the problem is that the keyboard code still thinks you keep L-Amiga and L-Alt pressed. Pressing and releasing each once should be sufficient. Now for my problem: if I load the kernel with symbols (loadbsd -S) and I request a stack backtrace when I enter ddb with the keyboad combination, I get a mmu error (sorry that I don't have the details handy) when I think it is about to print the call of _main(). So I trap into ddb recursively, and if I issue the same command again (trace) it works ok. It also works if I had loaded no symbols in the first place (but obviously I don't get the function names). The last time I tried this was relatively short after the keyboard entry into ddb was introduced; I usually don't intentionally crash my system... -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 14:39:56 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Binary releases and 64 bit off_t" (Apr 12, 4:42am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tsarna@endicor.com (Ty Sarna), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Binary releases and 64 bit off_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 12, 4:42am, Ty Sarna wrote: > Also note that *nobody* is going to be distributing NetBSD or any other > Net/2 derived system until the USL-tainted stuff gets replaced with > 4.4-Lite. (this IS an issue, too. Don't believe for a second that USL > will be understanding about this... They are actively contacting various > Net/2 distributers right now and demanding that they cease and desist... > I know Walnut Creek was contacted about their FreeBSD CDROM, as was some > company selling a disc with NetBSD 0/9/i386 on it). We're actually lucky > they haven't (yet?) bitched about the *BSD -currents being availible. > See comp.unix.bsd for detail... basicly all the *BSDs are on thin ice > until they can replace the USL code with 4.4-Lite's stuff. That is an important matter, thanks for bringing this up again. There are some stoneheads in Germany not accepting the fact that NetBSD makes only sense if you have FTP-access (or a friend with access...) and can chance/update regulary, and that it currently doesn't make sense to distribute NetBSD on a CD-ROM (however this is done - archived or unarchived...). The law-issue is one of the things i haven't thought off yet :-). > > or "Hey Fred, here's 10 disks for a special NetBSD-Amiga distribution for > > ya!", and this is a stage that I really really want to see happen. > > Couldn't happen now even if it was stable, thanks to USL. I'm sure Fred > doesn't have deep enough pockets to want to risk attracting attention > from USL's lawyers. (and I think 10 disks is underestimating the size of > even a minimal distribution ;->) Fred is very interested into distributing NetBSD-Amiga on one of his CD-ROMs - and he is aware of the law-suit problem and the libcrypt things. [...] > Hey, I'm 50% a low-midend user too :-) One of the two systems I run > NetBSD on is a 2500/20, which AFAIK is the slowest Amiga that can run > NetBSD (it does have an FPU, though). Besides, I don't even have one of > them thar super-fast 40MHz '040 systems like you do ;-) The low-end NetBSD-Amiga i know of is an A500 with 020-PACK68 enhancement, SCSI-Adaptor, and 4MB RAM. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 15:23:28 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Latest kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu osymh@gemini.oscs.montana.edu (Michael L. Hitch) wrote: > I've been playing with the driver a bit, and have gotten it to read > fine, but I've had problems when writing to the floppy. I've even built > a very minimal boot floppy and booted NetBSD a couple of times using the > floppy as the root file system. I had to modify the delay() routine > since a 33Mhz 68040 runs a bit faster than the 68030 systems. Aha. That may be why I get so many MFM_TRACK messages (indicating that it read the wrong track). Also, so far I haven't succeeded in mounting a floppy (using friday's sources); I get something like GCIOCTL: wrong argument from fsck, while newfs complains about cg0. But tarring to the disk is reasonably successful (until I get the MFM_TRACK messages). -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 19:48:17 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: Loadbsd V2 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 11:58pm, David Jones wrote: > The latest kernel requires version 2 of loadbsd. Is this correct? Yes it is. The kernel has support for the kernel symbols for the kernel debugger, and it needs yet another item passed from loadbsd. > I tried compiling the code in /aya/arch/amiga/stand/loadbsd, but GCC > gurued my system on the ADOS side! I think this is the first time I've > used GCC since I've upgraded to V40 kickstart. Has anybody else had a > problem with this? Is there a V2 _binary_ that I could snarf? I'd love to upgrate to V40 kickstart, but I don't think it's been relased yet, so I'm stuck with what I've got. I think bin/loadbsd-940320.gz on ftp.eunet.ch is version 2.0 of loadbsd. I've got a version 2.2 that has a few other changes, but I haven't sent the changes to Chris Hopps yet. 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 Apr 12 19:51: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: Latest kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 12, 1:19pm, Olaf Seibert wrote: > osymh@gemini.oscs.montana.edu (Michael L. Hitch) wrote: > > I've been playing with the driver a bit, and have gotten it to read > > fine, but I've had problems when writing to the floppy. I've even built > > a very minimal boot floppy and booted NetBSD a couple of times using the > > floppy as the root file system. I had to modify the delay() routine > > since a 33Mhz 68040 runs a bit faster than the 68030 systems. > > Aha. That may be why I get so many MFM_TRACK messages (indicating that > it read the wrong track). Also, so far I haven't succeeded in mounting > a floppy (using friday's sources); I get something like GCIOCTL: wrong > argument from fsck, while newfs complains about cg0. But tarring to the > disk is reasonably successful (until I get the MFM_TRACK messages). I was getting lots of MFM_TRACK messages that I was finally able to get rid of by increasing the delay times. I'm using something like DELAY (delay_ms * 40000); in the delay(delay_ms) routine at the moment. That seems to let me do random seeks when doing newfs and other operations. However, I now get MFM_DATA messages after doing some writes. I also noticed that the retries() routine can be called with no active block buffer, so the references to bp->xxx can panic the system. I put a check in retries() and fdstate() for a NULL bp value. I think I've only seen in from the retries() routine so far. It seems to occur when I get timeouts on a write. 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 Apr 12 19:52:54 1994 From: rhealey@aggregate.com Subject: Kernel name change to netbsd 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: 685 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu We seem to be the only port that still uses the vmunix moniker as opposed to /netbsd. Once you remove the bogus /sbin/kvm_mkdb and install a recent kvm_mkdb in /usr/sbin/kvm_mkdb, where it actually belongs, you should be able to rename the kernel to /netbsd without any problems. Note: This is for -current only! The 6xx and 7xx setups probably still have gobs of /vmunix dependancys in them. I figure with USL still on the warpath and going after the free UNIXi based on Net/2 no use having the u word anyplace obvious. Apparently USL is harassing the CD-ROM distributors in to halting sales of free UNIXi distributions until they are 100% 4.4lite based. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 12 19:57:17 1994 From: rhealey@aggregate.com Subject: ddb keyboard problems, workaround 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: 609 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu After much experimentation last night I discovered the keyboard spewing garbage after doing a continue from ddb was apparently due to a stuck state in the keyboard driver involving the left Amiga-Alt combo. But holding down the same combination it appeared to bring the keyboard back to reality. The keyboard hackers might want to take a look at this to see if the ddb code doesn't clear some keyboard state like it's supposed to. A symbolic kernel debugger is your friend!!! Every kiddie should have one! Nice how the key sequences are similar to gdb! Only oinks 80k for the symbols too. -Rob From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 12 21:30:17 1994 X-Mailer: AVM - V1.3.2 From: rudy@dorn.ping.de (Rudolf Neuhaus) To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: XRetinaZ2 problems. Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Hi! > Help! These trapsignals make it really hard to use, and the display problem > is giving me a headache ;-). Tell me what I'm doing wrong. I found it to be very unstable also, when using 1152x900. With 1024x768 I have no problems. 1152x900 was "tuned" (100MHz) so I thought, that might be the reason, but thats probably not it. BTW, the Xdefaults file coming with the server is supposed to be 800x600 - it is not. Its 1024x768. This might not be nice for some monitors... Rudy ---- Rudolf Neuhaus home: ->rudy@dorn.ping.de 44137 Dortmund (FRG) work: rudy@iml.fhg.de Tel. +49(0) 231/134404 uni : uphd02@zx1.hrz.uni-dortmund.de --- PGP Public key available on request - or finger rudy@lilly.ping.de From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 12 21:40:28 1994 X-Mailer: AVM - V1.3.2 From: rudy@dorn.ping.de (Rudolf Neuhaus) To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: XRetinaZ2 problems. Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu The following mail has been forwarded to you by rudy: > Are you using DefineMonitor on the Amiga side to generate the data for > Xconfig (or whatever the file is)? Do you use the Test Image button > to verify that your monitor can handle the display? Beyond that, I don't > know... the sources were supposed to be available... Make sure to generate an 8 bit mode... Rudy ---- Rudolf Neuhaus home: ->rudy@dorn.ping.de 44137 Dortmund (FRG) work: rudy@iml.fhg.de Tel. +49(0) 231/134404 uni : uphd02@zx1.hrz.uni-dortmund.de --- PGP Public key available on request - or finger rudy@lilly.ping.de From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 13 00:45:22 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: ddb keyboard problems, workaround To: rhealey@aggregate.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > After much experimentation last night I discovered the keyboard > spewing garbage after doing a continue from ddb was apparently > due to a stuck state in the keyboard driver involving the left > Amiga-Alt combo. But holding down the same combination it appeared > to bring the keyboard back to reality. The keyboard hackers might > want to take a look at this to see if the ddb code doesn't clear > some keyboard state like it's supposed to. This happens all the time under NetBSD when my gvp drive is being accessed (ie. most noticeable in heavy swapping). The keys that stick the most (90% of the time) are the shift keys and control. Normal keys rarely ever stick but when they do they're more of a hassle to find (I end up typing all the keys until things turn back to normal). > -Rob From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Apr 13 01:47:35 1994 From: Hubert Feyrer To: amiga-x@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de Subject: Re: /dev/view00 and /dev/view01 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > Im attempting to set up colour for xwindows and am having a bit > > of a problem. I have found out that the reason it isnt working is because > > of not having the devices /dev/view00 and /dev/view01. I was told that > > someone on the mailing list might be able to help. Well if you can, what > > do i do :) Thanks... > > What for am i writing FAQs? ^^^ To not let Markus all the honour at his own, I've added a MAJOR-MINOR-FAQ that tells how to create those devices. The next one to ask this question will be chopped off his head! I mean it! ;) Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 13 01:52:02 1994 From: Hubert Feyrer Subject: MAJOR-MINOR-FAQ (was: Re: /dev/view00 and /dev/view01) To: mikel@extro.ucc.su.OZ.AU (Mike Lorant) 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: 713 Sender: owner-amiga@sun-lamp.cs.berkeley.edu As people keep on asking how to create various devices (/dev/view* and /dev/grf1), I've hacked together a little FAQ on this: MAJOR-MINOR-FAQ (The "/dev/view"-blues) Look out for /pub/NetBSD-Amiga/DOCS/major-minor-FAQ on ftp.uni-regensburg.de! Read it! Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 13 04:45:21 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga.dev Subject: Re: Status of new binaries Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 31 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9404102305.AA11226@emunix.emich.edu>, Chris Hopps writes: > > Ummm, how about the fact that Sun Lamp is very rarely, if ever, > > reachable via FTP; as a practical matter... sun-lamp is HEAVILY > > used and has very low limits on ftp and other services. While > > it's nice to have stuff on sun-lamp, it will be almost impossible > > for anybody to actually retrieve binaries via ftp from sun-lamp. At > > least ftp.eunet.ch isn't ALWAYS busy... Even the mirrors might > > have a touch time getting in. > > Umm, the mirrors that exist now get through fine. I prefer ftp'ing to > US sites as well should other US residents.. I get 90k/s to US sites > 5k/s to eunet. As I stated before sun-lamp gets mirrored all over the > world eunet does not get mirrored to the states. > > No-one should be trying to ftp to sun-lamp. > > sup and ftp mirrors exist. try ftp.iastate.edu in (US) Well, at least for me here in germany ftp.iastate.edu is as slow as sun-lamp... are there any other mirrors on this side on the atlantic? What about uni-erlangen.de, I think it's actually a mirror of ftp.eunet.ch, will it mirror sun-lamp in the future? cu, Lutz Vieweg -- "Ich habe nichts zu sagen. Mir faellt auch nichts mehr ein. Denn alles was sie fragen, zerstoert mein nacktes Sein." ('Schliessmuskel' / "Metamorphose") From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 13 05:33:15 1994 To: amiga@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga Subject: Re: ncftp-1.7.2 uploaded Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 20 Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404101759.AA19003@rrzc1.rz.uni-regensburg.de>, Hubert Feyrer writes: > I've just uploaded ncftp-1.7.2.tar.gz into /pub/NetBSD-Amiga/incoming > on ftp.eunet.ch and ftp.uni-regensburg.de: > -rwxr-xr-x hubert/wheel 155648 Apr 10 18:47 1994 ncftp uhm, well, my ncftp-executable is just 80kB, including the readline-extension, because I linked it with shared libraries... If there's interest, I may upload this version, too... cu, Lutz Vieweg -- "Breite Hueften, schwerer Gang - so stolpern sie die Strasse lang. Fleischig Hintern, Pustelpo, Frauenblaeh im Damenklo. Jesuslatschen, Birkenstock, darueber einen Trachtenrock. Frotteeslip mit Bremsbelag, luenkern bringt es an den Tag." ('Schliessmuskel' / "Hamminkelner Maedels") From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 13 07:10:05 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: niklas@appli.se (Niklas Hallqvist) Cc: cgd@postgres.Berkeley.EDU, rhealy@aggregate.com, chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Adosfs sad news <9404120811.AA19378@della.appli.se> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Not every LKM VFS, or even most of them, should be required to be part of > the tree IMO. perhaps true. (but if they aren't, i shouldn't have to add constants for them... 8-) > In order to encourage LKM usage a method to provide table > slots for such (private) VFSs ought to be provided. Actually, some would say that the entire table as it's currently done is broken... > Would you, Chris, > seriously vote against such support, if well designed? Did you actually bother reading my mail? i said that it *should* be done, but i'd not yet gotten around to doing it, and i didn't have time to do it. That implies that if somebody else does it, it'll probably be accepted. > If so, I'll rest > my case, and also suggest LKM VFS be taken out of the kernel as it's kind > of useless, only letting a few VFSs almost always statically linked anyway, > be loaded. That doesn't imply that it's useless -- being able to load things rather than compiling them in, can save much memory, etc. > This is partly true, but I find it strange that you don't want to solve > a *real* problem, just beacuse the first code to hit it were GPL'd. No, i don't have *TIME* to solve the real problem. If i had time to do everything i wanted to do, i'd have done a hell of a lot more done than i do now. I don't see you offering to may me to work the 8-12 hours a day on this stuff that i do now. (yes, you're damned right that i'm annoyed -- i've better things to do than deal with this shit.) Frankly, it's *NOT* a problem for me. I've never had a problem with it, and i *won't* have a problem with it, because if i want to use the code that badly, i'll WRITE THE DAMNED THING MYSELF. > If someone came up with a general, well designed (in your opinion, that is) > solution, would you accept it, *although* no existing VFS used it? If > not, there's a hen and egg problem. I'm thinking about the problem. I've actually got an idea, that i might implement tonight, even... chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 13 11:24:37 1994 Subject: From: grau@theben.mch.sni.de To: amiga-dev@sun-lamp.cs.berkeley.edu Content-Type: text Content-Length: 1487 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, [...] > > sup and ftp mirrors exist. try ftp.iastate.edu in (US) > > Well, at least for me here in germany ftp.iastate.edu is as slow as > sun-lamp... are there any other mirrors on this side on the atlantic? I think so. I created a list of mirrors of eunet, as well as a list of mirrors of sun-lamp. Get the file 'getting-NetBSD' form the DOCS directory. Please get any information about changes/mistakes back to the maintainer of this list (me :-). Here is an excerpt: Germany: cranach.rz.tu-ilmenau.de /pub/unix/NetBSD/NetBSD-current ftp.cs.uni-bonn.de /unix/NetBSD/NetBSD-current ftp.cs.uni-sb.de /pub/misc/sunlamp/NetBSD-current ftp.germany.eu.net /pub/comp/i386/NetBSD/NetBSD-current hermes.hrz.uni-bielefeld.de /.mnt1/systems/NetBSD/NetBSD-current ftp.tu-chemnitz.de /pub/NetBSD/NetBSD-current ftp.uni-muenster.de /share/public2/NetBSD/NetBSD-current ftp.uni-stuttgart.de /pub/unix/systems/NetBSD/NetBSD-current ftp.zdv.uni-mainz.de /pub/NetBSD/NetBSD-current ftp.uni-regensburg.de /pub/os/NetBSD/NetBSD-current rs3.hrz.th-darmstadt.de /pub/os/NetBSD/NetBSD-current I don't know if any of these servers offer sup-access. > What about uni-erlangen.de, I think it's actually a mirror of ftp.eunet.ch, > will it mirror sun-lamp in the future? Sorry, I can't answer that question, but it is always a good idea to contact the maintainer of the archives. Most of the times they are very cooperative. Hope that helped. > cu, Lutz Vieweg Guenther From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 13 12:44:50 1994 From: Hubert Feyrer To: amiga-dev@sun-lamp.cs.berkeley.edu, lkv@mania.robin.de Subject: Re: Status of new binaries Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > What about uni-erlangen.de, I think it's actually a mirror of ftp.eunet.ch, > will it mirror sun-lamp in the future? We've a mirror of NetBSD-current here on ftp.uni-regensburg.de (mirrored via FTP from ftp.eunet.ch at the moment, but switching to sup is no problem). If someone tells me how to set it up as a sup-server, I'll going to do so! Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 13 12:52:17 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Status of new binaries" (Apr 11, 7:54pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: lkv@mania.robin.de (Lutz Vieweg), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Status of new binaries Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 11, 7:54pm, Lutz Vieweg wrote: > Well, at least for me here in germany ftp.iastate.edu is as slow as > sun-lamp... are there any other mirrors on this side on the atlantic? The 'official' german NetBSD-mirror is ftp.uni-regensburg.de -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Apr 13 14:12:53 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga.x Subject: Re: Retina X servers Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 40 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu In article <199404111758.KAA01004@sun-lamp.cs.berkeley.edu>, "Dave R. Madsen" writes: > First I tried using the xretina.tar.gz package which is on > ftp.eunet.ch in contrib/bsd/X11, but that server gives me a > segmentation fault immediately after it is executed. I then tried > the new XRetinaZ2 archive that was put into incoming. The Xconfig that > came with this server defined a screen mode that my monitor was unable to > reproduce, so I used DefineMonitor under amigados to create > one that should work. This X server starts up fine, but > the screen is offset majorly down and to the right and flickers > horribly, making it unusable. You are not the first one who reports such a problem, but alas, there has been no statement about this from the french guys who created XRetinaZ2 so far. The old Retina Z2 server always worked for me (even with a monitor creation of my own), but now I don't have a Retina Z2 anymore in my computer, so I cannot try the new ones. I'm now running the new Retina ZIII X-Server, which is in the incoming/experimental directory, and though this is a very first attempt (which can still be optimized in many ways), it runs reliable here. >From what Markus wrote, this X-Server ALSO works on the Retina Z2, Markus actually has both a Z2 and a Z3 in his computer, so he's probably tested this. As I wrote before, I cannot test the new server on the Z2, but you may do so, and I can assure you there are suitable gfx-modes available for your 38.5kHz monitor in it (currently, you need to binpatch the kernel to select the mode!) BTW, I'm using the 19-3 binaries. cu, Lutz Vieweg -- "Erst Mosch ist grad in Bad Salzuflen - und will mit seinem Mopshund knuffeln. Da blitzt es grell am Himmelszelt, ein schriller Schrei, der Kvter bellt." ('Schliessmuskel' / "Der Untergang der abendlaendischen Kultur") From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 13 15:46:16 1994 From: Andreas Heitmann To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Status of new binaries Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi ! >>>>> "Hubert" == Hubert Feyrer writes: >> What about uni-erlangen.de, I think it's actually a mirror of >> ftp.eunet.ch, will it mirror sun-lamp in the future? Hubert> We've a mirror of NetBSD-current here on Hubert> ftp.uni-regensburg.de (mirrored via FTP from ftp.eunet.ch Hubert> at the moment, but switching to sup is no problem). If Hubert> someone tells me how to set it up as a sup-server, I'll Hubert> going to do so! We (Markus Landgraf and I) are currently trying to set up our ftp-server (ftp.hrz.uni-kassel.de) as sup-mirror of sun-lamp. It's not a very fast server (2x64KBit/s), but it's better than nothing. The server will contain the collections ksrc-amiga, ksrc-common and src. If you need other collections, please tell me. When the server is up, I'll give an official announcement in this group. Greetings, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) I have no plants in my house. They won't live for me. Some of them don't even wait to die, they commit suicide. I once came home [and] found one hanging from a macrame noose, the pot kicked out from underneath. --Jerry Seinfeld From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 13 22:26:29 1994 Subject: From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "" (Apr 13, 9:13am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: grau@theben.mch.sni.de, amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 13, 9:13am, grau@theben.mch.sni.de wrote: > > hermes.hrz.uni-bielefeld.de /.mnt1/systems/NetBSD/NetBSD-current Remove this one please, it is obsolete (althought that might change RSN :-) 250-Please read the file README.export-control 250- it was last modified on Mon Aug 23 02:00:00 1993 - 233 days ago The entire tree wasn't updated since then. -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu Apr 14 16:48:05 1994 To: rhealey@aggregate.com Cc: amiga-x@sun-lamp.cs.berkeley.edu, mehlhaff@plague.berkeley.edu Subject: Re: New X bins for "off_t" kernels of Sun, 10 Apr 1994 00:39:05 -0500 <9404100539.AA02311@sirius.aggregate.com> From: "'Evil' ERic Mehlhaff" Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu rhealey@aggregate.com recently wrote: > > Is anybody going to cut new versions of the X binarys for the > new kernels with 64 bit off_t's and 32 bit uid/gid? I'm especially > interested in new versions of the libes, Xmono and xmosaic... I've beeen running a full X distribution, with the Xamiga kernel, on a current kernel(compiled from this weeks' lamp sources no less!). I don't know how whether the rest of my binaries set is post off_t -- I grabbed the 940319 bin-dist from eunet and installed it, and discovered that it broke lots of things. One of which was X -- I happened to have full source, and lots of disk space, so I X recompiled X. (Wasn't too hard, except for the fact that lex just refuese to work for me. I recompiled lex, bootstrapped from initscan.c, compiled flex-2.4.6. Nothing generated a lex that would make code that would compile the X stuff. sure, it worked enough to compile config and/or recompile lex. but elsewhere. I hear this is a known bug, though.) Incidentally, I found the bug that causes XOpenDisplay to Unix sockets open to the wrong socket (/tmp/X11-unix/X instead of X0 like it should) -- our struct sockaddr_un is differently sized than X expects it. Anyway, if, indeed, the 940319 bin-dist is post off_t, then everything should work ok (at least for the Xamiga server, anyway) and I'll go ahead and upload to eunet. probably this weekend. ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu Apr 14 18:52:54 1994 From: phil@gradient.com (Phil Mucci) To: amiga-x@sun-lamp.cs.berkeley.edu Subject: How's the new views coming? Content-Length: 251 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Howdy people.... Hey Ed, how's the new views coming along? We're you able to get a compile running? Also, what's all this talk about 64 bit off_t's. I didn't know that 680x0 gcc supported 64 bit ints. What are they? (long longs?) -Phil From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu Apr 14 20:31:20 1994 From: "Stephen J. Roznowski" To: rhealey@aggregate.com, mehlhaff@ocf.Berkeley.EDU Subject: Re: New X bins for "off_t" kernels Cc: amiga-x@sun-lamp.cs.berkeley.edu, mehlhaff@plague.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > Is anybody going to cut new versions of the X binarys for the > > new kernels with 64 bit off_t's and 32 bit uid/gid? I'm especially > > interested in new versions of the libes, Xmono and xmosaic... > > Anyway, if, indeed, the 940319 bin-dist is post off_t, then everything should > work ok (at least for the Xamiga server, anyway) and I'll go ahead and upload > to eunet. probably this weekend. > > ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU > The 940319 binaries on eunet are 32bit off_t. The set that I'm planning to upload to sun-lamp will be 64bit off_t. -SR From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu Apr 14 22:13:59 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: How's the new views coming? To: Phil Mucci Cc: amiga-x@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Thu, 14 Apr 1994, Phil Mucci wrote: > Hey Ed, how's the new views coming along? We're you able to > get a compile running? The status of the blitter routines is as follows: 1) The line blit is working wonderfully! 2) X-type area blitting cannot be directly handled by the Amiga blitter. Most blits will need to be devided up. The base blit routines are working, however. 3) The original version of my blit code was synchronous. I am in the process of adding async queueing. This code will also split up complex blits into smaller chunks that the CC blitter can handle. 4) I have not even begun to contemplate area fills and off screen pixmaps yet. > Also, what's all this talk about 64 bit off_t's. I didn't > know that 680x0 gcc supported 64 bit ints. What are they? (long longs?) gcc does support 64-bit long longs, and has for a while. This should not be of great concern unless you are trying to switch between 32 and 64 bit off_t's. Since CGD wrote that there will be yet another major change in the very near future, I have put off working on a set of 64-bit X libs and/or X server. I am anxiously awaiting a 64-bit binary distribution (poke poke). Eduardo From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Apr 15 04:23:40 1994 From: mw@eunet.ch Subject: Re: Retina X servers To: lkv@mania.robin.de (Lutz Vieweg) Cc: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1484 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > I'm now running the new Retina ZIII X-Server, which is in the > incoming/experimental directory, and though this is a very first > attempt (which can still be optimized in many ways), it runs > reliable here. > > >From what Markus wrote, this X-Server ALSO works on the Retina Z2, > Markus actually has both a Z2 and a Z3 in his computer, so he's > probably tested this. As I wrote before, I cannot test the new > server on the Z2, but you may do so, and I can assure you there > are suitable gfx-modes available for your 38.5kHz monitor in it > (currently, you need to binpatch the kernel to select the mode!) It DOES work on the Z2 Retina, but you really don't want to use it there (besides, if you run your own kernel, you HAVE to use a config file which has BANKEDPAGER (or similar, sorry, I'm not at home right now...) defined, so the segmented framebuffer appears to the mmap() call as one contiguous block of memory). The big problem of the server running on the Z2 is speed, you really want to use a server that does segment switching without taking a pagefault each time, so go for the french server. Well, if you really want, have a look at the experimental stuff, but I won't be able to help much, as I'm at a friends place here in California, and can't work on NetBSD for a while. Have a good one, -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 Fri Apr 15 07:07:42 1994 From: windiba@server.uwindsor.ca (Windibank Chris) Subject: Floppy drive major/minor To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu After getting the necessary files to add the floppy driver to my kernel I am having difficulty getting things to work. The kernel compiles fine but for some reason it's not reported at boot time. I added the line device fd0 at manufacturer 1 product 10 to my config file and did a mknod rfd0a c 10 0, is that correct ? Chris From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Apr 15 08:19:02 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Subject: XRetinaZ2 problems: Waiting for XServer to accept connections From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Hi, I downloaded the new Xretina server, but it refused to work for me. It keeps saying: Waiting for server to start accepting connections .. .. .. .. .. etc. I'm running the 744 kernel, I know it's old but I didn't have time to recompile a new one using the current sources. Could that be causing my problem with XRetinaZ2 ? John Vrolijk From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 15 20:59:53 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/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: Makefile.inc Log Message: oops, typo. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: grf_cc.c ite_cc.c iteioctl.h view.c viewioctl.h Log Message: little bit of KNiFeing, view and ite ioctl names cleaned. ite bell values made sensical for users. (that is pitch,msec not period,count) --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Modified Files: ansi.h asm.h cpu.h cpufunc.h db_machdep.h endian.h exec.h float.h frame.h limits.h mtpr.h param.h pcb.h pmap.h proc.h psl.h pte.h ptrace.h reg.h signal.h stdarg.h trap.h types.h varargs.h vmparam.h Log Message: protect against multiple inclusion (and be consitent) --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/m68k/include Modified Files: endian.h float.h frame.h limits.h ptrace.h signal.h stdarg.h trap.h types.h varargs.h Log Message: protect against multiple inclusion --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Modified Files: ansi.h asm.h cpu.h cpufunc.h db_machdep.h endian.h exec.h float.h frame.h limits.h mtpr.h param.h pcb.h pmap.h proc.h psl.h pte.h ptrace.h reg.h signal.h stdarg.h trap.h types.h varargs.h vmparam.h Log Message: also conform to standard style --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: autoconf.c machdep.c Log Message: missed a cast. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: st.c Log Message: fix pretend_tobe hack. from Robert Leland (leland@wacky.acet.org) --------------------------------- From: Charles Hannum Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/include Modified Files: float.h Log Message: Someone made a typo. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: AMIGA DDBGENERIC GENERIC Makefile.amiga ZEUS ZEUSONLY Log Message: vmunix? no, we are netbsd. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: AMIGA DDBGENERIC GENERIC GODZILLA ZEUS ZEUSONLY Log Message: add COMPAT_09 --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/vmqueue/sys/arch/amiga/amiga Modified Files: symbols.raw Log Message: convert vm system to use new queues. I'll never write code w/queues again. --------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 16 02:37:47 1994 Subject: floppy? 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 Can someone post the instructions for setting up the floppy, from the config line in the /sys/arch/amiga/conf directory to the values for making the device node? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 16 02:42:14 1994 Subject: Color X From: David Jones To: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu What's the story with X? I thought you couldn't run X on the 64-bit off_t kernels. Yet, Xmono runs quite well. Is there a more recent version of the color servers? I looked around on eunet and couldn't find any. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 16 03:37:50 1994 From: Andreas Johansson Subject: RetinaZ3 experimental X-server To: 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: 780 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Has anyone compiled a kernel with support for the Retina Z3 that would work with an A4000 w/ GVP scsi interface? It seems to me that the kernel compiled by mw did not contain the gvp driver. Or if I am doing something wrong, please tell me what. When I boot there is no recognition of either of my drives, no GVPDMA0 (or what it is called) and no suitable root. I am able to boot with the generic kernel. I get output on the Retina Z3, though. I would like to get NetBSD to work on my Retina Z3 without recompiling the kernel, with custom chips I get a pretty nifty 640x400 on a TV-set! I have not set NetBSD up completely yet. Thanks for any help! -- <-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=> : ajo@ludd.luth.se (Andreas Johansson) : <-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=> From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 16 06:00:43 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: Color X To: dej@eecg.toronto.edu (David Jones) Cc: 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: 259 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > What's the story with X? > > I thought you couldn't run X on the 64-bit off_t kernels. Yet, Xmono runs > quite well. I thought the deal was that old binaries (static and shared-lib) would work with the new kernel so long as you had old libraries... From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 16 23:41:25 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Color X" (Apr 15, 7:38pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: David Jones , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Color X Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 15, 7:38pm, David Jones wrote: > Subject: Color X > What's the story with X? > > I thought you couldn't run X on the 64-bit off_t kernels. Yet, Xmono runs > quite well. I think it was mentioned that non-off_t binaries work still continue to work on a new off_t-kernel. Does this explain something? Anyway, i hope to make a new release of my X binaries frm within next week (when i get my CD-ROM .-) > Is there a more recent version of the color servers? I looked around on > eunet and couldn't find any. No idea. FYI: Apr 15 13:54:21 tiger /netbsd: grf2: 0 x 0 0 color Picasso2 display Apr 15 13:54:21 tiger /netbsd: grf2 [2167/11] Things are becoming exiting :) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 17 00:05:13 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Yellow screen on reboot Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm still getting a yellow screen when I try to reboot my 16Meg A3000. This problem only started to occur when I upgraded from 8M to 16M. I'm running the latest binaries (13 April sources). Is anyone else seeing this problem? Does anyone have a fix? Thanks, -SR From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 00:09:46 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: Floppy drive major/minor Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 15, 12:17am, Windibank Chris wrote: > After getting the necessary files to add the floppy driver to my > kernel I am having difficulty getting things to work. The kernel > compiles fine but for some reason it's not reported at boot time. I > added the line device fd0 at manufacturer 1 product 10 to my config > file and did a mknod rfd0a c 10 0, is that correct ? I think the mknod commands should be: mknod fd0 b 2 0 mknod rfd0 c 18 0 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-x@sun-lamp.cs.berkeley.edu Sun Apr 17 00:10:48 1994 From: niklas@appli.se (Niklas Hallqvist) To: markus@techfak.uni-bielefeld.de Cc: dej@eecg.toronto.edu, amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Color X Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu >>>>> "Markus" == Markus Illenseer writes: Markus> On Apr 15, 7:38pm, David Jones wrote: >> Subject: Color X What's the story with X? >> >> I thought you couldn't run X on the 64-bit off_t kernels. Yet, >> Xmono runs quite well. Markus> I think it was mentioned that non-off_t binaries work still Markus> continue to work on a new off_t-kernel. Does this explain Markus> something? Anyway, i hope to make a new release of my X Markus> binaries frm within next week (when i get my CD-ROM .-) The problem that can occur are if you recompile X clients with old X libraries, but new OS includes/libs. There should be no problem if you arrange to use the old includes/libs when compiling X clients. Markus> Apr 15 13:54:21 tiger /netbsd: grf2: 0 x 0 0 color Picasso2 display Markus> Apr 15 13:54:21 tiger /netbsd: grf2 [2167/11] Are there any plans to extend the resolution & depth :-) Well, realistically, when do you hope to have an alpha version. I may buy a graphics board sometime this year, and have so far only looked at the Retina. If you think this server will be ready soon, I might check the Picasso out as well. Yes, I know, I'm not that fast releasing packages myself, remember ADOSFS? Speaking of which, CGD has made an elegant system handling unknown VFSs, so the ADOSFS LKM will soon be able to run on generic binary kernels (i.e. when COMPAT_09 are dropped from the GENERIC kernel, and I've released a small patch). Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 00:13:50 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: David Jones , amiga@sun-lamp.cs.berkeley.edu Subject: Re: floppy? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 15, 7:33pm, David Jones wrote: > Can someone post the instructions for setting up the floppy, from the config > line in the /sys/arch/amiga/conf directory to the values for making the > device node? How about: device fd0 at manufacturer 1 product 10 mknod fd0 b 2 0 mknod rfd0 c 18 0 (These are what I'm using.) 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-x@sun-lamp.cs.berkeley.edu Sun Apr 17 00:30:29 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Color X" (Apr 16, 1:51pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: niklas@appli.se (Niklas Hallqvist), markus@techfak.uni-bielefeld.de Subject: Re: Color X Cc: dej@eecg.toronto.edu, amiga-x@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 16, 1:51pm, Niklas Hallqvist wrote: > The problem that can occur are if you recompile X clients with old > X libraries, but new OS includes/libs. There should be no problem > if you arrange to use the old includes/libs when compiling X clients. I will have that in mind.. Let's see. > Markus> Apr 15 13:54:21 tiger /netbsd: grf2: 0 x 0 0 color Picasso2 display > Markus> Apr 15 13:54:21 tiger /netbsd: grf2 [2167/11] > > Are there any plans to extend the resolution & depth :-) No, not at all :-) I love that 0x0 display :-) Well, currently init_pi() returns -1 and thus the picasso-board is recognized but fails to initialize - i guess i should start coding init_pi() :-) - and ite switches over to grf0 as console (ECS). > Well, realistically, when do you hope to have an alpha version. I may > buy a graphics board sometime this year, and have so far only looked at > the Retina. If you think this server will be ready soon, I might check Well, i got a cheap Picasso - and there is a very stable X server for Amix available already... Why not combining this? Is there a guide for 'how to write grf-devices' or 'how to write a NetBSd-device' available somewhere (no, i don't intend to buy a book...)? -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 17 00:30:52 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Color X" (Apr 16, 7:21pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Color X Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Markus> Apr 15 13:54:21 tiger /netbsd: grf2: 0 x 0 0 color Picasso2 display > > Markus> Apr 15 13:54:21 tiger /netbsd: grf2 [2167/11] > > > > Are there any plans to extend the resolution & depth :-) reminds me that there is a bug-fix needed in grf.c: ----------- snip ------- snap ------- if (gp->g_display.gd_colors == 2) printf("monochrome"); else printf("%d color", gp->g_display.gd_colors); ----------- snip ------- snap ------- switch(gp->g_display.gd_colors) { case 0: printf("disabled"); break; case 1: printf("hm, monocolor"); break; case 2: printf("monochrome"); break; default: printf("%d color", gp->g_display.gd_colors); } ----------- snip ------- snap ------- Or whatever - who is responsible ? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 04:43:55 1994 From: sbusko@cap.gwu.edu (Steve Busko Jr.) To: amiga@sun-lamp.cs.berkeley.edu Subject: Misc stuff Cc: sbusko@cap.gwu.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu First I just read that Amiga Linux has a way to distinguish between the GVP I/O Extender and the rest of the GVP cards. So, case you devs missed that, I thought it might be useful to see how they did it. Next, for the Retina ZIII owners. How is the card? I'm thinking about getting it as Opal Vision isn't good for X and I just got a 17" monitor that doesn't go down to 15Mhz, so OV isn't used for now anyway. I don't see R ZIII sold in the US yet, but how much is it there (in $ if pos?) Or would it be better to get an orig Retina then upgrade??? I also have a prob w/ the color X server. I have the orig mono server working great w/ kernel 744 and bins. But when I link the cc4 I get that it can't find the display??? I'm sure it doesn't use views (not that I have them avail w/ 744 anyway), and mono still works... Lastly, I just wanted to double verify that the Ameristar A4065? will work in NetBSD-Amiga? As I found a dealer who will have them any day now and I need an ethernet card to do an in-house network. Thanks in advance for any help - Steve -- EOT ** sbusko@cap.gwu.edu --- Steve Busko Jr. (CyberMatrix) ****** **** Cyberpunk, the attitude, get it! | Do what thou wilt is **** ****** Only Amiga makes it possible! | the whole of the law. ** From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 17 05:21:00 1994 From: Arthur Hoffmann Subject: Re: Yellow screen on reboot To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) 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: 610 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > I'm still getting a yellow screen when I try to reboot my 16Meg A3000. > This problem only started to occur when I upgraded from 8M to 16M. > > I'm running the latest binaries (13 April sources). > > Is anyone else seeing this problem? Does anyone have a fix? > > Thanks, > -SR > This is absoluteley normal for a 16M A3000. I noticed the problem when I ran ther very first NetBSD kernel, and it hasnt changed a bit since then. At least CTRL-LAmiga-RAmiga still works :). Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 17 05:42:27 1994 From: "Stephen J. Roznowski" To: hoffmann@it.ntu.edu.au Subject: Re: Yellow screen on reboot Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: Arthur Hoffmann > > > > I'm still getting a yellow screen when I try to reboot my 16Meg A3000. > > This problem only started to occur when I upgraded from 8M to 16M. > > This is absoluteley normal for a 16M A3000. I noticed the problem when > I ran ther very first NetBSD kernel, and it hasnt changed a bit since > then. > At least CTRL-LAmiga-RAmiga still works :). It seems that not everyone has this problem. Any ideas of how to figure out what is causing the problem? (What does a yellow screen mean anyways?) -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 17 05:53:20 1994 Subject: Re: Yellow screen on reboot From: David Jones To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: hoffmann@it.ntu.edu.au, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > It seems that not everyone has this problem. Any ideas of how to figure > out what is causing the problem? (What does a yellow screen mean anyways?) Yellow=CPU exception before AmigaOS has installed default (display Guru) exception handlers. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 17 09:45:58 1994 From: mw@eunet.ch Subject: Re: Yellow screen on reboot To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: sjr@zombie.ncsc.mil, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1106 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I'm still getting a yellow screen when I try to reboot my 16Meg A3000. > > This problem only started to occur when I upgraded from 8M to 16M. > > This is absoluteley normal for a 16M A3000. I noticed the problem when > I ran ther very first NetBSD kernel, and it hasnt changed a bit since > then. > At least CTRL-LAmiga-RAmiga still works :). I *think* the problem lies within the V36 bootrom, thinking that the loaded kickstart image is still present (which it of course is NOT), and jumping into nevereverland thru the wrong reset-vector. The way to find out about this would be to write a (perhaps simplistic, in the first go) loadbsd that runs under V36, and then have BSD load from that old 1.4 kickstart (klick in the left upper corner in the V36 bootmenu, the one that allows selection of either kick 2.0 or 1.3). This is just an idea, but I have some reason to believe into it... (oh, and I have the same problem myself:-)) -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 Sun Apr 17 09:52:29 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Misc stuff Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404170022.AA18413@cap.gwu.edu> sbusko@cap.gwu.edu writes: > > First I just read that Amiga Linux has a way to distinguish between the > GVP I/O Extender and the rest of the GVP cards. So, case you devs missed > that, I thought it might be useful to see how they did it. The code to detect the different cards is in -current now. > Next, for the Retina ZIII owners. How is the card? I'm thinking about Sort of off-topic, but does the Retina Z3 have a monitor passthru and switch capability? I find that feature of the Picasso very attractive... > Lastly, I just wanted to double verify that the Ameristar A4065? will > work in NetBSD-Amiga? As I found a dealer who will have them any day > now and I need an ethernet card to do an in-house network. Double verify? I don't think it's been even single-verified :-). As far as I know, that board (A4066/A2066... they are identical except for name, the 4066 isn't a zorro-3 version) is not hardware compatible with the A2065. I would tend to assume it isn't unless someone has verified otherwise. Of course, if you can find programming information for it you could always write a new driver, or modify the existing driver to work. -- 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 Apr 17 09:52:32 1994 From: mw@eunet.ch Subject: Re: Misc stuff To: sbusko@cap.gwu.edu Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1206 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Next, for the Retina ZIII owners. How is the card? I'm thinking about I like it. I can't really say anything about WB-stuff, as I don't use it (grin:-)) There's quite a bit of potential for future enhancements in the X-server, and the console is already remarkably faster than the RZ2 console due to blitter usage in alphanum-mode. > Or would it be better to get an orig Retina then upgrade??? I don't think this is the way to go, the upgrade is a board swap, not just software, and I don't think you get a better deal by first getting a RZ2 just to later upgrade. Milage may vary of course if you can get a real cheap second hand RZ2. > Lastly, I just wanted to double verify that the Ameristar A4065? will > work in NetBSD-Amiga? As I found a dealer who will have them any day > now and I need an ethernet card to do an in-house network. Unless someone has in the meanwhile written a driver for it, no. There is currently just one driver, which runs on the OLD (!) Ameristar board, which is equivalent to the Commodore 2066. -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 Sun Apr 17 10:38:33 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: MAKEDEV patches Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Following is are patches for MAKEDEV in -current... changes: - correct a harmless type (sdf6 ->sd6) - add an RCS id - make all four floppuy devices. Having two floppies is IMHO certainly common enough to warrant creating the device nodes as standard. Of course, a second internal floppy is either #1 or #2, depending on amiga model, internal/external, etc, so we need to make 0, 1, and 2. Since we're doing that, we might as well go all the way and add 3. - Make a symlink mouse -> mouse0 for cross-arch compatibility. Most other machines have only 1 mouse port and call it's entry /dev/mouse. *** /usr/src/etc/etc.amiga/MAKEDEV Fri Apr 8 05:02:17 1994 --- /dev/MAKEDEV Sat Apr 16 17:07:07 1994 *************** *** 31,37 **** # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # ! # amiga/MAKEDEV (1/15/94), from: # # hp300/MAKEDEV (1/15/94), from: # @(#)MAKEDEV 5.5 (Berkeley) 5/28/91 --- 31,39 ---- # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # ! # $Id$ ! # ! # from: # # hp300/MAKEDEV (1/15/94), from: # @(#)MAKEDEV 5.5 (Berkeley) 5/28/91 *************** *** 80,88 **** case $i in all) sh MAKEDEV std st0 ite0 ite1 mouse0 mouse1 tty0 grf0 grf1 kbd ! sh MAKEDEV sd0 sd1 sd2 sd3 sd4 sd5 sdf6 vnd0 vnd1 vnd2 vnd3 vnd4 sh MAKEDEV view00 view01 view02 view03 view04 view05 pty0 ! sh MAKEDEV vnd5 vnd6 fd0 bpf0 bpf1 bpf2 bpf3 par0 lkm local ;; std) --- 82,91 ---- case $i in all) sh MAKEDEV std st0 ite0 ite1 mouse0 mouse1 tty0 grf0 grf1 kbd ! sh MAKEDEV sd0 sd1 sd2 sd3 sd4 sd5 sd6 vnd0 vnd1 vnd2 vnd3 vnd4 sh MAKEDEV view00 view01 view02 view03 view04 view05 pty0 ! sh MAKEDEV vnd5 vnd6 fd0 fd1 fd2 fd3 bpf0 bpf1 bpf2 bpf3 par0 ! sh MAKEDEV lkm local ;; std) *************** *** 264,269 **** --- 267,276 ---- case $unit in 0|1) mknod mouse${unit} c 15 ${unit}; chmod 666 mouse${unit} + if [ $unit = 0 ] + then + rm -f mouse; ln -s mouse${unit} mouse + fi ;; *) echo bad unit for mouse in: $i From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 17 10:39:37 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Some fd.c patches Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu The following patches do two things. First they add support for the A1020 5.25" drive (tested, and it works.... well, it suffers the same problems as 3.5" drives, but is no worse). Second, it provides partition information that is more correct. It now fills in the rpm value. It is currently incorrect (someone please fix), but at least it prevents the "warning! zero revolutions/minute" message. I also changed the reported pack name from "some pack" to the size/format of the disk... that's at least marginally more useful information. :-) *** fd.c.orig Fri Apr 8 05:12:49 1994 --- fd.c Sat Apr 16 20:56:34 1994 *************** *** 110,117 **** /* drive type values */ #define FD_NONE 0x00000000 ! #define FD_DD_3 0xffffffff /* double-density 3.5" (880K) */ ! #define FD_HD_3 0x55555555 /* high-density 3.5" (1760K) */ struct fd_type { int id; --- 110,118 ---- /* drive type values */ #define FD_NONE 0x00000000 ! #define FD_DD_3 0xFFFFFFFF /* double-density 3.5" (880K) */ ! #define FD_HD_3 0x55555555 /* high-density 3.5" (1760K) */ ! #define FD_DD_5 0xAAAAAAAA /* double-density 5.25" (440K) */ struct fd_type { int id; *************** *** 130,137 **** struct fd_type drive_types[] = { /* id name tr he rdsz wrsz sm pc1 pc2 sd st st */ ! { FD_DD_3, "DD 3.5", 80, 2, 14716, 13630, 1, 80, 161, 3, 18, 1 }, ! { FD_HD_3, "HD 3.5", 80, 2, 29432, 27260, 2, 80, 161, 3, 18, 1 }, { FD_NONE, "No Drive", 0, } }; int num_dr_types = sizeof(drive_types) / sizeof(drive_types[0]); --- 131,139 ---- struct fd_type drive_types[] = { /* id name tr he rdsz wrsz sm pc1 pc2 sd st st */ ! { FD_DD_3, "DD 3.5\"", 80, 2, 14716, 13630, 1, 80, 161, 3, 18, 1 }, ! { FD_HD_3, "HD 3.5\"", 80, 2, 29432, 27260, 2, 80, 161, 3, 18, 1 }, ! { FD_DD_5, "DD 5.25\"",40, 2, 14716, 13630, 1, 80, 161, 3, 18, 1 }, { FD_NONE, "No Drive", 0, } }; int num_dr_types = sizeof(drive_types) / sizeof(drive_types[0]); *************** *** 1130,1141 **** fd_label->d_magic = DISKMAGIC; fd_label->d_type = DTYPE_FLOPPY; strncpy(fd_label->d_typename, "fd", sizeof(fd_label->d_typename) - 1); ! strcpy(fd_label->d_packname, "some pack"); fd_label->d_secsize = 512; ! fd_label->d_nsectors = 11; ! fd_label->d_ntracks = 2; ! fd_label->d_ncylinders = 80; fd_label->d_secpercyl = fd_label->d_nsectors * fd_label->d_ntracks; fd_label->d_secperunit= fd_label->d_ncylinders * fd_label->d_secpercyl; --- 1132,1145 ---- fd_label->d_magic = DISKMAGIC; fd_label->d_type = DTYPE_FLOPPY; strncpy(fd_label->d_typename, "fd", sizeof(fd_label->d_typename) - 1); ! strcpy(fd_label->d_packname, fd->ft->name); + fd_label->d_rpm = 42 / fd->ft->sect_mult; /* XXXX replace 42 with + correct value for a 880K floppy */ fd_label->d_secsize = 512; ! fd_label->d_nsectors = 11 * fd->ft->sect_mult; ! fd_label->d_ntracks = fd->ft->heads; ! fd_label->d_ncylinders = fd->ft->tracks; fd_label->d_secpercyl = fd_label->d_nsectors * fd_label->d_ntracks; fd_label->d_secperunit= fd_label->d_ncylinders * fd_label->d_secpercyl; From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 11:04:32 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: iteconfig broken? Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu Something changed between the old iteconfig and the one in -current as of April 9th, that causes problems on my machine. Running the new iteconfig on a Apr9-current kernel causes whatever process was the forground owner of the console to go to into a coma, locking up the console (except for background openers like syslog). Killing that process from a remote login fixes the problem. Running the old iteconfig on the same kernel doesn't cause the problem. However, with the old iteconfig (haven't tested with the new one) I can "panic: vm_fault" the machine by running iteconfig while Xmono is running. Trying to change the ite size while X is running is probably a stupid thing to do, but I only wanted to set the colors. Even trying to get the current settings will panic the machine. While some iteconfig options perhaps shouldn't be allowed why grf0 is in graphics mode, it should be impossible to crash the machine like that. -- 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 Apr 17 12:33:54 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: iteconfig broken? To: tsarna@endicor.com (Ty Sarna) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1253 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Something changed between the old iteconfig and the one in -current as > of April 9th, that causes problems on my machine. Running the new > iteconfig on a Apr9-current kernel causes whatever process was the > forground owner of the console to go to into a coma, locking up the > console (except for background openers like syslog). Killing that > process from a remote login fixes the problem. Running the old > iteconfig on the same kernel doesn't cause the problem. This is a known and fixed problem. see cgd's recent changes in sys/dev/cons.c and mycroft's in sys/kern/vfs_subr.c.. > However, with the old iteconfig (haven't tested with the new one) I can > "panic: vm_fault" the machine by running iteconfig while Xmono is running. > Trying to change the ite size while X is running is probably a stupid thing > to do, but I only wanted to set the colors. Even trying to get the current > settings will panic the machine. While some iteconfig options perhaps > shouldn't be allowed why grf0 is in graphics mode, it should be > impossible to crash the machine like that. Don't run X too often so I never deal with it. I was aware of the problem however.. when I get a chance to look into it I will. In the meantime feel free. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 12:33:59 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Misc stuff To: sbusko@cap.gwu.edu Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 387 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > First I just read that Amiga Linux has a way to distinguish between the > GVP I/O Extender and the rest of the GVP cards. So, case you devs missed > that, I thought it might be useful to see how they did it. Michael Hitch provided me with this and appropriate changes a while ago. Its possible that Hamish picked it up from us for Linux. Needless to say we have it already. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 17:27:02 1994 From: Hubert Feyrer To: amiga@sun-lamp.cs.berkeley.edu, sbusko@cap.gwu.edu Subject: Re: Misc stuff Sender: owner-amiga@sun-lamp.cs.berkeley.edu > I also have a prob w/ the color X server. I have the orig mono server > working great w/ kernel 744 and bins. But when I link the cc4 I get > that it can't find the display??? I'm sure it doesn't use views (not > that I have them avail w/ 744 anyway), and mono still works... Well, I also have a 744 kernel, but I have views, too, and with me, switching the link from Xmono to Xcc[24] was enough to get it working. So, I'd suggest you put some views into your kernel. Mail me if you want my kernel. Greetings, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 20:39:21 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu Subject: New binaries on sun-lamp Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've just finished uploading new binaries onto sun-lamp and have asked Chris to move them to their proper location. Look for them to show up on the sun-lamp mirrors over the next couple of days. -SR >From the README: This is a binary snapshot, created from the NetBSD-current sources as of 13 April 1994. They should be used in the same way as all -current sources: VERY CAREFULLY, and only by those who know what they're doing. I messed up during the building of these, (I have the environment variable EXPORTABLE_SYSTEM set to true) so I've renamed the crypt libraries to have suffixes so any existing versions are not destroyed. File: Contents: ----- --------- bin.tar.gz /bin dev.tar.gz /dev etc.tar.gz /etc, .profile, .cshrc, /root, /mnt, /tmp sbin.tar.gz /sbin usr.bin.tar.gz /usr/bin usr.games.tar.gz /usr/games usr.include.tar.gz /usr/include usr.lib.tar.gz /usr/lib usr.libexec.tar.gz /usr/libexec usr.misc.tar.gz /usr/mdec, prototypes for /usr/local, /usr/src, /usr/obj usr.sbin.tar.gz /usr/sbin usr.share.tar.gz /usr/share var.tar.gz /var Additionally, the following -current kernel binaries are provided: netbsd-generic NetBSD kernel, which includes support for everything. Generated from the GENERIC config file. netbsd-a3000 NetBSD kernel, tailored for use on a stock A3000. Generated from the A3000 config file. Checksums of the various files are available in the file CKSUMS. Good luck! -SR From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 17 22:34:09 1994 From: Alan Bair Subject: Re: Misc stuff To: tsarna@endicor.com (Ty Sarna) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > Next, for the Retina ZIII owners. How is the card? I'm thinking about > > Sort of off-topic, but does the Retina Z3 have a monitor passthru and > switch capability? I find that feature of the Picasso very attractive... Everything I have read, Net & AmigaWorld, indicates it does NOT have the monitor passthru. A sidebar in AmigaWorld indicated that MacroSystems was considering selling an external switch to handle passthru. There are various opions that the pasthru switching can cause signal degredation at the higher frequencies. With the hints about an upcomming NetBSD X driver for the Picasso, it has complicated my decision on going for a Retina Z3 or the Picasso. > > -- > Ty Sarna "As you know, Joel, children have always looked > tsarna@endicor.com up to cowboys as role models. And vice versa." > -- 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 Sun Apr 17 23:54:51 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Misc stuff" (Apr 17, 7:02am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tsarna@endicor.com (Ty Sarna), amiga@sun-lamp.cs.berkeley.edu Subject: Re: Misc stuff Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 17, 7:02am, Ty Sarna wrote: > > Next, for the Retina ZIII owners. How is the card? I'm thinking about > > Sort of off-topic, but does the Retina Z3 have a monitor passthru and > switch capability? I find that feature of the Picasso very attractive... No, hasn't. Thats why i have a Picasso :-) (Well, Spectrum EGS and Picollo have that feature, too). Macro Systems me told that a monitor switch is not 'required or essential' - i wonder why. Anyway, under NetBSD this feature is not required (hm, unless someone rewrites the console-stuff :-). -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 00:15:26 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Misc stuff" (Apr 17, 2:54pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Alan Bair , tsarna@endicor.com (Ty Sarna) Subject: Re: Misc stuff Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 17, 2:54pm, Alan Bair wrote: > With the hints about an upcomming NetBSD X driver for the Picasso, it has > complicated my decision on going for a Retina Z3 or the Picasso. To make it more compilcated: It sould be possible to run them both at the same time :-) Sorry, i sure will not help you on deciding, may look like an advertisement... (although i am not connected with VT other than having worked for them during the CeBIT fair...) Picasso is a Z2 card -only-, have that in mind, whereas RetinaZ3 is obviously for Z3 (only), and cost more of course. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 18 02:25:58 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga.dev Subject: Re: Yellow screen on reboot Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 27 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <199404161532.LAA23371@zombie.ncsc.mil>, "Stephen J. Roznowski" writes: > I'm still getting a yellow screen when I try to reboot my 16Meg A3000. > This problem only started to occur when I upgraded from 8M to 16M. > > I'm running the latest binaries (13 April sources). > > Is anyone else seeing this problem? Yes. > Does anyone have a fix? I don't. cu, Lutz Vieweg -- "Das Telefon seit Tagen still. Kein Mensch, mit dem ich reden will. Ich seh im Spiegel mein Gesicht, nichts hat mehr Gewicht. Ich werfe Schatten an die Wand. Ich halte zdrtlich meine Hand. Ich red' mit mir und schau ins Licht, mich erreichst Du nicht. In meinem Film bin ich der Star, ich komm auch nur alleine klar. Panzerschrank aus Diamant, Kombination unbekannt. Alle Worte tausend mal gesagt, alle Fragen tausend mal gefragt, alle Gef|hle tausend mal gef|hlt. Tiefgefroren, tiefgek|hlt." ('Ideal', "Eiszeit") From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Apr 18 02:26:26 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga.x Subject: Re: RetinaZ3 experimental X-server Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 27 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu In article <199404160017.CAA27284@father.ludd.luth.se>, Andreas Johansson writes: > Has anyone compiled a kernel with support for the Retina Z3 that would work > with an A4000 w/ GVP scsi interface? It seems to me that the kernel compiled > by mw did not contain the gvp driver. You are correct, the kernel in incoming/experimental does not support scsi-devices other than the A3000's built-in. > I would like to get NetBSD to work on my Retina Z3 without recompiling the > kernel, with custom chips I get a pretty nifty 640x400 on a TV-set! Hmmm... well... you are the second one who's asking... The problem is: Markus kernel is NOT based on the latest kernel sources, and I don't feel comfortable with the idea of mixing Markus' changes with the current sources... I'd like to leave this (possibly tricky) part to him... I'll take a short look at it in the next days, but I won't dig deeper into the kernel internals if it doesn't run after a few compile-cycles... cu, Lutz Vieweg -- "Was heisst hier morgen - laecherlich - die Arbeit laeuft auch ohne mich!" ('Strassenjungs' / "Es geht los") From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 02:38:05 1994 Subject: Term? 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 Has anyone got term working on NetBSD? When I run trsh, my machine just hangs. I see no characters sent from the modem. I would expect to see something sent to the modem, indicating the negotiation of a new shell session. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 02:50:07 1994 Subject: Term 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 To follow up on my previous post, here is the contents of /.termrc: baudrate 38400 window 6 compress on timeout 80 There is no .term dir in my home directory. TERMDIR is set to /. I am running a kernel I built myself on March 26, from SUPed sources. Also, is there hardware flow-control built into the kernel? I lose characters in kermit at 38400. (Sometimes half a page worth). -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 03:24:53 1994 From: mbeausej@qc.bell.ca (michel beausejour) To: amiga@sun-lamp.cs.berkeley.edu Subject: interaction a2065/a3000 Cc: amiga@wunet.wustl.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've posted a message before regarding the problem that i have(loosing packets) between my a3000 and a1200 using ethernet cards. Finally i proved that my I-net card for the a1200 is good .Si i've put my a2065 board in my a2000 and connected it to my a1200 and it's working like a charm so what is wrong with my a3000 that cause my a2065 to loose some packets. I experience the problem with Amitcp under AmigaDos or using NetBSD. Thanks, Michel Beausejour mbeausej@qc.bell.ca From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 18 03:27:04 1994 From: Arthur Hoffmann Subject: mfs & swap problems. To: 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: 396 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I found that whenever I used my /tmp directory heavily the swap space got recduced. Now, after I cleared the /tmp directory again the swapspace doesn't increase anymore. Is there any way to let the system know that the free /tmp (mfs) space is usable for vm again? Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 18 03:32:38 1994 From: Arthur Hoffmann Subject: compiling latest suped kernel sources To: 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: 1138 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I was trying to compile the latest suped kernel sources from 18.04.1994 and got the following error. Does anyone have any suggestions? cc -I. -I../../../../arch -I../../../.. -I../../../../sys -DATZE -DM68030 -DPP P_OUTQ_SIZE=4096 -DGENERIC -DNKMEMCLUSTERS=256 -DKTRACE -DDDB -DDIAGNOSTIC -DFPC OPROC -DDIAGNOSTIC -DSYSVSEM -DSYSVMSG -DSYSVSHM -DPANICWAIT -DHAVE_USL_UFS -DCO MPAT_NOMID -DTCP_COMPAT_42 -DCOMPAT_43 -DGRF_A2024 -DGRF_PAL -DGRF_NTSC -DGRF_AC S -DGRF_ECS -DGRF_OCS -DGRF_CUSTOM_CHIP_MODES -DGRF -DCOMPAT_SUNOS -DGATEWAY -DL KM -DPROCFS -DPORTAL -DLOFS -DPROCFS -DFDESC -DADOSFSDEBUG -DADOSFS -DKERNFS -DM SDOSFS -DFIFO -DISOFS -DMFS -DNFSCLIENT -DNFSSERVER -DNFS -DFFS -DINET -DDEVPAGE R -DVNODEPAGER -DSWAPPAGER -DQUOTA -DFPSP -DTIMEZONE=-570 -DDST=1 -DMAXUSERS=16 -DMAXFDESCS=2048 -Dmc68020 -Damiga -o genassym ../../amiga/genassym.c ../../amiga/genassym.c: In function `main': ../../amiga/genassym.c:85: structure has no member named `v_pdma' ../../amiga/genassym.c:87: structure has no member named `v_pgrec' ../../amiga/genassym.c:88: structure has no member named `v_fastpgrec' *** Error code 1 Stop. Arthur. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 05:44:46 1994 From: mw@eunet.ch Subject: Re: Misc stuff To: abair@sol-tx.sps.mot.com (Alan Bair) Cc: tsarna@endicor.com, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1163 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Everything I have read, Net & AmigaWorld, indicates it does NOT have the > monitor passthru. A sidebar in AmigaWorld indicated that MacroSystems was > considering selling an external switch to handle passthru. There are > various opions that the pasthru switching can cause signal degredation at > the higher frequencies. Well, it does not have a switch, period. I've owned Retinas for quite a while now, and I never missed such a switch. Depends of course on what stuff you usually do with your computer, but just for using Worbench and NetBSD (the stuff I usually do with it:-)), there's absolutely no need to ever go back to the custom chips display. Besides: both boards already contain filtering perls to get the bord thru FCC, and those perls seriously harm sharpness in high-resolution modes. Removing those perls is pretty easy (and the result is obvious..), removing a switch would probably not be that easy. Only my humble option, I'm not affiliated whatsoever with MacroSystem. -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 Apr 18 05:57:30 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Binary releases and 64 bit off_t Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9404120958.AA25079@ente.techfak.uni-bielefeld.de> markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) writes: > Fred is very interested into distributing NetBSD-Amiga on one of > his CD-ROMs - and he is aware of the law-suit problem and the libcrypt > things. Yes, we've talked about these issues before. I'm still working on our NetBSD/amiga CD-ROM; the USL settlement hasn't delayed or stopped that, it only means that we couldn't release it right now if we wanted to. We also have a solution to the DES problem. The CDROM itself contains no DES code. Discs we ship inside North America come with an install floppy which contains the DES stuff, and the install softwrae automaticly detects and installs it. The person who will be the distributor for Europe and probably the rest of the world will get a copy of the install floppy minus the DES code. He will add functionally identical non-US DES code to the floppies he includes with discs. So, DES will be availible to everyone pretty much transparently. We handle all the stupid legal details so cdrom purchasers don't have to. > The low-end NetBSD-Amiga i know of is an A500 with 020-PACK68 enhancement, > SCSI-Adaptor, and 4MB RAM. How fast is the 020-PACK68 clocked? -- 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 Mon Apr 18 06:00:19 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: mfs & swap problems. Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <199404180056.KAA13179@nutmeg> Arthur Hoffmann writes: > Hi, > I found that whenever I used my /tmp directory heavily the swap > space got recduced. Now, after I cleared the /tmp directory again the > swapspace doesn't increase anymore. Is there any way to let the system > know that the free /tmp (mfs) space is usable for vm again? Not with the current mfs, It would need a lot of work to be able to release VM to the system. mfs is *NOT* like SunOS tmpfs. Also note that by default mfs uses as much memory as the partition you mount it on! If you only have one swap partition, DON'T MOUNT MFS ON IT WITHOUT USING THE -s FLAG TO LIMIT THE AMOUNT OF SWAP MFS USES!!! If you don't use -s bad things can happen. -- 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 Mon Apr 18 06:38:07 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 latest suped kernel sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 18, 10:36am, Arthur Hoffmann wrote: > Hi, > I was trying to compile the latest suped kernel sources from > 18.04.1994 and got the following error. Does anyone have any > suggestions? Yes - remove those three statements. It appears that those structure members have been removed. I didn't seen any reference to the symbols in any of the Amiga assembly code. > ../../amiga/genassym.c: In function `main': > ../../amiga/genassym.c:85: structure has no member named `v_pdma' > ../../amiga/genassym.c:87: structure has no member named `v_pgrec' > ../../amiga/genassym.c:88: structure has no member named `v_fastpgrec' > *** Error code 1 > > Stop. 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 Apr 18 08:36:27 1994 From: niklas@appli.se (Niklas Hallqvist) To: hoffmann@it.ntu.edu.au Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: compiling latest suped kernel sources Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Arthur" == Arthur Hoffmann writes: Arthur> Hi, I was trying to compile the latest suped kernel sources Arthur> from 18.04.1994 and got the following error. Does anyone have Arthur> any suggestions? Yes, remove the lines that have the undefined references from sys/arch/amiga/amiga/genassym.c. The be prepared for more work, I don't think Chris H has kept CGD's pace of changes in the vm subsystem. For example vm/queue.h is now sys/queue, queue_head_t is no more, you've got to use the new macros in sys/queue.h and I think vm/vm_statistics has gone (at least my last sup wiped it out). I'm working on these issues but my system's in a mess now and I'm going to work so I can't provide diffs now. Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 10:27:05 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: iteconfig broken? Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404170950.AA10907@emunix.emich.edu> chopps@emunix.emich.edu (Chris Hopps) writes: > This is a known and fixed problem. see cgd's recent changes in > sys/dev/cons.c and mycroft's in sys/kern/vfs_subr.c.. Ah! > Don't run X too often so I never deal with it. I was aware of the problem > however.. when I get a chance to look into it I will. In the meantime feel > free. Next time I upgrade to -current (so the iteconfig problem is fixed on my system) I'll try to find the problem and fix it if nobody beats me to it. -- 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 Mon Apr 18 11:18:52 1994 From: Andreas Heitmann To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: new sup server on ftp.hrz.uni-kassel.de Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi ! I just installed a sup-server on our ftp box ftp.hrz.uni-kassel.de. The server mirrors the releases ksrc-amiga, ksrc-common and src from the current collection of sun-lamp. The parameters for the supfile are: host=ftp.hrz.uni-kassel.de hostbase=/home/aFTP/ftp/pub/machines/amiga/NetBSD release=ksrc-amiga release=ksrc-common release=src Access to the server is provided for the default number of users (3 at the same time). If the server runs stable we can raise the limit. Remember that the server is still experimental. If you want me to mirror other releases, please tell me. In addition, sup binaries for IBM RS/6000 and HP/UX will soon be provided on the server. I'm going to put them in the directory: /ftp.hrz.uni-kassel.de:pub/machines/amiga/NetBSD/sup-binaries Have fun, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 18 11:20:56 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: serial driver patches Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu First, a patch to serreg.h. For the normal dual-/dev-entry dialin/dialout type serial scheme on SunOS and other BSD systems, the dialin line is minor unit n and the dialout line is n+128. The amiga netbsd MAKEDEV and /etc/ttys files are also set up this way. The serreg.h DIALXXX macros however were backwards. Also, with my ser.c changes below DIALIN is no longer used, so I deleted it. *** serreg.h Sun Apr 17 18:48:14 1994 --- serreg.h.orig Sun Apr 17 15:32:06 1994 *************** *** 66,69 **** dialout: carrier is ignored */ #define SERUNIT(dev) (minor(dev) & 0x7f) ! #define DIALOUT(dev) ((minor(dev) & 0x80) == 0x80) --- 66,70 ---- dialout: carrier is ignored */ #define SERUNIT(dev) (minor(dev) & 0x7f) ! #define DIALIN(dev) ((minor(dev) & 0x80) == 0x80) ! #define DIALOUT(dev) ((minor(dev) & 0x80) == 0x00) Next, changes to ser.c: I'm including the whole file since the diffs were nearly twice the size of the new file. Changes: - major style changes to make it mostly KNF compliant - Added support for cgd's new ttyflags stuff. See ttyflags(8) and ttys(5). - IXOFF removed from default iflags... it was XXXX'd and looked bogus. - default cflags changed from CREAD+CS8+CLOCAL to the default flags (CREAD+ CS7+HUPCTL+PARENB). Depending on the settings of ttyflags in /etc/ttys, CLOCAL and/or CRTSCTS can also be set by default on open. This is now consistent with cgd's changes to the i386 com driver (minus MDMBUF support) This needs some more testing, and someone also needs to examine the other "#if 0"'d code and either put it back or nuke it. Here's the file: -----snip snip----- /* * Copyright (c) 1982, 1986, 1990 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. * * @(#)ser.c 7.12 (Berkeley) 6/27/91 * $Id: ser.c,v 1.13 1994/03/30 17:24:36 chopps Exp $ */ #include "ser.h" #if NSER > 0 #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include int serprobe(); struct driver serdriver = { serprobe, "ser", }; int serstart(), serparam(), serintr(); int ser_active; int ser_hasfifo; int nser = NSER; #ifdef SERCONSOLE int serconsole = SERCONSOLE; #else int serconsole = -1; #endif int serconsinit; int serdefaultrate = TTYDEF_SPEED; int sermajor; int serswflags; #define SWFLAGS(dev) (serswflags | (DIALOUT(dev) ? TIOCFLAG_SOFTCAR : 0)) struct serdevice *ser_addr[NSER]; struct vbl_node ser_vbl_node[NSER]; struct tty ser_cons; struct tty *ser_tty[NSER]; struct speedtab serspeedtab[] = { 0, 0, 50, SERBRD(50), 75, SERBRD(75), 110, SERBRD(110), 134, SERBRD(134), 150, SERBRD(150), 200, SERBRD(200), 300, SERBRD(300), 600, SERBRD(600), 1200, SERBRD(1200), 1800, SERBRD(1800), 2400, SERBRD(2400), 4800, SERBRD(4800), 9600, SERBRD(9600), 19200, SERBRD(19200), 38400, SERBRD(38400), 57600, SERBRD(57600), 76800, SERBRD(76800), -1, -1 }; /* * Since this UART is not particularly bright (to put it nicely), we'll * have to do parity stuff on our own. This table contains the 8th bit * in 7bit character mode, for even parity. If you want odd parity, * flip the bit. (for generation of the table, see genpar.c) */ u_char even_parity[] = { 0, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0, 0, 1, 1, 0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0, 0, 1, }; /* * Since we don't get interrupts for changes on the modem control line, * we'll have to fake them by comparing current settings to the settings * we remembered on last invocation. */ u_char last_ciab_pra; extern struct tty *constty; #ifdef KGDB #include extern dev_t kgdb_dev; extern int kgdb_rate; extern int kgdb_debug_init; #endif #ifdef DEBUG long fifoin[17]; long fifoout[17]; long serintrcount[16]; long sermintcount[16]; #endif void sermint __P((register int unit)); int serprobe(ad) register struct amiga_device *ad; { register struct serdevice *ser; register int unit; unsigned short ir = custom.intenar; ser = (struct serdevice *) ad->amiga_addr; unit = ad->amiga_unit; if (unit == serconsole) DELAY(100000); ad->amiga_ipl = 2; ser_addr[unit] = ser; ser_active |= 1 << unit; ser_vbl_node[unit].function = (void (*) (void *)) sermint; add_vbl_function(&ser_vbl_node[unit], SER_VBL_PRIORITY, (void *) unit); #ifdef KGDB if (kgdb_dev == makedev(sermajor, unit)) { if (serconsole == unit) kgdb_dev = NODEV; /* can't debug over console port */ else { (void) serinit(unit, kgdb_rate); serconsinit = 1; /* don't re-init in serputc */ if (kgdb_debug_init) { /* * Print prefix of device name, * let kgdb_connect print the rest. */ printf("ser%d: ", unit); kgdb_connect(1); } else printf("ser%d: kgdb enabled\n", unit); } } #endif /* * Need to reset baud rate, etc. of next print so reset serconsinit. */ if (unit == serconsole) serconsinit = 0; return (1); } /* ARGSUSED */ int seropen(dev, flag, mode, p) dev_t dev; int flag, mode; struct proc *p; { register struct tty *tp; register int unit; int error = 0; int s; unit = SERUNIT(dev); if (unit >= NSER || (ser_active & (1 << unit)) == 0) return (ENXIO); if (!ser_tty[unit]) { tp = ser_tty[unit] = ttymalloc(); /* * The default values are not optimal for this device, * so increase the buffers */ clfree(&tp->t_rawq); clfree(&tp->t_canq); clfree(&tp->t_outq); clalloc(&tp->t_rawq, 8192, 1); clalloc(&tp->t_canq, 8192, 1); clalloc(&tp->t_outq, 8192, 0); } else tp = ser_tty[unit]; tp->t_oproc = (void (*) (struct tty *)) serstart; tp->t_param = serparam; tp->t_dev = dev; if ((tp->t_state & TS_ISOPEN) == 0) { tp->t_state |= TS_WOPEN; ttychars(tp); if (tp->t_ispeed == 0) { tp->t_iflag = TTYDEF_IFLAG; tp->t_oflag = TTYDEF_OFLAG; tp->t_cflag = TTYDEF_CFLAG; if (serswflags & TIOCFLAG_CLOCAL) tp->t_cflag |= CLOCAL; if (serswflags & TIOCFLAG_CRTSCTS) tp->t_cflag |= CRTSCTS; if (serswflags & TIOCFLAG_MDMBUF) tp->t_cflag |= MDMBUF; tp->t_lflag = TTYDEF_LFLAG; tp->t_ispeed = tp->t_ospeed = serdefaultrate; } serparam(tp, &tp->t_termios); ttsetwater(tp); } else { if (tp->t_state & TS_XCLUDE && p->p_ucred->cr_uid != 0) return (EBUSY); } (void) sermctl(dev, TIOCM_DTR | TIOCM_RTS, DMSET); if ((SWFLAGS(dev) & TIOCFLAG_SOFTCAR) || (sermctl(dev, 0, DMGET) & TIOCM_CD)) tp->t_state |= TS_CARR_ON; else tp->t_state &= ~TS_CARR_ON; s = spltty(); while ((flag & O_NONBLOCK) == 0 && (tp->t_cflag & CLOCAL) == 0 && (tp->t_state & TS_CARR_ON) == 0) { tp->t_state |= TS_WOPEN; if (error = ttysleep(tp, (caddr_t) & tp->t_rawq, TTIPRI | PCATCH, ttopen, 0)) break; } splx(s); if (error == 0) { /* * Reset the tty pointer, as there could have been a dialout * use of the tty with a dialin open waiting. */ tp->t_dev = dev; error = (*linesw[tp->t_line].l_open) (dev, tp); } return (error); } /*ARGSUSED*/ int serclose(dev, flag, mode, p) dev_t dev; int flag, mode; struct proc *p; { register struct tty *tp; register struct serdevice *ser; register int unit; unit = SERUNIT(dev); ser = ser_addr[unit]; tp = ser_tty[unit]; (*linesw[tp->t_line].l_close) (tp, flag); custom.adkcon = ADKCONF_UARTBRK; /* clear break */ #ifdef KGDB /* do not disable interrupts if debugging */ if (dev != kgdb_dev) #endif /* clear interrupt enable */ custom.intena = INTF_RBF | INTF_TBE; custom.intreq = INTF_RBF | INTF_TBE; /* and interrupt request */ #if 0 /* If the device is closed, it's close, no matter whether we deal with * modem control signals nor not. */ if (tp->t_cflag & HUPCL || tp->t_state & TS_WOPEN || (tp->t_state & TS_ISOPEN) == 0) #endif (void) sermctl(dev, 0, DMSET); ttyclose(tp); #if 0 if (tp != &ser_cons) { remove_vbl_function(&ser_vbl_node[unit]); ttyfree(tp); ser_tty[unit] = (struct tty *) NULL; } #endif return (0); } int serread(dev, uio, flag) dev_t dev; struct uio *uio; { register struct tty *tp = ser_tty[SERUNIT(dev)]; int error; if (!tp) return ENXIO; error = (*linesw[tp->t_line].l_read) (tp, uio, flag); return error; } int serwrite(dev, uio, flag) dev_t dev; struct uio *uio; { int unit = SERUNIT(dev); register struct tty *tp = ser_tty[unit]; if (!tp) return ENXIO; /* * (XXX) We disallow virtual consoles if the physical console is * a serial port. This is in case there is a display attached that * is not the console. In that situation we don't need/want the X * server taking over the console. */ if (constty && unit == serconsole) constty = NULL; return ((*linesw[tp->t_line].l_write) (tp, uio, flag)); } /* * We don't do any processing of data here, so we store the raw code * obtained from the uart register. In theory, 110kBaud gives you * 11kcps, so 16k buffer should be more than enough, interrupt * latency of 1s should never happen, or something is seriously * wrong.. */ #define SERIBUF_SIZE 16384 static u_short serbuf[SERIBUF_SIZE]; static u_short *sbrpt = serbuf; static u_short *sbwpt = serbuf; /* * This is a replacement for the lack of a hardware fifo. 32k should be * enough (there's only one unit anyway, so this is not going to * accumulate). */ void ser_fastint() { /* * We're at RBE-level, which is higher than VBL-level which is used * to periodically transmit contents of this buffer up one layer, * so no spl-raising is necessary. */ register u_short ints, code; ints = custom.intreqr & INTF_RBF; if (!ints) return; /* clear interrupt */ custom.intreq = ints; /* this register contains both data and status bits! */ code = custom.serdatr; /* should really not happen, but you never know.. buffer overflow. */ if (sbwpt + 1 == sbrpt || (sbwpt == serbuf + SERIBUF_SIZE - 1 && sbrpt == serbuf)) { log(LOG_WARNING, "ser_fastint: buffer overflow!"); return; } *sbwpt++ = code; if (sbwpt == serbuf + SERIBUF_SIZE) sbwpt = serbuf; } int serintr(unit) register int unit; { register struct serdevice *ser; int s1, s2; ser = ser_addr[unit]; /* * Make sure we're not interrupted by another * vbl, but allow level5 ints */ s1 = spltty(); /* ok, pass along any acumulated information .. */ while (sbrpt != sbwpt) { /* no collision with ser_fastint() */ sereint(unit, *sbrpt, ser); /* lock against ser_fastint() */ s2 = spl5(); { sbrpt++; if (sbrpt == serbuf + SERIBUF_SIZE) sbrpt = serbuf; } splx(s2); } splx(s1); #if 0 /* add the code below if you really need it */ { /* * Process a received byte. Inline for speed... */ #ifdef KGDB #define RCVBYTE() \ ch = code & 0xff; \ if ((tp->t_state & TS_ISOPEN) == 0) { \ if (ch == FRAME_END && \ kgdb_dev == makedev(sermajor, unit)) \ kgdb_connect(0); /* trap into kgdb */ \ } #else #define RCVBYTE() #endif RCVBYTE(); /* sereint does the receive-processing */ sereint(unit, code, ser); } #endif } int sereint(unit, stat, ser) register int unit, stat; register struct serdevice *ser; { register struct tty *tp; register int c; register u_char ch; tp = ser_tty[unit]; if ((tp->t_state & TS_ISOPEN) == 0) { #ifdef KGDB /* we don't care about parity errors */ if (kgdb_dev == makedev(sermajor, unit) && c == FRAME_END) kgdb_connect(0); /* trap into kgdb */ #endif return; } ch = stat & 0xff; c = ch; /* all databits 0 including stop indicate break condition */ if (!(stat & 0x1ff)) c |= TTY_FE; /* if parity checking enabled, check parity */ else if ((tp->t_cflag & PARENB) && (((ch >> 7) + even_parity[ch & 0x7f] + !!(tp->t_cflag & PARODD)) & 1)) c |= TTY_PE; if (stat & SERDATRF_OVRUN) log(LOG_WARNING, "ser%d: silo overflow\n", unit); (*linesw[tp->t_line].l_rint) (c, tp); } /* * This interrupt is periodically invoked in the vertical blank * interrupt. It's used to keep track of the modem control lines * and (new with the fast_int code) to move accumulated data * up into the tty layer. */ void sermint(unit) register int unit; { register struct tty *tp; register u_char stat, last, istat; register struct serdevice *ser; tp = ser_tty[unit]; if (!tp) return; if ((tp->t_state & (TS_ISOPEN | TS_WOPEN)) == 0) { sbrpt = sbwpt = serbuf; return; } /* first empty buffer */ serintr(unit); stat = ciab.pra; last = last_ciab_pra; last_ciab_pra = stat; /* check whether any interesting signal changed state */ istat = stat ^ last; if ((istat & CIAB_PRA_CD) && (SWFLAGS(tp->t_dev) & TIOCFLAG_SOFTCAR) == 0) { if (ISDCD(stat)) (*linesw[tp->t_line].l_modem) (tp, 1); else if ((*linesw[tp->t_line].l_modem) (tp, 0) == 0) { CLRDTR(stat); CLRRTS(stat); ciab.pra = stat; last_ciab_pra = stat; } } if ((istat & CIAB_PRA_CTS) && (tp->t_state & TS_ISOPEN) && (tp->t_cflag & CRTSCTS)) { #if 0 /* the line is up and we want to do rts/cts flow control */ if (ISCTS(stat)) { tp->t_state &= ~TS_TTSTOP; ttstart(tp); /* cause tbe-int if we were stuck there */ custom.intreq = INTF_SETCLR | INTF_TBE; } else tp->t_state |= TS_TTSTOP; #else /* do this on hardware level, not with tty driver */ if (ISCTS(stat)) { tp->t_state &= ~TS_TTSTOP; /* cause TBE interrupt */ custom.intreq = INTF_SETCLR | INTF_TBE; } #endif } } int serioctl(dev, cmd, data, flag, p) dev_t dev; caddr_t data; struct proc *p; { register struct tty *tp; register int unit = SERUNIT(dev); register struct serdevice *ser; register int error; tp = ser_tty[unit]; if (!tp) return ENXIO; error = (*linesw[tp->t_line].l_ioctl) (tp, cmd, data, flag, p); if (error >= 0) return (error); error = ttioctl(tp, cmd, data, flag, p); if (error >= 0) return (error); ser = ser_addr[unit]; switch (cmd) { case TIOCSBRK: custom.adkcon = ADKCONF_SETCLR | ADKCONF_UARTBRK; break; case TIOCCBRK: custom.adkcon = ADKCONF_UARTBRK; break; case TIOCSDTR: (void) sermctl(dev, TIOCM_DTR | TIOCM_RTS, DMBIS); break; case TIOCCDTR: (void) sermctl(dev, TIOCM_DTR | TIOCM_RTS, DMBIC); break; case TIOCMSET: (void) sermctl(dev, *(int *) data, DMSET); break; case TIOCMBIS: (void) sermctl(dev, *(int *) data, DMBIS); break; case TIOCMBIC: (void) sermctl(dev, *(int *) data, DMBIC); break; case TIOCMGET: *(int *) data = sermctl(dev, 0, DMGET); break; case TIOCGFLAGS: *(int *)data = SWFLAGS(dev); break; case TIOCSFLAGS: error = suser(p->p_ucred, &p->p_acflag); if (error != 0) return(EPERM); serswflags = *(int *)data; serswflags &= /* only allow valid flags */ (TIOCFLAG_SOFTCAR | TIOCFLAG_CLOCAL | TIOCFLAG_CRTSCTS); break; default: return ENOTTY; } return (0); } int serparam(tp, t) register struct tty *tp; register struct termios *t; { register struct serdevice *ser; register int cfcr, cflag = t->c_cflag; int unit = SERUNIT(tp->t_dev); int ospeed = ttspeedtab(t->c_ospeed, serspeedtab); /* check requested parameters */ if (ospeed < 0 || (t->c_ispeed && t->c_ispeed != t->c_ospeed)) return (EINVAL); /* and copy to tty */ tp->t_ispeed = t->c_ispeed; tp->t_ospeed = t->c_ospeed; tp->t_cflag = cflag; custom.intena = INTF_SETCLR | INTF_RBF | INTF_TBE; last_ciab_pra = ciab.pra; if (ospeed == 0) { (void) sermctl(tp->t_dev, 0, DMSET); /* hang up line */ return (0); } else { /* make sure any previous hangup is undone, ie. reenable DTR. */ (void) sermctl(tp->t_dev, TIOCM_DTR | TIOCM_RTS, DMSET); } /* set the baud rate */ custom.serper = (0 << 15) | ospeed; /* select 8 (not 9) bit mode */ return (0); } static void ser_putchar(tp, c) struct tty *tp; unsigned short c; { /* handle truncation of character if necessary */ if ((tp->t_cflag & CSIZE) == CS7) c &= 0x7f; /* handle parity if necessary (forces CS7) */ if (tp->t_cflag & PARENB) { c &= 0x7f; if (even_parity[c]) c |= 0x80; if (tp->t_cflag & PARODD) c ^= 0x80; } /* add stop bit(s) */ if (tp->t_cflag & CSTOPB) c |= 0x300; else c |= 0x100; custom.serdat = c; } #define SEROBUF_SIZE 32 static u_char ser_outbuf[SEROBUF_SIZE]; static u_char *sob_ptr = ser_outbuf, *sob_end = ser_outbuf; void ser_outintr() { struct tty *tp = ser_tty[0]; /* hmmmmm */ unsigned short c; int s = spltty(); if (!tp) goto out; if (!(custom.intreqr & INTF_TBE)) goto out; /* clear interrupt */ custom.intreq = INTF_TBE; if (sob_ptr == sob_end) { tp->t_state &= ~(TS_BUSY | TS_FLUSH); if (tp->t_line) (*linesw[tp->t_line].l_start) (tp); else serstart(tp); goto out; } /* * Do hardware flow control here. if the CTS line goes down, don't * transmit anything. That way, we'll be restarted by the periodic * interrupt when CTS comes back up. */ if (ISCTS(ciab.pra)) ser_putchar(tp, *sob_ptr++); out: splx(s); } int serstart(tp) register struct tty *tp; { register int cc, s; register struct serdevice *ser; int unit; int hiwat = 0; if (!(tp->t_state & TS_ISOPEN)) return; unit = SERUNIT(tp->t_dev); ser = ser_addr[unit]; s = spltty(); if (tp->t_state & (TS_TIMEOUT | TS_TTSTOP)) goto out; cc = tp->t_outq.c_cc; if (cc <= tp->t_lowat) { if (tp->t_state & TS_ASLEEP) { tp->t_state &= ~TS_ASLEEP; wakeup((caddr_t) & tp->t_outq); } selwakeup(&tp->t_wsel); } if (!cc || (tp->t_state & TS_BUSY)) goto out; /* * We only do bulk transfers if using CTSRTS flow control, not for * (probably sloooow) ixon/ixoff devices. */ if (!(tp->t_cflag & CRTSCTS)) cc = 1; /* * Limit the amount of output we do in one burst * to prevent hogging the CPU. */ if (cc > SEROBUF_SIZE) { hiwat++; cc = SEROBUF_SIZE; } cc = q_to_b(&tp->t_outq, ser_outbuf, cc); if (cc > 0) { tp->t_state |= TS_BUSY; sob_ptr = ser_outbuf; sob_end = ser_outbuf + cc; /* * Get first character out, then have TBE-interrupts blow out * further characters, until buffer is empty, and TS_BUSY gets * cleared. */ ser_putchar(tp, *sob_ptr++); } out: splx(s); } /* * Stop output on a line. */ /*ARGSUSED*/ int serstop(tp, flag) register struct tty *tp; { register int s; s = spltty(); if (tp->t_state & TS_BUSY) { if ((tp->t_state & TS_TTSTOP) == 0) tp->t_state |= TS_FLUSH; } splx(s); } int sermctl(dev, bits, how) dev_t dev; int bits, how; { register struct serdevice *ser; register int unit; u_char ub; int s; unit = SERUNIT(dev); ser = ser_addr[unit]; /* convert TIOCM* mask into CIA mask (which is really low-active!!) */ if (how != DMGET) { ub = 0; if (bits & TIOCM_DTR) ub |= CIAB_PRA_DTR; if (bits & TIOCM_RTS) ub |= CIAB_PRA_RTS; if (bits & TIOCM_CTS) ub |= CIAB_PRA_CTS; if (bits & TIOCM_CD) ub |= CIAB_PRA_CD; if (bits & TIOCM_RI) ub |= CIAB_PRA_SEL; /* collision with /dev/par ! */ if (bits & TIOCM_DSR) ub |= CIAB_PRA_DSR; } s = spltty(); switch (how) { case DMSET: /* invert and set */ ciab.pra = ~ub; break; case DMBIC: ciab.pra |= ub; ub = ~ciab.pra; break; case DMBIS: ciab.pra &= ~ub; ub = ~ciab.pra; break; case DMGET: ub = ~ciab.pra; break; } (void) splx(s); bits = 0; if (ub & CIAB_PRA_DTR) bits |= TIOCM_DTR; if (ub & CIAB_PRA_RTS) bits |= TIOCM_RTS; if (ub & CIAB_PRA_CTS) bits |= TIOCM_CTS; if (ub & CIAB_PRA_CD) bits |= TIOCM_CD; if (ub & CIAB_PRA_SEL) bits |= TIOCM_RI; if (ub & CIAB_PRA_DSR) bits |= TIOCM_DSR; return bits; } /* * Following are all routines needed for SER to act as console */ int sercnprobe(cp) struct consdev *cp; { int unit = CONUNIT; /* locate the major number */ for (sermajor = 0; sermajor < nchrdev; sermajor++) if (cdevsw[sermajor].d_open == (void *)seropen) break; /* XXX: ick */ unit = CONUNIT; /* initialize required fields */ cp->cn_dev = makedev(sermajor, unit); cp->cn_pri = CN_NORMAL; /* * If serconsole is initialized, raise our priority. */ if (serconsole == unit) cp->cn_pri = CN_REMOTE; #ifdef KGDB if (major(kgdb_dev) == 1) /* XXX */ kgdb_dev = makedev(sermajor, minor(kgdb_dev)); #endif } sercninit(cp) struct consdev *cp; { int unit = SERUNIT(cp->cn_dev); serinit(unit, serdefaultrate); serconsole = unit; serconsinit = 1; } serinit(unit, rate) int unit, rate; { int s; #ifdef lint stat = unit; if (stat) return; #endif s = splhigh(); /* might want to fiddle with the CIA later ??? */ custom.serper = ttspeedtab(rate, serspeedtab); splx(s); } sercngetc(dev) { u_short stat; int c, s; #ifdef lint stat = dev; if (stat) return (0); #endif s = splhigh(); while (!((stat = custom.serdatr & 0xffff) & SERDATRF_RBF)); c = stat & 0xff; /* clear interrupt */ custom.intreq = INTF_RBF; splx(s); return (c); } /* * Console kernel output character routine. */ sercnputc(dev, c) dev_t dev; register int c; { register int timo; short stat; int s = splhigh(); #ifdef lint stat = dev; if (stat) return; #endif if (serconsinit == 0) { (void) serinit(SERUNIT(dev), serdefaultrate); serconsinit = 1; } /* wait for any pending transmission to finish */ timo = 50000; while (!(custom.serdatr & SERDATRF_TBE) && --timo); custom.serdat = (c & 0xff) | 0x100; /* wait for this transmission to complete */ timo = 1500000; while (!(custom.serdatr & SERDATRF_TBE) && --timo); /* * Wait for the device (my vt100..) to process the data, since we * don't do flow-control with cnputc */ for (timo = 0; timo < 30000; timo++); /* clear any interrupts generated by this transmission */ custom.intreq = INTF_TBE; splx(s); } serspit(c) int c; { register struct Custom *cu asm("a2") = (struct Custom *) CUSTOMbase; register int timo asm("d2"); extern int cold; int s; if (c == 10) serspit(13); s = splhigh(); /* wait for any pending transmission to finish */ timo = 500000; while (!(cu->serdatr & (SERDATRF_TBE | SERDATRF_TSRE)) && --timo) ; cu->serdat = (c & 0xff) | 0x100; /* wait for this transmission to complete */ timo = 15000000; while (!(cu->serdatr & SERDATRF_TBE) && --timo) ; /* clear any interrupts generated by this transmission */ cu->intreq = INTF_TBE; for (timo = 0; timo < 30000; timo++) ; splx(s); } serspits(cp) char *cp; { while (*cp) serspit(*cp++); } int serselect(dev, rw, p) dev_t dev; int rw; struct proc *p; { register struct tty *tp = ser_tty[SERUNIT(dev)]; int nread; int s = spltty(); struct proc *selp; switch (rw) { case FREAD: nread = ttnread(tp); if (nread > 0 || ((tp->t_cflag & CLOCAL) == 0 && (tp->t_state & TS_CARR_ON) == 0)) goto win; selrecord(p, &tp->t_rsel); break; case FWRITE: if (tp->t_outq.c_cc <= tp->t_lowat) goto win; selrecord(p, &tp->t_wsel); break; } splx(s); return (0); win: splx(s); return (1); } #endif -----snip snip----- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 18 13:56:51 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Binary releases and 64 bit off_t" (Apr 18, 2:19am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tsarna@endicor.com (Ty Sarna), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Binary releases and 64 bit off_t Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 18, 2:19am, Ty Sarna wrote: > floppy minus the DES code. He will add functionally identical non-US DES > code to the floppies he includes with discs. So, DES will be availible > to everyone pretty much transparently. We handle all the stupid legal > details so cdrom purchasers don't have to. Good to know. Now lets wait until USL doesnt bother us again... > > The low-end NetBSD-Amiga i know of is an A500 with 020-PACK68 enhancement, > > SCSI-Adaptor, and 4MB RAM. > > How fast is the 020-PACK68 clocked? 16MHz... The system is unusable :) But heck, a Sun3/40 was, too. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 14:22:58 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Term" (Apr 17, 7:32pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: David Jones , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Term Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 17, 7:32pm, David Jones wrote: > baudrate 38400 > window 6 > compress on Remove that compression, looks like you have a V32bis/V42bis Modem anyway. > timeout 80 And remove this one. > There is no .term dir in my home directory. TERMDIR is set to /. heh? termdir in / ? What nonsense. Make a ~/.term/termrc available. > I am running a kernel I built myself on March 26, from SUPed sources. has nothing to do with kernel. > Also, is there hardware flow-control built into the kernel? I lose > characters in kermit at 38400. (Sometimes half a page worth). Pffrt :-) Serial-line has one byte cache. I suggest the following: ToDo on remote (!) machine: (compile term) Create ~/.termdir/ remote baudrate 38400 escape 0-128 ToDo on local machine: Create ~/.termdir/ baudrate 38400 escape 0-128 remark the remote-entry in the first termrc. and then: RTFM about how to connect. (start term on remote machine, quit terminal programm, start term on local machine, then start trsh) Change the escape-entries when you are sure it works, run linecheck. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 14:25:29 1994 From: niklas@appli.se (Niklas Hallqvist) To: dej@eecg.toronto.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Term Sender: owner-amiga@sun-lamp.cs.berkeley.edu version of term? version earlier than somewhere around 1.09-1.11 has this problem. How do you initiate your session, command line? Have you ktraced? Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 15:33:23 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "interaction a2065/a3000" (Apr 17, 8:41pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: mbeausej@qc.bell.ca (michel beausejour), amiga@sun-lamp.cs.berkeley.edu Subject: Re: interaction a2065/a3000 Cc: amiga@wunet.wustl.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 17, 8:41pm, michel beausejour wrote: > so what is wrong with my a3000 that cause my a2065 to loose some packets. > I experience the problem with Amitcp under AmigaDos or using NetBSD. hm, never encountered such problems. Say, in which slot was the 2065 in the A3000? Try the lowest one (bottom) for instance. Check with 'lancetest' under ADos (if you happen to have AS225R1/2). -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 19:14: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.137:17.03.94.14.46.14] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Misc stuff From: "hamish (h.i.) macdonald" To: chopps@emunix.emich.edu Cc: sbusko@cap.gwu.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Misc stuff Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> On Sun Apr 17 05:59:00 1994, >>>>> You wrote: chopps> Michael Hitch provided me with this and appropriate changes a chopps> while ago. Its possible that Hamish picked it up from us for chopps> Linux. Needless to say we have it already. Actually, I grabbed Russ's (amigaman) original posting on the subject and used the information therein. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 18 19:59:21 1994 From: rhealey@aggregate.com Subject: Re: Yellow screen on reboot To: mw@eunet.ch 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: 1029 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > This is absoluteley normal for a 16M A3000. I noticed the problem when > > I ran ther very first NetBSD kernel, and it hasnt changed a bit since > > then. > > At least CTRL-LAmiga-RAmiga still works :). > > I *think* the problem lies within the V36 bootrom, thinking that the > loaded kickstart image is still present (which it of course is NOT), and > jumping into nevereverland thru the wrong reset-vector. The way to find > out about this would be to write a (perhaps simplistic, in the first go) > loadbsd that runs under V36, and then have BSD load from that old 1.4 > kickstart (klick in the left upper corner in the V36 bootmenu, the > one that allows selection of either kick 2.0 or 1.3). This is just an idea, > but I have some reason to believe into it... (oh, and I have the same problem > myself:-)) > Additional data point: It only occurs on 16M V36, 12M and 8M seem to work just fine. AMIX seemed to be able to deal with this so it's probably just finding the "more magic" bit and frobbing it... -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 20:11:05 1994 Subject: Term>1.07 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 Where's the best place for me to FTP a non-Linuxized term more recent than 1.07? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 18 20:35:05 1994 To: amiga@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga Subject: Re: Misc stuff Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 25 Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404170022.AA18413@cap.gwu.edu>, Steve Busko Jr. writes: > Next, for the Retina ZIII owners. How is the card? Nice, IMHO :) > I don't > see R ZIII sold in the US yet Would surprise me if MacroSystem US does not sell it... > Or would it be better to get an orig Retina then upgrade??? No, of course not. This would just be much more expensive. Maybe you don't know it: There's a BIG difference between the old Retina (which is a Zorro-II card) and the Retina BLT Z3, which is a Zorro-III-only card. cu, Lutz Vieweg -- "Erst Mosch ist grad in Bad Salzuflen - und will mit seinem Mopshund knuffeln. Da blitzt es grell am Himmelszelt, ein schriller Schrei, der Kvter bellt." ('Schliessmuskel' / "Der Untergang der abendlaendischen Kultur") From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 01:11:01 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: dumpfont program Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm having problems building the dumpfont program on my Amiga. I am using gcc to build it as follows:- gcc dumpfont.c -o dumpfont This produces the following errors: In file included from dumpfont.c:13: /gcc/os-include/inline/exec.h:1032: warning: `struct SemaphoreMessage' declared inside parameter list /gcc/os-include/inline/exec.h:1032: warning: its scope is only this definition or declaration, /gcc/os-include/inline/exec.h:1032: warning: which is probably not what you want. /gcc/os-include/inline/exec.h:1341: warning: `struct StackSwapStruct' declared inside parameter list /gcc/os-include/inline/exec.h:1424: warning: `struct SemaphoreMessage' declared inside parameter list In file included from dumpfont.c:14: /gcc/os-include/inline/graphics.h:581: warning: `struct MonitorSpec' declared inside parameter list /gcc/os-include/inline/graphics.h:742: parse error before `FindDisplayInfo' /gcc/os-include/inline/graphics.h: In function `FindDisplayInfo': /gcc/os-include/inline/graphics.h:745: parse error before `_res' /gcc/os-include/inline/graphics.h:749: `_res' undeclared (first use this function) /gcc/os-include/inline/graphics.h:749: (Each undeclared identifier is reported only once /gcc/os-include/inline/graphics.h:749: for each function it appears in.) /gcc/os-include/inline/graphics.h: At top level: /gcc/os-include/inline/graphics.h:950: parse error before `handle' /gcc/os-include/inline/graphics.h: In function `GetDisplayInfoData': /gcc/os-include/inline/graphics.h:955: parse error before `a0' /gcc/os-include/inline/graphics.h:956: `buf' undeclared (first use this function) /gcc/os-include/inline/graphics.h:957: `size' undeclared (first use this function) /gcc/os-include/inline/graphics.h:958: `tagID' undeclared (first use this function) /gcc/os-include/inline/graphics.h:959: `displayID' undeclared (first use this function) /gcc/os-include/inline/graphics.h:962: `a0' undeclared (first use this function) /gcc/os-include/inline/graphics.h: At top level: /gcc/os-include/inline/graphics.h:1747: parse error before `gelsInfo' /gcc/os-include/inline/graphics.h: In function `SetCollision': /gcc/os-include/inline/graphics.h:1747: parameter name omitted /gcc/os-include/inline/graphics.h:1752: parse error before `__asm' /gcc/os-include/inline/graphics.h:1753: parse error before `)' /gcc/os-include/inline/graphics.h:1754: parse error before `__asm' /gcc/os-include/inline/graphics.h:1757: `a1' undeclared (first use this function) /gcc/os-include/inline/graphics.h:1757: parse error before `)' Does anyone know what I'm doing wrong ? I can't build a kernel until I get this font program working. +----------------------------------+--------------------------+ ! John Shardlow | "I seem to be having ! ! john@iceberg.demon.co.uk | tremendous difficulty ! ! jshardlow@london.micrognosis.com | with my lifestyle" ! ! | - Arthur Dent ! +----------------------------------+--------------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 19 01:22:34 1994 From: mw@eunet.ch Subject: Re: Yellow screen on reboot To: rhealey@aggregate.com Cc: mw@eunet.ch, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 710 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Additional data point: It only occurs on 16M V36, 12M and 8M seem Ack. > to work just fine. AMIX seemed to be able to deal with this so > it's probably just finding the "more magic" bit and frobbing it... No, Amix doesn't deal with it either.. Amix *does* handle it when you boot there directly, ie. without going thru booting kick2.x. Try explicitly booting kick2.x with the bootmenu, and then boot into amix, the machine won't restart afterwards. That's why I thought finding a way to boot into NetBSD from V36 might be the solution. -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 Apr 19 01:36:35 1994 From: Alan Bair Subject: Re: dumpfont program To: john@iceberg.demon.co.uk Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu First I would recommend that you try the fontdumper.c instead, which allows you to select the font you want to use. It also provides some extra value settings that are required by the current console drivers. There are comments on how to compile it at the top of the code, which may also apply to dumpfont. > > I'm having problems building the dumpfont program on my Amiga. I am using > gcc to build it as follows:- > > gcc dumpfont.c -o dumpfont > > This produces the following errors: > ... deleted errors > > Does anyone know what I'm doing wrong ? I can't build a kernel until I > get this font program working. Actually you can use the default font provided, I think its called: kernel_font.default I don't like the font, but it does work. > > +----------------------------------+--------------------------+ > ! John Shardlow | "I seem to be having ! > ! john@iceberg.demon.co.uk | tremendous difficulty ! > ! jshardlow@london.micrognosis.com | with my lifestyle" ! > ! | - Arthur Dent ! > +----------------------------------+--------------------------+ > -- 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 Apr 19 04:45:00 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu, dej@eecg.toronto.edu Subject: Re: Term>1.07 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: David Jones > Where's the best place for me to FTP a non-Linuxized term more recent > than 1.07? The "master site" is tartarus.uwa.edu.au:/pub/oreillym/term, I believe. This version should compile by typing "make netbsd". As soon as I get a chance, I'm going to send (another) patch that fixes a minor problem that I previous introduced (i.e. "#ifdef amiga" should be "#ifdef NetBSD"). Also, I have another enhancement that I'd like to send the author.... Enjoy, From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 19 07:29:57 1994 To: tsarna@endicor.com (Ty Sarna) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu Subject: Re: mfs & swap problems. From: Bill Squier Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In message , Ty Sarna writes: >In article <199404180056.KAA13179@nutmeg> Arthur Hoffmann .au> writes: >> Hi, >> I found that whenever I used my /tmp directory heavily the swap >> space got recduced. Now, after I cleared the /tmp directory again the >> swapspace doesn't increase anymore. Is there any way to let the system >> know that the free /tmp (mfs) space is usable for vm again? > >Not with the current mfs, It would need a lot of work to be able to >release VM to the system. mfs is *NOT* like SunOS tmpfs. > >Also note that by default mfs uses as much memory as the partition you >mount it on! If you only have one swap partition, DON'T MOUNT MFS ON IT >WITHOUT USING THE -s FLAG TO LIMIT THE AMOUNT OF SWAP MFS USES!!! >If you don't use -s bad things can happen. This suggestion interests me, as I find that gcc compiles lock the system in direct proportion to the amount of current activity (running apps). Without forcing a huge explanation of the mfs internals (although that would be interesting) can you explain what's going on? Most NetBSD implementations that I've seen simply include a line such as: /dev/sd1b /tmp mfs rw 1 1 in their /etc/fstab. Is this incorrect for a system with only one swap partition? FYI, my system is a 33MHz '030/882 with 8M 32bit mem and a 30Mb swap partition, with mfs mounted on it via the line shown above. Thanks. --- Bill Squier (groo@menger.eecs.stevens-tech.edu) "If you can read this, you're too close" From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 10:45:48 1994 From: Andreas Heitmann To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: dumpfont program Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi ! >>>>> "Alan" == Alan Bair writes: >> Does anyone know what I'm doing wrong ? I can't build a kernel >> until I get this font program working. Alan> Actually you can use the default font provided, I think its Alan> called: kernel_font.default I don't like the font, but it Alan> does work. It doesn't work with the RETINA console. If you want to use a font working with the RETINA driver, you have to make shure that the font is sized 8x8 Pixel. Topaz 8 will do it, but kernel_font.default doesn't. Maybe someone can provide us with an 8x8 font for the next distribution ? Greetings, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 11:11:13 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: New binaries: which one ? From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Since I'm still running vmunix.744 and the 720 rootfs, I was wondering if I should switch to a new set of binaries. If so, which one should I use ? Will my X still work with the new set ? John From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 12:11:42 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "New binaries: which one ?" (Apr 19, 9:40am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , amiga@sun-lamp.cs.berkeley.edu Subject: Re: New binaries: which one ? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 19, 9:40am, John Vrolijk wrote: > Since I'm still running vmunix.744 and the 720 rootfs, I was wondering > if I should switch to a new set of binaries. You should, yes. > If so, which one should I use ? > Will my X still work with the new set ? Yes, but don't delete the Xlibs and hold a copy of the old shared-libs, too. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 14:25:10 1994 To: amiga@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga Subject: Re: Misc stuff Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 37 Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404171954.AA12993@amcu-tx.sps.mot.com>, Alan Bair writes: > > > Next, for the Retina ZIII owners. How is the card? I'm thinking about > > > > Sort of off-topic, but does the Retina Z3 have a monitor passthru and > > switch capability? I find that feature of the Picasso very attractive... > > Everything I have read, Net & AmigaWorld, indicates it does NOT have the > monitor passthru. A sidebar in AmigaWorld indicated that MacroSystems was > considering selling an external switch to handle passthru. That's true. But if you don't want to play games on your Amiga, you won't need to buy such a thing... > There are > various opions that the pasthru switching can cause signal degredation at > the higher frequencies. Switching high frequencies is always a problem, just some thoughts on this: The Retina Z3 is specified for 110MHz pixel-clock. Now think of the harmonics you need to transfer, if you want to have an acceptable "sharp" display of two adjacent pixels, one black, one white... in this situation you need a switch that is designed for frequencies somewhere >500MHz... such a beast is neither simple nor cheap. I once tested a simple external switch with my Retina, and the result was awful, one could see lots of reflections on each horziontal high-contrast edge, and the sharpness was rather poor. cu, Lutz Vieweg -- "'Wozu bin ich noch am leben', sagte er, und stand im Regen. Ist es nur fuer Gottes Segen - oder soll man so nicht reden? Wie sich doch die Tage gleichen - ist das nicht nur ein schlechtes Zeichen? Kann denn sowas gut nur enden, ohne hier mein Hirn zu schaenden?" ('Schliessmuskel' / "Wozu?") From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 15:59:11 1994 From: Andreas Heitmann To: amiga@sun-lamp.cs.berkeley.edu Subject: Xlibs (was: New binaries: which one ?) Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "Markus" == Markus Illenseer writes: Markus> Yes, but don't delete the Xlibs and hold a copy of the Markus> old shared-libs, too. Maybe we should recompile the Xlibs, because libXt.* for example isn't working very well. The library was compiled without the SUNSHLIB flag and therefore the function XtInherit gives an error message. I can provide a working (shared) libXt, but I think someone should compile the complete set of libraries. Greetings, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) "The principles of aerodynamics show that it is impossible for a wing area of 0,7cm^2 to support, in flight, a gross weight of 1,2g. The humble-bee, blissfully ignoring of this fact, simply flies." _facinGravity_, Chandelier From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 19 16:18:17 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: mfs & swap problems. To: groo@menger.eecs.stevens-tech.edu (Bill Squier) Cc: tsarna@endicor.com, amiga-dev@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 834 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Most NetBSD implementations that I've seen simply include a line such > as: > > /dev/sd1b /tmp mfs rw 1 1 > > in their /etc/fstab. Is this incorrect for a system with only one > swap partition? Yes It should be comethign like /dev/sd6b /tmp mfs rw,-s10240 you don't want to backup your mfs so the 1 1 is not needed and you don't want the backing store for the fs to be you entire swap because then where would the system find backing store for real memory? > > FYI, my system is a 33MHz '030/882 with 8M 32bit mem and a 30Mb swap > partition, with mfs mounted on it via the line shown above. try working with a /dev/sd6b /tmp mfs rw,-s28672 that leaves 16M for swap and gives the rest to mfs. > Bill Squier (groo@menger.eecs.stevens-tech.edu) Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 19 16:42:09 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Color X To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 618 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > ----------- snip ------- snap ------- > if (gp->g_display.gd_colors == 2) > printf("monochrome"); > else > printf("%d color", gp->g_display.gd_colors); Is correct. > ----------- snip ------- snap ------- > > switch(gp->g_display.gd_colors) > { > case 0: > printf("disabled"); > break; > case 1: > printf("hm, monocolor"); > break; > case 2: > printf("monochrome"); > break; > default: > printf("%d color", gp->g_display.gd_colors); > } I haven't been in the code recently but why would the driver get this far if it isn't going to provide at least 2 colors? Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 19 18:01:14 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: mfs & swap problems. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 426 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Hi, > I found that whenever I used my /tmp directory heavily the swap > space got recduced. Now, after I cleared the /tmp directory again the > swapspace doesn't increase anymore. Is there any way to let the system > know that the free /tmp (mfs) space is usable for vm again? use a line like this in your fstab This uses 5M of swap at most for mfs. /dev/sd6b /tmp mfs rw,-s10240 > Arthur. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 18:28:07 1994 To: Andreas Heitmann Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Xlibs (was: New binaries: which one ?) <9404191101.AA09673@crunch> From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu If someone can tell me how to recompile the Xlibs I'm willing to give it a try. I don't know how long it will take on a 25Mhz 68030 ;^) What sources are needed ? John From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 19:10:23 1994 From: Danny Lepage Subject: Help needed To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1392 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have an A3000 16MHz, 2 Meg CHip, 4 Meg Fast (NTSC) with 50 Meg Quantum (Unit 6, With a 8 Meg sd6b) and 520 Meg Fujitsu (Unit 1, With 15 Meg sd0a, 230 Meg sd0d (/usr) 70 Meg sd0e (/home). I can boot in single user (Kernel 744 and 940325) but - kernel 744 in multi-user: I get MMU fault panic after executing a command at the shell prompt (at random, that is, sometimes I can 'ls', but the second 'ls' panic the kernel; generally, can't do anything without having the kernel to panic. - kernel 940325 : I can't even mount /dev/sd0a on /tmp, the machine 'freeze' after displaying the message 'exec: ????' (I don't remember the exact message but it is something about mounting the swap partition, and this is not an error message, this is the usual exec: ... displayed after doing mount -av). I use rootfs_720, (with the 940319 newfs/mount_mfs when trying the 940325 kernel). I can't find nothing in the FAQ or in the installation guide that can cure this problem. (I've tryed the vmunix.a3000.940319? but the boot process freeze after detecting my fujitsu even if I apply the binpatch required to boot with the other kernels). Can somebody tell me what I am doing wrong ? Or is it that I don't have enough memory to install NetBSD ? Thanks in advance. Danny Lepage poutine@M3iSystems.QC.CA From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 19 20:47:05 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Xlibs (was: New binaries: which one ?) To: John Vrolijk Cc: Andreas Heitmann , amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Tue, 19 Apr 1994, John Vrolijk wrote: > If someone can tell me how to recompile the Xlibs I'm willing to give > it a try. I don't know how long it will take on a 25Mhz 68030 ;^) > > What sources are needed ? First you need to get the X11R5 distribution from ftp.x.org or one of its mirrors: ftp.uu.net, gatekeeper.dec.com, etc. You need at least X11R5-tape1 and X11R5-tape2 (X11R5-tape3 is fonts). Once you have that, you need to apply all of the patches. If you want, you can grab a set of ddx files for an Amiga X server and install those. Now you get to the hard part: you need to create the proper Imake config files. I can get you a set of those. Follow the build instructions. `make World' should work properly. Finally, `make install' to install the libraries and new executables, and you're all set to create a tar file. I am waiting for X11R6, which should be out RSN. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 19 21:36:44 1994 From: DCG9367@tntech.edu Subject: XRetinaZ2 problems 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 have recently acquired a larger HD and reinstalled NetBSD. I have an A2000, GForce-040 8mb, vmunix.744 and rootfs.720. The Xretina which comes with rootfs.720 refuses to read my Xconfig and goes into a screenmode which my 1950 can't handle. The Xretina on eunet works, but has that annoying sprite in the upper corner and I can only get it to go into 640x480. Now, XretinaZ2 on eunet refuses to work. The server runs, but does not put anything into the error-log and all clients die with: cannot open display :0 I did not change anything before I installed the new Retina server, so I can't figure out what is wrong. I have /dev/grf[01] and /dev/view0[01]. What's wrong??????? David. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 01:41:24 1994 From: "Stephen J. Roznowski" To: dsnjvro@etmsun.ericsson.se, eeh@btr.btr.com Subject: Re: Xlibs (was: New binaries: which one ?) Cc: heitmann@crunch.ikp.physik.th-darmstadt.de, amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: "Eduardo E. Horvath eeh@btr.com" > If you want, you can grab a set of ddx files for an Amiga X server and > install those. > > Now you get to the hard part: you need to create the proper Imake config > files. I can get you a set of those. How about upload a diff to eunet that has the Amiga specific mods (to X11R5p26)? > > I am waiting for X11R6, which should be out RSN. > Agreed. -SR From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 02:28:27 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Xlibs (was: New binaries: which one ?) To: "Stephen J. Roznowski" Cc: dsnjvro@etmsun.ericsson.se, heitmann@crunch.ikp.physik.th-darmstadt.de, amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Tue, 19 Apr 1994, Stephen J. Roznowski wrote: > How about upload a diff to eunet that has the Amiga specific mods > (to X11R5p26)? The server ddx files and Imake files are available in Xamiga.src.tar.gz on eunet, and have been for some time. Here are some updated Imake config files. These are much cleaner and should work out of the box. You may need to change some options, like which server to build, whether to build PEX, etc. ------------------------ snip snip -------------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by btr!eeh on Tue Apr 19 16:06:38 PDT 1994 # Contents: foo netbsd.cf netbsdLib.rules netbsdLib.tmpl echo x - foo sed 's/^@//' > "foo" <<'@//E*O*F foo//' # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by btr!eeh on Tue Apr 19 16:06:38 PDT 1994 # Contents: foo netbsd.cf netbsdLib.rules netbsdLib.tmpl echo x - foo sed 's/^@//' > "foo" <<'@//E*O*F foo//' @//E*O*F foo// chmod u=rw,g=r,o=r foo echo x - netbsd.cf sed 's/^@//' > "netbsd.cf" <<'@//E*O*F netbsd.cf//' /* * SET VERSION NUMBERS BEFORE MAKING MAKEFILES */ #define OSName 4.4bsd #define OSMajorVersion 4 #define OSMinorVersion 4 #define HasGcc YES /* very useful for the server */ #define HasVoidSignalReturn NO /**/# platform: $XConsortium: bsd.cf,v 1.8 89/12/23 14:19:17 jim Exp $ /**/# operating system: OSName /***************************************************************************** * Platform-specfic parameters * *****************************************************************************/ #if OSMajorVersion >= 4 && OSMinorVersion >= 3 #define SetTtyGroup YES #endif #include #define HasBsearch YES #define BuildServer YES #define XamigaServer YES #define CppCmd /lib/cpp #define CcCmd gcc -fstrength-reduce -O2 #define StandardDefines -DNDBM #define StandardCppDefines -traditional -DNDBM #define BootstrapCFlags -DNDBM #define DirFailPrefix - #define AvoidNullMakeCommand YES /* #define BuildPexExt XamigaServer */ #define BuildPex NO /* compiler runs out of table space */ #define BuildXInputLib YES /* compiler runs out of table space */ @//E*O*F netbsd.cf// chmod u=rw,g=r,o=r netbsd.cf echo x - netbsdLib.rules sed 's/^@//' > "netbsdLib.rules" <<'@//E*O*F netbsdLib.rules//' XCOMM $XConsortium: sv4Lib.rules,v 1.8 91/07/19 15:38:53 rws Exp $ /* * SVR4 shared library rules */ #ifndef HasSharedLibraries #define HasSharedLibraries YES #endif #ifndef SharedDataSeparation #define SharedDataSeparation NO #endif #ifndef SharedCodeDef #define SharedCodeDef /**/ #endif #ifndef SharedLibraryDef #define SharedLibraryDef /**/ #endif #ifndef ShLibIncludeFile #define ShLibIncludeFile #endif #ifndef SharedLibraryLoadFlags #define SharedLibraryLoadFlags -Bshareable -Bforcearchive #endif #ifndef PositionIndependentCFlags #define PositionIndependentCFlags -fPIC #endif /* * InstallSharedLibrary - generate rules to install the shared library. */ #ifndef InstallSharedLibrary #define InstallSharedLibrary(libname,rev,dest) @@\ install:: Concat(lib,libname.so.rev) @@\ MakeDir($(DESTDIR)dest) @@\ $(INSTALL) -c $(INSTLIBFLAGS) Concat(lib,libname.so.rev) $(DESTDIR)dest @@\ $(INSTALL) -c $(INSTLIBFLAGS) Concat3(lib,libname,_pic.a) $(DESTDIR)dest @@\ $(RM) Concat($(DESTDIR)dest/lib,libname.so) @@\ $(LN) Concat(lib,libname.so.rev) Concat($(DESTDIR)dest/lib,libname.so) #endif /* InstallSharedLibrary */ /* * InstallSharedLibraryData - generate rules to install the shared library data */ #ifndef InstallSharedLibraryData #define InstallSharedLibraryData(libname,rev,dest) #endif /* InstallSharedLibraryData */ /* * SharedLibraryTarget - generate rules to create a shared library; * build it into a different name so that we do not hose people by having * the library gone for long periods. */ #ifndef SharedLibraryTarget #define SharedLibraryTarget(libname,rev,solist,down,up) @@\ AllTarget(Concat(lib,libname.so.rev)) @@\ @@\ Concat(lib,libname.so.rev): Concat3(lib,libname,.a) solist @@\ $(RM) $@~ @@\ (cd down; $(AR) Concat3(../lib,libname,_pic.a) `lorder solist | tsort` ) @@\ $(RANLIB) Concat3(lib,libname,_pic.a) @@\ $(LD) $(SHLIBLDFLAGS) -o $@~ Concat3(lib,libname,_pic.a) @@\ $(RM) $@ @@\ $(MV) $@~ $@ @@\ $(RM) Concat(lib,libname.so) @@\ $(LN) $@ Concat(lib,libname.so) @@\ @@\ clean:: @@\ $(RM) Concat(lib,libname.so.rev) Concat(lib,libname.so) Concat3(lib,libname,_pic.a) #endif /* SharedLibraryTarget */ /* * SharedLibraryDataTarget - generate rules to create shlib data file; */ #ifndef SharedLibraryDataTarget #define SharedLibraryDataTarget(libname,rev,salist) #endif /* SharedLibraryTarget */ @//E*O*F netbsdLib.rules// chmod u=rw,g=r,o=r netbsdLib.rules echo x - netbsdLib.tmpl sed 's/^@//' > "netbsdLib.tmpl" <<'@//E*O*F netbsdLib.tmpl//' XCOMM $XConsortium: sv4Lib.tmpl,v 1.4 91/07/19 15:38:11 rws Exp $ /* * SVR4 shared library template */ #ifndef SharedXlibRev #define SharedXlibRev 5.1 #endif #ifndef SharedOldXRev #define SharedOldXRev 5.1 #endif #ifndef SharedXtRev #define SharedXtRev 5.1 #endif #ifndef SharedXawRev #define SharedXawRev 5.1 #endif #ifndef SharedXmuRev #define SharedXmuRev 5.1 #endif #ifndef SharedXextRev #define SharedXextRev 5.1 #endif #ifndef SharedXinputRev #define SharedXinputRev 5.1 #endif SHLIBLDFLAGS = SharedLibraryLoadFlags PICFLAGS = PositionIndependentCFlags /* * and now a little bit of magic for using imake without source tree; if we * are using shared libraries, we really do not need to depend on anything */ #if SharedLibXext DEPEXTENSIONLIB = /* _UseCat($(USRLIBDIR),$(EXTENSIONSRC)/lib,/libXext.sa.$(SOXEXTREV)) */ EXTENSIONLIB = _Use(-lXext,-L$(EXTENSIONSRC)/lib -lXext) #endif #if SharedLibX DEPXLIB = $(DEPEXTENSIONLIB) /* _UseCat($(USRLIBDIR),$(XLIBSRC),/libX11.sa.$(SOXLIBREV)) */ XLIB = $(EXTENSIONLIB) _Use(-lX11,-L$(XLIBSRC) -lX11) #endif #if SharedLibXmu /* SVR4 shared libraries are deficient in link semantics */ DEPXMULIB = /* _UseCat($(USRLIBDIR),$(XMUSRC),/libXmu.sa.$(SOXMUREV)) */ XMULIBONLY = _Use(-lXmu,-L$(XMUSRC) -lXmu) XMULIB = $(XMULIBONLY) -z nodefs #ifndef XawClientLibs #define XawClientLibs $(XAWLIB) $(XMULIBONLY) $(XTOOLLIB) $(XLIB) #endif #endif #if SharedOldLibX DEPOLDXLIB = /* _UseCat($(USRLIBDIR),$(OLDXLIBSRC),/liboldX.sa.$(SOOLDXREV)) */ OLDXLIB = _Use(-loldX,-L$(OLDXLIBSRC) -loldX) #endif #if SharedLibXt DEPXTOOLLIB = /* _UseCat($(USRLIBDIR),$(TOOLKITSRC),/libXt.sa.$(SOXTREV)) */ XTOOLLIB = _Use(-lXt,-L$(TOOLKITSRC) -lXt) #endif #if SharedLibXaw DEPXAWLIB = /* _UseCat($(USRLIBDIR),$(AWIDGETSRC),/libXaw.sa.$(SOXAWREV)) */ XAWLIB = _Use(-lXaw,-L$(AWIDGETSRC) -lXaw) #endif #if SharedLibXinput DEPXILIB = /* _UseCat($(USRLIBDIR),$(XILIBSRC),/libXi.sa.$(SOXINPUTREV)) */ XILIB = _Use(-lXi,-L$(XILIBSRC) -lXi) #endif @//E*O*F netbsdLib.tmpl// chmod u=rw,g=r,o=r netbsdLib.tmpl exit 0 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 20 03:37:25 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: mfs & swap problems. Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <94Apr18.234954edt.5173@menger.eecs.stevens-tech.edu> Bill Squier writes: > This suggestion interests me, as I find that gcc compiles lock the > system in direct proportion to the amount of current activity (running > apps). Without forcing a huge explanation of the mfs internals > (although that would be interesting) can you explain what's going on? Yes, the Net/2 VM system overcommits memory, that is it will allocate memory to processes for which it doesn't have backing store (swap space). As processes modify copy-on-write pages or otherwise cause the VM system to actually give them the memory they allocated, swap is used up. If the vm system has overcommited and a process needs more when there is no swap left, the only two options the system has are to crash (as Net/2 and NetBSD do) or kill process to free up memory (as FreeBSD) does. Neither are really attractive options, but by that point it's too late to do anything else. As I understand it, mfs simply allocates as much memory as you tell it, by default this is the size of the partition you mount it on, unless you specify -s. As you use mfs, it will actually recieve memory from the system, but can't give it back (because in fact it's already allocate the whole thing -- as far as it knows, it already owns all of it). So, it uses up swap space that it doesn't give back, and generally exacerbates the overcommit situation. If you're using a lot of swap and a lot of /tmp (as when building with gcc), you're much more likely to run out of swap. > Most NetBSD implementations that I've seen simply include a line such > as: > > /dev/sd1b /tmp mfs rw 1 1 > > in their /etc/fstab. Is this incorrect for a system with only one > swap partition? No, it should be something like: /dev/sd1b /tmp mfs rw,-sX 0 0 Where X is a number (in blocks) that leaves you a enough of your swap partiton to be useful. The last two numbers should be zero, see fstab(5). The two fields mean frequencey between dumps (backups) and pass in which to fsck them. You don't want to back up or fsck mfs, so set them to zero. I think the reason so many people mount /tmp with no -s is simply because they don't realize how mfs works. I too thought it was like sun's tmpfs or AmigaDOS RAM:, and dynamicly grew/shrunk. In actually it's like RAD:, and by default allocates ALL of your swap if you only have one swap partition and don't use -s to limit it's usage. When I found out how mfs really worked, I added -s and my system has been *much* more stable ever since. -- 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 Apr 20 03:40:25 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: dumpfont program Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404190730.AA27462@crunch> Andreas Heitmann writes: > It doesn't work with the RETINA console. If you want to use a font > working with the RETINA driver, you have to make shure that the font > is sized 8x8 Pixel. Topaz 8 will do it, but kernel_font.default > doesn't. Maybe someone can provide us with an 8x8 font for the next > distribution ? There must be some pleasant-looking 8x8 freeware/PD fonts somewhere... maybe Pearl or one of the other topaz-replacements from the 1.3 days? It would be good to find one and make it kernel_font.c.distrib (or just make it kernel_font.c, since you can still replace it if you want a custom font). -- 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 Apr 20 03:53:33 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Xlibs (was: New binaries: which one ?) Sender: owner-amiga@sun-lamp.cs.berkeley.edu How about our underused amiga-x group for followups? -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 07:28:29 1994 From: clin@flute.aix.calpoly.edu Subject: Newbie question To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 486 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I've just install NetBSD on my A3000. I'm using vmunix744, and rootfs 720. Everything has been fine so far except for multiusr mode. I've installed all the necessary binaries in the /usr directory (the old ones, not the ones dated 940319, which is not complete). I used vipw to edit the root's pw and add a few user of my own. But when I tried to login, I keep getting login incorrect, when I'm sure that I'm entering the correct pw. Anyone had the same problem before? Jeff :) From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 09:21:49 1994 To: "Eduardo E. Horvath eeh@btr.com" Cc: amiga@sun-lamp.cs.berkeley.edu, heitmann@crunch.ikp.physik.th-darmstadt.de Subject: Re: Xlibs (was: New binaries: which one ?) From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've got approximately 245 MB of free disk space that I can temporarily use for this purpose. I also got the complete X11R5 mit-dist on my Sparc2 which I can put on a tape to take home with me. I got the XRetinaZ2 sources. While writing this, I've just received your Imake config files, thanx. Do you think 245 MB of disk space is enough to try ro recompile the X libs ? John From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed Apr 20 15:42:05 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Cc: "Eduardo E. Horvath eeh@btr.com" Subject: Recompiling Xlibs etc. From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Since I will make an attempt to recompile X11R5 including the libs, I need some info. I've got 245 MB of harddisk space that I can use. Which set of binaries should I use ( /bin, /usr/bin, /usr/include etc ) ? I've got the 720 binaries and includes and I'm running vmunix.744 Which binaries are stable and reliable to be used for this job ? Or can I use the ones that came with the rootfs_720 stuff ? For the Retina X-server I've got the source for XRetinaZ2, is that ok ?? Any info is appreciated. PS: I haven't send this to amiga@sun-lamp.cs.berkeley.edu anymore since someone suggested to use amiga-x@sun-lamp.cs.berkeley.edu for this kind of discussion. John From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 20 15:56:53 1994 From: Arthur Hoffmann Subject: Bug in swap? To: 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: 1476 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi I recently asked about if it was possible to get space back from /tmp, so that it could be used by vm again. Thanks for all the information I got :) Well I was told it was not possible, so what I did I simply split my 32M partition which was used by mfs (and swap) into 2 partitions. I wanted to make sure that swap and /tmp work independently. I put he following lines into my /etc/fstat file: /dev/sd6b none swap sw 0 0 /dev/sd6g /tmp mfs rw 0 0 1 partition pureley for swap and one pureley for /tmp. Also I changed my kernel configuration file in /usr/src/sys/arch/amiga/conf/MYCONF to work with this setup. The relevant lines look like this: #options GENERIC config netbsd root on sd6a swap on sd6b #config netbsd swap generic Then I did config MYCONF; cd ../compile/MYCONF; make depend; make. After the reboot I checked my system, df showed that /tmp was mounted and had the correct amount of memory, Also swapinfo showed that the swap partition was correctly configured. Now comes the problem: ====================== When I copied a large file to /tmp my swap space got less!!! I copied a ~7M file to /tmp, df showed /tmp space was reduced by that amount, but swapinfo showed that it was reduced as well!! The swapspace was reduced by ~ twice as much as the file size. Any Ideas? Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 20 18:57:22 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Color X" (Apr 19, 9:16am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chopps@emunix.emich.edu (Chris Hopps), markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: Color X Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 19, 9:16am, Chris Hopps wrote: > Subject: Re: Color X > > ----------- snip ------- snap ------- > > if (gp->g_display.gd_colors == 2) > > printf("monochrome"); > > else > > printf("%d color", gp->g_display.gd_colors); > > Is correct. This is the original code. > > ----------- snip ------- snap ------- > > > > switch(gp->g_display.gd_colors) > > { > > case 0: > > printf("disabled"); > > break; > > case 1: > > printf("hm, monocolor"); > > break; > > case 2: > > printf("monochrome"); > > break; > > default: > > printf("%d color", gp->g_display.gd_colors); > > } > > I haven't been in the code recently but why would the driver get this far > if it isn't going to provide at least 2 colors? When init_something() (ie. init_rt()) fails, it will fallback to ECS. And if it fails to report the size (non-initialized) and depth, we should consider to report the card/display as 'disabled' at least. My current Picasso-grf-driver doesn't initialize anything yet and thus should be considered as disabled. And if gp->g_display.gd_colors == 2 (as in original code) we don't have a monochrome display, but a 4 color display. This no flame, just discussion, ok? :) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 19:12:32 1994 From: Hubert Feyrer To: amiga@sun-lamp.cs.berkeley.edu, clin@flute.aix.calpoly.edu Subject: Re: Newbie question Sender: owner-amiga@sun-lamp.cs.berkeley.edu > ... I used vipw to edit the root's pw ... You have to set passwords via "passwd", with vipw you have to enter encrypoted passwords, better don't touch! :) Hope this helps, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 19:17:38 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Xlibs (was: New binaries: which one ?)" (Apr 19, 1:01pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Andreas Heitmann , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Xlibs (was: New binaries: which one ?) Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 19, 1:01pm, Andreas Heitmann wrote: > Subject: Xlibs (was: New binaries: which one ?) > >>>>> "Markus" == Markus Illenseer writes: > > Markus> Yes, but don't delete the Xlibs and hold a copy of the > Markus> old shared-libs, too. > > Maybe we should recompile the Xlibs, because libXt.* for example isn't > working very well. The library was compiled without the SUNSHLIB flag > and therefore the function XtInherit gives an error message. I can > provide a working (shared) libXt, but I think someone should compile > the complete set of libraries. Got my CD300 today and have an older DEC-Freeware-CD with X11 on it, guess what i will do next weekend :) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 20 19:50:29 1994 Subject: Re: Bug in swap? From: David Jones To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > /dev/sd6b none swap sw 0 0 > /dev/sd6g /tmp mfs rw 0 0 > > Any Ideas? Forgive me for asking, but if you are going to have a completely separate partition for /tmp, then why not just make it a ufs partition, and mount it normally? /dev/sd6g /tmp ufs rw 0 0 -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 19:52:15 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Xlibs (was: New binaries: which one ?) To: John Vrolijk Cc: amiga@sun-lamp.cs.berkeley.edu, heitmann@crunch.ikp.physik.th-darmstadt.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Wed, 20 Apr 1994, John Vrolijk wrote: > While writing this, I've just received your Imake config files, thanx. > Do you think 245 MB of disk space is enough to try ro recompile the X libs ? Should be. I managed to compile the libs and server in around 80MB. The X apps take more room, though. ========================================================================= 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 Wed Apr 20 20:16:06 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Xlibs (was: New binaries: which one ?)" (Apr 20, 8:32am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , "Eduardo E. Horvath eeh@btr.com" Subject: Re: Xlibs (was: New binaries: which one ?) Cc: amiga@sun-lamp.cs.berkeley.edu, heitmann@crunch.ikp.physik.th-darmstadt.de Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 20, 8:32am, John Vrolijk wrote: > I got the XRetinaZ2 sources. What for? > While writing this, I've just received your Imake config files, thanx. > Do you think 245 MB of disk space is enough to try ro recompile the X libs ? Yes, definitely enough. I belive 50MB are suficient even. If you have a CDROM with X on it, you can even make softlinks to the sources without copying them. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 20 20:17:42 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Xlibs (was: New binaries: which one ?)" (Apr 19, 4:10pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Eduardo E. Horvath eeh@btr.com" , "Stephen J. Roznowski" Subject: Re: Xlibs (was: New binaries: which one ?) Cc: dsnjvro@etmsun.ericsson.se, heitmann@crunch.ikp.physik.th-darmstadt.de, amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 19, 4:10pm, "Eduardo E. Horvath eeh@btr.com" wrote: > #define CcCmd gcc -fstrength-reduce -O2 That all? No FPU-support required? > /* #define BuildPexExt XamigaServer */ > #define BuildPex NO /* compiler runs out of table space */ > #define BuildXInputLib YES /* compiler runs out of table space */ Oh, i couldn't buildt Pex yet due lack of space on my drive :-) Does any of the current Amiga-Servers support Pex yet? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 21 00:28:37 1994 From: Eric Augustine Subject: USL and FreeBSD To: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 614 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have just been informed that the FreeBSD guys have been given the go-ahead to release their 1.1g by USL and it appears also that a CD release is soon to follow. The person who told me this has been involved in the FreeBSD /X386 thing for a while and seems to be a good source on this. The reasoning behind the okay might be that this should be the last release with any Net/2 stuff though I am not sure. I mentioned this because I know there have been likewise problems affecting us and I am not sure if USL is or is not the main culprit and if this change might mean a similar change for us. - Eric. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 21 00:34:48 1994 From: Hartmut Kuehn Subject: Supra and Oktagon ??!! 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: 800 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi ! Are there any news concering the implementation of the Supra WordSync Series 3 Controller in NetBSD ?? Or better, does anyone plan to implement the Oktagon 2008 controller, which seems to be the coolest controller nowadays ??? Bye ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@cs.tu-berlin.de * * (or kuehaaaf@w250zrz.zrz.tu-berlin.de) * * BITNET: KUEHN@DB0TUI11.BITNET * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 21 21:45:45 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: Current kernel sources: where can I get them? From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I've downloaded the binaries from 940319 from ftp.eunet.ch, I hope they are ok for my attempt at recompiling X. Now I need a more newer kernel. Where can I get the current sources for the kernel that works with the 940319 binaries ? John From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 21 21:51:45 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Supra and Oktagon ??!!" (Apr 20, 5:41pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Hartmut Kuehn , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Supra and Oktagon ??!! Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 20, 5:41pm, Hartmut Kuehn wrote: > Are there any news concering the implementation of > the Supra WordSync Series 3 Controller in NetBSD ?? > Or better, does anyone plan to implement the > Oktagon 2008 controller, which seems to be the No support for any NCR-based Adapter yet working, and i don't share your opinion on that 'coolest' adapter. Oktagon is a PIO-Adapter with no DMA capabilities. Thus it is quite hard to implement service for this one. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 21 21:59:26 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "USL and FreeBSD" (Apr 20, 2:21pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Eric Augustine , amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) Subject: Re: USL and FreeBSD Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 20, 2:21pm, Eric Augustine wrote: > I have just been informed that the FreeBSD guys have been > given the go-ahead to release their 1.1g by USL and it > appears also that a CD release is soon to follow. The > person who told me this has been involved in the FreeBSD > /X386 thing for a while and seems to be a good source on > this. The reasoning behind the okay might be that this > should be the last release with any Net/2 stuff though I > am not sure. I would like to have an affirmative answer on that, or a pointer to an official source. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 21 22:02:07 1994 To: amiga@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.RoBIN.de!mania!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga Subject: Re: dumpfont program Distribution: robin Organization: The Funny Farm X-Newsreader: Arn V1.00 alpha rel3 Lines: 28 Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404190730.AA27462@crunch>, Andreas Heitmann writes: > Alan> Actually you can use the default font provided, I think its > Alan> called: kernel_font.default I don't like the font, but it > Alan> does work. > > It doesn't work with the RETINA console. If you want to use a font > working with the RETINA driver, you have to make shure that the font > is sized 8x8 Pixel. No, the Retina driver also supports fonts with different sizes, but then you need to create your own text-mode-monitor-definition, and compile it into the kernel. The built-in monitor-definition all use the default "kernel_font". One may also modify the existing definitions just to use another font, just some parameters need adjustment then. I didn't know that the currently distributed kernel_font.default was not an 8x8 font, is has been of this size when the first Retina console device was written. cu, Lutz Vieweg -- "Breite Hueften, schwerer Gang - so stolpern sie die Strasse lang. Fleischig Hintern, Pustelpo, Frauenblaeh im Damenklo. Jesuslatschen, Birkenstock, darueber einen Trachtenrock. Frotteeslip mit Bremsbelag, luenkern bringt es an den Tag." ('Schliessmuskel' / "Hamminkelner Maedels") From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 21 23:09:00 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: Supra and Oktagon ??!! Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 21, 11:56am, Markus Illenseer wrote: > On Apr 20, 5:41pm, Hartmut Kuehn wrote: > > Are there any news concering the implementation of > > the Supra WordSync Series 3 Controller in NetBSD ?? > > Or better, does anyone plan to implement the > > Oktagon 2008 controller, which seems to be the > > No support for any NCR-based Adapter yet working, and i don't share > your opinion on that 'coolest' adapter. Oktagon is a PIO-Adapter > with no DMA capabilities. Thus it is quite hard to implement service > for this one. I beg to differ... The current kernel has support for the Supra Wordsync (series 2, I think), CSA 12 Gauge, IVS Vector, and my home-built SCSI board. I'm not certain about the status of the CSA 12 Gauge and the IVS Vector support, since I don't have either of them. The Supra Wordsync was running on my A2000 using pseudo-DMA, but might possibly not work on an A3000. It should work without using pseudo-DMA, although a bit slowly. My homebuilt SCSI board also works quite well with pseudo-DMA. IVS Trumpcard and Trumpcard Pro support is probably very close. Supra Wordsync series 3 should be fairly easy to add basic support (i.e. programmed-IO only). Also, I have been running another NCR-based adapter and that support has been in NetBSD for a number of months - the Zeus SCSI uses an NCR chip (the 53C710) :-). 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-x@sun-lamp.cs.berkeley.edu Thu Apr 21 23:18:17 1994 From: Andreas Heitmann To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Current kernel sources: where can I get them? Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu >>>>> "John" == John Vrolijk writes: John> Hi, I've downloaded the binaries from 940319 from John> ftp.eunet.ch, I hope they are ok for my attempt at John> recompiling X. Now I need a more newer kernel. Where can I John> get the current sources for the kernel that works with the John> 940319 binaries ? The current sources are, for example on ftp.hrz.uni-kassel.de. They are mirrored daily from sun-lamp.cs.berkeley.edu and can be transferred via the sup protocol. The server mirrors the releases ksrc-amiga, ksrc-common and src from the current collection of sun-lamp. The parameters for the supfile are: host=ftp.hrz.uni-kassel.de hostbase=/home/aFTP/ftp/pub/machines/amiga/NetBSD release=ksrc-amiga release=ksrc-common release=src If you need more details, please consult the sup manual pages or send mail to me. Greetings, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) I have no plants in my house. They won't live for me. Some of them don't even wait to die, they commit suicide. I once came home [and] found one hanging from a macrame noose, the pot kicked out from underneath. --Jerry Seinfeld From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 22 01:40:16 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: Some more fd.c patches Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Here are some more fd.c patches for anyone playing with the floppy driver. These include the patches previously posted by Ty Sarna. Also included are changes to autoconf.c and swapgeneric.c that should allow booting using the floppy drive as the root file system. [The diffs for autoconf.c doesn't have the correct line numbers, so you may have to make these changes manually.] The patches to fd.c provides the following: - Working support for HD drives. - The delay() routine uses the DELAY() function instead of a counted loop, so delay timing should be CPU-independent. It works on my 25Mhz 68040 and 33Mhz 68040 systems. [The DELAY() routine seems to be quite a bit off for large delays, so I have a "fudge-factor" multiplier that may need to be tweaked a bit.] - Writes seem to work reliably now. I finally tracked down the problem I was having that resulted in bad tracks. The Fdopen() routine called fd_probe every time, and fd_probe called get_drive_id(). Get_drive_id() deselects the drive - at times during the middle of the DMA write! The crude fix I've got just skips calling fd_probe() if a drive is currently selected. - The drive type values are now "inverted" so they match the definitions in the AmigaDOS disk resource includes. - The driver will retry the track read if an error is detected. - When writing to the floppy, if the write begins on the first sector of the track and will be writing the entire track, the old data isn't read off the disk since it is just going to be overwritten anyway. This allows a "poor man's format" to be done using dd: dd if=/dev/zero of=/dev/rfd0 bs=22b count=80 [for DD disks; bs=44b for HD disks]. - The side-delay and settle-delay value appear to have been reversed, so the entries in the drive_types table have been swapped. - The ADKF_MFMPREC flag wasn't being set, which I think is supposed to be set for MFM recorded disks. [hackdisk.device and trackdisk.device also set this.] - The disk label should report 300rpm for DD drives and 150RPM for HD drives. Michael diff -cr /mnt/src/sys/arch/amiga/amiga/autoconf.c /opt/sys/arch/amiga/amiga/autoconf.c *** /mnt/src/sys/arch/amiga/amiga/autoconf.c Mon Apr 11 09:52:56 1994 --- /opt/sys/arch/amiga/amiga/autoconf.c Sun Apr 10 19:10:55 1994 *************** *** 971,977 **** static char devname[][2] = { 0,0, /* 0 = ct */ 0,0, /* 1 = xx */ ! 'r','d', /* 2 = rd */ 0,0, /* 3 = sw */ 's','d', /* 4 = sd */ }; --- 1008,1014 ---- static char devname[][2] = { 0,0, /* 0 = ct */ 0,0, /* 1 = xx */ ! 'f','d', /* 2 = fd */ 0,0, /* 3 = sw */ 's','d', /* 4 = sd */ }; diff -cr /mnt/src/sys/arch/amiga/amiga/swapgeneric.c /opt/sys/arch/amiga/amiga/swapgeneric.c *** /mnt/src/sys/arch/amiga/amiga/swapgeneric.c Mon Feb 28 10:55:35 1994 --- /opt/sys/arch/amiga/amiga/swapgeneric.c Sun Apr 10 19:07:36 1994 *************** *** 58,64 **** }; int dmmin, dmmax, dmtext; ! /*extern struct driver rddriver;*/ extern struct driver sddriver; extern struct amiga_ctlr amiga_cinit[]; extern struct amiga_device amiga_dinit[]; --- 58,64 ---- }; int dmmin, dmmax, dmtext; ! extern struct driver fddriver; extern struct driver sddriver; extern struct amiga_ctlr amiga_cinit[]; extern struct amiga_device amiga_dinit[]; *************** *** 68,74 **** char *gc_name; dev_t gc_root; } genericconf[] = { ! /* { (caddr_t)&rddriver, "rd", makedev(2, 0), },*/ { (caddr_t)&sddriver, "sd", makedev(4, 0), }, { 0 }, }; --- 68,74 ---- char *gc_name; dev_t gc_root; } genericconf[] = { ! { (caddr_t)&fddriver, "fd", makedev(2, 0), }, { (caddr_t)&sddriver, "sd", makedev(4, 0), }, { 0 }, }; diff -cr /mnt/src/sys/arch/amiga/dev/fd.c /opt/sys/arch/amiga/dev/fd.c *** /mnt/src/sys/arch/amiga/dev/fd.c Fri Apr 8 10:12:49 1994 --- /opt/sys/arch/amiga/dev/fd.c Wed Apr 20 22:45:56 1994 *************** *** 109,117 **** #define DSKLEN_WRITE (1<<14) /* drive type values */ ! #define FD_NONE 0x00000000 ! #define FD_DD_3 0xffffffff /* double-density 3.5" (880K) */ ! #define FD_HD_3 0x55555555 /* high-density 3.5" (1760K) */ struct fd_type { int id; --- 109,118 ---- #define DSKLEN_WRITE (1<<14) /* drive type values */ ! #define FD_NONE 0xffffffff ! #define FD_DD_3 0x00000000 /* double-density 3.5" (880K) */ ! #define FD_HD_3 0xaaaaaaaa /* high-density 3.5" (1760K) */ ! #define FD_DD_5 0x55555555 /* double-density 5.25" (440K) */ struct fd_type { int id; *************** *** 120,125 **** --- 121,127 ---- int heads; int read_size; int write_size; + int gap_size; int sect_mult; int precomp1; int precomp2; *************** *** 129,137 **** }; struct fd_type drive_types[] = { ! /* id name tr he rdsz wrsz sm pc1 pc2 sd st st */ ! { FD_DD_3, "DD 3.5", 80, 2, 14716, 13630, 1, 80, 161, 3, 18, 1 }, ! { FD_HD_3, "HD 3.5", 80, 2, 29432, 27260, 2, 80, 161, 3, 18, 1 }, { FD_NONE, "No Drive", 0, } }; int num_dr_types = sizeof(drive_types) / sizeof(drive_types[0]); --- 131,140 ---- }; struct fd_type drive_types[] = { ! /* id name tr he rdsz wrsz gap sm pc1 pc2 sd st st */ ! { FD_DD_3, "DD 3.5\"", 80, 2, 14716, 13630, 414, 1, 80, 161, 3, 2, 18 }, ! { FD_HD_3, "HD 3.5\"", 80, 2, 29432, 27260, 828, 2, 80, 161, 3, 2, 18 }, ! { FD_DD_5, "DD 5.25\"",40, 2, 14716, 13630, 414, 1, 40, 80, 3, 2, 18 }, { FD_NONE, "No Drive", 0, } }; int num_dr_types = sizeof(drive_types) / sizeof(drive_types[0]); *************** *** 313,321 **** long cnt, inner; int val; ! for (cnt = 0; cnt < delay_ms; cnt++) ! for (inner = 0; inner < 500; inner++) ! val += inner * cnt; return(val); } --- 316,322 ---- long cnt, inner; int val; ! DELAY (delay_ms * 1000 * 25); /* NOTE: DELAY seems to run too fast */ return(val); } *************** *** 336,345 **** fdu_t fdu; { int i; - int cnt; /* XXXX not used? */ - cnt = 0; /* XXXX not used? */ - /* deselect all drives */ for (i = 0; i < DRVS_PER_CTLR; i++) DESELECT(SELMASK(i)); --- 337,343 ---- *************** *** 459,464 **** --- 457,464 ---- /* set known values */ fd->cyl = 0; + + delay (fd->ft->settle_time); } /* *************** *** 472,478 **** { int cyl, side; int dir, cnt; - int delay_time; cyl = track >> 1; side = (track % 2) ^ 1; --- 472,477 ---- *************** *** 494,504 **** if (cnt) { while (cnt) { - delay_time = fd->ft->step_delay; - if (dir != fd->dir) - delay_time += fd->ft->settle_time; fd_step(); ! delay(delay_time); --cnt; } delay(fd->ft->settle_time); --- 493,500 ---- if (cnt) { while (cnt) { fd_step(); ! delay(fd->ft->step_delay); --cnt; } delay(fd->ft->settle_time); *************** *** 605,615 **** track = fd->buf_track; /* gap space */ ! for (cnt = 0; cnt < 414; cnt++) *raw++ = 0xaaaaaaaa; /* sectors */ ! for (cnt = 0; cnt < 11; cnt++) { *raw = 0xaaaaaaaa; correct(raw); ++raw; --- 601,611 ---- track = fd->buf_track; /* gap space */ ! for (cnt = fd->ft->gap_size; cnt; cnt--) *raw++ = 0xaaaaaaaa; /* sectors */ ! for (cnt = 0; cnt < fd->sects; cnt++) { *raw = 0xaaaaaaaa; correct(raw); ++raw; *************** *** 616,622 **** *raw++ = 0x44894489; ! format = 0xff000000 | (track << 16) | (cnt << 8) | (11 - cnt); csum = encode_long(format,raw); raw += 2; --- 612,618 ---- *raw++ = 0x44894489; ! format = 0xff000000 | (track << 16) | (cnt << 8) | (fd->sects - cnt); csum = encode_long(format,raw); raw += 2; *************** *** 628,635 **** --- 624,635 ---- csum = 0; encode_block(raw+2, data + cnt * 512, 512, &csum); csum = encode_long(csum, raw); + correct (raw+2); raw += 256 + 2; } + *raw = 0xaaa80000; + correct(raw); + } #define get_word(raw) (*(u_short *)(raw)) *************** *** 646,652 **** /* * scan_sync - looks for the next start of sector marked by a sync. When ! * sector = 10, can't be certain of a starting sync. */ u_long scan_sync(raw, end, sect) --- 646,652 ---- /* * scan_sync - looks for the next start of sector marked by a sync. When ! * sect != 0, can't be certain of a starting sync. */ u_long scan_sync(raw, end, sect) *************** *** 655,661 **** { u_short data; ! if (sect != 10) { while (raw < end) { data = get_word(raw); if (data == 0x4489) --- 655,661 ---- { u_short data; ! if (sect == 0) { while (raw < end) { data = get_word(raw); if (data == 0x4489) *************** *** 696,702 **** end = raw + fd->ft->read_size; for (scnt = fd->sects-1; scnt >= 0; scnt--) { ! if ((raw = scan_sync(raw, end, scnt)) == 0) { /* XXXX */ printf("can't find sync for sector %d\n", scnt); return(1); --- 696,702 ---- end = raw + fd->ft->read_size; for (scnt = fd->sects-1; scnt >= 0; scnt--) { ! if ((raw = scan_sync(raw, end, scnt == fd->sects-1)) == 0) { /* XXXX */ printf("can't find sync for sector %d\n", scnt); return(1); *************** *** 774,780 **** if (data_csum != csum) { printf( ! "MFM_DATA: f=%d t=%d s=%d sn=%d sc=%d %ld, %ld\n", format, tnum, sect, snext, scnt, data_csum, csum); return(MFM_DATA); } --- 774,780 ---- if (data_csum != csum) { printf( ! "MFM_DATA: f=%d t=%d s=%d sn=%d sc=%d %lx, %lx\n", format, tnum, sect, snext, scnt, data_csum, csum); return(MFM_DATA); } *************** *** 791,807 **** int unit; { u_long id; ! int i; id = 0; /* loop and read disk ID */ ! for (i = 0; i < 32; i++) { SELECT(SELMASK(unit)); /* read and store value of DSKRDY */ ! id <<= 1; /* XXXX 0 << 1? */ ! id |= (ciaa.pra & CIAA_PRA_RDY) ? 0 : 1; DESELECT(SELMASK(unit)); } --- 791,807 ---- int unit; { u_long id; ! u_long id_bit; id = 0; /* loop and read disk ID */ ! for (id_bit = 0x80000000; id_bit; id_bit >>= 1) { SELECT(SELMASK(unit)); /* read and store value of DSKRDY */ ! if (ciaa.pra & CIAA_PRA_RDY) ! id |= id_bit; DESELECT(SELMASK(unit)); } *************** *** 811,818 **** get_drive_id(unit) int unit; { ! int i, t; ! u_long id; u_char mask1, mask2; volatile u_char *a_ptr; volatile u_char *b_ptr; --- 811,818 ---- get_drive_id(unit) int unit; { ! int t; ! u_long id, id_bit; u_char mask1, mask2; volatile u_char *a_ptr; volatile u_char *b_ptr; *************** *** 830,839 **** *b_ptr &= mask1; *b_ptr |= mask2; ! for (i = 0; i < 32; i++) { *b_ptr &= mask1; ! t = (*a_ptr) & CIAA_PRA_RDY; ! id = (id << 1) | (t ? 0 : 1); *b_ptr |= mask2; } --- 830,839 ---- *b_ptr &= mask1; *b_ptr |= mask2; ! for (id_bit = 0x80000000; id_bit; id_bit >>= 1) { *b_ptr &= mask1; ! if ((*a_ptr) & CIAA_PRA_RDY) ! id |= id_bit; *b_ptr |= mask2; } *************** *** 877,882 **** --- 877,887 ---- id = get_drive_id(fd->fdu); type = get_drive_type(id); + /* get_drive_id shuts off the motor */ + /* XXXX fdc_data[0] only as long as there is one controller */ + if (fd->fdu == fdc_data[0].motor_fdu) + fdc_data[0].motor_fdu = -1; + if (type == -1) { /* XXXX */ printf("fd_probe: unsupported drive type %08x found\n", id); *************** *** 910,916 **** fd->buf_track = track; fdc->state = WAIT_READ; - timeout((timeout_t)fd_timeout, (caddr_t)fdc, 2 * hz); fd_seek(fd, track); --- 915,920 ---- *************** *** 924,929 **** --- 928,934 ---- custom.dsklen = 0; delay(fd->ft->side_time); + timeout((timeout_t)fd_timeout, (caddr_t)fdc, 2 * hz); custom.dskpt = (u_char *)kvtop(raw_buf); custom.dsklen = len | DSKLEN_DMAEN; *************** *** 946,952 **** fdc->saved = fdc->state; fdc->state = WAIT_WRITE; - timeout((timeout_t)fd_timeout, (caddr_t)fdc, 2 * hz); fd_seek(fd, track); --- 951,956 ---- *************** *** 960,966 **** ADKF_MSBSYNC; /* set appropriate adkcon bits */ ! adk = ADKF_SETCLR | ADKF_FAST; if (track >= fd->ft->precomp2) adk |= ADKF_PRECOMP1; else if (track >= fd->ft->precomp1) --- 964,970 ---- ADKF_MSBSYNC; /* set appropriate adkcon bits */ ! adk = ADKF_SETCLR | ADKF_FAST | ADKF_MFMPREC; if (track >= fd->ft->precomp2) adk |= ADKF_PRECOMP1; else if (track >= fd->ft->precomp1) *************** *** 969,974 **** --- 973,979 ---- custom.dsklen = DSKLEN_WRITE; delay(fd->ft->side_time); + timeout((timeout_t)fd_timeout, (caddr_t)fdc, 2 * hz); custom.dskpt = (u_char *)kvtop(raw_buf); /* XXXX again raw */ custom.dsklen = len | DSKLEN_DMAEN | DSKLEN_WRITE; *************** *** 1057,1063 **** if (fdu >= DRVS_PER_CTLR) return(ENXIO); ! fd_probe(fd); if (fd->ft == NULL || fd->ft->tracks == 0) return(ENXIO); --- 1062,1080 ---- if (fdu >= DRVS_PER_CTLR) return(ENXIO); ! /* ! * XXXX don't probe if device is currently selected ! * it may be in the middle of a DMA transfer and fd_probe ! * will deselect all drives ! */ ! if (fdc->motor_fdu < 0) ! fd_probe(fd); ! #if 0 ! else ! printf ("fd: Fdopen called with a drive selected\n"); ! #endif ! ! if (fd->ft == NULL || fd->ft->tracks == 0) return(ENXIO); *************** *** 1130,1141 **** fd_label->d_magic = DISKMAGIC; fd_label->d_type = DTYPE_FLOPPY; strncpy(fd_label->d_typename, "fd", sizeof(fd_label->d_typename) - 1); ! strcpy(fd_label->d_packname, "some pack"); fd_label->d_secsize = 512; ! fd_label->d_nsectors = 11; ! fd_label->d_ntracks = 2; ! fd_label->d_ncylinders = 80; fd_label->d_secpercyl = fd_label->d_nsectors * fd_label->d_ntracks; fd_label->d_secperunit= fd_label->d_ncylinders * fd_label->d_secpercyl; --- 1147,1159 ---- fd_label->d_magic = DISKMAGIC; fd_label->d_type = DTYPE_FLOPPY; strncpy(fd_label->d_typename, "fd", sizeof(fd_label->d_typename) - 1); ! strcpy(fd_label->d_packname, fd->ft->name); + fd_label->d_rpm = 300 / fd->ft->sect_mult; fd_label->d_secsize = 512; ! fd_label->d_nsectors = fd->sects; ! fd_label->d_ntracks = fd->ft->heads; ! fd_label->d_ncylinders = fd->ft->tracks; fd_label->d_secpercyl = fd_label->d_nsectors * fd_label->d_ntracks; fd_label->d_secperunit= fd_label->d_ncylinders * fd_label->d_secpercyl; *************** *** 1192,1203 **** blknum = (unsigned long) bp->b_blkno * DEV_BSIZE / FDBLK; nblocks = fd->sects * fd->ft->tracks * fd->ft->heads; if (blknum + (bp->b_bcount / FDBLK) > nblocks) { ! /* XXXX */ ! printf("at end of disk\n"); ! bp->b_error = ENOSPC; ! bp->b_flags |= B_ERROR; ! biodone(bp); ! return; } bp->b_cylin = blknum; /* set here for disksort */ --- 1210,1228 ---- blknum = (unsigned long) bp->b_blkno * DEV_BSIZE / FDBLK; nblocks = fd->sects * fd->ft->tracks * fd->ft->heads; if (blknum + (bp->b_bcount / FDBLK) > nblocks) { ! nblocks -= blknum; ! if (nblocks == 0) { ! bp->b_resid = bp->b_bcount; ! goto done; ! } ! if (nblocks < 0) { ! bp->b_error = EINVAL; ! bp->b_flags |= B_ERROR; ! done: ! biodone(bp); ! return; ! } ! bp->b_bcount = dbtob(nblocks); } bp->b_cylin = blknum; /* set here for disksort */ *************** *** 1255,1265 **** dp = &fd->head; bp = dp->b_actf; /* XXXX */ ! printf("fd%d: Operation timeout\n", fd->fdu); if (bp) { retrier(fdc); fdc->state = DONE_IO; if (fdc->retry < 6) fdc->retry = 6; } else { --- 1280,1297 ---- dp = &fd->head; bp = dp->b_actf; + if (fd == NULL) { + printf ("fd_timeout called with no active drive?\n"); + return; + } + /* XXXX */ ! printf("fd%d: Operation timeout; state %d\n", fd->fdu, fdc->state); if (bp) { retrier(fdc); + #if 0 /* XXX retrier already set fdc->state? */ fdc->state = DONE_IO; + #endif if (fdc->retry < 6) fdc->retry = 6; } else { *************** *** 1368,1378 **** if (fd->buf_track != track) { TRACE1("do track %d\n", track); ! if (fd->buf_dirty) track_write(fdc, fd); ! else ! track_read(fdc, fd, track); ! return(0); } fdc->state = DO_IO; --- 1400,1424 ---- if (fd->buf_track != track) { TRACE1("do track %d\n", track); ! if (fd->buf_dirty) { track_write(fdc, fd); ! return (0); ! } else { ! if (read || sec != 0 || ! ((bp->b_bcount - fd->skip)/FDBLK) % fd->sects) { ! track_read(fdc, fd, track); ! return(0); ! } ! /* ! * if writing a full track, don't bother reading ! * in the old track - we're just going to overwrite ! * it all anyway. ! */ ! fd_seek (fd, track); ! fd->buf_track = track; ! /* clear sector labels */ ! bzero(fd->buf_labels, MAX_SECTS * 16); ! } } fdc->state = DO_IO; *************** *** 1397,1405 **** fdc->state = DOSEEK; else { fd->skip = 0; ! bp->b_resid = 0; ! dp->b_actf = bp->b_actf; ! biodone(bp); fdc->state = FINDWORK; } return(1); --- 1443,1455 ---- fdc->state = DOSEEK; else { fd->skip = 0; ! if (bp == NULL) ! printf ("fd: fdstate DONE_IO bp == NULL\n"); ! else { ! bp->b_resid = 0; ! dp->b_actf = bp->b_actf; ! biodone(bp); ! } fdc->state = FINDWORK; } return(1); *************** *** 1406,1419 **** case WAIT_READ: untimeout((timeout_t)fd_timeout, (caddr_t)fdc); custom.dsklen = 0; ! amiga_read(fd); ! fdc->state = DO_IO; ! return(1); case WAIT_WRITE: untimeout((timeout_t)fd_timeout, (caddr_t)fdc); custom.dsklen = 0; fdc->state = fdc->saved; fd->buf_dirty = 0; return(1); default: /* XXXX */ --- 1456,1490 ---- case WAIT_READ: untimeout((timeout_t)fd_timeout, (caddr_t)fdc); custom.dsklen = 0; ! if (amiga_read(fd) == 0) { ! fdc->retry = 0; ! fdc->state = DO_IO; ! return(1); ! } ! if (fdc->retry++ < 6) { ! track_read(fdc, fd, track); ! return(0); ! } ! if (bp) { ! bp->b_flags |= B_ERROR; ! bp->b_error = EIO; ! bp->b_resid = bp->b_bcount - fd->skip; ! dp->b_actf = bp->b_actf; ! fd->skip = 0; ! biodone(bp); ! } ! fdc->state = FINDWORK; ! return (1); case WAIT_WRITE: untimeout((timeout_t)fd_timeout, (caddr_t)fdc); custom.dsklen = 0; fdc->state = fdc->saved; fd->buf_dirty = 0; + /* + * post-write delay - should delay only if changing sides + * after a write? + */ + delay (4); return(1); default: /* XXXX */ *************** *** 1458,1469 **** /* XXXX */ printf("fd%d: hard error\n", fd->fdu); ! bp->b_flags |= B_ERROR; ! bp->b_error = EIO; ! bp->b_resid = bp->b_bcount - fd->skip; ! dp->b_actf = bp->b_actf; ! fd->skip = 0; ! biodone(bp); fdc->state = FINDWORK; return(1); #if 0 --- 1529,1544 ---- /* XXXX */ printf("fd%d: hard error\n", fd->fdu); ! if (bp == NULL) ! printf ("fd: retrier bp == NULL\n"); ! else { ! bp->b_flags |= B_ERROR; ! bp->b_error = EIO; ! bp->b_resid = bp->b_bcount - fd->skip; ! dp->b_actf = bp->b_actf; ! fd->skip = 0; ! biodone(bp); ! } fdc->state = FINDWORK; return(1); #if 0 -- 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 Apr 22 04:20:20 1994 From: Alan Bair Subject: New rootfs & BFFS To: amiga@sun-lamp.cs.berkeley.edu (Amiga NetBSD - General) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Some time ago I indicated I was working on a new rootfs, but unfortunately my real job got in the way. Well, Stephen Roznowski has proded me and I now have some time to work on the rootfs again. I plan on using the lastest files that Stephen uploaded to sun-lamp. However, this time I am trying to build a tar or other archive file instead of the filesystem image. This file would then be used with BFFS to populate the NetBSD filesystems. I have run into some problems and need advice on how to continue. 1. I have installed BFFS 1.3 with the 1.3.1 patch. I have been able to newfs my NetBSD partitions, run fsck, cd, els, etc. So this appears to be usable. Is this the latest version? 2. When trying to untar Stephen's tar files onto the NetBSD partition via BFFS all works OK until I get to a link. Then the tar fails saying it cannot create the link. This was version 1.09 of GNU tar. Is there a newer version that can create links via BFFS? 3. Since tar seemed to have some problems, is there another archiver that we could use? Ty Sarna said at one point that he was working on "pax". 4. In the past, some people have indicated that tar or other archivers may have trouble the Unix device files. Does anyone know of an archiver that will handle the devices? I remember someone mentioning cpio. 5. Another alternative for the devices, is to have a script on the AmigaDOS side to build the devices with the BFFS mknod. Is there an "easy" way to run Ty's MAKEDEV on the AMIGADOS side? Finally, is anyone makeing extensive use of BFFS and has any other hints? -- 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 Fri Apr 22 04:50:13 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: New rootfs & BFFS To: abair@sol-tx.sps.mot.com (Alan Bair) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1460 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Some time ago I indicated I was working on a new rootfs, but unfortunately my > real job got in the way. Well, Stephen Roznowski has proded me and I now have > some time to work on the rootfs again. I plan on using the lastest files that > Stephen uploaded to sun-lamp. However, this time I am trying to build a tar > or other archive file instead of the filesystem image. This file would then be > used with BFFS to populate the NetBSD filesystems. I have run into some > problems and need advice on how to continue. > > 1. I have installed BFFS 1.3 with the 1.3.1 patch. I have been able to newfs > my NetBSD partitions, run fsck, cd, els, etc. So this appears to be > usable. Is this the latest version? Its still very buggy (locks on my system etc..) > 5. Another alternative for the devices, is to have a script on the AmigaDOS > side to build the devices with the BFFS mknod. Is there an "easy" > way to run Ty's MAKEDEV on the AMIGADOS side? Calling it Ty's MAKEDEV kinda scared me. You should be using the MAKEDEV that is included in the tar.gz files on lamp. Also my ideas on this would be to use commodore's Installer to unarchive things directly from the tar files through BFFS. The tar files are built to be *exactly* correct for someone starting out. If the tar files re not *exctly* as they should be for new users. I need to change the source files on sun-lamp (like provide examples etc.) Thanks for all your work. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 22 04:54:00 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: New binaries: which one ? To: dsnjvro@etmsun.ericsson.se (John Vrolijk) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 340 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > Since I'm still running vmunix.744 and the 720 rootfs, I was wondering > if I should switch to a new set of binaries. > > If so, which one should I use ? > Will my X still work with the new set ? Grab the files a kernel from ftp.iastat.edu or another of sun-lamp's mirrors The files should be in an arch/amiga/ directory. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 22 05:03:03 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: dumpfont program To: heitmann@crunch.ikp.physik.th-darmstadt.de (Andreas Heitmann) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 396 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > It doesn't work with the RETINA console. If you want to use a font > working with the RETINA driver, you have to make shure that the font > is sized 8x8 Pixel. Topaz 8 will do it, but kernel_font.default > doesn't. Maybe someone can provide us with an 8x8 font for the next > distribution ? I have changed things so that it should always work from now on nothing needed from the user. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 22 05:52:00 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: New rootfs & BFFS Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404220128.AA04157@amcu-tx.sps.mot.com> Alan Bair writes: > 2. When trying to untar Stephen's tar files onto the NetBSD partition via > BFFS all works OK until I get to a link. Then the tar fails saying > it cannot create the link. This was version 1.09 of GNU tar. Is there > a newer version that can create links via BFFS? BFFS uses the regular AmigaDOS makelink packet, so if that tar works on AmigaDOS partitions it should also work on BFFS... unless BFFS is broken. > 3. Since tar seemed to have some problems, is there another archiver that > we could use? Ty Sarna said at one point that he was working on "pax". I have pax sort of working (it sometimes creates trashed filenames), but what I'd really like to do is just support mknod in ixemul.library. I am also wondering if this is the best solution anymore... in the future it's possible that people will want to install using logfs, and I don't expect a AmigaOS port of that to appear anytime soon. Possibly the best way to go is the old-fashioned ufs miniroot aproach on the swap partition, then build rootfs from a cpio or tar/MAKEDEV from the miniroot using whatever filesystem the user wants. > 4. In the past, some people have indicated that tar or other archivers may > have trouble the Unix device files. Does anyone know of an archiver > that will handle the devices? I remember someone mentioning cpio. The tar format doesn't have any provisions for device nodes, but cpio does. You can actually use gnu cpio on the amiga, but it will report "mknod: operation not supported" or somesuch when you try to extract device nodes. Also, the cpio command line sequence is a pain to work with compared to tar, so it's trickier to build a rootfs image with. > 5. Another alternative for the devices, is to have a script on the AmigaDOS > side to build the devices with the BFFS mknod. Is there an "easy" > way to run Ty's MAKEDEV on the AMIGADOS side? You could build the minimal set of nodes this way, then build the rest under NetBSD with MAKEDEV (it's not really "my" MAKEDEV, I just took the hp300 one and modified it a bit). -- 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 Fri Apr 22 05:53:40 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: New rootfs & BFFS Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404220159.AA22709@emunix.emich.edu> chopps@emunix.emich.edu (Chris Hopps) writes: > Its still very buggy (locks on my system etc..) I think the author found some bugs recently and is working on 1.4. > Also my ideas on this would be to use commodore's Installer to unarchive > things directly from the tar files through BFFS. The tar files are built Yes, this is how my install software works. I only do the minimum amount from the Installer though, a much as possible of the NetBSD-specific stuff should be done from NetBSD, to insure maximum compatibility. No matter how well AmigaOS can be made to work with NetBSD, NetBSD is much more certain to work with itself. I also want to use the standard netbsd install software where possible and where it makes sense to do so... The exception to this is partitioning. IMHO, all partitioning should be done under AmigaOS, since it's AmigaOS's native scheme. Also since it's a more complex scheme than usual for partitioning, I would rather trust a known AmigaOS partitioning program than use a new, possibly buggy netbsd RDB editor :-). > to be *exactly* correct for someone starting out. > > If the tar files re not *exctly* as they should be for new users. I need > to change the source files on sun-lamp (like provide examples etc.) However this isn't true... tar files can't contain device nodes, and there is a certain minumum set of these that have to exist to boot netbsd. One solution would be a minimal AmigaOS makdev script, then do the rest under NetBSD. t any rate, it's impossible for the tar files to contain everything. -- 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 Fri Apr 22 06:13:25 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: New rootfs & BFFS To: tsarna@endicor.com (Ty Sarna) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 427 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > However this isn't true... tar files can't contain device nodes, and > there is a certain minumum set of these that have to exist to boot > netbsd. One solution would be a minimal AmigaOS makdev script, then do > the rest under NetBSD. t any rate, it's impossible for the tar files to > contain everything. Correct they don't contain dev nodes just MAKEDEV, which would be run by the sysadmin to set the system up.. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 22 11:12:52 1994 From: terjem@stud.cs.uit.no (Terje Normann Marthinussen) Subject: Re: New rootfs & BFFS To: tsarna@endicor.com (Ty Sarna) 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: 1598 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > In article <9404220159.AA22709@emunix.emich.edu> chopps@emunix.emich.edu (Chris Hopps) writes: > However this isn't true... tar files can't contain device nodes, and > there is a certain minumum set of these that have to exist to boot > netbsd. One solution would be a minimal AmigaOS makdev script, then do > the rest under NetBSD. t any rate, it's impossible for the tar files to > contain everything. > This can't be correct? I moved my entire / between two disks using tar and it restored all my device nodes.... >From the HPUX man page on tar: The version portion of the key determines in which format tar writes the archive. tar can read either format regardless of the version. The version is specified by one of the following letters: N Write a new (POSIX) format archive. The new format allows file names up to 256 characters in length, and correctly archives and restores the following file types: regular files, character and block special devices, links, symbolic links, directories, and FIFO special files. The new version also stores the user and group name of each file and attempts to use these names to determine the uid and gid of a file when restoring with the p function modifier. This is the new default format. As it says, character and block device nodes. I'm very sure that gnu tar (can't find the manual page) supports the same.. Terje Marthinussen terjem@stud.cs.uit.no From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 22 12:44:28 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: New rootfs & BFFS Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <199404220802.EAA18118@tklab3.cs.uit.no> terjem@stud.cs.uit.no (Terje Normann Marthinussen) writes: > N Write a new (POSIX) format archive. The new format > allows file names up to 256 characters in length, and > correctly archives and restores the following file types: > regular files, character and block special devices, > links, symbolic links, directories, and FIFO special > files. The new version also stores the user and group > name of each file and attempts to use these names to > determine the uid and gid of a file when restoring with > the p function modifier. This is the new default format. Hey, you're right! I was originally planning to use tar, and then somebody mentioned that tar didn't do special files. So I checked it out (on SunOS) and found this to be true. I didn't realize that there was a new tar format. Shoot, wish I'd found that out earlier... I'll just ditch pax and add support to gnutar. I prefer tar anyway... > As it says, character and block device nodes. > I'm very sure that gnu tar (can't find the manual page) supports the same.. I just checked NetBSD's tar (which is gnu tar), and it does support ustar format archives. There probably isn't a manual page because nobody felt like converting it from info format. Well, forget everything I said about cpio and pax and go the tar route. Boy, and I already felt stupid enough today before this... I added a bunch of ROLLCOLOR() calls to the floppy driver to try to track down a problem, using different colors for different things. Then I realized I was working on a monchrome monitor (A2024) and wouldn't be able to tell them apart. D'oh! -- 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 Fri Apr 22 12:48:03 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: New rootfs & BFFS To: tsarna@endicor.com (Ty Sarna) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 624 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Boy, and I already felt stupid enough today before this... I added a > bunch of ROLLCOLOR() calls to the floppy driver to try to track down a > problem, using different colors for different things. Then I realized I > was working on a monchrome monitor (A2024) and wouldn't be able to tell > them apart. D'oh! Sorry about this :) You can use a 2024 with ROLLCOLOR() as a mater of fact I have done it and added the nec. constants to color.h a while ago: #define COL24_BLACK 0x0 #define COL24_DGREY 0x0009 #define COL24_LGREY 0x0880 #define COL24_WHITE 0xffff (look in /sys/amiga/amiga/color.h) Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 00:26:12 1994 From: Alan Bair Subject: Re: New rootfs & BFFS To: tsarna@endicor.com (Ty Sarna) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > In article <199404220802.EAA18118@tklab3.cs.uit.no> terjem@stud.cs.uit.no (Terje Normann Marthinussen) writes: > > N Write a new (POSIX) format archive. The new format > > allows file names up to 256 characters in length, and > > correctly archives and restores the following file types: > > regular files, character and block special devices, > > links, symbolic links, directories, and FIFO special > > files. The new version also stores the user and group > > name of each file and attempts to use these names to > > determine the uid and gid of a file when restoring with > > the p function modifier. This is the new default format. > > Hey, you're right! I was originally planning to use tar, and then > somebody mentioned that tar didn't do special files. So I checked it > out (on SunOS) and found this to be true. I didn't realize that there > was a new tar format. Shoot, wish I'd found that out earlier... I'll > just ditch pax and add support to gnutar. I prefer tar anyway... > > > As it says, character and block device nodes. > > I'm very sure that gnu tar (can't find the manual page) supports the same.. > > I just checked NetBSD's tar (which is gnu tar), and it does support > ustar format archives. There probably isn't a manual page because > nobody felt like converting it from info format. > > Well, forget everything I said about cpio and pax and go the tar route. About was about to make similar remarks about the use of tar as several others have. I have always used tar to move anything under Unix and it has worked. I just did it last night to build an experimental copy of my current root area. However, before we all cheer, I tried some experiments on the Amiga side and ran into problems. I mounted my experimental root partition under BFFS. Then I tried to tar up the root area. The tar I have could not read the devices or links. Now maybe this is just the tar I have. So I am going to try some alternates and also build from the latest sources to see if I can get one that works. It could be that AmigaDOS programs just don't know how to deal with these two beasts. Another choice is to try taring on the NetBSD side and then just untaring on the Amiga side into the BFFS partition. I have been able to manually create links and devices on a BFFS partition, so at least that part of the transfer works. > > -- > Ty Sarna "As you know, Joel, children have always looked > tsarna@endicor.com up to cowboys as role models. And vice versa." > -- 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 Sat Apr 23 00:32:19 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: NetBSD booting To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1152 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I am having problems when NetBSD boots into multi-user mode. Symtoms are: kvm_mkdb: /netbsd corrupted string table: Inappropriate file type or format and init: getty repeating to quickly on port /dev/ite0 My setup is as follows: Kernel: netbsd-generic dated April 16th /netbsd is a soft-link to /netbsd-generic /dev/* was created by the MAKEDEV script available for that purpose. /etc/* was create from the etc.tar.gz Most binaries are from the latest binary release. with a few extraneous that I had previously compiled. My System is an 8M/1M Amiga 3000UX with a 200M HD and an 80M HD. Ethernet card is installed. No graphics card is installed. The system is hooked up to the InterNet. I came to this situation through my own misfortune. I was compiling the latest sources during the library stage and had them installed. I then proceeded to delete some of the older shared libraries as I thought I didn't need them. I realized after deleting some of the libraries when I went to compile the kernel that I still needed those libraries. I can boot into single user mode no problems. What files to I need to fix?? Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 00:32:31 1994 From: rhealey@aggregate.com Subject: Re: New rootfs & BFFS To: tsarna@endicor.com (Ty Sarna) 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: 1801 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > IMHO, all partitioning should be done under AmigaOS, since it's AmigaOS's > native scheme. Also since it's a more complex scheme than usual for > partitioning, I would rather trust a known AmigaOS partitioning program > than use a new, possibly buggy netbsd RDB editor :-). > This creates the problem of how do you create initial partitions if you don't WANT to have to go through ADOS? Eventually the people doing the stand alone bootstrap will have a working solution and with Mike's recent work on the floppy driver it looks like it would be possible to actually boot and run a floppy based install. I personally find it EXTREMELY annoying to have to boot ADOS and then boot BSD, AMIX doesn't require this pain-in-the-butt procedure and NetBSD shouldn't need it. The rdb program for AMIX was relatively short and worked pretty well. It's too bad we can't get C= to hand some of the AMIX pieces over to NetBSD as it would speed up some processes. About floppy install, some ideas from the AMIX sequence: The floppy kernel uses a special device node that prompts on open, i.e. "Insert root file system". It next scans for working hard drives, formats and partitions, then installs the hard drive swap area as it's own swap. It then either sucks the distribution off of tape on to disk or lets you escape out to repair the hard drive. It's amazing what they fit on a 880k floppy for install and repair work. Nothing in this sequence would seem impossible to do for NetBSD. We would need a simple command line driven rdb editor and hard drive format program; equivelents of AMIX's ddsize, ddformat and rdb commands. Now that we have a working floppy driver, Thanks Brad and Mike!, we can start to think about floppy boots for install and recover operations. -Rob From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 23 00:34:04 1994 Subject: Re: New X color servers with source code From: David Jones To: phb@colombo.telesys-innov.fr (Philippe BRAND) Cc: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > As I can't send those archives, could someone grab them ? I am file sponging as I speak. Where should I put them: sun-lamp or eunet or both? I am not getting the sources, only the Xbsd* files. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 23 00:34:29 1994 From: Philippe BRAND Subject: New X color servers with source code To: amiga-x@sun-lamp.cs.berkeley.edu (NetBSD Liste) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 472 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I'm pleased to announce new version of X color servers, 2 planes and 4 planes. Full source code is also available for your hacking pleasure. As I can't send those archives, could someone grab them ? Files are: /pub/amiga/NetBSD/X11R5/XbsdCC2.gz 453203 /pub/amiga/NetBSD/X11R5/XbsdCC4.gz 317370 /pub/amiga/NetBSD/X11R5/mit.tar.gz 1818624 on my host colombo.telesys-innov.fr Have fun! -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Co-Sysop 2:320/104.21 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Apr 23 00:41:20 1994 From: Eric Augustine Subject: USL and FreeBSD 1.1g To: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Developer's news-list Amiga-Dev) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2611 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu An error in mailing somewhere sent this back... I am resending this... in case you get two of the same... you know why :) ****** A few days ago I mentioned that USL had given FreeBSD the okay to release 1.1g and as I expected there were more questions about the validity of this. I therefore asked my source for the message itself which he forwarded to me... Here are the pertinent parts (I removed questions about installation and getting the actual distribution) > > > After some delay, the FreeBSD group is very pleased to announce the > release of FreeBSD 1.1 GAMMA! > [a myriad of questions answered, removed - about why upgrade...] > > > Q. WHAT ABOUT THE LEGAL PROBLEMS I HEARD ABOUT? > > A. Thanks to an exceptional willingness on USL's part to negotiate on > this (when they could have simply said "No" and left it at that), we > are now able to do this 1.1 Release. > > NOTE: ** FreeBSD 1.1 will be the LAST Net/2 based release of FreeBSD **. > > Subsequent releases of FreeBSD will based on the BSD 4.4 LITE code and > all future releases of FreeBSD will be completely `unencumbered'. The > terms of this are mandated by the recent UCB/USL settlement and are > non-negotiable. > > This is not to say that FreeBSD users will be due for an enormous > shock as their favorite OS mutates beyond all recognition, far from > it. We will be approaching the port with great conservatism, taking > care to finely balance the needs of legality (4.4 lite) and stability > (unencumbered portions of the old code base), and we are very > optimistic about FreeBSD's future as a stable, high performance > operating system with all the features (and Internet support) that > people have come to expect from us. > > Folks who are interested in knowing more about (or, even better, > participating in) this process are encouraged to write to us at: > > freebsd-hackers@freefall.cdrom.com > > [more questions removed] > > You will also want to grab a copy of the new FAQ, the most up-to-date > copy of which is always in: > > freebsd.cdrom.com:~ftp/pub/FreeBSD/FAQ > > This contains very useful information about our mailing lists, hardware > supported and a host of other things. > > As always, we hope you enjoy FreeBSD as much as we have enjoyed > producing it! > > The FreeBSD Team > > > I hope this clears some of it up and points you in the right direction for the rest of your questions. If it is true and useful to us then while USL is handing out permissions maybe we should get in line... - Eric. ****** From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 00:47:29 1994 From: Eric Augustine Subject: USL and FreeBSD 1.1g To: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Developer's news-list Amiga-Dev) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2611 Sender: owner-amiga@sun-lamp.cs.berkeley.edu An error in mailing somewhere sent this back... I am resending this... in case you get two of the same... you know why :) ****** A few days ago I mentioned that USL had given FreeBSD the okay to release 1.1g and as I expected there were more questions about the validity of this. I therefore asked my source for the message itself which he forwarded to me... Here are the pertinent parts (I removed questions about installation and getting the actual distribution) > > > After some delay, the FreeBSD group is very pleased to announce the > release of FreeBSD 1.1 GAMMA! > [a myriad of questions answered, removed - about why upgrade...] > > > Q. WHAT ABOUT THE LEGAL PROBLEMS I HEARD ABOUT? > > A. Thanks to an exceptional willingness on USL's part to negotiate on > this (when they could have simply said "No" and left it at that), we > are now able to do this 1.1 Release. > > NOTE: ** FreeBSD 1.1 will be the LAST Net/2 based release of FreeBSD **. > > Subsequent releases of FreeBSD will based on the BSD 4.4 LITE code and > all future releases of FreeBSD will be completely `unencumbered'. The > terms of this are mandated by the recent UCB/USL settlement and are > non-negotiable. > > This is not to say that FreeBSD users will be due for an enormous > shock as their favorite OS mutates beyond all recognition, far from > it. We will be approaching the port with great conservatism, taking > care to finely balance the needs of legality (4.4 lite) and stability > (unencumbered portions of the old code base), and we are very > optimistic about FreeBSD's future as a stable, high performance > operating system with all the features (and Internet support) that > people have come to expect from us. > > Folks who are interested in knowing more about (or, even better, > participating in) this process are encouraged to write to us at: > > freebsd-hackers@freefall.cdrom.com > > [more questions removed] > > You will also want to grab a copy of the new FAQ, the most up-to-date > copy of which is always in: > > freebsd.cdrom.com:~ftp/pub/FreeBSD/FAQ > > This contains very useful information about our mailing lists, hardware > supported and a host of other things. > > As always, we hope you enjoy FreeBSD as much as we have enjoyed > producing it! > > The FreeBSD Team > > > I hope this clears some of it up and points you in the right direction for the rest of your questions. If it is true and useful to us then while USL is handing out permissions maybe we should get in line... - Eric. ****** From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 00:48:22 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: "Chris G. Demetriou" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/conf Modified Files: Makefile.amiga Log Message: kill symbols.{raw,sort}; no longer necessary, with kvm dbs. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: MAKEDEV Log Message: add more floppies, mouse link and fix typo from Ty Sarna (tsarna@endicor.com) --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC Added Files: A3000 Log Message: add A3000 (we use it in snapshot) and commented GENERIC. (pretty heafty) --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: a2091dma.c a3000dma.c gvp11dma.c sci.c scsi.c sd.c Log Message: make current with recent vm changes. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: amiga_init.c genassym.c machdep.c mem.c pmap.c Log Message: make current with recent vm changes, also clean old from genassym --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/m68k/include Modified Files: db_machdep.h Log Message: vm/queue.h doesn't exist any more. --------------------------------- 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 Modified Files: pmap.c Log Message: '040 changes from Amiga. --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/sys/arch/mac68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/include Modified Files: pmap.h Log Message: '040 changes from Amiga. --------------------------------- 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 Modified Files: trap.c Log Message: Almost a copy from Amiga. --------------------------------- 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 Modified Files: vm_machdep.c Log Message: Include cop. Add '040 stuff from Amiga. --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/sys/arch/mac68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/include Modified Files: param.h Log Message: '040 changes from Amiga. Protect against multiple inclusion. --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/sys/arch/mac68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/include Modified Files: pte.h Log Message: Add '040 stuff from Amiga pte.h. Also protect against multiple inclusion. --------------------------------- 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 Modified Files: locore.s Log Message: Add '040 stuff from Amiga. Modified TBIA and friends which were all basically flushing everything to satisfy year-old paranoia. --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/sys/arch/mac68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/include Modified Files: cpu.h Log Message: '040 changes from Amiga. Protect against multiple inclusion. Swap arguments in struct clockframe. --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/sys/arch/m68k/conf In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/m68k/conf Modified Files: files.m68k.newconf Log Message: Add fpsp support. Comment out fpspnull line until I figure out how to specify "not option" with new config. Don't need it yet, anyway. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: files.amiga Log Message: Changed fonts. Added 2 non (c) fonts kf_8x{8,11}.c retina now uses kf_8x8. CC console users can now choose between the provided fonts or provide there own. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: machdep.c Log Message: grab new net changes from hp300/mchdep.c --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: grf_rt.c ite_cc.c retina-mondefs.c Added Files: kf_8x11.c kf_8x8.c Removed Files: kernel_font.c.distrib Log Message: Changed fonts. Added 2 non (c) fonts kf_8x{8,11}.c retina now uses kf_8x8. CC console users can now choose between the provided fonts or provide there own. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: autoconf.c swapgeneric.c Log Message: changes to allow fd as boot device. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: fd.c Log Message: changes to make fd work better (not done yet) from Michael Hitch (osymh@montana.edu) --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: machdep.c Log Message: eek paste accidental spaces. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: swapgeneric.c Log Message: fix typo. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: ite_cc.c Log Message: spaces pasted should be tabs --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/doc In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/doc Modified Files: CHANGES Log Message: amiga 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/trees/src/sys/arch/amiga/dev Modified Files: ser.c Log Message: update to deal with ttyflags from tsarna@endicor.com (Ty Sarna), major design changes by me which include shrinking of ring buffer size from 16k to 256 bytes and removing code that realloced the clists for the tty from default to 8192 (was using 24k) suggested as suggested by theo. --------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 00:50:57 1994 From: Eric Augustine Subject: USL/FreeBSD To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2470 Sender: owner-amiga@sun-lamp.cs.berkeley.edu A few days ago I mentioned that USL had given FreeBSD the okay to release 1.1g and as I expected there were more questions about the validity of this. I therefore asked my source for the message itself which he forwarded to me... Here are the pertinent parts (I removed questions about installation and getting the actual distribution) > > > After some delay, the FreeBSD group is very pleased to announce the > release of FreeBSD 1.1 GAMMA! > [a myriad of questions answered, removed - about why upgrade...] > > > Q. WHAT ABOUT THE LEGAL PROBLEMS I HEARD ABOUT? > > A. Thanks to an exceptional willingness on USL's part to negotiate on > this (when they could have simply said "No" and left it at that), we > are now able to do this 1.1 Release. > > NOTE: ** FreeBSD 1.1 will be the LAST Net/2 based release of FreeBSD **. > > Subsequent releases of FreeBSD will based on the BSD 4.4 LITE code and > all future releases of FreeBSD will be completely `unencumbered'. The > terms of this are mandated by the recent UCB/USL settlement and are > non-negotiable. > > This is not to say that FreeBSD users will be due for an enormous > shock as their favorite OS mutates beyond all recognition, far from > it. We will be approaching the port with great conservatism, taking > care to finely balance the needs of legality (4.4 lite) and stability > (unencumbered portions of the old code base), and we are very > optimistic about FreeBSD's future as a stable, high performance > operating system with all the features (and Internet support) that > people have come to expect from us. > > Folks who are interested in knowing more about (or, even better, > participating in) this process are encouraged to write to us at: > > freebsd-hackers@freefall.cdrom.com > > [more questions removed] > > You will also want to grab a copy of the new FAQ, the most up-to-date > copy of which is always in: > > freebsd.cdrom.com:~ftp/pub/FreeBSD/FAQ > > This contains very useful information about our mailing lists, hardware > supported and a host of other things. > > As always, we hope you enjoy FreeBSD as much as we have enjoyed > producing it! > > The FreeBSD Team > > > I hope this clears some of it up and points you in the right direction for the rest of your questions. If it is true and useful to us then while USL is handing out permissions maybe we should get in line... - Eric. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 00:52:04 1994 From: Rohan Beckles Subject: Amiga Floppy Driver To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Just a quick question. I need clarification. 1. Does an Amiga floppy driver exist for NetBSD? 2. If yes, can it read and write MS-DOS floppies as well? I appologise if someone has asked this before, but I have only just joined the mailing list, so I'm rather new to this game. BTW, I have an idea for a program. It would run on an Amiga under X11, and would allow the user to control other X hosts. It would use the multiple screens capabilities of the Amiga(and RTG when C= get around to it), to put the desktop of another X11 node on a custom screen. This would allow the Amiga user to use GUI software on another machine without leaving their seat. Is this feasible with current technology, or am I just being stupid? From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 01:07:35 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: NetBSD booting To: garion@mermaid.micro.umn.edu (Ron Roskens) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1567 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I am having problems when NetBSD boots into multi-user mode. > Symtoms are: > > kvm_mkdb: /netbsd corrupted string table: Inappropriate file type or format This sounds like a bug I fixed a couple weeks ago. > init: getty repeating to quickly on port /dev/ite0 please provide: (do this set of commands paste if you wish.) [boot netbsd] mount /usr csh ls -l {/sbin,/bin,/usr/sbin,/usr/bin}/kvm_mkdb ls -l /usr/libexec/getty my output was: ls: /bin/kvm_mkdb: No such file or directory ls: /sbin/kvm_mkdb: No such file or directory ls: /usr/bin/kvm_mkdb: No such file or directory -r-xr-xr-x 1 bin bin 81920 Apr 21 02:22 /usr/sbin/kvm_mkdb -r-xr-xr-x 1 bin bin 98304 Apr 21 02:09 /usr/libexec/getty > /dev/* was created by the MAKEDEV script available for that purpose. > /etc/* was create from the etc.tar.gz > Most binaries are from the latest binary release. with a few extraneous > that I had previously compiled. getty and kvm_mkdb where from the latest binary release correct? > I came to this situation through my own misfortune. I was compiling the latest > sources during the library stage and had them installed. I then proceeded to > delete some of the older shared libraries as I thought I didn't need them. > I realized after deleting some of the libraries when I went to compile the > kernel that I still needed those libraries. I'd say if you don't get any farther just nuke each directory and replace it with the binary distribution. (note: don't nuke tar,gzip or you won't be able to unarchive the needed directories.) Chris. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat Apr 23 01:24:47 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: New X color servers with source code To: dej@eecg.toronto.edu (David Jones) Cc: phb@colombo.telesys-innov.fr, amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 618 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > > As I can't send those archives, could someone grab them ? > > I am file sponging as I speak. > > Where should I put them: sun-lamp or eunet or both? if you put them on eunet. I can grab them and figure where a good place would be on lamp if we should have them there. (other ports seem too...) I sure would like to get a full recent build though.. anyone. Like the entire distribution would be nice. I can happily put this on lamp like the hp300 in pub/NetBSD/ports/X11R5/hp300 I don't want the one on eunet as its old, buggy and pretty useless. (Some of the link libraries have known problems) Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 01:32:21 1994 From: Alan Bair Subject: NCR SCSI controllers To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu With the talk on NCR SCSI controllers, I was wondering if the Warp Engine's controller, which I think is NCR based, is supported by NetBSD yet? As I understand it's 040 setup is currently supported in some version of NetBSD, though it may not be publicly available yet. I'm asking because I was thinking of buying the Warp Engine, but would like to know I can use all of its features. > > On Apr 21, 11:56am, Markus Illenseer wrote: > > > > No support for any NCR-based Adapter yet working, and i don't share > > your opinion on that 'coolest' adapter. Oktagon is a PIO-Adapter > > with no DMA capabilities. Thus it is quite hard to implement service > > for this one. > > I beg to differ... The current kernel has support for the Supra Wordsync > (series 2, I think), CSA 12 Gauge, IVS Vector, and my home-built SCSI > board. I'm not certain about the status of the CSA 12 Gauge and the IVS > Vector support, since I don't have either of them. The Supra Wordsync > was running on my A2000 using pseudo-DMA, but might possibly not work > on an A3000. It should work without using pseudo-DMA, although a bit > slowly. My homebuilt SCSI board also works quite well with pseudo-DMA. > IVS Trumpcard and Trumpcard Pro support is probably very close. Supra > Wordsync series 3 should be fairly easy to add basic support (i.e. > programmed-IO only). > > Also, I have been running another NCR-based adapter and that support has > been in NetBSD for a number of months - the Zeus SCSI uses an NCR chip > (the 53C710) :-). > > 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 > -- 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-x@sun-lamp.cs.berkeley.edu Sat Apr 23 03:23:52 1994 Subject: X is the same as 21 March From: David Jones To: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu The X servers that were recently announced are the same as those posted on March 21. Do not waste your time and bandwidth sucking them over. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 05:45:34 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: NetBSD booting To: chopps@emunix.emich.edu (Chris Hopps) Cc: garion@mermaid.micro.umn.edu, 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: 1244 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Chris Hopps wrote: > > I am having problems when NetBSD boots into multi-user mode. > > Symtoms are: > > > > kvm_mkdb: /netbsd corrupted string table: Inappropriate file type or format > > This sounds like a bug I fixed a couple weeks ago. > > > init: getty repeating to quickly on port /dev/ite0 > > please provide: (do this set of commands paste if you wish.) [boot netbsd] > mount /usr > csh > ls -l {/sbin,/bin,/usr/sbin,/usr/bin}/kvm_mkdb > ls -l /usr/libexec/getty > > my output was: > ls: /bin/kvm_mkdb: No such file or directory > ls: /sbin/kvm_mkdb: No such file or directory > ls: /usr/bin/kvm_mkdb: No such file or directory > -r-xr-xr-x 1 bin bin 81920 Apr 21 02:22 /usr/sbin/kvm_mkdb > -r-xr-xr-x 1 bin bin 98304 Apr 21 02:09 /usr/libexec/getty My output is: ls: /bin/kvm_mkdb: No such file or directory ls: /sbin/kvm_mkdb: No such file or directory ls: /usr/bin/kvm_mkdb: No such file or directory -r-xr-xr-x 1 bin bin 24576 Apr 16 18:33 /usr/sbin/kvm_mkdb -r-xr-xr-x 1 bin bin 24576 Mar 20 08:00 /usr/libexec/getty So I'd probably best grab the lastest binaries again and reinstall. I am doing this and hooking up my new 632M HD now so more on this mishap later.. Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 23 11:25:17 1994 From: Donn Cave X-Sender: donn@homer08.u.washington.edu Subject: /etc/hosts To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1012 Sender: owner-amiga@sun-lamp.cs.berkeley.edu | If the tar files re not *exctly* as they should be for new users. I need | to change the source files on sun-lamp (like provide examples etc.) Well, I don't know if this has anything to do with the Amiga port, per se, or if this is the kind of thing you mean, but I'd recommend that the /etc/hosts entry for myname.my.domain be changed to 0.0. Context diff appended, from April 13 snapshot of -current. The way it is now, things that connect to the local host using gethostname() (e.g., term) end up trying to connect to 0.0.0.2, which hangs. Donn Cave, donn@cac.washington.edu ------------------------------------------ *** hosts.dist Fri Apr 22 17:09:55 1994 --- hosts Fri Apr 22 17:10:03 1994 *************** *** 9,13 **** 127.1 localhost localhost.my.domain # # Imaginary network. ! 0.2 myname.my.domain myname 0.3 myfriend.my.domain myfriend --- 9,13 ---- 127.1 localhost localhost.my.domain # # Imaginary network. ! 0.0 myname.my.domain myname 0.3 myfriend.my.domain myfriend From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 24 01:37:45 1994 From: chammer@hrz.uni-bielefeld.de Subject: st_pretend is MT_ISPYTHON for "WANGTEK 6200-HS rev 4B18" To: amiga-dev@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, thats it. It works good, the only problem is that tar seems not to be able to adjust the blocking factor. 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 Apr 24 16:43:01 1994 From: Philippe BRAND Subject: Re: New X color servers with source code To: oster@skdad.usask.ca (Greg Oster) Cc: amiga-x@sun-lamp.cs.berkeley.edu (NetBSD Liste) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 612 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Greg Oster writes: > > I'm pleased to announce new version of X color servers, 2 planes > > and 4 planes. Full source code is also available for your hacking pleasure. > Why are the files dated March 19, and why are they exactly the same size as > the ones already on ftp.eunet.ch in > /software/os/bsd/NetBSD/NetBSD-Amiga/contrib/bsd/X11 ???? Seems that my friendmade a little bit mistake. He should have provided me new version. Well, waiting for real new archives, one caan always recompile servers using provided code ;-) -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Co-Sysop 2:320/104.21 From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 24 17:28:58 1994 From: ozzy@catt.ncsu.edu (Chris Mattingly) Posted-Date: Sun, 24 Apr 1994 10:32:14 -0400 (EDT) Subject: Me happy now :) To: amiga@sun-lamp.cs.berkeley.edu (netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1117 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Well, don't know if anyone remembers, but about 2 months ago, I bought a 345 Meg Seagate... I tried to put netbsd on there, and it barfed. After many experiments with hacking the kernel, and a few other tricks, I found out that it was the 1024 bytes/sector that was causing all of the trouble. :) Sadly, it took a friend's MM/1 to put the sector size back to 512 bytes/ sector, since nothing I could find for amigados would do this. But after that, and a lot of patience re d/l'ing all the netbsd stuff, it ran just as happy as ever. So, the whole point of this is: Is it documented anywhere that the sector size of 1024 can cause problems? If not, then shouldn't it be documented somewhere, so that others don't go through the frustration that I had to? Later, Chris -- 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-dev@sun-lamp.cs.berkeley.edu Sun Apr 24 18:32:12 1994 Subject: cpp 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 The latest makefiles give CPP as CPP = cpp I had to change this to CPP = /usr/libexec/cpp -traditional I thought the source was supposed to compile out of the box, barring sup coherency issues. So, what's wrong with my configuration? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 24 19:27:53 1994 From: niklas@appli.se (Niklas Hallqvist) To: dej@eecg.toronto.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: cpp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "David" == David Jones writes: David> The latest makefiles give CPP as CPP = cpp David> I had to change this to David> CPP = /usr/libexec/cpp -traditional David> I thought the source was supposed to compile out of the box, David> barring sup coherency issues. So, what's wrong with my David> configuration? The problem you see is depending on whether you run the *real* GNU cpp, e.g. home-compiled or gotten from the gcc-2.5.8 binary archive, or with NetBSD GNU cpp, which by default is traditional. I've solved it bothways locally, I made /usr/bin/cpp a symlink to /usr/libexec/cpp aswell as added #ifdef __STDC__ where needed. I don't have the time to provide patches, I'm leaving for a three-and-a-half weeks of military service tomorrow morning and must fix a lot of stuff before then. Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Sun Apr 24 21:35:44 1994 From: Rafael Munoz Subject: NetBSD, ofcourse... To: amiga@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi all, Well, I have successfully loaded NetBSD onto my A3000. That is, I have installed the kernel, and have load it NetBSD into single-user mode, and all has worked. I have been using NetBSD.Install.744 as the document to install everything I needed. I have made a a root partition of 12 Megs (BSDR type), a swap partition of 35 Megs (I have 16 Megs of FAST RAM; BSDS type), and another partition called BSDD of 56 MEGS, all done via HDToolBox. I used streamtodev to put rootfs_720 onto the root partition (BSDR), and this worked fine. Like I said, I have been able to "run" it. I am using the following: loadbsd-940320 vmunix.a3000-940319 to start NetBSD, with rootfs_720. Now the problems: 1 - When trying to format the partitions as per NetBSD.Install.744 using newfs, I get the following errors: newfs /dev/rsd2d newfs: ioctl (GDINFO): Invalid argument newfs: /dev/rsd2d: can't read disk label; disk type must be specified. I went ahead and created /etc/fstab, which contains: /dev/sd2a / ufs rw 1 1 /dev/sd2b /tmp mfs rw 1 1 /dev/sd2d /usr ufs rw 1 1 And ofcourse, when I ran mount -av, /usr was not mounted since I had an error with newfs for /dev/rsd2d. So, what am I doing wrong, and what do I need to do to get the above to work as is explained in NetBSD.Install.744? Thanks in advanced... 2 - The second problem has to do with vi, which may be attributed to NOT having all of the necessary bin's setup yet. But I keep getting the error "can't read /etc/termcap", and the link is there, that is, /etc/termcap@ -> /usr/share/termcap/termcap.src Again, thanks for any and all info. BTW, all these "problems" may be due tothe fact that I have NOT copied all of the necessary bin files such as bin-usr.sbin.tar.gz, etc. It was not clear (to me anyway), whether I needed to get these files before formating the new partitions, so please bear with me. Thanks... -- ***************************************************************************** * Rafael Munoz Internet: erm008@comm.mot.com * * Motorola, Inc * * Plantation, FL Bix : rmunoz@bix.com * * 305-475-6298 GEnie : rmunoz * ***************************************************************************** From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Apr 24 21:41:30 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: cpp 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: 427 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > The latest makefiles give CPP as > > CPP = cpp > > I had to change this to > > CPP = /usr/libexec/cpp -traditional > > I thought the source was supposed to compile out of the box, barring sup > coherency issues. So, what's wrong with my configuration? Your ``box'' is wrong. Use the binaries that come from the sources and all will be fine. i.o.w your using a cpp that isn't form /usr/src/gnu/usr.bin/gcc2. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 25 00:26:19 1994 From: Hubert Feyrer Subject: Re: NetBSD, ofcourse... To: erm008@comm.mot.com (Rafael Munoz) 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: 1329 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > 1 - When trying to format the partitions as per NetBSD.Install.744 > using newfs, I get the following errors: > > newfs /dev/rsd2d > newfs: ioctl (GDINFO): Invalid argument > newfs: /dev/rsd2d: can't read disk label; disk type must be specified. To use /dev/[r]sd2d as a partition/filesystem, you have to create a partition with type BSDD for it (just as you did with BSDR and BSDS)! > 2 - The second problem has to do with vi, which may be attributed to NOT > having all of the necessary bin's setup yet. But I keep getting the error > "can't read /etc/termcap", and the link is there, that is, > > /etc/termcap@ -> /usr/share/termcap/termcap.src AFAIK, /usr/share/termcap/termcap.src _is_ on the rootfs_720's rootfs! Maybe because of your faulty mount-attemp, the /usr is occupied by your (intended) /usr and the /usr/share/.. is no more visible. Try the above & see! Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 25 00:45:02 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: NetBSD, ofcourse... To: erm008@comm.mot.com (Rafael Munoz) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 468 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > loadbsd-940320 vmunix.a3000-940319 > > to start NetBSD, with rootfs_720. Now the problems: Your problem is that the binaries on rootfs_720 are way old and things in the kernel that you are using are new and so there is a mismatch grab the latest kernel and binaries from ftp.iastate.edu (or other sun-lamp mirrors) and at least install /bin and /sbin. This should allow you to procede to format things then install all the other new bins. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 25 08:59:00 1994 From: Arthur Hoffmann Subject: where is bfreelist? To: amiga-dev@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: 1575 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I'm trying to compile a recent kernel for a few days now, but I keep on getting stuck with the following: cc -c -O2 -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DATZE -DM68030 -DPPP_OUTQ_SIZE=4096 -DNKMEMCLUSTERS=256 -DKTRACE -DDDB -DFPCOPROC -DDIAGNOSTIC -DSYSVSEM -DSYSVMSG -DSYSVSHM -DPANICWAIT -DHAVE_USL_UFS -DCOMPAT_NOMID -DTCP_COMPAT_42 -DCOMPAT_43 -DCOMPAT_SUNOS -DCOMPAT_09 -DGRF_A2024 -DGRF_PAL -DGRF_NTSC -DGRF_ACS -DGRF_ECS -DGRF_OCS -DGRF_CUSTOM_CHIP_MODES -DGRF -DMSDOSFS -DTPIP -DISO -DGATEWAY -DLKM -DPROCFS -DPORTAL -DLOFS -DPROCFS -DFDESC -DKERNFS -DFIFO -DISOFS -DMFS -DNFSCLIENT -DNFSSERVER -DNFS -DFFS -DINET -DDEVPAGER -DVNODEPAGER -DSWAPPAGER -DQUOTA -DFPCOPROC -DFPSP -DKERNEL -Dmc68030 -Damiga -DREFBIT -DTIMEZONE=-570 -DDST=1 -DMAXUSERS=16 -DMAXFDESCS=2048 ../../../../arch/amiga/amiga/machdep.c ../../../../arch/amiga/amiga/machdep.c: In function `bootsync': ../../../../arch/amiga/amiga/machdep.c:1029: `bfreelist' undeclared (first use this function) ../../../../arch/amiga/amiga/machdep.c:1029: (Each undeclared identifier is reported only once ../../../../arch/amiga/amiga/machdep.c:1029: for each function it appears in.) ../../../../arch/amiga/amiga/machdep.c: In function `boot': ../../../../arch/amiga/amiga/machdep.c:1093: warning: `volatile' function does return *** Error code 1 Well after I saw this I decided to sup and try again, but It didn't help. Any info? Thanks. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 25 09:05:45 1994 From: niklas@appli.se (Niklas Hallqvist) To: cgd@postgres.Berkeley.EDU Cc: chopps@sun-lamp.CS.Berkeley.EDU Cc: amiga-dev@sun-lamp.CS.Berkeley.EDU Subject: Re: recent NetBSD changes... Sender: owner-amiga-dev@sun-lamp.CS.Berkeley.EDU >>>>> "Chris" == Chris G Demetriou writes: Chris> the recent changes i made to NetBSD which were marked as: some Chris> prototype cleanup, eliminate/replace bogus types (e.g. quad and Chris> u_quad) -> use better types (e.g. quad_t & u_quad_t in inodes), Chris> some cleanup. Chris> will probably cause the Adosfs some problems -- timevals are Chris> now replaced by 'timespec's in vnodes/stat structs, etc. Chris> the changes are obvious, but i thought you should know... Thanks, it's always nice to be aware of what changes causes problems. To the amiga-developpers: I'm going away for some weeks (military service). If anyone wants to, they can dig up the ADOSFS code and make the necessary changes to it. If you do this, please add the new fstype handling, it's no big deal. Protect the old way with COMPAT_09. Look at the ufs to see how to do it. You may need to change the LKM loading code as well, if you do, use COMPAT_09 there as well. I've run NetBSD without COMPAT_09 since CGD invented the new fstype, it's quite stable. I suggest we make a GENERIC binary without COMPAT_09, either instead of the ordinary GENERIC kernel or as well as that one. Probably a user-land upgrade kit would be nice, with fsck newfs mount* and all others that depend on mount.h! If noone does the ADOSFS changes, I'll make them early June. Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 25 09:06:26 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: where is bfreelist? To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 316 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I fixed this yesterdya you should see it after supscan today. (I missed the scan by not much I guess) I've been doing lots of stuff and since I have one machine I can't risk supping everyday and after major changes (like the ones happening recently.) So it takes a couple days for me to catch this stuff. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 25 11:38:22 1994 From: Rohan Beckles Subject: NetBSD Graphics & Sound To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu What Amiga facilities does NetBSD support? I mean, does it have support for the Amiga's native sound? What about Gfx under X11? Does it support cards like the EGS standard, Picasso II, and will it support RTG when it becomes available(don't hold your breath!)? Rohan Beckles dzrec@wmin.ac.uk From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 25 13:50:54 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "NetBSD Graphics & Sound" (Apr 25, 9:28am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Rohan Beckles , amiga@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD Graphics & Sound Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 25, 9:28am, Rohan Beckles wrote: > Subject: NetBSD Graphics & Sound > What Amiga facilities does NetBSD support? I mean, does it have support for > the Amiga's native sound? Yes - NetBSD enables you to write that support yourself - and it's quite easy :-) (Just noone ever bothered with it yet). Currently you can just make the machine 'beep'. > What about Gfx under X11? Does it support cards like the EGS standard, Picasso > II, and will it support RTG when it becomes available(don't hold your > breath!)? X11 does work for native custom chips and on the Retina board. RTG is already supported (just not Amiga-DOS RTG :-). In the works is a view-device for Picasso II board, will run X11 on it. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 25 15:03:41 1994 From: Rohan Beckles Subject: AmigaDOS & UNIX To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu A couple more questions: 1. Can you boot from NetBSD on the HD? 2. Can you run AmigaDos and NetBSD/X11 concurrently, assuming you have enough memory? Rohan Beckles dzrec@wmin.ac.uk. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 25 17:43:21 1994 From: dvb@ssd.kodak.com (Dave Blaszyk) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Help Content-Length: 919 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I am trying to install rootfs_720, onto a hard drive controlled by a 2091, 'dcp' and 'filetodev' reference 'scsi.device', which on the installation disk for version1.3, doesn't exist. NOTE: Actually, I am using a IVS vector for NetBSD, but it doesn't seem to "behave" when working with either filetodev or dcp. I haven't quite figured out why... [Q] Is there a 2.x installation disk for A2091? NOTE: If the above is yes, then I assume 'scsi.device' is on this disk. How do I go about getting the disk, do I really have to ask Commodore to ship me this? I really don't want to wait! [Q] If 'scsi.device', is not on the disk, is it on the 2.x systems disk? /-// \\-\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 Mon Apr 25 17:45:42 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "AmigaDOS & UNIX" (Apr 25, 12:52pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Rohan Beckles , amiga@sun-lamp.cs.berkeley.edu Subject: Re: AmigaDOS & UNIX Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 25, 12:52pm, Rohan Beckles wrote: > Subject: AmigaDOS & UNIX > A couple more questions: > > 1. Can you boot from NetBSD on the HD? Pardon? You can boot NetBSD using the 'loadbsd' command from within ADos. Or what do you mean? > 2. Can you run AmigaDos and NetBSD/X11 concurrently, assuming you have enough > memory? Nope. Would require heavey changes - is not intended yet. Problem: Amiga-DOS has no memory protection sheme and every lousy programm can destroy/overwrite memory - even the running NetBSD-memory, hence this would require a very tricky scheduler. Please don't compare this facts with the AUX from Apple, Mac-Finder- Programms are monotasking and easy to protect. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Apr 25 17:55:03 1994 From: mbeausej@qc.bell.ca (michel beausejour) To: amiga@sun-lamp.cs.berkeley.edu Subject: new kernel Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm trying to compile my own kernel,so i've downloaded the tar_file sys.tar.gz from sun-lamp which was dated of the 16 april 1994. I installed it and try to compile.I'm stuck with the following error: ../../../../kern/sys_process.c no member in structure for 'v_page_size' in procedure pread.Well i see no assignment for v_page-size in the source of sys_process.c!!!!! So i checked the include files and vm_page.c contains an assigment in procedure vm_set_page_size but i don't think ir's related. Bye Michel Beausejour mbeausej@qc.bell.ca From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 25 18:14:11 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Help" (Apr 25, 10:26am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: dvb@ssd.kodak.com (Dave Blaszyk) Subject: Re: Help Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 25, 10:26am, Dave Blaszyk wrote: > Subject: Help > > I am trying to install rootfs_720, onto a hard drive controlled by a 2091, > 'dcp' and 'filetodev' reference 'scsi.device', which on the installation > disk for version1.3, doesn't exist. Neither 'dcp', 'filetodev' nor 'scsi.device' are on any Commodore-disks. > NOTE: Actually, I am using a IVS vector for NetBSD, but it doesn't seem to > "behave" when working with either filetodev or dcp. I haven't quite > figured out why... Probably can't deal with SCSI-Commands. [...] scsi.device is in the ROM on the a2091, how would you elsewise start the harddrive-support, booting off scsi.device from floppy? On a wild guess, id' say your dcp is either broken, or the options were not correct. How did you start dcp? (Please delete filetodev - very unsafe and dcp is lot easier to handle with). -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Apr 25 21:50:59 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Help To: dvb@ssd.kodak.com (Dave Blaszyk) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 720 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I am trying to install rootfs_720, onto a hard drive controlled by a 2091, > 'dcp' and 'filetodev' reference 'scsi.device', which on the installation > disk for version1.3, doesn't exist. > > NOTE: Actually, I am using a IVS vector for NetBSD, but it doesn't seem to > "behave" when working with either filetodev or dcp. I haven't quite > figured out why... First go grab device-streams from eunet. NExt you probably need to figure out what device the IVS uses (intuitively it seems it would be `ivsscsi.device' > > [Q] Is there a 2.x installation disk for A2091? [..] > [Q] If 'scsi.device', is not on the disk, is it on the 2.x systems disk? It is in the rom of any autobooting controller. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 26 00:44:22 1994 From: rhealey@aggregate.com Subject: DDB always hurls on stack backtrace. 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: 346 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Has anybody been able to get DDB to NOT cause an MMU fault when you request a stack backtrace? It always causes an MMU fault after printing out the top level function. Is it flying off the end of the frames for some reason? Other than this rather annoying misfeature DDB is proving to be VERY useful in debugging some kernel code. -Rob From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 26 01:46:40 1994 From: phil@gradient.com (Phil Mucci) To: amiga-x@sun-lamp.cs.berkeley.edu, phb@colombo.telesys-innov.fr Subject: Re: New X color servers with source code Content-Length: 341 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > host colombo.telesys-innov.fr > > Have fun! > > -- > Philippe BRAND Philippe, would it be possible for you to tar and gzip up the starting at the ddx/absd point? Myself and Arno Griffen of the Linux project are in the process of planning a graphix device layer and would love to see this source. Any possibility? Thanks! -Phil From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 26 01:48:12 1994 From: Hartmut Kuehn Subject: Re: Supra and Oktagon ??!! To: osymh@gemini.oscs.montana.edu, 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: 1692 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi ! > > No support for any NCR-based Adapter yet working, and i don't share > > your opinion on that 'coolest' adapter. Oktagon is a PIO-Adapter > > with no DMA capabilities. Thus it is quite hard to implement service > > for this one. > > I beg to differ... The current kernel has support for the Supra Wordsync > (series 2, I think), CSA 12 Gauge, IVS Vector, and my home-built SCSI Really ??!! That would be a great thing for a friend of mine who is suffering so long with his Supra Word Sync Series 3. Do you know if the current kernel can be patched to work with the Series 3, there can't be much differnces between 2 and 3 ??!! If it's possible, here are the config-ids: Manufacturer ID is 1056, Prod. ID is 12 (decimal) (showconfig says Prod=1056/12). BTW: Where are the sources for this kernel ? The only thing I found was the 744-src-distribution (which has no supra) and something in incoming/experimental, which seems to have arch/amiga/dev/supradma.c in the file conf/files.amiga. But where do I find a src-dist. with this files ?? Thanks in advance for any help, hope the Series 3 will be supported soon !!! ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@cs.tu-berlin.de * * (or kuehaaaf@w250zrz.zrz.tu-berlin.de) * * BITNET: KUEHN@DB0TUI11.BITNET * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 26 05:49:42 1994 Subject: source:not found / Updating Binaries To: amiga@sun-lamp.cs.berkeley.edu From: "Danny Lepage" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 626 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I installed the 940319 binaries set and since then, I get "source:not found" just after booting with NetBSD. (I use the 940417 kernel from sun-lamp in arch/amiga, and get this problem with either the 940319 and 940417 distribution sets). May someone shed some light on me please? Also, I'd like to know what is the proper procedure to install new sets of binaries (/bin, /sbin, /usr/bin, /usr/sbin, /usr/lib, /usr/libexec, etc.), I mean, should I Install the newer set on top of the old one, or should I remove the originals directories before? Any help would be greatly appreciated. Danny Lepage dlepage@Altitude.CAM.ORG From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 26 05:49:43 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: source:not found / Updating Binaries To: dlepage@CAM.ORG (Danny Lepage) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I installed the 940319 binaries set and since then, > I get "source:not found" just after booting with NetBSD. > (I use the 940417 kernel from sun-lamp in arch/amiga, > and get this problem with either the 940319 and 940417 > distribution sets). > May someone shed some light on me please? This is because the file /etc/profile was written for bash not normal sh. The source command is invalid in sh. You can get rid of this error message by either getting bash and installing it on your system or by replacing the /etc/profile script with something more appropriate. > Any help would be greatly appreciated. > > Danny Lepage > dlepage@Altitude.CAM.ORG From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 26 10:48:01 1994 From: Philippe BRAND Subject: Re: New X color servers with source code To: phil@gradient.com (Phil Mucci) Cc: amiga-x@sun-lamp.cs.berkeley.edu Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 501 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Phil Mucci writes: > Philippe, would it be possible for you to tar and gzip up the > starting at the ddx/absd point? Myself and Arno Griffen of the Linux > project are in the process of planning a graphix device layer and > would love to see this source. Any possibility? Ahem... I'm afraid my english is not as good as I thought. I think I understand here that you want an archive with only ddx/absd tree inside ? -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Co-Sysop 2:320/104.21 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 26 22:28:09 1994 From: Arthur Hoffmann Subject: New kernel break programmes. To: amiga-dev@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: 1071 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi I just sent a message before mentioning that I couldn't buld new kernels anymore, some problem with ranlib. the problem seems to be the new kernels. I suped the changes for 26.04.1994 and build the kernel, booted my machine with it and the problems started. Like building another kernel didn't work, as described in another mail. Then I wanted to run term, which didn't work either, so I tried to recompile it (term that is) but I got stuck with this: rm -f client.a ar rc client.a lib.o client.o terminal.o select.o socket.o connect.o ranlib client.a ranlib: client.a: Inappropriate file type or format gmake[1]: *** [client.a] Error 1 gmake[1]: Leaving directory `/tmp/term114' gmake: *** [netbsd] Error 1 When I went back to my old kernel and booted with that I could build kernels again, term worked and all the rest was btter as well. Did I miss something? btw. I'm using the latest binaries from sun-lamp. Thanks for any info. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Apr 26 22:45:58 1994 From: Arthur Hoffmann Subject: What's wrong with libkern.a? To: amiga-dev@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: 709 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I have been compiling the kernel from today and all seems to be fine, until the following happens: making sure the kern library is up to date... loading netbsd ld: malformed input file (not rel or archive) /home2/src/sys/lib/libkern/libkern.a *** Error code 1 Stop. I then went a and made a new ranlib, ld and ld.so and removed libkern.a, but it didn't change a thing. Anyone know what's wrong? Before I started I did a make clean in /home2/src/sys/lib/libkern, so that the kern library would be built new. I did this before with older kernels and never had this problem. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 26 23:02:49 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: New X color servers with source code" (Apr 26, 9:44am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Philippe BRAND , phil@gradient.com (Phil Mucci) Subject: Re: New X color servers with source code Cc: amiga-x@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Apr 26, 9:44am, Philippe BRAND wrote: > Subject: Re: New X color servers with source code > Phil Mucci writes: > > > Philippe, would it be possible for you to tar and gzip up the > > starting at the ddx/absd point? Myself and Arno Griffen of the Linux > > project are in the process of planning a graphix device layer and > > would love to see this source. Any possibility? > > Ahem... I'm afraid my english is not as good as I thought. I think I > understand here that you want an archive with only ddx/absd tree inside ? I wonder what use is the ddx-tree for the graphics layer for Linux? Rather more interesting are the ioctl's in the kernel (views). -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Apr 26 23:27:15 1994 From: phil@gradient.com (Phil Mucci) To: phil@gradient.com Cc: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: New X color servers with source code Content-Length: 399 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu --------- Received message begins Here --------- > I wonder what use is the ddx-tree for the graphics layer for Linux? > > Rather more interesting are the ioctl's in the kernel (views). One step ahead of you there Markus...their already being developed. We just wanted to see some sample ddx code - especially stuff that deals with different pixel formats. (bitplane vs. chunky) -Phil From owner-amiga@sun-lamp.cs.berkeley.edu Tue Apr 26 23:47:25 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Supra and Oktagon ??!!" (Apr 26, 12:42am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Hartmut Kuehn , osymh@gemini.oscs.montana.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Supra and Oktagon ??!! Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 26, 12:42am, Hartmut Kuehn wrote: > BTW: Where are the sources for this kernel ? The only thing > I found was the 744-src-distribution (which has no supra) > and something in incoming/experimental, which seems to have > arch/amiga/dev/supradma.c in the file conf/files.amiga. > But where do I find a src-dist. with this files ?? Forget about to search in the NetBSD-Amiga tree for any recent kernel. Everything is now moved to NetBSD-current, thanks to Chopps, which includes the Amiga specific stuff, too. > Thanks in advance for any help, hope the Series 3 will be > supported soon !!! Psion Series 3 is supported :-) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 27 04:50:55 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: I get these errors building a kernel, any ideas Sender: owner-amiga@sun-lamp.cs.berkeley.edu sh ../../../../conf/newvers.sh ICEBERG gcc -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DICEBERG -DA3000 -DMAPMEM -DKTRACE -DCOMPAT_43 -DTCP_COMPAT_42 -DDIAGNOSTIC -DMFS -DFIFO -DQUOTA -DINET -DKERNEL -Dmc68020 -Damiga -DREFBIT -c vers.c making sure the kern library is up to date... loading vmunix locore.o: Undefined symbol _ser_fastint referenced from text segment init_main.o: Undefined symbol _pdevinit referenced from text segment vfs_syscalls.o: Undefined symbol _vnode_pager_umount referenced from text segment vfs_syscalls.o: Undefined symbol _vnode_pager_uncache referenced from text segment vfs_vnops.o: Undefined symbol _vnode_pager_uncache referenced from text segment ufs_alloc.o: Undefined symbol _vnode_pager_uncache referenced from text segment ufs_bmap.o: Undefined symbol _vnode_pager_setsize referenced from text segment ufs_inode.o: Undefined symbol _vnode_pager_setsize referenced from text segment ufs_inode.o: Undefined symbol _vnode_pager_uncache referenced from text segment ufs_vnops.o: Undefined symbol _vnode_pager_uncache referenced from text segment ufs_vnops.o: Undefined symbol _vnode_pager_setsize referenced from text segment ufs_vnops.o: Undefined symbol _vnode_pager_uncache referenced from text segment conf.o: Undefined symbol _seropen referenced from data segment conf.o: Undefined symbol _serclose referenced from data segment conf.o: Undefined symbol _serread referenced from data segment conf.o: Undefined symbol _serwrite referenced from data segment conf.o: Undefined symbol _serioctl referenced from data segment conf.o: Undefined symbol _serstop referenced from data segment conf.o: Undefined symbol _ser_tty referenced from data segment conf.o: Undefined symbol _kbdopen referenced from data segment conf.o: Undefined symbol _kbdclose referenced from data segment conf.o: Undefined symbol _kbdread referenced from data segment conf.o: Undefined symbol _kbdwrite referenced from data segment conf.o: Undefined symbol _kbdioctl referenced from data segment conf.o: Undefined symbol _kbdselect referenced from data segment cons.o: Undefined symbol _sercnprobe referenced from data segment cons.o: Undefined symbol _sercninit referenced from data segment cons.o: Undefined symbol _sercngetc referenced from data segment cons.o: Undefined symbol _sercnputc referenced from data segment machdep.o: Undefined symbol _sun_sigreturn referenced from text segment machdep.o: Undefined symbol _vnode_pager_umount referenced from text segment machdep.o: Undefined symbol _ser_outintr referenced from text segment swapgeneric.o: Undefined symbol _sddriver referenced from data segment swapgeneric.o: Undefined symbol _sddriver referenced from data segment *** Error code 1 Stop. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 27 05:25:16 1994 From: DCG9367@tntech.edu Subject: Problems with vmunix0325 and 0415 binaries 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 have recently gotten the latest binaries dated April 15 ( i think) from sun-lamp and the newest kernel dated March 25. I was running the new kernel fine, and extract the bin.tar.gz Everything extracted fine except sh (busy text file) and [ (link exists). Si I thought fine, Ill just make the remke the link. Well as soon as I went to /bin and did an ls i got this: root@lockerbox(1) ls -la Bad System Call root@lockerbox(2) HELP!! I can't seem to find a newer kernel. The README in the bin directory on sun-lamp refers to the kernels being there, but I couldn't find them. Are the April 15 binaries compatible with the March 25 kernel? Where can I get a later kernel? David. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 27 05:46:14 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Cron & setreuid stuff To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) 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@sun-lamp.cs.berkeley.edu Cron ( atrun ) seems to have a problem with the setreuid function. I keep getting mail from it stating this every 10 minutes. It's mildly annoying. Anyone have a fix or something?? From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 27 08:44:43 1994 Subject: Segm. fault with sun-lamp /usr binaries To: amiga@sun-lamp.cs.berkeley.edu From: "Danny Lepage" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1251 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Setup: A3000 16Mhz, 2Meg Chip, 4Meg Fast Quantum 50Meg (sd6b 8 Meg -> swap) Fujitsu 520Meg (sd0a 15 Meg -> root, sd0d 218 Meg -> /usr, sd0e 80 Meg -> /home) Kernel: NetBSD 0.9a (GENERIC) #0: Sat Apr 16 22:35:42 EDT 1994 sjr@istari: /usr/local/src/NetBSD-current/sys/arch/amiga/compile/GENERIC ( latest from sun-lamp) Binaries, libs etc. : latest from sun-lamp 1) Ok, I can boot fine in single user mode except for "[: not found" 2) The executables from /bin, /sbin seems to work fine, but the ones from /usr/bin, /usr/sbin (more, ldd, man, users, vmstat) give me a segmentation fault - core dump 3) Trying to execute MAKEDEV from /etc gime me the following error: ./MAKEDEV: 282: Syntax error: word unexpected (expecting ")") This is the MAKEDEV found in dev.tar.gz from sun-lamp latest distribution. Naturally, I can't boot in multi-user 'cause all the deamons barf with : segmentation fault - core dump :) (Anyway, going MU for now won't give anything, as I can't vipw {you bet, it core dumps too} thus, I won't be able to log with any USERID. Somebody has any idea, suggestion, etc. to give me? Thanks in advance. Danny Lepage dlepage@Altitude.CAM.ORG Some body has any idea, suggestion etc... From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 27 08:56:23 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Recent problems. To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2642 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I have been seeing alot of problems recently regarding the bins on lamp. Id like to make a few comments. 1) I have no way to test these I took steve's word that hetested them as much as possible. I doubt very much that he was getting core dumps from any command run that was not statically linked. What that makes me think is that something is amiss in thetransfer of the binaries from the tar files to the filesystem. The best way to do things is to backup everything. then *delete* all the directoriees your going to be replacing leaving of course the ones like etc where you have configured you own stuff. Make sure however that you do not delete binaries that you need to install things. 2) You must be running the kernel that goes with the binary set. Normally this is not an issue but lately major changes have taken place that don't allow mixing.. its all part of running current I gues. If you installing new binaries on top of old binaries and running an older kernel your going to get yourself in trouble as the new binaries want the new kernel. I imagine this may be causing most of the problems. On a slightly related topic: I posteed recently in comp.unix.amiga asking for donation of a second machine and more storage space. So far it has been the concencus that users will send money ($50-100) to me with a SASE so that I may return all of it if I do not gather enough for something usefull. One thing I need despretley is more HD space the only reason I do not build the snapshots is becuase I simply have no space. My sytem is configured to run all static linked bins so I don't even have enough space to create a snapshot of that. I gave a bunch of reasons for the machine in my post so go see it if your interested. Mainly its for future support I have no 040 so I cannot test that I have no AGA so I cannot write support or test for that. I have no HD space so I cannot assit in keeping an X distribution current with the rest of the system. I currently run on a 22Mhz 030 with slow DMA so it takes a long time for things to happen Like and 1 and 1/4 hours (takes about 15 minutes on an 040) for a kernel build alone. I have to test my changes on the same machine I develop on etc etc. etc. I don't feel bad about asking as I put alot of work into NetBSD and I have no job currently (which needs to change *real* fast.) Send me some mail if you have anything to donate or would like to talk about it. (repsone has been light so far perhaps 4 people I need 40 people at $100 for the system less for just adding more space and such) Thanks to anyone who helps your really helping NetBSD amiga. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 27 09:03:36 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Recent problems. To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2642 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have been seeing alot of problems recently regarding the bins on lamp. Id like to make a few comments. 1) I have no way to test these I took steve's word that hetested them as much as possible. I doubt very much that he was getting core dumps from any command run that was not statically linked. What that makes me think is that something is amiss in thetransfer of the binaries from the tar files to the filesystem. The best way to do things is to backup everything. then *delete* all the directoriees your going to be replacing leaving of course the ones like etc where you have configured you own stuff. Make sure however that you do not delete binaries that you need to install things. 2) You must be running the kernel that goes with the binary set. Normally this is not an issue but lately major changes have taken place that don't allow mixing.. its all part of running current I gues. If you installing new binaries on top of old binaries and running an older kernel your going to get yourself in trouble as the new binaries want the new kernel. I imagine this may be causing most of the problems. On a slightly related topic: I posteed recently in comp.unix.amiga asking for donation of a second machine and more storage space. So far it has been the concencus that users will send money ($50-100) to me with a SASE so that I may return all of it if I do not gather enough for something usefull. One thing I need despretley is more HD space the only reason I do not build the snapshots is becuase I simply have no space. My sytem is configured to run all static linked bins so I don't even have enough space to create a snapshot of that. I gave a bunch of reasons for the machine in my post so go see it if your interested. Mainly its for future support I have no 040 so I cannot test that I have no AGA so I cannot write support or test for that. I have no HD space so I cannot assit in keeping an X distribution current with the rest of the system. I currently run on a 22Mhz 030 with slow DMA so it takes a long time for things to happen Like and 1 and 1/4 hours (takes about 15 minutes on an 040) for a kernel build alone. I have to test my changes on the same machine I develop on etc etc. etc. I don't feel bad about asking as I put alot of work into NetBSD and I have no job currently (which needs to change *real* fast.) Send me some mail if you have anything to donate or would like to talk about it. (repsone has been light so far perhaps 4 people I need 40 people at $100 for the system less for just adding more space and such) Thanks to anyone who helps your really helping NetBSD amiga. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 27 10:17:34 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: New kernel break programmes. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: amiga-dev@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: 1789 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm pretty much in the same boat as you. I'm running a fairly new kernel now with binaries from the 17Apr94 snapshots on ftp.iastate.edu. It looks like the kernel or some binaries have trouble because of the recent changes. I'll bet if you looked at the offending archive file you would see that its length is zero. Beware of strip, because it will strip files down to nothing as well. In the case of strip, the problem appears to be the ftruncate() call. I don't know if ar uses ftruncate() too, but we shall see. Of course, now I'm getting occasional bursts of "ser_fastint: buffer overflow" messages as well. Never a dull moment! > > Hi > I just sent a message before mentioning that I couldn't buld new > kernels anymore, some problem with ranlib. > the problem seems to be the new kernels. > I suped the changes for 26.04.1994 and build the kernel, booted my > machine with it and the problems started. > Like building another kernel didn't work, as described in another > mail. Then I wanted to run term, which didn't work either, so I tried > to recompile it (term that is) but I got stuck with this: > > rm -f client.a > ar rc client.a lib.o client.o terminal.o select.o socket.o connect.o > ranlib client.a > ranlib: client.a: Inappropriate file type or format > gmake[1]: *** [client.a] Error 1 > gmake[1]: Leaving directory `/tmp/term114' > gmake: *** [netbsd] Error 1 > > When I went back to my old kernel and booted with that I could build > kernels again, term worked and all the rest was btter as well. > Did I miss something? > > btw. I'm using the latest binaries from sun-lamp. > > Thanks for any info. > > Arthur. > > __ > Arthur Hoffmann 58/1 Dickward Drive > Fannie Bay N.T. 0820 > hoffmann@it.ntu.edu.au Darwin - Australia. > > From owner-amiga@sun-lamp.cs.berkeley.edu Wed Apr 27 21:05:27 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Segm. fault with sun-lamp /usr binaries" (Apr 26, 10:41pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Danny Lepage" , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Segm. fault with sun-lamp /usr binaries Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 26, 10:41pm, "Danny Lepage" wrote: > Kernel: NetBSD 0.9a (GENERIC) #0: Sat Apr 16 22:35:42 EDT 1994 > sjr@istari: /usr/local/src/NetBSD-current/sys/arch/amiga/compile/GENERIC > ( latest from sun-lamp) Hm, quite new. > Binaries, libs etc. : latest from sun-lamp You sure? > 1) Ok, I can boot fine in single user mode except for > "[: not found" [ is a programm which normaly resides in either /bin or /sbin. > 2) The executables from /bin, /sbin seems to work fine, but the > ones from /usr/bin, /usr/sbin (more, ldd, man, users, vmstat) give me a > segmentation fault - core dump Hmmm. Looks like the binaries don't match with your kernel. Please check with either older binaries or older kernel, if older kernel works ok, then your binaries are too old for your current kernel. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Apr 27 22:07:26 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: New kernel break programmes. To: ahh@netcom.com (Andy Heffernan) Cc: hoffmann@it.ntu.edu.au, amiga-dev@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: 798 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I'm pretty much in the same boat as you. I'm running a fairly > new kernel now with binaries from the 17Apr94 snapshots on > ftp.iastate.edu. It looks like the kernel or some binaries have > trouble because of the recent changes. I'll bet if you looked at the > offending archive file you would see that its length is zero. Beware > of strip, because it will strip files down to nothing as well. In the > case of strip, the problem appears to be the ftruncate() call. I don't > know if ar uses ftruncate() too, but we shall see. I tried using older, pre-off_t strip and ar binaries after setting up a link to libc.so.4.0, but they have the same problem, even though they use the old syscall which should lead them to oftruncate(). (Verified using ktrace.) Time to start digging... From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Apr 28 00:33:24 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: New kernel break programmes. To: chopps@emunix.emich.edu (Chris Hopps) Cc: ahh@netcom.com, hoffmann@it.ntu.edu.au, amiga-dev@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: 480 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > > > I tried using older, pre-off_t strip and ar binaries after > > setting up a link to libc.so.4.0, but they have the same problem, even > > A link to what? The reason the major number changes is becuase the > library is totaly incompatible with other versions. OK, fine. I didn't do anything with links. I waved my hands mystically and made the old library available to the old programs, while simultaneously making the new library available to the new programs. ******************** ------- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Apr 28 01:10:32 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: New kernel break programmes. To: ahh@netcom.com (Andy Heffernan) Cc: ahh@netcom.com, hoffmann@it.ntu.edu.au, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 268 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I tried using older, pre-off_t strip and ar binaries after > setting up a link to libc.so.4.0, but they have the same problem, even A link to what? The reason the major number changes is becuase the library is totaly incompatible with other versions. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Apr 28 07:46:54 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: New kernel break programmes. To: ahh@netcom.com (Andy Heffernan) Cc: hoffmann@it.ntu.edu.au, amiga-dev@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: 1367 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu [blah blah -- more of the same] > I tried using older, pre-off_t strip and ar binaries after > setting up a link to libc.so.4.0, but they have the same problem, even > though they use the old syscall which should lead them to > oftruncate(). (Verified using ktrace.) Time to start digging... Folks with ftruncate() problems might want to try this patch: *** sys/ufs/ufs_vnops.c-orig Mon Apr 25 03:29:15 1994 --- sys/ufs/ufs_vnops.c Wed Apr 27 21:19:06 1994 *************** *** 275,281 **** if (vap->va_size != VNOVAL) { if (vp->v_type == VDIR) return (EISDIR); ! if (error = itrunc(ip, vap->va_size, 0)) /* XXX IO_SYNC? */ return (error); } if (vap->va_atime.ts_sec != VNOVAL || vap->va_mtime.ts_sec != VNOVAL) { --- 275,281 ---- if (vap->va_size != VNOVAL) { if (vp->v_type == VDIR) return (EISDIR); ! if (error = itrunc(ip, (u_long)vap->va_size, 0)) /* XXX IO_SYNC? */ return (error); } if (vap->va_atime.ts_sec != VNOVAL || vap->va_mtime.ts_sec != VNOVAL) { This fixes both ar and strip for me. The semantics of long long elude me when it comes to parameter passing; I would expect the compiler to implicitly typecast vap->va_size (which is a long long) to int (which is what itrunc() wants) but I guess I am wrong. I wonder if byte-ordering is what has kept this from being an issue with the 386 folks... From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 28 09:16:24 1994 From: Rafael Munoz Subject: screen and NetBSD... To: amiga@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi all, Has anyone been able to compile screen under NetBSD on the Amiga? I have all the latest /usr/include files (bin-usrinclude940319...), and when I try to compile it (make install), there are tons of warnings regarding the second argument for signal(), I see no compiler errors, just warnings, then the compilation stops with an Error 1, and that is it... If I had an error, I would be able to fix it (last year I had obtained screen for my HPUX 705 workstation to use when I would call in to work, so I had the experience of compiling it already). Any info would be appreciated! -- ***************************************************************************** * Rafael Munoz Internet: erm008@comm.mot.com * * Motorola, Inc * * Plantation, FL Bix : rmunoz@bix.com * * 305-475-6298 GEnie : rmunoz * ***************************************************************************** From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 28 11:16:49 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: Mirroring NetBSD-current for Amiga From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello, since we have a mirror running from ftp.eunet.ch for NetBSD-Amiga, and everything seems to have moved to NetBSD-current, I was wondering if we should change our mirroring to another site that has the Amiga stuff for NetBSD-current. I'm now occassionally getting stuff from ftp.iastate.edu. Can we use that site for mirroring or is there a better site ? Our mirror machine is located in Sweden. Is there a machine closer than ftp.iastate.edu for this purpose ? John Vrolijk From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Apr 28 11:34:34 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: New kernel break programmes. To: ahh@netcom.com (Andy Heffernan) Cc: hoffmann@it.ntu.edu.au, amiga-dev@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: 226 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Folks with ftruncate() problems might want to try this patch: I just got word from Chris Demetriou that the UFS truncate problem has been fixed (by using prototypes), so you should be able to sup and be back in business. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 28 13:50:07 1994 From: Andreas Heitmann To: dsnjvro@etmsun.ericsson.se Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Mirroring NetBSD-current for Amiga Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "John" == John Vrolijk writes: John> Hello, since we have a mirror running from ftp.eunet.ch for John> NetBSD-Amiga, and everything seems to have moved to John> NetBSD-current, I was wondering if we should change our John> mirroring to another site that has the Amiga stuff for John> NetBSD-current. John> I'm now occassionally getting stuff from ftp.iastate.edu. John> Can we use that site for mirroring or is there a better site John> ? Our mirror machine is located in Sweden. Is there a John> machine closer than ftp.iastate.edu for this purpose ? Hi ! Recently I installed a mirror from sun-lamp on ftp.hrz.uni-kassel.de. It mirrors some releases of NetBSD-current (ksrc-amiga, ksrc-common,src). Mirroring takes place daily at 7:00am CEDT. Mail me for more details. Greetings, Andreas Heitmann (heitmann@crunch.ikp.physik.th-darmstadt.de) "Hey, it's Unix! I know this!" Lex, Jurassic park. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 28 15:04:47 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Mirroring NetBSD-current for Amiga" (Apr 28, 11:23am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Andreas Heitmann , dsnjvro@etmsun.ericsson.se Subject: Re: Mirroring NetBSD-current for Amiga Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 28, 11:23am, Andreas Heitmann wrote: > Recently I installed a mirror from sun-lamp on ftp.hrz.uni-kassel.de. > It mirrors some releases of NetBSD-current (ksrc-amiga, > ksrc-common,src). Mirroring takes place daily at 7:00am CEDT. Mail me > for more details. I'd figure that Kassel would be of no help for him, as Sweden has a direct line to the US and only a slow gateway to the german WIN. At that speed he could also poll from sun-lamp directly :-) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Apr 28 15:57:39 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Perl To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 157 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Has anyone been able to compile perl-4.036 with the sun-lamp source dated april 16th?? I am trying to compile perl and it dies out on the doio.c file. Ron From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Apr 28 19:13:44 1994 From: Arthur Hoffmann Subject: panic swfree... To: amiga-dev@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: 902 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I have been trying to compile a new kernel from the current sources for a few days now and encountered a few problems. Thank you all for the help and hints I got so far. Today I finally was able to compile a new kernel for my A3000, but when I try to boot the system with it I get the following error: panic swfree stopped at _Debugger+0x6 _Debugger+$7fffffff: unlk a6 Does anyone know what that is related to? Another thing I noticed over the last couple of weeks is that I get TIMEO errors again when the SCSI controller tries to negotiate sync mode, I don't know why. I did buy the WD33C93A-PL 00-08 and put it into the computer. It worked great at first, but now... Thanks again for your help. (I used the sources which I suped with the changes from 29.04.1994) Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 hoffmann@it.ntu.edu.au Darwin - Australia. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 29 07:21:33 1994 Subject: NetBSDi(lee.HP.AM.G(ite0 ??? To: amiga@sun-lamp.cs.berkeley.edu From: "Danny Lepage" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1294 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Ok, I don't have segmentation fault anymore. The problem seems to be dcp, you was corrupting / truncating some files. (I used bffs instead of dcp to transfer from ADOS to NetBSD and my core dump problem has gone). I'm now able to go multi-user (after adding some memory, 4 Meg Fast don't seems to be enough) but the following problem: (I'm using the newest kernel / binaries from sun-lamp arch/amiga). 1) I got the following as a login prompt (just after booting multi-user): NetBSDi(lee.HP.AM.G(ite0 loi: After login, all is fine. using login to log as another user pose no problem, but after a logout, I get the above login prompt. Seems that getty is having some problem. is'nt it? Any idea of what my be the problem? 2) I can't get swapinfo to work properly, it gives me: swapinfo: panic : nswapmap goof I mounted my swap partition as follow: /dev/sd6b /tmp mfs rw,-s65536 0 0 My system: A3000 16 Mhz 2Meg Chip, 16Meg Fast, sd6b (swap partition) 40 Meg. I used -s65536 to get ~ 32 Meg of swap space since I have 16 Meg of mem. Is this done correctly ? Can this Be related with problem 2? Well, thanks to everyone that helped me so far, and thanks to everybody that maked NetBSD-amiga possible. Danny Lepage poutine@M3iSystems.QC.CA dlepage@Altitude.CAM.ORG From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 29 12:10:35 1994 From: rbungen@attmail.com (R. R. Bungener) To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: rbungen@hvlpa.att.com Phone: +3135871526 Fax-Phone: +3135875811 Subject: Problem with SunLamp binaries Content-Type: Text Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello, Last night, why is it always night, I installed the binaries and kernel from ftp.iastate.edu and the following happend : 1. I used my old kernel (730 on a 720 rootfs) and, ofcourse I gat those bad systems calls. 2. Then I swapped my vmunix with the new version from iastate and I got the following report : >>> NetBSD 0.9a (GENERIC) #0 SAT MAR 26 .... >>> sjr@ ....... >>> realmem=6291456 >>> avail mem= 3555328 >>> using 51 buffers containing 417792 bytes of memory >>> 0 Amiga memory segments >>> Realtime clock A2000 >>> rtclock0 [1/9] >>> par0 [1/6] >>> grf0: 640x400 ..... >>> grf0 [1/7] >>> ser0 [1/3] >>> no suitable root Is there anyone there knowing what to next ? Thanks Robert R. Bungener Email : rbungen@hvlpa.att.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 29 16:18:44 1994 From: rbungen@attmail.com (R. R. Bungener) To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: rbungen@hvlpa.att.com Phone: +3135871526 Fax-Phone: +3135875811 Subject: Problem with SunLamp binaries Content-Type: Text Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello, Last night, why is it always night, I installed the binaries and kernel from ftp.iastate.edu and the following happend : 1. I used my old kernel (730 on a 720 rootfs) and, ofcourse I gat those bad systems calls. 2. Then I swapped my vmunix with the new version from iastate and I got the following report : >>> NetBSD 0.9a (GENERIC) #0 SAT MAR 26 .... >>> sjr@ ....... >>> Amiga 2000, 68030 (CPU+MMU), 25Mc 68882 FPU >>> realmem=6291456 >>> avail mem= 3555328 >>> using 51 buffers containing 417792 bytes of memory >>> 0 Amiga memory segments >>> Realtime clock A2000 >>> rtclock0 [1/9] >>> par0 [1/6] >>> grf0: 640x400 ..... >>> grf0 [1/7] >>> ser0 [1/3] >>> no suitable root I am using a A2000 rev. 6.1 with 6M ram and GVP GForce 030/40 with a real 68030 and : 50M HD divided sd0 with the root and swap partition of 16M 105M HD divided sd2 with 3 equal partitions Is there anyone there knowing what to next ? Thanks Robert R. Bungener Email : rbungen@hvlpa.att.com From owner-amiga@sun-lamp.cs.berkeley.edu Fri Apr 29 20:27:08 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/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC Log Message: add commented out options for selecting font. --------------------------------- From: Alien Briggs Update of /b/source/CVS/src/lib/libkvm In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/lib/libkvm Modified Files: Makefile kvm.c Log Message: Add mac68k to amiga in looking for cpu040. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: machdep.c Log Message: fix form hp300. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: grf_rt.c Log Message: don't reinit board twice if it works once. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: Locore.c pmap.c Log Message: change mmap to vmpte to avoid nameclash with the syscall. --------------------------------- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 29 23:00:48 1994 Subject: From: rbungen@hvlpa.att.com (R R Bungener +31 35 87 1526) Original-From: hvlpa!rbungen (R R Bungener +31 35 87 1526) To: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello, Back again with the same problem, but more info The problem was that after loading the new binaries and the vmunix.generic to my BSD partitions I was unable to boot up the system again. It dieds with : >>> NetBSD 0.9a (GENERIC) #0 : Sat Mar 26 ...... >>> sjr@......... >>> Amiga 2000 68030 (CPU+MMU) 25 Mc 68882 FPU >>> real mem= 6291456 >>> avail mem= 3555328 >>> using 51 buffers containing 417792 bytes of memory >>> 0 Amiga memory segments >>> Realtime clock A2000 >>> rtclock [1/9] >>> par0 [1/6] >>> grf0: 640 x 400 4 color custom ...... >>> grf0 [1/7] >>> ser0 [1/3] >>> no suitable root I am using a A2000 with a GVP GForce 030/40 (No EC) and Quantum HD id:0 with three partitions BSDR, BSDS and BSDD Quantum HD id:2 with also three partitions The rdb info looks like : gvpscsi.device unit 0 : Blk=0 HostID=7 BlockBytes=512 Flags=0x0012 LastLUN DiskValid BadBlockList=-1 PartitionList=1 FileSysHeaderList=4 DriveInit=-1 Cylinders=2343 Sectors=35 Heads=1 Interleave=1 Park=2343 StepRate=3 WritePreComp=2343 ReducedWrite=2343 RDBBlocksLo=0 RDBBlocksHi=69 LoCylinder=2 HiCylinder=2342 CylBlocks=35 AutoParkSeconds=0 DiskVendor=QUANTUM DiskProduct=P40S 940-40-94xx DiskRevision=A.2 ControllerVendor= ControllerProduct= ControllerRev= No bad blocks PART Blk=1 DriveName=BSD_ROOT DevFlags=0 HostID=7 Next=2 Mount Surfaces=1 BlocksPerTrack=35 Reserved=00000000 PreAlloc=00000000 Interleave=0 LowCyl=2 HighCyl=621 NumBuffers=30 BufMemType=0 MaxTransfer=00ffffff Mask=00fffffe BootPri=0 DosType=42534452 'BSDR' PART Blk=2 DriveName=BSD_SWAP DevFlags=0 HostID=7 Next=3 Mount Surfaces=1 BlocksPerTrack=35 Reserved=00000000 PreAlloc=00000000 Interleave=0 LowCyl=622 HighCyl=1103 NumBuffers=30 BufMemType=0 MaxTransfer=00ffffff Mask=00fffffe BootPri=0 DosType=42534453 'BSDS' PART Blk=3 DriveName=BSD_USR DevFlags=0 HostID=7 Next=-1 Mount Surfaces=1 BlocksPerTrack=35 Reserved=00000000 PreAlloc=00000000 Interleave=0 LowCyl=1104 HighCyl=2342 NumBuffers=30 BufMemType=0 MaxTransfer=00ffffff Mask=00fffffe BootPri=0 DosType=42534444 'BSDD' FSHD Blk=4 HostID=7 Next=-1 Version=0 DosType=444F5301 'DOS\1' SegListBlocks=5 GlobVec=-1 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 gvpscsi.device unit 2 : Blk=0 HostID=7 BlockBytes=512 Flags=0x0037 LastDisk LastLUN LastTarget DiskValid ControllerValid BadBlockList=-1 PartitionList=1 FileSysHeaderList=4 DriveInit=-1 Cylinders=1223 Sectors=42 Heads=4 Interleave=1 Park=-2 StepRate=0 WritePreComp=0 ReducedWrite=0 RDBBlocksLo=0 RDBBlocksHi=167 LoCylinder=1 HiCylinder=1222 CylBlocks=168 AutoParkSeconds=0 DiskVendor=QUANTUM DiskProduct=LP105S 910109405 DiskRevision=2.8 ControllerVendor=GVP ControllerProduct=GVPSCSI(#1!) ControllerRev=ALL No bad blocks PART Blk=1 DriveName=BSD_USR2 DevFlags=0 HostID=7 Next=2 Mount Surfaces=4 BlocksPerTrack=42 Reserved=00000000 PreAlloc=00000000 Interleave=0 LowCyl=1 HighCyl=597 NumBuffers=30 BufMemType=0 MaxTransfer=00ffffff Mask=00fffffe BootPri=-128 DosType=42534445 'BSDE' PART Blk=2 DriveName=DH3 DevFlags=0 HostID=7 Next=3 Mount Surfaces=4 BlocksPerTrack=42 Reserved=00000002 PreAlloc=00000000 Interleave=0 LowCyl=598 HighCyl=890 NumBuffers=32 BufMemType=0 MaxTransfer=7fffffff Mask=00fffffe BootPri=-128 DosType=444F5301 'DOS\1' PART Blk=3 DriveName=BSD_USR3 DevFlags=0 HostID=7 Next=-1 Mount Surfaces=4 BlocksPerTrack=42 Reserved=00000000 PreAlloc=00000000 Interleave=0 LowCyl=891 HighCyl=1222 NumBuffers=30 BufMemType=0 MaxTransfer=00ffffff Mask=00fffffe BootPri=-128 DosType=42534446 'BSDF' FSHD Blk=4 HostID=7 Next=-1 Version=0 DosType=444F5301 'DOS\1' SegListBlocks=5 GlobVec=-1 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 Perhaps gives this a better way to solve my problem, Thanks, Robert R. Bungener Email : rbungen@hvlpa.att.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 29 23:14:29 1994 X-Mailer: DUUCPv1.17b X-Reader: GRn2.0k From: barnhill@zinder.do.open.de (Larry Barnhill) To: owner-amiga-dev@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: Recent problems. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu :I have been seeing alot of problems recently regarding the bins on :lamp. Id like to make a few comments. : [------------------------] :I posteed recently in comp.unix.amiga asking for donation of a second :machine and more storage space. So far it has been the concencus that :users will send money ($50-100) to me with a SASE so that I may return :all of it if I do not gather enough for something usefull. One thing I I didn't see this yet. I understand the problem. [--------------------] : :I don't feel bad about asking as I put alot of work into NetBSD and I :have no job currently (which needs to change *real* fast.) : :Send me some mail if you have anything to donate or would like to talk :about it. (repsone has been light so far perhaps 4 people I need 40 people :at $100 for the system less for just adding more space and such) I'll send you $100, Postal Money Order, if you'll send me your address. It will take a week approx. as I'm in Europe. I'll send your address to my Daughter in the States and she'll send You a Money-Order, OK? : :Thanks to anyone who helps your really helping NetBSD amiga. :Chris. : ---- barnhill@zinder.do.open.de ( L. Barnhill ) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Apr 29 23:38:56 1994 Subject: From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rbungen@hvlpa.att.com (R R Bungener +31 35 87 1526), amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Apr 30, 2:05am, R R Bungener +31 35 87 1526 wrote: > It dieds with : > >>> NetBSD 0.9a (GENERIC) #0 : Sat Mar 26 ...... > >>> sjr@......... > >>> Amiga 2000 68030 (CPU+MMU) 25 Mc 68882 FPU > >>> real mem= 6291456 > >>> avail mem= 3555328 > >>> using 51 buffers containing 417792 bytes of memory > >>> 0 Amiga memory segments ^^^^^^^^^^^^^^^^^^^^^^^ NetBSD isn't seeing any of the Exec memory lists. I would guess that you are running with the wrong version of loadbsd. You need at least version 2.0 for the current kernels, and you should be running 1.744, > >>> Realtime clock A2000 > >>> rtclock [1/9] > >>> par0 [1/6] > >>> grf0: 640 x 400 4 color custom ...... > >>> grf0 [1/7] > >>> ser0 [1/3] > >>> no suitable root It can't find the root because it doesn't see any AutoConfigured devices - all the devices it sees are the built-in devices. This will also indicates that you are using the wrong version of loadbsd. PLEASE, PLEASE, PLEASE - anyone running a version of loadbsd earlier than the 1.744 version, I would suggest that you get the latest version. [I think this would be loadbsd-940320.gz on ftp.eunet.ch. 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 Apr 30 04:48:23 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Recent problems. Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9404270558.AA23125@emunix.emich.edu> chopps@emunix.emich.edu (Chris Hopps) writes: > I posteed recently in comp.unix.amiga asking for donation of a second > machine and more storage space. So far it has been the concencus that > users will send money ($50-100) to me with a SASE so that I may return > all of it if I do not gather enough for something usefull. One thing I > need despretley is more HD space the only reason I do not build the > snapshots is becuase I simply have no space. My sytem is configured to > run all static linked bins so I don't even have enough space to create > a snapshot of that. Back when Markus W was still "in charge" and we were first considering the CD-ROM idea, we talked about donating a percentage of profits from the CD-ROM people who are working on the amiga port. We're still planning to do this, but of course that won't happen until the CD-ROM does. Also, we want to spred the money around among the developers, not just give to one person. > Send me some mail if you have anything to donate or would like to talk > about it. (repsone has been light so far perhaps 4 people I need 40 people > at $100 for the system less for just adding more space and such) $4000 just to add space? You can now get 1.2G hardddrives for $600 ($.48/M!) now. Just how much space do you need? :-) About the only positive thing about recent C= news is that you'll probably be able to find a used 4000 inexpensively soon. -- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 30 05:15:30 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) From: billy@mana.apana.org.au (Jeff Coleman) To: sun-lamp.cs.berkeley.edu%amiga@sserve Cc: billy@mana.apana.org.au Subject: problems booting netbsd. Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi folks I am having trouble getting netbsd to single user mode. setup is a2000/a2620/4mb 32bit fast/1mb chip/240mb quantum (netbsd)/ 40mb segate. Using rootfs_720 loadbsd-940320 and vmunix.generic.940305 or vmunix.generic- 940325. It seems to startup ok... thinks its a a2000/68030 etc.. not a 68020. It finds root ok on sd6a but then goes into a dead loop for ever. trapsignal(1,11,3466,d8a,d86) I've been posting to comp.unix.amiga and have taken peoples advice to grab latest version of kernel (generic) and loadbsd but I am still having problems. Jeff. Jeff Coleman [Canberra, Australia] billy@mana.mana.oz.au billy@mana.apana.org.au ..!uunet!munnari.oz!werple.apana.org.au!mana!billy A Member of APANA (mail info@apana.org.au), I represent myself ONLY. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 30 20:04:07 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) From: billy@mana.apana.org.au (Jeff Coleman) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: problems booting netbsd. Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 29, you wrote: > On Apr 30, 11:16am, Jeff Coleman wrote: > > a2000/a2620/4mb 32bit fast/1mb chip/240mb quantum (netbsd)/ 40mb segate. > > > > Using rootfs_720 loadbsd-940320 and vmunix.generic.940305 or vmunix.generic- > > 940325. > > > > It seems to startup ok... > > > > thinks its a a2000/68030 etc.. not a 68020. > > That is probably the problem. I don't think NetBSD sets things > up for the 68020/68851. I think if you use binpatch to change the > MMU type, it might work better. You need to change the variable > _mmutype from -1 to 1: > binpatch -s _mmutype -r 1 vmunix > Yes this was the problem. many thanx. Jeff. > 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 > Jeff Coleman [Canberra, Australia] billy@mana.mana.oz.au billy@mana.apana.org.au ..!uunet!munnari.oz!werple.apana.org.au!mana!billy A Member of APANA (mail info@apana.org.au), I represent myself ONLY. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 30 20:17:32 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "This week's NetBSD/amiga changes" (Apr 29, 12:01pm) 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 Apr 29, 12:01pm, Operator wrote: > Modified Files: > grf_rt.c > Log Message: > don't reinit board twice if it works once. Ah, great. That one buggerd me already. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 30 20:20:32 1994 From: Hartmut Kuehn Subject: Re: Supra and Oktagon ??!! To: markus@techfak.uni-bielefeld.de, 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: 2405 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi ! > > Are there any news concering the implementation of > > the Supra WordSync Series 3 Controller in NetBSD ?? > > Or better, does anyone plan to implement the > > Oktagon 2008 controller, which seems to be the > > No support for any NCR-based Adapter yet working, and i don't share > your opinion on that 'coolest' adapter. Oktagon is a PIO-Adapter Not my opinion, just the news I heard about controllers. I don't have the hardware-knowledge to build an opinion about controllers. The problems are elsewhere, a friend of mine and obviously many other people tend to buy a new controller in order to be able to use NetBSD. For my friend, the GVP-controller is out of mind, because he tested one in his A2000-constellation and it doesn't work at all with his GB-HD under AmigaDOS. The old Commodore-controller is also no good choice for an A2000, so here is the question to those of you, who are familiar with the internal ongoing of NetBSD: Which controller is the best regarding the future of NetBSD ?? If one wants to buy a "good" controller to run NetBSD with, which is in your opinion the best for the A2000 ?? > with no DMA capabilities. Thus it is quite hard to implement service > for this one. Personally I'm fine, I have an A3000 :-) Thanks for your help Bye ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@cs.tu-berlin.de * * (or kuehaaaf@w250zrz.zrz.tu-berlin.de) * * BITNET: KUEHN@DB0TUI11.BITNET * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@cs.tu-berlin.de * * (or kuehaaaf@w250zrz.zrz.tu-berlin.de) * * BITNET: KUEHN@DB0TUI11.BITNET * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 30 21:24:03 1994 From: William J Coldwell To: Hartmut Kuehn Subject: Re: Supra and Oktagon ??!! Cc: osymh@gemini.oscs.montana.edu, amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hartmut asked: >Do you know if the current kernel can be patched to work >with the Series 3, there can't be much differnces between >2 and 3 ??!! There are _no_ differences to us (their software and firmware changed, but since we don't use it, we don't care). If Michael has it work with his WordSync, it'll work with all of them out there. As soon as I find an old tape, I'll give Michael what he needs to add in the Nexus HD controller to the kernel. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 30 23:22:39 1994 From: Hartmut Kuehn Subject: Re: Supra and Oktagon ??!! To: billc@icecube.cryogenic.com Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD Mailing List) 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: 1078 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi ! > Hartmut asked: > >Do you know if the current kernel can be patched to work > >with the Series 3, there can't be much differnces between > >2 and 3 ??!! > > There are _no_ differences to us (their software and firmware changed, but > since we don't use it, we don't care). If Michael has it work with his > WordSync, it'll work with all of them out there. > > As soon as I find an old tape, I'll give Michael what he needs to add in the > Nexus HD controller to the kernel. Great, thanks a lot. Bye ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@cs.tu-berlin.de * * (or kuehaaaf@w250zrz.zrz.tu-berlin.de) * * BITNET: KUEHN@DB0TUI11.BITNET * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From owner-amiga@sun-lamp.cs.berkeley.edu Sat Apr 30 23:26:12 1994 From: Hartmut Kuehn Subject: Re: Supra and Oktagon ??!! To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD Mailing List) 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: 2189 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi ! > > At our ftp-site there was a kernel with definite supra-support. > > We used a hex-editor to search for a string like supra and found > > Suprascsi. Also the incoming/experimental kernel for the Retina Z3 > > which I use has this string. So we thought, we directly patch the prod-id etc. > > in the kernel so that his controller is recognized ... but we need the sources > > of the new kernel ... is it that simple ?? > > It's not that simple to patch - the controller list in ioconf would be > easy enough to patch, but there's a big double switch in autoconf.c that > sets up the configuration for each support device. It could certainly > be patched, but it might not be easy to find what to patch. > > Anyway, the current device supported is 1056/12. However, the > experimental kernel only had the A3000 scsi configured. There will be a > string "Suprascsi" from the autoconf.c code that will be there even if > the device isn't configured in the kernel. If it is configured, the string > should be there twice. Some of the first generic kernels made with the > Supra support available may not have had the Supra configured, but I think > the current generic kernels should have it. I see. I guessed it wouldnt be so simple :-) But the 1056/12 is exactly the same for my friends supra, so compiling a kernel should be the solution. Could someone please be so kind to grab the experimental server sources and compile a version that recognises the supra-controller and lay it somewhere where I can ftp it ??!! It would be big help for my friend, he waited so long for NetBSD :-) !!! Thanks in advance ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@cs.tu-berlin.de * * (or kuehaaaf@w250zrz.zrz.tu-berlin.de) * * BITNET: KUEHN@DB0TUI11.BITNET * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * *******************************************************