jwabik@umnd-cs.UUCP (Jeff Wabik) (01/05/87)
It's happening again. I (finally) plucked DBW's vt100 (v2.4) off the net today, and gave a shot at compiling (much the same as I did with 2.3). The whole process was uneventful and rather painless, that was, of course, until I tried to execute. The vt100 screen came up, and it appeared that the device info from SYS: loaded, but then (depending on phase of the moon and which version of the OS I tried) I got varying crashes: The most prominent were visits to the guru with changing medidations; screen blanking and changing to it's choice of colors was a close second, and coming in third was the workbench screen flipping into >interlace< (?!) followed by the display of half an alert. (No, I had NOT selected interlace from WB1.2). The same happed when I tried to compile 2.3 a while back, and due to lack of similar comments from others, this problem must be at my end. In short: HELP! I do get one warning from the compiler -- something about NULL being re-defined in vt100.c. Other than that, no worries. Arrgh. Thanks in advance .. -Jeff
cmcmanis@sun.uucp (Chuck McManis) (01/08/87)
In article <351@umnd-cs-gw.umnd-cs.UUCP>, jwabik@umnd-cs.UUCP (Jeff Wabik) writes: > > It's happening again. I (finally) plucked DBW's vt100 (v2.4) off the > net today, and gave a shot at compiling (much the same as I did with 2.3). > The whole process was uneventful and rather painless, that was, of > course, until I tried to execute. The vt100 screen came up, and it > appeared that the device info from SYS: loaded, but then (depending on > phase of the moon and which version of the OS I tried) I got varying crashes: > [He goes on to describe some crashes etc ...] To Jeff and anyone else out there who gets frustrated and turns to the net for help, please include your system setup if you want to get informed answers. Things that are always useful to know are OS revision, (Alpha, Beta, Gamma or Release and number ie WB1.2R for workbench 1.2 Release version) C compiler and revision, Manx or Lattice, (or Commodore) I can only say that a) I compiled vt100 2.4 using Lattice C V3.10 and it ran fine under WorkBench 1.2 Gamma 1. Before compiling it I edited vt100.h and removed the #define MANX and left in the #define LATTICE and it worked fine. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (01/08/87)
In article <351@umnd-cs-gw.umnd-cs.UUCP>, Jeff Wabik (jwabik@umnd-cs.UUCP) writes: [ description of awful things that happen when he tries to run vt100 v2.4] > The same happed when I tried to compile 2.3 a while back, and due > to lack of similar comments from others, this problem must be > at my end. In short: HELP! I do get one warning from the compiler -- > something about NULL being re-defined in vt100.c. Other than that, > no worries. Arrgh. The complaint about NULL being redefined leads me to believe you might be compiling under Lattice with Manx defined. In vt100.h, there are two lines that are as follows in the distribution: #define LATTICE 0 #define MANX 1 If you are using the Lattice compiler, change these definitions to the following: #define LATTICE 1 #define MANX 0 (If you are indeed using Manx, then of course this change is not for you, and the problem lies somewhere else. . .) Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
jwabik@umnd-cs.UUCP (Jeff Wabik) (01/10/87)
In article <11073@sun.uucp>, cmcmanis@sun.uucp (Chuck McManis) writes: > In article <351@umnd-cs-gw.umnd-cs.UUCP>, jwabik@umnd-cs.UUCP (Jeff Wabik) writes: > > > > It's happening again. I (finally) plucked DBW's vt100 (v2.4) off the > > net today, and gave a shot at compiling (much the same as I did with 2.3). > > The whole process was uneventful and rather painless, that was, of > > course, until I tried to execute. The vt100 screen came up, and it > > appeared that the device info from SYS: loaded, but then (depending on > > phase of the moon and which version of the OS I tried) I got varying crashes > > > [He goes on to describe some crashes etc ...] > > To Jeff and anyone else out there who gets frustrated and turns to the > net for help, please include your system setup if you want to get > informed answers. Things that are always useful to know are OS revision, > (Alpha, Beta, Gamma or Release and number ie WB1.2R for workbench 1.2 > Release version) C compiler and revision, Manx or Lattice, (or Commodore) [ He continues: "...I made the proper corrections to vt100.h and it worked fine for me..."] Sorry for the sortfall of info in the last message. I compiled with MANX 3.20a, correctly fixed vt100.h, and the compile occured with no errors. My machine is 512k, 2 drives. I tried to compile under WB1.1, 1.2b4, and 1.2g1, all with the same results. Crashes occur at execution time, shortly after device information starts loading from SYS:. Sometimes a Guru, sometimes blank screen, sometimes multicolor w/ strange noises (from speaker), somtimes screen flips to interlace (?!) and dies,...,just all sorts of crazy things. I have confirmed that that one of my 8520's is bad -- my realtime clock doesn't work. Could this be causing my problem? The compiler seems to function correctly on everything else. Thanks, again, in advance... -Jeff
wagner@utcs.UUCP (01/12/87)
In article <356@umnd-cs-gw.umnd-cs.UUCP> jwabik@umnd-cs.UUCP (Jeff Wabik) writes: >I have confirmed that that one of my 8520's is bad -- my >realtime clock doesn't work. Could this be causing my problem? I suspect it could ...the serial device uses the timer device, if I remember correctly. >The >compiler seems to function correctly on everything else. It's not clear that the compiler is at fault. Michael
jwabik@umnd-cs.UUCP (Jeff Wabik) (01/14/87)
In article <1987Jan12.003406.11104@utcs.uucp>, wagner@utcs.uucp (Michael Wagner) writes: > > In article <356@umnd-cs-gw.umnd-cs.UUCP> jwabik@umnd-cs.UUCP (Jeff Wabik) writes: > >I have confirmed that that one of my 8520's is bad -- my > >realtime clock doesn't work. Could this be causing my problem? > > I suspect it could ...the serial device uses the timer device, > if I remember correctly. > > >The compiler seems to function correctly on everything else. > > It's not clear that the compiler is at fault. The serial device does use one of the 8520's, but it is clear that this particular aspect of a 8520 failure (timing for serial port) is not causing this problem: This note is being written via my Amiga's serial port and version 2.2 of vt100 (not compiled by me!). I'm still confused. If I am wrong and 8520 timings are not working correctly, wouldn't the logical result of such a failure be the inability to communication via the serial port? -Jeff
grr@cbmvax.cbm.UUCP (George Robbins) (01/17/87)
In article <362@umnd-cs-gw.umnd-cs.UUCP> jwabik@umnd-cs.UUCP (Jeff Wabik) writes: > >The serial device does use one of the 8520's, but it is clear that this >particular aspect of a 8520 failure (timing for serial port) is not causing >this problem: This note is being written via my Amiga's serial port and >version 2.2 of vt100 (not compiled by me!). I'm still confused. If I am >wrong and 8520 timings are not working correctly, wouldn't the logical >result of such a failure be the inability to communication via the >serial port? > -Jeff The actual RS232 serial data is handled by a UART function in the Paula Chip, not the 8520's. The serial keyboard interface is handled by serial port on one of the 8520's, the other 8520's serial port is available on the parallel connector. Is this confusing enuf 8-) The Paula serial port deals with Asynchronous data formats, while the 8520's have separate clock and data lines. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)