From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a05:620a:10a7:: with SMTP id h7mr39685523qkk.423.1579396048403; Sat, 18 Jan 2020 17:07:28 -0800 (PST) X-Received: by 2002:a9d:6557:: with SMTP id q23mr10868719otl.368.1579396048043; Sat, 18 Jan 2020 17:07:28 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!g89no11059287qtd.0!news-out.google.com!w29ni1711qtc.0!nntp.google.com!g89no11059275qtd.0!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 18 Jan 2020 17:07:27 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.136.24.151; posting-account=o_Y23woAAACPYGlDsFV1OivhygPNSoRn NNTP-Posting-Host: 47.136.24.151 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <06754867-2b4c-470a-ac42-98f3a56099d4@googlegroups.com> Subject: Re: Creating several types from a base type and conversion From: Ken Roberts Injection-Date: Sun, 19 Jan 2020 01:07:28 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:57892 Date: 2020-01-18T17:07:27-08:00 List-Id: 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 e= valuation phase of the NTDS project. > Ok, so there are no "half-word addresses" in the HW, so no half-word=20 > endianness. >=20 The half-word addressing was to/from memory only - the actual hardware memo= ry 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 regi= ster for the actual memory transfer. > Your other posts suggest that the manuals used little-endian bit=20 > numbering, so I assume you will use the same bit-numbering order in the= =20 > record-representation clauses. You should then specify the Bit_Order=20 > aspect as System.Low_Order_First for those record types. >=20 > From your other posts, it seems the practice was to store five 6-bit=20 > characters in a 30-bit word. There must be some "endianness" convention= =20 > here: is the first of these five characters stored in the high bits of=20 > the word, or in the low bits? If the HW does not support character=20 > addressing, this endianness convention was defined and implemented by=20 > the SW running on the computer, and so does not have to be considered in= =20 > the emulator per se. >=20 The original program spec was to use CMS1 programming language later update= d to CMS2 language. I didn't have access to the CMS compiler or even a syst= em 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 fol= lowed by the 642 machine code). there was a separate routine that was invok= ed to pull the characters out of the machine word and format for the intend= ed 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 devic= e - Masked OR with A and output buffer word being assembled - Store A to buffer - end loop -- Character=20 - 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=20 - 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 o= n > >> the monitors was implemented in the SW programs that ran on the emulat= ed > >> 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? >=20 > > The "display" part was either an old-school teletype machine (using > > 5-bit characters) >=20 > I assume that the SW in the machine was responsible for sending the=20 > characters to the teletype, one by one, so the method for storing=20 > characters in words was a SW convention, right? >=20 Correct - see above for the approximate routine that was used. The formatte= d 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 initiat= ed with an I/O instruction and formatted as: (I/O base address + channel number) : Mu =3D=3D current output address, Ml = =3D=3D final output address. When memory detected Mu =3D=3D Ml, then depend= ing on I/O instruction used, would terminate the buffer, or terminate buffe= r and generate an interrupt to the computer. I/O was handled asynchronously and the memory controller had interrupt prio= rity 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 wi= th core memory (mini rings of magnets with wires running through them), tim= ing 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=20 > in words. If you emulate this CRT, you may have to implement that in the= =20 > emulator. >=20 > > (reaaalllly long URL from google reposted via bit.ly) > >=20 > > http://bit.ly/368sGgl Picture of computer I'm trying to emulate. >=20 > Looks very much like the AN/USQ-20. And the acronym "NTDS" matches=20 > "Naval Tactical Data System", check. Yep. There was also a secondary 18-bit computer in use that the 642 talked to, b= ut that's a different project. >=20 > --=20 > Niklas Holsti > Tidorum Ltd > niklas holsti tidorum fi > . @ .