Some pontification about FIODEC chars

[Bill E]

There seems to be a general idea that the -1 uses FIODEC characters. It doesn't.

FIODEC chars are actually 8 bits. What it uses is 'concise' code, which is 6 bits.

These are what the macro assembler generates for (flexo, (char, and (text directives.

So, what's the difference? Essentially only that FIODEC adds a parity bit that guarantees an odd number of bits in the character. Concise is FIO & 037.

There is one minor difference, FIO does not support the Red and Blk character codes,

Concise doesn't support the FIO Stop Code and Delete characters.

Teaser - why I'm pontificating on this will be clear in a few +/- days.

Bill

[Bill E]

Uh, 077. Typo.

Bill

[Alen Shapiro]

Hi Bill,

I've had to come at this from an odd direction since the C -> PDP-1 Cross Compiler comes with no printf libraries and generates machine code using GASM (which employs ".ascii" that was not around in the PDP-1 design days). Just to get info out of the PDP-1 using the built-in char sets, I wrote a small C program that would just output Lower Case and Upper Case character tables. Here's a screenshot of the C-program output:

I crafting 6-bit integers and rotate through them for each available character, though, internally I'm also ORing in a 7th bit to indicate from which table the character will output from. The extra 7th bit indicates if the character should be preceded by a lower-case switcher (072) or upper-case switcher (074) character. The putc() code that outputs a character is:

void
pdp1_putc(int c) {
asm volatile ("lio %0" : : "r"(c) : "$io");
asm volatile ("tyo");
}

The odd little box at the bottom of the TTY screen output was crafted using two of the carriage-control characters in the Upper Character Set ('|' (056) and '_' (040)), and the "overbar" character (056) from the Lower Character Set. Those three characters do not advance the printing location when output to the emulated teletype. The C code uses a

#define TTY33

to accommodate the teletype carriage control. I leave TTY33 undefined when using simh to run the PDP1 code on a normal Pi terminal.

The actual C program code is here.

The actual need for this kind of putc() code was a stepping stone on the way to be able to output real ASCII strings in a C program e.g.

puts("Hello World!\n");

as well as printing numbers in base 2, 8, 10, and 16 so I could at least develop C debugging output. If it's of any use here are the current C functions that seem to work pretty well on both simh and the distributed PiDP-1 simulator.

main() looking like this:

void
main(void) {
pdp1_ascii_puts("\nHello World!\n");
for(int i=0 ; i < 20 ; i++) {
pdp1_puti(i, TEN_BASE);
pdp1_ascii_puts(")    = ");
pdp1_puti(i, OCTAL_BASE);
pdp1_ascii_puts("    = ");
pdp1_puti(i, TWO_BASE);
pdp1_ascii_puts("    = ");
pdp1_puti(i, HEX_BASE);
pdp1_ascii_puts("\n");
}
}

results in this output:

Here's the full C program.

No idea if this is of any use/interest.

Regards,

--Alen

[Alen Shapiro]

Oooops, "!" is not part of the PDP-1 character set. I changed the program to:

pdp1_ascii_puts("\n+++Hello World+++\n");

[Bill E]

Thanks for the info. My use case is that I'm implementing socket support via an IOT and of course the TCP/IP world doesn't use FIODEC or Concise.

Bill

[Alen Shapiro]

PDP-1 socket support would be amazing. With a socket layer there's a chance I could then get Mosquitto C-library for MQTT client running (perhaps I'll skip the socket TLS certificate stuff though), implementing C IOT code on PDP-1.

Now if only I could figure out why my C code is currently placed in high(ish) PDP-1 memory when generated as a .rim file.

Onward!

Regards,

--Alen

[Bill E]

It's coming. It's the implementation of my new version of the Data Communications System the -1 supported. I sent out a preliminary description a while back, that has changed significantly.

It's turned out to be a pretty complex beast but with a fairly simple one IOT interface.

Testing now.

Bill