Kevin Savetz and I saw it. It's amazing that LCML owns multiple mind-blowing big iron from Cray, DEC, IBM, etc., and yet the museum director described the tiny Micral-N as "the rarest thing we own".

On 02/18/2018 04:17 AM, Adrian Graham via cctalk wrote: Wow, even a Bendix G-15 in there (although with Control Data logo). Talk about a restoration project!!! Jon

On 2/18/18 11:30 AM, Mark Linimon via cctalk wrote: on loan. there are supposed to be more in DC

Actually they have three. MARCH no longer exists. It's VCFed Mid-Atlantic chapter. :) I know of a few in private hands. And I know of someone who has two or three that he's looking to sell.

On 2018-Feb-18, at 11:30 AM, Mark Linimon via cctalk wrote: Paul Pierce has a G-15: http://www.piercefuller.com/collect/bendix/index.html Or he did, ca 2001. I would so like to be restoring a tube computer. How is Cory's LGP-30 project going, if he's reading?

On 2018-Feb-18, at 11:57 AM, Al Kossow via cctalk wrote: Oh, OK. I take it Paul downsized a fair bit. I think you (or someone) mentioned previously his 709 went to the CHM. Anything else of the big stuff?

On Feb 18, 2018, at 1:53 PM, Brent Hilpert via cctalk wrote: Looks like I spot Paul's LGP-30s there as well. Good for parts, but I understand the drums are unsalvageable. I'm at a temporary standstill with mine due to an issue with two of the recirc registers, problem believed to be at the drum. Unlike a lot of 'other' gear, I have to tread lightly on this stage of the troubleshooting and have been keeping my eyes out for the correct miniature Winchester connectors to be able to switch in/out the heads. So, not a lot of progress has been made since last spring, but I did bring the machine up last month to exercise the bearings and Flexowriter. Also fabbed-up and installed replacement 'wings' for the control panel which are missing from practically all of them, so it's at least looking better. Jurgen Muller's LittleGP-30 kit has been fun to put together, now I just need to brush up on my programming. I also had the fortune of seeing the University of Stuttgart's 100% functional LGP-30 this winter...some pics here: https://photos.app.goo.gl/d5UL8ps5eAkEdCPs2 -C

On Sun, Feb 18, 2018 at 11:55:04AM -0800, Josh Dersch via cctalk wrote: Well, get to work guys, I'd like to be able to sit at the IBM typewriter one more time, just for old time's sake :-) May I ask which serial numbers these are? mcl

What an amazing selection of hardware and software (people). Thank you for sharing your photos. Mark. On 18 February 2018 at 19:04, Jon Elson via cctalk <cctalk at classiccmp.org> wrote:

Here's another pile of photos. These are mostly of the basement and 3rd floor storage areas. https://imgur.com/a/ti86K g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!

would have been funnier if it said Mac Pro https://www.apple.com/mac-pro/ On 2/18/18 3:14 PM, alan--- via cctalk wrote:

although we have phillips ?broadcast ?gear! Love our ?LDK-20 camera and camera chains! ? Ed# ?www.smecc.org? ? ? In a message dated 2/18/2018 4:38:22 PM US Mountain Standard Time, cctalk at classiccmp.org writes: ? not allot of phillips stuff in north amarica is there? On Sun, Feb 18, 2018 at 5:29 PM, Angelo Papenhoff via cctalk < cctalk at classiccmp.org> wrote:

On Sun, 18 Feb 2018, Zane Healy via cctalk wrote: Zane, they've got a DPS-8 maintenance/operator/? panel sitting right out front. It's fully operational and is connected via some magic hardware to a Raspberry Pi running a Multics emulator. The guy that wrote the emulator gave a talk that should be the first one you watch once Erik has a chance to get the video posted. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!

whats invovled in makin an emulator? i have a chunk of stuff for the phillips p1000 On Mon, Feb 19, 2018 at 5:57 PM, Charles Anthony via cctalk < cctalk at classiccmp.org> wrote:

On Mon, Feb 19, 2018 at 06:36:13PM -0600, Adrian Stoness via cctalk wrote: I would say it depends a lot on how complex your target machine is. But in essense you will have to write code for each device you wish to emulate mapping their functionality over to your host machine, the one running the emulator. As a minimum you will write code for the CPU and some sort of output device, such as a serial console. For some machines you might need images of ROM code in order to be fully compatible with existing software. I wrote a PDP-8 emulator for fun. The basic CPU and serial was done in a few hours. I then hardcoded the paper tape loader in memory and allowed input to be read from an image file. Adding extended memory support and running conformance tests has taken the bulk of the time. /P

In order to connect to the outside world, you need a way to queue event based on cycle counts, execution of particular address or particular instructions. This allows you to connect to the outside world. Other than that it is just looking up instructions in an instruction table. Dwight ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Pontus Pihlgren via cctalk <cctalk at classiccmp.org> Sent: Tuesday, February 20, 2018 11:22:32 AM To: Adrian Stoness; General Discussion: On-Topic and Off-Topic Posts Subject: Writing emulators [Was: Re: VCF PNW 2018: Pictures!] On Mon, Feb 19, 2018 at 06:36:13PM -0600, Adrian Stoness via cctalk wrote: I would say it depends a lot on how complex your target machine is. But in essense you will have to write code for each device you wish to emulate mapping their functionality over to your host machine, the one running the emulator. As a minimum you will write code for the CPU and some sort of output device, such as a serial console. For some machines you might need images of ROM code in order to be fully compatible with existing software. I wrote a PDP-8 emulator for fun. The basic CPU and serial was done in a few hours. I then hardcoded the paper tape loader in memory and allowed input to be read from an image file. Adding extended memory support and running conformance tests has taken the bulk of the time. /P

On Tue, Feb 20, 2018 at 4:01 PM, Eric Christopherson via cctalk < cctalk at classiccmp.org> wrote: An emulator does not necessarily need to be cycle accurate. Some architectures have overlapping instruction execution, memory caches, I/O memory contention -- calculating cycles can be very complex. Other architectures, such as the DPS8/M do not seem to have left any documentation about cycle timing. The dps8/m emulator is coded for performance, not timing accuracy. -- Charles

interesting

stated: instruction I instructions in a still on For early machines like the Manchester baby AKA the SSEM and the Ferranti Pegasus its almost essential. Many of programs for these early machines rely on cycle times to produce predictable delays. So the SSEM noodle timer only works because the machine runs at 110Khz.. the the a few count been Davd

On Wed, Feb 21, 2018 at 8:52 AM, Ray Arachelian via cctalk < cctalk at classiccmp.org> wrote: the "DIS" instruction -- Delay until Interrupt -- which stalls the DPS8/M CPU until an interrupt or the Timer Register runs out. The Timer Register is set for 1/4 second. The emulator implements the DIS instruction by sleeping for 10 milliseconds, checking for I/O events, decrementing the Timer Register by 10 ms and checking for runout, otherwise repeat. The host CPU shows <1% usage for a idling Multics system. This configuration was arrived at through an iterative process of understanding how Multics uses the Timer Register and trying to figure out how to implement a 512KHz countdown register in software without excessive overhead. Writing an good emulation can require more then understanding the hardware -- the way the software uses the hardware can help make design decisions. Because Multics only uses the Timer Register for process scheduling, and the quantum is always 1/4 second, having a low-resolution timer was perfectly acceptable and easily implementable. -- Charles

On Feb 21, 2018, at 11:09 AM, Al Kossow via cctalk <cctalk at classiccmp.org> wrote: This is why I wonder if multithreaded emulation might be a reasonable future approach: Model more components of a system as operating independently as they produce and react to signals, have them block when not reacting (either to a clock pulse or a signal), and let the operating system manage scheduling. -- Chris

It depends on the machine being emulated. In some cases, multiple components that seem to be independent actually have tightly coupled timing, and software relies on that. For example, a CDC 6000 series mainframe has 10 or 20 PPUs plus one or two CPUs. With a bit of care, you can model the two CPUs using two threads. But all the PPUs have to be done in one thread because they run in lockstep. If you make them each a thread, the OS won't boot. I tried it and gave up. It would have been nice, it might have opened a path to a power-efficient emulation, but it didn't appear doable. Processors vs. I/O devices might work, but again the devil is in the details. paul

On 2/21/18 11:11 AM, Chuck Guzis via cctalk wrote: Synchronization at start of instruction fetch, DMA complete, and firing of an interrupt can hide a lot of timing inaccuracies. Finding idle loops can help with host processor CPU resource consumption.

That actually just came up for discussion in a donation review meeting this week at CHM. I don't know if they're that interesting w/o the software and documentation, and even then, these things were all locked down with licenses, except for the really early ones like Daisy and Valid. On 2/21/18 11:37 AM, Chuck Guzis via cctalk wrote:

We had a lot of ZyCAD stuff at ETA because we just had to drive a couple miles up the road to get it ;-) Lots of the ETA brass were buddies with the ZyCAD brass because they all came from ADL. We used it to simulate the ALSI 20K gate arrays before they were built. The gear we had was usually plugged into some Apollo headless nodes, which I think were Multibus backplanes?? and then accessed over the Domain network. Chris

On Mon, Feb 19, 2018 at 06:36:13PM -0600, Adrian Stoness via cctalk wrote: That depends on how accurate you want the emulation to be. A programmer of modest ability should be able to knock up a simple switch()-based step-by-step CPU emulation in a few hours. This is analogous to a simple microcoded CPU and the performance will suck. Making it *cycle-accurate* involves deep understanding of the emulated CPU's internal architecture. If part of the platform requires cycle-accurate timing for bit-banging some hardware device, you're going to need this. Making it *fast* also involves being an expert in compiler backends for the target architecture, because this requires decompiling and then recompiling the code on the fly. ... and that's the easy bit. Now you get to emulate the hardware.

On 02/19/18 19:36, Adrian Stoness via cctalk wrote: Quite a lot actually.? A single CPU system is difficult enough, but a mainframe might be much, much harder.? The idea to use an existing emulator framework, such as SIMH, is a great one. An easy implementation is to implement an interpretive CPU emulation at first, and then later on add other things such as JITs or caching. Does this machine implement microcode?? Do you want to emulate it all the way down to the microcode level?? Is microcode changeable by the OS/applications?? If not maybe implement the higher level (assuming CISC) CPU layer. There's a lot to consider.? The CPU(s), any co-processors, I/O devices/busses, peripherals/terminals, etc.? Are you going to emulate every co-processor in software, or is the system documented enough so you can emulate just the protocols that the main CPU(s) use to talk to those devices?? For example, many systems have some sort of storage processors.? You could emulate everything 100% in software, but for that you'd need disk and firmware dumps of everything.? Or, if the firmware on those is fairly fixed, just emulate the functionality. Are you planning on emulating the whole machine, or just the userland?? Might be easier to create a simulation of the OS in software on the host side the way that Executor did with MacOS - Cliff implemented his own version of MacOS 7.x, enough to be able to run most applications of that era, but not all.? see: https://github.com/ctm/executor.git and https://github.com/ctm/executor.git - some of this is called "High Level Emulation" and is sort of what WINE does (though wine isn't an emulator). You'll need to fully understand all aspects of the hardware of that machine, every detail.? If you have schematics and can read them, they can be an absolute gold mine as documentation sometimes is vague, and looking at the schematics and resolve what actually happens.? If you have source code for an OS, that too can be a great resource to help understand what happens and how. In terms of I/O. you'll be writing the reverse of what a driver will do - so if you have docs on how to write drivers for that machine, you're going to implement the hardware itself, in software, to match or connect to drivers on the system. Sometimes timing matters, sometimes it doesn't.? Where it doesn't, you have the opportunity to improve execution speed by running at full speed on the host. You'll have to do lots of experimenting.? Queues tagged with future events (i.e. at CPU_CYCLES+ONE_TENTH_THOUSANDTH_OF_A_SECOND, trigger IRQ # 3 ), are a good way to go, or you could go the hard way and implement a multi-process/thread emulator. You'll have to implement more than 90% of a working emulator before you'll even be able to see progress and know you're on the right track, because more than likely you won't get far enough to get anything starting to boot until that point.? Once you get there, you should implement a debugger for yourself and write trace log mechanisms throughout your code so you can turn on tracing at specific points to see what your code is doing, then sit there and read megs and megs of those logs until you figure out where it's going wrong vs actual hardware. If it's possible to write a CPU tester (and device testers) on the real thing, do that.? Run every CPU instruction through various edge cases, look at the resulting status flags and log all registers in/out to a database.? (This will easily be multi-gigabyte output). For example. say you have a shift instruction on a 16 bit word.? What happens when the register is 32 bits, and the carry flags are set and you do a shift left by 18 times?? Yes, that doesn't make sense, I know.? But an intel chip and 68000, and a SPARC, and a PPC, and ARM chip and a POWER4 chip all produce totallly different results with such inputs, so you can't assume it will just be handled by your host's CPU without a lot of extra work. And your emulator, if it's designed to be portable, must implement all those weird edge cases.? And if you don't implement a portable emulator, if it only runs on a current OS with a current chip, it will soon be obsolete in a few years.... After you've built your test suite, run your emulated CPU against this test frame, and flag any results that differ from what the physical hardware generated.? Repeat that process with device hardware such as tape drives, disk drives, etc.? Likely terminal emulation won't be too hard if standard stuff like vt100 are supported as you can use existing terminal emulators.? But other stuff will be hard.? Some, really, really hard.? Other things will be easy. Hopefully the documentation you have is complete enough to write a full OS from scratch on that machine, if it isn't, then you may have to do a lot of black box reverse engineering which is only possible if you have access to working hardware and lots of time. These are good resources to give you an idea of what you're in for: ? ?http://www.xsim.com/papers/Bario.2001.emubook.pdf ?https://fms.komkon.org/EMUL8/HOWTO.html ?https://www.reddit.com/r/EmuDev/ Good luck, you have a lot of work ahead of you.? If you can, I'd suggest the first step would be to scan all the materials you have, find a bunch of folks interested in your project and share it with them.? Be careful as there's a lot of "emu scene" folks out there with tons of free time, more than you might have, who will happily promise to help, but instead take your documentation, firmware, OS images, etc. and compete with you behind your back just to get there first, instead of actually helping you with your project.? On this latter point, I sadly speak from experience.

i dont think there is any physical hardware to test from left sept for maybe part of the front panel and a tape drive sitting in europe in museum and a couple random bit in some private collections drawings theres some but not allot. most of the known documentation is in dutch and from what i understand i have the largest chunk of surviving documents in english https://imageshack.com/a/img924/4649/oyprpu.jpg https://imageshack.com/a/img922/9277/19TwCI.jpg https://imageshack.com/a/img922/9277/19TwCI.jpg managed to aquire unused core sheets with this stuff was a nice bonus have to get them framed at some point https://imageshack.com/a/img922/841/kTGEiY.jpg ill give those sites a look On Wed, Feb 21, 2018 at 11:44 AM, Eric Christopherson via cctalk < cctalk at classiccmp.org> wrote:

On 02/21/18 12:44, Eric Christopherson wrote: D'oh!? Meant to point to the wikipedia article about it that describes how it works.? Sorry about that.? I guess I didn't hit Control-C in the browser hard enough. :) https://en.wikipedia.org/wiki/Executor_(software)

If microcode is not user-changeable, or if that capability is not a core feature, then you can easily omit it. That tends to make the job much easier. For example, I don't know that anyone emulates the PDP-11/60 WCS. The absence of that emulation isn't a big deal, unless you want to run the Richy Lary PDP-8 emulator on that emulated 11/60. (Has it been preserved?) Caching doesn't change user-visible functionality, so I can't imagine wanting to emulate that. The same goes for certain error handling. I've seen an emulator that included support for bad parity and the instructions that control wrong-parity writing. So you could run the diagnostic that handles memory parity errors. But that's a pretty uncommon thing to do and I wouldn't bother. Typically you'd emulate the I/O device functionality, regardless of whether that is implemented in gates or in co-processor firmware. That's the approach taken with the MSCP I/O device emulation in SIMH, or the disk controller emulation in the CDC 6000 emulator DtCyber. All those use coprocessors, but the internals of those engines are much more obscure and much less documented than the APIs of the I/O devices, and finding executable code may also be very hard (never mind source code and assemblers). For example, I have only seen UDA50 firmware once, on a listing on a desk in CXO back around 1981. Exact emulation is ideal, but often not necessary. What's required is emulation that delivers what the OS and drivers rely on. Devices may have undocumented features, and bugs, that aren't touched by the software that you care about. Just the documented features (from the programmer manuals) can often be sufficient, especially in well documented machines (DEC machines are examples of such, most of the time). Sometimes you get surprised by some OS. RSTS/E occasionally pokes at strange internals, perhaps to complain about a missing ECO that needs to be installed for the OS to be happy. Handwritten short test sequences are very helpful for this. While you'll need 90% or so for an OS to boot, you might need only 5% to test a few instructions entered via deposit commands. paul

Van: Al Kossow via cctalk<mailto:cctalk at classiccmp.org> Verzonden: woensdag 21 februari 2018 20:11 Aan: cctalk at classiccmp.org<mailto:cctalk at classiccmp.org> Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!) On 2/21/18 10:59 AM, Paul Koning via cctalk wrote: People have been searching for it for a while now, but it appears to have been lost. I have a WCS module for the 11/60 (and an 11/60 to go with it), but I have never seen the required software. I even forgot the names, something like ?microcode assembler? and linker. Are the assembler, etc tools available? The 11/60 microcode for the PDP8 emulation is not helping much either if the required tools are gone. Crazy idea ? I am repairing a dead 11/40 and learning a lot of how the CPU works. There are 256 microde instructions all 56 bits (IIRC, too lazy to check now). If you install the EIS or FIS, you get new microcode instructions on top of the standard 256. ?Copying? how EIS and FIS add their micro instructions could be the basis of an 11/40 ?PDP-8? add-on, just like EIS and FIS ? Yeah, I know, I started the paragraph with ?crazy idea? ?

Guy Sotomayor Jr via cctalk writes: I'd like to echo this, depending on the caching and the behavior of the system. In writing the 3B2/400 emulator, I was at first reluctant to write an accurate emulation of the MMU cache, feeling it unnecessary. I very quickly learned that it was not only necessary, but essential to a correctly running system. Moreover, it had to have the same caching algorithm as the real hardware to get UNIX SVR3 running happily. -Seth -- Seth Morabito https://loomcom.com/ web at loomcom.com

Van: Paul Koning via cctalk<mailto:cctalk at classiccmp.org> Verzonden: woensdag 21 februari 2018 20:37 Aan: Guy Sotomayor Jr<mailto:ggs at shiresoft.com> CC: General Discussion: On-Topic and Off-Topic Posts<mailto:cctalk at classiccmp.org> Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!) True, that is unfortunately a fairly common type of software bug. And because it is, emulators have to work around those bugs. I make it a point to call it a bug, though, because I don't want anyone to get the impression that OS programmers who wrote such things were doing the right thing. paul Yeah, I found that out when I was working on the PDP8/e emulation running on a 6809. OS/8 does that as well. After issueing the disk I/O it executes a few more instructions, because it ?knows? that the requested disk data cannot yet have been loaded into memory. I solved that problem with a counter that can be preset to some TBD value. The value defines the number of extra emulated instructions before it jumps to the (now) loaded data from disk ? at least, that is how I remember it doing over 10 years ago. I have an extensive webpage on pdp8 emulation on 6809. I succeeded in finishing it: booting OS/8 and running spacewr on it! Don?t ask how ?fast? it ran ?

Van: Pontus Pihlgren<mailto:pontus at Update.UU.SE> Verzonden: woensdag 21 februari 2018 21:15 Aan: Henk Gooijen<mailto:henk.gooijen at hotmail.com>; General Discussion: On-Topic and Off-Topic Posts<mailto:cctalk at classiccmp.org> CC: Paul Koning<mailto:paulkoning at comcast.net> Onderwerp: Re: Writing emulators (was Re: VCF PNW 2018: Pictures!) On Wed, Feb 21, 2018 at 07:44:33PM +0000, Henk Gooijen via cctalk wrote: While I too might consider it a bug and bad style. The OS/8 guys knew exactly what hardware they would support and probably gained some performance by doing it "wrong" Do you have a link to your work? /P Direct link: www.pdp-11/nl/homebrew/pdp8/pdp8startpage.html<http://www.pdp-11/nl/home… It is a long story! From the start to a working emulation with lots of debug facilities (as found on HP64000 development systems). But this emulation runs the pdp8 diagnostics without errors.

From: Guy Sotomayor Jr Sent: Wednesday, February 21, 2018 11:24 AM Also the method used by the KLH10 emulator (KS-10, KS-10/ITS microcode, KL-10). There, each device type runs in a separate fork, using System V style memory mapping. This of course means that it only runs under certain Unix variants. Rich

Guy Sotomayor Jr wrote: Hercules uses posix threads, not forks, however, each device does not necessarily get it's own thread. It's pretty portable stuff though. With very few tweaks, I run it on VMS. Regards, Peter Coghlan.

On Wed, Feb 21, 2018 at 1:59 PM, Paul Koning via cctalk <cctalk at classiccmp.org> wrote: I have long heard of the PDP-8 emulator that depends on the 11/60 WCS but every time it comes up, it's always been said to be lost. Feel free to prove me wrong, anyone. I'd love to stare at it. -ethan

A few more snippets of information: it was used by the WPS-8 development group in Merrimack, NH (a few cubes over from my first office at DEC). The host ran RSTS/E, and there was a RSTS "Runtime System" as part of the machinery. I've never seen any of the code; the brief description above is all I know. paul

On Mon, 19 Feb 2018, Charles Anthony wrote: I could have sworn someone said it was a Raspberry Pi. My apologies! g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!

I have to say that I hate this email thread abuse so much...! Is it so difficult to leave the thread about PICTURES (fill in whatever topic it was about) intact? It would be so much better to start a new thread instead: - Does not disturb original discussion. - Can be found and identified easily: Do you think that you will find the <blah blah emulator intersting blah> easily in a few years if it's discussed under the caption "VCF PNW 2018: Picture!"? And on the other hand there are those people who seem to be unable to create a prober reply to the list and therefore make threads appear scattered and broken into many many pieces... Sorry for ranting, but I enjoyed the pictures and following discussion so much and now encountering that dumb emulator discussion in this place annoys me so much...! And yes, I know that I sent this message as a reply to another message. Kind regards Philipp On 19.02.2018 15:44, geneb via cctalk wrote:

On Feb 21, 2018, at 9:39 AM, Pontus Pihlgren via cctalk <cctalk at classiccmp.org> wrote: I was one of the offenders. A list member politely pointed out to me (in private mail) the existence of the of the in-reply-to header which my client isn?t set to use. I had no idea! I?d been diligently changing subject: headers when I hijacked threads, but to no avail. So, apologies for my past bad behavior and I?ll try to do better in the future. I would encourage you though, rather than give up, just politely be more explicit about what is needed - it was ignorance rather than laziness in my case which was the problem. - Mark

On 02/21/2018 05:26 AM, Philipp Hachtmann via cctalk wrote: ;-) I suspect it's either people that don't know they are breaking threading or MUAs that behave badly. I'm on a list where it seems as if a frequent contributer uses an MUA that does not send In-Reply-To or References headers at all. It doesn't even send a User-Agent header. *sigh* I've taken to leveraging Mutt's ability to "link-threads" (&) and "break-thread" (#) to ""fix things and make the thread appear like I want in Thunderbird. I think your reply is in direct response to the message that it is replying to. So ? I think you're on the lighter side of gray here. :-) -- Grant. . . . unix || die

On 02/21/2018 11:06 AM, Adrian Stoness wrote: Mail User Agent I.e. email client. -- Grant. . . . unix || die

On 02/21/2018 02:05 PM, Fred Cisin via cctalk wrote: Well?. Not exactly. I could see how a loose connection could be made. Mail User Agents are often used to reach out and make first contact with people. I could see how a new MUA could justify using the name ?Omuamua. (Including the ?Okina.) -- Grant. . . . unix || die

On 19.02.2018 02:52, Zane Healy via cctalk wrote: I was looking through the pics and saw - nothing... But I also would be VERY interested about if and what Honeywell stuff they have.