Reading/Writing to DECTape

[Bob Smith]

I have developed some utilities for reading/writing to RK8E devices and all works well.  I would like to test if they can be made to work for DECTapes.  My system is on RKA0.  I cannot find a way to access DECTapes for read/write with the User Service Routine.  I have tried attaching an image of a DECTape converted to SimH format.  I can load the DTA0 device handler, but cannot create a write file with USR's ENTER command.  Is it possible to access DECTapes on an RK8E system and if so is there a way of attaching an image that can be used with USR?  Even though the PiDP8 build lists the DTA0 device I cannot read the Directory of the DECTape image I have attached.

[Rick Murphy]

Yes, you can have a DECTape controller (TC08 or TD8E) on a system with an RK8E.

Chances are that your tape image doesn't have a valid OS/8 directory, especially given that DIR DTA0: isn't working. Zero the "tape" with ".ZERO DTA0:" and you should be fine. Note that ZERO wipes out the tape so make sure you're starting from a fresh image that you don't care about.

    -Rick

On Tue, Oct 24, 2017 at 10:02 PM, Bob Smith <rrjd...@gmail.com> wrote:

I have developed some utilities for reading/writing to RK8E devices and all works well.  I would like to test if they can be made to work for DECTapes.  My system is on RKA0.  I cannot find a way to access DECTapes for read/write with the User Service Routine.  I have tried attaching an image of a DECTape converted to SimH format.  I can load the DTA0 device handler, but cannot create a write file with USR's ENTER command.  Is it possible to access DECTapes on an RK8E system and if so is there a way of attaching an image that can be used with USR?  Even though the PiDP8 build lists the DTA0 device I cannot read the Directory of the DECTape image I have attached.

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/34f7571a-5d86-40e7-a4a9-3827e92fd94f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[William Cattey]

The OS/8 V3D RK05 system pack build Warren and I have in the trunk of the PiDP-8/i build tree has

built in and tested support for TC08 style DECTapes.  I use it all the time.

At SIMH, you use device dt<n>  where <n> is your unit number:

So from within OS/8 under Simh, to mount a DECTape called mine.tu56 you would proceed as follows:

^e

sim> att dt0 mine.tu56

DT: creating new file

DT0: 12b format, buffering file in memory

sim> c

DIR DTA0:

BAD INPUT DIRECTORY 

.ZERO DTA0:

.DIR DTA0:

          

 730 FREE BLOCKS

.

Note that on the PiDP-8, the current directory may not be writeable so you might have

to provide  a longer path. Something like "/home/pi/mine.tu56"

From the above example, you see that it creates a new file.

But you can also attach existing files.

Going forward, I hope to make this RK05 system image useful to REAL PHYSICAL machines.

But to do that, I need to change from TC08 support to TD8E support.  

Here's why:

TC08 was a big, expensive DMA option, that was common on larger configurations of PDP-8/I.

The TD8E "Simple DECTape Controller" was a single-board add-on that, like the Woz chip, used

the CPU to do the heavy lifting.

DEC used the SAME device ID for both kinds of DECTape, so you CANT have an OS/8 build

that supports both TD8E and TC08.

Also SIMH needs to use the device ID, so the SIMH dt device is for TC08 emulation, and

the SIMH td device is for TD8E emulation.

I opted for the TC08 for the PiDP-8/i because it runs a lot faster.  The emulator just does block

copies at the Linux level.  The TD8E emulation would run the CPU and copy bits. The difference is 

significant and noticeable.

However, the RK05 packs I've created could easily be burned onto physical packs with Dave Gesswein's

tools.  For deployment on PDP-8e systems, it is to be expected that the USUAL DECTape is TD8E.

So I'll cook up a simple procedure to make a TD8E build of the packs.

Good luck spinning virtual tapes!

[Warren Young]

On Wednesday, October 25, 2017 at 2:01:38 PM UTC-6, William Cattey wrote:

sim> att dt0 mine.tu56

DT: creating new file

Note that the second line above only appears if "mine.tu56" isn't found. If you thought you gave the path to an existing *.tu56 file, check your current working directory from within SIMH with a !pwd command.

Note that on the PiDP-8, the current directory may not be writeable so you might have

to provide  a longer path. Something like "/home/pi/mine.tu56"

That's being fixed in the next release: the default current working directory of the simulator as booted by the /etc/init.d/pidp8i script will be $prefix/share/media, which should be writable by the user who installed the software. It also happens to be a good place to store files like "mine.tu56".

If you start the simulator another way, such as "make run", CWD will remain wherever the caller left it.

 

So I'll cook up a simple procedure to make a TD8E build of the packs.

That should be a small matter of code in mkos8, plus a corresponding configure script option.

[Bob Smith]

I should have mentioned I am using SimH on Windows at the moment.  I find it much faster to develop complicated assembly language routines in the Windows environment before transferring them to the PiDP8.  When I tried your example below, SimH hangs after typing the first DIR.  If I try to execute ZERO DTA0: first, SimH hangs at that point.  I can only recover by typing CTRL-E and no file is created when I exit SimH.  Thus I do not think the problem is with the PiDP8 install.  Perhaps I have a defective rk0.dsk image, but it has worked with everything else I have tried.

[Warren Young]

On Wednesday, October 25, 2017 at 3:01:07 PM UTC-6, Bob Smith wrote:

If I try to execute ZERO DTA0: first, SimH hangs at that point.

What does an OS/8 "RESORC" command give? 

[Bob Smith]

.RESORC

SYS,DSK,RKA0,RKB0,RKA1,RKB1,RXA0,RXA1,TTY,LPT,DTA0,DTA1,PTP,PTR

[William Cattey]

At SIMH, instead of "dt" use "td".

I'm guessing that your OS/8 disk packs are configured for the TD8E driver instead of the TC08 driver,

and so SIMH happily connected a file to the TC08 channel, but OS/8 is waiting for device ready on the

TD8E emulated hardware.

On Tuesday, October 24, 2017 at 10:02:58 PM UTC-4, Bob Smith wrote:

[Bob Smith]

William,

If my disk pack were configured for RTD8e would RESORC report the DTA0: and DTA1: devices?  I don't recall where I got my RK05 image of OS/8, but I have also downloaded other RK05 images containing the DTA0 device and I even reloaded SimH, version 3.9, all to no avail.  Are you using SimH version 4.0?  The only other thing I can think to try is to use an RK05 image that is proven to work with DECTapes.  Could you send me a copy of an RK05 image that works for you?  Remember, I am using SimH in Windows not PiDP8.  I am waiting for Warren's upcoming release to install it, but as of now I am still using Oscar's original distribution.  Thanks for your patience.

[Bob Smith]

Bill,

The RK05 image you sent me solved my problem!  I am now able to access and transfer documents to/from DECTapes.  The problem must have been having the wrong disk images for what I was trying to do.  Next test is to confirm it works with USR; I am sure it will.  Thanks for all your advice and patience working me through this issue.  I am looking forward to your and Warren's next release.

On Thursday, October 26, 2017 at 8:38:34 AM UTC-7, William Cattey wrote:

[William Cattey]

In answer to your query, YES, RESORC knows only of "DTA" devices regardless of whether they are

controlled by the TD8E driver or the TC08 driver.  In order to learn which driver is associated with the name,

you would have to run BUILD, and issue the PRINT command.  It would detail not only the devices

assigned, but also the drivers associated with them.

Sorry for the delay in answering this question. I know you've got an image that has all the bits aligned.

Nevertheless, for others, I want to help clarify the DECTape situation.

-Bill

[Bob Smith]

Bill,

You can also find out which driver is being used by OS/8 with the command RESORC/E.  Either TC08 or TD8E will be listed.  I believe this is what Warren suggested I try, but I neglected the /E qualifier.

[Warren Young]

On Friday, October 27, 2017 at 11:59:33 AM UTC-6, Bob Smith wrote:

You can also find out which driver is being used by OS/8 with the command RESORC/E.  Either TC08 or TD8E will be listed.  I believe this is what Warren suggested I try, but I neglected the /E qualifier.

Thank you for the broad application of the principle of charity, but I was just trying to find out if you had any DECtape controller drivers at all installed. :)

Incidentally, we now publish default configurations of all of our generated OS/8 media on the project home page for people like you, who aren't using the current PiDP-8/I software but still want to try the OS/8 disk images. Since this relies on a feature that isn't yet formally released, these images are "beta" in some sense, but Bill & I have been running on them for weeks now with no problems.

[clasystems]

On Friday, October 27, 2017 at 1:59:33 PM UTC-4, Bob Smith wrote:

Bill,

You can also find out which driver is being used by OS/8 with the command RESORC/E.  Either TC08 or TD8E will be listed.  I believe this is what Warren suggested I try, but I neglected the /E qualifier.

On Friday, October 27, 2017 at 6:56:28 AM UTC-7, William Cattey wrote:

In answer to your query, YES, RESORC knows only of "DTA" devices regardless of whether they are

controlled by the TD8E driver or the TC08 driver.  In order to learn which driver is associated with the name,

you would have to run BUILD, and issue the PRINT command.  It would detail not only the devices

assigned, but also the drivers associated with them.

Resorc has an internal round-about process to determine the "type" of a device; it is by no means written in a straight-forward manner.  RESORC was one of those ;later programs that were clearly needed, but having not planned for them, it's difficult to get the information, as opposed to BUILD that by definition "knows" everything about the TENTATIVE system it creates [should you correctly build it and more importantly actually BOot it, making your actual system be in sync with that particular copy of BUILD.

In point of tact, there is nothiing "sacred" about BUILD or its name.  Savvy users have tons of image copies of BUILD each with a different name so the configuration needed can be created in short order.  In fact, it is always true:  IF you cannot find out, run BUILD and remember what it told you.

We have other devices, some user-written and it is anywhere form difficult to near impossible to get RESORC to "know" about them because to do so, we have to invent NEW kludges that are not only new, but also not in conflict with the existing standard ones.  The only thing OS/8 actually "knows" is exactly how to get a handler loaded, in terms of is it a one page or a two page, and the relative entry point.  Thus, all RESORC ever is is just "educated guesswork" to be charitable.  This is also why you must NEVER mix-and match these components from different-era OS/8 variants.  The kludges drift in memory between releases, etc.

Additionally, RESORC has no way to actually know the size of for example, DECtapes be they TC08 or TD8E.  The only actual arbiter of size is the directory on the current DECtape as accessed through the handler.  There is a table within the core image of PIP.SV which is used to set the DEFAULT sizes of devices, but it has no control over their actual current size.

Case in point:

Actual DECtapes come standard in 2702 octal logical 128 word blocks [all software other than the DMS ignores the 129th word[.  But savvy users sort out "premium" DECtapes that are easily enough [works about 40% of the time if you don't chop off the tape!] you can get 3300 octal blocks. [Thus is a long-term average, as for quite a while it was more like 80%].  Some of my important data tapes have surfaced not only 3300 blocks long, but containing OS/8 files so long they cannot be put on the 2702 block tapes [yes, one file too long for the standard length; other tapes have so many files they also get into that ballpark.

And of course, you can have patched copies of PIP.SV with the table entries patched accordingly [but you CANNOT use the CCL form, you have to run say PIPDTB.SV and use the /Z option, etc.  And of course, RESORC is totally in the dark here on any of this.

The PEPS package version of SIMH allows both TD and DT tapes to be as long as 10000 octal blocks, which is 2048 OS/8 records.  [Compare that with the standard of 737 OS/8 records, so you can see this is quite a difference.  [Note:  It cannot go longer because the search routines are performed in 12-bit unsigned arithmetic or equivalent.  Some TD8E routines search in one-s complement unsigned 12-bit arithmetic]

This way, standard tapes, the existing "premium" length , and even "fantasy" lengths are supported.  All you need to do is change one line in two places in the source code which sets the tape length allowed in SIMH.  It's up to the O/S to tale advantage of it, and you can certainly get a copy of PIP to handle that fine [again, RESORC hasn't got a clue].

I take advantage of this in P?S/8 to allow it to basically support eight TC08 DECtapes.each of which is about 2/3 the size of the OS/8 1/2 of an RK pack, which means that OS/8 using even all four RK packs doesn't hold all that much more storage.  That way, I have SIMH configured to support either system which allows taking advantage of the best features of both.  [And there is a bi-directional file conversion program OS8CON so you can work in either system or in the host environment freely as the user sees fit, thus it can be the best of all THREE worlds.  And needless to say, the host can boot either system and either system can boot the other from the same SIMH session, etc.

While future P?S/8 systems will support the P?S/8 SHELL, which will operate the way you wish OS/8 had worked [but never will] I can also use one or more RK packs for P?S/9.  This is because SIMH supports booting to RK0, RK1, RK2 and RK3.  [OS/8's BOOT command supports this as well].  But for the present, it really isn't that important to have more than eight steroids-driven DECtapes and the four RK packs for both systems to use at present.  The future will tell a different story.  [Note:  As some of you know, I am almost ready to release this product performing an end-run around potential lawsuits from moribund shareware authors, etc so the package extensions [which have no equivalent on the PiDP-8] are accessible to the end user, etc.  Look for an upcoming announcement [AND DOCUMENTATION] on the pepswin group.  Note:  The extensions are useful to P?S/8 and OS/8 alike.]

I think Dave Gesswein is putting the two parameter settings into the master SIMH code base, so this will be available on the PiDP-8 as well.

cjl