news@daver.bungi.com (02/12/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Thu, 14 Feb 91 19:11:16 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Mon, 11 Feb 00 22:01:48 Received: by neat.cs.toronto.edu with UUCP id <12507>; Thu, 14 Feb 1991 17:31:27 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA01796; Thu, 14 Feb 91 17:23:22 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j6r6o-0000K0a@daver.bungi.com>; Thu, 14 Feb 91 14:07 PST X-Path: news From: tim@proton.amd.com (Tim Olson) To: xm-pc532@daver.bungi.com Subject: Re: Bug in minix library setjmp.s; lots of GNU tools diffs available Date: Mon, 11 Feb 1991 22:01:48 -0500 Message-Id: <1991Feb12.3148.0@proton.amd.com> Illegal-Object: Syntax error in References: value found on neat.cs.toronto.edu: References: <<9102072159.AA02808@halsoft>> ^ ^-illegal reference separator \-expected word, illegal end of message identification Reply-To: pc532@bungi.com Organization: Advanced Micro Devices, Austin, TX Precedence: bulk In article <9102072159.AA02808@halsoft> writes: | Ian writes: | >Jyrki Kuoppala writes: | > - When porting emacs to pc532-Minix, I noticed there's a bug in the | > - setjmp library routine - it doesn't save registers r3-r7 (and f4-f7) | > - which I think it should do. | ... | >I believe in ANSI C, there is no requirement to save registers in setjump. | >Variables which have to be accessed after the setjump should be marked | >volatile. Yes, some people have said that is ugly and nor the way it | >should be done, but I pretty sure, that is the way it is! | | I suspect that register variables ought to be preserved despite what the | ANSI standard says, particularly since well optimized C compilers put | everything they can into registers whether or not they are declared | register. Actually, the most "correct" implementation of setjmp/longjmp is to ensure that all automatic variables, like statics and externals, have the value they had at the time of the longjmp. Saving register values in the jmpbuf causes those that were actually in registers to have the values they had at the time of the setjmp (but externals and automatics not in registers have their longjmp value). The reason the ANSI standard specified that the values of non-volatile automatics are not to be relied upon (how's that for a double-negative! ;-) is that: 1) There exist "correct" implementations (VAX with stack-unwind longjmp, register-windowed RISC processors). 2) There exist "register save" implementations. 3) Forcing one or the other to be the standard would be prohibitive on various architectures. -- -- Tim Olson Advanced Micro Devices (tim@amd.com)
news@daver.bungi.com (02/12/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Mon, 18 Feb 91 00:00:38 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Mon, 11 Feb 00 22:01:48 Received: by neat.cs.toronto.edu with UUCP id <6650>; Sun, 17 Feb 1991 23:20:16 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA06426; Sun, 17 Feb 91 23:07:46 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j8251-00001ga@daver.bungi.com>; Sun, 17 Feb 91 20:02 PST X-Path: zoo.toronto.edu!bnr-vpa!MAILER-DAEMON From: Mail Delivery Subsystem <uunet!bnr-vpa!MAILER-DAEMON> To: utzoo!bungi.com!pc532 Subject: Returned mail: Cannot send message for 3 days Date: Mon, 11 Feb 1991 22:01:48 -0500 Message-Id: <9102180213.AA18751@uunet.UU.NET> Reply-To: pc532@bungi.com Precedence: bulk ----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Thu, 14 Feb 91 19:11:16 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Mon, 11 Feb 00 22:01:48 Received: by neat.cs.toronto.edu with UUCP id <12507>; Thu, 14 Feb 1991 17:31:27 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA01796; Thu, 14 Feb 91 17:23:22 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j6r6o-0000K0a@daver.bungi.com>; Thu, 14 Feb 91 14:07 PST X-Path: news From: tim@proton.amd.com (Tim Olson) To: xm-pc532@daver.bungi.com Subject: Re: Bug in minix library setjmp.s; lots of GNU tools diffs available Date: Mon, 11 Feb 1991 22:01:48 -0500 Message-Id: <1991Feb12.3148.0@proton.amd.com> Illegal-Object: Syntax error in References: value found on neat.cs.toronto.edu: References: <<9102072159.AA02808@halsoft>> ^ ^-illegal reference separator \-expected word, illegal end of message identification Reply-To: pc532@bungi.com Organization: Advanced Micro Devices, Austin, TX Precedence: bulk In article <9102072159.AA02808@halsoft> writes: | Ian writes: | >Jyrki Kuoppala writes: | > - When porting emacs to pc532-Minix, I noticed there's a bug in the | > - setjmp library routine - it doesn't save registers r3-r7 (and f4-f7) | > - which I think it should do. | ... | >I believe in ANSI C, there is no requirement to save registers in setjump. | >Variables which have to be accessed after the setjump should be marked | >volatile. Yes, some people have said that is ugly and nor the way it | >should be done, but I pretty sure, that is the way it is! | | I suspect that register variables ought to be preserved despite what the | ANSI standard says, particularly since well optimized C compilers put | everything they can into registers whether or not they are declared | register. Actually, the most "correct" implementation of setjmp/longjmp is to ensure that all automatic variables, like statics and externals, have the value they had at the time of the longjmp. Saving register values in the jmpbuf causes those that were actually in registers to have the values they had at the time of the setjmp (but externals and automatics not in registers have their longjmp value). The reason the ANSI standard specified that the values of non-volatile automatics are not to be relied upon (how's that for a double-negative! ;-) is that: 1) There exist "correct" implementations (VAX with stack-unwind longjmp, register-windowed RISC processors). 2) There exist "register save" implementations. 3) Forcing one or the other to be the standard would be prohibitive on various architectures. -- -- Tim Olson Advanced Micro Devices (tim@amd.com)
news@daver.bungi.com (02/15/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Fri, 15 Feb 91 02:00:26 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Thu, 14 Feb 00 14:39:10 Received: by neat.cs.toronto.edu with UUCP id <20574>; Thu, 14 Feb 1991 19:52:43 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA06366; Thu, 14 Feb 91 19:19:52 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j6rOv-00004Ca@daver.bungi.com>; Thu, 14 Feb 91 14:26 PST X-Path: cs.wwu.edu!phil From: phil@cs.wwu.edu (Phil Nelson) To: pc532@bungi.com Subject: MINIX 1.5 / 1.3 hybrid DISTRIBUTION Date: Thu, 14 Feb 1991 14:39:10 -0500 Message-Id: <9102141939.AA08494@strawberry.cs.wwu.edu> Reply-To: pc532@bungi.com Precedence: bulk Hello Everyone, The distribution of minix 1.5 hybrid (kernel version 1.3) is now ready. It is available for anonymous ftp from willow.cs.wwu.edu (140.160.140.153) in the directory pub/minix532. There are also binaries of gcc-1.37 and patch that will help you in your upgrading. The binaries live in pub/minix532/bin. If you do not have access to ftp, I can mail you the distribution. I presume most of you have access to ftp, so I'll take e-mail requests for those who don't. Send your mail to phil@cs.wwu.edu. For this distribution to be useful you need (a) minix 1.3 version for the pc532 from Bruce and (b) a full source tree for minix 1.5 (pc version). There are upgrade kits available for 1.3 -> 1.5 via anonymous ftp from plains.nodak.edu in the directory pub/Minix/updates. This distribution includes crc listings for the 1.5 source tree used as a reference, the final "reference" source tree that includes Bruce's sources and the final 1.5 hybrid source tree. WARNING: This distribution does not contain full source or executable due to the copyright on Minix. This will take some effort on your part to get it working. Several people have successfully created working versions of the 1.5 hybrid ... (Would you who have working 1.5 hybrid systems please tell of your experiences with it?) Version 1.5 is a major improvement when compared to version 1.3. It has the following major features (or improvements): a) Supports minix 1.5 except the kernel which is still 1.3. 1.5 has many more commands and some of the commands are much nicer and more complete. The 1.5 version is much easier system for porting free programs. (If I remember correctly, bison needed no changes to get it to compile using the SYS_V defs.) b) Kernel does include the 1.5 TTY driver! This TTY driver supports ALL speeds available on the pc532 UARTS. It includes user selectable (at compile time) hardware flow control. The xon/xoff works correctly and you can use both ports on one uart at the same time without hanging the system. (In fact, I don't know of a single hang caused by the 1.5 TTY driver.) c) The local definitions for your disk and its partitions have been extracted from scsi_hi.c into an include file. This allows updates to scsi_hi.c that will not change your partition information. d) The file system supports 64 Meg partitions (up from 32 Megs in version 1.3) e) Signals work a little better. f) Bruce's ranlib and ld have been changed to support the minix ar format. This allows minix532 to have only one ar on the system. g) I have several "quick hacks" that have been useful to me. These include a version of the minix "term" that supports zmodem. (You can run rz and sz without exiting term. Term also connects the communication port to sz and rz.) h) gcc-1.39 has compiled with minimal changes. (The changes were mainly to the minix include tree to add "dummy" include files.) I may be missing some things, but I think any one who is running minix on their pc532 will be pleased with this version. I think it is a much more useful operating system than minix 1.3. There have been reports of many free programs being ported easily to the atari st minix 1.5. They include TeX and GNU emacs. There is also an almost complete uucp package for minix 1.5 and many email systems for it also. I think that there are some minix 1.5 machines running news. I expect to see minix 1.6.? ready for distribution by AST by sometime this summer. It is supposed to have a TCP/IP implementation ready and has a more complete file system (it includes locking which 1.5 does not). Bruce and I are going to be working on getting the kernel up to version 1.5. Work is alread under way, but we have no idea when it will be ready. Until then, the 1.5 hybrid version appears to be stable enough to use. When it is done, we will distribute updates as changes from this minix 1.5 hybrid version. When you get the distribution, I recommend that you read the README file with the distribution and the README file with the pc532 specific programs in the commands directory. I hope this makes many people happy! --Phil phil@cs.wwu.edu (Phil Nelson) Computer Science Department Western Washington University Bellingham, WA 98226
news@daver.bungi.com (02/15/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Mon, 18 Feb 91 06:08:31 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Thu, 14 Feb 00 14:39:10 Received: by neat.cs.toronto.edu with UUCP id <6171>; Mon, 18 Feb 1991 04:18:53 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA03434; Mon, 18 Feb 91 04:08:08 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j85tI-00001Qa@daver.bungi.com>; Mon, 18 Feb 91 00:06 PST X-Path: zoo.toronto.edu!bnr-vpa!MAILER-DAEMON From: Mail Delivery Subsystem <uunet!bnr-vpa!MAILER-DAEMON> To: utzoo!bungi.com!pc532 Subject: Returned mail: Cannot send message for 3 days Date: Thu, 14 Feb 1991 14:39:10 -0500 Message-Id: <9102180747.AA16385@uunet.UU.NET> Reply-To: pc532@bungi.com Precedence: bulk ----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Fri, 15 Feb 91 02:00:26 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Thu, 14 Feb 00 14:39:10 Received: by neat.cs.toronto.edu with UUCP id <20574>; Thu, 14 Feb 1991 19:52:43 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA06366; Thu, 14 Feb 91 19:19:52 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j6rOv-00004Ca@daver.bungi.com>; Thu, 14 Feb 91 14:26 PST X-Path: cs.wwu.edu!phil From: phil@cs.wwu.edu (Phil Nelson) To: pc532@bungi.com Subject: MINIX 1.5 / 1.3 hybrid DISTRIBUTION Date: Thu, 14 Feb 1991 14:39:10 -0500 Message-Id: <9102141939.AA08494@strawberry.cs.wwu.edu> Reply-To: pc532@bungi.com Precedence: bulk Hello Everyone, The distribution of minix 1.5 hybrid (kernel version 1.3) is now ready. It is available for anonymous ftp from willow.cs.wwu.edu (140.160.140.153) in the directory pub/minix532. There are also binaries of gcc-1.37 and patch that will help you in your upgrading. The binaries live in pub/minix532/bin. If you do not have access to ftp, I can mail you the distribution. I presume most of you have access to ftp, so I'll take e-mail requests for those who don't. Send your mail to phil@cs.wwu.edu. For this distribution to be useful you need (a) minix 1.3 version for the pc532 from Bruce and (b) a full source tree for minix 1.5 (pc version). There are upgrade kits available for 1.3 -> 1.5 via anonymous ftp from plains.nodak.edu in the directory pub/Minix/updates. This distribution includes crc listings for the 1.5 source tree used as a reference, the final "reference" source tree that includes Bruce's sources and the final 1.5 hybrid source tree. WARNING: This distribution does not contain full source or executable due to the copyright on Minix. This will take some effort on your part to get it working. Several people have successfully created working versions of the 1.5 hybrid ... (Would you who have working 1.5 hybrid systems please tell of your experiences with it?) Version 1.5 is a major improvement when compared to version 1.3. It has the following major features (or improvements): a) Supports minix 1.5 except the kernel which is still 1.3. 1.5 has many more commands and some of the commands are much nicer and more complete. The 1.5 version is much easier system for porting free programs. (If I remember correctly, bison needed no changes to get it to compile using the SYS_V defs.) b) Kernel does include the 1.5 TTY driver! This TTY driver supports ALL speeds available on the pc532 UARTS. It includes user selectable (at compile time) hardware flow control. The xon/xoff works correctly and you can use both ports on one uart at the same time without hanging the system. (In fact, I don't know of a single hang caused by the 1.5 TTY driver.) c) The local definitions for your disk and its partitions have been extracted from scsi_hi.c into an include file. This allows updates to scsi_hi.c that will not change your partition information. d) The file system supports 64 Meg partitions (up from 32 Megs in version 1.3) e) Signals work a little better. f) Bruce's ranlib and ld have been changed to support the minix ar format. This allows minix532 to have only one ar on the system. g) I have several "quick hacks" that have been useful to me. These include a version of the minix "term" that supports zmodem. (You can run rz and sz without exiting term. Term also connects the communication port to sz and rz.) h) gcc-1.39 has compiled with minimal changes. (The changes were mainly to the minix include tree to add "dummy" include files.) I may be missing some things, but I think any one who is running minix on their pc532 will be pleased with this version. I think it is a much more useful operating system than minix 1.3. There have been reports of many free programs being ported easily to the atari st minix 1.5. They include TeX and GNU emacs. There is also an almost complete uucp package for minix 1.5 and many email systems for it also. I think that there are some minix 1.5 machines running news. I expect to see minix 1.6.? ready for distribution by AST by sometime this summer. It is supposed to have a TCP/IP implementation ready and has a more complete file system (it includes locking which 1.5 does not). Bruce and I are going to be working on getting the kernel up to version 1.5. Work is alread under way, but we have no idea when it will be ready. Until then, the 1.5 hybrid version appears to be stable enough to use. When it is done, we will distribute updates as changes from this minix 1.5 hybrid version. When you get the distribution, I recommend that you read the README file with the distribution and the README file with the pc532 specific programs in the commands directory. I hope this makes many people happy! --Phil phil@cs.wwu.edu (Phil Nelson) Computer Science Department Western Washington University Bellingham, WA 98226
news@daver.bungi.com (02/15/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Fri, 15 Feb 91 02:02:14 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Thu, 14 Feb 00 18:35:12 Received: by neat.cs.toronto.edu with UUCP id <20569>; Thu, 14 Feb 1991 23:47:54 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA03717; Thu, 14 Feb 91 23:28:02 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j6tCB-00009Aa@daver.bungi.com>; Thu, 14 Feb 91 16:21 PST X-Path: lev.Seri.GOV!sverre From: sverre@lev.Seri.GOV (Sverre Froyen) To: pc532@bungi.com Subject: Re: MINIX 1.5 / 1.3 hybrid DISTRIBUTION Date: Thu, 14 Feb 1991 18:35:12 -0500 Message-Id: <9102142335.AA05906@lev.seri.gov> Illegal-Object: Syntax error in References: value found on neat.cs.toronto.edu: References: <<9102141939.AA08494@strawberry.cs.wwu.edu>> ^ ^-illegal reference separator \-expected word, illegal end of message identification Reply-To: pc532@bungi.com Precedence: bulk > > WARNING: This distribution does not contain full source or executable >due to the copyright on Minix. This will take some effort on your part >to get it working. Several people have successfully created working >versions of the 1.5 hybrid ... (Would you who have working 1.5 hybrid >systems please tell of your experiences with it?) I have been using a prerelease if this hybrid for about 3 weeks. My recommendation: The effort it takes to upgrade is well worth it. The new version is WONDERFUL! Most of the problems porting code in 1.3, like shell scripts failing, makes not working properly, etc., are GONE. There are still bugs no doubt. I sent a description of some to Bruce and I will post the ones that were not fixed to the mailing list once I take a look at new distribution. This brings up the question, once again, of software maintenance. Should we try to find a way to coordinate Minix bug fixes, porting of utilities, etc. One way to do this would be to assign a moderator for each task. A task could be the kernel, another the libraries (or a subset of the libraries), yet anothre gcc, etc. We would send our changes, improvements, or fixes to the moderator, with an optional posting to the mailing list so that others might get immediate benefit. The moderator would incorporate the changes and send out an ``approved'' patch/version and maybe also a new binary. This scheme might avoid some of the duplication of effort that seemed to take place with Minix 1.3. Irrespective of the above, from now on, please indicate for which version your changes, fixes, ports, etc. are meant. Sverre -- Sverre Froyen sverre@seri.gov, sunpeaks!seri!sverre
news@daver.bungi.com (02/15/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Mon, 18 Feb 91 06:08:23 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Thu, 14 Feb 00 18:35:12 Received: by neat.cs.toronto.edu with UUCP id <6170>; Mon, 18 Feb 1991 04:18:37 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA03402; Mon, 18 Feb 91 04:07:59 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j85sn-00006ua@daver.bungi.com>; Mon, 18 Feb 91 00:06 PST X-Path: zoo.toronto.edu!bnr-vpa!MAILER-DAEMON From: Mail Delivery Subsystem <uunet!bnr-vpa!MAILER-DAEMON> To: utzoo!bungi.com!pc532 Subject: Returned mail: Cannot send message for 3 days Date: Thu, 14 Feb 1991 18:35:12 -0500 Message-Id: <9102180720.AA08565@uunet.UU.NET> Reply-To: pc532@bungi.com Precedence: bulk ----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Fri, 15 Feb 91 02:02:14 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Thu, 14 Feb 00 18:35:12 Received: by neat.cs.toronto.edu with UUCP id <20569>; Thu, 14 Feb 1991 23:47:54 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA03717; Thu, 14 Feb 91 23:28:02 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j6tCB-00009Aa@daver.bungi.com>; Thu, 14 Feb 91 16:21 PST X-Path: lev.Seri.GOV!sverre From: sverre@lev.Seri.GOV (Sverre Froyen) To: pc532@bungi.com Subject: Re: MINIX 1.5 / 1.3 hybrid DISTRIBUTION Date: Thu, 14 Feb 1991 18:35:12 -0500 Message-Id: <9102142335.AA05906@lev.seri.gov> Illegal-Object: Syntax error in References: value found on neat.cs.toronto.edu: References: <<9102141939.AA08494@strawberry.cs.wwu.edu>> ^ ^-illegal reference separator \-expected word, illegal end of message identification Reply-To: pc532@bungi.com Precedence: bulk > > WARNING: This distribution does not contain full source or executable >due to the copyright on Minix. This will take some effort on your part >to get it working. Several people have successfully created working >versions of the 1.5 hybrid ... (Would you who have working 1.5 hybrid >systems please tell of your experiences with it?) I have been using a prerelease if this hybrid for about 3 weeks. My recommendation: The effort it takes to upgrade is well worth it. The new version is WONDERFUL! Most of the problems porting code in 1.3, like shell scripts failing, makes not working properly, etc., are GONE. There are still bugs no doubt. I sent a description of some to Bruce and I will post the ones that were not fixed to the mailing list once I take a look at new distribution. This brings up the question, once again, of software maintenance. Should we try to find a way to coordinate Minix bug fixes, porting of utilities, etc. One way to do this would be to assign a moderator for each task. A task could be the kernel, another the libraries (or a subset of the libraries), yet anothre gcc, etc. We would send our changes, improvements, or fixes to the moderator, with an optional posting to the mailing list so that others might get immediate benefit. The moderator would incorporate the changes and send out an ``approved'' patch/version and maybe also a new binary. This scheme might avoid some of the duplication of effort that seemed to take place with Minix 1.3. Irrespective of the above, from now on, please indicate for which version your changes, fixes, ports, etc. are meant. Sverre -- Sverre Froyen sverre@seri.gov, sunpeaks!seri!sverre
news@bungi.com.mu.edu (02/16/91)
----- Transcript of session follows -----
421 bnrgate.tcp... Deferred
----- Unsent message follows -----
Received: by bnr-vpa; Sun, 17 Feb 91 13:17:45 est
Return-Path: <utzoo!bungi.com!pc532>
Received: from utzoo with uucp; Sat, 16 Feb 00 09:09:54
Received: by neat.cs.toronto.edu with UUCP id <6563>; Sun, 17 Feb 1991 09:40:16 -0500
Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA03371; Sun, 17 Feb 91 09:25:34 -0500
Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16)
id <m0j7nyh-00006Qa@daver.bungi.com>; Sun, 17 Feb 91 04:58 PST
X-Path: uunet!munnari!eyrie.oz.au!athos
From: uunet!munnari!eyrie.img.uu.oz.au!athos (David Burren)
To: img-pc532@eyrie.uu.oz.au
Subject: "Dead" PC532 developments
Date: Sat, 16 Feb 1991 09:09:54 -0500
Message-Id: <3744@eyrie.img.uu.oz.au>
Reply-To: pc532@bungi.com
Organization: img Consultants, Melbourne, Australia
Precedence: bulk
My first PC532 is being stubborn about coming alive. This is basically a
status report. I haven't heard about similar problems, but if you've got
any clues or guesses, please drop me a line!
I've just spent a day with a few friends and $xx,000 worth of logic analysers,
CROs, etc trying to solve the problem.
Obvious symptoms (as reported previously): no LEDs, no serial I/O, no nothing.
Examining the activity on the EPROM showed fetches up to the location of the
BRanch instruction that jumps to the high EPROM location, at which stage the
same four bytes are repeatedly fetched ad infinitum.
The initial accesses looked a bit strange, from the following locations:
0, 1, 2, 3, 4, 5, 6, 7, 8, 7, 4, ...
Strangely enough, fetches from addresses in the range ...4xxx (hex) also
showed up occasionally.
Examining a working board (with the same EPROM) showed quite different
behaviour (ie. the fetches looked reasonable and the board worked).
Surmising that the data coming out of the ROM was not the same as that going
into the CPU (a bit hard to check, as we don't have a chip rig that large)
we started exploring the back of the CPU with a CRO. Some very weird-looking
waveforms emerged.
By the time we called it a night we'd tracked down an intermittent fault
between BD06 on the EPROM and BD06 on the buffer next door (on the way
to the CPU).
I'd like to think that this is the only problem, but I'm not that confident.
We'll find out tomorrow night I suppose.
Stategies we've tried along the way included swapping various parts with a
working board: EPROM, PALs, even using a spare CPU.
Hmmm... now I can say that I've seen a 175-pin PGA chip successfully extracted
from its socket......
___________________________________________________________________________
David Burren (Athos) img Consultants
Systems Development (general dogs-body) G.P.O. Box 3304GG
Melbourne, VIC 3001
Email: athos@img.uu.oz.au Australia
Phone: +61 3 819 4554
P.S. When this board finally works I'm going out and getting solidly pissed!
Seeing as we've only got the test equipment for another day I'm hoping
to get drunk soon :-)
Ironically enough, with all that test equipment, we still didn't have a simple
multimeter :-) Probably something to do with setting everything up on
someone's lounge-room floor, and me not realising I should take along my VOM...news@daver.bungi.com (02/17/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Sat, 16 Feb 91 14:59:30 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Sat, 16 Feb 00 11:38:13 Received: by neat.cs.toronto.edu with UUCP id <6488>; Sat, 16 Feb 1991 14:11:19 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA00660; Sat, 16 Feb 91 14:08:49 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j7WzD-00007qa@daver.bungi.com>; Sat, 16 Feb 91 10:50 PST X-Path: convex.convex.com!texsun!vector!maniac From: texsun!vector.dallas.tx.us!maniac@convex.convex.com (Jon Buller) To: texsun!bungi.com!pc532 Subject: Re: MINIX 1.5 / 1.3 hybrid DISTRIBUTION Date: Sat, 16 Feb 1991 11:38:13 -0500 Message-Id: <m0j7UvO-0001eeC@vector.dallas.tx.us> Illegal-Object: Syntax error in References: value found on neat.cs.toronto.edu: References: <<9102141939.AA08494@strawberry.cs.wwu.edu>> ^ ^-illegal reference separator \-expected word, illegal end of message identification Reply-To: pc532@bungi.com Precedence: bulk > If you do not have access to ftp, I can mail you the > distribution. I presume most of you have access to ftp, so I'll take > e-mail requests for those who don't. Send your mail to phil@cs.wwu.edu. Sounds great! Esp. the parts about fixes/upgrades. I (unfortunately) do not have access to any off-site ftp, so could you mail the stuff to me? Thanks, -- Jon Buller jonb@vector.dallas.tx.us ..!texsun!vector!jonb FROM Fortune IMPORT Quote; FROM Lawyers IMPORT Disclaimer;
news@daver.bungi.com (02/17/91)
----- Transcript of session follows -----
421 bnrgate.tcp... Deferred
----- Unsent message follows -----
Received: by bnr-vpa; Sun, 17 Feb 91 07:08:01 est
Return-Path: <utzoo!bungi.com!pc532>
Received: from utzoo with uucp; Sat, 16 Feb 00 23:15:03
Received: by neat.cs.toronto.edu with UUCP id <6580>; Sun, 17 Feb 1991 04:27:48 -0500
Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AB26748; Sun, 17 Feb 91 04:18:01 -0500
Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16)
id <m0j7kJs-00002aa@daver.bungi.com>; Sun, 17 Feb 91 01:04 PST
X-Path: uunet!tarpit!tous!manatee!John.Connin
From: John Connin <uunet!manatee!johnc>
To: uunet!bungi.com!pc532
Subject: Need info on Opus 32.16 board..
Date: Sat, 16 Feb 1991 23:15:03 -0500
Message-Id: <9102162315.AA08297@manatee.UUCP>
Reply-To: pc532@bungi.com
Precedence: bulk
I recently ran across an Opus 32.16 rev D3 board with 2 Mbytes of
memory but less documentation and software. Well anyway since the price
was pocket change, I purchased it assuming that worst case it might
make a paper weight.
Does anybody know if board documentation is available ??
Does anyone have any ideas how I might utilize the board in general
or in combination with a pc532 ??
Any and all leads, thoughts, and ideas would be appreciated.
--
John Connin: manatee Orlando, Florida
UUCP: {uunet,ge-dab,ucf-cs}!tarpit!tous!manatee!johncnews@daver.bungi.com (02/18/91)
----- Transcript of session follows ----- 421 bnrgate.tcp... Deferred ----- Unsent message follows ----- Received: by bnr-vpa; Sun, 17 Feb 91 14:33:24 est Return-Path: <utzoo!bungi.com!pc532> Received: from utzoo with uucp; Sun, 17 Feb 00 13:31:50 Received: by neat.cs.toronto.edu with UUCP id <6581>; Sun, 17 Feb 1991 13:58:54 -0500 Received: from daver.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA11962; Sun, 17 Feb 91 13:57:08 -0500 Received: by daver.bungi.com (/\=-/\ Smail3.1.18.1 #18.16) id <m0j7tBf-0000DRa@daver.bungi.com>; Sun, 17 Feb 91 10:32 PST X-Path: dlr From: dlr@daver.bungi.com (Dave Rand) To: pc532@bungi.com Subject: Re: Need info on Opus 32.16 board.. Date: Sun, 17 Feb 1991 13:31:50 -0500 Message-Id: <m0j7tAw-00001PC@daver.bungi.com> Reply-To: pc532@bungi.com Precedence: bulk [In the message entitled "Need info on Opus 32.16 board.." on Feb 16, 23:15, John Connin writes:] > Does anybody know if board documentation is available ?? > Schematics and pal equations are not available to the best of my knowledge. You can get Unix (5.3) from Opus or National Semiconductor. If you have trouble getting information, please let me know and I'll put you in touch with the right people... -- Dave Rand {pyramid|mips|bct|vsi1}!daver!dlr Internet: dlr@daver.bungi.com