Monopoly game (written in Basic)
Tim Radde
remembers a really big Monopoly game that was
written in Basic. It spans several files and uses CHAIN to go back
and forth. I have a printed copy only. I think
it ran on the pdp-8, but am not totally sure. I seem to recall
running it and seeing it produce a printout of the
board. It had other features like an accelerated game, and others I
no longer remember. Just curious if anyone
remember this game?
Tim Radde
Johnny Billquist
Don't remember seeing that, but I would suspect it would be something
for RSTS/E rather than OS/8...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
David Gesswein
Tim Radde <tra...@excite.com> wrote:
>After seeing the thread on Eliza it got me wondering if anyone
>remembers a really big Monopoly game that was
>written in Basic. It spans several files and uses CHAIN to go back
>and forth.
>
are referring to.
pdptim
My first thought was it came from the pdp-10 I used while at Penn
State. But there is some writing
on the front page (that I wrote) and this particular item was
something from my early college days with their
pdp-8. I suppose it could have come from the remote system they had
access to. I don't remember what kind
of system that was. It's the biggest monopoly game I ever saw coded.
I guess it really doesn't matter
where it came from.
glen herrmannsfeldt
> After seeing the thread on Eliza it got me wondering if anyone
> remembers a really big Monopoly game that was
> written in Basic. It spans several files and uses CHAIN to go back
> and forth.
This reminds me that in high school I started working on Monopoly
with a friend in HP 2000TSB BASIC. We never completely finished it,
partly because we didn't use CHAIN and it started to get too big.
-- glen
Charles Richmond
ISTM that there was a version of Monopoly that ran on the Commodore 64.
There is a version of Monopoly in the DEC book "101 BASIC Computer
Games". I think it is written in PDP-8 BASIC. It starts on page 153 and
is called "mnoply.bas".
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Johnny Billquist
> Tim Radde wrote:
>> After seeing the thread on Eliza it got me wondering if anyone
>> remembers a really big Monopoly game that was
>> written in Basic. It spans several files and uses CHAIN to go back
>> and forth. I have a printed copy only. I think
>> it ran on the pdp-8, but am not totally sure. I seem to recall
>> running it and seeing it produce a printout of the
>> board. It had other features like an accelerated game, and others I
>> no longer remember. Just curious if anyone
>> remember this game?
>>
>
> ISTM that there was a version of Monopoly that ran on the Commodore 64.
>
> There is a version of Monopoly in the DEC book "101 BASIC Computer
> Games". I think it is written in PDP-8 BASIC. It starts on page 153 and
> is called "mnoply.bas".
Dave Ahl's "101 BASIC Computer Games" is definitely RSTS/E. :-)
Oh, and had it been for a PDP-8, it would have been named "MNOPLY.BA" :-)
David Powell
>Charles Richmond wrote:
>> Tim Radde wrote:
>>> After seeing the thread on Eliza it got me wondering if anyone
>>> remembers a really big Monopoly game that was
>>> written in Basic. It spans several files and uses CHAIN to go back
>>> and forth. I have a printed copy only. I think
>>> it ran on the pdp-8, but am not totally sure. I seem to recall
>>> running it and seeing it produce a printout of the
>>> board. It had other features like an accelerated game, and others I
>>> no longer remember. Just curious if anyone
>>> remember this game?
>>>
>>
>> ISTM that there was a version of Monopoly that ran on the Commodore 64.
>>
>> There is a version of Monopoly in the DEC book "101 BASIC Computer
>> Games". I think it is written in PDP-8 BASIC. It starts on page 153 and
>> is called "mnoply.bas".
>
>Dave Ahl's "101 BASIC Computer Games" is definitely RSTS/E. :-)
>
This is the one I have:
.TY RKB1:MONPLY.BAS
1 REM MONOPOLY GAME BY DAVID BARKER, SOUTHEASTERN STATE COLLEGE,
DURANT, OK
2 REM SLIGHT PROGRAM MODIFICATIONS BY DAVID AHL, DIGITAL
3 REMARKABLY TRANSLATED TO OS8 BASIC BY KAY R. FISHER ...DEC
>Oh, and had it been for a PDP-8, it would have been named "MNOPLY.BA" :-)
>
OS/8 doesn't care, call it "FOO.BASIC" if you like :-) After 1978ish
the third and subsequent chars were accepted and ignored. The down
side of that is, if you accidentally type a PDP-11 style "DEL *.BAK"
to make a bit of space on your DECtape, then it's the .BA files that
go. :-(
And getting them back under OS/8 isn't easy. :-((
Regards,
David P.
Johnny Billquist
Then it's not from the book straight off. But yeah, lots of people used
that book as a base, and adopted to their computers basic dialect.
Fun! It would actually be interesting to see the whole program, but I
don't think that's something we should post here.
>> Oh, and had it been for a PDP-8, it would have been named "MNOPLY.BA" :-)
>>
>
> OS/8 doesn't care, call it "FOO.BASIC" if you like :-) After 1978ish
> the third and subsequent chars were accepted and ignored.
True. But if you typed DIR, you'd still see "MONPLY.BA".
> The down
> side of that is, if you accidentally type a PDP-11 style "DEL *.BAK"
> to make a bit of space on your DECtape, then it's the .BA files that
> go. :-(
:-)
> And getting them back under OS/8 isn't easy. :-((
Hmm... It shouldn't be that hard, unless someone squished the disk
afterwards, in which case you loose.
But I can't remember ever seeing an UNDELETE program. But I don't see
any problems creating one. Perhaps the biggest problem would be
realizing where a file ended, if it wasn't a text file, since there is
no information left to figure that one out afterwards.
Interesting exercise. I'm almost tempted to write one right here and now...
pdptim
I looked at the date on the front banner page of this listing and it's
June 11th, 1976. So it's from the time where
I was using the 8i at the school, but it must have been from their
remote system they had access too. The
Basic has Matrix reads/writes in it. I don't know of any Basic that
support that in the DEC world?
Johnny Billquist
> I looked at the date on the front banner page of this listing and it's
> June 11th, 1976. So it's from the time where
> I was using the 8i at the school, but it must have been from their
> remote system they had access too. The
> Basic has Matrix reads/writes in it. I don't know of any Basic that
> support that in the DEC world?
We are definitely not in PDP8-land. But we are in DEC-land. Both BASIC+
and BASIC+2 do.
This on a PDP-11 (running RSX) with BASIC+2:
***********
BASIC2
help sta mat input
STATEMENTS
MAT
INPUT
The MAT INPUT statement assigns values from a terminal or terminal-format
file to array elements.
Format
MAT INPUT [ chnl-exp, ] { array [ (int-exp1 [,int-exp2]) ] },...
Example
1000 MAT INPUT Emp_name$(10,10)
***********
David Gesswein
Johnny Billquist <b...@softjar.se> wrote:
>
>Then it's not from the book straight off. But yeah, lots of people used
>that book as a base, and adopted to their computers basic dialect.
>Fun! It would actually be interesting to see the whole program, but I
>don't think that's something we should post here.
>
David Gesswein
http://www.pdp8online.com/ -- Run an old computer with blinkenlights
Have any PDP-8 stuff you're willing to part with?
pdptim
> In article <gv40qt$fb...@Tempo.Update.UU.SE>,
> Johnny Billquist <b...@softjar.se> wrote:
>
> >Then it's not from the book straight off. But yeah, lots of people used
> >that book as a base, and adopted to their computers basic dialect.
> >Fun! It would actually be interesting to see the whole program, but I
> >don't think that's something we should post here.
>
> A link was posted earlier in this thread.
>
>
> David Gessweinhttp://www.pdp8online.com/-- Run an old computer with blinkenlights
> Have any PDP-8 stuff you're willing to part with?
I don't have a pdp-11 that run RSX or RSTS. I believe Basic-Plus was
available for both? My 11/84 runs
BSD Unix only right now.
cjl
> > In article <gv089a$ad...@Tempo.Update.UU.SE>,
>
> - Show quoted text -
Of course if it is a text file, PIP can handle it. When I convert
files to/from P?S/8 <-> OS/8, the default conversion location on the
device is block 0016. [In OS/8 logical terms, record 0007.]. A
typical usage would be something like.
.R CONVRT,FILE1, FILE2, FILE3, FILE4 > /1=0016
This P?S/8 command runs the inter-system conversion program. Passed P?
S/8 text files' contents is concatenated together, converted into OS/
8's definition of 8-bit ASCII [really 7 bit] and written raw to
logical unit 1 at block 0016. The 0016 is default, but for safety,
you have to specify the output unit. For example, if booted to a P?S/
8 DECtape system on unit 0, mount a scratch DECtape on unit 1. The
result is a single OS/8 ASCII text file in the usual default place.
Booting to OS/8, use PIP to zero the directory and then create a file
of arbitrary name in place. [I don't remember the command line
switches; is it /I=xxxx where xxxx is the length of file you want to
fake ?]. You can use a length that is far too long; no need to
guess. When PIP is then used to create the file from itself [in ascii
mode, which is the default], it reads the file and finds the control-
Z. Then the directory entry is rewritten with the appropriate correct
length, etc.
The command is reversible: Just make the P?S/8 file list be output
files and the entire process goes the other way, i.e., towards P?S/8
files. [The line numbers are created starting at 100 by 10, just like
BASIC].
The usual P?S/8 restriction of 17 files max applies. For larger
projects, there are switches to use the prevailing P?S/8 extended file
structure as a single output file of arbitrary length. No line
numbers are created in this usage. The towards OS/8 direction ignores
line numbers, if present, so converting the single file back to the OS/
8 format also works, just pass the single input file, etc.
Just for information: P?S/8 runs in 2K, not 4K. This includes a 2K
internal buffer for a tentative file to be edited. Each file supports
line numbers which can be modified. The line numbers are stored in 12-
bit binary; 0000 and 4095 are not allowed. The rear of the file
stores start-of-line pointers and the line number in the rear of the
2K file in pairs. The text is in the front as a stream. The file is
full when the pointers would overlap to add another line, etc.
When you run a P?S/8 system program, you get a list of up to 17 passed
files. [Interally, a count-of-output-files is passed to delineate
input from output; the P?S/8 command processor allows command forms of
either output < input or input > output, so you can use whichever form
is more intuitive for you.] Any program is welcome to expect the line
numbers; for example there is a printing program usually known as
PRINT] that ornately lists them out on the console or on an available
LPT: with the possibility of some passable formatting switches. You
can opt in or out the line numbers among other things.
However, most programs only expect to see the concatenated stream of
the text characters from all of the files stitched together. The
CONVRT program outputs towards OS/8 in that mode, but when it comes
from OS/8, it auto-creates the standardized line numbers itself. If
the output file is realized [by passed option switches] that it is not
a member of this file system, and instead belongs to the extended file
system [where there are no inherent line number considerations], the
output file is created essentially as a continuous stream of what
would be in a long chain of the 2K files sans line numbers. [All P?S/
8 text files use the same definite end-of-file internal convention.]
In this operating mode, the file size can essentially be most of a
maxxed out physical device of 4096 blocks which corresponds to around
2048 OS/8 records, far longer than a DECtape.
Most really long source files easily fit into 14 or so files. [Note:
You need to have a few output files for the binary!]. If it's really
too long, the CONVRT program can be used in both directions using a
scratch tape [that perhaps never actually gets to OS/8!] as an
intermediary in both directions:
First specfify up to 17 2K text files that want to eventually become a
single extended file's contents. Convert to OS/8 format. Then
specify a single extended directory file as output to the OS/8-style
input. Thus, now all of those files are in one long file. For truly
insanely long source code files, you can repeat this process up to
sixteen times. Thus, as a practical matter, you could pass to P?S PAL
the contents of something north of 256 2K files since each of up to
somewhat less than 17 files could be passed where each one has the
concatenated contents of what [was] is 17 files in their original
form. No one is writing PAL files that long! [I have written stuff
that would be around 100 files in a single assembly; this gets you a
six-inch thick assembly listing from your line-printer. I admit I did
most of the editing with OS/8 TECO, and this occupied most of an RKA1:
on an RK05/RK8E disk cartridge.]
Remember that P?S/8 is designed to actually run on 4K machines. The
2K that isn't the file buffer also includes the latest device
directory. This scheme was invented by Richard Lary [who I am glad to
report is getting past some really serious medical problems recently].
The idea is that you bring into the editing buffer any 2K file
[segment] of your source code. As long as it fits in 2K [leave
sufficient "extra" space to handle most cases], you can just write the
file right back. Since the before and after directory entries are
unmodified, no long-time tape motion occurs; you just write the file
back in-place. [Note: If you find yourself running out of room, you
have to save the file, erase a portion, save that to an alternate file
location; if you planned ahead for this, the tape motion could merely
be relative, since the contingency file can be pre-allocated for the
purpose. Later, you can rename the file for name consistency when you
allow the tape to return to the front of the tape at a time of your
choosing. This random-access editing saves an amazing amount of time,
especially on DECtapes! [Remember, Richard Lary and Lenny Elekman
wrote this on and for a single-DECtape 4K straight-8. From the
forerunner of this system [R-L Monitor AKA MS/8] POLY BASIC and P?S
SPACEWAR were written on the same machine.]
Some people "who don't like to get their fingernails dirty" will turn
their noses up at all of this, but given the alternatives to do OS/8
or DMS type stuff on the same hardware would take impractically too
much time to even do it at all, this is the only rational way to
implement a practical editor. [Note: At the time, it was proven that
a skilled operator of the high-speed reader/punch could develop code
faster than using the DMS on a DECtape.] Of course, for fancier
hardware, P?S/8 should eventually get to do more OS/8-style stuff as
well. Clearly choices are always better...
Years ago, Mark Hyde of Syracuse University wrote a universal file
system converting program that ran in 4K. It is limited to internal
device handling, but does know about TC01/TC08 DECtape and PDP-12
Linctape. The program is totally stand-alone, and only assumes that
07600-07777 is off limits. It can be loaded from paper-tape, DMS, P?S/
8 or OS/8. It also runs on his PDP-15-based PDP-8 simulator [which
supports internal OS/8 and P?S/8 I/O optimization; when the program
realizes that P?S/8 binary loader is running, it instead runs real
PDP-15 code that does what the loader would do instead of running the
loader code one simulated execution at a time. Same for P?S/8 normal
file I/O and all similar OS/8 operations as well as the file
converting program. Breaking out of the simulator into instead
emulation makes the program actually practical!]
In the case of creating P?S/8 text files, the created files are aware
of the line numbers' space allocations, but doesn't actually write
them out. In essence, it write the files one single output block at a
time, stopping when the file would overflow had the line numbers been
implemented All that is required is a single sentinal 12-bit word of
0000 to signify end-of-file. Then it moves on to the next P?S/8
output file as necessary, etc.
Once this is done, the P?S/8 editor can trivially fix the files: Just
load them into the editor and invoke the line number resequence
command with any arguments you want [defaults to start at 100 and
steps of 10; override as you will]. Due to the tremendous consistency
checking, the file is able to be self-repaired from any line number
pair info corruption, including in this case totally lack of any non-
zero information correct or otherwise. Then just save the file
inplace. Repeat for all file created by his program.
cjl
David Powell
>David Powell wrote:
>> In article <gv089a$ad2$3...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@softjar.se> in alt.sys.pdp8 wrote:
>>
>
>True. But if you typed DIR, you'd still see "MONPLY.BA".
>
>> The down
>> side of that is, if you accidentally type a PDP-11 style "DEL *.BAK"
>> to make a bit of space on your DECtape, then it's the .BA files that
>> go. :-(
>
>:-)
>
>> And getting them back under OS/8 isn't easy. :-((
>
>Hmm... It shouldn't be that hard, unless someone squished the disk
>afterwards, in which case you loose.
Not necessarily, any write may, or may not overwrite the deleted
stuff, but anyone who squishes an unbacked-up volume onto itself
deserves to loose. Always easier to restore from backup than attempt
to recover.
>But I can't remember ever seeing an UNDELETE program. But I don't see
>any problems creating one.
There was an UNDELETE, but it had problems. IIRC, called "DROP",
often available at DECUS UK / EU conferences late 1970s, on a DECtape
of "Use at you own risk" stuff. It worked, more or less, on a single
segment dir, but IIRC had problems with the expansion of a full
segment into the next. It identified ASCII and .BN files, and the
rest had their block0 data interpreted as the CCB of a .SV, with a
suggested name if the data matched one the CUSPs.
>Perhaps the biggest problem would be
>realizing where a file ended, if it wasn't a text file, since there is
>no information left to figure that one out afterwards.
Life is easy with text files if all files are written to their logical
end.
>Interesting exercise. I'm almost tempted to write one right here and now...
>
I look forward to seeing the result...
In the meantime, I'll stay with the tried and tested method of opening
the whole device in TECO and searching for the right bit(s). Then
checking to see that it's all there and it is not a deleted earlier
version, etc.
Regards,
David P.
Johnny Billquist
No, BASIC+ was/is only for RSTS/E.
BASIC+2 on the other hand was/is available for both RSX and RSTS/E.
Johnny Billquist
TECO is (always) your friend. :-)
Or in this case SUPERTECO (if my memory don't have parity errors...).
David Powell
>David Powell wrote:
>> In article <gv40qt$fbu$1...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@softjar.se> in alt.sys.pdp8 wrote:
>>> Interesting exercise. I'm almost tempted to write one right here and now...
>>>
>>
>> I look forward to seeing the result...
>> In the meantime, I'll stay with the tried and tested method of opening
>> the whole device in TECO and searching for the right bit(s). Then
>> checking to see that it's all there and it is not a deleted earlier
>> version, etc.
>
>TECO is (always) your friend. :-)
>
>Or in this case SUPERTECO (if my memory don't have parity errors...).
>
If you did it that way and typed DIR, you'd probably see "STECO.CM".
:-)
Ooops! We're in a loop! Time to ^G^G out.
Regards,
David P.
Mike Roach
<tra...@excite.com> wrote:
I never used the PDP-8 or PDP-11 versions, but I do remember the PDP-10
version. I converted it (as well as that weird STARTREK game, and some
others) to run on the Alpha Microsystems' AM-100 BASIC. At the time I
don't think I converted any of the PDP-8 (OS/8 or TSS/8) games I had
used; they were on a DECTAPE I lost years ago in a flood. The PDP-10
games were on paper tape and I was able to read them into an Alpha Micro
by using a teletype. Eventually the converted games made it to the
Alpha Micro User's Society (AMUS) library and onto VCR and MAG tapes
distributed by AMUS.
Hmm ... anyone here have any of the old AMUS library files? Last time I
checked the files weren't available online. I'll have to check with my
old contacts and see if I can find anything.
--
You can do this in a number of ways. IBM chose to do all of them.
Why do you find that funny?
-- D. Taylor, Computer Science 350, University of Washington
Johnny Billquist
> In article <gvcf78$b0f$1...@Tempo.Update.UU.SE>,
> Johnny Billquist <b...@softjar.se> in alt.sys.pdp8 wrote:
>
>> David Powell wrote:
>>> In article <gv40qt$fbu$1...@Tempo.Update.UU.SE>,
>>> Johnny Billquist <b...@softjar.se> in alt.sys.pdp8 wrote:
>>>> Interesting exercise. I'm almost tempted to write one right here and now...
>>>>
>>> I look forward to seeing the result...
>>> In the meantime, I'll stay with the tried and tested method of opening
>>> the whole device in TECO and searching for the right bit(s). Then
>>> checking to see that it's all there and it is not a deleted earlier
>>> version, etc.
>> TECO is (always) your friend. :-)
>>
>> Or in this case SUPERTECO (if my memory don't have parity errors...).
>>
>
> If you did it that way and typed DIR, you'd probably see "STECO.CM".
> :-)
>
> Ooops! We're in a loop! Time to ^G^G out.
Hmm, no. SUPERTECO was just plain TECO, but you added a switch to the
input file, I think it was.
So, still TECO.SV
(I guess I could check the documentation if this really is important...
Or the source...)
.CM, by the way? What files used that extension? I can't remember ever
seeing it.
David Powell
>David Powell wrote:
>> In article <gvcf78$b0f$1...@Tempo.Update.UU.SE>,
>> Johnny Billquist <b...@softjar.se> in alt.sys.pdp8 wrote:
>>
>>> David Powell wrote:
>>>> In article <gv40qt$fbu$1...@Tempo.Update.UU.SE>,
>>>> Johnny Billquist <b...@softjar.se> in alt.sys.pdp8 wrote:
>>>>> Interesting exercise. I'm almost tempted to write one right here and now...
>>>>>
>>>> I look forward to seeing the result...
>>>> In the meantime, I'll stay with the tried and tested method of opening
>>>> the whole device in TECO and searching for the right bit(s). Then
>>>> checking to see that it's all there and it is not a deleted earlier
>>>> version, etc.
>>> TECO is (always) your friend. :-)
>>>
>>> Or in this case SUPERTECO (if my memory don't have parity errors...).
>>>
>>
>> If you did it that way and typed DIR, you'd probably see "STECO.CM".
>> :-)
>>
>> Ooops! We're in a loop! Time to ^G^G out.
>
>Hmm, no. SUPERTECO was just plain TECO, but you added a switch to the
>input file, I think it was.
>So, still TECO.SV
>
Just a two word patch to TECO. For the version distributed in the
OS/8 extensions kit, it was documented as (something like):
.GET SYS TECO
.ODT
(Do the patch)
.SA SYS STECO
Mass storage far too valuable for that sort of trick, we had the patch
stuck to the top of the LA30 (with a few others) and applied it as
necessary, but the .CM is an alternative.
>(I guess I could check the documentation if this really is important...
>Or the source...)
>
>.CM, by the way? What files used that extension? I can't remember ever
>seeing it.
>
The "+2" contraction of .COM - indirect command file.
Regards,
David P.