Should instructions trash the AC?

[dfe...@gmail.com]

Hi, all.

I am playing with Rob Doyle's PDP8 implementation in VHDL (thanks, Rob!)
and have added an IOT that does stuff with what's in the AC. In order to
"fit in", should my instruction clear the AC afterwards like DCA or is
it OK to just leave the contents alone?

Cheers.

[Klemens Krause]

Typical IOTs don't clear the AC. For example a TLS-instruction (Teleprinter
Load Sequence) puts a character to the serial line and keeps it in the AC.
There are even input instructions which don't clear the AC.
KRS (Keyboard Read Static) does an inclusive OR with the content of the AC.

What's happening, depends to the interfaced device. It has access to the omnibus
control lines and can clear or increment or "OR" the AC-contents with data
from the omnibus lines.
I think there is no standard.

Klemens

[David Evans]

In article <kiefuo$gtn$1...@inf2.informatik.uni-stuttgart.de>,

Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
>dfe...@gmail.com wrote:
>>
>> I am playing with Rob Doyle's PDP8 implementation in VHDL (thanks, Rob!)
>> and have added an IOT that does stuff with what's in the AC. In order to
>> "fit in", should my instruction clear the AC afterwards like DCA or is
>> it OK to just leave the contents alone?
>>
>Typical IOTs don't clear the AC. For example a TLS-instruction (Teleprinter
>Load Sequence) puts a character to the serial line and keeps it in the AC.

Yes, I saw this, but I wondered if it is an aberration or the norm.

>There are even input instructions which don't clear the AC.
>KRS (Keyboard Read Static) does an inclusive OR with the content of the AC.
>

Yeah!

>I think there is no standard.
>

Cool. As I can make my instruction do whatever I want, if there is no
standard then I'll just leave the AC alone. That makes things easier for
the programmer, anyway.

Thanks!

[Klemens Krause]

David Evans wrote:
> In article <kiefuo$gtn$1...@inf2.informatik.uni-stuttgart.de>,
> Klemens Krause <kra...@informatik.uni-stuttgart.de> wrote:
>> dfe...@gmail.com wrote:

....

>
>> I think there is no standard.
>>
>
> Cool. As I can make my instruction do whatever I want, if there is no
> standard then I'll just leave the AC alone. That makes things easier for
> the programmer, anyway.

Yes primary all 6000-Opcodes are NOPs. Everything that is done is done and
initiated by the addressed IO-device.
Normally there are 3 bit function codes (bits 9-11) and 6 bit device select
codes (bit 3-8). Naturally there exist standards for IO-devices and also for
processor extensions. The interrupt system and the memory extension unit are
also controlled by "IO"-intructions.
But it would be easy to make an IOP which puts AC-contents to a stack and
get them back from there. This is done in the H 6120 single chip PDP8.
Or you could make a device for vectored interrupts and so on.

Klemens

[cjl]

First define your purpose.

If you want to make something easier for the programmers, model something that exists that is analogous to what you wish to interface.

For example, if an input device that takes in serial data meant to be asynchronous, expect the program to access it one 7/8-bit character at a time, then you need to implement all of the following to make any sense:

6xx1 - Skip on the input flag is set. Do NOT do anything else.
6xx2 - clear the input flag and the AC. This allows it to be microprogrammed with the other instructions.
6xx4 - .OR. transfer data into the AC. Note: The data is that associated with the reason the input flag raised. This expressly is NOT a license to get new data; in fact NEVER do that.

6xx6 is thus clear the input flag and load the data into the AC.

Why the seeming complications? The simple answer of course is: BECAUSE.

Programmers who really know the keyboard interface used every smidgen of the hardware. Control-C etc. checking is based on the notion of maintaining the flag so it can be re-read by another program. The buffer will be checked for say control-C by reading with the 6xx4 instruction by an .or. transfer; the flag is NOT disturbed by doing this.

The whole reason for all of this is because the major basic tenet of PDP-8 operating systems is only the "kernel" is resident, meaning the system device handler, which will bring in other code to process this situation than was that which detected it. The basic non-resldency of the operating system thus requires a way to know that it was brought in by a hasty exit, not a normal termination because the program ran out of stuff to do, etc. Thus, the notion of a logical abort is implemented this way.

Again, my example is of a terminal input that is essentially a keyboard, real or emulated by another device pumping the data into the interface a character at a time.

Frill instructions have been added over the years; compatible software has to not depend on them, but custom software can embrace it.

6xx0 - clear the input flag; do nothing else. The seeming redundancy is because the real ASR-33 or ASR-35 teletype cannot help but read a character in on the reader by hardware design. But since that's not possible, clearing the flag just starts the reader up. The only way to NOT read the paper-tape is to leave the flag up. Interrupt-driven programs like FOCAL, 1969 cannot handle that. Thus, the KL8E and KL8-JA added 6030 - clear the keyboard input flag because if relevant 6032 cleared the flag and started the reader [and also cleared the AC].

Again, if this is not your device, don't worry about it. Also remember, that you cannot have an IOT0 on a negative or positive buss machine which means if your device needs it, it won't work on the older hardware.

6xx3 is essentially reserved for arcanity such as load the baud rate from the low-order 4 bits using the DEC standard baud rates. Likely used on the serial port associated with a printer or comm port such as on the VT78.

6xx5 is often something like interrupt enable the device per ac[11]. On the KL8 interfaces, this is a bit complicated because it affects both the input and the output, but an LPT output like a device 66 parallel could do that for itself alone. And on the KL8, the other IOT5 could be skip on an interrupt is coming from one or the other side of the dual-direction interface; the reason is to get past tty interrupts as quickly as possible to service higher-priority interrupts, and if a TTY is the source, take a little extra cycles to figure which one; lowers the worst-case latency on faster devices, but again, makes it dependent on the newer interface.

You rarely see 6xx7. On the older machines it is possible to decode it, but the simplest is the simple IOT1, IOT2, IOT4 approach because on the older bus they all are possible and can be combined, OR they can be partially decoded with a bit more effort; the most effort is needed to pick up that unique 6xx7, so by choice it hardly happened. Of course if you have an Omnibus or newer, all of these considerations are moot; all 8 instructions are equally easy to decode.

On the output side, the frill of 6xx0 is to set the flag unconditionally to "prime the pump" for the output routines. Again, not possible on the older hardware.

6xx1 is skip on output done flag and nothing else.

6xx2 is clear the output flag and nothing else.

6xx4 is output the character; thus 6xx6 is 2 then 4 combined in that order.

We already dealt with potential 6xx3 and 6xx5 frills above.

If you do this, you can be a console device and be compatible with all sorts of stuff like various handlers. Good software generally specifies the device codes to easily change definitions. But the instructions themselves have to match with expectations.

By all means possible strictly avoid what the RX8E and the DECmates do; it's poison and why OS/8 can never quite run on any DECmate and the variants that do, don't quite work [to varying extents]. Years ago, I bit the bullet and "got religion" with P?S/8 so all programs can always work also on a DECmate, but all the "soul" of the interface had to be removed to maintain dual-compatibility. [But P?S/8, unlike OS/8, totally supports control-s/control-q protocol; in OS/8 only the KL8E handler does, not anything else. Ask people who learned the hard way why they cannot use VT-100 unless the baud rate is slowed down to *minimize* the console splats; to eliminate them means running not much faster than an ASR-33.]

It was a lot of work to do it, and I regretted having to merely because some dimwits never asked software people what compatibility was needed; they copied the RX8E interface which is a really poor idea; it's a multiple-flag device short on instructions, so they made every one of them skip on and also clear the associated flag. So, some other dimwit thought that that was the prototypical interface instead of an aberration. It's just a hop, skip [and not a jump] to why all DECmates are incompatible.

[Note: To even contemplate fixing OS/8 the same way requires a) rewriting everything, b) trying to locate free bits in the system device handler area. a) is merely a major amount of work, b) is very little work that could take an infinite amount of time to implement.]

cjl

[cjl]

On Wednesday, March 20, 2013 4:34:19 PM UTC-4, dfe...@gmail.com wrote:

Just a little bit of further explanation:

The DECmate instructions that are incompatible IN THE HARDWARE are that all the skip on flag instructions are instead skip on AND CLEAR the flag, and the instructions that ought to clear it do nothing, or at most clear the AC or some innocuous other function that is besides the issue. Thus, at the minimum, it is impossible to have that logical abort condition because you are not capable of reading without the hardware knowing it to allow it to be reread.

to make matters weirder, the 6030 instruction SETS the input flag instead of clearing it! [What were they smoking?]. 6032 is pretty much nothing [maybe clear ac] 6036 gets a new character; could also hang for awhile at times in the control-panel memory trap until regular -8 mode starts again. The 6034 is now worthless; it's now re-read the character just read with no guarantee it was read the first time. And since there is no relevant flag set, it's now something diagnostics can use on DECmates, but no practical software. [Note: All of the even instructions 6030,6032,6034,6036 are trapped and emulated, so don't even think you can reset the flag to mean what YOU want it to be. [Note: The dimwits didn't trap the ODD instructions, so you cannot even change the slushware; way to go, wingnuts!]

In P?S/8 I have a worse time because it supports TWO logical aborts:

1) Control-C abort and jump to 07600 to reboot. [Pretty much the same as OS/8 and everything else]

2) Control-B abort as above, but when the system reloads, not only realized the program aborted, but the BATCH should also be aborted.

Thus, I had to scramble for two bits [which with effort I found]. So, when the keyboard monitor reloads, all the following might happen:

1) Input flag up? If so, check for control-C and also control-B; abort accordingly.

2) Flag not up? Try the two logical abort bits, the one for control-C first. If either set do as above.

The code to check stuff is not the problem; any decent system has once-only code in it. But the entire system resident is 07600-07777 and over the years pretty much everything is reserved. [Ditto for OS/8, thus the problem there.]

But I did find a few bits, in fact I even found a few more more recently and will implement a few more goodies.

Again, no one asked anyone that mattered about what was acceptable and what was not. When something is almost compatible hardware, the realistic expectation is that the software will ALMOST RUN on it, but not quite. And that is exactly what happened. [Note: OS/278 V2 ODT; never hit LF; it makes the machine hang; of course it's pretty hard to actually make USE of ODT without the LF command, but that's what's so great about software that ALMOST runs! It's so much fun getting surprises about what does and doesn't work!]

[David Evans]

In article <be48cf6e-e4cc-48f3...@googlegroups.com>,

cjl <clasy...@gmail.com> wrote:
>On Wednesday, March 20, 2013 4:34:19 PM UTC-4, dfe...@gmail.com wrote:
>> Hi, all.
>>
>>
>>
>> I am playing with Rob Doyle's PDP8 implementation in VHDL (thanks, Rob!)
>>
>> and have added an IOT that does stuff with what's in the AC. In order to
>>
>> "fit in", should my instruction clear the AC afterwards like DCA or is
>>
>> it OK to just leave the contents alone?
>>
>>
>>
>> Cheers.
>
>First define your purpose.
>
>If you want to make something easier for the programmers, model
>something that exists that is analogous to what you wish to interface.
>

[ Massive deletia. ]

Thanks, that explains a lot and makes me feel a lot less nervous. It is
conventions like these that made me unsure of what to do. Based on what
you wrote, once I can get back to PDP8 hacking, I can make my new device
a better citizen.

Cheers!