Exploring The Bendix G-15’s Typewriter

The Bendix Corporation’s Bendix G-15 was introduced in 1956 as an affordable system for industrial and scientific markets. As with any computer system, a range of peripheral devices for input and output were available, which includes an electric typewriter. Produced by IBM, this typewriter was heavily modified by Bendix, with the version that [Usagi Electric] got their mittens on being equipped with a gigantic 28″ platen. With just power applied to the machine it will even still work as a regular electric typewriter, but it can do much more.

The bits that make an IBM electric typewriter into a Bendix G-15 accessory. (Credit: Usagi Electric)
The bits that make an IBM electric typewriter into a Bendix G-15 accessory. (Credit: Usagi Electric)

Most typewriters for the G-15 have a much smaller platen, as can be seen in the brochures for the system. The typewriter is connected together with other peripherals like plotters, card punches and tabulators via a coupler which uses a 5-bit interface. For the encoding on this interface no standard encoding is used, but rather 4 bits are used as data followed by 1 bit to indicate a command. In addition a number of other signal lines are used with the Bendix G-15, which allows control over the punch card reader and run status on the computer from the comfort of the typewriter’s desk.

In addition to the added electronics that communicate with the Bendix G-15, there are also solenoids and sensors which interface with the typewriter’s keyboard. This is what allows for command keys on the typewriter to be recorded separately along with the regular number and letter keys, in addition to the Bendix G-15 using the typewriter to automatically type on the paper. After a good cleaning session the typewriter’s basic functionality is restored, with the hope that once the Bendix G-15 over at the Usagi Farm can power up its DC circuit both will happily chat with each other. Color us excited.

Continue reading “Exploring The Bendix G-15’s Typewriter”

How DEC’s LANBridge 100 Gave Ethernet A Fighting Chance

Alan Kirby (left) and Mark Kempf with the LANBridge 100, serial number 0001. (Credit: Alan Kirby)
Alan Kirby (left) and Mark Kempf with the LANBridge 100, serial number 0001. (Credit: Alan Kirby)

When Ethernet was originally envisioned, it would use a common, shared medium (the ‘Ether’ part), with transmitting and collision resolution handled by the carrier sense multiple access with collision detection (CSMA/CD) method. While effective and cheap, this limited Ethernet to a 1.5 km cable run and 10 Mb/s transfer rate. As [Alan Kirby] worked at Digital Equipment Corp. (DEC) in the 1980s and 1990s, he saw how competing network technologies including Fiber Distributed Data Interface (FDDI) – that DEC also worked on – threatened to extinguish Ethernet despite these alternatives being more expensive. The solution here would be store-and-forward switching, [Alan] figured.

After teaming up with Mark Kempf, both engineers managed to convince DEC management to give them a chance to develop such a switch for Ethernet, which turned into the LANBridge 100. As a so-called ‘learning bridge’, it operated on Layer 2 of the network stack, learning the MAC addresses of the connected systems and forwarding only those packets that were relevant for the other network. This instantly prevented collisions between thus connected networks, allowed for long (fiber) runs between bridges and would be the beginning of the transformation of Ethernet as a shared medium (like WiFi today) into a star topology network, with each connected system getting its very own Ethernet cable to a dedicated switch port.

On Cloud Computing And Learning To Say No

Do you really need that cloud hosting package? If you’re just running a website — no matter whether large or very large — you probably don’t and should settle for basic hosting. This is the point that [Thomas Millar] argues, taking the reader through an example of a big site like Business Insider, and their realistic bandwidth needs.

From a few stories on Business Insider the HTML itself comes down to about 75 kB compressed, so for their approximately 200 million visitors a month they’d churn through 30 TB of bandwidth for the HTML assuming two articles read per visitor.

This comes down to 11 MB/s of HTML, which can be generated dynamically even with slow interpreted languages, or as [Thomas] says would allow for the world’s websites to be hosted on a system featuring single 192 core AMD Zen 5-based server CPU. So what’s the added value here? The reduction in latency and of course increased redundancy from having the site served from 2-3 locations around the globe. Rather than falling in the trap of ‘edge cloud hosting’ and the latency of inter-datacenter calls, databases should be ideally located on the same physical hardware and synchronized between datacenters.

In this scenario [Thomas] also sees no need for Docker, scaling solutions and virtualization, massively cutting down on costs and complexity. For those among us who run large websites (in the cloud or not), do you agree or disagree with this notion? Feel free to touch off in the comments.

PumpkinOS

PumpkinOS: A Modern Reimplementation Of PalmOS For Today’s Platforms

In a world where the personal digital assistant (PDA) has become yet another retro computing system, it’s always nice when experiencing the software for such platforms can be done in a way that does not involve hunting down original hardware of questionable functionality. Here PumpkinOS is a PalmOS-compatible project by [migueletto] which runs as a regular application on modern systems and allows for  original PalmOS applications for the Motorola 68k to run on x86 and ARM host systems.

On start-up the Launcher shows up first, just like with PalmOS, from which the four standard PalmOS applications (AddressBook, MemoPad, ToDoList and DateBook) can be launched. Due to endianness issues (m68k being Big Endian), files created by these applications cannot be shared between PumpkinOS and PalmOS, and as noted on the GitHub page, it’s still a far from finished project. That said, it appears to be able to run quite a few original PalmOS applications from sites like PalmDB, and compatibility should get better over time.

The author maintains a development blog as well, for those who are interested in the more in-depth details of this project.

A Brief History Of Keyboard Encoding

Photoelectric encoder keyboard configured as ASCII
Photoelectric encoder keyboard configured as ASCII

While typing away on our DIN, PS/2, USB or Bluetooth keyboards one of the questions which we rarely concern ourselves with is that of how the keyboard registers which keys we’re pressing. One exception here is when the keyboard can only register a limited number of simultaneous keypresses (rollover). Even though most keyboards today use a matrix which connects the keys, there are many configuration choices even here, which much like other keyboard configurations come with their own advantages and disadvantages. As a good primer we can look at this article by [Daniel Beardsmore] as he takes us through both historical and current-day keyboards.

Especially before  it was realistic to just put an entire microcontroller with a look-up table into every keyboard, more inventive approaches were required to not only register keypresses, but also encode them for the host computer. The photoelectric approach of the 1960s was one such encoding method, before diode matrices became popular, along with more exotic encoding switches that contained their code already hard-wired on their multitude of pins. One inevitable limitation with these was that of a lack of multi-key support, leading to the development of matrix scan technology around 1970.

Matrix scanning keyboards allow for multiple key presses at the same time, tackle debouncing of keys and were at the forefront of what gives us the ubiquitous and generally boringly reliable keyboards which we use today.

The Rise And Fall Of Silicon Graphics

Maybe best known as the company which brought a splash of color to corporate and scientific computing with its Indigo range of computer systems, Silicon Graphics Inc. (later SGI) burst onto the market in 1981 with what was effectively one of the first commercial graphics operations accelerator with the Geometry Engine. SGI’s founder – James Henry Clark was quite possibly as colorful a character as the company’s products, with [Bradford Morgan White] covering the years leading up to SGI’s founding, its highlights and its eventual demise in 2009.

The story of SGI is typical of a start-up that sees itself become the market leader for years, even as this market gradually changes. For SGI it was the surge in commodity 3D graphics cards in the 1990s alongside affordable (and cluster-capable; insert Beowulf cluster jokes here) server hardware that posed a major problem. Eventually it’d start offering Windows NT workstations, drop its MIPS-based systems in a shift to Intel’s disastrous Itanium range of CPUs and fall to the last-ditch effort of any struggling company: a logo change.

None of this was effective, naturally, and ultimately SGI would file (again) for Chapter 11 bankruptcy in 2009, with Rackable Systems snapping up its assets and renaming itself to SGI, before getting bought out by HPE and sunsetting SGI as a brand name.

Fortran And WebAssembly: Bringing Zippy Linear Algebra To NodeJS & Browsers

With the rise of WebAssembly (wasm) it’s become easier than ever to run native code in a browser. As mostly just another platform to target, it would be remiss if Fortran was not a part of this effort, which is why a number of projects have sought to get Fortran supported on wasm.

For the ‘why’, [George Stagg] makes the point that software packages like BLAS and LAPACK for Fortran are still great for scientific computing, while the ‘how’ is a bit more hairy, but getting better courtesy of the still-in-development LLVM front-end for Fortran (flang-new). Using it for wasm is not straightforward yet, due to the lack of a wasm32 target, but as [George] demonstrates, this is easily patched around.

We reported on Fortran and wasm back in 2016, with things having changed somewhat in the intervening eight years (yes, that long). The Fortran-to-C translator utility (f2c) is effectively EOL, while LFortran is coming along but still missing many features. The Dragonegg GCC-frontend-for-LLVM project was the best shot in 2020 for Fortran and WebAssembly, but obsolete now. Classic Flang has been in LLVM for a while, but is to be replaced with what is now called flang-new. The wish by [George] is now to find a way to get his patched flang-new code for wasm support into the project.

In the article, the diff for patching the flang-new toolchain to target wasm is provided. During compilation of the standard Fortran runtime it was then found that the flang-new code assumes that target system sizeof() results are identical to those of the host system, which of course falls flat for wasm32. One more patch (or hardcoded hack, rather) later the ‘Hello World’ example in Fortran was up and running, clearing the way to build the BLAS (Basic Linear Algebra Subprograms) and LAPACK (Linear Algebra Package) libraries and create a few example projects in Fortran-for-wasm32 which uses them.

The advantage of being able to use extremely well-optimized software packages like these when limited to a browser environment should be obvious, in addition to the benefit of using existing codebases. It is certainly [George]’s hope that flang-new will soon officially support wasm (32 and 64-bit) as targets, and he actively seeks help with making this a reality.