kaleidoscope source / executable in loadable format?

[Peter Peterson]

Hi all,

Does anyone know if there is a source file or executable of the PDP-12 Kaleidoscope that we could load over serial or from a disk image? Dawson looked a bit but didn't see anything.

We know it's not very long to toggle in, but that's still kinda slow for a demo. Right now we're planning to pre-load it, but that means that we have to make sure we don't do anything to blow it away before we want it. I thought it'd be worth an ask.

Thanks,

Peter

--

Peter A. H. Peterson, Ph.D.

Assistant Professor
Department of Computer Science

University of Minnesota Duluth

[Michael Thompson]

This is on your DEMO_12_NUMBER_1_Jan_4_72.linc tape image.

I will look through the RK05 pack images. I know it is on one.

/KALIED

/Starting Block Number: 0520

/Number of Blocks: 0001

*20

 /KALEID

 /PDP12 VERSION OF 

 /KALEIDOSCOPE

 /SCOPE PATTERN CHANGES

 /BY SAM7 + SAM10

 /PATTERN WILL CHANGE WITH

 /PREAMP INPUT INTO A-D 10

 /CREATED ON 7-12-69 BY

 /MICHAEL I. GAGE

 *4020

 LMODE

 A, LDA I

 0000

 SCR 0

 COM 

 ADM

 .+7

 BCL I

 4000

 STC 1

 ADD .+12

 DIS 1

 LDA I

 1777

 SCR 0

 ADM

 .-16

 ADA I

 -6377

 STA I

 0000

 DIS 1

 SAM 7

 STC .+3

 SAM 10

 ADA I

 SAM 7

 APO

 JMP A

 BCL I

 7774

 AZE I

 JMP A

 ADA I

 SCR 0

 STA

 A+2

 STC A+15

 JMP A

And a slightly modified one from the LCM:

The LCM binary is attached.

LINC    ORG       4020       Kaleidoscope                                    

4020    1020                                       LDA        I,00         Load AC, full register

4021    0000       variable                                HLT                         Halt

4022    0343                                       SCR        03           Scale right N places

4023    0017                                       COM                      Complement AC

4024    1140                                       ADM      00           Add AC to memory (sum also in AC)

4025    0034                                       xxx         xx           xxxx

4026    1560                                       BCL         I,00         Bit clear (any combination of 12-bits)

4027    4000                                       STC         0000       Store and clear AC (full address)

4030    4001                                       STC         0001       Store and clear AC (full address)

4031    2043                                       ADD       0043       Add memory to AC (full address)

4032    0141                                       DIS         01           Display point on oscilloscope

4033    1020                                       LDA        I,00         Load AC, full register

4034    1777       variable                                DSC        I,17         Display character on oscilloscope (2 x 6 matrix)

4035    0343                                       SCR        03           Scale right N places

4036    1140                                       ADM      00           Add AC to memory (sum also in AC)

4037    0021                                       XOA                       Extended Operations Buffer to AC

4040    1120                                       ADA       I,00         Add memory to AC (index class)

4041    1400                                       SHD        00           Skip: Right half AC unequal to specified half of memory register Y

4042    1060                                       STA        I,00         Store AC (index class)

4043    0000       variable                                HLT                         Halt

4044    0141                                       DIS         01           Display point on oscilloscope

4045    0103       0106                       SAM      03           Sample analog chan N

4046    4051                                       STC         0051       Store and clear AC (full address)

4047    0107       0107                       SAM      07           Sample analog chan N

4050    1120                                       ADA       I,10         Add memory to AC (index class)

4051    0000       variable                                HLT                         Halt

4052    0451                                       APO                       Skip: Ac contains positive number

4053    6020                                       JMP       0020       Jump to register Y

4054    1560                                       BCL         I,00         Bit clear (any combination of 12-bits)

4055    7774                                       JMP       1774       Jump to register Y

4056    0470                                       AZE        not         Skip: AC not equals 0000 or 7777

4057    6020                                       JMP       0020       Jump to register Y

4060    1120                                       ADA       I,00         Add memory to AC (index class)

4061    0340                                       SCR        00           Scale right N places

4062    1040                                       STA        00           Store AC (index class)

4063    0022                                       xxx         xx           xxxx

4064    4035                                       STC         0035       Store and clear AC (full address)

4065    6020                                       JMP       0020       Jump to register Y

 

--
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

[Peter Peterson]

Sweet -- thanks.

[Peter Peterson]

Hi Mike,

Thanks again for responding. I didn't mention the important detail that our demo 12 tape won't boot and may be corrupt. (Dawson tried to boot OS/8 from disk and then run DIR on LTA0 but it "moved the tape, positioned it at block 1 or 0 I assume, and then hung." So, our demo 12 image is probably not very useful. If there's a disk image including kaleidoscope that might be the easiest. Barring that, we'll toggle it in.

Thanks again,

Peter

[CLASystems]

I sent to Michael the original Kaleidoscope from the days of the LINC that is much like the one he listed [but it is not that version].

When I write code, my objective is to have VERY CLEAR SOURCE CODE DOCUMENTATION and most of these old programs lack that, because they were created on the original LINC systems with the tiny screen that discouraged commentary, etc.

As such, as source code quality of documentation and readability, even my DISASSEMBLIES of binary files usually far exceeds the original source.  In this case of course I had the crappy source code available to look at, etc.

That said, the code has to be capable of being assembled with P?S/8 PAL, and in this case with the dual LINC and PDP-8 mode option switch set.

P?S/8 PAL is generally a superset of the DIAL assembler.  DIAL does not support literals is the shortest answer why, but there are other issues.

The only thing not supportable is multiple-line TEXT files because that is a "cheat" that depends on the internal file format on DIAL.  As such, it has to be changed in a minor way to support the standard TEXT statements on each line.  this is a common problem others have had, etc.

For OS/8, there is a series of user-written dual mode assemblers all called "PAL12" yet they are NOT all the same!

I will assume the older version ought to be called V4; certainly the newer version proclaims itself as V5.  There are some problems:

V4 correctly assembles LINC code, albeit as a PDP-8 assembler it is quite bad; it was from the "dark days" of PAL8 before it got a good quick-fix that I personally asked for.  [Actually I got an apology from Richard Lary; he had assumed it was better than it was!  In those days, he was not working on OS/8 any more, and then later came back to do other OS/8 things such as the Fortran IV that could run without FPP-12 hardware by a simulation, etc. so it could be used on more machines, etc.]

I am working on larger projects such as the moidifications to MARK12 and PRTC12F that require a proper assembler in OS/8.  Years ago, I used the V4 version successfully with large projects on the LINC-8  For the record, there is only ONE BOOTABLE OS/8 LINCtape for the 8K LINC-8 with special hardware modifications. It is about 20 feet away from me [and staying there until the RICM PDP-12 can read it!]  On that tape are some important things, such as the OS/8 handlers for that system, a copy of OS/8 BUILD ready to go to boot a new system, etc. and a proper copy of V4.

What we have been able to find is unfortunately only an older version of V4, let's call it V4- .  V4- can assemble these large projects, but still gets errors because it totally lacks features; my guess it is was a work-in-progress preliminary version and apparently came out a few months before the final V4 [the one on the tape].

But unfortunately, there are many redundant copies of V5.  All of them do not assemble sophisticated dual assembly properly.  There is a fundamental disconnect of how to parse a LINC mode MRI statement that was fine in V4, etc.  I started working on the gargantuan task of severe surgery to these source files, but gave up in discust; too many problems and there are hundreds and hundreds of them and there are "families" of what/how to fix, etc.  It's a thankless task and I am deterring this to a time when I can get that tape read, etc.

All that said, V5 is perfectly adequate for these more ordinary assemblies.  As such, KALEID.PAL [or .12 if you wish] can be assembled with V5.  You will get a better source code file to list out, etc. and if yo wish, I can send you a PDF file of the output of either P?S/8 PAL pr V5 from the PEPS SIMH simulator for Windows, etc.  There are other games-oriented source files as well, etc.

Thus, I recommend using my file, and even attempt changes if you wish; it is more inviting to do so, etc. and you can run PAL12 V5 there on the serial-disk system.  The binary is of course tiny and can load quite quickly.

cjl

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

Bill Gates, 1992

[CLASystems]

NO!  This is wrong!  The demo-12 tape is a DIAL tape.  This is alien to OS/8 entirely.  If it is corrupt, it is not because of that irrelevant conclusion.  Keeo the three worlds of PDP-12 apart:

1) P?S/8 can interchange source files with the other two, but otherwise it is its own system, etc.

2) OS/8 and P?S/8 use the same LINCtape format, but ONLY those two, and they are not directly compatible with each other.

3) DIAL is thoroughly incompatible with the other two.  That said, there is a program on P?S/8 to interchange source files between DIAL and P?S/8 called L6DCON.  It includes its own handlers for only the LINC-8 or the PDP-12.  If attempted on any other machine it complains, etc.  Conversion is bi-directional and the default conversion area is the edit buffer on the DIAL tape [block 370).  An obscurity of DIAL is that you can AP [Add Program] to an absolute block.  You can start with an empty tape and use block 0000 in the AP command.  This is the trick that Jack Burness used to move the DIAL source files from the TOPS-10 system when he was developing them using a VERY obscure variant of the PDP-10 cross-assembler for the PDP-9, usually known as PAL10. This one is DIAL-compatible and is known as DIAL10.  There MAY be a surviving copy, but apparently most PDP-10 people are unaware of it, etc.  [Mike:  If we find the appropriate tape, it will be a PDP-10 DECtape you can read on your 8/E, etc.]

Thus, if you have all three systems, you can move the source files among all three.

But do not ever directly mix-and-match them, they are toxic to each other.

However, OS/8 cannot write on DIAL tapes at all, so you did no damage!

cjl

[Peter Peterson]

Ah ha!

Are there DIAL disk images? If so, could we boot that disk image and then access the tape? Perhaps this is all just silly -- if the tape is not bootable, who knows how much else is corrupted. Still, it would be fun to try.

Peter

[Michael Thompson]

We have two demo tapes, DEC-12-UXZC-U0 DEMO-12, and DEC-12-SEZB-U2 Demo Tape Part 2.

Once we can get the LINCtapes working on our PDP-12 we can make a copy of them.

--

Michael Thompson

[Dawson Rosell]

Charles, I was following the instructions in the demo12 manual, but I forgot about it being DIAL. I'll give that a shot, thanks! 

Michael, our Demo12 tape has a "#1" on it. As far as I know there isn't a second tape. I'll check tonight though. 

[Michael Thompson]

Our demo tapes are from 1971. Yours is a little newer and from 1972. It will be interesting to see what the difference is.

--

Michael Thompson

[CLASystems]

On Thu, Aug 10, 2017 at 1:58 PM, Peter Peterson <pa...@d.umn.edu> wrote:

Ah ha!

Are there DIAL disk images? If so, could we boot that disk image and then access the tape? Perhaps this is all just silly -- if the tape is not bootable, who knows how much else is corrupted. Still, it would be fun to try.

Peter

​This is an area of expertise for me where you separate the mens from the boyz.  All well-meaning people aside, only a few of us left who really know what is what in terms of good PDP-12 software etc.

What I want to do is create an image format that can get back to me so I can work with it on the SIMH simulator in either OS/8 or P?S/8 or both as required.

The most immediate way to do that is to get SOMETHING onto an RK05 image as defined by Kyle's/Adamson's server side on the PC which is deliberately identical to the .RK05 file as used on SIMH so we can all interchange stuff, etc.

That said, it does NOT have to be OS/8 at all!.

In fact, I expect to talk to Kyle here at home shortly about how to modify the server so I can more easily support P?S/8 than currently.

[Briefest possible explanation of the problem; it gives insight into the inter-system foibles that​ apply in these situations].

P?S/8 addresses all storage to the nearest logical 128 12-bit words on any supported device.  This allows things OS/8 cannot do, but it also means that some things kludged for the benefit are harder to do in P?S/8.  [Hard takes awhile; the impossible takes somewhat longer.]

The only reason OS/8 works at all on the RK8E [the real controller that uses the real RK05 disks, not to be confused with the .RK05 file format used by the SIMH simulator to support simulation of the RK8E AND also the format used on the SerialDisk server.] is that OS/8 is a kludge that wants certain things "both ways" and gets you neither.

The original goal was to cheat your way to support of a larger device.  In those days, the "largest" was the RK08 and RK01 drive.  [I worked at a place that used them.  A full cabinet of small M cards is the controller; the disk drive in another cabinet!]  These disks have a "smarter" interface and that is where the kludge was born.  On that former device, you can set a word count of how many words you want transferred.  If you read the first half, the other half is read by the controller to confirm the record checksum, but the second half doesn't transfer into memory.  If you write the first half, the checksum is at the end of the record, so as a consequence, the second half is written out with all zeroes.  The former contents is destroyed.]  So, OS/8 was kludged to work with that device as the "model" of what should be done, etc.

 But the RK01 is 1/2 the size of the RK05, thus, that stunt didn't quite work, but leaves us with all of the trade-offs none-the-less.   When DEC was designing the RK8E, Richard Lary had to "plead" with the hardware designers to have added a "transfer only the first half" bit or else OS/8 could not be implemented.  [Consider a core--image of locations 07500-07577.  That is a valid OS/8 core-image ,SV file.  If that also transferred the second half, the OS/8 system device handler is destroyed in memory!]   Thus, the 1/'2 bit was needed to make OS/8 work at all, but there are trade-offs.

1) To have a 12-bit number of 256 word records means that you need a two-page buffer to read or write everything.  Most programs need one to read while another to write by the nature of what most utilities do.  Thus, you need FOUR pages just for the OS/8 minimum even before you start considering the program code to implement it! To put that into perspective, there are only 32 pages in field 0 and the last one is always reserved in all viable PDP-8 operating systems.  Thus, 4 out of 31 is too big a fraction.  Nice if you want more buffers and the program is small enough, but not good to start from a compromised starting point.  This is why P?S/8 uses 128-word buffers.  That way, you only need TWO pages to accomplish the same thing.  [Not every program wants to in theory improve performance because it may mean the program cannot be achieved at all.  For example, P?S/8 BATCH runs in 4K and uses a 1 page input buffer.  OS/8 was designed without BATCH at all, and as such uses an ugly "external" kludge such that BATCH requires a minimum of 12K.  [Actually rather pathetic that a smaller system can do things a larger one cannot!.]

Generalizing, because P?S/8 only reserves field 0 07600-07777, the extended memory can supply as much as a 32 page full field buffer for input and output.  Programs that do raw read, copy and verify such as P?S/8 BLKCPY of course use the maximum buffer size if available, but will function at all even if you can only accommodate a 1 page buffer for in reading and another one page for writing, etc.

In OS/8, thus for all considerations taken together, you can only use the even pair sizes from 2,4,6,8 etc.but only up to 30.  The case of 32 is not allowed because of the x7600-x7777 restriction where x is any extended memory field [1 or higher depending on what you have].  P?S/8 allows ALL 32 values from 1 through 32 thus, utilities have better basic design freedom, etc.
|

Now admittedly P?S/8 system device handler addressibility via single-precision block numbers means at most 0000 through 7777 is half the storage space of OS/8 with the same range but of RECORDS of 256 words, but it still doesn't get you complete support of an RK05, so they "split" the drive into two halves, each about 2/3 of what OS/8 could address, but of course cannot do the entire device.

P?S/8 also has logical unit support for all handlers.  For the PDP-12 LINCtape system, that means that P?S/8 supports as many LINCtapes as the hardware allows, drives 0 through 7.  No handler has to be loaded at all, and why in many configurations P?S/8 runs so much faster than OS/9 [not universally true, just often so.]  Thus, actually the complete scope of addrsssibility of these handlers is four times as much as the OS/8 system device handler, just not all in one particular drive.

In any case, it is what it is in the case of OS/8, a stunted design caused by early management interference.  This is in part why P?S/8 continues to be developed.  [DEC REJECTED OS/8 because of idiotic management decisions not once but twice.  I later found out my friends at DEC were in an adversarial relationship with the idiot managers who rejected P?S/8 not for the benefit of DEC, but rather for spite as a "power play" against my friends, who were actively advocating for P/S/8 at the time[s]. ]

But P?S/8 goes further.  It uses non-system handlers as well, but for the present, the only program that does is the BLKCPY program as a stop-gap measure until the P?S/8 SHELL is working.  [Sometimes dubbed as "the OS/8 killer".]



The non-system P?S/8 handlers can support as much as 2048 times as much storage as OS/8 !  Thus, having the smaller minimum blocksize is not compromised while there is no trade-off at all in terms of larger device size.  As such, a viable configuration of P?S/8 is an entire RK05 cartridge as an entire device.

But how does P?S/8 run on the actual RK8E where you cannot properly access the drive to BOTH HALVES of every physical record?  The reason is that P/S/8 has RATIONAL code space sizes, i.e.m the handler can be written that does the job while OS/8 allows a measily at most 124 words more than what fits in field 0 07600-07777.

Thus, the method goes something like this:

There are at most 32 pages of memory/buffer transfers consisting of some combination of the following:

a) Starts with a read or write of the second half of the physical 256 word record.

b) some number of well-bounded double-pages that correspond to the physical nature of the RK05 geometry.

c) Ends with perhaps a read or write of the first half of a sector.

Any of the above may or may not be present; the handler has to handle all contingencies.

If a) and a read, read in the entire sector into a buffer within the handler.  The move the second page of the buffer to the caller'sbuffer.

If a write, then not only read in the entire sector, but then move the caller's buffer to the second page and them write out the sector.

If b) These are the routine operations that dominate calls statistically.  These are handled conventionally with no special considerations.

If c:, the if a write, read in the entire sector, and move the caller's buffer to the first page, then write out the entire sector.

If this is a read, in the specific case of the RK05, the read 1/2 bit being set is useful, thus nothing special.  In a sense, this is just normal extension to reading as in b) above.

The only consequence of all of this is P?S/8 cannot run in 4K as is usually the case [such as TC01/08 DECtape or PDP-12 TC12 LINCtape.  Extended memory is welcome and fully available to programs, but if 8K is required, then this is partially reserved.  [Note: Programs such as P?S/8 PAL are prepared to use another 3K if available; the 4th K is where the extended handler is, but the first 3K is available.  Also, any copying-oriented program can use 3/4 of a field for more buffer space, etc.]

Thus, this is the current P?S/8 system device handler for the RK8E/RK05 [and the corresponding non-system handlers work the same way].

For the PRESENT SerialDisk, this would have to be slavishly followed because the unit of storage is as in the actual OS/8 RK8E handler, and this is pointless because this is a FILE and not a physical disk!

As such, I will be asking for a modification so that the unit of storage is the 1/2 record 128 word block.  [Just because the real hardware has this restriction does in no way imply an alternate software based on an image format file has to follow suit.  Small changes to the OS/8 handlers I did the latest edit on are trivial, OR the scope of the server can be extended to work both ways, Their choice, not mine; either works for me, etc.

Once that is done, then not only OS.8 but also P?S/8 can support a program to use the backup format I am suggesting:

Using my 256 words/block LINCtape stand-alone subroutines [such as in LTBODT and L6DCON] read the DIAL tape blocks [also works for forerunner LAP systems from the LINC and LINC-8 thus has broad appeal].  Write raw to an .RK05 image that is mounted but NOT formatted for any particular operating system.

The easiest to do is to require OS/8 and load the non-system SerialDisk handler three, and write out to say the fourth disk that the server handles [I doubt if you are even using more than the first two, the original restriction of Ky;e's version].  That way, the first few blocks of the .RK05 file contain an exact image of the DIAL or related LINCtapes.  That file can be e-mailed to me and worked on in SIMH, and you can use it also for backup and restoration of particular tapes.  This method floats all boats!

The program is a small programming project for me.  Just cobbling up a bunch of code I've written before, just not quite in the same mix, but nothing new.

The largest issue is to define the way the program finds out what is the number of blocks on the tape.  Original LINC systems are only blocks 0000 through 0777 and are found on 150 foot reels.  DIAL tapes I gather are something like 3700 octal blocks.  Variations clearly exist.  [I have formatted DIAL-type LINCtapes to as many as 2000 octal blocks.]

Thus, the program has to ask for either the highest block or the total quantity of blocks [same info, slightly different interpretation].  Restoration will include internal information that will already know the requirements for restoration, etc.

Also, I would not lock down the format until it got kicked around by many,anyone with a bona fide interest, etc.  Conversions can be done on a one-off basis if need be until we have total stabilkity, etc.

Just so you know, I have been approached by someone who has historical archival copies of some of the original LINC operating systems on the actual tapes.  These need to be put online,etc.  As such, I have already put some thought into this problem, etc.

cjl

[CLASystems]

On Thu, Aug 10, 2017 at 1:58 PM, Peter Peterson <pa...@d.umn.edu> wrote:

Ah ha!

Are there DIAL disk images? If so, could we boot that disk image and then access the tape? Perhaps this is all just silly -- if the tape is not bootable, who knows how much else is corrupted. Still, it would be fun to try.

Peter

On Thu, Aug 10, 2017 at 12:51 PM, CLASystems <clasy...@gmail.com> wrote: