I'm about to check in changes to Makefile.in to enable creation of v3f-td12k.tu56 and v3f-tc08.tu56 by default.

There is a robustness issue:

There are device architecture issues that force simh to enable EITHER td (TD8E) or dt (TC08) dectape but not both.

There is an OS/8 architecture issue where there is not a lot of space for device drivers.

The td12k maker does something ugly: It modifies the default boot pack device drivers by:

a. Using the dt/TC08 device to attach a tape with device drivers.

b. Loading the TD8EA.BN driver from that dt/TC08 image into the system BUILD program.

c. Disabling TC08 DECtape.

d. Enabling TD8E DECtape.

e. (It also turns off the init.tx startup message.)

Although the switching from dt to td enablement in simh goes away when you quit and restart simh, the active device drivers in OS/8 stay configured for TD8E unless explicitly cleaned up.

The td12k maker cleans up this ugliness when it is done. Unless it errors out before it can clean up.

Without the cleanup, scripts that assume they can work with DECtape images will hang when they try to read them.

I have a script, "v3d-reset-tc08.os8" that undoes what the td12k maker should clean up, but fails to clean up on errors.

QUESTION:

Should we try and make this situation less fragile?

Things we could do:

a. Put TD8EA.BN in the version of BUILD.SV hosted on the v3d.rk05 running pack. (Presuming there is room.)

b. Have the td12k builder use a scratch copy of v3d.rk05

c. Add "on error cleanup" capabilities into os8-run.

d. Not care, because it's working now.

Can any command in the os8-run program or its libraries that cares about the tape format check whether the OS/8 device driver it needs is present on the boot media before doing its work, and error out if it isn't present?

(Or equivalently, poke around in core for evidence of the driver being loaded.)

Wellllll... There's an architectural bug in os8-run, and it goes like this: There is currently NO way to test for the output of commands run under OS/8 from within a script.

Implementing such functionality is made more complicated by the fact that the event loop is backwards.

When the event loop changes from:

Listen for Prompt -> Act -> Special case output

to:

Act -> Listen for output

Then we can add constructs to the scripting language that will enable testing of output from OS/8 commands.

After having implemented and checked in choice a, and having now clarified that choice c is a major project that really should not happen until the redo of the event loop (which for many reasons we have agreed is out of scope for the merge), and having decided that choice d, not care is probably wrong, I shall take the step of using a scratch version of the system packs. TOTALLY doable, and 2.5 meg of intermediate file is tiny compared to other stuff we are doing.

2.5 meg of intermediate file is tiny compared to other stuff we are doing.

Megs I'm less concerned about than build time. How much longer does it make the build, as a percentage? A wild guess is fine; just get me within a factor of 10 or so. :)

It actually DECREASES the build time.

Instead of taking several steps at the end of the build to:

1. re-attach the system disk.
2. re-run BUILD.
3. De-configure TD8E.
4. Configure TC08.
5. Exit

We take one step at the beginning of the build:

1. cp v3d.rk05 v3d-copy.rk05

And one step at the end of the build:

1. rm v3d-copy.rk05

This is a CLASSIC case of trading time for space.

(P.S. Using Fossil Wiki formatting instead of Markdown because my enumerate got converted to bullets.)

It actually DECREASES the build time.

Then I see no reason not to do it.

Using Fossil Wiki formatting instead of Markdown because my enumerate got converted to bullets

While composing a much longer reply, I discovered the problem, which is actually an error I made in one of my local updates to the PiDP-8/I Fossil skin for v2.7, not a problem with Fossil itself. (The change makes the new hamburger menu render nicer than with the stock skin CSS.) It's fixed now.

With that CSS bug fixed, there's still some of my prior post's educational content that's worth keeping, so here it is:

First, this message of yours that I'm replying to is set to use Markdown, not Fossil Wiki. You can see it by editing the post and looking at the "Markup style" setting, If you distrust the UI, you can also see it with this low-level command:

$ fossil artifact edf0d92256

That shows you the raw artifact content in a format documented here. In particular, reading up on Fossil's "card" concept will help you understand what the raw artifact data means.

You can retrieve the post's hash many different ways:

1. In the email alert message at the end of the URL it gives to point you to the new post.

2. Click the "Link" text in the forum web UI to make Fossil highlight the post, then extract the forum post's unique hash from the URL in your browser's address bar.

3. Go to the Timeline, find your post there, and get a hash any way you could do for any other change recorded by Fossil. With this option, if you can't find the entry for your forum post, the Timeline is probably filtered not to show it; the Timeline defaults to showing checkins only.

And more, but those will suffice.

In addition to the MIME type, the artifact command above also gives the post's raw text, and I can't fault Fossil's choices in rendering your Markdown to HTML.

I recommend that you don't indent lists like that with Markdown, since indentation is meaningful in Markdown. I'm kind of surprised that Fossil managed to do the "right thing" with that at all, since normally an indented list makes it a child of a list item with no indentation, if it can find one immediately above. That's probably why it Fossil has done what appears to be the right thing here, despite being given ambiguous input: because there is no parent list item for it to make any of these three lists a child of.

Markdown's syntax is structured around 4-space indentation, so it's better to left-justify each list numeral in Markdown, then put 2 spaces after the dot for single-digit list items so that the paragraph text starts in column 5. This then lets each paragraph wrap properly to give the intended "hanging numeral" effect, both in Markdown and in the plaintext. For a child list, the numeral starts in column 5, and the paragraph text in column 9:

1. First item, left-justified

   1. Child list item, starting in column 5

2. Second top-level item, still left-justified

(NOTE: It was in constructing that example that I first saw the CSS bug.)

If you look at this post's raw text using the artifact command, you'll also see that this post uses Markdown's auto-numbering feature, though I normally don't like to use that, since it means the plain text form isn't numbered properly.

Contrast Fossil Wiki, which requires two spaces followed by either an asterisk or a number sign depending on whether you want bullets or a numbered list, followed by two spaces. Fossil Wiki syntax is rather strict about that spacing. Fossil Wiki also has trouble with blank lines in lists. Markdown is much more flexible with how you're allowed to format lists, which is one of several reasons I prefer it.

The next time you hit Preview and Fossil shows you something you don't expect, feel free to send me a copy of the raw text somehow. I'll be happy to diagnose it for you.

Funny story for you!

Halfway through editing that message, I switched to Markdown because I found a way to get Markdown to do what I wanted, and then FORGOT to delete my complaint.

Nevertheless, I'm grateful for the tutelage, and glad you found and fixed the problem that was messing with my lists.

I would like to look at the raw version of your reply, but since I'm not the author, I don't get the edit option.

If I want to use the artifact command, where in the hierarchy do I need to be?

It didn't work from a random directory in my build tree, which made sense.

wdc-home2:v3f wdc$ fossil artifact edf0d92256
not found: edf0d92256
wdc-home2:v3f wdc$ pwd
/Users/wdc/src/pidp8i/os8-v3f-extensions/src/os8/v3f

It also didn't work from within the museum directory.

wdc-home2:PiDP-8 wdc$ cd ~/museum/
wdc-home2:museum wdc$ ls
pidp8i.fossil
wdc-home2:museum wdc$ fossil artifact edf0d92256
use --repository or -R to specify the repository database
wdc-home2:museum wdc$ ls
pidp8i.fossil
wdc-home2:museum wdc$ cd pidp8i.fossil 
-bash: cd: pidp8i.fossil: Not a directory
wdc-home2:museum wdc$ file pidp8i.fossil 
pidp8i.fossil: SQLite 3.x database

wdc-home2:museum wdc$ fossil artifact edf0d92256 -R pidp8i.fossil not found: edf0d92256

You probably need to run fossil sync to pull down recent Forum posts to your local repository. The artifact command only looks in your local clone, so if it's out of date, the command won't find newer artifacts.

You can get my prior post's artifact with

$ fossil art 52594a2afa

I see you actually did discover the proper syntax there at the end, but it failed because the local clone hadn't been sync'd recently. The equivalent for my post above is:

$ fossil art -R ~/museum/pidp8i.fossil 52594a2afa

Fossil is pretty tolerant about position of options on the command line, but I prefer to gather them at the start, except when editing past commands.

You might want to put this into your local crontab:

42 2 * * * /usr/local/bin/fossil all sync

The time is semi-random: chances are very low that I'm doing anything with Fossil at 2:42 am on any given day.

Thanks for the additional tutelage.

I see about the auto-numbering. There are 3 sections prefaced by "1. " and one of them is displayed as "2. ".

I shall consider a cron job to do fossil sync. I never remember to do it myself. As soon as I did it, then the artifact command worked from my random working directory in my branch.