Well, I just found a REALLY stupid gap in the v3f sources as a possible platform for OS/8 Device Extensions Kit.

BATCH.PA is missing.

BATCH has a HARD CODED CONSTANT that links it to the version of the OS/8 Keyboard Monitor. You HAVE to have BATCH.SV that matches the version of OS8.PA you used. With v3f that magic constant CHANGED.

So when you try to make a complete system with the v3f Keyboard Monitor (OS8.PA), you MUST recompile BATCH.PA with the magic constant CBATCH updated. That value is set by wherever the assembler happens to put your page zero literal, for the entry to the monitor. Depending on what someone does to the source, that constant WILL change.

• They could have included BATCH.
• They could have been disciplined with the management of page zero literals.
• They could have keyed to a constant that wasn't going to change.

BUT NOOOOOOO!

The following diddling of the constant results in a BATCH that runs.

GET SYS BATCH
ODT
01776/3216 3207
200G

I shall ponder how to integrate this.

With this work, v3f can run batch and can run its own unique version of LCSYS.BI and UCSYS.BI that I've got under test now.

Further investigation:

BATCH.PA found in the os78v2 sources has VERSON=10 (which is 8 decimal).

The DSN 1979-December/1980-January for version numbers of all subsystems and how to get them. It says BATCH for the Combined Kit should be 8A. I think the codeline of BATCH.PA in os78v2 is what matches the Extensions kit.

I've decoded batch.en from Mike Thompson's snapshot of the Extensions Kit binaries. I've fed it to DCP24, the disassembler, and then fed v3d BATCH.SV to DCP24 as well.

I've produced source listings of the v3d BATCH.PA and the os78v2 BATCH.PA and I'm doing a comparison of the form:

• Recognizing that .SV files pick up bits in pages that don't matter and the disassembler will dutifully try to make sense of them, there WILL be differing blocks to be ignored.

• Step through the comparison of the listing files, and see if the differences reported in the .SV images by DCP24 make sense.

I have completed my analysis.

Essentially one looks at the binary output generated by

R PAL8
BAT782.BN,BAT782.LS<BAT782.PA

And confirms that the bits generated match the bits found in the disassembly output.

I have done that.

They differ in exactly one word:

Location 01776 contains the magic constant 3216.

It turns out that os78v2 contains OS/8 Keyboard monitor V3R, and the Device Extensions Kit contains V3S. The V3S monitor shifted that critical page zero literal and the magic constant in BATCH.PA needs to be 3207.

I shall take BATCH.PA from os78v2, change the value of CBATCH to its proper value, 4571 in source which will put the right magic constant, 3207 in location 01776, and we will have a bona fide BATCH V8A for the OS/8 Device Extensions, i.e. v3f sources.

I assume this isn't how the original OS/8 programmers worked, that you're being forced to rediscover this stuff essentially because OS/8 wasn't under version control, so you can't just roll back to the January 1980 version and have a single coherent snapshot of all of the source code for the files that went into the binaries that are still floating around.

This makes me wonder if it would be useful to retroactively reconstruct an OS/8 source code repository along the lines of the Unix history repository. I suspect the materials available for reconstructing the Unix history repo were more plentiful and available than what is now available for OS/8; it might not even be possible to reconstruct it now, except possibly by disassembly.

Another thought I have in reading through all of this is how you want to document what you've done for the release? The options I see are:

1. Summarize all of this for the ChangeLog.

2. Just point to this thread from the ChangeLog.

3. Rewrite it as a wiki article.

Reconstructing the OS/8 source code repository is precisely the concept I've had in mind since I started working on Device Extensions.

Indeed, I've been in contact with a couple people who've at various times tried reconstructing the source tree:

• Robert Armstrong, the guy who gave us the SBC6120. (If you don't know what the SBC6120 is, it's a kit like the PiDP-8/i, except that it's a 2/3 scale PDP-8e front panel look-alike and instead of a raspberry pi, it contains the Intersil 6120 chip that was a PDP-8 microprocessor.)

• Lee Nichols, who has a PDP-8 page of his own.

I've been pondering how to approach the task of making a tree that is:

• Historically accurate.
• Widely visible.
• Hosted in a way that it won't die if the one REALLY interested developer loses interest.
• Able to facilitate running and validation of code.
• A platform for follow-on development.

I was unaware of the UNIX history repository

Inasmuch as there is a project, Software Heritage that regularly crawls github, and allows for additional metadata, perhaps a github project with this stuff is apropos.

Indeed I was trying to figure out if there was a sensible way to export our fossil tree to github to enable making os8-run more widely visible. I'm trying to interest Vim van der Mark in this historical work but he wrote back saying he couldn't figure out how to see my stuff on tangentsoft. (Perhaps it was a typo in my email. I will dig deeper.)

Vince Slyngstad has his extensive DECUS historical archive on his site, but it's gonna go POOF if he does.

pdp8.org went POOF a year ago when Aaron Nabil didn't renew the DNS. I THINK his stuff is replicated somewhere...

P.S. I've been thinking that, to avoid confusion with the historical artifact "os8v3f" which is a particular archive file with particular sources, perhaps I should globally replace "v3f" with "v3g" or some such in our tree. I'm starting to diverge SIGNIFICANTLY from the os8v3f historical artifact.

Reconstructing the OS/8 source code repository is precisely the concept I've had in mind since I started working on Device Extensions.

I think what's made available through this repository should be focused on end-user deliverables.

What I proposed above should be separate, in the same way that the binary Unix kits are separate from Spinellis' Unix History Repository.

That repo is read-only and is re-generated occasionally as more history is uncovered and reconstructed. End users never make checkins to that repository, since it is a historical archive only. I think the same approach will work for OS/8 under Fossil.

In fact, you might be able to reuse some of the tools they used to build that repository, at least as educational models.

I was trying to figure out if there was a sensible way to export our fossil tree to github

Yes.

However, I'd have thought the lesson of relying on third-party hosting services would be clear to everyone by now. Just in the source code repository space, we've lost Google Code, Gna!, and CodePlex, and we almost lost SourceForge. GitHub is now owned by Microsoft, who previously abandoned CodePlex.

While tangentsoft.com could go away, the clones you and many others now have can't all go away unless you all also lose interest at the same time. This is what you get from a proper DVCS.

Most of the features that make GitHub what it is require re-centralizing the DVCS, which puts you at the central service's mercy. There is no equivalent of "fossil ui" with a GitHub repo, to open the web view of a repo and see pretty much exactly what you do on github.com.

If you want to re-publish this repository on GitHub, you don't need my blessing. Just take my warning with you instead: It's a Trap!