• Please review our updated Terms and Rules here

OS/8 running on a PDP-8/L with 8KW memory and a non-standard mass storage device.

I had two DF32s long ago. I had plans to somehow keep the electronics as is and use them to then talk to an emulated actual drive. Never did get around to that though.
 
The RF08 is very close to the DF32 from a programing standpoint so making it work under SIMH should be straightforward.
In a sense. There seem to be differences in the way the drivers are documented, though. The DF32 is just S:, whereas the RF08 are S0: through S4. Dave's .zip file has a disassembly that claims to be for the RF08 driver. I haven't yet made the time to compare that with the driver in my working DF32 image.
 
The copy of RF08NS.PA that I have from the V3D sources has conditionals for building it as a DF32 or an RF08. If built as RF08 then it has an entry point for RF as a block device. It is the only DEC handler that also has a character device entry point called NULL which like the Unix /dev/nul entry accepts and discards anything fed to it on write and returns end of file on a read. The RF08SY.PA source has a single entry point for SYS and specifies the size as 1777 blocks. This is for OS/8, are you talking about something for DMS? I know almost nothing about DMS.
 
Do you have any operating DF32?
Not currently for actually using the platter. I'm using my DS32 emulator board so looks like I have 4 DS32 attached. Need to refresh the design and make another so I don't have to keep moving between my 8/I and straight 8. The one that I had running the head cable disintegrated and I haven't repaired. Also need to make timing track writer since I removed and cleaned the platter and didn't quite get it back on the same. It worked but not reliable. Not sure if that was much different than when it was new based on all the program people created for testing it. Will try getting it working sometime but not high priority.
The RF08 is very close to the DF32 from a programing standpoint so making it work under SIMH should be straightforward.
It is supported by SIMH. Just need to grab the right tapes and follow the install procedure.

Have thread hijacked. Should we start a new thread?
 
It is supported by SIMH. Just need to grab the right tapes and follow the install procedure.

Have thread hijacked. Should we start a new thread?
I have confirmed that the RF08 driver for DMS is a little different. I think it implements "units" which look like DF32.

Where are these tapes?

We could start a new thread, but I fear it would only get a few posts, with most of the DMS ground having been covered already.
 
Is their a functional RF08 around? I haven't seen one. Probably could make one under SIMH.
The Rhode Island Computer Museum has an RF08 in a donated system. It hasn't been powered up in a very long time, and I suspect that the platter is corroded to the heads. Making an FPGA emulator for the platter would be possible, but a bunch of work.

 
It's my thread. Happy for it to morph...

I am learning stuff as well in the process!

When I have a spare minute I will test your S: and S0: question. I should know the answer to that, but that brain cell must have died off recently...

Dave
 
>>> What isn't clear to me is whether you can get away with referencing S0: as S:.

I tried using PIP with just S: and it doesn't like it at all. S0: through S7: and it is a happy bunny.

So the answer is probably no, you can't get away with referencing S0: as S:.

Dave
 
I have just downloaded the latest SerialServer from GitHub (V1.6 of server.c) and I am having a problem compiling server.c using gcc on an iMac with OS/X.

I get the following errors (I have suppressed the warnings and notes):

Code:
server.c:382:1: error: function definition is not allowed here
{
^
server.c:516:5: error: implicit declaration of function 'HELPBoot' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
                                HELPBoot();
                                ^
2 errors generated.

It looks like the HELPBoot function is declared in the middle of the main code?

Thoughts?

EDIT: I have just moved the entire "HELPBoot" function to before "main" and the SerialServer compiles fine now (with the use of the -Wno-pointer-sign compiler option to get rid of the warning and note messages).

Dave
 
>>> What isn't clear to me is whether you can get away with referencing S0: as S:.

I tried using PIP with just S: and it doesn't like it at all. S0: through S7: and it is a happy bunny.

So the answer is probably no, you can't get away with referencing S0: as S:.

Dave
I have been developing "expect" scripts which spawn SIMH and install DMS on DF32, RF08, and DECtape. What I found is that the DF32 version of PIP doesn't seem to support unit numbers for device S, whereas the RF08 version seems to support (and require)!vi them. You can use DF32 PIP on the RF08, but then there's no way to refer to the extra storage. It would be cool if the DECtape driver implemented unit numbers and worked with the RF08 PIP. Unit numbers on the serial disk would also be awesome :).
 
Which version of OS/8 and PIP are you using?
Who/which thread were you replying to? I'm using SIMH, the DEC-D8-xxxx-PB paper tape images an the linux "expect" command to install DMS on the various simulated media. So no version of OS/8 is involved. I'm using the "AF" versions of system builder and PIP, which seem to match the manuals I'm using. (I do have an older manual, referencing "8D", but I'm ignoring that.)

You can see the scripts I'm working on here:

I actually have a couple of questions -- does it matter at all what I answer to the "CORE?" prompt? Or which version of DDT is used? What is the "patch" to PIP, do I need it, and how is that loaded?
 
Saw the latter part of your post. Thanks. At least then we can be looking at the same thing.

I was a bit too quick off the mark with looking at the [OS/8] source for PIP!

Of course, it is DMS and we have no source code - that is why I am busy disassembling and commenting PIP...

My original question was running OS/8 on the LD12, but that definitely involves hardware for the memory extension logic.

I then 'fell back' on using 4K DMS, as this only requires 4KW - so I don't need any additional logic at all (other than a second serial port).

What I did have to do was to write a serial driver for DMS, and a corresponding DMS SerialServer. I have done this based on the RF08 variant - and simulated the disk accordingly.

This was one reason that I couldn't use the 'standard' SerialServer - 1. it was for OS/8 and not DMS and 2. it didn't support RF08 disks - different disk geometry.

I am also sure there us a gotcha with PIP - hence the reason I was disassembling it in the first place.

I have been busy today, and will be busy tomorrow (we are replacing our projectors with 86" monitors at Church tomorrow - and I am in charge of the project)...

I will have a look at your questions during some "down time"...

Cheers,

Dave
 
I spent a little time today disassembling the TC08 driver. I got most of it figured out, except I still don't get how the tape motion ends up stopped at the end. (Seems like 0200 would seek to the forward end of the tape.)

The disassembled df32, rf08, and tc08 drivers are here:
(Thanks for the head start, daver2!)

I haven't looked at the new serial driver yet.
 
I got most of it figured out, except I still don't get how the tape motion ends up stopped at the end. (Seems like 0200 would seek to the forward end of the tape.)
Since it's only a DTXA rather than a DTCA DTXA, it will XOR the GO bit with 1, which was presumably set already, thus clearing it and only it. Without looking at it further, I'm not sure why they don't just clear all of register A if they want to stop it and return.
 
Back
Top