27 May
2003
27 May
'03
6:28 a.m.
where do i get simh help? i'm trying to install VMS on a simh instance, and
it doesn't seem to want to play nice. where do i get help for simh? the
documentation is slim, and there seems to be no mailing list.
help?
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
too." -Bender
27 May
27 May
7:33 a.m.
I've had pretty good success in the comp.os.vms newsgroup with simh
questions in the past. There seems to be a pretty active VMS-on-simh
community frequenting there.
----- Original Message -----
From: "Brian Hechinger" <wonko(a)4amlunch.net>
To: <cctalk(a)classiccmp.org>
Sent: Tuesday, May 27, 2003 2:11 PM
Subject: simh help?
where do i get simh help? i'm trying to install
VMS on a simh instance,
and
it doesn't seem to want to play nice. where do i
get help for simh? the
documentation is slim, and there seems to be no mailing list.
help?
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
oo." -Bender
8:40 a.m.
Brian Hechinger wrote:
where do i get simh help? i'm trying to install
VMS on a simh instance, and
it doesn't seem to want to play nice. where do i get help for simh? the
documentation is slim, and there seems to be no mailing list.
Depends on what problem you are having, what version of simh you are using,
and what OS you are running it on. I can run VMS in simh under Linux
without
any problems. Haven't used it under Windows though.
28 May
28 May
7:46 a.m.
On Tue, May 27, 2003 at 03:19:51PM -0600, Kevin Handy wrote:
Depends on what problem you are having, what version of simh you are using,
and what OS you are running it on. I can run VMS in simh under Linux
without
any problems. Haven't used it under Windows though.
i run it on NetBSD without any trouble.
v2.1.0-4 on IRIX 6.5.16f.
build with MIPSpro 7.4
with -apo it was fast as balls, but was EXTREMELY unstable.
without -apo it's much clower (no surprise there) and it is not completely
stable, but only mostly stable.
i am curious if anyone else has tried to build it with non-gcc on something.
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
too." -Bender
8:09 a.m.
Brian Hechinger wrote:
On Tue, May 27, 2003 at 03:19:51PM -0600, Kevin Handy
wrote:
Does simh crash, or does it just do wacky things? More details would
be useful.
Depends on what problem you are having, what
version of simh you are using,
and what OS you are running it on. I can run VMS in simh under Linux
without
any problems. Haven't used it under Windows though.
i run it on NetBSD without any trouble.
v2.1.0-4 on IRIX 6.5.16f.
build with MIPSpro 7.4
with -apo it was fast as balls, but was EXTREMELY unstable.
without -apo it's much clower (no surprise there)
and it is not completely
stable, but only mostly stable.
i am curious if anyone else has tried to build it with non-gcc on something.
-brian
It's probably mostly done with some version of GCC, but I believe that
it is often compiled using Microsoft Visual C.
If you can discover where the problem is, then I'm sure Bob would like
to know about it and would probably be happy to receive any fixes.
The hard part is determining what is going wrong, and without access to
the specific compilers, that is rather hard.
8:47 a.m.
On Wed, May 28, 2003 at 02:49:27PM -0600, Kevin Handy wrote:
Does simh crash, or does it just do wacky things? More details would
be useful.
it stops responding. if i don't clear out my nvram file, it fails on memory
check the next time i boot the cpu.
i need to delete the nvram file and restart, then it works. for a while
anyway, and then eventually stops responding.
It's probably mostly done with some version of
GCC, but I believe that
it is often compiled using Microsoft Visual C.
it's been added to my LONG list of things to clean up for building with
non-gcc. MIPSpro being very anal complains a LOT about the source code.
If you can discover where the problem is, then I'm
sure Bob would like
to know about it and would probably be happy to receive any fixes.
i'd love to, but i'm not even sure how to. ;(
The hard part is determining what is going wrong, and
without access to
the specific compilers, that is rather hard.
one i get the Challenge running i would be more than happy to give out
accounts to help the non-gcc cause.
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
too." -Bender
9:24 a.m.
Brian Hechinger wrote:
Sometimes that's a good thing. It may actually be pointing right at
the problem, but hiding it under a mass of additional messages.
On Wed, May 28, 2003 at 02:49:27PM -0600, Kevin Handy
wrote:
Odd. If you can still Control/E to the prompt, try 'N' for several
instructions
to see if it is stuck in VMS's idle loop (cycles through a very small number
of instructions). If it is, it might not be seeing any interrupts.
If Control/E doesn't work, then things are really hosed.
Does simh crash, or does it just do wacky things?
More details would
be useful.
it stops responding. if i don't clear out my nvram file, it fails on memory
check the next time i boot the cpu.
i need to delete the nvram file and restart, then it works. for a while
anyway, and then eventually stops responding.
I haven't been using a NVR file, and it seems to work ok.
Try commenting it out in your configuration file, and see what happens.
It's
probably mostly done with some version of GCC, but I believe that
it is often compiled using Microsoft Visual C.
it's been added to my LONG list of things to clean up for building with
non-gcc. MIPSpro being very anal complains a LOT about the source code.
i'd love to, but i'm not even sure how to. ;(
I've done it using the 'N' command (next instruction), trying to trace
out
bad instructions, and using gdb. It's very tedius when you are looking for
one instruction out of a million executed that are wrong.
29 May
29 May
1:06 a.m.
On Wed, May 28, 2003 at 04:03:55PM -0600, Kevin Handy wrote:
Odd. If you can still Control/E to the prompt, try 'N' for several
instructions
to see if it is stuck in VMS's idle loop (cycles through a very small number
of instructions). If it is, it might not be seeing any interrupts.
oops, forgot to mention that part. if i Ctrl/E from within the running
simulator, it crashes sim and takes the controlling xterm/rxvt with it.
i should try doing this telnetting in from a remote machine i think.
If Control/E doesn't work, then things are really
hosed.
it works, just not well. ;)
Sometimes that's a good thing. It may actually be
pointing right at
IMHO that's *always* a good thing. it has really opened my eyes to the fact
that your average opensource coder has been so coddled by the whole gcc/x86
platform that they have really started to make stupid mistakes and even
stupider assumptions about things. the most common assumption is that a
void pointer and an int pointer is the same size. which just happens to be
true in 32-bit land, but totally hoses those of us who live in 64-bit land.
hell, even the code that autoconf generates for tests makes that assumption.
the problem, but hiding it under a mass of additional
messages.
how do i build just the VAX portion? 'make vax' does nothing, and 'make
VAX'
says everything is up to date. that's one ugly makefile, so it's kinda hard
to interpret for someone who hasn't messed with makefiles in years.
I've done it using the 'N' command (next
instruction), trying to trace out
bad instructions, and using gdb. It's very tedius when you are looking for
one instruction out of a million executed that are wrong.
first i need to get it to not crash completely. ;)
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
too." -Bender
1:19 a.m.
--- Brian Hechinger <wonko(a)4amlunch.net> wrote:
it has really opened my eyes to the fact that your
average opensource
coder has been so coddled by the whole gcc/x86 platform that they have
really started to make stupid mistakes and even stupider assumptions
about things.
They used to say the same thing about BSD/VAX coders...
the most common assumption is that a void pointer and
an int pointer is
the same size. which just happens to be true in 32-bit land...
The charge in 1983 was "char * and an int are the same size..."
... but totally hoses those of us who live in 64-bit
land.
The hosed parties 20 years ago tended to be 16-bit users/admins.
hell, even the code that autoconf generates for tests
makes that
assumption.
I realize that Linux on x86 is a hugely popular platform for Open Source
work, but there's plenty of UltraSPARC machines out there... surely
you don't need an Alpha to shatter these assumptions
-ethan
(whose Alpha is running VMS, not UNIX; because it can)
1:54 a.m.
On Thu, May 29, 2003 at 06:18:40AM -0700, Ethan Dicks wrote:
They used to say the same thing about BSD/VAX coders...
all those unix people are evil!!! *ducking!*
The charge in 1983 was "char * and an int are the
same size..."
equally as evil. ;)
The hosed parties 20 years ago tended to be 16-bit
users/admins.
i wasn't lucky enough to get to deal with 16-bit machines on a regular basis.
i do now, but not then. ;)
I realize that Linux on x86 is a hugely popular
platform for Open Source
work, but there's plenty of UltraSPARC machines out there... surely
you don't need an Alpha to shatter these assumptions
i wonder how many people build things 64-bit though? it's very easy to build
and run 32-bit software on sparc64 and MIPS64. i do, but i'm one of those
weirdos. ;)
(whose Alpha is running VMS, not UNIX; because it can)
all my alphas run VMS. my octane only runs IRIX because no-one has ported
VMS to it yet. ;)
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
too." -Bender
3:28 a.m.
New subject: All The World's A VAX (was Re: simh help?)
--- Brian Hechinger <wonko(a)4amlunch.net> wrote:
On Thu, May 29, 2003 at 06:18:40AM -0700, Ethan Dicks
wrote:
Some historical commentary on the "all the world's a VAX" syndrome:
http://mail-index.netbsd.org/amiga-dev/1994/07/13/0007.html
http://www.cs.bgu.ac.il/~omri/Humor/ten-commandments.html (cf #10)
http://www.cnam.fr/Jargon/jargon.html?1910 (exhaustive!)
I remember pulling down lots of programs from comp.sources.unix
and comp.sources.games, both for building in their native environment
and for porting to VMS/AmigaDOS/whatever-was-in-front-of-me-at-the-
moment. There were some things that I never did get working (but I
did get Pinfocom, Larn and Ultra-Larn working on non-UNIXy boxen).
-ethan
They used to say the same thing about BSD/VAX coders...
all those unix people are evil!!! *ducking!*
The charge in 1983 was "char * and an int
are the same size..."
equally as evil. ;) 
1:27 a.m.
On Thu, 29 May 2003, Brian Hechinger wrote:
oops, forgot to mention that part. if i Ctrl/E from
within the running
simulator, it crashes sim and takes the controlling xterm/rxvt with it.
If the xterm/rxvt seems 'hosed' but is still running, try running
"reset",
which should reset the terminal to 'sane' characteristics. I'm guessing
the problem is that the keyboard gets set to 'noecho' or 'raw' mode or
something.
i should try doing this telnetting in from a remote
machine i think.
Or, if possible, try it from a virtual/serial console - without a
windowing system in the way.
IMHO that's *always* a good thing. it has really
opened my eyes to the fact
that your average opensource coder has been so coddled by the whole gcc/x86
platform that they have really started to make stupid mistakes and even
stupider assumptions about things. the most common assumption is that a
void pointer and an int pointer is the same size. which just happens to be
Do you mean void * and int (not a pointer)? All pointers should be the
same size... (Sorry, I'm being pedantic.)
true in 32-bit land, but totally hoses those of us who
live in 64-bit land.
hell, even the code that autoconf generates for tests makes that assumption.
First, you need a "BIN" subdir, and then "make BIN/vax". I think I
remember reading this in a readme somewhere... I usually end up just
being lazy and running a "make all". Anyways, who knows when I'll want to
play with an IBM 1401 sim :).
Pat
--
Purdue University ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www.itap.purdue.edu/rcs/
the problem, but hiding it under a mass of
additional messages.
how do i build just the VAX portion? 'make vax' does nothing, and 'make
VAX'
says everything is up to date. that's one ugly makefile, so it's kinda hard
to interpret for someone who hasn't messed with makefiles in years.
1:54 a.m.
On Thu, May 29, 2003 at 08:32:10AM -0500, Patrick Finnegan wrote:
If the xterm/rxvt seems 'hosed' but is still running, try running
"reset",
which should reset the terminal to 'sane' characteristics. I'm guessing
the problem is that the keyboard gets set to 'noecho' or 'raw' mode or
something.
no, the xterm/rxvt crashes along with simh. i need to start a new xterm.
Or, if possible, try it from a virtual/serial console
- without a
windowing system in the way.
that's not a bad idea, maybe i'll drag a vt into work next week and do that.
Do you mean void * and int (not a pointer)? All
pointers should be the
same size... (Sorry, I'm being pedantic.)
no, you are right to be pedantic. i was wrong, you corrected me. i would have
done the same to you. ;)
First, you need a "BIN" subdir, and then
"make BIN/vax". I think I
remember reading this in a readme somewhere... I usually end up just
being lazy and running a "make all". Anyways, who knows when I'll want to
play with an IBM 1401 sim :).
brian@marvin$ gmake BIN/vax
gmake: *** No rule to make target `BIN/vax'. Stop.
i wouldn't mind making everything all the time, but it takes a while, and i'm
impatient. ;)
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
too." -Bender
7:42 a.m.
It was thus said that the Great Patrick Finnegan once stated:
On Thu, 29 May 2003, Brian Hechinger wrote:
No, they don't have to be the same size; I think I recall that char * on
certain PDPs were slightly larger than say, an int * (because pointers only
pointed to word boundaries, yet you could pack several characters per word
so extra storage was needed to store the offset into a word for a char *).
And don't forget the whole mess with near and far pointers in the DOS world
(technically those were extentions but ... ).
Given the following declaration:
void *vp1;
void *vp2;
char *cp1;
char *cp2;
int *ip;
The following should hold true:
vp1 = cp1;
cp2 = vp1;
assert(cp1 == cp2); /* should be fine */
While the following may or may not work:
vp1 = cp1;
ip = vp1;
vp2 = ip;
cp2 = vp2;
assert(cp1 == cp2) /* may or may not hold */
-spc (Don't have the C Standard handy ... )
IMHO that's *always* a good thing. it has
really opened my eyes to the fact
that your average opensource coder has been so coddled by the whole gcc/x86
platform that they have really started to make stupid mistakes and even
stupider assumptions about things. the most common assumption is that a
void pointer and an int pointer is the same size. which just happens to be
Do you mean void * and int (not a pointer)? All pointers should be the
same size... (Sorry, I'm being pedantic.)
3:07 a.m.
Brian Hechinger wrote:
'make BIN/vax' should work (case is important here). All the binaries
are created in the BIN subdirectory.
The makefile should actually be fairly simple (as I wrote the original
version). Skip past the top of the makefile (which figures out your OS
and if network deviced should be configured) and the major part of
it is just lists of files for each emulator.
Something like it became necessary when the emulators started
sharing code for devices, and manually typing the compile
line was getting too complicated.
That's always a good start. ;=)
On Wed, May 28, 2003 at 04:03:55PM -0600, Kevin Handy
wrote:
I don't know why it would take the xterm with it. Odd that.
[Sounds of grasping at straws]
Memory corruption might be occurring somewhere.
Wonder if one of the memory monitors, like ElectricFence, would
yield useful information. Don't know whats available on your system.
Odd. If you can still Control/E to the prompt, try
'N' for several
instructions
to see if it is stuck in VMS's idle loop (cycles through a very small number
of instructions). If it is, it might not be seeing any interrupts.
oops, forgot to mention that part. if i Ctrl/E from within the running
simulator, it crashes sim and takes the controlling xterm/rxvt with it.
i should try doing this telnetting in from a remote
machine i think.
That assumption started in the first versions of Unix on the PDP11, and
still occurrs in new code. It's part of what was once called the
"all the worlds a VAX" mentality.
Make sure you have all warnings turned on when you compile (look for
the CC definition), under gcc the option would be '-Wall'. Maybe it will
point at something obvious.
If Control/E doesn't work, then things are
really hosed.
it works, just not well. ;)
Sometimes that's a good thing. It may
actually be pointing right at
IMHO that's *always* a good thing. it has really opened my eyes to the fact
that your average opensource coder has been so coddled by the whole gcc/x86
platform that they have really started to make stupid mistakes and even
stupider assumptions about things. the most common assumption is that a
void pointer and an int pointer is the same size. which just happens to be
true in 32-bit land, but totally hoses those of us who live in 64-bit land.
hell, even the code that autoconf generates for tests makes that assumption.
the problem,
but hiding it under a mass of additional messages.
how do i build just the VAX portion? 'make vax' does nothing, and 'make
VAX'
says everything is up to date. that's one ugly makefile, so it's kinda hard
to interpret for someone who hasn't messed with makefiles in years.
I've done
it using the 'N' command (next instruction), trying to trace out
bad instructions, and using gdb. It's very tedius when you are looking for
one instruction out of a million executed that are wrong.
first i need to get it to not crash completely. ;)
7:46 a.m.
It was thus said that the Great Kevin Handy once stated:
That assumption started in the first versions of Unix on the PDP11, and
still occurrs in new code. It's part of what was once called the
"all the worlds a VAX" mentality.
Make sure you have all warnings turned on when you compile (look for
the CC definition), under gcc the option would be '-Wall'. Maybe it will
point at something obvious.
Also try:
gcc -Wall -ansi -pedantic
Be prepared for *lots* of warnings.
-spc (I mean, lots)
30 May
30 May
2:20 a.m.
Sean 'Captain Napalm' Conner wrote:
It was thus said that the Great Kevin Handy once
stated:
For large values of lots, or small values of infinity!
Actually, most of the '-Wall' messages in simh were fixed some time
ago, but many more may have crept back in.
That assumption started in the first versions of
Unix on the PDP11, and
still occurrs in new code. It's part of what was once called the
"all the worlds a VAX" mentality.
Make sure you have all warnings turned on when you compile (look for
the CC definition), under gcc the option would be '-Wall'. Maybe it will
point at something obvious.
Also try:
gcc -Wall -ansi -pedantic
Be prepared for *lots* of warnings.
-spc (I mean, lots)
2:38 a.m.
On Fri, May 30, 2003 at 08:59:55AM -0600, Kevin Handy wrote:
Actually, most of the '-Wall' messages in simh were fixed some time
ago, but many more may have crept back in.
i don't have gcc installed on the octane, so i can't try gcc wall, but MIPSpro
complains a LOT about the source code. i can send you a copy of the output if
you are interested.
-brian
--
"I'd say don't quit your day job, but you're pretty lousy at that
too." -Bender
1 Jun
1 Jun
8:01 a.m.
On Thu, May 29, 2003 at 03:44:52PM -0400, Sean 'Captain Napalm' Conner wrote:
It was thus said that the Great Kevin Handy once
stated:
That isn't all - you can turn it up some more. One of my small C
projects has a list of gcc-options explicitly built for maximum anal
retentive mode of the gcc:
-ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Wshadow
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Waggregate-return -Wmissing-declarations -Wnested-externs -Winline
-Werror -W
This make gcc complain about practically everything looking even
remotely funny - only way to get more complaints would probably be to
use a real lint.
It can be annoying as hell, but I really find it helpful during
development.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
That assumption started in the first versions of Unix on the PDP11, and
still occurrs in new code. It's part of what was once called the
"all the worlds a VAX" mentality.
Make sure you have all warnings turned on when you compile (look for
the CC definition), under gcc the option would be '-Wall'. Maybe it will
point at something obvious.
Also try:
gcc -Wall -ansi -pedantic
Be prepared for *lots* of warnings.
-spc (I mean, lots) 
8:54 a.m.
New subject: IBM 5324
Anyone have information on the IBM 5324? I just picked up one and can find
nothing, nada, zip, zero, zilch on it. It's got the terminal, keybrd, and
box. I have yet to open it up, but will soon.
Thanks for any links or info you can provide.
Tarsi
6 Jun
6 Jun
5:14 a.m.
On Thu, May 29, 2003 at 03:44:52PM -0400, Sean 'Captain Napalm' Conner wrote:
Also try:
gcc -Wall -ansi -pedantic
Be prepared for *lots* of warnings.
-spc (I mean, lots)
i use MIPSpro and DEC C all the time. i'm *used* to lots of warnings. :)
-brian
--
"You know, evil comes in many forms, be it a man-eating cow or Joseph Stalin.
But you can't let the package hide the pudding. Evil is just plain bad! You
don't cotton to it! You gotta smack it on the nose with the rolled up newspaper
of goodness! Bad dog! Bad dog!" -- The Tick
29 May
29 May
7:34 a.m.
It was thus said that the Great Brian Hechinger once stated:
IMHO that's *always* a good thing. it has really opened my eyes to the fact
that your average opensource coder has been so coddled by the whole gcc/x86
platform that they have really started to make stupid mistakes and even
stupider assumptions about things. the most common assumption is that a
void pointer and an int pointer is the same size. which just happens to be
true in 32-bit land, but totally hoses those of us who live in 64-bit land.
A void * and an int, or an int *? Generally speaking, one can cast any
type of pointer into a void *, and cast a void * back to any other type of
pointer (without casts! At least in ANSI C; I think in C++ you need a
cast). But if you mean casting a pointer (of any kind) into an int (or
unsigned long, or whatever) then yes, I can see where that would definitely
lead to problems.
-spc (The only time my code failed on a 64-bit system, there was a bug
in the Standard C library of that system that I triggered ... )
8:54 a.m.
Sean 'Captain Napalm' Conner wrote:
It was thus said that the Great Brian Hechinger once
stated:
Usually a <mumble>* to an int, because on many systems an int and a
pointer are the same size (all the world's a vax). :-P A lot of older code
swaps pointers into/outof int's.
IMHO that's *always* a good thing. it has
really opened my eyes to the fact
that your average opensource coder has been so coddled by the whole gcc/x86
platform that they have really started to make stupid mistakes and even
stupider assumptions about things. the most common assumption is that a
void pointer and an int pointer is the same size. which just happens to be
true in 32-bit land, but totally hoses those of us who live in 64-bit land.
A void * and an int, or an int *? Generally speaking, one can cast any
type of pointer into a void *, and cast a void * back
to any other type of
pointer (without casts! At least in ANSI C; I think in C++ you need a
cast). But if you mean casting a pointer (of any kind) into an int (or
unsigned long, or whatever) then yes, I can see where that would definitely
lead to problems.
-spc (The only time my code failed on a 64-bit system, there was a bug
in the Standard C library of that system that I triggered ... )
27 May
27 May
6:15 p.m.
Brian Hechinger wrote:
where do i get simh help? i'm trying to install
VMS on a simh instance, and
it doesn't seem to want to play nice. where do i get help for simh? the
documentation is slim, and there seems to be no mailing list.
Sorry, can't help with the VMS quetions but this link should take you to
a SIMH mailing list - see you there.
http://mailman.trailing-edge.com/mailman/listinfo/simh
-- hbp
7870
days inactive
7880
days old
23 comments
9 participants
participants (9)
-
als＠thangorodrim.de -
d_cymbal＠hotmail.com -
erd_6502＠yahoo.com -
hansp＠citem.org -
kth＠srv.net -
pat＠purdueriots.com -
spc＠conman.org -
tarsi＠binhost.com -
wonko＠4amlunch.net