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

[djg]

And if second serial port isn't implemented yet their is a version that works on the console port
https://github.com/dustyoldcomputers/console-serial-disk

 

[396era]

Thanks for the insight daver2.

My Christmas list this year will be easy. I just hand everyone a copy of the BoM

This Mac simulation with all the hardware extensions looks fun:

PDP-8/E Simulator

 

[gnupublic]

This Mac simulation with all the hardware extensions looks fun:

Not only fun, this is a great thing!
The TC-08 works really great, even Poly-Basic works! But this took Bernhard some time to debug. The foto of the TC-08 is from my 8/e rack I got from Gerold Pauler.

 

[daver2]

The serial ports are not a problem. I have written my own serial server in Java that takes my developed code and automatically uses it in preference to the version stored on the disk/tape I am using. This permits me to do some PAL development work on my Mac and not have to bother about patching the disk as a separate step.

What are the constraints that will 'break' OS/8 running with 8KW?

Is it just the 'size' of the disk/tape device driver?

Is it also true that PIP contains it's own copy of the device drivers - designed for interrupt use?

I see there are data/code within various programs (e.g. PIP/RESORC) to handle different devices. Presumably, if I piggy-back my device driver off another one, and mimic the device geometry, all of this will be well. I have already done this with my existing device driver and it seems to work fine.

I am still trying to work out where all the 'gotchas' are though!

Just having a look through the V3D OS/8 sources. I see device tables embedded within RESORC, but nothing obvious jumping out at me within PIP.

Dave

 

[daver2]

Ok, so I have tracked the following text down in the OS/8 V3D System Reference Manual:


That looks conclusive that I should be able to run OS/8 on an 8KW machine. OK, it might be a limited system, but that comes with the territory...

I assume that I would write my own serial disk device driver that 'masquerades' as an existing disk device that supports the associated disk geometry. That avoids (presumably) having to modify PIP, RESORC, BUILD etc.

Are there any other gotchas I need to consider?

Dave

 

[vrs42]

Ok, so I have tracked the following text down in the OS/8 V3D System Reference Manual:

View attachment 1268310
That looks conclusive that I should be able to run OS/8 on an 8KW machine. OK, it might be a limited system, but that comes with the territory...

Os/8 will run fine in 8K. The only exception is when the system device driver cannot be made to fit in the last page of field 0 along with the other overhead that also needs to live there.

I assume that I would write my own serial disk device driver that 'masquerades' as an existing disk device that supports the associated disk geometry. That avoids (presumably) having to modify PIP, RESORC, BUILD etc.

Yes. Most commonly folks mimic the RK05 geometry, as that arrangement is simple, but the result is fairly roomy. The existing serial disk device drivers and their associated servers have trod this ground already. Problems with RESORC, etc. persist, but mostly don't prevent things from working, so much as make them look wrong.

Are there any other gotchas I need to consider?

RESORC in particular has many versions, newer ones are not even written in PAL. So far, no-one has managed to fix all the issues there. As a result, user drivers are often mislabeled in the output.

Issues with PIP mostly occur when initializing media. Techniques for patching it for device size are fairly well known and simple enough to be usable in practice.

BUILD is mostly fine, though you need the right version for your OS version, and it is a pain to keep it synchronized with the actual configuration. (Which is to say, it "Works as designed".)

A deep exploration of the existing Serial Disk implementations and their history will bring out the known issues and the coping strategies. Or you could take our word for it and just use one of them as they are, rather than re-invent that particular wheel .

I'm sure Doug will have some advice, if you insist on writing and debugging your own driver. In your situation, I'd just use his console serial disk, as it is a snap to set up and you need the console port to be hardware compatible (which is easy) anyway.

 

[daver2]

Hi Vince.

I have already written a serial driver myself - so no issues there.

My concern is looking at the bigger picture. I have made my serial driver look like an existing device, so I should not need to play with the other various programs (for disk geometry, device names etc.).

My current problem is where are all instances of the 'old' device driver squirreled away?

The obvious way of building a new disk is to start off with an existing (say) RK05 image and patch the beast.

The other way is to start off with the paper tape distribution and build a system from scratch.

To do the latter option, I load the RIM and BUILD loaders and then pull in the paper tape for BUILD into the machine and execute it at 200.

I then specify a SYS device etc. and (magically) OS/8 gets written to the desired system disk. However, this has to be the 'original' device driver that doesn't exist on my serial line disk machine.

Where are the disk driver(s) actually stored for BUILD to use? I can't see them within the BUILD source. Or are they somehow 'tagged onto' the end of the BUILD tape?

I am trying to make sense of the process of loading, building and bootstrapping OS/8 and where things are stored.

This is more of a 'knowledge capturing' request.

I am re-reading the OS/8 manuals - but there is only so much a brain can take in at any one time before leaking...

Dave

 

[vrs42]

My current problem is where are all instances of the 'old' device driver squirreled away?

OK. If your new device looks just like, say an RK05 driver, with the same names, entry points, and sizes, then things are fairly easy. The boot device will supply it's driver from block 0, which will be installed in the last page of field 0 as SYS:. Since it's permanently resident, things just work.

BUILD has commands to load and unload drivers from it's internal tables, activate them, etc. You'd need to locate the BUILD which is meant for your system (hopefully it's on the RK05 image you started from), unload the RK05 drivers, load and activate your new driver, configuring that as the new SYS:. This brings BUILD into line with your new configuration. When all that is just so, you can type $BOOT to BUILD and get the system fully squared away. Hopefully you remembered to RUN instead of R, because next you need to SAVE the new BUILD, with it's updated tables.

The obvious way of building a new disk is to start off with an existing (say) RK05 image and patch the beast.

The other way is to start off with the paper tape distribution and build a system from scratch.

That is a nightmare. You'll need to be a serious masochist to enjoy that.

Which reminds me -- SIMH is the bee's knees for this kind of work. Thats how the serial disk stuff in the repository that Kyle and I maintain is done. The huge advantage is that things are scripted, so when they don't work out, you just edit the script and try again, and it's a matter of seconds to be able to try again, not hours or evern days. When stuff works in simulation, you have some hope it will work on the real hardware too.

Where are the disk driver(s) actually stored for BUILD to use? I can't see them within the BUILD source. Or are they somehow 'tagged onto' the end of the BUILD tape?

ISTR something like that, but loading from paper tape is so slow and (for me at least) error prone, that I haven't even looked at that process in years.

I am re-reading the OS/8 manuals - but there is only so much a brain can take in at any one time before leaking...

I hear you there! I'm puzzling over the DMS manuals at the moment. Took me some minutes to understand how to even list the directory. Now I'm trying to understand how files and directories are stored, and ... yikes.

 

[daver2]

Yes, I a using SIMH at the moment - until I get my LD12 wired up...

I have already loaded the paper tape images into SIMH and created a virgin system disk by using a SIMH script file. It is a boring job - but I have the process documented now. This was using a 'real' RF08 disk interface (well, a virtual one in SIMH) rather than my own bespoke serial driver of course. I was just following the procedure through.

>>> That is a nightmare. You'll need to be a serious masochist to enjoy that.

I have done much worse things in the past and have overcome (much to my surprise)!

I can tell you about DMS...

Dave

 

[DougIngraham]

What are the constraints that will 'break' OS/8 running with 8KW?

Two page system handlers is the only thing I know of. In the case of a 2 page SYS handler the first page is found from 07607 to 07743 and the second page is loaded between 27600 through 27777. The TD8E handler and the third party byte version of the RX0X handler are the only ones I can think of off the top of my head. I strongly suggest avoiding a 2 page system handler. The implementation was a kludge from the start.

Is it just the 'size' of the disk/tape device driver?

Yes.

Is it also true that PIP contains it's own copy of the device drivers - designed for interrupt use?

No. PIP uses handlers in the regular way. What it does have is special knowledge of the size of devices. This is so when you tell it to format a device it knows when to stop. It has to know this for things like the RK05 and RL01 where there are multiple partitions stored on a device. For example, if you write off the end of RK0A you will start overwriting the beginning of RK0B and blow the directory. In theory the handlers will not let this happen but almost none of them enforce this because there is no code room to do the test.

I see there are data/code within various programs (e.g. PIP/RESORC) to handle different devices. Presumably, if I piggy-back my device driver off another one, and mimic the device geometry, all of this will be well. I have already done this with my existing device driver and it seems to work fine.

For the most part this works. PIP needs to be patched for User defined handler sizes which does not apply here. RESORC knows about DEC devices so it works for them but not for user defined devices. BOOT may also have some device specific information. I have not looked closely at it.

I am still trying to work out where all the 'gotchas' are though!

One that surprised me was the way BOOT copies the system info from the old system device to the new one. It performs a read using SYS. Then it saves the last page of field 0 somewhere and loads the new SYS into the last page of field 0 and does the write. It then puts back the saves the last page and puts the original back. I think of these are Read SYS and Write SYS. Because in Console Serial Disk the Read SYS and the Write SYS were the same where one of them was pretending to be an RK05 and the other the Virtual CSD 4095 block image it didn't work. The entry point address is passed to the server and that is what is used to determine the virtual device. In the case of BOOT both of the entry points were 07605 so both were the emulated RK05 image. So it copied the system blocks over the top of itself. It didn't hurt anything but it didn't work to create a bootable image either.

Just having a look through the V3D OS/8 sources. I see device tables embedded within RESORC, but nothing obvious jumping out at me within PIP.

I think the only thing in PIP is that it assumes the device size by using the entry point address to figure out the size of the device for non system devices. This is why you have to patch the size for non DEC devices. I need to do more research for my book on this topic.

RESORC is one of those cases where the program itself is informational only and not needed in a correctly operating system. But it would sure be nice if it worked the way you expect it to when developing handlers. The problem is that BOOT knows some stuff but this stuff is not saved anywhere when it does its thing. So RESORC has to make assumptions. Basically DEC would have to update RESORC when a new device was supported. If the device size was part of a system table it would have solved some issues.

If you haven't looked at it here is a link to my book.

OS/8 handler info

There may be something there that could assist you. Please let me know if you find any mistakes.

 

[DougIngraham]

Ok, so I have tracked the following text down in the OS/8 V3D System Reference Manual:

View attachment 1268310
That looks conclusive that I should be able to run OS/8 on an 8KW machine. OK, it might be a limited system, but that comes with the territory...

I assume that I would write my own serial disk device driver that 'masquerades' as an existing disk device that supports the associated disk geometry. That avoids (presumably) having to modify PIP, RESORC, BUILD etc.

Are there any other gotchas I need to consider?

What they don't say here is that you can't boot from the TD8E with only 8k. But if you have the RK05 why would you want to?

The only gotcha is that your system boot device must be a one page handler in order to work in 8k. That means it can be no longer than 93 words.

 

[djg]

I hear you there! I'm puzzling over the DMS manuals at the moment. Took me some minutes to understand how to even list the directory. Now I'm trying to understand how files and directories are stored, and ... yikes.

I use DMS with my straight 8 so some experience if you get stuck. I have code to extract stuff from DMS images to generate my web pages I can send if useful to you. Did send them to someone. Was that you?
http://www.pdp8online.com/pdp8cgi/d...es/dms/monitor_system_maindecs.tu56;sort=name

 

[DougIngraham]

I suppose I need to mention the other gotcha. Which is leaving the ready flag set. If you leave the ready flag set and you are running a program that uses the Fortran Run Time System an interrupt will occur and the FRTS will hang. If it is a device it knows about it will clear it but on a non standard device not so much. The FRTS turns off interrupts when it makes a call to a handler. You can either turn off the ability of the ready flag to cause an interrupt on an omnibus machine or on the older machines you will need to code such that the flag is not left enabled. There is a chapter on this topic in my book. I think this is what we did for the last version of Serial Disk. I think this was Vince's idea and was one of those why didn't I think of that moments for me.

 

[daver2]

Thank you Vince and Doug for your help.

Now I have found the right section in the right manual it is starting to make sense!

The DEC supplied file stream handlers are within here:



So, by writing a new handler (in the appropriate format), and crossing my fingers, toes and everything else (!) I should be able to load BUILD from paper tape and then load my new device handler from paper tape and promptly watch it crash and burn for the first ten or so times until I start to understand what I should be really doing...

Thanks for the other 'gotchas' Doug - that will save some further head scratching.

My brain is fried now - so I am going to do something mundane for the rest of the evening now!

Dave

 

[vrs42]

I use DMS with my straight 8 so some experience if you get stuck. I have code to extract stuff from DMS images to generate my web pages I can send if useful to you. Did send them to someone. Was that you?
http://www.pdp8online.com/pdp8cgi/d...es/dms/monitor_system_maindecs.tu56;sort=name

Yes, you did send the stuff to me a while back. I'm gradually reminding myself of things I guess I used to know, but this time starting from the context of actually using DMS.

Thanks for the refresh on the DECtape image link. I had a DF32 image I've been playing with, and it will be nice to throw the DECtape image into the mix. The DF32 is weird because it still uses 129 word blocks, and moreover it skews them all by a word, so that a block boundary will line up with the DF32's protection boundary.

Are there also RF08 images around? It looks like every media typpe moves the directory and SAM blocks around. The RF08 also apparently has partitions, whereas the DF32 doesn't.

 

[DougIngraham]

Thanks for the other 'gotchas' Doug - that will save some further head scratching.

You are welcome.

The fact that someone else is venturing into writing OS/8 handlers is exciting.

I wrote my book for myself but with the idea that others would need that information as well. I originally thought that maybe 10 people world wide would be interested but I was secretly hoping it might be as many as 100. Now I am afraid I was optimistic thinking 10.

Vince has most of the handler sources on his site if you need more examples to look at. I need to get more example code in the book. I don't like showing code that has not been tested which is why some of the examples are not in there. I have to fix my machines to test stuff.

I have a collection of handler sources but it is not online. If there is something you want to look at let me know. Also I would be interested in looking at your handler when you get it to a place you are comfortable letting others look at it.

Also, to save your fingers I suggest you look at the most recent version of Serial Disk and the way we took advantage of the help boot loader. It is only 9 instructions that you have to toggle in. The CSD loader is only 8 but it depends on the code coming in on the console port and that makes a big difference.

 

[daver2]

I have written a device driver for DMS - so this is my first foray into OS/8.

I have managed to make sense of ak-4660c-ba. 90% will have evaporated by tomorrow though.

I will go and have a read of your book now. The works laptop doesn't like it!

Dave

 

[daver2]

If you get really bored, I have uploaded the work on my DMS serial driver if you fancy a laugh.

I won't provide you with the Java server - the code is absolutely awful!

bootloader.pal is (as the name says) my toggled-in boot loader. It is quite long (so there are many opportunities for optimisation) but I was working on a DEC help loader encoded variant.

DERDMS.pal is the actual DMS serial driver.

derdmspdp8.ini is the SIMH INI file I am using for testing.

dmsdump.cpp is a very, very crude directory dumper utility. It should work with disk and tape images (when configured appropriately). This requires some further work!

RF08 DMS 7600 disassembly.txt is my disassembly of the RF08 DMS bootstrap.

I think that is a description of the five files in there.

Dave

 

[djg]

Are there also RF08 images around? It looks like every media typpe moves the directory and SAM blocks around. The RF08 also apparently has partitions, whereas the DF32 doesn't.

Is their a functional RF08 around? I haven't seen one. Probably could make one under SIMH.

 

[DougIngraham]

Is their a functional RF08 around? I haven't seen one. Probably could make one under SIMH.

I've not seen one either. The only one I remember seeing is the one at the Computer Museum of America. I probably walked by one in the basement of the Living Computer Museum but you would never know without opening the cabinet. I would guess it would have the same issues as the DF32 with the corrosion on the platters. Do you have any operating DF32? I don't plan to even try to get my 2 platters running.

The RF08 is very close to the DF32 from a programing standpoint so making it work under SIMH should be straightforward.