converting text to ptp

[Dawson Rosell]

So I'm having a little trouble with converting text to ptp files. I run the txt2ptp program that Warren gave me and it runs fine and says there were no errors, but when I attach the new file (in this case WHET.FT) to the ptr in simh and then use PIP to list it out (R PIP, TTY:<PTR:) it displays as shown in the picture below. It seems that the program isn't adding carriage returns. I asked Warren about this earlier and he said it looked like just Line Feeds or as he said "what UNIX lazily redefined as newlines"

Is there a different program I should be running?

Thanks!
​

[Michael Thompson]

Looks like an issue with CR/LR in Windows vs. OS/8.

--
You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--

Michael Thompson

[Michael Thompson]

Usually test editors will save the files in several formats. Try doing a save-as, and see if there are options for the CR-LF, and LF.

On Mon, Aug 21, 2017 at 4:01 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

--

You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--

Michael Thompson

[Michael Thompson]

This is another very useful tool for moving files to and from OS/8 disk images.

https://github.com/simh/simtools/tree/master/putr

On Mon, Aug 21, 2017 at 4:01 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

--

You received this message because you are subscribed to the Google Groups "PDP-12 Restoration Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pdp+uns...@d.umn.edu.

--

Michael Thompson

[CLASystems]

When I am "out of the loop" often times, silly issues like this crop up.

1) The best way our of all SIMH issues like this is to use my PEPSWIN [P?S Enhanced PDP-8 Simulator] package for Windows.

Anyone can cobble up a machine that runs Windows XP or newer, etc.

The entire point of my work is to make this conceptually impossible:

Often converting a file is incredibly messy with needless problems caused by an amazing number of problems unforeseen.  It cannot be helped, but I have learned one lesson over the yerrs which is never ASSUME anything about anything.

?I am not all that surprised that a program has such problems.  Frantly, Warren was not that grreat at writing software [you may have other opinions] and much of what he did was to follow others ASSUMING their work was acceptable to imitate.

When there are deaf-leading the dumb-leading the blind situations,m it comes to me to eradicate all ills.

My package is totally function at this point; I need to weed out the portions that represent that which is my own work from the package that is "just"the package but that is a relatively small matter at this point.  A LARGER one for me is preventing legal issues that could loom from some shyster lawyer for a disgruntled third-party shareware author, etc.  Thus, I have paused general release of the package primarily to create placeholders and the like and then document what to do regarding this.

Even with the remaining few parts removed, what is the remaining parts left are 100% mine and are the "guts" of the package.  In particular is the STRIP.TEC Teco macro that entirely vanquished every aspect of the problems you have stumbled into, etc.

What I recommend at this point to solve any particulars once and for all QUICKLY, is that you e-mail me the problem file and I will crank it through the package and return it in a format that will be liked.

The BEST overall method is to send me images of SIMH-compatible devices in e-mail, such as the .RK05 files that are compatible not only with any SIMH [whether a "raw" one or the polished superset I use] but also with Kyle Owen's server which I gather is what you are using on the PDP-12.  That file is universal and can be attached to e-mail directly without even needing any form of "wrapper" as as e-mail attachment.

That way, I can do all of them [assuming there are more than one].  The resultant files will be fine with MS-DOS/Windows and OS/8 if that is what you are at the moment caring about.  [That is not the be-all/end-all of things as it is, but it is supported in all that I do that is not P/S/8.  My PEPSWIN package includes both systems, etc.

Thus, for all of you with "non-commercial" interestes in PEPSWIN, I can send you a package with the proviso that you destroy it when I come out with the REAL public-domain one and of course do NOT ever distribute what I sent you.

I want to get this over with because I have much other things to do, but the size of the last-minute albatross around my neck is getting smaller, etc.

The intention is you just download a self-extracting archive file and double-click on it, and it takes care of the rest with a few initial interacttions.  Then it is obvious what to do, etc.  Also, Pete Peterson has some ideas about more intuitive icons, etc.  But I will trust you people to do the right thing, etc.  Besides, I want more beta testers to report any problems, etc.

So, please get back to me for both the short-term problems and the long-term one that ends all of your "pains".

cjl

"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992

[Dawson Rosell]

Thank you both for the quick responses!

Michael, I will look into PUTR, thank you!

Charles, I have attached the two files I wanted to convert to papertape format. I will play with getting them on the .rk05 because I still need to make a nice clean image with the Fortran compiler and a couple other files. I'm definitely interested in the PEPSWIN stuff as well. I use Ubuntu 16.04 primarily (but have a Win10 partition), will PEPSWIN run in WINE or should I just use my XP virtual machine?

Thanks again.

[CLASystems]

On Mon, Aug 21, 2017 at 7:14 PM, Dawson Rosell <rose...@d.umn.edu> wrote:

Thank you both for the quick responses!

Michael, I will look into PUTR, thank you!

​It was written a very long time ago by my friend John Wilson.  It only runs in MS-DOS.  To my knowledge that limits it to Windows 98 Second Edition and back or on real MS-DOS.  My boot CD runs the Windows 98 SE MS-DOS [the one that comes with it as a companion startup disk] that is fleshed out, etc.  You will likely have to run the SATA interface in compatibility mode to use it, but that way you don't need to get a USB diskette to do it that way, etc.  [It boots the virtual diskette on the CD, but it needs to run a driver to access the REST of the CD.]

From there it can read any FAT32 on back partition, and that's where PUTR can run.  But you need to create another partition because Windows Vista on up to Win10 all require NTFS for the partition they reside on.  [Notce I did not say DRIVE C:  I am an expert on Windows machinations.  They lie and tell you they are one and the same.  I have machines that have MS-DOS and maybe even Windows 3.1 on drive C: and no more.  Then there are a multitude of other systems further up the disk.  You need a few utilities to manage it all, but to claim what I routinely do cannot be done is pure BS.  It isn't easy, but it certainly a lot easier than the claimed impossible.]

PUTR has to actually access the hardware as in MS-DOS, etc.  Cannot used the excessively virtualized environment of even Windows 2000.  Windows ME is not viable either because they PREVENTED any access to the real underlying DOS either when coming up, going down, or even from the Windows desktop.  [You can do all of those from 98SE on back to Win 95, but Windows 98 SE with some extensions is the best of all worlds.  This includes a smattering of ME programs, etc.

In any case, you can not even use it on my Boot disk unless you create say a FAT32 partition first.  Third=party partition programs such as Eaze-us will work fine to do that.  Windows 10 has to be compatible with it, but it won't create them itself, etc.

I have to document some of this in the PEPS for Windows manual because I recommend a separate partition just for PEPS to make it easier to backup all of  your PDP-8 work into a nice little .ZIP file, etc.  That way, no extraneous junk, etc.

My two areas of expertise are the PDP-8 and MS-DOS/Windows, and a lot of Windows "stuff" few people know about.  [I've been a meber of some obscure forums for years, and have learned a lot; besides, the Windows world kept me eating after the PDP-8 no longer could!]

That said, i do not program anything in Windows or MS-DOS, but I am an expert on obscure BATCH techniques, and there is a lot of that inside of PEPS.  The typical operation is you double-click on a particular icon, and that runs an associated BATCH file to carry out the precise intended function.  There are many to support a real development environment for the PDP-8 from source file editing without burdens to creating PDF files for publication, etc.  And that of course means launching OS/8 and P?S/8 as needed for the particulars of a project [although they can boot each other within the same session.]  I also support management of the SIMH log file, and that can be useful to illustrate some techniques, etc.  [You can turn the log file on and off and clear or retain it.  That's two different icons in the PEPS command window.]

I will be working on updating the PEPS user guide somewhat, it needs another pass.  Then, all that will be missing are all of the appendices that deal with all of the sundry issues.​

 

​  Look for the announcement in the pepswin group, etc.
​

Charles, I have attached the two files I wanted to convert to papertape format. I will play with getting them on the .rk05 because I still need to make a nice clean image with the Fortran compiler and a couple other files. I'm definitely interested in the PEPSWIN stuff as well.

​You are needlessly conflating two separate things with each other.  When you use OS/8, you can have up to FOUR .RK05 images in play [I always do!] each with an RKAx: directory and an RKBx: directory where x is 0 or 1 or 2 or 3.  Moreover, the standard EXTENDED RK bootstrap supports booting to ANY of the four.  The one in SIMH actually can do that, but you have to specify bo RK0 or bo RK1 or bo RK2 or bo RK3.  The standard bootstrap is the two-word one to boot RKA0: but there is a standard extended one that reads the switch register to set the drive unit bits.  [OR you can create one piece of code for each of the four possibilities; either way works, and I need to use that because I will be working on P?S/8 for RK8E as well.  The standard package is for P?S/8 on TC08 DECtapes 9 through 7 with unit 1 reserved for inter-system conversion programs, thus, OS/8 gets DTA1:.  It cannot take much more because it only has 14 total .logical devices [DSK is a dummy alas for one of the others, not a separate device!].

But in P?S/8, the system device handles all eight drives without loading handlers at all, thus this is a good "mix" for working on both equally.  Future versions can support say P?S/8 on RK drive 2 and 3 with OS/8 on drive 0 and 1.  Then the DECtape issue becomes another option, and not virtually a requirement.  [Note: Because P?S/8 is a more complex system, it doesn't have a nice and neat utility like BUILD so that you can just change what you are booting to and nothing else changes. That's extremely low priority at this point to be realist, the rudiments alone have to wait until the next clean release, etc.]

Thus while in theory, while P?S/8 supports about a dozen different devices, for the present it will be on TC08 DECtape, and some logistic problems I have to solve with Michael Thompson stand before having a version for the PDP-12 LINCtape [which is not on anyone's simulator].  Note: Looking to the future, DECtape images of LINCtapes can be converted on a working PDP-12 using the TC12F program.  DECtapes can be imaged and supported in SIMH, etc.

To make life more interesting, my Kermit-12 utilities for OS/8 allow for an avenue that os not obvious:

The programs were originally created to support bullet-proof encoding and checksumming of files to avoid loss.  Thus, you could send any OS/8 file and trust you got it to the other "end" of things regardless of the "path" which could be hostile e-mail servers, etc.

But that is only part one.  The ENCODE and DECODE utilities can create an entire OS/8 device IMAGE into a compressed encoded file, to be expanded on the other end.  It is NOT required it be an OS/8 device!  The only requirement is the underlying block structure is the same as what the relevant OS/8 handler does with the data.  Neglecting odd byte-mode devices, this generally means that OS/8 can therefore move the corresponding P/S/8 system​ directly.  And since DECtapes and LINCtapes for both systems are compatible at the block level, that means you can create a bootable P?S/8 LINCtape that was created by me on SIMH as a DECtape and you don't even need to go through the TC12F program!  [You just need a working LINCtape drive.]  Thus, taking advantage of everything, you can get what you need from me via an e-mailed .rk05 file image.

So, think of "scratch" RK05 images that are for example meant to be RKA1: and RKB1:, not even intended to be booted, and use that as an intermediary.  Put your files on that, and I can send them back to you properly converted so they "at home" in the OS/8 environment as intended.

 

I use Ubuntu 16.04 primarily (but have a Win10 partition), will PEPSWIN run in WINE or should I just use my XP virtual machine?

​I have not tested PEPS in anything but the real XP [thus, I don't see any problems] or Windows Vista [I am in the death throes of the testing of Vista 64-bit.  I found some problems I had to end-run knowing Microsoft will never fix them, but I suspect the same problems exist in all 64-bit systems, just that Vista was the first to have the problem!  It's an obscurity regarding the REG program, the command-line version of the REGEDIT program because I do have to ensure a copy of things are correct.  The registry changes themselves are innocuous, but the managing program​

 

​I wrote got perturbed and that was a correct reponse; MS screwed up!  Now it handles all cases, etc.  It was never about the actual registry patching, rather the cosmetics after the fact the program needs to proclaim that all went as intended .  [It had, but the returned stuff was wrong!]

I have done some "surface-level" testing with Windows 7, but a long time ago with the "grandfather" of where i am now.  I foresee no problems, just have to actually do it.

My laptop runs XP and Vista-64 [that's really not as easy as it sounds!] and I got the free upgrade to Widows 10 [and can install it properly later when I get to it.]  I also have to test Windows 8 of course.

I don't foresee any problems with Windows 10; this is a desktop consideration.  You place a pair of icons on the desktop manually that in turn accesses the rest. the package includes a routine to manage setting an environment variable so you don;t have to learn how to do that.  But every system requires the variable be set. I just recommend using a drive other than C: so you can isolate your work better, etc. but yes, it will run on C:, and ought to work fine in Windows 10.

But if you want to play it save, by all means use a virtual machine running XP [and what do you use to get that?  There are more than a few, so please tell me which].  Then later, when you know what you are doing, you can try Windows 10 and see if it "behaves" there.  [Note:  I use VERY CAREULLY contrived Windows environment-variable language in the shortcuts, so it damn well better run on all of them!  As I said, the only problems are either cosmetic or an MS bug I had to work-around, etc

There are some cosmetic considerations that have to be dealt with  They do not exist in XP or Vista.  there is an available registry patch that restores what was FORGOTTEN ABOUT into Win 7 or Win 8 and it claims Windows 10 as well.  [The issue is this:  There are so many icons in the command window, you deserve the ability to arrange them in a logical grouping, and not merely by alphabetical order.  Without the help, you get sorted order and align to grid bot at the same time.  With the fix, you can retain the align to grid, but you place the icons where you want them to be.  The manual includes an example of a well-organized command window given some assumptions about what is in it with regard to sample projects, etc.  Most people do need everything, but what projects are being worked on need a particular pair of icons, one to edit the file, and another to launch SIMH passing the file in on the PTR: handler.  All exited SIMH sessions can have their output cleaed up by the STRIP.TEC macro for either LPT: output or PTP: output, etc. the latter is what I will use to solve your problem, etc.

From what I understand, WINE is not an emulator of a proper Windows desktop, just can launch executables adequately.  It has to be nitty-gritty details compatible.  I may be trying it on the REACTOS project where they are paying attention to details [and enough of it is done to me useful!].

Al in all, I recommend trying it from the XP emulator [depending on your details of what exactly that means].
​

Thanks again.

​cjl [will send you back proper files soon hopefully!]
​

 

[Michael Thompson]

putr worked fine on Windows XP.

Doesn't seem to like Windows 7.

--

Michael Thompson

[CLASystems]

On Mon, Aug 21, 2017 at 8:25 PM, Michael Thompson <michael.9...@gmail.com> wrote:

putr worked fine on Windows XP.

Doesn't seem to like Windows 7.

​I cannot get some of it to run on anything past 98 SE, but you aren't playing with diskettes!

cjl​

 

[CLASystems]

OK, all conversions went well.

Your original files have lower-case in them, which I suspect OS/8 F4 will hate.  As such, I also passed the files through OS8CON [in both directions] so these are the all-upper-case versions of the original [thus 4 files attached.]

cjl

On Mon, Aug 21, 2017 at 8:18 PM, CLASystems <clasy...@gmail.com> wrote:

[Michael Thompson]

The original mixed case file had just a line feed at the end of each line. The upper case file has a carriage return and a line feed at the end of each line.

--

Michael Thompson

[CLASystems]

​The original mixed case file had just a line feed at the end of each line. The upper case file has a carriage return and a line feed at the end of each line.

​True, but not entirely accurate:

The all-purpose nature of the STRIP.TEC macro completely cleans up all sorts of irregularities, including LF without CR, CR without LF and LF/CR instead of CR/LF.  In short, just on line termination alone it cleans up all mistakes, etc.  But it does not case convert.  Thus, all of the files are fine in
that regard.

I just went further than that in making a case-folded version from the already cleaned up input by using OS8CON, the P?S/9 conversion program.  It is not quite as "smart" with regard to the other problems, but generally comes close.  However, in this case, it was a post-process ​

 after what was already established in the STRIP.TEC pass.

When An OS/8 file [the mixed-case but otherwise OK file with CR/LF ending every line] is passed through OS8CON towards P?S/8, all of the following conversions occur:

1) [This will be fixed in the next release].  A couple of characters are totally ignored.  In the next release they will be converted to the # character instead.  The characters are @ and ` which are in violation of the P/S/8 6-bit character set.  Technically, they have no proper function in a six-bit word as in six-bit they become 000000 which is universally accepted as some form of null situation, admittedly system-specific as to exactly what.  But at the minimum, the way the TEXT and SIXBIT directives work in PAL, this has to be an end of string at the very least.  Thus, any practical implementation must not allow these characters directly, etc.  DIAL does it's internal reckoning somewhat differently, and in the process winds up slightly more restricted, in part because the file format has no internal word restrictions.  This is also part of the reason that editing with DIAL has pathological cases where you lose control for minutes at a time as it pathetically starts a "fix-up" process, etc.  I may in the future do a P?S/8 SHELL editor for the PDP-12 screen which by nature really has to be all upper-case, but there are better ways to do it than DIAL, and many have soundly criticized both it and the Vista editor for not being "smart" etc.  I would use the technique invented by Stewart Duwar except I would do a final clearout which as far as I know, he never implemented.  [This is getting off-topic, but the point is you have to have ground-rules, and the P/S/8 ones are consistent with the TEXT and SIXBIT directives of PAL, etc.]

In any case, the next release of OS8CON will instead of tossing the characters, they will be arbitrarily converted into # because the one valid case where they can be tolerated would be allowed.

Originally, the TEXT directive allows only the " characters delimiting the text.  This was then extended to " or ' as delimiters.  In TOPS10 PAL10, it was generalized to any innocuous character as a delimiter, most notably ; is not allowed because that indicates multiple statements on a line, but just about anything else could be tried.  Since this is a 7-bit character set situation, instead of flagging both ` and @ as illegal characters, they allowed both of them [not interchangeably].  But this is only true as delimiters of TEXT directives and no other place in the file is valid.  Since P?S/8 cannot support this, it was deleted.  But the new change will convert it to # because this will allow statements of the form

    TEXT #HELLO#

which is perfectly fine.  As a slight super set, P?S/8 PAL does not require the second delimiter IF and only IF the TEXT directive is the last statement on the line.  [The presence of a ; character cannot be considered as a delimiter, etc.]

These conversions are not affected by this situation, but it is germane to the topic.

2) Since P?S/8 text files cannot handle FF, the syntax EJECT with an optional horizontal tab in front is treated as the equivalent.  The conversion will provide the HT for neatness, but when going towards OS/8 it can be missing.  In most sixbit languages this is the syntax to be used originally, and it is an accommodation to the seven-bit character set that the FF character is equivalent to that sequence.  DIAL also supports this feature as does OS/8.  OS8CON thus converts FF to <HT>EJECT<CR> <LF>.  This is important because both PAL10 and P?S/8 PAL also support the TITLE ditrective and its alternative syntax:

    EJECT STRING

If there is a string after the EJECT, it becomes the title line on the next printed page.  OS/8 PAL8 does not support at least one of these methods, but P?S/8 is dual-compatible with PAL19 in this regard.  The default is to build the title line string from the first line of every input file, but P?S/8 also supports a command-line switch to turn off the secondary changes because the source program may be the concatenated convents of many files, thus it would be pointless to change it on every file in that situation.When a converted program is to a shorter series of P?S/8 extended-length files, this is a valid use of the feature, etc.  For example, the proper source files for FOCAL, 1969 is two files, normally called FOCAL.ZZM and FLOAT.ZZM.  When separately converted to P?S/8 extended-length files, each can participate as intended; the resultant listing is 100% authentic when compared to PAL10, etc.

Again, this is an issue not germane here, but this is to be thorough as these issues invariably do come up, etc especially when converting source code from DIAL.  P?S/8 supports another similar conversion program between DIAL tapes and P?S/8.  P?S/8 L6DCON uses internal LIINCtape routines and can only run on a LINC-8 or PDP-12.  The stated problem above does not apply, but there are other considerations.  [Note:  Both programs work in BOTH DIRECTIONS!].

3) CR/LF is converted into P?S/8 internal <EOL> which can be likened to the unix usage of LF alone, which was the original complaint.  Thus, if the ffiles were imaged directly into OS/8 complete with the inappropriate end-of-line, OS8CON would also have fixed the same problem.  However, it would also fold the file characters to upper-case as this is the character set of P?S/8 files.

Thus, without having to care, OS8CON likely could just be the only programming necessary, but it was clearly already resolved by the STRIP.TEC macro reducing the additional conversion to all upper-case.

Thus, as a post-process I decided to create all UC versions after the fact.  But since the ifles were as you described, P?S/8 OS8CON could have done that all by itself [I just didn't care because STRIP.TEC does EVERYTHING!].

Thus, in hindsight, this is what Warren was referring to, not liking it,but dealing with it from a unix position which was not helpful.  Since MS-DOS text conventions are the same as DEC conventions, the PEPS package for Windows will always solve these problems.

Always keep me in the loop when attempting any of these situations.  It's likely I've already been there and done that regardless of the particulars.  That way, a lot less time is wasted reinventing wheels.  If there is one criticism of Warren, it was that he was arguably TOO independent and self-sufficient and didn't ask if that was the case.  Since we are carrying on without him, let's all cooperate to help each other out where appropriate, etc.

In the meantime, I should be done with another pass on the PEPS user guide soon.  I will announce that soon in the pepswin group; still will be a "beta" but should be closer to final [sans appendixes resolving].

I had a snag I fixed last week:  The AnyPDF convertor turned out had a bug in it as used out-of-the-box where it misformatted lines wider than 120 characters.  This seldom occurs, but not never.  I created output that it ruined, etc.  fortunately,I studied their package more thoroughly and found obscure marghin property settings that corrected the problem.  [Largely undocumented, but it worked!  The settings exist, but the parameter numbing system is not documented, so I just started experimenting until I saw wha might work, etc.  Worked first time, etc.] so this is no longer an issue.

cjl

[Dawson Rosell]

Thanks for the converted files Charles! I got them on a rk05 image and they display normally, but don't compile. I forgot to go through the code and make sure its compatible with OS/8 Fortran IV. I'll look at that soon. Fall semester starts next week so I'm trying to get as much done this week as I can. 

[CLASystems]

Glad to help.  Yes, you now have the ball in your court so to speak.  Many have been there before; rarely are higher-level languages as compatible as one would want.  For years, people worked on nothing else but converting sources to work in new environments, separating out truly compatible features from extensions common in some particular "world" historically the most egregious being IBM adding dozens of extensions with a hidden agenda:  Make you dependent on their extensions, although  in general, you can work out the incompatibility by removing the needless frills, etc.

At some point well down the line, you should get the FORTX third-party product that is nearly compatible with the DEC offering, but is SABR-based, thus a bit closer to being PDP-8 code and not have the performance lost in layers of emulation of instructions that aren't even there, etc.  You are then just getting a yardstick on how well the emulation is and not the underlying architecture, etc.

Ultimately, what I would do is convert the code to assembler directly.  The PDP-8 instruction set coupled with common techniques for additional precision, etc. is a better gauge than any of these things.  It's just not a machine anyone bothers to care about the notion that a high-level language implementation imparts any insight in the how well the actual machine works.  And this is quite fair.  On some machines, the code is already in place, and you plug in arguments into it as the translation of compiling certain instructions.  That way, you are operating on more of a level playing field. without trying to write a compiler, etc.

DEC did have a plan to actually implement this, and MACREL is actually an out-of-control frill-laden super-set of what was needed, etc.Unfortunately, they canned the compiler portion of the project, etc.  [Probably because the PDP-11 people were scared that the PDP-8 represented a better value both on cost and comparable performance.  The reasons DEC went out of business are mainly incompetent management and cost-center in-fighting and sabotage.

cjl

[Dawson Rosell]

So I got the all caps single precision loaded just fine into simh. When I try to compile it spits out a few errors (as expected) but one of them is strange to me. It says MK 0002. So theres a misspelled keyword at ISN 0002. That line is IMPLICIT REAL*4 (A-H,O-Z) . I know this is a legal statement in other dialects Fortran, but maybe not OS/8 Fortran? I posted on the VCFED forums but thought I'd ask here too. 

Thanks!

[Michael Thompson]

If you compile it with like this:

R F4
,WHTSTS.LS<WHTSTS.FT

You will get a listing with the errors interspersed in the code.

It doesn't like "IMPLICIT", or REAL*4. The Language Reference Manual says that FUNCTIONS need at least one argument.

It has been a few decades since I did some FORTRAN programming, so it will take a while to wake those neurons up.

--

Michael Thompson

[CLASystems]

On Wed, Aug 23, 2017 at 8:55 PM, Michael Thompson <michael.9...@gmail.com> wrote:

If you compile it with like this:

R F4
,WHTSTS.LS<WHTSTS.FT

You will get a listing with the errors interspersed in the code.

It doesn't like "IMPLICIT", or REAL*4. The Language Reference Manual says that FUNCTIONS need at least one argument.

​I'm not surprised.  REAL*4 is pure IBM 360 propaganda.  A language cannot know the number of either bits in a group of bits nor how many of said groups there are in a variable description.  As in some other DEC FORTRANs, the standard floating point is 36-bits in the designated format invented for the early PDP-8 floating point PACKAGE which is all software.  The FPP-12 hardware uses the same format, albeit some other software packages have come along that do not, most notably the so-called 27-bit package where the exponent range is lowered to a mere 9 bits, which most people this side of astronomers don't care about while all will welcome 3 more bits of accuracy, etc.  But you cannot control this.  If you lack the hardware, you get an emulator much like the classic package except that the addressing scheme in no way imitates the PDP-8 addressing, rather the full 15-bit addressing a 32K machine deserves.  [The OS/8 BASIC addressing is also 15-bits.  8K BASIC uses relative addressing thus the address specified is relative to where the instruction is forward or backward of where the instruction is; this also uses the 27-bit floating format.  Actual addressibility is limited to a total of 4K, but this is because in this application, the program is "digested" into tokens thus you can get an amazing amount of BASIC programming into a stack no longer than an entire memory field.}

8K BASIC is based on 4K BASIC, a toy written by Lenny Elekman as a consultant to DEC.  [He never worked for DEC ever again after the fiasco of NOT tossing the OS/8 demo and instead a total do-over.  Jack Burness instead wrote DIAL; Hank Maurer write the DIBOL compiler, then hacked it on the R-L Monitor, the forerunner of P/S/8, and DEC never actually knew they were selling it!  Years later, they cloned the interface which works just like P?S/8 onto an "innards" of OS/8 with an offset date, etc.  Joe Fischetti quit the PDP-8 and instead joined an -11 group that unfortunately was run by a wacko manager with very strange notions of how to write an I/O sub-system.  When the "rules" were presented to Joe, he correctly said the man was a moron and quit on the spot.  Of course Joe was correct and the entire project was cancelled a few months later, good riddance.  Later, the entire "slot" was filled with what became RSTS but this was a totally different project with different people; just that DEC felt the -11 needed several different O/Ses for the -11, etc.  Joe became a consultant to many different companies, especially the small odd ones, and often had to create a P/S/8-like operating system just to do any work because these small outfits had no clue about software at all.  Hard to believe you could purchase a system akin to a PDP-8 with an RK8E/RK05 on it and the software only runs on punch-cards!  Eventually Lenny and Hank worked on the OS/8 BASIC releases, but on nothing else in any sense of the word OS/8; they were permanently disinterested in needless mediocrity, etc.​

 

​Richard Lary was himself hardly connected with the PDP-8 and was eventually moved to the hard disk controller section of the Colorado DEC disk engineering group.  [He still lives in Colorado Springs to this day.]  The very last thing he did was to add the FPP-12 emulator to the FRTR you are attempting to use [if you can get past the compiler differences].

Jack Burness slightly modified 4K BASIC into 8K BASIC which is quite useful in 8K unlike the 4K toy subset.  It is notable that this is the program "lifted" by Gates and Allen that became MS BASIC for 8-bit machines with an 8K ROM and 1K RAM.  [They couldn't get the code as efficient as on the PDP-8.]  The actual source code became obscure, but there is a horrible hard-to-read listing that is the result of a whole lot of document degradation, recopying, and it started bad on a known highly-out-of-alignment printer used on many then-current listing files; you can actually see the quality degrade as a function of the release dates of the various programs [apparently that cost-center didn't have a budget for equipment maintenance! ]  Thus, even if this were as good as it could get, it would still be hard to read, etc.

Despite all of this, I have been typing up the source code on a very intermittent basis for years, and I can see the light at the end of the tunnel.  The source validation is easily done [despite there being an entire page missing!] because fortunately, we have the binary paper-tapes to prove the source is proper, etc.  [Note:  There are two binaries:  One is 8K BASIC for any PDP-8 with extended memory; the other is LAB-8/E BASIC that supports some of the lab peripherals.  They never did a version for the PDP-12, but it would also be quite easy once I have the entire source code typed up, etc.]

The intention is to interface this with P?S/8 to support BASIC source code files, etc.  It is not clear how much memory will be required, because as in the case of the 4K version, pretty much all of memory is taken up by either the program token stack, variables, stack and the program digester and interpreter, the latter two are surprisingly small, and as it is typical Lenny Elekman code, hardly documented.  But time will tell as to how far I get, etc.

With some concessions to absolute maximum program size, I can perhaps get it to work in 8K, but the "cleaner" approach would be to use 12K to take advantage of the internal routines.  Since there is no actual BASIC source code, the LIST command has an amazing amount of work to do recreating what the source MIGHT have been, arbitrating the "rules" of "neatness" etc.  Not all of the details have been worked out, but it is clear that to recreate the source program requires at least an additional field, etc.  Some special accommodations will have to be made to avoid dual line numbers, etc.  But first things first, it is VERY TEDIOUS to type up the source code and then verity that the incremental work is correct, etc.  Realistically, this is a back burner project for 2018, etc.
​

It has been a few decades since I did some FORTRAN programming, so it will take a while to wake those neurons up.

​I probably stopped my brief encounter with Fortran BEFORE you started.  I didn't use it much at all because at Brooklyn Poly we developed the PLAGO PL/I subset.  Richard Lary wrote the "hairy" stack recycling routines that are so complicated and not able to be understood, there was a comment in front of the code to the effect DO NOT CHANGE ANY OF THIS!!!

The code always worked even as PLAGO grew in terms of the language features.  Richie did that little thing AFTER he and Lenny had toggled in the R-L Monitor System into the Poly straight PDP-8 belonging to the EE department.  I came there a few months later and was handed a working R-L DECtape by  someone who became my close friend soon thereafter; I basically abandoned the IBM 360 at that point.  [I was an "ordinary" EE student there for a while, but didn't know anything DEC until I stumbled upon this other system that used a model 33 Teletype, etc.  Changed my life forever.

Since we were the student chapter of the ACM, we volunteered to help users debug their code regardless of language.  Most of them were using WATFOR because it compiled so much faster [but ran slower].  It was in that role that I learned FORTRAN debugging their code and asking them language-element questions while I easily found most of their LOGIC problems.  Debugging is a technique that is essentially a universal skill.  The best way to find YOUR program bug is to ask someone else to look the code over, etc.

cjl​

[Dawson Rosell]

These are the contents of WHET.LS:

^C,MI^D0^P^E^F@^C ^^LG^C^B0TN^B@O@^D^BPX^T^B^A@^BP^OTE^B0@^B^P3@^B IC^B
0Q^TD^B@U@^A^BPW    ^D^O^BPRN^A^O^B^PPE    ^F^BP^P^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A ^A^C^XG ^A
^C^A ^A^B4^A 7^A^B:^A =^A^B@^A C^A^BF^A I^A^BL^A O^A^BR^A U^A^BX^A [^A^B
^^A A^A^BD^A G^A^BJ^A M^A^BP^A S^A^BV^A Y^A^B^BC^P^A^D^B@^B^F^C@^C^F^D^D
^G^F@^GP^^P    D^E
                   P@
                     ^F^G
                         PP^D1H^F^A@^B^D^BW\^B^X2^F^B^B^B ^C^B^B^F^B     ^B^B^U^B ^X^B^B$^B ^^^A
^C^C@^PI4^G^E3^P^E^DII^DN^W8^E^S%^O^ES(P1GJ@@ ^X2^F^A/)^E^C^C
^X@^Y%^O@^U/[VK@^P^P%^N@@^Q+P8^B=^F

This doesn't look right.

Charles, if REAL*4 is IBM propaganda, would I use just REAL? And then What about IMPLICIT? If functions require an argument, would I need to include a dummy argument? How would I do that?

[CLASystems]

On Thu, Aug 24, 2017 at 9:07 AM, Dawson Rosell <rose...@d.umn.edu> wrote:

These are the contents of WHET.LS:

^C,MI^D0^P^E^F@^C ^^LG^C^B0TN^B@O@^D^BPX^T^B^A@^BP^OTE^B0@^B^P3@^B IC^B
0Q^TD^B@U@^A^BPW    ^D^O^BPRN^A^O^B^PPE    ^F^BP^P^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A
^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A^A ^A^C^XG ^A
^C^A ^A^B4^A 7^A^B:^A =^A^B@^A C^A^BF^A I^A^BL^A O^A^BR^A U^A^BX^A [^A^B
^^A A^A^BD^A G^A^BJ^A M^A^BP^A S^A^BV^A Y^A^B^BC^P^A^D^B@^B^F^C@^C^F^D^D
^G^F@^GP^^P    D^E
                   P@
                     ^F^G
                         PP^D1H^F^A@^B^D^BW\^B^X2^F^B^B^B ^C^B^B^F^B     ^B^B^U^B ^X^B^B$^B ^^^A
^C^C@^PI4^G^E3^P^E^DII^DN^W8^E^S%^O^ES(P1GJ@@ ^X2^F^A/)^E^C^C
^X@^Y%^O@^U/[VK@^P^P%^N@@^Q+P8^B=^F

This doesn't look right.

​That is some form of binary output, and yes, I didn't respond to that:

In general, OS/8programs take multiple passes to do things because they are "lazy" and do one thing at a time.  Let me give the example I do know, OS/9 PAL8 versus P?S/8 PAL versus the future P?S/8 SHELL XPAL.

OS/8 PAL8 has positional syntax in the way the command is decoded if PAL8 is the program requesting the command decode.  Thus, if you want both a binary and a listing, you have to specify two separate outputs and there has to be two different identical passes over the input.  The PAL language is by nature a two-pass assembly.  Pass 1 is just used to define the symbols in the program and NOT to generate any code.  Bear in mind, since the language supports literals, WHERE code goes determines the values of certain symbols, which can in turn depend on literal tables being properly defined.

This is a slight digression, but it is a warning that was issues by my late friend Jim Roth when he got to make some modifications to PAL8 that are immaterial to the assembly process.  [He wrote the original P?S/8 PAL assembly, the base code with no features, essentially a replacement for the paper-tape PAL III, and handed it off to me to add all of the "meaty" features that both PAL III and his early work lacked.  Today it is a superset of all of the other ones including LINC code generation for the LINC-8 and the PDP-12, and of course literals, etc.

If you are not careful, you can get into a pass-dependent situation where the value of a symbol can be pass-dependent and never actually generate any errors!  The language has no way to know if you do this, and it is essentially unfixable.  The problem is that if the value is a function of how many passes, then if you separately create binary and listing in two different passes, there will be no errors, yet the binary and listing CONTENTS will not match!  A user had complained about this, but the answer is you are asking the impossible given a multiple pass program.  Thus, the only way to get the values to agree is to do first pass 1 then 2 and later ANOTHER assembly with pass 1 and then pass 3, meaning the first assembly only produces binary and the second only produces listing, thus the same overall process is applied.  The syntax is too ""flexible" to prevent this, and the ONLY way to avoid it would be to have a one-pass language which fixes up after the fact with relocation and linking resolution in a post-processing linking program.  This is a common problem with compilers as a general subject.  The "solution" is to ALWAYS do things in a like manner, that way all results are the same.  [Of course there is no valid reason to create such code, but the user didn't realize this, and PAL is not a language you get any "crutches" to prevent you from making a fool of yourself, etc.].

In any case, P?S/8 PAL only does one or two passes, and if two, both outputs are created at the same time [if you ask for them].  In fact, unlike PAL8, P?S/8 PAL allows you to request pass 1 only!  This is useful in the early stages of development when there are many errors.  You get a summary of all symbols still undefined which is invaluable to a programmer, while clumsy PAL8 has no such facility.  Suppose you have 100 undefined symbols and on average they are used each in three places in the program overall.  The issue is that you haven't yet defined them, and unlike Fortran, NOTHING is implicit; you MUST define things either BEFORE you reference them, or worst-case by the very end of the first pass.  [The latter is allowed because a symbol could be such as the address of the first free location past a table; until the contents of the table are defined, you cannot know that.

What is actually done is every tine a symbol is encountered the first time but NOT in a defining situation, it is marked internally as undefined but does have stored a "value" which is actually just the address of the first encounter, not really the value.  When you get to the end of the assembly, hopefully a symbol defining circumstance was parsed, and if so, the flag of undefined is removed, and the value replaces in the defining statement, etc.  Thus, at the end of the assembly, you now know all the symbols that are STILL undefined by name, and a small useful feature, the first address in the assembly where the usage for it was encountered.

Thus, the way PAL8 does this, you have to get an entire listing and wade through it to locate the THREE HUNDRED ERRORS after waiting for the entire two or three pass assembly, and THEN using a text editor, wade through that entire lisiting seatching for the US [undefined symbol] lines to mentally resolve, etc.

In P?S/8 PAL, when pass 1 ends, there is the dumpout on the console of just the undefined symbols themselves in the small neat printout.  From that short printout you can then start fixing all of the problems and get the problem down to a dull roar.  One page of a printout can handle up to about 250 symbols or so, that is 250 or so symbols STILL UNDEFINED!    The other way is clumsy and stupid, and takes at least two passes and likely wastes paper [back in the day that is exactly what it did!];  Thus, this is why P?S/8 PAL has an option to prevent a second pass entirely.  You cannot suppress the errors at the end of pass 1, etc.  [Of course, you can do it the same hard way as PAL8, the point is you do not have to!]  During the second pass, if any, the same issues apply for both assemblers, but it's your fault if you forge ahead too soon, etc.

In general, the above situation doesn't happen, but the point is the language doesn't prevent the attempt that can get you into trouble because you cannot debug from a listing where the binary and listing do not match!  [Better you learn to not make that fatal blunder in the first place.  The problem might be something like using a literal whose contents is generated from an indirect process whereby you need to know the values of other symbols before hand.  Literal generation is inhibited during pass one, other than counting the places and creating the tables, then throwing them away, etc.  Thus, this is slightly oversumplfied, do not define a literal in terms of another value dependent on the same literal by circular logic, but the assembler cannot know it is circular, etc.

OK, back to the logistic.  [Fortunately, the above is rare, but when it happens, people get a rude awakening!]

In P?S/8 PAL, the situation is impossible.  The binary will ALWAYS match the listing, so you can rest assured you can figure out your problem from a level playing field always.  It SHOULD always be a given that if you are looking at a listing you see a perfect listing of what is in memory when your program loads [seems obvious, but....]

The reason P/S/8, a more primitive system can do this is because there is no handler for the listing output.  PAL works the same way as OS/8 BATCH.  If the device 66 LPT: is available, it is automatically used [also the same way DIAL works].  The listing cannot be sent to a definable handler in the ordinary sense.

However, P?S/8 supports a concept alien entirely to OS/8 called the Logical Console Overlay.  All output directed to either the system console or the lineprinter is redirected via logical calls into extended memory.   All conforming P?S/8 programs will redirect to the logical calls.  The exact configuration of the overlay is then responsible for where the output winds up as this is invisible to the callers, etc.  Thus, the output could be redirected [in theory] to the contents of an extended-length P?S/8 file [and then you would need to write a companion program to read it].  This is all nearly moot as the purpose of getting listing output is to actually LIST the output!  this is especially true in the SIMH environment where there is no actual real printer, but in fact it is a file, in the HOST environment.  IN PEPS for Windows, that can be post-processed into a PDF file [which in turn can be viewed or even printed, etc.]

Thus, the small  theoretical discrepancy is more than made up by the far more efficient overall process.  [Yes, it is rather pathetic that a 4K system can outperform an 8K system that was sloppily designed!].

When the SHELL is implemented, there will be another assembler for that environment dubbed XPAL.  It will of course largely be based on P?S/8 PAL.  In the SHELL environment, you still cannot open more than one file on a device, but there is no reason you cannot output to TWO files if they are on different devices.  [Note:  this is rather pathetic: OS/8 is all about multiple devices, yet you can only access one of them for output at a time!].  Thus, in XPAL, the binary goes to one file and the listing to another.  Thus, there is NEVER the need for two second passes, unless the system is so primitive it doesn't have a second device logical unit.  [Note: Just for ultimate flexibility, XPAL will have to known to perform a second pass a second time to another file if you opt for a single device for all output. It is theoretically possible, and then the proviso about pass-dependent code will apply, but it is expected such a system would hardly ever happen.  The anomaly mentioned above is not solved by always having only two passes, it is merely contained so you can debug it.  It is ALWAYS an invalid technique you have to gain expertise to know to avoid, etc.

Thus, P?S/8 SHELL will support a new concept of positional default devices, and the system will have to be configured accordingly.  OS/8 requires you to assign what device is DSK:  In essence, the P?S/8 SHELL will require you to define DSK1, DSK2, and perhaps DSK3, and they must all be different.  That way, a successfully parsed command will be able to pass to the program which devices can be simultaneously opened for writing, etc.  [Note: OS/8 could have had this, but just put that on the scrap heap of the hundreds of things wrong with OS/8!].  My work is to eliminate it, just not quite there [and I only have a staff of one person - me!]

Give all of my experience, but NEVER actually run a parted-out compilation of F4, what I am suggesting is that the sane positional notion applies here as well.  Thus, at the minimum, you need to change the command.  Place a comma BEFORE the output file tin indicate you want a LISTING as the output and not the binary.  [Of course you could have two files, but at this point you do not want to even look at the binary!].  In OS/8, a null section followed by a comma means you are leaving out that specification.  The OS/8 command decoder is generic, so I am  certain it will support the syntax, just not sure what will happen!  Try it.

​

 

Charles, if REAL*4 is IBM propaganda, would I use just REAL? And then What about IMPLICIT? If functions require an argument, would I need to include a dummy argument? How would I do that?

​I see no reason why the rest shouldn't work.  As I remember, it, Fortran works as if the statement IMPLICIT INTEGER I-N and IMPLICIT REAL A-H and O-Z are the defaults, and the syntax allows you to override that.  Also, DOUBLE PRECISION, etc.

IBM's previous computers were 18-bits, no bytes!​

 

​cjl​

[mpepper]

Regarding the issue with IMPLICIT and REAL ... it would seem you don't have the FORTRAN IV manual. If not, you can download it at 

    http://bitsavers.trailing-edge.com/pdf/dec/pdp8/os8/AA-H609A-TA_OS8_Language_Reference_Manual_Mar79.pdf

This volume contains multiple OS8 languages. FORTRAN-IV is from p 137 to 331. It is a searchable pdf.

REAL is a valid type and can be used before FUNCTION to declare the type returned. See sections 7 and 10. I may have missed it, but I do not see a way to declare a range of letters -- only individual symbolic names.

   Hope this helps.

     -maury-

[Michael Thompson]

PUTR runs OK on Windows 7 32-bit, but will not run on Windows 7 64-bit.

--

Michael Thompson

[CLASystems]

On Sat, Aug 26, 2017 at 9:26 AM, Michael Thompson <michael.9...@gmail.com> wrote:

PUTR runs OK on Windows 7 32-bit, but will not run on Windows 7 64-bit.

​That makes sense.  Virtually no one ever ran XP 64, so we don't even think about it.  And again, it cannot support anything such as diskettes where the real hardware has to be accessed instead of a fake virtual version of it.  The reason is this is beyond the standard logical calls.  It has to use the hardware making allowed changes to registers, etc. that only exist in the hardware.  The virtualized diskette interface only supports the standard calls, etc.  Thus, my need to support various other hardware diskette formats can only be done from the programs that venture forth at that level.  PUTR only gets to the directory level [which is bad enough] but there are programs that get even further down and can format disks with non-standard gaps.

But these have meaning in the DEC world for a bunch of cases.  The original widespread programs were written by the seems-to-have-disappeared author of Teledisk and some related programs such as CPM22.

Here is a ,multi part example that shows​

 

​some of the problems.

On paper, FDFORMAT for which we have the source code available, mostly Turbbo Pascal code, ought to be able to create RX50 diskettes for use with the Rainbow, DECmates II, III, III+, Microvax, some similar -11 models as well as the "professional" models [there are differences.  RT11 had to be modified to create programs just for pros that are a world apart from the "regular" -11s, and also an Omnibus-compatible controller from CESI that is essentually compatible with the OS/278 V2 handlers for RX50 that can be used on the 8/E, etc.  It's so obscure even I don't know the part number, but someone wanted Omnibus support so they did it.  The reason I don't know is that it didn't need software support per se except for one point:  All RX handlers of OS/278 are incompatible with all the other RC handlers for no good reason.  Thus, using those handlers means that all RC01/02/03 handlers won't work.  CESI didn't know that, but they never asked me in part because by then there were some "intenral" fights going on and I was in the middle of this with regard to the MDC8.  Not to digress too much, I had control of the stuff that OS/8 and P?S8 ran on, and they had control of the variant that ONLY OMNI-8 could use [optionally; OMNI-8 could run on standard DEC peripherals, and it could run on "my" variant, but admittedly their way was higher performance and they made the foolish mistake of needlessly creating the schism.  Had they not fought over the firmware, everyone could have used the same exact firmware, but, I on;ly worked for them, the horse has to come to the water and drink it, you can only lead it in the correct direction, etc.  Classic hardware people totally ignorant of software requirements wanting to wrest control from software people they had no direct control over, better to have lousy local control and poorer results than having to depend on others who knew better how to design the firmware in the first place, etc.  AGain, not my beef, but I did have to sorta take sides for various reasons.  But this was when CESI was going downhill; I was there before this whole little tempest started, etc.  Of course a GOOD businessman doesn't put all his eggs in one basket, but I digress.

In any case, the RX50 was used in many specific applications, mostly made by DEC, and all of them were slaves to pre-formatted diskettes because virtually all of them made no attempt to format.  And partially this was a valid point:  The RX50 was barely good enough to read or write diskettes.  You need an even better grade of drive to FORMAT as well.  It's the nature of jitter-prone devices, etc.  The earlier DSD-210 can format RX01 media because it uses a far better drive than DEC used, one of the SA-8xx family which were the best drives made at the time.

In any case, by the time this all mattered, PC-AT diskettes existed that were by nature better than the RX50 so formatting on them was reasonable, especially if you used the TEAC FD55-GFR or GFV.  Ironically, the DECmate III+ uses one of them, but only in the low-density mode, thus, the only difference between the DECmate III+ and everything else is it can read and write 20% faster and no other drive advantage even though it was an entire generation newer.  Those who understand the IBM 360K diskette versus the 1.2 MB diskette read/write/format problem when using the PC-AT or clones can understand the issues.  In any case, the RX50 format is a low-density format, but on a high track-density basis.  Thus, you could never format for an RX50 before the PC-AT drives were in use.

FDFORMAT can run on those latter drives, and the parameters allow the disk format of the RX50 or so it would seem.  I refer to the usual geometry issues, etc.  But the problem is you wind up with a disk format that can only be read or written on the actual PC!  For never fully analyzed reasons, these diskettes were hated on every actual DEC machine!

But the Teledisk author came out with CPM22, a program to read virtually ANY 5.25" CP/M-80 variation and there is special support for the DEC RX50.  Using CPM22, you can format [low-level] correctly for the RX50, apparently it makes special checks for the DEC 10-sector geomtery and does some arcane adjustment of parameters, etc.  The net result is a proper RX50 diskette with the bonus of a CP/M-80 directory on it.  [That is unimportant.  All RX50 can always be high-leveled to any format you want; that is simply a matter of writing directories, not formatting.  And of course it did mean you could get to a DECmate with the APU option some CP/M-80 files from other non-DEC systems, etc.

I use FDFORMAT as a format design tool.  There are multiple optimal formats for the DECmates because not all systems access the diskette the same way.  The most deficient is of course OS/8 because there is no room in the handler, etc.  But I can use FDFORMAT in a crafty manner to make diskettes that are "prre-staggered" in terms of sector order to overcome the poor format.  The net result is a diskette that is noticeably faster.  But it didn't work!

Enter Teledisk to the "rescue".  Teledisk makes image copies of diskettes noting certain obscurities of the format that change along the way. this often thwarts various copy-protect schemes.  For example, I have a Yamaha Disklavier and there are "copyright" protected disks versus the normal diskettes, which are 3.5" 720K PC diskettes at the low-level and totally different meaning at the high-level.  Track 0 side one of these disks ought to have sectors 1 through 9.  Copy-protected disks come in two variants:  On this track/surface is all the controls:  a) There is no sector 9, b) there is instead a sector marked 109.  I don't know why there are two different ways commonly in use, but I do know a copyrighted disk that fails to have the expected irregularities will be treated as an unformatted diskette entirely.  [A non-copy-protected disk has all sectors present and can be used for ordinary purposes.  The instrument itself can only empty the directory in connection with a complete low-level format that doesn't have any errors in the process.]

Using Teledisk you can freely copy these diskettes to image files and vice-versa.  While the data is read, a screen component indicates the irregularities as encounted, etc.

But something unexpected happened as well:  Passing my custom layout RX50 disketttes through Teledisk creates fully compatible RX50 diskettes!  My custom layouts are preserved, but the descendant diskette has whatever "gap" or other odd subtle difference resolved.  Whatever the issue is, he knew how to solve it!

Thus, part of my archive on ibiblio.org includes a sizable collection of RX50 diskettes in Teledisk format.  For the ones I custom designed, you get a better-than-original diskette in that when it is booted, the system on it either runs faster or boots up faster or both.  Thus, I have various non-standard sector order diskettes that are only optimal for the intended purpose.  [Note: It is difficult to run Teledisk because it can only run on SLOW machines!]/

There is a mostly-equivalent replacement program freeware now known as IMAGEDISK.  It also requires real access to the hardware, but the speed of the CPU is not an issue [as with PUTR] just have to have 5.25" diskettes.  [I use a a TEAC FD-505 combo drive, one 3.5" and the other 5.25" in the same half-height package.]

IMAGEDISK can work with RX50 disks fine, but I am not certain it preserves sector order considerations.  It also cannot do the Disklavier diskette trick.  So, it is of limited capabilities compared to Teledisk,.  As such, the claims by the IMAGEDISK authors should be noted as a bit optimistic.

My machine for copying these diskettes is actually faster than Teledisk ought to run on, but to make it work, I turn off both the level 1 and level 2 cache in the BIOS.  Then it works fine.  [And can be restored for all other purposes.]  Only for the benefit of the Disklavier, I also have an old IBM 960EL laptop which is a Pentium 133.  What I really want is an 970EL with a Pentium 166, as that is the fastest machine Teledisk runs on.  [When I get a chance, I will try to upgrade th e 960EL to the faster chip.]

I do have a few old Compaq chassis that came with Pentium 75 in them that should be able to work with a 5.25" drive if anyone is interested in this.  just have the clunky box, but in theory it should be able to take some old IDE hard disk, and I once used one of them to "obtain" some of the Disklavier diskettes, etc.  I am sure they upgrade to at least a P100 from looking at the on-board jumpers, etc.  I think Bob Vines might want one of them, but I believe there are three available, etc.

All of the above must run from Windows 98 Second Edition or less; they are real MS-DOS programs.

cjl

​

[Michael Thompson]

I found some example FORTRAN-IV programs on pdp-8.net and gave them a try on SIMH. They worked OK. I tried them on the PDP-12, and was surprised to see the MQ register count up while it was compiling. The programs looked like they were running, but there was no output. I will try them on my 8/e.

Sent from my iPhone