info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
BIN loader disassembly from EDUSYSTEM 20 paper tape
163 views
Skip to first unread message
Martin Eberhard
Mar 15, 2020, 3:54:22 PM3/15/20
to
If anyone's interested, I just disassembled the BIN loader that's in RIM format at the beginning of the EDUSYSTEM 20 paper tape.
This loader is kind of interesting. When the RIM loader loads this BIN loader, the RIM loader gets modified to jump to this BIN loader when the RIM load is done. Then this BIN loader repairs the RIM loader, undoing this modification.
It then pulls the KSF and KRB instructions from the RIM loader and pastes them into its own code, so that the BIN loader loads from the same device as the RIM loader did - whether its the console TTY, a high-speed paper tape reader, or even another serial port at a different address. This is kind of cool - in my case, I've modified my RIM loader to load from a 9600 baud serial port, with KRB at 6306 (distinct from the console TTY at 6036). Even with this modified RIM loader, EDUSYSTEM 20 loads and runs perfectly on my PDP-8e.
There is a strange bit of code at the beginning of this BIN loader that looks like it is intended to copy itself into another memory field and then jump there. But as found, it copies from field 0 to field 0, so it doesn't actually do anything useful. I suspect this BIN loader was used for other DEC applications, where the the field in which it is loaded by the RIM loader is different than where it wants to run.
Anyway, if you are interested, you can find my disassembly here. I've tried to be pretty verbose, explaining how it works in the comments:
https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/30%20DEC%20Software/Edusystem/Edusystem%2020/
Naturally, reassembling this disassembly produces the exact same code as found on the EDUSYSTEM paper tape - at least when using PALBART (but I think also with PAL III).
-Martin E.
This loader is kind of interesting. When the RIM loader loads this BIN loader, the RIM loader gets modified to jump to this BIN loader when the RIM load is done. Then this BIN loader repairs the RIM loader, undoing this modification.
It then pulls the KSF and KRB instructions from the RIM loader and pastes them into its own code, so that the BIN loader loads from the same device as the RIM loader did - whether its the console TTY, a high-speed paper tape reader, or even another serial port at a different address. This is kind of cool - in my case, I've modified my RIM loader to load from a 9600 baud serial port, with KRB at 6306 (distinct from the console TTY at 6036). Even with this modified RIM loader, EDUSYSTEM 20 loads and runs perfectly on my PDP-8e.
There is a strange bit of code at the beginning of this BIN loader that looks like it is intended to copy itself into another memory field and then jump there. But as found, it copies from field 0 to field 0, so it doesn't actually do anything useful. I suspect this BIN loader was used for other DEC applications, where the the field in which it is loaded by the RIM loader is different than where it wants to run.
Anyway, if you are interested, you can find my disassembly here. I've tried to be pretty verbose, explaining how it works in the comments:
https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/30%20DEC%20Software/Edusystem/Edusystem%2020/
Naturally, reassembling this disassembly produces the exact same code as found on the EDUSYSTEM paper tape - at least when using PALBART (but I think also with PAL III).
-Martin E.
Scott Lurndal
Mar 16, 2020, 2:44:41 PM3/16/20
to
Martin Eberhard <mfebe...@gmail.com> writes:
>If anyone's interested, I just disassembled the BIN loader that's in RIM fo=
>rmat at the beginning of the EDUSYSTEM 20 paper tape.=20
>
>This loader is kind of interesting. When the RIM loader loads this BIN load=
>er, the RIM loader gets modified to jump to this BIN loader when the RIM lo=
>ad is done. Then this BIN loader repairs the RIM loader, undoing this modif=
>ication.=20
>
>It then pulls the KSF and KRB instructions from the RIM loader and pastes t=
>hem into its own code, so that the BIN loader loads from the same device as=
> the RIM loader did - whether its the console TTY, a high-speed paper tape =
>reader, or even another serial port at a different address. This is kind of=
> cool - in my case, I've modified my RIM loader to load from a 9600 baud se=
>rial port, with KRB at 6306 (distinct from the console TTY at 6036). Even w=
>ith this modified RIM loader, EDUSYSTEM 20 loads and runs perfectly on my P=
>DP-8e.
>
>There is a strange bit of code at the beginning of this BIN loader that loo=
>ks like it is intended to copy itself into another memory field and then ju=
>mp there. But as found, it copies from field 0 to field 0, so it doesn't ac=
>tually do anything useful. I suspect this BIN loader was used for other DEC=
> applications, where the the field in which it is loaded by the RIM loader =
>ion/30%20DEC%20Software/Edusystem/Edusystem%2020/
>
404 Not Found.
>If anyone's interested, I just disassembled the BIN loader that's in RIM fo=
>rmat at the beginning of the EDUSYSTEM 20 paper tape.=20
>
>This loader is kind of interesting. When the RIM loader loads this BIN load=
>er, the RIM loader gets modified to jump to this BIN loader when the RIM lo=
>ad is done. Then this BIN loader repairs the RIM loader, undoing this modif=
>ication.=20
>
>It then pulls the KSF and KRB instructions from the RIM loader and pastes t=
>hem into its own code, so that the BIN loader loads from the same device as=
> the RIM loader did - whether its the console TTY, a high-speed paper tape =
>reader, or even another serial port at a different address. This is kind of=
> cool - in my case, I've modified my RIM loader to load from a 9600 baud se=
>rial port, with KRB at 6306 (distinct from the console TTY at 6036). Even w=
>ith this modified RIM loader, EDUSYSTEM 20 loads and runs perfectly on my P=
>DP-8e.
>
>There is a strange bit of code at the beginning of this BIN loader that loo=
>ks like it is intended to copy itself into another memory field and then ju=
>mp there. But as found, it copies from field 0 to field 0, so it doesn't ac=
>tually do anything useful. I suspect this BIN loader was used for other DEC=
> applications, where the the field in which it is loaded by the RIM loader =
>is different than where it wants to run.
>
>Anyway, if you are interested, you can find my disassembly here. I've tried=
>
> to be pretty verbose, explaining how it works in the comments:
>
>https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporat=
>
>ion/30%20DEC%20Software/Edusystem/Edusystem%2020/
>
404 Not Found.
steve...@gmail.com
Mar 16, 2020, 2:53:42 PM3/16/20
to
Martin,
Which version of Edusystem 20 do you have? I have version C and the self-starting BIN loader in this version does not auto-repair RIM loader. One needs to repair RIM loader by hand: reset 07774 to 3376.
And, for what it's worth, I have mostly reconstructed the .PA source code for EduSystem 20 Version C basic. I have an original printed paper source code listing from the 1970s. My listing is missing a couple of pages but I was able to mostly reconstruct the missing parts from the binary paper tape and the symbol table & CREF in the listing. I am happy to share Edu20C.PA if anyone wants it.
For what it's worth, I ended up just rewriting my own self-starting BIN loader instead of reconstructing one from dis-assembling the one on the Edu20C paper tape. I did dis-assemble it, but thought the code was more complex than it really needed to be.
Cheers,
-- steve
Which version of Edusystem 20 do you have? I have version C and the self-starting BIN loader in this version does not auto-repair RIM loader. One needs to repair RIM loader by hand: reset 07774 to 3376.
And, for what it's worth, I have mostly reconstructed the .PA source code for EduSystem 20 Version C basic. I have an original printed paper source code listing from the 1970s. My listing is missing a couple of pages but I was able to mostly reconstruct the missing parts from the binary paper tape and the symbol table & CREF in the listing. I am happy to share Edu20C.PA if anyone wants it.
For what it's worth, I ended up just rewriting my own self-starting BIN loader instead of reconstructing one from dis-assembling the one on the Edu20C paper tape. I did dis-assemble it, but thought the code was more complex than it really needed to be.
Cheers,
-- steve
Martin Eberhard
Mar 16, 2020, 5:19:59 PM3/16/20
to
Hi Steve,
I'm actually not sure what version of Edusystem 20 I have. I ripped a tape image I found "somewhere" on the web. That tape image is in the same directory as my disassembly (from my prior message). When I run Edusystem, it does not identify which version it is. Any suggestion how I can find out? Just because its BIN loader repairs the RIM loader, I'm guessing it might be newer than yours.
I agree about the extra complexity of the loader. As I mentioned, the one I disassembled has a section for copying itself into a different field - but the way it's set up it doesn't actually do anything. But this doesn't add too many instructions :-)
I'd love to have a copy of your reconstructed source code. If you like, I'll post it in my archive on Mike Douglas's DERAMP.COM site.
Martin
I'm actually not sure what version of Edusystem 20 I have. I ripped a tape image I found "somewhere" on the web. That tape image is in the same directory as my disassembly (from my prior message). When I run Edusystem, it does not identify which version it is. Any suggestion how I can find out? Just because its BIN loader repairs the RIM loader, I'm guessing it might be newer than yours.
I agree about the extra complexity of the loader. As I mentioned, the one I disassembled has a section for copying itself into a different field - but the way it's set up it doesn't actually do anything. But this doesn't add too many instructions :-)
I'd love to have a copy of your reconstructed source code. If you like, I'll post it in my archive on Mike Douglas's DERAMP.COM site.
Martin
Martin Eberhard
Mar 16, 2020, 5:32:02 PM3/16/20
to
Martin Eberhard
Mar 16, 2020, 5:39:48 PM3/16/20
to
> Yes, it looks like this editor busts the URL in pieces. I will try to make a shorter link that fits on one line. Otherwise, you can put the two pieces of the URL together on your browser...
Okay, I've created a "tiny URL" for this directory:
https://tinyurl.com/wcmxhjo
This should work for you.
steve...@gmail.com
Mar 16, 2020, 8:18:43 PM3/16/20
to
Hi Martin,
"When I run Edusystem, it does not identify which version it is. Any suggestion how I can find out?"
I don't know of any easy way to find out. I only know which version I have because of the label on the original DEC paper tape says Version C and the paper source code listing that came with it also matches the part number ("DEC-08-EDU20A-C-LA"). I don't know of any version information that would survive into the binary paper tape. But yes, the self-repair on the binary loader does suggest you have a later version--at minimum of the binary loader. DEC may have merely grafted a revised self-starting BIN loader onto the same Edu20C. A bit more on this below.
"I'd love to have a copy of your reconstructed source code. If you like, I'll post it in my archive on Mike Douglas's DERAMP.COM site."
I wanted to attach the files to this message but since I haven't officially joined this group yet I am not able to add attachments. I will join and when that's done I will share them here. Otherwise I can put them out on DropBox. Feel free to share them with anyone, such as Mike Douglas' site. Hobbyists have been given legal copyright permission to all DEC software in all its various forms.
I can also share my version of the self-starting BIN Loader, in case anyone might be interested. I also ended up making a utility program called BINCMP that lets you compare BIN format tapes. You load one tape into memory using BIN Loader, then BINCMP reads the other from the tape reader and tells you whenever what's on the second tape doesn't match what got loaded into memory from the first tape. One thing that would be interesting to do would be to compare the BIN formatted section of your Edu20 tape with the EDU20C.BN that I have. Then we can see how well they do or don't match.
For what it's worth, I now do all of my PDP-8 work on one of Oscar Vermuellen's PiDP-8/I kits (https://obsolescence.wixsite.com/obsolescence/pidp-8). I have a real PDP-8/e but haven't turned it on in years. It came with quite a collection of paper tapes, including an Edu20C Basic program that translates typed-in text into human readable text on physical paper tape just like your PUNTXT program. It was written by one of my classmates. I ordered an OP-80A paper tape reader that I will connect up to a spare Raspberry Pi so I can read all of my physical paper tapes. Then I will be able to share even more PDP-8 code.
Cheers,
-- steve
"When I run Edusystem, it does not identify which version it is. Any suggestion how I can find out?"
"I'd love to have a copy of your reconstructed source code. If you like, I'll post it in my archive on Mike Douglas's DERAMP.COM site."
I can also share my version of the self-starting BIN Loader, in case anyone might be interested. I also ended up making a utility program called BINCMP that lets you compare BIN format tapes. You load one tape into memory using BIN Loader, then BINCMP reads the other from the tape reader and tells you whenever what's on the second tape doesn't match what got loaded into memory from the first tape. One thing that would be interesting to do would be to compare the BIN formatted section of your Edu20 tape with the EDU20C.BN that I have. Then we can see how well they do or don't match.
For what it's worth, I now do all of my PDP-8 work on one of Oscar Vermuellen's PiDP-8/I kits (https://obsolescence.wixsite.com/obsolescence/pidp-8). I have a real PDP-8/e but haven't turned it on in years. It came with quite a collection of paper tapes, including an Edu20C Basic program that translates typed-in text into human readable text on physical paper tape just like your PUNTXT program. It was written by one of my classmates. I ordered an OP-80A paper tape reader that I will connect up to a spare Raspberry Pi so I can read all of my physical paper tapes. Then I will be able to share even more PDP-8 code.
Cheers,
-- steve
Steve Tockey
Mar 16, 2020, 11:55:02 PM3/16/20
to
All,
Looks like it is not possible to attach files in this group. Oh well. Instead, I put things out in DropBox. You should be able to find things here:
https://www.dropbox.com/sh/p8n7kund4utqy4q/AAB4-6cLuPOyKk-M685w24dna?dl=0
Cheers,
-- steve
Looks like it is not possible to attach files in this group. Oh well. Instead, I put things out in DropBox. You should be able to find things here:
https://www.dropbox.com/sh/p8n7kund4utqy4q/AAB4-6cLuPOyKk-M685w24dna?dl=0
Cheers,
-- steve
Martin Eberhard
Mar 17, 2020, 11:22:28 AM3/17/20
to
Thanks Steve!
Nice code. I've posted those in my archive at DERAMP.COM.
With a small tweak, your BIN loader could do what DEC's does - steal the actual paper tape reader instructions from the RIM loader. This has the advantage of also working when the RIM loader is reading from a second serial port (instead of the console or a high-speed reader). This configuration was probably uncommon back in the day, but now that we are loading via files on our Macbooks/PC's, it's much more likely.
Martin
Nice code. I've posted those in my archive at DERAMP.COM.
With a small tweak, your BIN loader could do what DEC's does - steal the actual paper tape reader instructions from the RIM loader. This has the advantage of also working when the RIM loader is reading from a second serial port (instead of the console or a high-speed reader). This configuration was probably uncommon back in the day, but now that we are loading via files on our Macbooks/PC's, it's much more likely.
Martin
Steve Tockey
Mar 17, 2020, 3:05:35 PM3/17/20
to
Martin,
Thanks. We all have our own unique theories about how good code should look, that's an example of my theory when applied to assembler-level code. BINCMP.PA is another example.
I looked at DERAMP.COM but couldn't see anything other than 8-bit stuff. Where is the link to your archive? I couldn't find it.
"With a small tweak, your BIN loader could do what DEC's does - steal the actual paper tape reader instructions from the RIM loader."
That's true, I was just following what the original BIN loader did. Which is also what the original self-starting BIN Loader on Edu20 vC did. It would be an easy change to do that, should someone want. As well, someone may also want to automatically patch address 07774 with 3376 like yours does. I will assume that someone smart enough to set up different device codes for alternate serial I/O could also modify this relatively straightforward code in relatively straightforward ways.
Or, they could just use your version because it already does these two useful things.
"This configuration was probably uncommon back in the day, but now that we are loading via files on our Macbooks/PC's, it's much more likely."
Yes, from what I remember of back then. It was a long, long time ago.
By the way, do you have a real PDP-8 of some flavor? Or, are you running SIMH or some other -8 emulator? Just curious.
-- steve
Thanks. We all have our own unique theories about how good code should look, that's an example of my theory when applied to assembler-level code. BINCMP.PA is another example.
I looked at DERAMP.COM but couldn't see anything other than 8-bit stuff. Where is the link to your archive? I couldn't find it.
"With a small tweak, your BIN loader could do what DEC's does - steal the actual paper tape reader instructions from the RIM loader."
Or, they could just use your version because it already does these two useful things.
"This configuration was probably uncommon back in the day, but now that we are loading via files on our Macbooks/PC's, it's much more likely."
By the way, do you have a real PDP-8 of some flavor? Or, are you running SIMH or some other -8 emulator? Just curious.
-- steve
Martin Eberhard
Mar 17, 2020, 3:30:23 PM3/17/20
to
Hi Steve,
All my DEC stuff is within this directory:
https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/
The loaders are further down, under 30 DEC PDP-8 Family Software, and then under 02 Loaders Punches Dumps.
I've been scanning documents and taking photos, as well as scraping everything I can find from around the web. (Other people's sites have a nasty way of going away just when I want a document!)
There's a lot of material in my DEC subsection, and I've tried to keep it organized. But I'm the first to say it's not perfect!
I'm running on a PDP-8e with 24K of core, a TD8-E with a TU56 tape drive, and a few other boards It's not yet all working perfectly, but I'm getting there.
All my DEC stuff is within this directory:
https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/
The loaders are further down, under 30 DEC PDP-8 Family Software, and then under 02 Loaders Punches Dumps.
I've been scanning documents and taking photos, as well as scraping everything I can find from around the web. (Other people's sites have a nasty way of going away just when I want a document!)
There's a lot of material in my DEC subsection, and I've tried to keep it organized. But I'm the first to say it's not perfect!
I'm running on a PDP-8e with 24K of core, a TD8-E with a TU56 tape drive, and a few other boards It's not yet all working perfectly, but I'm getting there.
William Cattey
Mar 17, 2020, 3:55:04 PM3/17/20
to
Nice archive, Martin!
Steve Tockey
Mar 17, 2020, 5:27:48 PM3/17/20
to
Martin,
I will second William Cattey's comment on it being a nice archive. Looks like you have a lot of good stuff. It looks like I may also have some stuff that you don't have, like the 1967 edition of the Small Computer Handbook for the original PDP-8 (aka "straight 8", the one with no letter). There is also an -8/I and -8/L handbook, I think from 1968 or 1969. Anyway, we might want to find a way to merge our respective collections.
By the way, the "mfe" name is what made it hard for me to find. That doesn't--to me, anyway--hint that I can find DEC stuff buried inside. I wonder if a more descriptive name would be helpful?
My -8/e also has 24K. I think 8K of it is magnetic core, the remainder is semiconductor. And I have an RX02 dual floppy drive but it stopped working a while ago. I also have an ADM-3/A video terminal and a high-speed optical paper tape reader. I had an Okidata dot matrix printer running at one point (even wrote an OS/8 device driver for it). But again, age takes a toll on hardware just as it does on people.
If you have TD8-E / TU56, are you running OS/8? If so, if you change your second serial board to device codes 01/02 then you can access it as PTR: and PTP: from OS/8 without having to write a separate device handler for it. Anyway, I also recently re-constructed the PT8-E high speed paper tape reader/punch device handler for OS/8. I could only find the .BN file on the web, not the .PA file. It would be easy to modify that to use your second serial line device codes and still make OS/8 think it is PTR: and PTP:.
I will second William Cattey's comment on it being a nice archive. Looks like you have a lot of good stuff. It looks like I may also have some stuff that you don't have, like the 1967 edition of the Small Computer Handbook for the original PDP-8 (aka "straight 8", the one with no letter). There is also an -8/I and -8/L handbook, I think from 1968 or 1969. Anyway, we might want to find a way to merge our respective collections.
By the way, the "mfe" name is what made it hard for me to find. That doesn't--to me, anyway--hint that I can find DEC stuff buried inside. I wonder if a more descriptive name would be helpful?
My -8/e also has 24K. I think 8K of it is magnetic core, the remainder is semiconductor. And I have an RX02 dual floppy drive but it stopped working a while ago. I also have an ADM-3/A video terminal and a high-speed optical paper tape reader. I had an Okidata dot matrix printer running at one point (even wrote an OS/8 device driver for it). But again, age takes a toll on hardware just as it does on people.
If you have TD8-E / TU56, are you running OS/8? If so, if you change your second serial board to device codes 01/02 then you can access it as PTR: and PTP: from OS/8 without having to write a separate device handler for it. Anyway, I also recently re-constructed the PT8-E high speed paper tape reader/punch device handler for OS/8. I could only find the .BN file on the web, not the .PA file. It would be easy to modify that to use your second serial line device codes and still make OS/8 think it is PTR: and PTP:.
Martin Eberhard
Mar 17, 2020, 6:23:25 PM3/17/20
to
Thanks.
I'm actually just borrowing a little corner of Mike Douglas's website - mfe are just my initials, and everything below that is my archive. Sorry it's a bit obscure, but it saved me from having to build and support a website :-)
Send me all the docs you have - I'll add to my archive - thanks!
I've got another 8K of core that I plan to install "when I get around to it." My console is an ASR33 - 10 years ago, I found one new in box - 0 hours on its hour meter. It took a while to get it running, as all its lubricants had solidified, and the rubber print hammer had turned to goo. But it's the right way to talk to an 8e!
I have a high-speed reader/punch that I want to restore. It's the PDP-11 version though, so I might trade it if I can find one that's set up for an 8e. (I do have the correct omnibus board.) (That's partly why I want to keep this 2nd serial port at the normal 2nd serial port address...)
I also have a filthy dirty RX01 dual floppy drive that will one day go on this computer.
Now that I am quarantined at home for the next few weeks, I might actually get to some of these projects.
I'm actually just borrowing a little corner of Mike Douglas's website - mfe are just my initials, and everything below that is my archive. Sorry it's a bit obscure, but it saved me from having to build and support a website :-)
Send me all the docs you have - I'll add to my archive - thanks!
I've got another 8K of core that I plan to install "when I get around to it." My console is an ASR33 - 10 years ago, I found one new in box - 0 hours on its hour meter. It took a while to get it running, as all its lubricants had solidified, and the rubber print hammer had turned to goo. But it's the right way to talk to an 8e!
I have a high-speed reader/punch that I want to restore. It's the PDP-11 version though, so I might trade it if I can find one that's set up for an 8e. (I do have the correct omnibus board.) (That's partly why I want to keep this 2nd serial port at the normal 2nd serial port address...)
I also have a filthy dirty RX01 dual floppy drive that will one day go on this computer.
Now that I am quarantined at home for the next few weeks, I might actually get to some of these projects.
Steve Tockey
Mar 17, 2020, 11:03:22 PM3/17/20
to
Martin,
I ran your copy of Edu20 Basic on my PiDP-8/i. It is definitely a different version. Looks like your copy matches Edu20 as described in Chapter 5 of the EduSystem Handbook. Edu20C is a later version that does everything in Chapter 5 but also includes the string manipulation functions in Edu25 (Chapter 6). Specifically, Edu20C supports LEN(A$), CAT(A$,B$), MID(A$,S,L) (see pages 6-12 and 6-13). Edu20C Basic also supports the command LINPUT (see page 6-10).
I ran your copy of Edu20 Basic on my PiDP-8/i. It is definitely a different version. Looks like your copy matches Edu20 as described in Chapter 5 of the EduSystem Handbook. Edu20C is a later version that does everything in Chapter 5 but also includes the string manipulation functions in Edu25 (Chapter 6). Specifically, Edu20C supports LEN(A$), CAT(A$,B$), MID(A$,S,L) (see pages 6-12 and 6-13). Edu20C Basic also supports the command LINPUT (see page 6-10).
Steve Tockey
Mar 17, 2020, 11:15:43 PM3/17/20
to
"mfe are just my initials"
Yes, I did figure that out eventually :^)
"My console is an ASR33 - 10 years ago, I found one new in box - 0 hours on its hour meter"
Wow, is that striking the Mother Lode or what? Amazing luck.
"But it's the right way to talk to an 8e!"
Too noisy and too slow. ADM-3A at a minimum, for my tastes.
"I have a high-speed reader/punch that I want to restore. It's the PDP-11 version though, so I might trade it if I can find one that's set up for an 8e. (I do have the correct omnibus board.)"
Is there really a difference in the reader-punch hardware itself between the PDP-8 and PDP-11? Normally there isn't. At most, all you should need are the cables that go between the reader-punch and the PC8E Omnibus card. You do have the PC8E documentation in your collection, including the maintenance manuals. They should tell you what the cabling is supposed to look like.
"Now that I am quarantined at home for the next few weeks, I might actually get to some of these projects."
I'm essentially quarantined here (Seattle) too but I have to be in work-from-home mode. Retro-computing after hours only, unfortunately.
Be safe and healthy.
Yes, I did figure that out eventually :^)
"My console is an ASR33 - 10 years ago, I found one new in box - 0 hours on its hour meter"
"But it's the right way to talk to an 8e!"
"I have a high-speed reader/punch that I want to restore. It's the PDP-11 version though, so I might trade it if I can find one that's set up for an 8e. (I do have the correct omnibus board.)"
"Now that I am quarantined at home for the next few weeks, I might actually get to some of these projects."
Be safe and healthy.
Martin Eberhard
Mar 18, 2020, 11:29:28 AM3/18/20
to
Hi Steve,
Thanks for figuring out the edusystem 20 versions! I wonder why they changed from that self-starting BIN loader on the older version. It seems clearly superior to the BIN loader on the version C tape.
Regarding the high-speed reader/punch: The PC04 and PC05 are based on the same hardware, but are different. The PC04 is meant for the PDP8e, while the PC05 is meant for the PDP11. The actual punch is different - different boards in the card cage, etc. Check it out here (sorry for the long URL... you'll probably have to repair it.):
https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/20%20Paper%20Tape%20Subsystems/PC04%20PC05%20Paper%20Tape/DEC-00-PC0A-D_PC04_Manual.pdf
I haven't dug into what exactly is different. I bought my Omnibus controller together with this reader/punch. Obviously the board is for an 8e, but the reader/punch is a PC05...
If anyone can explain the differences, and save me digging through the documentation, I'd love the help. How easy is it to reconfigure a PC05 to behave like a PC04?
Martin E.
Thanks for figuring out the edusystem 20 versions! I wonder why they changed from that self-starting BIN loader on the older version. It seems clearly superior to the BIN loader on the version C tape.
Regarding the high-speed reader/punch: The PC04 and PC05 are based on the same hardware, but are different. The PC04 is meant for the PDP8e, while the PC05 is meant for the PDP11. The actual punch is different - different boards in the card cage, etc. Check it out here (sorry for the long URL... you'll probably have to repair it.):
https://deramp.com/downloads/mfe_archive/011-Digital%20Equipment%20Corporation/20%20Paper%20Tape%20Subsystems/PC04%20PC05%20Paper%20Tape/DEC-00-PC0A-D_PC04_Manual.pdf
I haven't dug into what exactly is different. I bought my Omnibus controller together with this reader/punch. Obviously the board is for an 8e, but the reader/punch is a PC05...
If anyone can explain the differences, and save me digging through the documentation, I'd love the help. How easy is it to reconfigure a PC05 to behave like a PC04?
Martin E.
Steve Tockey
Mar 18, 2020, 8:21:01 PM3/18/20
to
"> I haven't dug into what exactly is different. I bought my Omnibus controller together with this reader/punch. Obviously the board is for an 8e, but the reader/punch is a PC05..."
What is the Omnibus board identifying number? M8xx?
The key difference between PC04 and PC05 seems to be on the bottom of page 1-1 of the manual you referenced, "The PC05 contains its own power supply and control drive circuitry, while the control circuitry for the PC04 is contained in the CPU".
Table 2-2 on page 2-3 shows that the same 8 basic reader-punch circuit boards are in each version: 1x G918, 4x M040, and 3x M044. The M7050, M710, and M715 are the PDP-11 controller logic that's unique to the PC05.
So it looks like at least in theory, you could remove the M7050, M710, and M715 and use the PC05 as if it was a PC04. Unfortunately, figure 2-1 on page 2-2 shows those 8 basic boards not being plugged in to the same slots in the backplane.
I think it's safe to assume that the PC05 backplane all these boards plug in to is wire-wrapped? If so, that could be in your favor.
The practical upshot would be that if you were ambitious enough, you could figure out where on the Omnibus card connector the necessary signals are (easy with the print set for the Omnibus card). You could then figure out where the corresponding signals are on the wire-wrapped backplane in the PC05. Then it's just a matter of connecting the two. 8 bits of read data, 8 bits of write data, and on the order of 5-ish control signals with some power & ground means connecting on the order of 25 connections between the two. The top two slots in the PC05 backplane seem to be unused, too. If your Omnibus card came with the two W077A cables, you could even hand-wire from the pins in slots 1A & 1B to the right places and use the W077A Omnibus cables. But again, all that ultimately depends on how much more detailed research you want to do to find the pins on the wire-wrapped backplane and how comfortable you are connecting everything.
Martin Eberhard
Mar 18, 2020, 8:47:02 PM3/18/20
to
> What is the Omnibus board identifying number? M8xx?
It's an M840, the PC8-E controller board.
> Unfortunately, figure 2-1 on page 2-2 shows those 8 basic
> boards not being plugged in to the same slots in the backplane.
I was rather hoping I might luck into someone who has a PC04 that they might consider swapping for a PC05...
I'm in no hurry on this, I still have PLENTY of other projects. Today I concluded that my TU56 has some component (somewhere in the read channel?) that is temperature sensitive - it behaves when cool, but gets more and more flaky as it warms up. It will take some time to track it down. I went through the few adjustment in the TU56, tuning the edge detectors on the read amplifiers, and tuning the motor control oscillator. None of these was particularly far off, so I don't think they are the problem.
By the way, I've started a project to list and identify as many of the older DEC modules as I can, and link them to the options to which they belong. It's a work in progress, but have a look - the DECModules.xls file here:
https://deramp.com/downloads/mfe_archive/005-Documentation%20and%20Code%20by%20Martin/020%20Documentation%20by%20Martin/0500-DEC%20PDP8%20Documentation/
It's got a couple of tabs at the bottom, one lists modules, the next lists options, and the last lists products.
In order to keep the size reasonable (like the rest of my DEC archive), I've restricted myself to Omnibus, Unibus, and earlier DEC systems - no QBus, etc. Gotta draw the line somewhere :-)
Steve Tockey
Mar 18, 2020, 9:55:52 PM3/18/20
to
"It might be a punch in the face - requiring rewiring the backplane. Or it might be easier than that."
Is this document in your archives?
http://www.bitsavers.org/pdf/dec/papertape/PC04-PC05.pdf
It's the print set that should have everything needed--assuming you did eventually want to go that route after all.
"I was rather hoping I might luck into someone who has a PC04 that they might consider swapping for a PC05..."
"Today I concluded that my TU56 has some component (somewhere in the read channel?) that is temperature sensitive - it behaves when cool, but gets more and more flaky as it warms up. It will take some time to track it down."
"By the way, I've started a project to list and identify as many of the older DEC modules as I can, and link them to the options to which they belong. It's a work in progress, but have a look - the DECModules.xls file here"
"I've restricted myself to Omnibus, Unibus, and earlier DEC systems - no QBus, etc. Gotta draw the line somewhere :-)"
Dennis Boone
Mar 19, 2020, 3:06:40 PM3/19/20
to
> By the way, I've started a project to list and identify as many of the
> older DEC modules as I can, and link them to the options to which they
> belong. It's a work in progress, but have a look - the DECModules.xls
> file here:
>
> https://deramp.com/downloads/mfe_archive/005-Documentation%20and%20Code%20by%20Martin/020%20Documentation%20by%20Martin/0500-DEC%20PDP8%20Documentation/
You're aware of:
> older DEC modules as I can, and link them to the options to which they
> belong. It's a work in progress, but have a look - the DECModules.xls
> file here:
>
> https://deramp.com/downloads/mfe_archive/005-Documentation%20and%20Code%20by%20Martin/020%20Documentation%20by%20Martin/0500-DEC%20PDP8%20Documentation/
http://homepage.cs.uiowa.edu/~jones/pdp8/hard8e/modules.html
http://dustyoldcomputers.com/pdp-common/spares/spares-m.html
http://so-much-stuff.com/pdp8/flipchip/modules.htm
etc?
De
Steve Tockey
Jun 20, 2020, 7:58:35 PM6/20/20
to
Martin and all,
I successfully connected an OP-80a replica paper tape reader from JM Precision Engineering:
http://jmprecision.co.uk/shopping/start.php?browse=1&cat=24&=SID
to a spare Raspberry Pi (*) and used it to read a real paper tape copy of Edu20c Basic. I then compared the contents of that real paper tape, bit-for-bit, with the reconstructed version I shared earlier. There are no differences between those two binary images. They match exactly.
The self-starting Binary Loader on the front of my reconstructed version is known to be different than the original, but they function equivalently.
Cheers,
-- steve
(*) I connect the spare Pi to the OP-80a via GPIO so I cannot run the OP-80a and the PiDP-8/i at the same time. I read in the tape on the spare Pi and save it as a simulated paper tape file (e.g., *.bn). I then transfer that simulated tape image to the PiDP-8/I and deal with it there as the simulated tape. It would be more work, but one could build a parallel-to-serial converter and have the OP-80a read directly into the PiDP-8/I via a serial link. For my needs, that extra step is unnecessary. And, for what it's worth, I'm willing to share what I did to make the connection, including the C code on the spare Pi that transfers the paper tape data into a file on the Pi.
I successfully connected an OP-80a replica paper tape reader from JM Precision Engineering:
http://jmprecision.co.uk/shopping/start.php?browse=1&cat=24&=SID
to a spare Raspberry Pi (*) and used it to read a real paper tape copy of Edu20c Basic. I then compared the contents of that real paper tape, bit-for-bit, with the reconstructed version I shared earlier. There are no differences between those two binary images. They match exactly.
The self-starting Binary Loader on the front of my reconstructed version is known to be different than the original, but they function equivalently.
Cheers,
-- steve
(*) I connect the spare Pi to the OP-80a via GPIO so I cannot run the OP-80a and the PiDP-8/i at the same time. I read in the tape on the spare Pi and save it as a simulated paper tape file (e.g., *.bn). I then transfer that simulated tape image to the PiDP-8/I and deal with it there as the simulated tape. It would be more work, but one could build a parallel-to-serial converter and have the OP-80a read directly into the PiDP-8/I via a serial link. For my needs, that extra step is unnecessary. And, for what it's worth, I'm willing to share what I did to make the connection, including the C code on the spare Pi that transfers the paper tape data into a file on the Pi.
0 new messages