Re: Creating several types from a base type and conversion

[Ken Roberts <alisonken1@gmail.com>]

On Saturday, January 18, 2020 at 4:30:15 PM UTC-8, Niklas Holsti wrote:

> Is it the AN/USQ-20? https://en.wikipedia.org/wiki/AN/USQ-20

Yep. although the systems I worked on were the 642A/B variants - the USQ-20 link posted showed the original 642 as designed by Sperry/Univac for the evaluation phase of the NTDS project.


> Ok, so there are no "half-word addresses" in the HW, so no half-word 
> endianness.
> 

The half-word addressing was to/from memory only - the actual hardware memory controller had an S register (30-bit) that was used for actual memory in/out transfers between memory and the rest of the machine, with Zu and Zl (both 15-bit) registers that would then be taken from/placed into the S register for the actual memory transfer.

> Your other posts suggest that the manuals used little-endian bit 
> numbering, so I assume you will use the same bit-numbering order in the 
> record-representation clauses. You should then specify the Bit_Order 
> aspect as System.Low_Order_First for those record types.
> 
>  From your other posts, it seems the practice was to store five 6-bit 
> characters in a 30-bit word. There must be some "endianness" convention 
> here: is the first of these five characters stored in the high bits of 
> the word, or in the low bits? If the HW does not support character 
> addressing, this endianness convention was defined and implemented by 
> the SW running on the computer, and so does not have to be considered in 
> the emulator per se.
> 

The original program spec was to use CMS1 programming language later updated to CMS2 language. I didn't have access to the CMS compiler or even a system that could compile, so I worked directly with the 642 via the teletype.

I actually had to dig into the microfiche (it was rather nicely laid out - 1 microfiche slide per module, each formatted with CMS code immediately followed by the 642 machine code). there was a separate routine that was invoked to pull the characters out of the machine word and format for the intended device.

IIRC - the routine basically did:

- RJump to unpack routine
- Read next address into A
- Loop until end  -- Word loop
-   loop 5  -- Character loop
-     Circular left shift A 6
-     Logical AND A & 8#77#
-     Convert A to appropriate character for output device
-     Shift A to place character into correct bit position for output device
-     Masked OR with A and output buffer word being assembled
-     Store A to buffer
-     end loop -- Character 
-   Read next address & check for end of output
-   End loop  -- Word
- Return jump to (RJump + length of output) for next instruction

Note the output could either be 

- 5-bits (1 character) per word for teletype
- 30-bits (1 character plus position location bits) per word for PPI
- 30-bits (3 character) per word for ACRO (Auxiliary Crt Read Out)

> >>> For most stuff, memory will be returning either DataWord or
> >>> InstructionWord for each memory access, but I'm also looking at an
> >>> easier way to manage characters for text display on the emulated
> >>> monitors.
> >> I would assume that in the original system, the diplay of characters on
> >> the monitors was implemented in the SW programs that ran on the emulated
> >> processor. Why should the processor emulator do something special for
> >> this? Did the monitors display data directly from "display buffers" in
> >> the 32K memory, using DMA?
> 
> > The "display" part was either an old-school teletype machine (using
> > 5-bit characters)
> 
> I assume that the SW in the machine was responsible for sending the 
> characters to the teletype, one by one, so the method for storing 
> characters in words was a SW convention, right?
> 

Correct - see above for the approximate routine that was used. The formatted output was placed into an output buffer, then output was initiated with I/O instruction that used the output buffer start/end memory addresses.

The NTDS computer used a memory address for buffer control that was initiated with an I/O instruction and formatted as:

(I/O base address + channel number) : Mu == current output address, Ml == final output address. When memory detected Mu == Ml, then depending on I/O instruction used, would terminate the buffer, or terminate buffer and generate an interrupt to the computer.

I/O was handled asynchronously and the memory controller had interrupt priority for what section of the computer received the next memory access. The hardware was rather interesting in how memory was setup and controlled - it appears to have a lot more control than the current memory schemes, but with core memory (mini rings of magnets with wires running through them), timing and control was rather interesting.


> > or a CRT that was a combination radar repeater/computer symbology
> > display unit with attached 15 line X 65 character text display using
> > a really interesting 30-bit layout.
> That sounds like possibly involving a HW-defined lay-out of characters 
> in words. If you emulate this CRT, you may have to implement that in the 
> emulator.
> 
> > (reaaalllly long URL from google reposted via bit.ly)
> > 
> > http://bit.ly/368sGgl  Picture of computer I'm trying to emulate.
> 
> Looks very much like the AN/USQ-20. And the acronym "NTDS" matches 
> "Naval Tactical Data System", check.

Yep.

There was also a secondary 18-bit computer in use that the 642 talked to, but that's a different project.

> 
> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .