scripted setup of tops10 for decwar

[statespacedev]

idea is to build on rich's work https://sky-visions.com/dec/tops703/ for scripted setup of a baseline tops10 for decwar

based on the steubentech image modified by merlyn that we have and that does work, we want scripted install from tape of fortran-10 v6 from https://pdp-10.trailing-edge.com/ - here's download of tape image https://pdp-10.trailing-edge.com/tapes/BB-D480C-SB_1981.tap.bz2

[statespacedev]

hi rich - @rcornwell - so i've got the 'pdp10-kl load.ini' script rolling along seemingly ok - boots from tape, creates the two rp6 files in /dsk, nice console output and can get a command line (think it's booted from the rp6 files by then actually?)

but then, having trouble with 'pdp10-kl run.ini' though - so bypassing tape and just booting from the rp6 files - not getting any console output and command line, so far - just kinda 'locks up' - the lights on the front panel are blinking, but doesn't look too healthy, not like the boot from tape...

any experiences with difficulties around kl booting from the rp6 files? cheers, noah

[rcornwell]

You can't boot directly to the RP06 on KL10. You need to load "bts/boot.exb", then continue to get it running, You get a BOOT prompt, pressing return will load and execute "dsk:system.exe[1,4].

[statespacedev]

boom!!! wootwoot! beautiful! thank you rich! @rcornwell - booting!!! first try after seeing your reply:)
yep was trying the run.ini 'as is' and it ended like so

if "%SIM_NAME%" != "KL-10" goto KS
load -c bts/boot.exb
goto BOOT
:KS
boot %DSK%0
:BOOT

just needed to change that to

if "%SIM_NAME%" != "KL-10" goto KS
load -c bts/boot.exb
continue
goto BOOT
:KS
boot %DSK%0
:BOOT

[statespacedev]

will try to track script versions here https://github.com/drforbin/decwar/blob/minimalist/docs/sec6-scripted-tops10-setup.md
and in the folder 'tops703' there
this 'first version' builds system fast, with no extra software -
can try adding kermit and fortran on that now - then testing decwar compile -
expecting will need the older fortran, but might get surprised, we'll see!

[statespacedev]

note to self around accounts - simply making a junk pile here of past notes, to help try to remember some of this stuff:)

rando notes

here's some comments from merlyn

    The original place where decwar was placed was 5,30 which was the GAM:
    ersatz device, CIS was using [1,27] was the multiplayer decwar directory.
    Everyone would be handed off from their original hosts to that HOST and logged onto that directory.
    The CIS source is Always referencing it.

current pic is that the three files below could be direct from the utexas tape that got sent to compuserve. notice they don't mention the many 'newer / later / compuserve' fortran files. so...

at utexas the build was done in [10,30,decwar] and then deployed to gam: which was a 'logical device name' assigned to [5,30].

at compuserve, the build was deployed to [1,27]. not clear yet where they did there build, hopefully doesn't really matter too much?

note to self, if it's not already there, create p,pn [1,27] using react, then copy DECWAR.EXE, DECWAR.GRP, DECWAR.HLP, DECWAR.NWS to its home folder to 'deploy/install' it. [1,27] is where decwar was deployed for compuserve. for utexas it was logical device name 'gam:', assigned to [5,30].

decwar.imp has mucho learnings about 'building decwar from tape'

this is clearly some important stuff. hence the '.imp' extension. and note it's first thing listed in decwar.tap file. in fact, decwar.imp and decwar.tap match up perfectly.

one useful thing could be that [10,30,DECWAR] was an important folder / sfd at some point, probably for the build from tape described in decwar.imp, so p,pn 10,30 and sfd [10,30,decwar] were important back then, and could still be! in fact it's even possible that if we were 10,30 and in [10,30,decwar] then everything would magically work. this may be something to try asap.

for our possible 'include' troubles, note especially

Files INCLUDEd in DECWAR.FOR (extracted from WARMAC.MAC by TECO macros):
PARAM.FOR	Parameters (constants).
HISEG.FOR	High segment common block.
LOWSEG.FOR	Low segment common block.

Tools used to build game (.SAV files generated from TECO macros):
PARAM.SAV	Build PARAM.FOR from WARMAC.MAC.
HISEG.SAV	Build HISEG.FOR from WARMAC.MAC.
LOWSEG.SAV	Build LOWSEG.FOR from WARMAC.MAC.
EXTERN.SAV	Build EXTERN.FOR from MSG.MAC.
SETEXT.SAV	Build SETEXT.FOR from SETMSG.MAC.

TECO macros used to build game (require TECO 124):
PARAM.TEC	Source for PARAM.SAV.
HISEG.TEC	Source for HISEG.SAV.
LOWSEG.TEC	Source for LOWSEG.SAV.
EXTERN.TEC	Source for EXTERN.SAV.
SETEXT.TEC	Source for SETEXT.SAV.

hmmm, don't have teco 124, potential trouble? wasn't for merlyn! but potentially could be for a 'build from tape'?

.teco param.tec
[2K Core]
*^C
.version
TECO 24A(235) + 

merlyn's build workflow and the 'steubentech descendant'

with kermit rolling and files prepped over from raspi side to tops10 side, time this weekend to start digging into merlyn's instructions from the file 'changes' in the repo.

CAN1.CMD is linker control file for building executable.
DECCMP.CMD full compile control file.

these two @COM1, @com2 are splitting up and equiv to @deccmp. @can1 gets used for r link.

.compile @com1
.compile @com2
.r link
*@can1
.get decwar
.ssave
then create p,pn [1,27] and install DECWAR.EXE, DECWAR.GRP, DECWAR.HLP, DECWAR.NWS in that p,pn. then
.dir [1,27]
.r [1,27] decwar

the one already there decwar in [1,27] is definitely working. and looks like there's also another older one already there in [5,30]

.dir [5,30]
.r [5,30] decwar

[rcornwell]

First off you can add additional accounts in my script by adding them to load.ini under r react section.

Most likely I would say source for decwar probably can go in [10,30,decwar], data files in whatever ppn you want. Then put main decwar executable in [1,4]. So they can just say "r decwar".

[statespacedev]

yep being able to automate all the account stuff is a huge win with the scripts - already starting on that today:)

[drforbin]

That's incorrect. It's looking for account [1,27] for the stat files.

[statespacedev]

ahha - thinking this means the compuserve code brought on some dependencies on [1,27] - merlyn knows cause he tamed the compuserve code enough for returning to vanilla tops10 - so this is a show stopper right here - we can forget about the earlier utexas stuff for now - the compuserve code is expecting [1,27]

just fwiw - maybe someday it could be possible to have an 'almost original pure utexas' version - do have the feeling the original utexas tape is there in what we've got today - and even revive the original teco scripts, etc - but for now happy to focus on what we've got in hand and getting that going with scripted tops10:)

[drforbin]

I could change it! But the cis code is looking for the stat (history) files in 1,27.
The standard utexas code does run fine in sys: [1,4].
If you guys can find the original ut code I'd love to look at it.
I think the reference to 1,27 is in warmac.mac...look there.

[statespacedev]

ok thanks merlyn, will add this to our notes for future use - no worries we'll keep rolling cis style for now - have already added [1,27] usr decwar pwd decwar to the install script and just used it for the first time - logged in as [1,27] decwar!:)

[drforbin]

You dont have to login as 1,27
it just looks for the stat files in 1,27
The executable should be able to be placed elsewhere as well, I think?
Have a look at warmac.mac and search for 1,27
There should be a function called stat or something like that which is called to handle the history files.
The swap file of course follows whereever the executable is. You would have to change decfix.exe
because it does look in 1,27 also.

[drforbin]

Again thxs for keeping this alive guys!

[drforbin]

it's also on hecnet

[drforbin]

Did I commit my changes fixing the romulan speaking and the TALK command?
Also these was a memory leak which was associated with varibles being changed within loops.
remember fortran is call by reference not call by value, so there will be blood!

[statespacedev]

think those fixes are in the development branch merlyn - hoping to dig into those onboard new 'scripted decwar machine' - we'll see!:) fortran is up next - kermit and [1,27] are working, links to the v2 scripts are in these notes here - will probly kick off a new discussion thread for fortran, hoping it will go smooth but...;) we'll see!

https://github.com/drforbin/decwar/blob/minimalist/docs/sec6-scripted-tops10-setup.md#itr2---kl-only-cleanup-kermit-decwar-account

[drforbin]

The latest is up on the server...my tops10 server which you have access to Noah

[rcornwell]

You do not have to create an account for [1,27], just create a directory. "r credir", then "dskb:[1,27]/protect:xxx".

[statespacedev]

ahha! understood, makes sense rich, true!:)
well, already did add the user, and it's working ok - password disabled, etc
maybe one nice thing is, when you kermit in and login as decwar - boom you're in the [1,27] directory, hahaha:)
here at first am just going to be kermit dumping some fortran files in there and seeing if can compile em
just making a total junk pile right there in [1,27] until we're sure things are working good -
then hopefully can tidy up and get smart about how to make 'decwar tape' tap file - loooooots to learn there for me!:)

[drforbin]

Just path[1,27]

[drforbin]

Yes, that's correct. You just need ufd.

[statespacedev]

just thinking about it and realizing that for a 'normal install' / install from tape, there's good reasons to keep things nice and minimal and zen with just ufd [1,27] - build elsewhere and install 'around' a [1,27] ufd (however the install ends up looking in detail, exe file elsewhere etc:)
so if we're able to add a decwar.tap to rich's library - that can be our objective!:)
least we can do to pay you back for your awesome work with all these tap files and scripts rich!:)