Feature request: Support for remote TTY/3270 (and others) ports

[iblowmymind]

Hello, me again! Is the XNS remote TTY port interface documented? If so, would it be possible to write support for emulation of this behaviour? A Xerox 8000-series server can expose some of its local ports over network, so that other devices (e.g., terminal emulation inside a Xerox workstation) can connect to it. One use case for this would be to expose a configured TTY port (in Linux, a block device or in Windows, a named pipe or a physical serial port) through Dodo into a terminal emulator in ViewPoint. VP actually has a very wide selection of Terminal Emulators (even a 3270 emulator, that'd be fun to play with!)

Thanks!

[masinter]

https://github.com/Interlisp/medley also has both client and server chat (terminal programs) for Xerox Network Systems XNS.

[iblowmymind]

That could be a good point to start from as well! Does anyone have the Courier source for the network TTY impl.?

[masinter]

CHATTERMINAL.pfi.pdf CHATDECLS.pfi.pdf CHATSERVER-NS.pfi.pdf CHATSERVER.pfi.pdf

[iblowmymind]

Thank you for your assistance! I'll make sure to check through these documents to figure out how remote ports work. However, I do suspect that the Courier program for TTY will be needed at some point to provide a reference. I've looked through my local files but couldn't seem to find it.

[devhawala]

Back from holidays...

Seems that you mean GAP (Gateway Access Protocol, Courier program 3 version 3). Well, that's a big christmas wish :-)

Much to do in Dodo:

• create the GAP courier definitions for Java, after finding a usable source (GAP3.cr is incomplete, best bet will probably be the Lisp module NSCHAT or a combination of both)
• extend Dodo's Courier infrastructure to allow "borrowing" the underlying SPP-stream of the Courier connection as data connection between the client (e.g. Viewpoint) and the remote system (Unix or mainframe host)
  (i dont't remember where, but i have read that all data transfers run over the same SPP connection, be it the Courier calls for initiating and closing the end-to-end connection and the end-to-end communication itself: it's not a bulk-data transfer during a single Courier call, but somehow Courier temporarily releases its use ot the SPP connection; no idea how this is managed)
• implement the GAP Courier server module
• define and implement the Clearinghouse items necessary for presenting the available remote connections to the clients, this may not trivial as it is unclear what exact information (and how) the Clearinghouse must provide to clients for being able to use the GAP protocol for connecting to specific remote systems, e.g. an IBM mainframe vs. a Linux box vs. ...
• implement the connectors to the external systems like Linux or Windows logins or emulated IBM mainframes or ...

That's the things that come in mind first, with many smaller development items probably forgotten.

This will be a long road until one can play around with the Viewpoint terminal emulators. Maybe i find some time and motivation in the next year.

[iblowmymind]

Wow, that does seem like a daunting task... Has GAP been implemented in other projects that are re-implementing Services before? If not, this definitely will be a challenge.

For the missing parts (such as presenting remote connections), if we can't find any other solution, we could reverse-engineer the network packets by, for example, running a Services instance in Darkstar. However, that probably wouldn't lead to much, as Darkstar doesn't have an implementation of RS232 anyway, so we wouldn't be able to provide consoles for Services to serve. I could try running GVX in a Solaris VM in QEMU (like I tested previously), but that isn't going to lead to much, because as far as I can remember, it requires a special code generated by Xerox specialists to be able to initialize a network. Besides, even if it did work, it would certainly be painful.

Either way, thank you anyway for explaining it to me, lol! I'll try my best to contribute in any way, even if I haven't really investigated how Dodo's written. Happy holidays, and a happy new year to you!

[iblowmymind]

Hello, Hoping the AServices directory here can provide some help: https://mega.nz/file/EvQXEIiI#3_2godFKoPbnHkOD630P9BEVeYS2dzd7jhcY33j4HMI I don't think there's anything related to GAP, but there are useful impl's about filing.

[devhawala]

Hello,

just a quick note for announcing that the new version Dodo just uploaded now has External Communication Services, allowing to access real resp. emulated legacy external system via plain telnet (Unix-, VMS-machines or the like) or via tn3270-telnet (3270 lines on mainframes).

See the sections in the Clearinghouse documentation on TTY terminal connections and 3270 terminal connections for details on how to define and configure the port objects for the terminal emulations in ViewPoint or Star.

Greetings, Hans

[iblowmymind]

Oh, wow- really? I'd be extremely interested to hear how you managed to get the specifics of the implementation. My greatest of congratulations! I'll be testing it right now.

[iblowmymind]

Incredible!

[iblowmymind]

I have a z/OS system I could test, but it would take a while for me to set it up. Was 5250 supported too?

[iblowmymind]

dslisting...

[iblowmymind]

What are the PF keys bound to, by the way?

[iblowmymind]

Would emulating a Network Management Terminal Emulator be possible now, now that terminal services are in? Maybe even coupled with support for hot-editing the CHS members (without having to restart Dodo), it could be a really nice way of managing the CHS. I don't believe it has to be consistent in the way that commands and the syntax is laid out, as those are probably handled by the server side, but accuracy would be cool nontheless.

[iblowmymind]

Dialing bbs.fozztexx.com (Level 29 BBS) right now, works perfectly fine!

[masinter]

Medley has CHATSERVER and CHATSERVER-NS as well as CHATNS. I remember using it to talk to clearinghouse. Although we have Lisp clients for CHS as well.

I'm wondering if it might be possible to use the online.interlisp.org method of running without an install to let people try out Star. Put darkstar in a docker container.

Darkstar would be a lot faster if, rather than always emulating the microcode engine, you could "compile" the microcode to C and compile that.

[devhawala]

Hello,

for the PF keys: while in the 3270 emulator, press the "Keyboard" key (with Dwarf the "Alt" key by default) and then the "Show" function key ("F10" in Dwarf): this will open the Keyboard windows showing the current meaning of the keyboard keys; pressing the "Keyboard" key again while in the 3270 emulator will show the meaning of the 3270 special keys (while "Keyboard" is pressed), so "Keyboard"-1 is the 3270-PF01 key (in Dwarf: "Alt"-"1").

for the "5250" terminal: there is no 5250 emulator for Viewpoint and friends, as far as i know. This may be due to the fact that IBM introduced those mid-range systems (AS/400, S/36 etc.) in about the same time frame as Xerox did for Star, so these terminals were not known/used enough to develop/market such an emulator and hardware interfaces?

Hans

[iblowmymind]

I'm wondering if it might be possible to use the online.interlisp.org method of running without an install to let people try out Star. Put darkstar in a docker container.

If, say, Darkstar was written in C/C++, Emscripten could've been used to compile Darkstar to WebAssembly and make it embeddable in Web browsers. You can technically compile a full JVM to WASM using Emscripten and that can technically run Dwarf, but I bet it would be extremely slow.

[iblowmymind]

Hello,

for the PF keys: while in the 3270 emulator, press the "Keyboard" key (with Dwarf the "Alt" key by default) and then the "Show" function key ("F10" in Dwarf): this will open the Keyboard windows showing the current meaning of the keyboard keys; pressing the "Keyboard" key again while in the 3270 emulator will show the meaning of the 3270 special keys (while "Keyboard" is pressed), so "Keyboard"-1 is the 3270-PF01 key (in Dwarf: "Alt"-"1").

for the "5250" terminal: there is no 5250 emulator for Viewpoint and friends, as far as i know. This may be due to the fact that IBM introduced those mid-range systems (AS/400, S/36 etc.) in about the same time frame as Xerox did for Star, so these terminals were not known/used enough to develop/market such an emulator and hardware interfaces?

Hans

Ah, I see, thank you! I thought I remembered seeing 5250 emulation somewhere in ViewPoint, but it might just be my memory misleading me. I'll have to check again.

[iblowmymind]

An idea just came to my head: NetHub XNS driver for Win9K/NT? An XNS driver ships with GVWIN and that should work with NetHubGateway (haven't tested), but the driver only supports Win9K and the extra NT driver found in GVWIN 2.3 only supports NT 4. It could be an interesting experiment if we wrote a driver that directly interacts with NetHub without the official XNS driver and provide network services to GVWIN. It would both allow to run in newer Windows versions (say, XP) and would be easier to configure with a connection to NetHub.

[iblowmymind]

I did test with XP, and the XnsPkt driver only runs up to NT 4, not above. XP switched to the Windows Driver Model, whereas the XNS Packet Driver uses the NT 4 Networking, which was deprecated long ago. The driver at https://github.com/gcasa/Mesa/tree/master/Windows/Mesa1.0/Source/XNSDriver does install successfully, but isn't compatible with GlobalView. Perhaps we could write a driver based on this (but has native NetHub support instead of using a packet filter) that provides functions that GVWIN would understand? Will have to look into it when I can. Meanwhile, here is the driver that GVWIN 2.3 provides: DRVNT.zip

[iblowmymind]

Not sure if this is an error related to Dodo, but copying a TTY object from my CHS (that connects to the Level 29 BBS) in Star OS 5.2 on Darkstar and opening its prop's will cause a bugcheck, with the following 8-segment error code: 7530 0033 0636 0001 0394 0065 0535 (Uncaught signal, module global frame=033636 pc=0001 signal global frame=394065 signal index=535 word=(missing? idk if the docs for the MP are wrong). I was able to successfully connect on ViewPoint.

[devhawala]

Hello,

the problem may be in Dodo, as there is a bit of guessing when filling the fields in the CHS Courier objects returned for line types. Since ViewPoint can work with the TTY object, the CHS object for a TTY line seems not to be too wrong...

But StarOS and ViewPoint are however black boxes, so no idea of what exactly in the CHS line object is not satisfying enough for StarOS, as long as the signal name corresponding to "signal global frame=394065 signal index=535" is unknown.

Moreover the "pc=0001" is a bit suspicious, as it is highly improbable that a procedure fails in the first instruction: even it is really the first procedure in the Mesa module, the first byte of a procedures code (here at 0000) would be the frame length code, so 0001 would the first executable instruction byte, but a procedure usually starts with saving the arguments from the stack to the local frame, which is very improbable to fail by throwing a signal. But maybe i'm misinterpreting the pc part of the MP-code sequence.

Long story short: i think it's a StarOS problem,

Greetings, Hans

[iblowmymind]

Hmm.. I'll try to packet capture what happens when the terminal object is copied to the desktop both on GlobalView and on StarOS and see if there's any difference. I would also really like to experiment with network-debugging the Star using an XDE machine on, say, Dwarf, but I don't know if 1) Dodo requires special facilities for that or supports it, and 2) if we have the toolkit to debug StarOS 5.2, and if that toolkit even works on modern XDE versions that can be emulated (as the oldest XDE version we have that works is 4.0, and that correlates with the release of ViewPoint 1.0).

Network debugging in general would be really cool, though, as we do have the toolkit for GVWIN 2.2/2.3 (including Sword), but Dwarf crashes trying to run Tajo-in-BWS, and I can't connect newer Windows machines to Dodo due to a missing packet driver. I'll see in the following days when I'm free..

[devhawala]

Hello, i tried a TTY terminal connection with StarOS5 on my side, i get the same problem with a slightly different MP code sequence. Opening the icon copied from the divider opens the properties sheet and crashes, but not a single packet is sent by StarOS during that, so it seems to be a local problem with the data by the icon, sent by Dodo initially.

OK, then i tried to reproduce that with a debugger. You can find an early version of Sword in the Draco "xde5.0_2xTajo+hacks" disk, here's a recipe:

• before starting Dodo, create a "workstation"-CHS-entry your StarOS machine, with a name of your choice and the "machineId" of the Darkstar StarOS instance
• start Dodo
• prepare and start a Draco "xde5.0_2xTajo+hacks" machine, then log on in the XDE Executive
• start the StarOS machine, but do not open the TTY window yet
• the background menu of XDE, there is an "Interpreter" entry in the menu stack with a single "New interpreter" entry
• selecting the "New interpreter" menu will open a new Sword instance; the menu "client:" of the Sword window allows to choose the debug target, "remote" lets you enter the name of the workstation to debug remotely and clicking "Apply!" will let the debugger wait for the remote machine to request a debugger
• while Sword waits, there will be a "RETRY"-Icon blinking slowly in the HeraldWindow
• with a NetSpy opened in parallel, you can see that XDE sends "teledebug" packets (both socket and clientType) to StarOS (as the client to be debugged) and StarOS responds with "Error"/"NO_SOCKET" packets (correct, as StarOS still runs fine)
• BUT: trying to open the TTY window in StarOS to produce the problem will not enter the remote debugging session, instead it lets StarOS enter the MP-Code sequence produced by the debugger substitute (or whatever it was called in Star)
• the problem is that the local debugger substitute must be disabled by setting the appropriate boot switch(es) with the Installer (Othello), but the 911-trick for getting the command prompt of the installer (instead of the menu-guided mode) did not work with the StarOS installer floppy disk

So i'm a bit stuck there to get a debug session on StarOS. But i also suspect that debugging won't be useful without the matching symbol files for StarOS, as no module or procedure or variable names will be available.

So far for my experiments Hans

[iblowmymind]

Yeah, StarOS uses an older version of the Installer, meaning that "911" is not the shortcut to get into it. I remember there being one, I just don't remember how you get into it. I'll try to check it out.

[iblowmymind]

You have to boot with the install floppy, and run option 12. I think this (temporarily) sets the flags to disable local debug subst, and reverts them after run.

[iblowmymind]

Okay, so I did manage to get it to trap on remote-debug with a 0915, but my Draco doesn't seem to be picking it up... What now?

[iblowmymind]

I get no socket errors whenever system is running, but when I drop into a 0915 I get no replies from the machine. Why would this be?

[devhawala]

Hello, thanks for the tip with menu entry 12 of the installer floppy, i should have read all the list instead of simply trying 911, old habits...

So i managed to get a working debug session, but as expected, it is worthless without symbols (and even if...). Here's a screenshot of the call stack walk:

I think your problem is possibly that you try to use the main window of Sword to start the debug session. Instead, you should open a new interpreter with the desktop/background menu (see my previous post): this will create an iconized window "Debug.log" (at the same place as the Sword icon) and this window (Sword instance) is the one i used to start debugging.

If you open a NetSpy just before opening the TTY icon in StarOS, you will see that StarOS sends a "teledebug" packet. After starting the debug session, NetSpy will show a heavy traffic between both machines...

Greetings, Hans

[devhawala]

just to clarify: there must be a 'workstation' clearinghouse object with the correct machine-id (ethernet address) for your StarOS machine in the CHS database, in my case the workstation is called staros5, so the file in the CHS database is called ws~staros5.properties and has the following content:

#
# workstation
#

# description of the service
description = StarOS 5.x  unter DarkStar

# network address of the service
machineId = darkstar-Star

with 'darkstar-Star' being defined in the file machines.cfg (already defined and needed to slow down Dodo a bit for the Darkstar emulator).

And here's an extract of the NetSpy output with the the XDE debugger waiting for the StarOS machine going into MP 0915, with:

• ethernet address 10-00-FE-41-55-E2 is the XDE/Sword machine (Draco)
• ethernet address 10-00-AA-12-00-70 is the StarOS5.2 machine (Darkstar)

...
[31] => packet length: 60 -- at    271789.248400 ms

          => raw packet content:
              0x000 : 1000 AA12 0070 1000 FE41 55E2 0600 1D74 002C 0004 0000 004A 1000 AA12 0070 0030
              0x010 : 0000 004A 1000 FE41 55E2 703B 00F2 3CA3 0008 000B 0003 0001 0000 0000

          => ethernet packet header
              dst-addr : 10-00-AA-12-00-70
              src-addr : 10-00-FE-41-55-E2
              ethType  : 0x0600 (xns)

          => xns packet header
              ckSum   : 0x1D74
              length  : 44 bytes => 22 words
              transCtl: 0
              pktType : 4 = PEX

          => xns destination
              network : 0000-004A
              host    : 10-00-AA-12-00-70
              socket  : 0030 - teledebug

          => xns source
              network : 0000-004A
              host    : 10-00-FE-41-55-E2
              socket  : 703B

          => PEX header
              identif.  : 00F2 - 3CA3
              clientType: 8 = teledebug

          => xns PEX payload ( bytes: 8 => words: 4 )
              0x000 : 00 0B 00 03 00 01 00 00                          ????????

[32] => packet length: 92 -- at    271807.806799 ms

          => raw packet content:
              0x000 : 1000 FE41 55E2 1000 AA12 0070 0600 29B7 004E 0003 0000 004A 1000 FE41 55E2 703B
              0x010 : 0000 004A 1000 AA12 0070 0003 0002 0000 1D74 002C 0004 0000 004A 1000 AA12 0070
              0x020 : 0030 0000 004A 1000 FE41 55E2 703B 00F2 3CA3 1D74 002C 0004 0000 004A

          => ethernet packet header
              dst-addr : 10-00-FE-41-55-E2
              src-addr : 10-00-AA-12-00-70
              ethType  : 0x0600 (xns)

          => xns packet header
              ckSum   : 0x29B7
              length  : 78 bytes => 39 words
              transCtl: 0
              pktType : 3 = Error

          => xns destination
              network : 0000-004A
              host    : 10-00-FE-41-55-E2
              socket  : 703B

          => xns source
              network : 0000-004A
              host    : 10-00-AA-12-00-70
              socket  : 0003 - error

          => Error header
              ErrorCode : NO_SOCKET
              ErrorParam: 0x0000

          => xns Error payload ( bytes: 44 => words: 22 )
              0x000 : 1D 74 00 2C 00 04 00 00 00 4A 10 00 AA 12 00 70  ?t?,?????J?????p
              0x010 : 00 30 00 00 00 4A 10 00 FE 41 55 E2 70 3B 00 F2  ?0???J???AU?p;??
              0x020 : 3C A3 1D 74 00 2C 00 04 00 00 00 4A              <??t?,?????J

[33] => packet length: 60 -- at    273306.547799 ms

          => raw packet content:
              0x000 : FFFF FFFF FFFF 1000 AA12 0070 0600 866B 0028 0004 0000 0000 FFFF FFFF FFFF 0030
              0x010 : 0000 0000 1000 AA12 0070 0030 F0FA 00EB 0008 0000 0000 0000 0000 0000

          => ethernet packet header
              dst-addr : FF-FF-FF-FF-FF-FF
              src-addr : 10-00-AA-12-00-70
              ethType  : 0x0600 (xns)

          => xns packet header
              ckSum   : 0x866B
              length  : 40 bytes => 20 words
              transCtl: 0
              pktType : 4 = PEX

          => xns destination
              network : 0000-0000
              host    : FF-FF-FF-FF-FF-FF
              socket  : 0030 - teledebug

          => xns source
              network : 0000-0000
              host    : 10-00-AA-12-00-70
              socket  : 0030 - teledebug

          => PEX header
              identif.  : F0FA - 00EB
              clientType: 8 = teledebug

          => xns PEX payload ( bytes: 4 => words: 2 )
              0x000 : 00 00 00 00                                      ????

[34] => packet length: 60 -- at    273457.288899 ms

          => raw packet content:
              0x000 : 1000 AA12 0070 1000 FE41 55E2 0600 1D74 002C 0004 0000 004A 1000 AA12 0070 0030
              0x010 : 0000 004A 1000 FE41 55E2 703B 00F2 3CA3 0008 000B 0003 0001 0000 0000

          => ethernet packet header
              dst-addr : 10-00-AA-12-00-70
              src-addr : 10-00-FE-41-55-E2
              ethType  : 0x0600 (xns)

          => xns packet header
              ckSum   : 0x1D74
              length  : 44 bytes => 22 words
              transCtl: 0
              pktType : 4 = PEX

          => xns destination
              network : 0000-004A
              host    : 10-00-AA-12-00-70
              socket  : 0030 - teledebug

          => xns source
              network : 0000-004A
              host    : 10-00-FE-41-55-E2
              socket  : 703B

          => PEX header
              identif.  : 00F2 - 3CA3
              clientType: 8 = teledebug

          => xns PEX payload ( bytes: 8 => words: 4 )
              0x000 : 00 0B 00 03 00 01 00 00                          ????????

[35] => packet length: 572 -- at    273495.458999 ms

          => raw packet content:
              0x000 : 1000 FE41 55E2 1000 AA12 0070 0600 D6C9 022E 0004 0000 004A 1000 FE41 55E2 703B
              0x010 : 0000 004A 1000 AA12 0070 0030 00F2 3CA3 0008 0001 0004 0001 0000 0003 09F0 09F8
              0x020 : 06C4 0988 099C 09B4 09D0 0022 0850 0880 08B8 08FC 0036 003A 003E 0042 0046 004A
              0x030 : 004E 0052 0056 005A 005E 0062 0066 006A 006E 0072 0076 007A 0001 0001 0135 0BBF
              0x040 : 0000 0000 001F FB80 0000 0000 C400 FC20 0000 0000 0002 9080 0006 0006 0000 0060
              0x050 : 0432 0001 CE20 001C 0003 0432 000B CE66 001F 0430 8100 149E 001E 0460 0420 0000
              0x060 : FFFF 8000 0422 8000 0420 8000 0420 0000 CE42 0002 0000 0007 0000 0006 0000 0000
              0x070 : 0400 CE28 0005 CE30 0800 0002 CE5D 0002 CE5D 0000 0000 0006 0000 0000 0400 CE28
              0x080 : 0000 0013 000F 0000 0103 0000 0000 0000 0000 017B 0000 FFFE 0000 0000 0000 0000
              0x090 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x0A0 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x0B0 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x0C0 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x0D0 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x0E0 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x0F0 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x100 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
              0x110 : 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

          => ethernet packet header
              dst-addr : 10-00-FE-41-55-E2
              src-addr : 10-00-AA-12-00-70
              ethType  : 0x0600 (xns)

          => xns packet header
              ckSum   : 0xD6C9
              length  : 558 bytes => 279 words
              transCtl: 0
              pktType : 4 = PEX

          => xns destination
              network : 0000-004A
              host    : 10-00-FE-41-55-E2
              socket  : 703B

          => xns source
              network : 0000-004A
              host    : 10-00-AA-12-00-70
              socket  : 0030 - teledebug

          => PEX header
              identif.  : 00F2 - 3CA3
              clientType: 8 = teledebug

          => xns PEX payload ( bytes: 522 => words: 261 )
              0x000 : 00 01 00 04 00 01 00 00 00 03 09 F0 09 F8 06 C4  ????????????????
              0x010 : 09 88 09 9C 09 B4 09 D0 00 22 08 50 08 80 08 B8  ?????????"?P????
              0x020 : 08 FC 00 36 00 3A 00 3E 00 42 00 46 00 4A 00 4E  ???6?:?>?B?F?J?N
              0x030 : 00 52 00 56 00 5A 00 5E 00 62 00 66 00 6A 00 6E  ?R?V?Z?^?b?f?j?n
              0x040 : 00 72 00 76 00 7A 00 01 00 01 01 35 0B BF 00 00  ?r?v?z?????5????
              0x050 : 00 00 00 1F FB 80 00 00 00 00 C4 00 FC 20 00 00  ????????????? ??
              0x060 : 00 00 00 02 90 80 00 06 00 06 00 00 00 60 04 32  ?????????????`?2
              0x070 : 00 01 CE 20 00 1C 00 03 04 32 00 0B CE 66 00 1F  ??? ?????2???f??
              0x080 : 04 30 81 00 14 9E 00 1E 04 60 04 20 00 00 FF FF  ?0???????`? ????
              0x090 : 80 00 04 22 80 00 04 20 80 00 04 20 00 00 CE 42  ???"??? ??? ???B
              0x0A0 : 00 02 00 00 00 07 00 00 00 06 00 00 00 00 04 00  ????????????????
              0x0B0 : CE 28 00 05 CE 30 08 00 00 02 CE 5D 00 02 CE 5D  ?(???0?????]???]
              0x0C0 : 00 00 00 00 00 06 00 00 00 00 04 00 CE 28 00 00  ?????????????(??
              0x0D0 : 00 13 00 0F 00 00 01 03 00 00 00 00 00 00 00 00  ????????????????
              0x0E0 : 01 7B 00 00 FF FE 00 00 00 00 00 00 00 00 00 00  ?{??????????????
              0x0F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x100 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x110 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x120 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x130 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x140 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x150 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x160 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x170 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x180 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x190 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x1A0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x1B0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x1C0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x1D0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x1E0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x1F0 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ????????????????
              0x200 : 00 00 00 00 00 00 00 00 00 00                    ??????????
...

Remarks:

• packet 31 is XDE/Sword asking StarOS if it needs help
• packet 32 is the error response packet from StarOS
• (here i open the TTY terminal icon)
• packet 33 is the StarOS request for help (teledebug broadcast)
• packet 34 is again XDE/Sword asking StarOS if it needs help
• starting with packet 35 StarOS runs the communication with the XDE machine for the teledebug session

Hope that helps Hans

[iblowmymind]

I do have the workstation set-up, though, and XDE has no issues resolving the CHS name for the workstation and finding its numeric address. I'll try a bit more experimenting.

And I do use the interpreter, I had just tried it with the sword tool for that screenshot to see if anything changed :D

I do remember having some symbols but they're likely for GVWIN 2.3.

[iblowmymind]

Here's something cool that I just did. Connected to a CDC Cyber 875 running ICEM DDN, over Tektronix 4014. Better than any Tek4014 emulator I've seen...