How to get files on/off of the PDP-8 ?

[alank2]

What is the best way to get a file like .SV transferred to or from the PDP-8?

[Jonathan Trites]

Searches seem to say that kermit would be the way to go, although that is just from reading web pages.

There seems to be a pdp8 version here: http://www.columbia.edu/kermit/pdp8.html

This page talks about using kermit with a pdp10: http://retrocmp.com/projects/blinkenbone/simulated-panels/231-virtual-pdp-10-ki10-kermit-file-transfer

But it might be a similar process for pdp8.

Try a search like "pdp8 file transfer" or "pdp8 file transfer pc".

I haven't tried any of those things but it is what I could find.

[Jonathan Trites]

Also just thought of this.

There's also the load/dump and save/restore commands at the simh command line.

See sections 3.1 and 3.2 here: http://simh.trailing-edge.com/pdf/simh_doc.pdf

[Rick Murphy]

I use the PUTR program to do that. It's a MS-DOS .com file but I've gotten it to work under dosbox on Linux with no real effort. This allows you to easily city files to and from the OS/8 media.

    -Rick

On Mar 6, 2017 1:49 AM, "alank2" <alan.kam...@gmail.com> wrote:

What is the best way to get a file like .SV transferred to or from the PDP-8?

--
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/85d99fb7-c5ff-4265-ab76-7cbbd306da0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Remy van Elst]

I've documented a way with PIP and printing to get text on and off the system. SV files work as well with PIP:

https://raymii.org/s/articles/Creating_an_OS8_RK05_system_disk_from_RX01_floppies_for_the_PDP-8_with_SIMH.html#Punching_and_reading_PAPERTAPE_with_PIP_aka_getting_files_in_and_out_of_the_system

https://raymii.org

--
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/c976cb79-4e34-49f6-8bc5-27238e81b1e0%40googlegroups.com.

[alank2]

I get a line too long error even when I try the /I option with pip...

[Remy van Elst]

There is a max of I think 140 characters per line.

https://raymii.org

On Mon, Mar 6, 2017 at 3:00 PM, alank2 <alan.kam...@gmail.com> wrote:

I get a line too long error even when I try the /I option with pip...

--

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/ed127849-ce87-4663-bc8d-ae83d3203e3d%40googlegroups.com.

[alank2]

So, was PIP able to work with binary files like SV's that had more than 140 characters?

[Len]

Here's a thread discussing my son's and my experiences with this a few months ago (sorry, I'm not trying to ignore your contribution to that thread, Remy!):

https://groups.google.com/forum/#!topic/pidp-8/h9OK306CI68

[Paul Borman]

This weekend I wrote some utilities to extract files from PDP-8 disk images.  I plan to add the ability to delete and write files and possible to defrag the file system.  These utilities are written in Go and run on the host machine (development is being on on a Mac but the programs should work fine on a RaspberryPI).

I will try to get this up on github sometime soon, if there is interest.

[clasystems]

On Sunday, March 5, 2017 at 8:49:45 PM UTC-5, alank2 wrote:

What is the best way to get a file like .SV transferred to or from the PDP-8?

An interesting place for me to start with this group..

Let me start with an introduction:

I am the "legendary" Charles Lasner; some of you know who I am; the rest can do a Google search.  [Don't forget to search for exactly "Charles Lasner" to avoid most of the false positives.]

Now that I got that out of the way, I am completely "resurfacing" now that I am retired from the labor force, but certainly not computers.  I have certain limitations; all things 12-bit computing are none of them, although I am a total novice at PIDP8, and all I ask is the ordinary courtesy of a newbie in that regard, but for ALL of the real PDP-8-related questions, I can deconfuse any and all of you.  And understandably, some of you are just "wandering around" because apparently no one here knows all that much.  We all can learn what we don't know, including me.

Before I start, just one quick note:

I personally created alt.sys.pdp8 back in the day, and because of the barrage of insults that comes up now and then I have had to essentially retreat from my own creation.  I don't need questions from people far younger than my software questioning how I just happen to know things they never could, and thus they assume I must be as clueless as they are, etc.  When you get to my age, you will understand.  The simple answer to those things is that I was "there" at the time and I am quite well-known over the last 50 years or so.

Now all that said, I want to start here with a clean slate and will report on many topics; since all of them will be connected to the real PDP-8 and related issues, there can be no question as to the relevance of anything I post.  Please note I am not saying anything out of ego, just out of absolute fact.  Yes, I am that guy :-).

For right now, I will concentrate an the relevant answers to the question posed; I face it everyday as I am currently writing new PDP-8 code.  I took a little "break" from it from about 1992 through 2007 because it was no longer economically viable for me to eat, but I never stopped caring.  2007 was a bad year for me and I have certain medical issues, but it doesn't stop me from working brain to fingers in front of a laptop.  I think I can slowly deal with the front panel of the PIPDP-8, but frankly I'm not sure.  However, I use the SIMH simulator in Windows daily, etc.  [A topic for another time.]

I am the author of Kermit-12 and more importantly, the associated utilities which are what is needed to deal with your issues.  It's the problems I worked out in the late 1980's into 1990.  No edit has been made to any of the Kermit-12 package members with the lone exception of a hack patch that works [but slightly messes up the modularity of the source code for all of its intended configurations; when I get a chance I will more "cleanly" put it into the source code, and I have a few other minor changes on my Kermit-12 to-do list that affect running it under OS/278 V2 on the DECmates, and also getting users of the GIZMO system a way to not have to kludge things either.  [The hack patch affects certain actual systems out there, such as a real PDP-8/I and a real PDP-12 that have been restored.  These systems are hard to get a second serial interface on [PT08, etc.] so when the hack is applied, you can perform a Kermit session where the "other side" is the actual console device on 03/04 which is not actually a terminal, but in this case is a PC running a terminal emulator in turn able to support Kermit protocol.  None of that affects PIPDP-8 usage, so for all of your collective purposes, it's fine as it was back in the day, etc.

Specifically, only very sophisticated Kermit packages handle full binary, and it is not required, just a nice option if you can get there.  This Kermit is closer to the bare essentials, which means strictly seven-bit ASCII text files.  This is where the other Kermit-12 package utilities come in.

In the package you will find the source file K12ENC.PAL and K12DEC.PAL.  Kermit package conventions use the full three-character extension such as in RT-11 and TOPS-10.  You have to make the appropriate extension conversions [mentally] to translate into the limited OS/8 environment.  The short-hand notation for filename description is such that MS-DOS files are 8.3,, and OS/8 is 6.2, and TOPS-10 and RT-11 are 6.3.  Since often the transfer is into a "wider" name convention system, always do the appropriate renaming, etc.

If you assemble K12ENC.PAL using that file brought into SIMH on some machine, you can assemble it into ENCODE.BN and save it into ENCODE.SV.  This is described early in the source file so you can set all proper assembly options [which always matter, so I never leave anything to chance].

Similarly, K12DEC.PAL becomes DECODE.BN and then DECODE.SV

I can assist anyone with e-mail of any and all of these files upon request made here, etc.

You take any file in OS/8 as the object of the problem and solution.

Say you want to encode PAL8.SV and then get it back to PAL8.SV somewhere else, and use Kermit-12 to move an "ASCiI-fied" version of it as an intermediary to get through the Kermit process, etc.

An example of this is actually in the Kermit package now.  Look for PAL8.ENC and CREF.ENC.

These are the releases of PAL8 and CREF, respectively, that are from the OS/278 V2 package.  I personally checked them to make sure there are no 6120 CPU-isms or OS/278 isms, both of which can happen on that turkey that was ruined by clowns in DEC that were quite clueless.  [Here's an example:  OS/8 ODT needs the <LF> command a lot, a common one, etc.  Well, in that OS/278 system, if you press <LF> in ODT, the machine hangs!  You have to TURN IT OFF to recover!]

So, I completely recommend you replace your current PAL8 and CREF with these two; I certainly have since around 1983.  [Forget about everything else in OS/278!]

So, to take PAL8.ENC back into the original .SV form:

Assume PAL8.EN is in the default [DSK:] directory.

.R DECODE
*PAL8.SV<PAL8.EN

That's all it takes.

To create ENcoded files is similar:

.R ENCODE
*PAL8.EN<PAL8.SV

For this basic function, I made it as easy to use as possible.

The utilities have more uses, and it might come in handy:

An entire OS/8 device can be turned into an ENcoded file.  For this you need to know the length in octal OS/8 records of the device you intend to ENcode.  Note:  OS/8 is very sloppy with regard to what a RECORD is versus what a BLOCK is.  If you understand more global PDP-8 topics, a block is 128 12-bit words, but to confuse everyone, they are used interchangeably here.  II will always point this out where necessary because without that understanding there are certain things that literally cannot be properly understood.

If you have no other way to know that length, here is an easy trick.  The DIR command on an empty device will show xxxx free "blocks".  Take that number and add seven and convert to octal.  This is necessary due to the limitations of the OS/8 command decoder.

Let me give the example that illustrates all of these points at once:

If you use the SIMH simulator with TC08 DECtape support, the DECtapes are actually 2702 octal DECtape blocks.  Each is 129 12-bit words because all DECtapes are required to be multiples of 18-bit words for inter-compatibility, etc.  Logically, the handlers all prevent the last word by setting the word count to -128 on each and every block.  Thus, the LOGICAL block size of a DECtape is 128 words [and the physical length is 129 words, something only needed when discussing DECtape hardware issues].

OS/8 uses two such blocks per OS/8 record.  Thus, you have .1341 octal records.  In decimal that becomes 737.  Subtracting seven you get 730, and a DIR listing of an empty DECtape will indeed show 730 free "blocks" etc.

So, do the slight math for your device.  Let's assume it's a DECtape for the moment, calculate as appropriate for other devices, etc.

To Encode an entire DECtape into a file:

.R ENCODE
DECTAP.EN<DTA1: /I=1341

And to decode that into the equivalent of the original DECtape:

.R DECODE
DTA1:<DECTAP.EN/I=1341

The encoding format uses groups of five-bit encoding into a caseless character.  This means that the encoded file can be passed through just about any intermediaries and come out the other side without loss of the original file.  It also includes some internal comments to help the process out.  You can look at PAL8.ENC to see what is done, etc.

And the data is protected using a 60-bit checksum using quintuple-precision arithmetic.  If you get through the process, you can be pretty damn sure you didn't lose anything.  Error messages are defined and all of this is explained in the first couple pages of the two source code files, etc.

Also, the size of the file you get YMMV because it uses run-length compression for any 12-bit value.  Many other schemes encode 8-bit bytes and more specifically all zero bytes only.  There are also a pair of utilities in the package for the Kermit standard encoding in what they call .BOO [boot] format.  It isn't anywhere as good as ENCODE and DECODE, which are an outgrowth of those utilities [retained because it is relevant in the more general Kermit sense of things.  In fact, this format was the outgrowth of a discussion I had with Frank da Cruz, the original Kermit author for the TOPS-10 version and head of the project, etc.  He had his own misgivings and I wanted to make sure it could also get through modems using the WPS8 communication, something that is quite "manglling" but few outside of DECmate users were familiar with, etc.]

For some configurations, there is a fatal flaw in the design:  The ENCODEd file is larger than the original, and if the entire device is being used, the resultant file is larger than the device!  How do you get this to work if you don't have some other device even larger?

I dealt with that as well.

In the above examples, change the options on the command-decode line to:

/I /! =xxxx

And in a separate instance use:

/I /2=xxxx

Each of these creates a "half" image of the device.  Clearly, a half device image can fit on a device.  Thus, consider a small system based only on a couple of DECtapes:

1)  Create a bootable OS/8 DECtape that only has on it ENCODE.SV

2) The DECtape to be images is on DTA1:

3) .R ENCODE
   *SYS:PART1.EN<DTA1:/I /1=1341.

This means that the mostly-empty system DECtape now has the rest of the free space to hold the part one file.

4) Similarly create another empty system DECtape with only DECODE on it at the receiving end assuming identical configurations, etc.

5) Copy the PART1.EN file onto the system DECtape.  This essentially reproduces what was done above.  [It is assumed the file was sent by Kermit or other means; this is now how the receiver puts it back together.

6) Using DECODE and the same options and an empty DECtape on drive 1, you will recreate the first half of the original DECtape, etc

7) Do all of the last few steps except with a PART2.EN file to recreate the second half of the DECtape.  Job done and no device storage larger than what is at hand is needed.

I think I have given an adequate answer to this question posed.  Anything else, feel free to follow up.

cjl

[Jonathan Trites]

Actually, it seems kermit is already present on Oscar's disk image so no need to build anything.

There are these files:

 K12DEB.BN   3   

 K12DEB.SV   4   

 K12DEC.BN   5   

 K12DEC.SV   5   

 K12DJG.BN  24   

 K12DJG.SV  33   

 K12ENB.BN   3   

 K12ENB.SV   4   

 K12ENC.BN   6   

 K12ENC.SV   6   

 K12MIT.BN  24   

 K12MIT.SV  33   

And I can run it at least at a basic level:

.R K12MIT

PS/8 PS/12 OS/8 OS/12 OS/78 OS/278  KERMIT-12  V10G   06 SEPTEMBER 1990

[CPU TYPE IS: PDP-8/E]

INSERT LOCAL USER MESSAGE HERE!

TYPE HELP<CR> FOR HELP

KERMIT-8/E>HELP

SUPPORTED COMMANDS ARE:

CONNECT (TO REMOTE SYSTEM)

SEND DEV:FILNAM.EX

RECEIVE DEV: (FILENAME AND EXTENSION NOT ALLOWED)

GET DEV:FILNAM.EX

FINISH (SERVER)

EXIT (TO OPERATING SYSTEM)

HELP (THIS MESSAGE)

ESCAPE CHARACTER: CONTROL-]

KERMIT-8/E>

[Joshua Kaplan]

That is an awesome writeup on how to do the encoding and decoding. I've been trying to work on a utility that would let me encode and decode outside of the PDP system - but haven't had the time. This would be extremely useful to be able to get files on and off that might have issues being uploaded and downloaded via kermit (or more reliably as well).

I was reading through some documents online on how the encoder works and trying to piece through the assembly - but haven't had much luck. I think the most interesting document I've read on how to read the format was this email you wrote about the format:

ftp://kermit.columbia.edu/kermit/d/k12enc.doc

Of course - I might just need to break the format down into the groups and their types so that I can track what is what as well.

Would you happen to know if there was an encoder/decoder that isn't in assembly? Of course - it is possible that assembly is the best language for this - so I might just have to work from that and the above document.

[alank2]

K12ENC AND K12DEC work very well - thank you!!!!

[clasystems]

On Monday, March 6, 2017 at 10:42:40 PM UTC-5, Jonathan Trites wrote:

Actually, it seems kermit is already present on Oscar's disk image so no need to build anything.

There are these files:

 K12DEB.BN   3   

 K12DEB.SV   4   

 K12DEC.BN   5   

 K12DEC.SV   5   

 K12DJG.BN  24   

 K12DJG.SV  33   

 K12ENB.BN   3   

 K12ENB.SV   4   

 K12ENC.BN   6   

 K12ENC.SV   6   

 K12MIT.BN  24   

 K12MIT.SV  33   

Most, but not all of these are correct.

 

And I can run it at least at a basic level:

.R K12MIT

PS/8 PS/12 OS/8 OS/12 OS/78 OS/278  KERMIT-12  V10G   06 SEPTEMBER 1990

[CPU TYPE IS: PDP-8/E]

INSERT LOCAL USER MESSAGE HERE!

TYPE HELP<CR> FOR HELP

KERMIT-8/E>HELP

SUPPORTED COMMANDS ARE:

CONNECT (TO REMOTE SYSTEM)

SEND DEV:FILNAM.EX

RECEIVE DEV: (FILENAME AND EXTENSION NOT ALLOWED)

GET DEV:FILNAM.EX

FINISH (SERVER)

EXIT (TO OPERATING SYSTEM)

HELP (THIS MESSAGE)

ESCAPE CHARACTER: CONTROL-]

KERMIT-8/E>

The problem with this is that someone doesn't read the documentation.  The release includes what should have been used in .ENC format, retrieve THAT file and DECODE it.  The discrepancy is people just sloppily assume things.   Like anything else, if you don't read, you suffer the consequences.

The source file has lots of good info in many pages of the beginning, including the fact that you SHOULD NOT just assemble it on your own. It HAS to be that way so it can be proper customized, and the easy way is to assembly it with the file PARAM.PAL which should be in the file collection.  That is precisely what was done in the encoded binary in the release, etc.  I have no control over people who don't quite understand what they are doing.

The DJG version is the one with the patch, but I have no idea if otherwise it was also properly assembled.  The correct way is to have the slightly newer source and also PARAM.PAL.  I had nothing to do with that patch, and I on record that it is done in a hack way and I know who did it, whose motives were merely a quick-and-dirty solution to the problem.  When I integrate it properly in the next official release, none of this will be a problem.  The updated PARAM.PAL file will address what the hack is trying to do as well OR I might implement a command-line option.

There is already another problem that must be kludged to get around:  I never contemplated a 6120-based non-DECmate, thus the GIZMO cannot run the standard version.  I will either add a command-line switch or something more definitive regarding DECmates versus other systems that have the 6120 as the CPU.

This also came up in an item called the CPU-8 which was a one-board quad-card Omnibus CPU based on the 6120 with external DMA capability added on the board, pretty clever overall actually.  All peripherals work, etc.  But it also flunks the logic; it ain't a DECmate merely because the CPU is a 6120.

Here is the problem:

The reason OS/278 is hopelessly incompatible is that the 03/04 interface itself is hopelessly "nearly" compatible with the standard one on all prior machines even including the PDP-5 and the PDP-8/S [they have other problems, thus are rejected from the "family of 8" definition that OS/8 and P?S/8 require.

On all compatible machines:

6031 - skip on keyboard flag, nothing else.

6031 - on DECmates [meaning using the 6121 IO chips - skip on flag, and regardless CLEAR THE FLAG!

On this point alone, this means all Control-C handling is now hopelessly broken.  If you are running BATCH, the abort to 07600 is incapable of realizing the user abort!

6032 clear the AC and clear the keyboard flag.  But on the DMs it's just clear the AC.

6034 read the keyboard buffer and do not clear the flag the true LATEST character is .OR. into the AC.  But on the DMs, it is re-read the previous character, not the LATEST character.  Again, part of why control-C handling and related valid technique on all other machines cannot work.

6036 because it is 6032 and then 6034 gets you the latest character into the AC and the flag is cleared.  But on the DM, it is true that it loads the AC with the latest character.

This is why oversimplified atypical and certainly not "intelligent" console input handling sorta works.

There is a similar output problem, but if we had only that, we might be able to live with it.

To make matters far worse, once the good people [I know them all personally, I was almost one of them, another story for another time] all left the PDP-8 group, a bunch of idiot "young turks" took over and ruined many things, including breaking things better left unfixed.

These absolute idiots also had an attitude, refused to let anyone in from the user community and just broke things scandoulsly;  Clueless and arrogant, they even produced a short "edict" for other programs to "follow:.

This is nice and neat table of PDP-8 versus DECmate.  Looks great.  One problem IT IS A FAIRYTALE!  Thus, this guaranteed total failure, etc.

My fix will involve something like this:

For those who do not know, there are two distinct ways to program the PDP-8 output to the console.  OS/8 does not enforce it, but a lot of the code does it the non-overlapped way which is unfortunate.  I will illustrate both:

1) non-overlap:

TLS
TSF
JMP .-1
[sometimes an extraneous TCF]

This guarantees that no CPU processing independent of the wait loop is ever done.  Especially bad on teletypes and you could tell from the sound of it it was not smooth, but actually noticeably choppy.

2) Overlap.

TSF
JMP .-1
TLS


This has the advantage that all OTHER programming has productively used up much [if not all\ of the wait time.  The next time the subroutine is called, in general the characters are outputted in perfect step to the baud rate; on a teletype you can here the smooth output.

the second method has to be initialized; no such thing in the first.

Kermit-12 has a lot of space for once-only initialization code, a concept that goes back to the days of FOCAL, 1969.  The space is later reclaimed as a buffer or something for a later purpose.

So, in the once-only code, I have a time-out routine to make sure the flag is definitely done CHANGING.  Then with a clear AC I output a <NUL> using a TLS.  That "primes the pump" for the rest of the code efficiently using the second method consistently, etc.

Some if the ignorance comes from not realizing this is ALWAYS a non-interrupt environment and inappropriately partially applying interrupt handler illogic.  Intertupts are handled a totally different way, irrelevant to virtually all of OS/8, etc.

The change is to wait yet again for the flag using TSF until that skips.  Then perform another TSF.  If it skips again, this is a PDP-8, and if not, then it is a DECmate.  That's the gist of what I have to do as part of a more compehensive next release, etc.

So, go obtain the RELEASE K12MIT.ENC, and decode it and you have the intended release without the silly message and perhaps other mis-set defaults not defaulted as intended.

Custom versions have to NOT use PARAM.PAL because knowledgeable users make custom changes.

Logistically, I had to accommodate the small contributions of former code writers to the project.  this allows all of them to be viable, etc.

Perhaps I should also remove all of that silliness to simplify the program and just document how to patch in those things over the normal messages; again, hindsight is 20/20, but this was not my project, I was "merely" a contributor [and I also volunteer to test the MS-DOS version, not write anything there].  Since this is now ancient history, I will consider a next release I can more fully call my own.

A good thing is the ENCODE and DECODE are there, so you have less to do.

cjl [thanks for telling me this, but I am ignorant of all things PIPDP-8]  [Hopefully as some help me to learn, that will change]

[clasystems]

On Monday, March 6, 2017 at 10:55:11 PM UTC-5, Joshua Kaplan wrote:

That is an awesome writeup on how to do the encoding and decoding

I hope so.  But I didn't post now anything not covered in more succinct form on the first two pages of the source files K12ENC.PAL and K12DEC.PAL

If anyone needs any of these files, I also maintain one of the larger [not by any means the largest] on-line archive of 12-bit files which includes verbatim the entire release; I do not include the newer source code that leads to the DJG version because it does not adhere to my strict source code requirements and easily confuses and breaks the conditions.  As I said, yo my knowledge this is only important to a few users that have REAL PDP-8 systems and contrived configurations.  That said, I did foresee a real PDP-8 using a DECmate III as a console device running Kermit-12 on that, etc.

My archive is located on Ibiblio.org, all directories below the PDP-8 part are my "little area" and concern many subjects, most of them relevant to members of this forum.  Feel free to browse, etc.

http://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/kermit/k12/

And I am perfectly willing to host relevant PIPDF-8 files as well.  The great thing about the PDP-8 is the files are actually quite small compared to other machines, so for the present, I have no problems making the collection even say 4 times as large, etc.

. I've been trying to work on a utility that would let me encode and decode outside of the PDP system - but haven't had the time. This would be extremely useful to be able to get files on and off that might have issues being uploaded and downloaded via kermit (or more reliably as well).

Stop re-inventing wheels.  That is the trivial part in the broader scheme of things.

I was reading through some documents online on how the encoder works and trying to piece through the assembly - but haven't had much luck. I think the most interesting document I've read on how to read the format was this email you wrote about the format:

ftp://kermit.columbia.edu/kermit/d/k12enc.doc

That is the exact definition document of how it all works, and it is in the complete Kermit-12 package.  I can explain anything you want that is in there, but I think it is pretty straight-forward and pretty self-explanatory.

Of course - I might just need to break the format down into the groups and their types so that I can track what is what as well.

It really isn't that complicated, and that's by design.  Please go read that document you correctly cite again.
 

Would you happen to know if there was an encoder/decoder that isn't in assembly? Of course - it is possible that assembly is the best language for this - so I might just have to work from that and the above document.

Yes, I can definitively say there is nothing else because nothing else is needed.  You just have to run the ENCODE utility on a functioning OS/8 system, including any SIMH-based one; I do it all the time.

The easy part is that once you have what you want, and get it to a SIMH environment [perhaps by e-mailing a .TU56 or .RK05 image file] then you can put that into another SIMH environment.

From there, you have to use the PTP: handler to have the file appear in the host environment as the file designated to be the simulated paper-tape punch file.

There are limitations on that method as described [and i have totally eliminated those problems as well, but they aren't relevant here, and involved a Windows-based version of SIMH I am just putting the "polis" on; I have been actually using it quite fine for just under three years, but I want it to be completely "slick" etc. A topic for another time].  Suffice to say, the contents of that PTPfile [I call it PTPOUT.TXT so I can look at it in Notepad, but some binary routines can look at it as well] will be exactly accurate for the purposes described here [just not for a lot of OTHER things; sorry to be a little cryptic, but the package hasn't been released yet.  Many will be impressed; the biggest critic of it is me, and now I approve it!, but you have to wait, etc.  Only got one set of hands!\]

So, that moves the ENCODED file to any system that hosts SIMH, in the host environment.

In my own case [using Windows] I use a 12.4 format, because that is what I am supporting [no details!].  For the Kermit-12 files, that means they are identical in my package as they were in the original TOPS-10 environment where those archives were created in the first case.]

A lesson that all must learn is to not to reinvent wheels and take full advantage of the works of others.  What I do bridges gaps no one else does, and then the overall process flies.

cjl

[clasystems]

On Tuesday, March 7, 2017 at 12:19:03 AM UTC-5, alank2 wrote:

K12ENC AND K12DEC work very well - thank you!!!!

Glad to hear it.  I try to write code that will outlast me.  In that regard, I failed, since I am still here :-)  But these two programs will not be changed from that early release because they just work.  If someone wants to write some .DOC file on thje process, I would welcome that of course, take what I said here, enhance what is in the source files at the beginning, and perhaps some introductory material and then we have a proper user guide, etc.

[Note:  Back when i wrote these things,  I was and still am the most prolific commenter of PDP-8 code, but not all that big on manuals not as a bunch of comments inside of PAL code, etc.

However, these days, I have developed a half-way decent writing style using an acceptable word-processor and others have complemented me on my new work.  But I have too many other PDP-8 projects to spare going back for the benefit of anything Kermit-related.  It would be about #45 on the back-burner project list!  I due course, if there is interest, I can explain some of them.  It appears few here are familiar with me, and that's fine, I only want in return some courtesy and respect and acknowledgement of expertise where due, AND some help as I may be taking the plunge with regard to the PIDP-8 itself, but frankly it scares me a little due to my medical condition [limited sight problems] and  at present really no time to give it the proper attention.  Realistically, six months down the road for me personally, but I am active every day on something at least somewhat relevant.

cjl

[clasystems]

I have a project I expect to get to in about a month on a different topic, but it does tie in with Kermit-12:

For the purposes of my question, I have purchases USB to serial cables and a null-modem to hook to two PC's in the same room, each running my Windows variant of SIMH and my extensions, etc.  The relevant part is I need help with the WINDOWS-specific configuration to get each of the SIMH systems to support device 40/41 so that each can talk to the other and use Kermit-12 on both ends.

If these were real PDP-8s and/or DECmates, this wouldn't be an issue, but my configuration is two Windows systems, one likely Vista Ultimate 64-bit and the other Windows 7 Ultimate 64-bit.

So, essentially running twin packages on both ends, and I need to know how to get SIMH to like it so that in the SIMH, device 40/41 is the second serial port.

Also, would like to know how fast that can be done.  All the cables are less than 3 feet each. etc/

Any help would be appreciated for April.

cjl

[clasystems]

This would also help me debug any changes I make to Kermit-12 at the source level!

cjl

[Jonathan Trites]

I found this in the simh documentation here: https://github.com/simh/simh/blob/master/doc/simh_doc.doc

Click "View Raw" to get the document. 

The short answer is that you are probably looking for "SET CONSOLE SERIAL" from section 3.14:

So, your USB serial cables should be installed as some COM port, and then use SET CONSOLE SERIAL to set the serial port and serial port options as discussed in 3.14. 

I pasted that section here:

3.14Console Options

Console options are controlled by the SET CONSOLE command.

The console terminal normally runs in the controlling window. Optionally, the console terminal can be connected to a Telnet port. This allows systems to emulate a VT100 using the built-in terminal emulation of the Telnet client.

SET CONSOLE TELNET=<port> connect console terminal to Telnet session

on port

SET CONSOLE NOTELNET disable console Telnet

Normally a console terminal configured to listen to on a telnet port requires that a telnet connection be active for the simulator to run. A telnet console can have its contents written to a buffer and which will allow the simulator to run without an active telnet connection. When a telnet connection is established, the buffer contents is presented to the telnet session and execution continues as if the connection had been there all along. Console buffering can be enabled by the following command:

SET CONSOLE TELNET=BUFFERED{=bufsiz}

enable console buffering and optionally

set the buffer size to ‘bufsiz’. The default buffer size is 32768.

SET CONSOLE TELNET=NOBUFFER disable console buffering

Output to the console telnet session can be logged simultaneously to a file:

SET CONSOLE TELNET=LOG=<filename>

log console port output to file

SET CONSOLE TELNET=NOLOG

disable logging

The console provides a limited key remapping capability:

SET CONSOLE WRU=<value> interpret ASCII code value as WRU

SET CONSOLE BRK=<value> interpret ASCII code value as BREAK

(0 disables)

SET CONSOLE DEL=<value> interpret ASCII code value as DELETE

SET CONSOLE PCHAR=<value> bit mask of printable characters in range

[31,0]

A simulator console can be connected to a serial port on the host system.

SET CONSOLE SERIAL=ser0 connect console to serial port ser0

SET CONSOLE SERIAL=COM1 connect console to serial port COM1

SET CONSOLE SERIAL=/dev/ttyS0 connect console to serial port /dev/ttyS0

The available Serial ports on the host system can be displayed with the command:

SHOW SERIAL display available serial ports on host

Serial port speed, character size, parity and stop bits can be indicated on the by appending the speed, character size, parity and stop bits to the serial port name:

SET CONSOLE SERIAL=ser0;2400-8N1

This will connect at 2400 with 8 bit characters, no parity and 1 stop bit. The default serial speed, character size, parity and stop bits is 9600-8N1.

Values are hexadecimal on hex CPU's, octal on all others.

The SHOW CONSOLE command displays the current state of console options:

SHOW CONSOLE show all console options

SHOW CONSOLE TELNET show console Telnet state

SHOW CONSOLE WRU show value assigned to WRU

SHOW CONSOLE BRK show value assigned to BREAK

SHOW CONSOLE DEL show value assigned to DELETE

SHOW CONSOLE PCHAR show value assigned to PCHAR

Both SET CONSOLE and SHOW CONSOLE accept multiple parameters, separated by commas, e.g.,

SET CONSOLE WRU=5,DEL=177 set code values for WRU and DEL

[Jonathan Trites]

And in case I misunderstood and you wanted Windows serial port information, the USB serial cable should automatically install and assign itself to some COM port, in my case COM3. You can change the serial port settings by going to the Control Panel and then Device Manager, and then into the properties of that device, as shown in this screenshot. I plugged in my Trendnet USB serial cable and this is how it installed itself automatically. If you click Advanced..., there is an option to change the COM port number if you wish.

Hope that helps.

[clasystems]

This is not quite right, apparently.

I DO NOT want to change the console [the 03/04 device] I want to add ANOTHER device 40/41 as well, both at the same time.

cjl

[clasystems]

Sorry, not the important stuff.

There are commands in the SIMH to set the port speed, I know that, and it involves some statement specifying that it is indeed a USB port in this case, which is pretty much the same hardware I am using.

This part is obvious and should pluig n play fine.  But so much more needed beyond that.

I got a garbled incomplete fragment of some stuff from others, but I need the entire definition.  This is just Windows and the default settings.  I need the SIMH configuration settings, a totally different issue, and also how high I can crank the speed up considering the short connection in this instance.  The speeds can be any PC serial port speeds, need not use nice numbers from real-word terminals.  Some PCs also have 2x and 4x port cards, but that's all irrelevant because this is the USB variant, so I want to know its fastest reliable "native" speed, etc.

cjl [I know, it's all confusing; A lot of SIIMH is either confusing, wrong, or just plain missing]

But as I said, a next-month project  but I did get the two cables and the null modem delivered, etc.

[clasystems]

Just a Kermit-12 factoid.

Proper assembly of all of these programs aside, the release used a nice OPTIONAL install method:

Just consider the number of memory fields a program loads into, say either some subset of 00000-07577.  Or perhaps 00000-07577 and part of 10000-17577, etc.

For every encoded .SV image in the release package, the binary was NOT the only file to load..

Consider there is a fiile on the release that is essentially

*0

ZBLOCK 7600-.

Or maybe also has

FIELD 1
*0
ZBLOCK 7600-.

As well.  Using ABSLDR, load first that Z4K.BN or Z8K.BN as necessary THEN the main binary file [such as K12MIT.BN]  Same for the smaller utilities as well.

When you save the file it is of course larger than it ought to be.  [But you could expressly state the proper limits manually.]

That is what was done on the release.  Why?

Because then any "holes" in the core image are all set to 0000.  Nice to have a "clean" core image, but it also serves a non-cosmetic purpose:  The resulting file when passed through the ENCODE program is generally remarkably smaller.  This is because of the run-length compression.  In just a few internal words in the ENCODE format internals, the entirety of the nearly whole memory field is stored in just two words!  OS/8 stores junk because it does not pre-clear memory before loading.  [It could have, they just didn't do it.]  So, this way, the .ENC files are as small as possible.  This is discussed in the beginning of at least the main K12MT.PAL file.  [Just further proof no one read the documentation sufficiently.]

cjl  [When you send stuff over 1200 baud modems typically back then, you care about stuff like this!]

[Jonathan Trites]

I also came across this:

sim> show dev

PDP-8 simulator configuration

CPU     idle disabled

TSC     disabled

FPP     disabled

CLK     60Hz, devno=13

PTR     devno=01

PTP     devno=02

TTI     devno=03

TTO     devno=04

TTIX    lines=4, devno=40,42,44,46

TTOX    devno=41,43,45,47, 4 units

LPT     devno=66

RK      devno=74, 4 units

RL      disabled

RX      RX8E, devno=75, 2 units

DF      devno=60-62

RF      disabled

DT      devno=76-77, 8 units

TD      disabled

MT      devno=70-72, 8 units

CT      disabled

Maybe this is what you are looking for?

TTIX    lines=4, devno=40,42,44,46

TTOX    devno=41,43,45,47, 4 units

Is that the device 40 and 41 stuff you are meaning?

It looks like you can attach a serial port to that if I understand the documentation right:

sim> help ttix attach

<snip>

Multiplexer lines may be connected to serial ports on the host system.

Serial ports may be specified as an operating system specific device names

or using simh generic serial names.  simh generic names are of the form

serN, where N is from 0 thru one less than the maximum number of serial

ports on the local system.  The mapping of simh generic port names to OS

specific names can be displayed using the following command:

   sim> SHOW SERIAL

   Serial devices:

    ser0   COM1 (\Device\Serial0)

    ser1   COM3 (Winachcf0)

   sim> ATTACH TTIX Line=n,Connect=ser0

or equivalently:

   sim> ATTACH TTIX Line=n,Connect=COM1

The input data rate for all lines or a particular line of a the TTIX

device can be controlled by specifying SPEED=nnn{*fac} on the ATTACH command.

SPEED values can be any one of:

    0 50 75 110 134 150 300 600 1200 1800 2000 2400

    3600 4800 7200 9600 19200 38400 57600 76800 115200

A SPEED value of 0 causes input data to be delivered to the simulated

port as fast as it arrives.

If a simulated multiplexor devices can programmatically set a serial

port line speed, the programmatically specified speed will take precidence

over any input speed specified on an attach command.

Some simulated systems run very much faster than the original system

which is being simulated.  To accommodate this, the speed specified may

include a factor which will increase the input data delivery rate by

the specified factor.  A factor is specified with a speed value of the

form "speed*factor".  Factor values can range from 1 thru 32.

Example:

   sim> ATTACH TTIX 1234,SPEED=2400

   sim> ATTACH TTIX 1234,SPEED=9600*8

   sim> ATTACH TTIX Line=2,SPEED=2400

The SPEED parameter only influences the rate at which data is deliverd

into the simulated multiplexor port.  Output data rates are unaffected

If an attach command specifies a speed multiply factor, that value will

persist independent of any programatic action by the simulated system to

change the port speed.

<snip>

The help goes on some more but maybe that gives you a hint? 

I don't really know, I just did some internet searches for "simh serial" and the like and running the help commands on my simh on the raspberry pi.

Pages like http://mailman.trailing-edge.com/pipermail/simh/2013-August/012583.html and https://github.com/simh/simh/issues/76 described it a little bit.