Stewardship of v3f Source

(1) By Bill Cattey (poetnerd) on 2018-10-06 21:38:19 [link] [source]

I've researched the source file BUILD.PA in the v3f source.

Digital Software News May/June 1979 (DEC AA-H820-BA) page 37 gave version number corrections against what was published in the Device Extensions User Guide AA-D319A-TA:

5.   The Device Extensions kit binary of BUILD,SV should be V7A
and NOT V6A. Version 7A is the BUILD.SV that will work under
Batch.

The other 4 line items refer to pages in the User guide. This one just says the version number should be different.

I have compared the v3f source of BUILD.PA against other BUILD.PA versions and have learned:

OS/8 v3d and OS/78 v2 are identical.
v3f and OS/278 are identical except for 3 newlines.
v3f appears to be the basis for version 40 found at vandermark.ch.

My conclusion: is that the software developers spazzed, but nobody wanted to issue a patch or a source correction so late in the development life of the package.

Line 634 of v3f should change "V6A" to "V7A".

QUESTION: How do we want to account for this? I can modify BUILD.PA in .../src/os8/v3f to change the line so that it looks right going forward. The version difference is significant. V7A works under the OS/8 BATCH system.

People running BUILD should get the proper version.

(2) By Bill Cattey (poetnerd) on 2018-10-16 00:26:19 in reply to 1 [link] [source]

After much meditation, I decided that the source code management of this tree gives a good history of changes. I amended Makefile.in to depend on the .../src/os8/v3f sources {.PA,.MA,*.BI} for PAL, MACREL, and BATCH input source.

I changed line 634 of BUILD.PA from "V6A" to "V7A"

Everything rebuilds nicely, and the changes are tracked.

I consider this issue to be closed. I invite readers of this thread to disagree.

(3) By Warren Young (tangent) on 2018-10-17 14:34:27 in reply to 2 [source]

I changed line 634 of BUILD.PA from "V6A" to "V7A"

That sounds sensible to me. We might also document it separately, explaining why we're not building something that matches byte-for-byte what might've been built in 1975 or whatever, but I see no reason we have to remain byte-for-byte compatible with the original binaries within the PiDP-8/I project.

Other projects might have stricter emulation requirements, which is one of the reasons we might document our differences: in case someone takes our source tree as canonical, for whatever strange reason.