its icon indicating copy to clipboard operation
its copied to clipboard

Have a single SYSTEM; CONFIG?

Open atsampson opened this issue 6 years ago • 19 comments

At present, each of the three emulators we support has a separate copy of SYSTEM; CONFIG. This means that changes that don't just affect one emulator (e.g. to networking) have to be made multiple times.

Could we merge these back together into a single file? The sims KA10 has a different machine name anyway, but the klh10 and simh KS10s are both called DB -- we could distinguish them by expanding a "which emulator is this" variable in the Makefile (there's already a KLH10P variable), or we could give them different machine names (which is closer to historical practice).

atsampson avatar Aug 16 '18 20:08 atsampson

Yes, this would be desirable. I have considered it from time to time.

I thought about which name to use when I first wrote the expect script to automate the KSHACK; BUILD DOC instructions. I finally picked DB because that was the name for the generic KS10 distribution and I wanted to continue the tradition. KA10 wasn't in the picture back then.

I also thought about which names there would be for KLH10 and SIMH, but I wasn't pleased with any idea I came up with. My assumption has been that people wanting to use ITS really should pick their own names. So I didn't want to encroach on the name space by naming something that barely are worth it. My preference would be to do something with KLH10P.

larsbrinkhoff avatar Aug 16 '18 20:08 larsbrinkhoff

That sounds reasonable!

atsampson avatar Aug 16 '18 21:08 atsampson

Somewhat related to this, I think we should have a way to run the build with another ITS name than the default. E.g. make EMULATOR=klh10 ITS=AI.

larsbrinkhoff avatar Aug 17 '18 11:08 larsbrinkhoff

Another idea. Maybe it's possible to do something like the old AIKA etc. I.e. have two DBSIMH and DBKLH, and mask off the suffix.

larsbrinkhoff avatar Aug 25 '18 08:08 larsbrinkhoff

My current thinking is this:

  • For AIKA etc, mask off everything after the two first characters in MNAME. Don't change MCOND.
  • For DB ITS, add an additional query similar to /Configuration? (RP06, RP07, RM03 or RM80)

larsbrinkhoff avatar Aug 31 '18 05:08 larsbrinkhoff

New thinking. Have a common CONFIG file with the common definition, plus the "traditional" machines: AIKA, DM, etc. Then have each machine (DB, KA, ES, etc) add in their own section at build time. The combined file goes onto the minsrc tape for building the target ITS.

larsbrinkhoff avatar Feb 28 '23 06:02 larsbrinkhoff

I've been looking a the various config files and found that they are not in sync i.e. they are different depending on the emulator despite the fact that they all have pretty much the same core machine definitions in them. Would it make sense to start with one combined config file that gets copied into the emulator directory from a common location? Then we could work on improving the script to separate out the common/specific parts.

oilcan-productions avatar Feb 28 '23 22:02 oilcan-productions

One combined file will not work for DB that is different for SIMH and KLH10 (and maybe pdp10-ks?).

As I recall, some version of the config file comes with a macro to define simulated machines: DEFVKS. If that is one of the differences getting in the way, it could be removed.

I'd like to see these stay: AIKA, MLKA, DM, MC(KL), MX(KS), AI(KS), SI, FU, PM, DX?, PI?.

DB, KA, KL, TT, ES, HX, LC, etc should be removed from the common config. The fact that DB is used for three emulators may be a complication, but I think it can and should be solved. Maybe KA and KL should be renamed DB, but let's discuss that. The rest are configurations for individual machines that have been blessed by checking them into the repository. There's a longer list here: https://github.com/PDP-10/its/issues/686. It would be a bit much having them all checked in, but no big problem.

larsbrinkhoff avatar Mar 01 '23 07:03 larsbrinkhoff

I also suggest doing this separately from #2159.

larsbrinkhoff avatar Mar 01 '23 07:03 larsbrinkhoff

@larsbrinkhoff sounds good. Should we get on a call at some point to discuss or keep it here in the issues?

oilcan-productions avatar Mar 01 '23 19:03 oilcan-productions

I'm happy to do a call if you like, but I don't really have any more details worked out beyond what I sketched above. "Try it and see." When you have a draft on a branch, we can discuss the specifics.

Ok, I will add this. I imagine there's a common config somewhere, with a line like ;;; INSERT HERE. And then each machine has it's own fragment in some other place, like build/mchn/XX. At build time, the INSERT HERE is replaces with the $MCHN fragment. Something like that?

larsbrinkhoff avatar Mar 02 '23 06:03 larsbrinkhoff

I do not see how this is any different then what we have now. Much less useful, since now I can't just edit the config and rebuild.

rcornwell avatar Mar 02 '23 13:03 rcornwell

Having thought a little more about this, I have the idea that each machine should have its own CONFIG "fragment" in e.g. build/mchn/XX/config. But since some machines can run on more than one emulator, and emulators sometimes require different configuration, the build should first check if there is a file build/mchn/XX/config.$EMULATOR. E.g. maybe DB would have build/mchn/DB/config.simh, bhild/mchn/DB/config.klh10, and build/mchn/DB/config.pdp10-ks.

larsbrinkhoff avatar Mar 29 '23 06:03 larsbrinkhoff

There should probably also be a per-machine "ttytyp" file.

larsbrinkhoff avatar Mar 29 '23 07:03 larsbrinkhoff

What is the difference between this and what we have now? The object is to have same sources on all machines.,

rcornwell avatar Mar 29 '23 12:03 rcornwell

@rcornwell, I have tried to explain already, apparently unsuccessfully. I think the best thing to do now is "show us the code". I'm ready to give it a go when a free time slot appears.

larsbrinkhoff avatar Mar 29 '23 15:03 larsbrinkhoff

I am under the impression that this request is to have one master configuration file that includes all the systems being build. And that the individual configuration files for specific systems to be removed. Currently there is one configuration file for each system build. You are proposing a main configuration file that is assembled for each specific build from a global config file and a per system config file. It is unclear to me how this is an improvement of what we already have or how this meets the request being asked.

rcornwell avatar Mar 29 '23 16:03 rcornwell

I agree with Richard (I must be ill). We should have one config and all different ITS systems should have distinct names. I like to run multiple ITS systems on the same host — from different emulators. This should just work and each ITS should be able to reference the others.

eswenson1 avatar Mar 29 '23 17:03 eswenson1

There are a number of problems with the current state, which would be good to fix.

We should have one config

Yes, in so far there should be a single config file with all common information. Currently we have many different copies of the config file, which is not good.

all different ITS systems should have distinct names.

We have DB in use for KS10 emulators, but there are different configurations for different emulators. I wouldn't want to have a plethora of names for the GitHub project.

We have AI which has both KA10 and KS10 variants. We don't build any of those, but it would be nice with a solution that could do it.

I like to run multiple ITS systems on the same host — from different emulators.

I have no objection against this. A new solution should accommodate this.

each ITS should be able to reference the others.

Reference how? (With respect to the CONFIG file.)

larsbrinkhoff avatar Mar 30 '23 07:03 larsbrinkhoff