Hey Mike (et al),

I'm setting up an SMP-8 machine (700mhz CPUs) for simulated machines,
and had a bear of a time figuring out why I couldn't get responses
from the simulated 2000/ACCESS when telnetting in.

Turns out, setting ipl_ptime=1 in the simh hp2100_ipl.c did the trick.
(Thanks to Bill [dtpi_pappas] for tipping me off to this setting
through his postings here).

I've use ipl_ptime=8 on 2.4Ghz, 2.0Ghz, 1.6Ghz, 1Ghz, 800Mhz, 500Mhz
single-CPU machines and also on another SMP 700mhz (2-CPU) machine,
all running FreeBSD or NetBSD, with no problems.   Suddenly this
8-CPU 700mhz machine needs ipl_ptime to be really small.

Interesting bit is: 2000/F works fine.  Same simh, but different
HP IPL programming though.   Seems odd.  2000/E works fine on all
too.

Mike, might you pop a query to Bob Supnik and see if we can't get this
variable turned into a configurable setting at the console?   Would
make things a bit easier to adjust for different machines :-D

Nonetheless, I now have the 8-CPU SMP machine gearing up to handle
all my HP-2000 simulations (along with some others).

Cheers!
-scott

All,

If anyone is running simh V3.4-0 for a TSB system, you'll probably
want to fix the following (at least for FreeBSD and NetBSD).

If you disconnect a telnet connection into a TSB system running
under simh while the system is sending output to your terminal,
you can crash simh on the IOP side (2000F and ACCESS versions, and
probably 2000E as well).

The problem is that when simh is sending output to the socket
for your telnet connection, and you've disconnected, it will
simply crash the simh running the IOP.  This is because simh
is sending data using send(2) and should instruct the send(2)
call to prevent a SIGPIPE signal if the connection has closed.

The following fix will correct this:

--- sim_sock.c- Wed Aug  3 23:14:35 2005
+++ sim_sock.c  Wed Aug  3 23:14:41 2005
@@ -246,7 +246,7 @@

  int32 sim_write_sock (SOCKET sock, char *msg, int32 nbytes)
  {
-return send (sock, msg, nbytes, 0);
+return send (sock, msg, nbytes, MSG_NOSIGNAL);
  }

  void sim_close_sock (SOCKET sock, t_bool master)


Adding the "MSG_NOSIGNAL" to the flags (4th argument to send(2))
prevents a SIGPIPE signal that results when the attempt is made
to write to the socket when the socket has closed.

I'll pass this on to Bob Supnik as well, but wanted to point
this out here as well, as I believe there are people running
simulated TSBs here that might have this crash vulnerability.

Regards,
-scott

Hello all,

My name is Terry Newton, pleased to join the "family".
I've been hacking on the HP21MX for awhile, mostly working
on an on-going (never ending:) OS project but recently
discovered another world of existing software for the HP.
I put up a page containing screen shots of a few games
found in the Interex archives and restored to operation...

http://www.infionline.net/~wtnewton/oldcomp/hpgames/

Includes a source download but currently compiling and
running the games as-is requires RTE-IVB or equivalent.
I have SIMH save files for the board games and a modified
hp2100.exe program for emulating HP2615/HP2645 screen codes,
if anyone wants them let me know. My "capture" method is
rather crude at the moment, simply catching the programs
in a state of execution which chops off their initial text
output. I'd like to convert some of these games into
stand-alone ABS files, if anyone has any ideas...

Terry

I have provided Al Kossow ASCII extractions of the HP-2000 Contributed
Library tapes.   They are available at:
       http://www.bitsavers.org/bits/HP/tapes/2000tsb

The files there are:

2000dmp5-5-84iclContrib.dir.txt               15-Aug-2005 16:56   101k
2000dmp5-5-84iclContrib.tap.gz                14-Nov-2003 12:08   3.4M
2000dmp5-5-84iclContrib.tar.gz                15-Aug-2005 16:58   3.0M
36600-10001_2000contrib.dir.txt               15-Aug-2005 16:58    68k
36600-10001_2000contrib.tap.gz                14-Nov-2003 11:02   3.5M
36600-10001_2000contrib.tar.gz                15-Aug-2005 16:58   2.0M
HP_2000_Contributed_Library_Rev_1638.dir.txt  15-Aug-2005 16:58    68k
HP_2000_Contributed_Library_Rev_1638.tap.gz   15-Aug-2005 12:29   2.2M
HP_2000_Contributed_Library_Revâ€"1638.tar.gz 15-Aug-2005 16:59   2.0M

The .tap.gz files are the TAP/SIMH-format HP-2000 Tape Images.
The .dir.txt files are respective output logs of my tape processing
program, identifying tape header information and "DIR" format
directories of the files contained on the tape.
The .tar.gz are UNIX tar(1)-format archives of the tape files,
detokenized or converted to ASCII.

Additionally, Al has provided the Contributed Library indexes and
program documentation for the programs at:
       http://www.bitsavers.org/pdf/hp/2000TSB/
that accompany these tapes.

Share and enjoy.

-scott

Hi all, and another warm welcome to our new members.

I dusted off my tape drive taday and flipped through tapes and was
able to read a couple of new hibes.

The first set is a set of 3 tapes, hand writen lables (not my
handwriting)

"York Cty System, HIB, Archive, 800BPI, Tape 1 (-3) of 3"

The other is my handwriting,

"Cal Lib A000, Access, Before Purge" with a note in the seel reading:
"HIB w/ CALLIB and its files in A000, some progs may need work but
most OK"

Anyone wanting to work with them, just ask.

I tried another sleep from Datatornics systems corp (TSB-F) but it
has two load points and confuses my drive.

I'll try to get to others as time permits.

Thanks all, enjoy.

Mike.

Dear All,

About HP

HP provides technology solutions to consumers, businesses and
institutions across the globe. Our offerings span IT infrastructure,
personal computing and access devices, global services and imaging
and printing for consumers, enterprises and small and medium
businesses. Our company employs over 140,000 people in 178 countries
doing business in more than 40 currencies and more than 10 languages.

OUR REQUIREMENT

Expert - Unix system / HPe3000 / C programming – 892474

Job Description

Description

Software Engineers/Senior Software Engineers

Experience: 1-6 yrs
Mandatory Skills : Familiarity with COBOL
HPe3000 platform.
Familiarity with migration methodology
Expert - Unix system programming
Master - C and any other programming language
Optional :

Hi Ron,

--- Ron Jarrell <jarrell@...> wrote:

> Managed to accidentally kill simh while running
> access, and so now I have to
> warmstart if I want to recover... Is one of those
> tape files actually a
> master tape that I can use for that? Or just give up
> and reload the disk
> images from my backup?

Been there, done that :)

Yes, mcp4b.tap is a master.  Here's a quick example of
a reload/fixup with it:

(Just deliberately killed simh without a SLEEP...)
mod99# ./hp2100 asmain-big

HP 2100 simulator V3.5-0
Debug output to "STDERR"
Listening on port 4020
Listening on port 4021

MAG TAPE SELECT CODE? 16
2754? N
LOAD WHICH MODULE?  7920  <--- (I simulate 7920 and
2883 drives together)
7900 OPTION?  N
2883 OPTION?  Y
SYSTEM GENERATION? N
MAG TAPE RELOAD? N
SYSTEM NOT SLEPT; FOR WARM START ATTEMPT, LOAD MASTER
TAPE
AND PRESS RETURN.  OTHERWISE MUST RELOAD FROM MAG TAPE
PUT MAG TAPE UNIT ON-LINE.  PRESS RETURN

PUT MAG TAPE UNIT ON-LINE.  PRESS RETURN
<----- (Simulator interrupted with ^E)
Simulation stopped, P: 03237 (SFS 12)
sim> att msc0 mcp4b.tap
sim> cont


** WARM START PROGRAM **

ADT CHECK - OK

IDT CHECK - OK

DIRECTORY CHECK - OK

DISC SPACE USED CHECK - OK

WARM START CHECK COMPLETE

LOAD OR DUMP COMMANDS?
DATE?  255/05
TIME?  1513
HP22687A-1812
ROS
  ....  ....  ....  ....  ....  ....  ....  ....
  ....  ....  ....  ....  ....  ....  ....  ....
  ....  ....  ....  ....  ....  ....  ....  ....
  ....  ....  ....  ....  ....  ....  ....  ....

And you're back and running.

> Having been over 20 years I can no longer remember
> what I'm supposed to hit
> to be able to log in from the console, which I
> wouldn't worry about except
> the $hello in the image is apparently picky about
> that :). I think I'm
> confusing my hp3000 bits with my hp2000 too, which
> doesn't help, since I
> keep trying to use ctl-a...

TSB doesn't have login access at the console--only
operator commands are available there.

> How on earth do you do a break? I tried the telnet
> "send brk", which is what
> they use in a lot of emulators, but it didn't work..
> (since I could solve my
> problems with a000 by just reenabling break, if I
> could break.)

I found, quite by accident, that hitting CTRL-2
(sending a NULL) a few times from my BSD Xterm
does the trick.  This works on my linux and solaris
boxes running X11 Xterm as well.  I haven't figured
out what works for microsoft windows telnet yet.

> Now I'm regretting having gotten rid of my library
> of stuff stored on hp2645
> tapes. Or at least not having read it into something
> else before pitching
> them... I think I had the whole software library we
> had stored on the z999
> account on the fairfax county systems.

There are full contrib library tape images at
http://www.bitsavers.org/bits/HP/tapes/2000tsb/
now.  All is not lost :)

Hope this helps.

-scott

Been a while since much chatter has occured here, so I thought
I'd drop a note to keep the message count rising.

I'm about 98% completed with re-tokenization programming for
ASCII TSB BASIC files.

I've chosen 2000/ACCESS tokenization for this initial implementation.
2000/F will be supported a bit later.  Not radical changes, but
there are some significant difference and incompatibilities with
ACCESS.

Currently, I'm using both my de-tokenization and tokenization
processes against each other to cross-verify.  I'm working at the
ASCII comparison level today, but will begin debugging the
tokenized-data level tomorrow.

I've run into a few very odd situations, though... Primarily
involving 2000/F programs that were converted on-the-fly
by the 2000/ACCESS "CONVERT" utility.  Some results of that
CONVERT program loading tapes onto an ACCESS system result in
ASCII-representable program lines that are impossible to re-enter
into TSB.  (i.e.   ^N/^O character conversions to ^J/^M in
string literals in image statements).

There were previously a few parties on this list showing interest
in re-tokenizing programs.  Drop an email if you want to be kept
abreast of the progress.

And if ANYONE has ANY information on the TSC version of TSB Basic,
I'd REALLY appreciate hearing from you.  It's got some very
interesting feature to it, from what I've seen of the TSC tokenized
BASIC programs.

I must say that this has been one of the more enjoyable programming
experiences I've undertaken in recent years.   I really do miss
the Olden Days.

Best regards,
-scott

Scott,

This is very promising. For you to have found an artifact of the HP
conversion between F and Access has several implications. One is that
we should be able to say with conviction that some particular
programs in the available libraries were in fact written prior to
Access. Another point is that the process seems to be proving itself
as trustworthy.

Back in the days of the HP2000 some more sophisticated sites
developed techniques for modifying the tokens themselves after they
had been syntaxed. Through careful manipulation of the common area,
the symbol and or value table and or the File Control Block they were
able to peek and poke anywhere in system memory on a running system
from basic, on the fly. These programs were written by "white hat
hackers" but were subsequently modified by others to produce the
infamous "Account Jumpers".

As I recall a single patched statement was all that was necessary to
completely violate system security. It was a simple assignment
statement patched to create a type mismatch ultimately allowing a
string in common to end up with a logical length greater than it's
physical length. Using that string, arrays later in common could be
extended to span even greater areas of memory. This patched statement
could then be placed in some other program and smuggled onto a system
by tape without the operator catching on. After that, the rest of
the "Trojan" program could be stripped off and the rest of the
account jumper could be typed in around it.

Hewlett Packard's answer to this threat was to create a stand-alone
syntax checker that could be used to find and remove programs with
incorrect token syntax.

Your work with conversion between ASCII and tokenized forms of
programs now makes it much safer to release some of the peek and poke
programs from the GMU tapes.

Modifying the GMU Roster program to be an account jumper should not
be too much work. I guess it could be thought of more like the Unix
SU utility, perhaps requiring that the port first log in as A000, and
only allow A000 to become any other user on the system. (I wonder
what would happen if you jump to an account that does not exist) It
would be a bit more work to completely reverse engineer the peek and
poke process, but doable.

Very cool!

Hope this helps,
Mike.

Hello all, ive just joined the group and am pleasently suprised that there is
this much
activity and interest in getting old HP2000's virtually back into action.

I used an HP2000 Access back in the 70's when I was at high school here in
England. As a
little attempt to recapture my youth Im going to try and get an HP 2000 Access
system up
and running here on my Mac OSX (BSD like) laptop. Its amazing to see the manuals
again,
really does bring it all back.

Anyway, any pointers on where to begin with my little HP on Mac project? I
really have no
idea about this. I have only just learnt what SIMH is and know nothing about
that, and on
top of all that I have never used a HP2000 operator console so wouldnt know
where to
begin with booting an HP even if I got SIMH to work. All help appreciated.

On the upside, from my own HP Access days, I can remember a few of the unique
programs that were available on the Brighton Polytechnic Access System (and
could
probably recreate them) as well as one way to crash Access from any account (a
fudge with
the SYSTEM statement).

Best wishes

Quentin

OK, like wow...

In just some hours last night and today, I've
succeeded
in testing and matching the token-level generation
against the XREF program from the HP CSL.
It's one of the large and more complicated programs
I could find.   I can now state with assurance that
the tokenization code not only works, but really can
parse numeric expressions--I was worried about that.

See, TSB Tokenization has, for example, two kinds of
commas, two kinds of +/- symbols, and some other
interesting parsing of characters.  I really thought
my expression parsing would wind up fatally broken
when it came down to the token coding.  A bit of
foresight saved me on these issues though.

I'm actually quite fascinated at the extremes in the
TSB tokenization... There are some quite interesting
methods used for parsing and utilizing reentrant
code, but also some very odd (and wasteful, IMHO)
oversights.   One odd example is that whenever a
function (LEN, CHR$, SIN, POS, etc) is coded,
the arguments to the function are always followed by
an empty (NULL) word of data.  I didn't find this
fact documented, and couldn't realise it until
I actually performed token-level comparisons with
TSB tape data.  I suppose they did this "marker"
word of wasted memory to facilitate parsing rather
than save (possibly a lot) of user memory space.

And on some previously mentioned issues, take the
following statement I found on an ACCESS system:

1413  PRINT '13'10371"DATA      --TRAINING EXPENSE--"

That is an impossible statement to type in, however
it's there in the HP CSL program DECSN, 36065 REV C,
on ACCESS systems.

I can see clearly, though, how it occured.  When
the CSL program was converted to load on an ACCESS
system, it originally looked like:

1413  PRINT "^N^O"371"DATA      --TRAINING EXPENSE--"

The ACCESS loader "CONVERT" program blindly converts
the ^N and ^O characters to ascii 13 (10) and 10 (10).
The LIST output routine in TSB converts them to 'XX
notation.

This presents a directly problem to my efforts,
though.
Trying to parse  '10371  is impossible, as the
quoted-ascii can be either '10 or '103.

HOWEVER, on detokenization, I see the opportunity to
force the ASCII representation of the statement to
be:
1413  PRINT '13'10;371"DATA      --TRAINING EXPENSE--"

This would result in a one-word lenghthening of the
program length when re-tokenized, but would allow
all programs to be de-tokenized and back.

One other ^N/^O conversion issue is impossible to fix
when going to ASCII and back to token: IMAGE
statements.  Due to the nature of how IMAGE statements
are stored, there is simply no fix and the ASCII
output
is basically broken unless then resultant CR/LF
characters are removed.

A lotta babble above, but I just wanted to share my
success with all :)

And now on to responses to Mike's reply:


--- mgemeny <no_reply@yahoogroups.com> wrote:

> Scott,
>
> This is very promising. For you to have found an
> artifact of the HP
> conversion between F and Access has several
> implications. One is that
> we should be able to say with conviction that some
> particular
> programs in the available libraries were in fact
> written prior to
> Access. Another point is that the process seems to
> be proving itself
> as trustworthy.

Indeed trustworthy.  One thing to remember is that
even if you try to take concern with "hacked" CSAVE
programs, all the CSAVE tricks are lost when
detokenizing--It is LITERALLY a cut-and-paste image
of the program when LISTed on a TSB system.

So on that issue, no security issues.

And to prove the trustworthiness of the tokenization,
I will further be processing all 400,000 lines of the
CSL and PATTI libraries, comparing both ASCII
conversions and token conversions to ensure accuracy.
I'm building up a regression list of the most bizarre
statement syntaxes I can find for regular testing of
the code each time it gets modified.


> Back in the days of the HP2000 some more
> sophisticated sites
> developed techniques for modifying the tokens
> themselves after they
> had been syntaxed. Through careful manipulation of
> the common area,
> the symbol and or value table and or the File
> Control Block they were
> able to peek and poke anywhere in system memory on a
> running system
> from basic, on the fly. These programs were written
> by "white hat
> hackers" but were subsequently modified by others to
> produce the
> infamous "Account Jumpers".

Right, ROS is the most common example.  I have already
been looking at the ACCESS source to see what other
tricks we might exploit.

The TSC version of 2000/F really helps me here, too.
It uses a common system call (No clue what the
statement mnemonic for it is; I'll just call it "SYS")
to make calls into OS code.   For example, in ACCESS
we have the "CONVERT" statement.   In TSC, it's
a "SYS #11;A,A$" to do the equivalent of:
     CONVERT A TO A$

I do know that they had to use this format simply
because the 2000/F statement table was full, and they
couldn't add all the new functionality they wanted.
The ACCESS system broke the statement-type table
up, separating STATEMENTs from OPERATORs, thus giving
ACCESS room for more statement types.

From what I have discovered so far, TSC added 21
functions via a "SYS #n" call.  Lotsa stuff like
the convert, string math, and such.

If I can verify that the access source we have matches
the ACCESS 1B binaries we've got, we might even be
able
to coerce Jay West to help modify ACCESS with more
functionality.   I'm sure nothing he's doing would
be more important (Hi Jay :)

>
> As I recall a single patched statement was all that
> was necessary to
> completely violate system security.

... or simply crash the system :)

> Hewlett Packard's answer to this [security] threat
> was to
> create a stand-alone
> syntax checker that could be used to find and remove
> programs with
> incorrect token syntax.

I think my programming could head in this direction as
well.  My program originally presumed pristine ACCESS
BASIC code, but I've added syntax checking as much
as possible.  And when I find invalid syntax that I
don't yet catch, I do indeed add more checks.

> Your work with conversion between ASCII and
> tokenized forms of
> programs now makes it much safer to release some of
> the peek and poke
> programs from the GMU tapes.
>
> Modifying the GMU Roster program to be an account
> jumper should not
> be too much work. I guess it could be thought of
> more like the Unix
> SU utility, perhaps requiring that the port first
> log in as A000, and
> only allow A000 to become any other user on the
> system. (I wonder
> what would happen if you jump to an account that
> does not exist) It
> would be a bit more work to completely reverse
> engineer the peek and
> poke process, but doable.

From recollection, isn't "account jumping" simply
(pun intended) the manipulation of the Teletype
Table (putting the desired user ID in)?

One of the first modifications I'd like to make to
ACCESS is multiple backspace keys recognized (_, BS
and DEL) and even a smarter CRT-oriented mode for
erasing the characters being backspaced.  One problem
with ACCESS right now is that the backspace key
works, but for each backspace keypress, it still
emits a "_", leaving you with no clue how far you
backspaced.

> Very cool!
>
> Hope this helps,
> Mike.

Cheers.  I'm really quite enjoying this project.

--- Scott G Taylor <bub7734@...> wrote:

> Date: Mon, 3 Oct 2005 21:22:24 -0700 (PDT)
> From: Scott G Taylor <bub7734@...>
> Subject: Re: [HP2000 Family] Very cool!
> To: hp2000family@yahoogroups.com
>
>
> OK, like wow...
>
> In just some hours last night and today, I've
> succeeded
> in testing and matching the token-level generation
> against the XREF program from the HP CSL.
> It's one of the large and more complicated programs
> I could find.   I can now state with assurance that
> the tokenization code not only works, but really can
> parse numeric expressions--I was worried about that.
>
> See, TSB Tokenization has, for example, two kinds of
> commas, two kinds of +/- symbols, and some other
> interesting parsing of characters.  I really thought
> my expression parsing would wind up fatally broken
> when it came down to the token coding.  A bit of
> foresight saved me on these issues though.
>
> I'm actually quite fascinated at the extremes in the
> TSB tokenization... There are some quite interesting
> methods used for parsing and utilizing reentrant
> code, but also some very odd (and wasteful, IMHO)
> oversights.   One odd example is that whenever a
> function (LEN, CHR$, SIN, POS, etc) is coded,
> the arguments to the function are always followed by
> an empty (NULL) word of data.  I didn't find this
> fact documented, and couldn't realise it until
> I actually performed token-level comparisons with
> TSB tape data.  I suppose they did this "marker"
> word of wasted memory to facilitate parsing rather
> than save (possibly a lot) of user memory space.
>
> And on some previously mentioned issues, take the
> following statement I found on an ACCESS system:
>
> 1413  PRINT '13'10371"DATA      --TRAINING
> EXPENSE--"
>
> That is an impossible statement to type in, however
> it's there in the HP CSL program DECSN, 36065 REV C,
> on ACCESS systems.
>
> I can see clearly, though, how it occured.  When
> the CSL program was converted to load on an ACCESS
> system, it originally looked like:
>
> 1413  PRINT "^N^O"371"DATA      --TRAINING
> EXPENSE--"
>
> The ACCESS loader "CONVERT" program blindly converts
> the ^N and ^O characters to ascii 13 (10) and 10
> (10).
> The LIST output routine in TSB converts them to 'XX
> notation.
>
> This presents a directly problem to my efforts,
> though.
> Trying to parse  '10371  is impossible, as the
> quoted-ascii can be either '10 or '103.
>
> HOWEVER, on detokenization, I see the opportunity to
> force the ASCII representation of the statement to
> be:
> 1413  PRINT '13'10;371"DATA      --TRAINING
> EXPENSE--"
>
> This would result in a one-word lenghthening of the
> program length when re-tokenized, but would allow
> all programs to be de-tokenized and back.
>
> One other ^N/^O conversion issue is impossible to
> fix
> when going to ASCII and back to token: IMAGE
> statements.  Due to the nature of how IMAGE
> statements
> are stored, there is simply no fix and the ASCII
> output
> is basically broken unless then resultant CR/LF
> characters are removed.
>
> A lotta babble above, but I just wanted to share my
> success with all :)
>
> And now on to responses to Mike's reply:
>
>
> --- mgemeny <no_reply@yahoogroups.com> wrote:
>
> > Scott,
> >
> > This is very promising. For you to have found an
> > artifact of the HP
> > conversion between F and Access has several
> > implications. One is that
> > we should be able to say with conviction that some
> > particular
> > programs in the available libraries were in fact
> > written prior to
> > Access. Another point is that the process seems to
> > be proving itself
> > as trustworthy.
>
> Indeed trustworthy.  One thing to remember is that
> even if you try to take concern with "hacked" CSAVE
> programs, all the CSAVE tricks are lost when
> detokenizing--It is LITERALLY a cut-and-paste image
> of the program when LISTed on a TSB system.
>
> So on that issue, no security issues.
>
> And to prove the trustworthiness of the
> tokenization,
> I will further be processing all 400,000 lines of
> the
> CSL and PATTI libraries, comparing both ASCII
> conversions and token conversions to ensure
> accuracy.
> I'm building up a regression list of the most
> bizarre
> statement syntaxes I can find for regular testing of
> the code each time it gets modified.
>
>
> > Back in the days of the HP2000 some more
> > sophisticated sites
> > developed techniques for modifying the tokens
> > themselves after they
> > had been syntaxed. Through careful manipulation of
> > the common area,
> > the symbol and or value table and or the File
> > Control Block they were
> > able to peek and poke anywhere in system memory on
> a
> > running system
> > from basic, on the fly. These programs were
> written
> > by "white hat
> > hackers" but were subsequently modified by others
> to
> > produce the
> > infamous "Account Jumpers".
>
> Right, ROS is the most common example.  I have
> already
> been looking at the ACCESS source to see what other
> tricks we might exploit.
>
> The TSC version of 2000/F really helps me here, too.
> It uses a common system call (No clue what the
> statement mnemonic for it is; I'll just call it
> "SYS")
> to make calls into OS code.   For example, in ACCESS
> we have the "CONVERT" statement.   In TSC, it's
> a "SYS #11;A,A$" to do the equivalent of:
>     CONVERT A TO A$
>
> I do know that they had to use this format simply
> because the 2000/F statement table was full, and
> they
> couldn't add all the new functionality they wanted.
> The ACCESS system broke the statement-type table
> up, separating STATEMENTs from OPERATORs, thus
> giving
> ACCESS room for more statement types.
>
> From what I have discovered so far, TSC added 21
> functions via a "SYS #n" call.  Lotsa stuff like
> the convert, string math, and such.
>
> If I can verify that the access source we have
> matches
> the ACCESS 1B binaries we've got, we might even be
> able
> to coerce Jay West to help modify ACCESS with more
> functionality.   I'm sure nothing he's doing would
> be more important (Hi Jay :)
>
> >
> > As I recall a single patched statement was all
> that
> > was necessary to
> > completely violate system security.
>
> ... or simply crash the system :)
>
> > Hewlett Packard's answer to this [security] threat
> > was to
> > create a stand-alone
> > syntax checker that could be used to find and
> remove
> > programs with
> > incorrect token syntax.
>
> I think my programming could head in this direction
> as
> well.  My program originally presumed pristine
> ACCESS
> BASIC code, but I've added syntax checking as much
> as possible.  And when I find invalid syntax that I
> don't yet catch, I do indeed add more checks.
>
> > Your work with conversion between ASCII and
> > tokenized forms of
> > programs now makes it much safer to release some
> of
> > the peek and poke
> > programs from the GMU tapes.
> >
> > Modifying the GMU Roster program to be an account
> > jumper should not
> > be too much work. I guess it could be thought of
> > more like the Unix
> > SU utility, perhaps requiring that the port first
> > log in as A000, and
> > only allow A000 to become any other user on the
> > system. (I wonder
> > what would happen if you jump to an account that
> > does not exist) It
> > would be a bit more work to completely reverse
> > engineer the peek and
> > poke process, but doable.
>
> From recollection, isn't "account jumping" simply
> (pun intended) the manipulation of the Teletype
> Table (putting the desired user ID in)?
>
> One of the first modifications I'd like to make to
> ACCESS is multiple backspace keys recognized (_, BS
> and DEL) and even a smarter CRT-oriented mode for
> erasing the characters being backspaced.  One
> problem
> with ACCESS right now is that the backspace key
> works, but for each backspace keypress, it still
> emits a "_", leaving you with no clue how far you
> backspaced.
>
> > Very cool!
> >
> > Hope this helps,
> > Mike.
>
> Cheers.  I'm really quite enjoying this project.
>

IIRC from my days as an HP Access user (1975-1980), on HP vdus,
Tektronix 4010's and plain vttys backspace did indeed move the cursor
back along the line, although not erasing the characters until you
typed over them. I cant remember what happened on Decwriters and ttys
but I guess the underscore was used. Is my memory faulty or did we have
a patched system?

On 4 Oct 2005, at 05:22, Scott G Taylor wrote:

> One of the first modifications I'd like to make to
> ACCESS is multiple backspace keys recognized (_, BS
> and DEL) and even a smarter CRT-oriented mode for
> erasing the characters being backspaced.  One problem
> with ACCESS right now is that the backspace key
> works, but for each backspace keypress, it still
> emits a "_", leaving you with no clue how far you
> backspaced.



___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com

Hello

Well on my way to Access on Mac OSX now. Got SIMH HP2100 sim up and
running, now need an image for Access. Any pointers please?

TIA

Quentin





___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com

Hi all

Coming along nicely with my Access on OSX, now have hp2100 simh up and
running. Now need a image of Access, can anyone point me in the right
direction for this?

TIA

Quentin





___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com

Hi

I now have Access up and running on Mac OSX BUT when I telnet to the IOP mux I
get the
simh HP2100 simulator message, but no amount of ctrl-M ctrl-J's will get me a
PLEASE
LOG IN message. On the main console, all is good and all oper command works. Any
ideas?

Thanks

Quentin

Quentin,

I would try reducing the IPL Polling interval, ipl_ptime in
hp2100_ipl.c.
Lower numbers makes for faster polling but slows the simulation, so you
want it as large as can be while giving stable performance.

Keep us posted,
Mike.

For reference,

I have a 8-SMP 700mhz machine that requires
ipl_ptime=2, a 2.4ghz machine that requires ptime=8
and run ptime=10 most everywhere else.  Lower
numbers on any of those machines results in
what you're describing.

-scott

--- mgemeny <no_reply@yahoogroups.com> wrote:

> Quentin,
>
> I would try reducing the IPL Polling interval,
> ipl_ptime in
> hp2100_ipl.c.
> Lower numbers makes for faster polling but slows the
> simulation, so you
> want it as large as can be while giving stable
> performance.
>
> Keep us posted,
> Mike.
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Fair play? Video games influencing politics. Click
> and talk back!
>
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/f7l0lB/TM
>
--------------------------------------------------------------------~->
>
>
>
> Yahoo! Groups Links
>
>
>     hp2000family-unsubscribe@yahoogroups.com
>
>
>
>
>
>

Hey All,

--- Scott G Taylor <bub7734@...> wrote:

> For reference,
>
> I have a 8-SMP 700mhz machine that requires
> ipl_ptime=2, a 2.4ghz machine that requires ptime=8
> and run ptime=10 most everywhere else.  Lower
> numbers on any of those machines results in
> what you're describing.
>
> -scott

On my 1.4ghz AMD Sempron machine Access works ok
under WinXP using the default 31 value, but under
Linux (Knoppix) I've been unable to get it to work.
Just as with OSX I get the simulator message using
Telnet but can't log on with ctrl-M/ctrl-J.

I briefly tried using the latest simh (3.5.0)
but still no luck.

> --- mgemeny <no_reply@yahoogroups.com> wrote:
>
> > Quentin,
> >
> > I would try reducing the IPL Polling interval,
> > ipl_ptime in
> > hp2100_ipl.c.

This value can be set via the startup scripts or
from the simh console using: d ipli time value
where value is the number to set. To examine
the existing value use: e ipli time

I'd really like to get Access running under
Linux, it is inconvenient to boot into XP and
when I do I'm too afraid to play too much :)
If anyone has Linux tips I'd appreciate it,
might also be related to the OSX problem
since AFAIUI OSX is based on BSD Unix, not the
same but Linux is a *nix of sorts and probably
has similar networking methods.

Terry




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

Thanks to everyone for your help. Sadly no amount of fiddling with the
ipli time has got me a PLEASE LOG IN, so it looks like I am going to
have to understand how this works and see if I can get to the bottom of
it.

One minor thing that I did note was the the Windows asiop startup
script tries to use port 23 for the mux, this is not available on OSX
and probably most *nix systems, so I went for 3999 as this is
unreserved according to my services file.

Wish me luck and if anyone cracks this on their system in the meantime
(Im thinking Linux) let me know.

Quentin



___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com

Quentin,

I wanted to offer some observation that may help, perhaps as a last
resort.

Under windoz, I have been able to boot and run Access with the Main
and IOP running on different boxes, across a network.

If you were to set up such a configuration you could also introduce a
packet sniffer such as Ethereal to capture the conversation between
the two in an operational environment. What documentation we have of
the protocol between the two can be found in 22687-
90020_AccessInternals.pdf starting at PDF page 426 (and especially
PDF page 346-439).

You could then try replacing one of the windoz boxes with a Mac, and
look at the sniffer and work on that one side until it works, then
replace the other CPU with a Mac and work on that until it works as
well. Then try to put it all together on the same Mac.

It would be a slow process perhaps saved as a last resort but I did
want to offer it as an option.

Hope this helps,
Mike.

At the risk of being a pest, it occurs to me that a project such as
this could be split up among a number of people. If someone had the
Windows boxes and the time to set it up, capture the ethereal sniffer
data and post it. Someone else could take that captured data and work
up some code to dissect the conversation on the Interconnect between
the IOP and the Main processor. Then Quentin would only have to
capture his data between his IOP and Main (using the same sniffer)
and the same code could show us the difference between his two
processors conversation on the Interconnect and the working Windows
processors.

Just an idea, any volunteers?

I have a busy weekend and doubt that I will be of much help on this.

Hope this helps,
Mike.

I had written: (346 should have been 436, but even after that the
discussion may apply)

Quentin,

I wanted to offer some observation that may help, perhaps as a last
resort.

Under windoz, I have been able to boot and run Access with the Main
and IOP running on different boxes, across a network.

If you were to set up such a configuration you could also introduce a
packet sniffer such as Ethereal to capture the conversation between
the two in an operational environment. What documentation we have of
the protocol between the two can be found in 22687-
90020_AccessInternals.pdf starting at PDF page 426 (and especially
PDF page 346-439).

You could then try replacing one of the windoz boxes with a Mac, and
look at the sniffer and work on that one side until it works, then
replace the other CPU with a Mac and work on that until it works as
well. Then try to put it all together on the same Mac.

It would be a slow process perhaps saved as a last resort but I did
want to offer it as an option.

Hope this helps,
Mike.

Hopefully someone can save me the trouble of digging through the source
code....

You can create an account without a password by simply omitting a password
and preserving the positionality with ,,'s on the NEW- command. But.... if
you have an account that was NEW-'d with a password, and you want to remove
the password entirely (as opposed to changing it), how can one do that with
the CHA- command?

Not really a trivia question, because I don't know the answer ;)

On a side note... I have recently come into a fair quantity of 12920/12921
mux panels. If anyone needs one to get a real HP2K system up, contact me
off-list. I'm going to be regenning my 21MX/E access system this weekend
(and praying the wife doesn't notice the electric bill) to include RJE
support. I found a way to actually use that so I've been studying up on RJE.
Fun Fun!

Regards,

Jay West

----- Original Message -----

From: Ron Jarrell

To: hp2000family@yahoogroups.com

Sent: Friday, October 07, 2005 11:17 PM

Subject: [HP2000 Family] hp terminal w/tape?

Anyone still have access to a 2645 class terminal with a tape drive?  I found a couple of my old tapes which i'm pretty sure have a bunch of stuff from the z999 library of fairfax county's old pair of 2000's...

----- Original Message -----

From: Bob Brown

To: hp2000family@yahoogroups.com

Sent: Friday, October 07, 2005 11:12 PM

Subject: RE: [HP2000 Family] CHA-XNNN,,,, trivia question

Having success with Hercules for the mainframe side?

 

-Bob

 

---

From: hp2000family@yahoogroups.com [mailto:hp2000family@yahoogroups.com] On Behalf Of Jay West
Sent: Friday, October 07, 2005 10:02 PM
To: hp2000family@yahoogroups.com
Subject: [HP2000 Family] CHA-XNNN,,,, trivia question

 

Hopefully someone can save me the trouble of digging through the source
code....

You can create an account without a password by simply omitting a password
and preserving the positionality with ,,'s on the NEW- command. But.... if
you have an account that was NEW-'d with a password, and you want to remove
the password entirely (as opposed to changing it), how can one do that with
the CHA- command?

Not really a trivia question, because I don't know the answer ;)

On a side note... I have recently come into a fair quantity of 12920/12921
mux panels. If anyone needs one to get a real HP2K system up, contact me
off-list. I'm going to be regenning my 21MX/E access system this weekend
(and praying the wife doesn't notice the electric bill) to include RJE
support. I found a way to actually use that so I've been studying up on RJE.
Fun Fun!

Regards,

Jay West

--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: 10/7/2005

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: 10/7/2005