(date: 2024-10-13 09:42:47)
date: 2024-10-13, from: Old Ventage Computing Research
Every collector has that machine, the machine they sunk so much time and, often, money into that they would have defenestrated it years ago except for all the aforementioned time and money. Yours truly is no exception.
For those of you unfamiliar with the general world of Lisp machines, they are, as their name implies, workstations entirely designed around the Lisp programming language. That doesn’t just mean using conventional processors with a Lisp runtime either: these devices are built to run Lisp from the silicon up with specific hardware support. (Some of these systems could also run Prolog, my personal favourite AI-adjacent language. We’ll play with a surprising small Prolog implementation in a future article.) They existed in highly technical environments as workhorses of the first wave of AI hysteria (you crazy kids today with your LLMs) for applications like natural language processing and expert systems. The genre more-or-less flourished from the end of the 1970s to the early 1990s and included some of the first systems to implement advances like bitmapped displays, networking and pointer devices. In turn, those unusual capabilities caused them to also develop distinctive user interfaces for their unique feature set, years before today’s GUI and keyboard conventions we almost unconsciously take for granted were even conceived of. Working with a Lisp machine can be a remarkably different user experience from modern computing and the occasionally jarring nature of those differences isn’t something present-day emulators fully capture.
Unfortunately, their rarity also makes them the whitest of white elephants sometimes. Besides what I had to do to get it working properly to start with, the hard drive started timing out and it randomly froze during boot or shortly afterwards. (There was also the matter of me never finishing its setup, let alone getting it networked.) I’m not letting this benighted thing die on me after all I’ve put into it, so it’s time for a Refurb Weekend.
The MacIvory line hails from Symbolics, probably the longest lived Lisp-specific machine maker (not counting Texas Instruments, which of course remains very much in business and never specialized purely in Lisp hardware). Symbolics came out of an acrimonious split in the Artificial Intelligence Laboratory at the Massachusetts Institute of Technology where the first Lisp machine was built, the so-called “CONS” machine (named after the list-building primitive). Developed initially by programmers Richard Greenblatt and Tom Knight, the CONS machine and all of its descendants use varieties of a machine-specific dialect reasonably called Lisp Machine Lisp, descended from Project MAC’s Maclisp, that added object-oriented (“Flavors”) and system programming features. The CONS machine’s key advances included incremental garbage collection and parallel runtime type evaluation (the machine was a tagged architecture) that with minor changes evolved into the “CADR” machine (the Lisp primitive to take the second item of a list). This is a 1979 example from the recent sale of Paul Allen’s personal machines:
The CADRs in particular became very popular with the AI Lab hacking community — Steven Levy in Hackers: Heroes of the Computer Revolution called the Lisp machines “a true hacker’s machine” — and started attracting substantial outside attention, even DARPA funding. Meanwhile, Russell Noftsker, hired originally by Marvin Minsky in 1965 as the administrator of the Project MAC AI Group that spun off into the AI Lab, had left in 1973 to form his own company (Pertron Controls, Inc.), although he still maintained personal connections at the Lab. Unfortunately, the contentiousness of what transpired next makes the various extant personal accounts unreliable. What is fairly certain was that in 1979 Noftsker and Richard Greenblatt discussed commercializing the technology but could not come to an agreement: Noftsker intended to create a more typical startup using venture capital that would then have ownership stakes, whereas Greenblatt believed growing customer interest was sufficient for advance orders to make a company self-sustaining and keep it in the hands of its founders.
The resulting dispute was so fraught that the lab split into two factions, but most supported Noftsker’s approach. Noftsker notably agreed to give Greenblatt a year’s head start, though with most of the departing AI Lab denizens moving full-time to Noftsker’s new venture, Greenblatt’s team struggled with development. (Stallman and Minsky were conspicuously not part of either company.) Despite the already existing customer interest Greenblatt had hoped for, eight months later his team still had no commercial product, distressing Control Data Corporation consultant Alexander Jacobson who wanted a Lisp machine for a natural language processing project. Greenblatt’s original intentions notwithstanding, Jacobson forced the issue by creating a business plan and board and finding a partner, to which Greenblatt acquiesced. This new company in late 1979 was LISP Machine, Inc., or LMI. On Noftsker’s side he made a deal with Patrick Winston, the AI Lab’s director at that time, that in return for his staff using MIT facilities, MIT could freely use the software internally that the new company was developing. Noftsker’s team incorporated as Symbolics, Inc. in 1980.
Both companies’ first products were reworked CADRs. LMI called theirs the LMI-CADR; Symbolics, after a substantial delay in finding venture capital due to the recession, called theirs the LM-2. LMI’s CADR brochure (above, via Bitsavers) has a 1979 screenshot of the Lisp machine interface of the time. Symbolics only intended the roughly 1MHz LM-2 to be a stopgap but due to delays developing its successor ended up producing around a hundred of them (at $70,000 each, or over $240,000 in 2024 dollars). Codenamed the “L-machine,” that successor was the 1982 Symbolics 3600.
The first 3600s weren’t much smaller than the CADRs, about the dimensions of a refrigerator due to the physical size of the necessary hard disks and its widely spaced card slots for wire-wrapped prototypes. Symbolics developed a completely new architecture for the 3600, using a stack machine for the low-level instruction set with a 36-bit logical word (either a 32-bit value and a 4-bit tag, or a 28-bit address and an 8-bit tag set, “limiting” the machine to 256 megawords of RAM) on a 44-bit physical word with eight bits of error correction, and providing 4096 hardware registers with half as a high-speed stack cache and the remainder for the microcode and speed-sensitive operations. All addressing was by word (no bytes) and each word could carry two instructions, sort of VLIW before it was VL. Built from TTL logic, the CPU ran at a nominal 5MHz and many primitives could execute in a single clock cycle, but a lack of word prefetch, a four-cycle minimum penalty for main memory access and a few complex microcoded instructions reduced performance from that theoretical maximum by around thirty percent on average. The machine provided a monochrome 1100x900 display and an on-board Motorola 68000 as a service processor (termed the “front end processor”) handled bootup and peripherals; Ethernet and a mouse came standard, and the hardware directly supported virtual memory and garbage collection. Symbolics also developed a more streamlined keyboard by reducing the “space cadet” keyboard’s symbol set while retaining the modifier and function keys.
The 3600 series did well in its rareified market niche, in no small part
due to the relative weakness of LMI’s next generation offering, the 1983
LMI-LAMBDA. Unlike the 3600, which was a total revamp, the LAMBDA’s Lisp
core was largely a hopped-up CADR with cache, faster logic and some
architectural improvements. It was notable for its 8088 service
processor and its early use of NuBus, the interconnect standard
originating with the MIT NuMachine, a 68010-based Unix system (“TRIX,” a
Unix V7 lookalike that GNU also intially used as a kernel) which Western
Digital subsequently licensed for development. (We’ll come back to NuBus
shortly.) LMI hedged its bets by offering a 68000 option and Unix, which
could even run simultaneously with Lisp, but the company only ended up
selling around 200 of the LAMBDAs and became so starved for cash that
Texas Instruments agreed to license the architecture in return for a 25
percent corporate stake. TI had already purchased the NuMachine rights
from Western Digital in 1982 after WD decided not to enter the
workstation market, and it updated and merged LAMBDA with its
nunew acquisition to create a smaller platform it called the “Low
Cost Lisp” system. The LCL CPU (codenamed “Raven”) subsequently became
the basis of the $52,500+ [$160,000+] TI Explorer workstation in 1984,
which I guess was relatively lower cost for a Lisp workstation, though
the G-machines were still cheaper.
The 3600s had other advantages over other Lisp vendors as well, in particular establishing an early lead in computer graphics through the Symbolics Graphics Division, also established in 1982 and located in Los Angeles’ Westwood district near Hollywood. Early SGD animations generated by a 3600 system appeared on the shipboard displays in Star Trek III in 1984, and as a kid in junior high I remember the 1987 short Stanley and Stella in Breaking the Ice (here is a remastered version from the original director and executive producer) that turned up at a local computer animation festival. I didn’t fully understand what a Lisp machine was back then, but I reasoned that if they could do stuff like that then they must be pretty cool. SGD remained in operation into the 1990s, generating the CGI orca in 1993’s Free Willy.
During this period Symbolics officially christened their fork of the Lisp machine operating system as Genera, and ZetaLisp as their version of Lisp Machine Lisp. Originally the system software had been copyrighted by MIT and licensed to both LMI and Symbolics, and Noftsker’s initial arrangement with Patrick Winston ensured that Symbolics’ work could be done on MIT systems and made available to MIT, but Symbolics increasingly believed that the company needed greater control of the software base and in 1981 moved development to their own machines. Although Symbolics kept at least the letter of their arrangement with MIT and other customers by providing nearly all of the source code, customers — including MIT — were not allowed to redistribute it further. This infuriated Richard Stallman, who alleged Symbolics was acting unfairly to prevent their work from being incorporated into LMI’s products (as well as, for that matter, TI’s), and he determined to independently reimplement Symbolics’ improvements in MIT’s code base to prevent Symbolics from gaining unilateral control. After two years of doing so, he announced the GNU project in September 1983 and left the AI Lab the following year, and the rest is history.
By 1987 at least three efforts were being made to develop a Lisp-on-a-chip, though only two had any lasting import. LMI had been attempting its own reworked Lisp architecture as the RISC-inspired K-machine for several years, but the company went bankrupt in 1987 before its completion. However, LMI’s work indirectly lived on through Texas Instruments, who produced the 553,000-transistor MegaChip (codenamed “Hummingbird”) as a further evolution of the CADR/LAMBDA/LCL architecture; TI deployed MegaChip as the core of its new “Compact Lisp Machine,” sold as the TI Explorer II. For its part, that same year and also after considerable delay, Symbolics announced their own single-chip Lisp processor with yet another new architecture. Symbolics christened their CPU “Ivory,” a 390,000-transistor chip initially fabricated on a 2μm double-level metal CMOS process.
Ivory implements a four-stage pipeline fed by a 32-word (64-instruction) direct-mapped I-cache, itself populated by an autonomous prefetch. The simplest instructions take just a single cycle in each pipeline stage, though the more complex ones may spend several cycles in the execution phase before retirement. Tag and ECC checking are done parallel to the pipeline and in the typical case incur no time penalty. Instead of a conventional D-cache, however, the CPU has a 128-word top-of-stack cache, a 32-word scratch pad acting like a register bank, and a 16-entry translation lookaside buffer. Specialized SIMD/vector instructions accelerate garbage collection (along with other hardware features), database searches and graphical operations, and additional custom hardware also speeds up virtual memory and Lisp calls and returns. A coprocessor interface allows for an optional FPU.
A relatively advanced design for the era, Ivory in its first stepping (“Merlin”) was easily twice as fast at the same Lisp code than the L- and G-machines, though fabrication problems meant Symbolics took close to a year getting the first I-machine to market as the VMEbus-based XL400 in 1988. Ivory’s development delays ultimately exacted a heavy toll. While Noftsker had pushed for Symbolics to create a “Lisp chip” as early as 1983, the company’s board rejected the project and it sat in semiconductor turnaround until around 1985 when design work could resume. Meanwhile, cheaper general-purpose computing was improving at an even faster rate and the performance delta between Lisp machines running Lisp and PCs and Macs running Lisp, though still non-trivial, was shrinking just as rapidly. This phenomenon meant that Lisp machines had to get cheaper to maintain their value proposition: while Moore’s law applied equally to Lisp machines as well as x86 and 68K, there were a lot more people working on processor design at Intel and Motorola than there were at Symbolics and TI.
NuBus had its critics for its overengineered nature and it made cards and systems more expensive, but there were many fans as well. Although Steve Jobs had ferociously fought against expansion slots and colour displays as contrary to the Macintosh’s nature, his precipitous departure from Apple in 1985 cleared the way for both to be implemented in the Macintosh II. Michael Dhuey and his team selected NuBus due to its plug-and-play nature which fit with Apple’s goals of ease of use.
The microExplorer beat Symbolics’ competing product by over six months, but in the end Symbolics did basically the same thing as TI: they put an Ivory on a NuBus card, and they sold it in a Mac II. Symbolics had been working on an Ivory card initially for the 68K-based Sony NEWS but the companies could not come to an agreement and the TI-Apple announcement sealed its fate. As announced in October 1988 Symbolics’ package system came in more costly at $21,900 [$58,300], in part due to the larger 300MB hard disk it shipped with, but the card itself started at $10,900 [$29,000]. Also like the microExplorer, additional Lisp memory could be added with NuBus RAM cards. Struggling after downsizing their facilities due to sales declines, the MacIvory was a bright spot for the company, which still had a residual following using Genera as a rapid prototyping environment. Symbolics produced a refined version dubbed the MacIvory II and a VMEbus version called the UX400 for SunOS-based Sun-3 and SPARC systems, both in 1989.
Meanwhile, the eighties/nineties “AI winter” set in around 1988 after DARPA’s Strategic Computing Initiative slashed new spending on artificial intelligence projects, citing the projects’ expense but more importantly a general failure to meet their lofty and ill-defined goal of full machine intelligence. TI, never a Lisp machine specialist to begin with, had already been exploring SPARC as a licensee and quietly ended further development of the MegaChip to concentrate on the new architecture. Their gradual exit eventually left the Lisp market almost entirely to Symbolics, who continued modest Ivory development with process shrinks to 1.2 microns and finally 1 micron, now fabricated by Hewlett-Packard, and increasing its speed factor over the old 3600 line to roughly six times. The fastest Ivories were introduced in the XL1200 large system and UX1200 card in 1990, and the MacIvory III in 1991.
And that, finally, brings us to our problem child. Let’s meet the hardware.
When the machine arrived it was utterly DOA, and I was livid at getting a $4500 doorstop. Even an anti-capper like me knew why: this was around the time when problems with classic Mac capacitors (notably 68030 Macs and their contemporaries like the Macintosh Portable) were starting to emerge, and this one was still on its factory caps. I sent it off to a professional to be recapped; this took a couple months and a couple hundred bucks. In the meantime I transplanted the MacIvory card and its half-height hard disk to my spare IIci for analysis. This disk contained System 7.6 and a preconfigured basic Genera 8.3 world. Since I had no install media I did have the presence of mind to try making a dd image of it using my NetBSD Quadra 605, but that turned out to be to no avail because the hard disk was riddled with soft errors. Writing anything to the 7.6 partition would cause it to poop its pants, Disk First Aid got so confused it claimed it wasn’t even an HFS volume, and DiskWarrior repeatedly failed writing out a replacement directory on two different hard disks. This seriously called into question the state of the Genera partition as well. I had great difficulty believing the machine had been tested before it was shipped.
As the disk image was basically unrecoverable this meant I’d need to locate Genera CDs to reinstall it, but it also meant I needed to find an external SCSI CD-ROM drive to read them that was also compatible with Genera. As it happens, the MacIvory only supports single-speed (yes, 1x) CD-ROM drives. It took me a couple weeks to track down a working AppleCD 150 (I already had a few CD caddies from my 2x AppleCD 300) and a basic Genera distribution on disc, totalling close to a thousand dollars between them. I got a larger 4GB hard disk, partitioned and formatted it, installed System 7.1 (my preferred version of System 7) and got the basic Genera 8.3 world rebuilt from the CD with the Y2K patch. I don’t have any pictures of this process as I did it years ago, but other than loading the Y2K changes and saving the modified world, everything I did was straight out of the thorough Genera 8.3 Software Installation Guide for MacIvory Machines which is on Bitsavers.
At this point and even after very limited use the 640x480 internal video became obviously cramped as a console (remember that real Lisp machine consoles were usually 1100x900 or more) and I wanted to improve its throughput, which is partially limited by how quickly the Mac can service Remote Procedure Calls from the Ivory. Although I put in 64MB of RAM to see if that would help caching, all that really seemed to do was make the initial memory test obnoxiously long. For these additional upgrades I had a number of cards on the shelf and altogether they make four CPUs running together in one case.
To speed up the Mac system side, I installed a DayStar Digital PowerCache 68030 in the processor direct slot (this is #1 of our four on-board CPUs and takes over for the 25MHz 68030 on the motherboard). This card is the 50MHz version with a 68882 FPU and 32K of L2 cache for basically double the performance. I originally got it for my long-suffering NetBSD IIci, but the tasks that machine does didn’t really benefit much and it ended up sitting in the parts box. As such I chose the PowerCache over a Turbo 040 mostly because I already had it, but also because I wasn’t sure initially if this was one of the MacIvory systems that didn’t like Quadras. (As it turns out, I bet right because it is one of those cards; more shortly.)
For the network card there are few choices because the MacIvory actually controls the network card over NuBus with its own driver (in fact, if the Mac gets control of it first the MacIvory will be unable to initialize networking, so for file exchange this machine uses LocalTalk and not EtherTalk). Other than onboard Ethernet on some systems, the typical supported option is the Apple Ethernet NB Card, part number 670-4417. This was the card originally shipped with the system and is a 10Mbit card with an AAUI port (no RJ-45, but I have plenty of AAUI transceivers around here). It carries #2 of our four on-board CPUs, its own 68000 running at 10MHz.
The video card choice was even simpler: the fast and temperamental Apple Display Card 8•24 GC, Apple’s first video card with QuickDraw acceleration intended for the Macintosh IIfx, and my personal favourite Mac video card. I used one with a NuBus bridge in my first Mac, a IIsi, where it was probably a waste but it sure was quick. Although the MacIvory itself can address a specific NuBus video card (the NuVista) for graphics and some of the rendering tools will use it, this video card doesn’t service the Mac side and we don’t have an extra slot for one.
Accelerated is where it gets interesting. The 824 GC has its own CPU, an AMD Am29000 (#3 of our four on-board CPUs), which is used for fast drawing operations directly to its own video RAM rather than the Mac’s CPU pushing pixels over the bus. (It will even accelerate any ordinary 824 and 4*8 cards present because they support NuBus block transfers.) The Am29K is a Berkeley RISC chip like the SPARC and implements register windows as well, but unlike SPARC it uses variably sized windows to avoid wasting valuable on-chip resources. On the card it runs at 30MHz (from a 60MHz crystal) with 2MB of VRAM and 64K of SRAM for cache. A CDEV loads the Am29K-optimized “GC QuickDraw” and “GC OS” kernel to the card and then patches QuickDraw calls to redirect to the GC. Apple bragged this accelerated video between five and thirty times, which sounds immediately suspect, but I certainly find it to be a very swift option for ’030 Macs and we’ll test its throughput soon enough. The Am29000 family was a popular architecture in rasterization applications and embedded systems, and eventually evolved into the basis of the x86-compatible AMD K5, which helped keep the company treading water until the speedy yet technologically unrelated K6 was released.
The trick with acceleration is that the 8•24 GC control panel is extremely finicky. It won’t run in 32-bit mode, so now my 64MB of RAM was mostly wasted because I was limited to 8MB in 24-bit mode, and ’040 Macs need not apply at all. Although it can run accelerated under 7.5 and 7.6, graphical glitches can occur especially with pull-down menus, so you really must run 7.1. Good thing we’ve already installed it.
This card has an additional 2MB of VRAM (64-pin SIMMs of the same spec as the IIfx). I found some IIfx SIMMs a number of years ago and decided to install them, though it’s arguable the system is using much GWorld space anyway, and it doesn’t unlock any additional resolutions or colour depths. Theoretically up to an additional 8MB may be installed in these slots but I can’t think of any 68K Mac application that would be usefully improved by 10MB of VRAM.
Last but not least, CPU #4 is the MacIvory III itself, which I’m going to abbreviate to MI3 for the rest of this article. This is a revision C, one of those card versions that does not work in a Quadra, probably because of the ’040’s caches. (No MacIvory card will work in a NuBus Power Mac or any 68K system with an activated Power Macintosh Upgrade PDS card.) The card bolted to the front is the six-megaword memory expander, which was in large part responsible for the MI3 being much faster than earlier versions because it’s local to the CPU instead of having to be accessed over NuBus. This card does not have the Floating Point Accelerator option, a Weitek 3164 FPU on a daughtercard, though I’ve never had a personal need for it. The 3164 provides 32 64-bit floating point registers compliant to IEEE 754 and is accessed on a full 32-bit bus over the Ivory coprocessor interface.
Even though NuBus memory boards were no longer functionally necessary (though I believe they were still supported) and the MI3 is much more practical in a 3-slot Mac, the footprint of the 6MW memory card still takes up almost a slot’s width on its own. We can squeeze this into the IIci by putting it in the NuBus slot closest to the PDS where there is sufficient space for the overhang. The red strips are power bus bars containing a small amount of dielectric acting as an overgrown common decoupling capacitor. Frequently seen on boards into the late 1980s, they were gradually superseded by conventional SMT caps which take up less space.
I’m not interested in taking the memory board off lest I damage anything, but you can get an idea what’s under it fron the back: most of the base 2MW of memory and a couple large support ICs, primarily the NuBus interface chips. U48 in particular is a TI (heh) SN74BCT2420FN, a NuBus transceiver/register.
I mentioned that the 3600 series have an on-board 68000 as a service processor, formally termed the Front-End Processor (FEP). As its name implies, the FEP handles the startup console but also manages slower devices during normal operation. (As an interesting point of trivia, 3600 systems could themselves be front end consoles for the Connection Machine CM-2 and CM-2a supercomputers.) I-machines, however, even the large systems, completely dispensed with a discrete FEP and all device management moved to the CPU. On boot the Ivory itself serves as the console, loading a small binary image which today we’d term the bootloader, but it’s still called the FEP and still takes the same or similar commands. Strictly speaking, if we treat the Mac as a formal front end, then our PowerCache card would be the real “FEP” since it handles all the peripherals that the MacIvory doesn’t. The upshot of all this is that there isn’t a CPU #5 on the card; it’s all Ivory, all the time.
Eventually the repaired original logic board returned and I transferred everything back. Unfortunately, when I attempted to install the rest of the system, the AppleCD 150 started ejecting every disc I tried to insert and wouldn’t mount anything. You guessed it: capacitors. Rehabilitating the optical drive was a bigger job than I could handle and it went off to be recapped too, adding a couple hundred dollars more.
This was the state of the machine as you see it here and the bulk of the money spent. When the AppleCD 150 came back, I made sure it worked and planned to finish the installation “later.” As usual “later” didn’t happen until a few weeks ago, after I was replacing the spinning hard disks on the Quadra 800 and the Amiga 4000T with ZuluSCSIs and decided to see how the Lisp Mac was faring. It started but froze after around 10 or 15 minutes messing around. In fact, it would freeze even without the MacIvory booted up, and the hard disk was making weird clicking noises.
That got rid of the ominous hard drive noises but it still randomly froze after a few hours, and sometimes after a freeze it wouldn’t power back up until I let it sit around for awhile. Considering the sheer number of cards in this system, that particular problem seemed like overheating. I did an unscientific finger test on the PowerCache CPU’s heat spreader and found it was quite hot to the touch, and because the card is so close to the power supply it makes it impossible to mount any reasonable heat sink and fan on it. Although there’s a fan in the power supply itself which provides case ventilation, and it was clean, working and pushing air, the Am29000 on the 8*24 GC was also uncomfortably hot and so was the Ivory’s heatsink, so it probably wasn’t enough.
However, this system is also mounted on its side for space-saving reasons. I had it in the “standard” Apple vertical position with the power switch up (same as the Quadra 700) so that I can forcibly power down the system if the Ivory is misbehaving (it can maintain its own state which can even survive reboots), but it’s possible things were slipping around as a result too. In particular, the PowerCache CPU board was definitely a bit wiggly.
To test both those theories, I pulled out the system and ran it horizontally with the cover off but everything still installed. If there was a hardware problem unrelated to those two causes, it should have manifested that way, and of course it ran all day like a champ. A quick check with a Snooper board failed to demonstrate any obvious faults.
The first order of business was to ensure the PowerCache card was staying in its slot. The IIci case (and also the Q700’s) has multiple provisions for keeping things properly aligned when the system is vertical. For example, to prevent long NuBus cards from being warped by gravity, guides in the lid clamp onto the end of the cards and keep them in position. The Ethernet card is short and doesn’t need the help, but both the 8*24 GC and MI3 cards engage the stabilizer guides due to their greater length.
Unfortunately, the DayStar card is the wrong size and thickness to put on the cache card’s clip, and installing immobilizers and shims around it just made airflow worse. Eventually I removed the card and very carefully with a jeweler’s screwdriver slightly bent out the first and third rows of the card’s pins towards the port’s outer edges — if you’re going to rely on a friction fit, then by golly make more friction. I’m not sure how much difference this actually made but it did subjectively seem to seat better afterwards.
I thought about replacing the power supply fan with a faster one but it seemed simpler just to add a second case fan. Unfortunately, with everything crammed inside there wasn’t a lot of additional space. I still had some 80x80x25mm Arctic F8 fans (2000rpm, 31cfm) left over from when I was putting a fan bank in my mATX Raptor Blackbird, so I grabbed one just to see. To my delight it did fit and sat neatly on top of the RAM sticks with space to clear.
But since it was going to be sitting vertical I didn’t want the fan to smack around on anything. I thought about removing the internal speaker or maybe drilling holes through the drive bracket to mount it, but it dawned on me that the drive bracket already had holes I could use to thread something through. The F8 doesn’t weigh much, so I got some 10lb monofilament nylon and ran a loop through the drive bracket and what would be the top mounting holes for the fan. For power I plugged it directly into the old hard disk’s connector since the ZuluSCSI was running fine just on termination power. Airflow direction is front to back to augment the power supply’s fan.
Even that wasn’t quite enough to solve the freezes, though now they were definitely less frequent and the system was running stably for longer periods. I was pretty sure heat wasn’t the problem anymore because all four CPUs were nice and cool to the touch even after hours of runtime, and all the cards seemed to be staying in place.
After pondering the situation I dimly recalled a problem I had decades ago with the NetBSD IIci where it also got intermittently unstable, and after multiple thrashings with a Snooper card I remembered catching a sag on one of the power supply lines. As a test I replaced the General Electric power supply in this unit with a recapped ASTEC I had sitting on the shelf, and the last remaining hiccups disappeared. I’m not sure why this didn’t show up when I was burning it in horizontally, but perhaps it was just marginal enough to only flip out under load. Either way, let’s get busy like Arsenio.
Fired up with the PowerCentral and 824 GC control panels both fully enabled. Notice that the 824 GC CDEV reports the 4096K of video RAM installed, and that the About This Macintosh box shows that most of our 64MB is now wasted. I suppose in the future I should do something about that but I don’t feel like going through the parts box for a crapload of 1MB or 2MB SIMMs right now.
Our three NuBus cards as reported in TattleTech.
I promised you some benchmarks, and Snooper can generate statistics for hard disk, video, CPU, FPU and memory, so let’s take a baseline with the accelerators off. Snooper reports all values relative to an idealized example of the selected system, here the IIci itself. (We’ll skip the hard disk test because we’re already on solid state and we don’t have a free slot for a faster SCSI controller anyway.) I should note that the 32K L2 cache in the PowerCache can’t be disabled, which explains the slightly higher memory and CPU scores than stock, and the 200% FPU result is probably invalid because the accelerator FPU likely can’t be properly bypassed in this configuration. While the unaccelerated 8*24 GC is only 65% the speed of the IIci’s onboard video, the IIci can’t display a screen this size either.
The actual performance improvement yielded by the GC’s acceleration is sometimes disputed, so let’s just turn that on but stay with the IIci’s stock CPU. Turning on acceleration increases video performance to 169% of the baseline IIci, about two and a half times faster than unaccelerated — not even close to Apple’s claimed 5x to 30x speedup, but definitely something you’d notice. This is why I like the 8•24 GC so much despite its idiosyncrasies.
It gets even more lopsided when we turn the PowerCache on too: FPU performance remains 200% as expected and the CPU scales to nearly that number at 197% (it’s twice as fast), yielding 285% memory moving performance over stock. Similarly, video performance jumps even higher to 253% of baseline as the PowerCache muscles through those operations that can’t be effectively offloaded to the GC’s Am29K. I also compared the CPU and FPU score to the IIfx and got nearly exactly 100% and 125%. Who’s “wicked” fast now?
For gits and shiggles let’s also pit this system against a couple likely Quadras you might have bought a MacIvory in. This version of Snooper predates the Quadra 650 (as well as my Q800 workhorse and the top-tier Q840AV), so we’ll use the Quadra 700 as a stand-in even though its onboard video is inferior. The PowerCache gets to 70% CPU and 50% FPU of the Q700’s 25MHz full 68040, a respectable result considering the ’040 pipeline and larger L1 caches, while still managing 137% of the Q700 on the memory benchmark and 113% of its video performance.
Time to resume the Lisp business. I should note that everything here is as of MacIvory Support version 4.2, which to the best of my knowledge is the last version that was released.
The MacIvory support package is split up over several places as deposited by its installer. The main applications are in the MacIvory Applications folder, including Genera, which is the primary bootstrap application. Yes, that’s a HyperCard stack and we’ll look at it later. The poetically-named Breath of Life application is how an initial system is built after installation of the Mac components: it restores an FEP filesystem from CD or tape, creating it first if necessary, and sets up default virtual memory paging files and boot files. If you get hopelessly hosed, you can use it to pave over everything and try to start fresh. Source code in C and libraries for creating your own Ivory-powered applications are included which we might explore in a future entry.
The other major part is in the System Folder. An Ivory folder is created here containing support files and the default namespace which we’ll spend some time in (the other Namespace folders are backups I made), along with the main MacIvory CDEV, which the installer oddly places in the Extensions folder but leaves an alias for in Control Panels.
That CDEV is how all the Mac-specific components get set up. Basic information about the card is shown, including the card revision (you need 20.1 for Quadra support; this card is 20.0). You’ll notice that Russell-CDR is declared as the sole MacIvory disk partition and that all 1,674,137 available pages on it have been allocated.
“Life support” for the MacIvory is handled with a shared-memory scheme, where the MI3 can post RPC calls to the host Mac and the Mac will deposit its replies, and vice versa. These are the default values for its usage.
Networking, as mentioned earlier, is handled by the Ivory directly addressing the Ethernet card over NuBus, either a real one or one with a pseudo-slot — the IIci doesn’t forward anything. The MacIvory expects full control of whatever card we point it at. If we had more slots, we could double-home the system, allocating one to the MacIvory and the others to the Mac. “Digital Networking Architecture” (they really mean Digital Network Architecture) and DECnet are specifically supported here, though I don’t have any such systems regularly running and thus I don’t usually have this option checked either. TCP/IP (which Symbolics calls IP-TCP) and Chaosnet are configured separately outside of the control panel.
The other channel is the “cold load stream,” the lowest level text-based interface to the hardware and in practical terms not unlike hooking up a serial terminal to the Ivory in its FEP capacity. The Mac booter puts this into a window where you can interact with it.
I should parenthetically note that the following screenshots of Genera running on the Mac are tricky to get. My usual Inogeni VGA capture box doesn’t like the 75Hz refresh rate and the Genera app traps all the keys when running, including Command, Shift and 3 — except Alt-Tab, which the LiteSwitch app switcher INIT nabs first. The trick, if you can time it right, is to have another app like SimpleText running with no windows visible. As long as the Genera app output is windowed, which it is by default for the FEP and can be configured so for Genera proper, you can then take a screenshot by switching to SimpleText instead. (If the window isn’t moveable, Genera will “helpfully” cut off some of its window when backgrounded so you can see mounted desktop drives, but this is exactly what we don’t want for a screenshot.)
The FEP ROM loads its kernel from its part of the Genera partition, which contains a small Lisp environment and command processor. If it detects that an apparently valid Lisp session is present on the card, it will offer to warm boot it here (though you can always force a cold start).
After loading the Genera world and initializing the basic configuration, the Ivory then switches over to the full environment, but it’s also possible to stop automatic boot after the FEP kernel loads if you need to do maintenance work from its prompt.
It’s possible to trigger errors or hit race conditions that make the cold load stream come up on the console, even if you were accessing the system remotely. This is rare and can sometimes be recovered from, but if it happens you’ll have to do it from the Mac.
The black bar at the bottom would ordinarily be populated with hints as to what key and mouse button sequences do what, though as an artifact of the way we’re taking screenshots it remains black on the console (we’ll get around this problem in a little bit). In the Genera User’s Guide this is called the mouse documentation line.
The lowest part of the screen is the status line or who line, which by default gives the current time (from the Mac), username (no one’s logged in yet), the current Lisp package, the process state (here User Input, since it’s waiting for us to enter a command), and then any additional status information. Occasionally small horizontal underlines flash through below the text; these indicate certain types of processing are occurring, and are correspondingly called run bars. If a file is open, its name will be displayed along with how much has been read so far and a line indicator below that.
On smaller screens, larger fonts aren’t used and the screen layout becomes denser, so you really want as big a framebuffer as you can get. With Moveable Screen set in the Genera app as we did here for screenshot purposes, you can move the entire Lisp window around and resize it, but as a practical matter we’ll be using it full screen. Genera cooperatively multitasks like any other Mac application, so you can use the Mac as a Mac while Lisp runs in the background and makes asynchronous calls to the Mac (which is, in fact, how we’re even taking these pictures).
I decided the next step was to get the network up. You are warned that the steps we’ll take in the rest of this article will deviate, in some parts significantly, from the official Symbolics manual, but for my purposes I find the result more convenient and Mac-like to manage (ut semper de gustibus non est disputandum).
Genera has a pseudodevice called SYS: (a “logical pathname”) under which many components and local configurations live, and it can point to either an LMFS directory or an HFS folder. This is medicated by SYS.TRANSLATIONS file, which contains a Lisp function mapping pseudofolders under SYS: to actual directories or folders. The configurations Mac Genera will consult are in :System Folder:Ivory:Namespace: (I recommend making a backup in the Finder before mucking with it), with the translations function found in that folder as SYS.translations. However, it seems that the system hardcodes SYS:SITE;. to always reference files in the Namespace folder on the Mac side, even if you don’t specify it in the function definition. This will make installation a little complicated later on and we’ll come back to this issue.
It turns out this folder handles lots of things on a Mac Ivory box. For networking purposes Symbolics supported either standalone systems or networked systems, though in Symbolispeak “standalone” merely indicates that the resources the given machine consults are stored locally; properly configured, a so-called standalone system can still access and be accessed over any supported network protocol. Regardless, in both cases you have to set up a “site,” or at least modify the standalone site shipped with Genera by default, which for Mac Genera also lives in :System Folder:Ivory:Namespace:. As this is an HFS folder, that means changing it in the Namespace Editor, which is the normal way you’d edit a site in Genera, or tricks like directly invoking (tcp:initialize-internet-namespace) will fail hard: at best you’ll get filesystem impedance mismatches saying it can’t write attribute :AUTHOR or some such, and at worst it will solidly bug out into the FEP.
I have only one other Symbolics Lisp machine on the premises which is usually not acting as such — to be discussed at the end — and thus I have no interest in creating a new site. Happily, the entire standalone site in Mac Genera is just text files you can edit in SimpleText, and everything you’ll want to edit for basic networking is in Standalone-Objects.text. Avoid changing the name of the namespace, the site name or the hostname; if you do these things improperly or incompletely, you’ll get lots of error messages and generally make Genera unhappy, and I’m not going to go into detail about it here. However, less crucial stuff like pretty names and timezones are fair game. For example, on my machine the host is still called MACIVORY, but its PRETTY-NAME is now Russell, and while the user name for logins remains LISP-MACHINE I also changed the displayed user name by setting LISPM-NAME under USER LISP-MACHINE to spectre.
As configured out of the box Mac Genera doesn’t know what the Internet is, even though it includes built-in TCP/IP support. To “define the Internets,” add the following stanza after the NETWORK CHAOS stanza:
NETWORK INTERNET SITE STANDALONE TYPE INTERNET
Remember to put a blank line after this and every other new stanza you enter. Finally, add an ADDRESS INTERNET x.x.x.x to the HOST MACIVORY stanza. (If you like, this address can also be added to any Set Network Address line in the FEP’s startup scripts with a ,INTERNET|x.x.x.x [comma before it], but isn’t necessary.)
Now start defining your hostnames. The first one you must define is the gateway; there will be no networking without it. The simplest way is to make the X11 host you’ll use the gateway, so something like
HOST FOOBAR ADDRESS INTERNET x.x.x.x SERVICE GATEWAY IP INTERNET-GATEWAY SERVICE X-WINDOW-SYSTEM TCP X-WINDOW-SYSTEM SERVICE LOGIN TCP TELNET SITE STANDALONE
However, you can make any host the gateway that the MacIvory box can reach directly. You can define additional hostnames in the same way; just drop the GATEWAY service since they aren’t your gateway (are they?). The lines given here make it the gateway, say it’s a valid host for starting an X session with, and say it’s a valid host for connecting to via Telnet.
Next, add the services you’ll use to the HOST MACIVORY stanza, if they aren’t already there. At minimum you will want at least SERVICE LOGIN TCP TELNET so you can remotely log into your machine. For illustration purposes, we’re going to use this set:
SERVICE FILE CHAOS NFILE SERVICE FILE CHAOS QFILE SERVICE LISPM-FINGER CHAOS-SIMPLE LISPM-FINGER SERVICE LOGIN CHAOS 3600-LOGIN SERVICE LOGIN CHAOS TELNET SERVICE LOGIN CHAOS SUPDUP SERVICE LOGIN TCP TELNET SERVICE LOGIN TCP 3600-LOGIN SERVICE NAMESPACE CHAOS NAMESPACE SERVICE NAMESPACE-TIMESTAMP CHAOS-SIMPLE NAMESPACE-TIMESTAMP SERVICE SEND CHAOS SEND SERVICE SEND CHAOS CONVERSE SERVICE SHOW-USERS CHAOS NAME SERVICE TIME CHAOS-SIMPLE TIME-SIMPLE SERVICE UPTIME CHAOS-SIMPLE UPTIME-SIMPLE
Finally, put the subnet you’ll log in from into the SITE STANDALONE stanza with SECURE-SUBNETS INTERNET x.x.x.x. When you’re finished, you should have something that looks like this:
For the fonts, since Genera doesn’t implement an X font server, you’ll need your Genera CD or you can copy the files out of an existing Genera install — but it’s easier if you have the CD as it’s ISO 9660 and you can just mount it on your Linux box. The font files are stored as PCF (Portable Compiled Format). Something like this will work:
% sudo tcsh # mkdir /usr/share/fonts/genera # cd /run/media/censored/GENERA_8_3/sys.sct/x11/fonts/75dpi/ # or where your CDs get mounted # cp *.pcf.* /usr/share/fonts/genera # cd /usr/share/fonts/genera # foreach k (*.pcf.*) foreach? mv $k `echo $k | perl -pe 's/\.~\d+~//'` foreach? end # ls charb08.pcf courbo18.pcf helvr12.pcf lubr12.pcf lutrs10.pcf symb18.pcf ...
The little tcsh foreach loop is to strip the version number off the file (I’ll discuss that a bit when we briefly talk about LMFS). Unless you don’t already have them or you prefer them, you should also remove Genera’s version of Helvetica and Times (hel.pcf and tim.pcf) as these will conflict with what you likely have already. Then do a quick fc-cache -f -v to load the new fonts.
Next we need to add a small system patch because unfortunately most modern X servers, including Xwayland (which sucks anyway), will not work with Genera; Genera will open the window but then receive an Xlib error and halt. That knocked my Fedora 40 Raptor Talos II workstation right out of the running, and doesn’t appear related to endianness (adding +byteswappedclients to the X server command line didn’t fix it, which interestingly suggests that Genera’s Xlib implementation is little-endian despite Ivory having no intrinsic endianness). However, I was successfully able to get it to talk to X11.app and XQuartz in Mac OS X 10.4 Tiger (later versions may work with XQuartz also), OpenWindows in SunOS 4.1.x (Solbourne OS/MP) and Power MachTen on Mac OS 9. Amusingly, these are all big-endian and worked with it just fine.
The problem ended up being Genera’s implementation of XSetModifierMapping, which needs to be patched out. At the Genera console, enter
(defun xlib:set-modifier-mapping (display &rest args) (values))
and answer Y when it asks if you want to overwrite the current definition. This is a great example of how you can patch a live Genera system while it’s running. At this point you can then Save World to capture the change (incremental should be fine), though I put it in MACIVORY:>(user name)>lispm-init.lisp to run upon first startup for comparison purposes. That file can be edited with Edit File MACIVORY:>(user name)>lispm-init.lisp and we will talk about the editor later. Your user name comes from LISPM-NAME in the same Mac-side standalone site file, by the way.
Now we’re ready to bring up services. At the Genera console, after logging in (with the Login command and username LISP-MACHINE, no password required), next type Enable Network INTERNET (or All), Enable Services and (neti:remote-login-on) to allow remote logins. I put the equivalent of those commands in my init file, which now looks like this:
(neti:remote-login-on) (defun xlib:set-modifier-mapping (display &rest args) (values)) (cp:execute-command "Enable Network" "All") (cp:execute-command "Enable Services")
and triggers this:
% ftp russell Connected to russell. 220 FTP service ready. Name (russell:spectre): spectre 230 USER accepted. Remote system type is . ftp> passive Passive mode off. ftp> ls 200 PORT ce,ns,or,ed,162,213 (TIM port 41685) accepted. 150 Here comes a listing of >spectre>*.*.*. >spectre>lispm-init.lisp.4 1 172 9/07/24 22:12:33 spectre >spectre>lispm-init.lisp.3 1 170 9/07/24 22:11:28 spectre >spectre>lispm-init.lisp.2 1 171 9/07/24 22:10:44 spectre >spectre>lispm-init.lisp.1 1 87 9/07/24 21:48:59 spectre 226 File transfer completed. ftp> quit 221 Goodbye.
Notice no password required! The name TIM doesn’t come from DNS but by reverse resolution using the namespace we just built by hand. There are a few other oddities about FTP, by the way: it’s simpler to just use it to transfer files to and from your home directory, as it were, and then place them in the right locations from the Lisp prompt. If FTP connects but gives you a 421 error, you forgot the SECURE-SUBNETS INTERNET x.x.x.x line.
It should also be noted that the line ending character natively in Genera is $8d, not $0d, not $0a, and not $0d $0a, as shown if we transfer any of the files above in binary mode. However, if you transfer in ASCII mode (i.e., not binary), then the line endings should get converted for you, and you can write and upload files from your own local machine instead.
There are also mail (SMTP) and finger servers listening:
% telnet russell 25 # smtp Trying... Connected to russell. Escape character is '^]'. 220 [ce.ns.or.ed] SMTP service ready. HELO localhost 250 [ce.ns.or.ed] HELP 214- Symbolics Lisp Machine SMTP server; Zmail 437.0. 214- Protocol is RFC 821. 214 Commands supported are HELO, MAIL, RCPT, DATA, RSET, SEND, SOML, VRFY, EXPN, HELP, NOOP, QUIT, and XCTM. MAIL From: <president@whitehouse.gov> 501 Bad reverse path: From: <president@whitehouse.gov>. QUIT 221 Goodbye. % finger @russell [russell.floodgap.com] spectre MACIVORY Unknown (Genera 8.3, 1 private patch, Patched for Y2K. 7.9MW MacIvory model 3) % finger spectre@russell [russell.floodgap.com] spectre MACIVORY Unknown (Genera 8.3, 1 private patch, Patched for Y2K. 7.9MW MacIvory model 3) % finger macivory@russell [russell.floodgap.com] spectre MACIVORY Unknown (Genera 8.3, 1 private patch, Patched for Y2K. 7.9MW MacIvory model 3) macivory: The user named "macivory" was not found. No user with that name is already known by the local machine, but it is not certain that there is no such user. Some namespace server did not respond.
Bottom line: don’t put your Lisp machine outside of a firewall, especially since Telnet and FTP don’t require a password!
Let’s actually start the X connection up. On the X side, allow the MacIvory system to connect with xhost +russell (or what have you), or just plain xhost + if you’re on a trusted network and things aren’t working. On the Genera side, the command is Start X Screen hostname, such as Start X Screen FOOBAR (capitalization doesn’t matter). Remember, you have to have previously defined FOOBAR (or whatever host name you’re using) as a host in the standalone site! In the sample Telnet session below, the ! at the end of a line is what Genera does to wrap the text; if you use a wide terminal, Set Remote Terminal Options can be used to expand the output.
% telnet russell Trying... Connected to russell. Escape character is '^]'. Symbolics System, FEP0:>Inc-Genera-8-3-from-Genera-8-3.ilod.1 (Patched for Y2! K.) MacIvory model 3 Processor, 7.9M words Physical memory, 24.4M words Swapping ! space. Genera 8.3 Standalone Russell Type c-_ H for Help. Type Set Remote Terminal Options to set the terminal type. Warning: Russell is a server machine. Please exercise caution. Command: Start X Screen (the name of a host) tim
The (the name of a host) prompt is provided for you by Genera. (The c-_ sequence is Ctrl-Underscore (i.e., Control-Shift-Minus), and allows access to a subset of Symbolics keys via Telnet. For example, Control-Underscore followed by A is Abort, E is End, H is Help, C is Complete and N is Network.) If you did it right, a new window will appear. On my 1080p display, the Lisp content area is 1728x972.
I mentioned that Genera has a pseudodevice called SYS: where certain core components are stored. This is not the Genera world you run, which is part of the FEP’s filesystem, but it does contain (or will, when we finish this task) the source code for it as well as things like fonts, optional packages, online documentation and site configurations. The filesystem mappings that compose SYS: are contained in an S-expression in SYS.translations. At this point the file looks more or less like this (with the ≡ character representing Escape/$1E, displayed on a Telnet connection to Genera as <Equivalence>):
;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: FS; Base: 10 -*-
(SET-LOGICAL-PATHNAME-HOST "SYS" :TRANSLATIONS
'(("SYS:**;*.*.*" "MacIvory|HOST:≡:Ivory:Namespace:**:*.*")
SYS: is subdivided into various subcomponents, represented by the double asterisk, and LMFS file references are not only by filename and extension but also by version number (or LATEST). This snippet of Lisp tells the filesystem module that SYS: in its entirety should be represented by folders under the Ivory System Folder, ignoring the version number. For example, SYS:FONTS;font.font.3 will be turned into an RPC request for :System Folder:Ivory:Namespace:FONTS:font.font.
That said, the Lisp clueful among you will have noticed something in the earlier screenshot: the Ivory System Folder doesn’t have a SITE folder. How then does that work to access the default namespace, which Genera looks for in SYS:SITE;? It happens first and foremost because the default FEP local boot script explicitly references it, but there’s also an implied mapping (“SYS:SITE;..*” “MacIvory|HOST:≡:Ivory:Namespace:.”) that always exists. In fact, this very mapping is used to locate SYS.translations itself.
However, we don’t actually want everything in SYS: stored on the Mac side when we complete the install. Doing so makes things a lot slower because there’s an RPC request required for each file instead of “directly” from LMFS, there are filesystem attribute mismatches, and most importantly because a lot goes into SYS: and it might overrun your Mac HFS volume. Change the file to this:
;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: FS; Base: 10 -*-
(SET-LOGICAL-PATHNAME-HOST "SYS" :TRANSLATIONS
'(("SYS:SITE;*.*.*" "MacIvory|HOST:≡:Ivory:Namespace:*.*")
("SYS:**;*.*.*" "MACIVORY:>rel-8-3>sys>**>*.*.*")))
which is equivalent functionally to this, but makes the implied mapping explicit so there are no surprises:
;;; -*- Mode: Lisp; Syntax: Common-Lisp; Package: FS; Base: 10 -*-
(SET-LOGICAL-PATHNAME-HOST "SYS" :TRANSLATIONS
'(("SYS:**;*.*.*" "MACIVORY:>rel-8-3>sys>**>*.*.*")))
thus storing everything but SYS:SITE;..* on the LMFS side yet keeping our standalone site configuration on the Mac side where we can get at it outside of Genera if we need to. In LMFS volumes, the greater-than sign is the path delimiter.
The translations facility isn’t nearly as flexible as you think it is, by the way: you can’t say, for example, that files ending in .SYSTEM. are in one place and all the other files are somewhere else. It’s only granular to the folder level (darn).
For the installation step, make sure your CD-ROM drive is available and powered on (rebooting your Mac if necessary). The CD-ROM here, as I mentioned, is a recapped 1x AppleCD 150 (Sony CDU-8002) on ID 1 that requires a caddy. The CD SC and CD SC+ predate the 150 and being 1x drives themselves may also work, but not the 300 or any later drive, which are 2x and faster. Insert the Genera CD and wait for it to mount, then bring Genera back up and log in.
The disc is accessible as CDROM1: (because it’s on SCSI ID 1). At the Lisp command line I entered Show Directory CDROM1:>.;NEWEST to make sure it was readable, and then the command Restore Distribution :Menu yes :Use Disk (notice the named parameter feature). We’re not doing this from X or Telnet because this program always runs on the Mac console, even if you start it from Telnet or an X session.
The Pathname for the fake tape distribution images is always under CDROM1:>DISTRIBUTION>. You should install at least CDROM1:>DISTRIBUTION>8_3_SOURCE_DIST_1.TAPE (containing the Genera base sources and documentation), but as space permits you may also want to install 8_3_SOURCE_DIST_2.TAPE (non-loaded optional systems). When you’ve entered the tape path, click Initialize Restoration; the CD will start and you’ll see the selected tape file accessed in the status line.
A huge list of packages and files appears. Notice how everything is going in SYS: and its use of the semicolon as a path delimiter, which gets remapped into the underlying filesystem’s (be it HFS or LMFS). We’re going to restore everything, so we’ll go directly to Perform Restoration.
As soon as you do that, you’ll immediately get an error with the first file which is emitted to SYS:SITE;NOTICE.TXT.112. The dialogue box demonstrates the general way errors are handled in Genera: flexibly, with many options. This is the :AUTHOR error I warned you about with the Namespace Editor trying to alter the standalone namespace on the Mac side from the Lisp side, but the file in fact has already been written (just not its optional metadata), so either press Command-B (the equivalent to Super-B) or click that option to skip the operation. That might seem like you’re skipping the file entirely, but in this case all you’re doing is skipping writing the metadata it can’t write in any case. The .SYSTEM. files that indicate which built-in and optional systems are installed on your machine go to SYS:SITE;.SYSTEM. too, so you’ll have to do this a few times to complete the process.
To break up the monotony of all these screenshots, here’s a glamour pic of the IIci during the installation. Pretty, yes? No crashes now!
Eventually you will have a nice long list of everything that was placed on the system and you will be returned to the Restore Distribution main screen to install the next set.
To switch back to Dynamic Lisp Listener 1, hold down F9 (the Mac FUNCTION equivalent), hold down 1 and press S. This key combination rotates through windows, by the way. You can restart Lisp at this point if you like, and I did, but it’s not necessary.
At this point we’ve finished tuning up the hardware and installing the software, so let’s have a little test drive. Pedantic Lisp machine denizens are advised: I don’t have a neckbeard as long as yours, and I’m mostly doing this from the perspective of an minimally informed tourist, so I won’t be demonstrating the length and breadth of Genera and Lisp Machine Lisp just like any other grab bag of screenshots couldn’t exhaustively demonstrate a classic Mac or the Oberon System either. Treat this as a brief show-and-tell and not a user’s guide. Also, because the X font set ends up slightly different, the appearance of UI elements and text prompts varies a little bit from what you’d see on the Mac console. Let’s return to the Dynamic Lisp Listener command prompt with the wider screen on our Linux workstation (restart the X session as instructed above).
Since I use a conventional three-button USB mouse with my POWER9 system, we no longer need key modifiers for the middle and right buttons. We’ll start with the menu, which the mouse documentation line shows is on the right mouse button.
In the Dynamic Lisp Listener, and in fact many though not all programs, right-click brings up a three-item context menu. In Symbolispeak, these are called momentary menus because they exist only temporarily. The marking and yanking menu is better known to modern audiences as “select, cut and paste,” and the window operation menu handles basic operations on the current window like closing it or sending it to the back. (What window, you might ask? In this case, the display is occupied by one. Full-screen windows like this usually omit any frame. More on this later.)
But we’ll click the option in the middle, the system menu, which opens up into this new three-column menu. The system menu is sort of like the Lisp machine Windows Start button, long before it was a twinkle in billg’s eye, allowing you to create and modify windows, adjust the window itself (these are more or less the options you’d find in the window operation menu), or open a new program. As befits the combinatorial power of the space cadet and Symbolics keyboards, there are lots of keyboard equivalents, though for purposes of brevity here we will only point out a few in the remaining text.
From the Programs column we’ll click on the Document Examiner, Genera’s pioneering built-in hypertext help system and one of the best-known applications on Lisp machines. Our installation effort paid off: we have a full stack of documents. Each pane has a scrollbar, though the thumbs don’t scale to the view size, and you use different mouse buttons to move the viewport instead of dragging the thumb (in simple terms, left down, right up, and middle to the pointer position).
If we open the first one on the list, Genera Concepts, the document opens in a viewer pane, including any associated graphics. A “bookmarks” pane acts more or less as your history, but you can also populate it manually, and documents and document libraries can be searched. A separate tool called Concordia could be used to author your own such documents.
You don’t have to kill programs if you don’t want to, and Genera multitasks very well even with limited memory. Ordinarily one could just switch windows with FUNCTION-1-S or bury the window to push it down in the Z-order and bring up something else. However, if you want to make the window go away completely, then you kill it. (Note that processes have an afterlife. I’ll talk about that when we discuss Genera internals.)
The confirmation dialogue comes from Genera, not from the Document Examiner. We close it.
Another useful facility with Genera is completions, where you can ask the system to suggest choices for the command you’re trying to enter. This can be done from the keyboard (SPACE or COMPLETE, depending) or with the mouse. The list so generated is not always exhaustive but it can still be substantial. Despite the spaces, these are all independent commands, e.g., the command we’re about to launch is “Show Machine Configuration,” including the spaces, not a command “Show” with the argument “Machine Configuration”).
And here’s the machine configuration. It recognizes the PowerCache’s 68030 CPU and 68882 FPU (which it calls an “FPA”) and the Apple Design keyboard which appears to the system as an Extended Keyboard II, as well as the motherboard and slots and any currently running SCSI drives (I had the CD-ROM off). It has “direct access” to the LMFS and FEP volumes on the ZuluSCSI.
Completions work for files and directories too. When an argument is required, Genera tries to provide you with reasonably sane defaults (though this doesn’t always work).
For the first instance, I typed in what I wanted, but you can also request a completion based on the default as done here. In a sense, completion menus effectively replace file requesters.
But the text on the screen isn’t just text. For example, I can right click on one of the previous commands and edit it.
This pops up a form (in Symbolispeak, a menu proper) which I can change, along with all of its arguments (including implied defaults).
Even the key prompts are clickable: I can press END, or I can just click the prompt telling me to press END.
Things like file listings are live objects on screen also.
I can right-click on a line in the file listing to get options on it too (you can even just left-click for the default, which is usually to open or display it). Here I’ll request this directory …
… and then display this file in the directory we just requested …
… et voila.
We’ve seen some of the basic interface, so now we’ll peek under the hood. Appropriately, we’ll do this using a built-in system monitor tool called Peek. Peek isn’t in the default system menu but it has its own key combination SELECT-P (on the Mac, ESC-P, on X, F1-P).
Peek starts up with a “help” screen and a series of clickable words on the top bar, which you can think of as primitive tabs. There are keyboard shortcuts for most things in Peek, as there are for most things in Genera. Peek can show you running processes, memory areas, remaining free memory and disk space, file system connections, active windows, active servers, network state and all Chaosnet host statuses. We’ll do each going from left to right.
The Genera scheduler is preemptive and tasks marked as “preemptive” take over the CPU as soon as they are runnable (priority permitting), relegating other tasks not marked preemptive to wait. The very highest priority tasks are “deadline” tasks that must complete execution in the specified time interval while within their critical sections. These tasks tend to be crucial system or user interface tasks like the status line updater and even the scheduler itself. You can see preemptive (P), foreground (F) and deadline (D) tasks in this list, and many tasks have multiple flags.
You may have noticed some tasks are listed as “dead.” These are tasks that were manually killed and they remain in the process table, even keeping a window allocation if they had one, although the scheduler will never put them on the processor. However, unlike zombie tasks on a Unix system which can only be reaped (and then only by their parent or when their parent exits), these tasks can be resurrected by resetting and thus restarting them.
The Areas tab shows how Genera handles memory. These memory ranges are composed of spaces called regions and come out of the unified physical and virtual (“swapping space”) pool, with a certain number of physical pages wired to the system. Although the K would imply kilobytes, it is in fact kilowords, and each page is 256 words, not bytes.
If you click on an area, its component regions are displayed, including their starting address (virtual, not physical), size and usage, and garbage collection status. Here we look at the area allocated to the FEP, which has one region located at a high virtual address (the address is octal).
The Meters tab is supposed to show the metering variables for storage, the garbage collector, ZWEI sectionization (in the editor), netboot and the hard disk, but nothing appears there on this system. The Symbolics Internals manual suggests some of this is only populated on error, but we bashed all those out when we got this system back in shape, so there.
You might wonder why the FEP has not only a separate volume but also a completely different type of file system, and the reason is its very different purpose. The FEP file system is simpler and faster than LMFS and is optimized for reliable concurrent access to files which are written rarely but accessed frequently. These obviously include FEP boot scripts, binaries and the bootable Genera world, but also information about the entire disk the FEP file system is on (thus each disk accessible by Genera must have an FEP file system of its own to describe it). FEP volumes are hierarchical and versioned like LMFS volumes, and use the same “greater-than” delimiter. Its most notable contents are “load” binary image files, generally ending in .load or .?lod where ? is F for FEP and I for Ivory, but there are other types like virtual memory paging files and (on 3600-series systems) microcode.
The Windows tab shows the running screens and windows on those screens. Each endpoint, the Mac console and the X session, have two screens consuming different parts of the display. On the X session we’re using here, the “who screen” refers to the who line/status line, which is subdivided into the (currently blank) file sheet and the other indicators (time, username, etc.), and the “X screen” proper has the running applications occupying the remainder of the display, namely Peek and its components (the “tabs,” called the “Dynamic Mode Command Menu 1,” and the main “Peek Pane 1”) which cover the Dynamic Lisp Listener we started it from. The Mac console has its own who screen, plus the initial Dynamic Lisp Listener, the Zmacs editor (which always comes up on boot because I had it open when I saved the world after committing the Y2K patch), and the ghost window for the Document Examiner I had running on the console and later killed (“Help 1” and its component panes). The typeout refers to a dynamic popup window containing out-of-band output generated by the process, usually informational text or error messages, but sometimes acts as a separate interface of its own.
Naturally each component is live and you can do operations on it.
The Servers tab shows active servers and their state, but this is a standalone system (with networking), so there’s nothing listed.
No SLAP or Chaosnet connections are running, but of course there’s one INTERNET (IP) connection open, which is the very X session we’re taking grabs from (I am amused that exactly 68,040 packets were received at the time the screenshot was taken; I didn’t plan that). Each supported IP protocol is listed: ICMP (the packets are probably from when I was pinging the link), EGP (Exterior Gateway Protocol for routing between autonomous systems, now obsolete and replaced with Border Gateway Protocol [BGP]), UDP and of course TCP. The single interface is listed as well, with the IPs blacked out because some of you are fun but I don’t trust you, and its gateway, which I have chosen to be the NetBSD IIci so that they can interact, intertwine and have little baby IIcis (also it’s on the same network hub).
If we click the one open TCP connection, we can see the current status. Some of the network statistics look hinky or overflowed, but you can clearly see it’s going to port 6000 on tim, this POWER9 workstation, making that obviously our X session.
Help and Quit we saw and are self-explanatory, leaving the final tab, Hostat. This polls all known Chaosnet hosts, but in this case there’s only one, which is Russell itself on 52525. This is the default Chaosnet address Genera installs ship with and is considered “undesirable” in the documentation due to this conflict. I left the address as it was because I’m like that. We click Quit and return to the Dynamic Lisp Listener.
Another useful activity is the File System Operations application. Let’s dig around in the filesystem a little.
This pops up its own menu of options, where you can open a tree view of the LMFS root, or another device, or your home directory; you can also open a new Lisp window, refresh the screen, get help or quit, or do special administration operations.
You guessed it: the tree is clickable. We are within the location (MACIVORY:>rel-8-3>sys>..*) that maps to most of SYS:, and most of the system’s source code and binaries are available in it. Here we’ve drilled down to the Lisp examples folder. The version numbers given were as they came from the Genera disc; if I had edited these files there would be newer versions, but you can always go back to a previous one and they are always listed. (Even if you delete them, they’re still listed and you can still recover them until you expunge them completely.)
We’re going to now load this Lisp source file into Genera. The file is Conway’s Game of Life ported to Flavors, the object-oriented extension to Lisp Machine Lisp used by all descendent systems that powers the user interface (and many other things).
A typeout window appears with the status, showing it was successfully compiled and loaded into package USER.
We’ll now flip back to the Lisp window using the system menu, though you can also press FUNCTION-1-S as a shortcut as we explained earlier, or just open a Lisp window separately within the file manager itself.
This Lisp file defines a new function (play-life-game) (I’ll get to how we know this in a moment). Genera is so Lisp-oriented that as soon as we type the closing parenthesis, it will call the function.
After a few iterations, it terminates with the return value of NIL.
We’ll switch back to the file manager (with the keys this time) and pull up the file in Zmacs, the editor.
Zmacs is powered by ZWEI, the successor to EINE that we mentioned way back in the early history portion, and is the primary editor on the system. (I may have to write Zvi if I start using this a lot more.) The first line sets the editor mode and the destination package; you can compile source right from the editor. Most of Symbolics’ source is fairly well documented and here it explains that “The function play-life-game runs Life.”
We scroll down and duly find that function (on the Mac console, unless you move the keys assigned to the arrow keys, this can only be done with the mouse). This is the code we loaded and then executed. It, and every other function in this file, is now fully part of Genera. If we saved the world at this point, it would have a copy of the Game of Life in it, and it would always be available every time that world is loaded.
You’ll also notice that the editor pane is only taking up part of the screen, and that there is a blank area with a pattern over it. That’s one of the windows behind Zmacs.
From the right-button menu (either window operations or the system menu), we can expand it to make it take more space. This is actually a general way of resizing and moving any window.
This brings up the window’s frame which you can move and distort. Here we’ll drag it to take up the entirety of the available screen.
Any window can be manipulated in this fashion. Many permutations and screen layouts are possible with this and other options.
Besides the tree view, the file manager offers various special operations that can be performed on Lisp volumes. The level 2 operations (the second grouping) are relatively straightforward, things like making backups, looking at the FEP file system and expunging deleted files completely. However, level 3 as shown here starts getting more low-level, things like altering and initializing partitions, and you get a special warning message.
Let’s go back to the Lisp Listener and look at systems now.
In Symbolispeak a system is a bag of system components that can be loaded on demand into Genera, including both the actual binary code and any documentation for it. The RPC facility used to interoperate with MacIvory, for example, is a system which is already part of the default world. The Load System command can enable other systems that are installed in the file system but not currently loaded. Our completion list gives a few, though it doesn’t list them all. As configured earlier when we talked about the SYS.translations file, all of the system definitions live in the Ivory System Folder and end with the extension *.system.
Systems can reference and load in other systems, so the first thing that Genera does is collect all the (sub)systems thus referenced. This hits our first error due to the filename length limitations of HFS. Again, however, Genera’s flexible error handling saves the day. You should have already renamed these long names as I indicated earlier, so now you can just change the name it’s looking for (you have to do it twice because it checks the file twice). Remember to do this step again when it gets to the second such file.
After the system definition files are scanned and loaded, Genera starts loading code and documentation and prints a running list of its steps. By default this list is paged with a MORE prompt and will wait for you to press a key before continuing. If this annoys you, especially because a large system like this one might take a good minute or so and you’d like to get a beverage while you wait, press FUNCTION-M (i.e., for X F3-M or for the Mac F9-M) to toggle paging on and off globally.
The process finally completes. It should be possible to rewrite the definition files to point to the new name(s), but I haven’t done this yet or looked to find all the places it would need to be done in.
In the Document Examiner, we now have new documents for the Symbolics C package and can open and read them.
Similarly, a new activity called C has been added to the system menu.
This is the Dynamic C Listener. It’s like the Lisp Listener, and understands the same commands, but adds new commands specifically for C.
For example, a limited REPL will accept things like ,printf(“Hello world!”); (the comma is required) and evaluate them on the spot, much as the Lisp Listener would do with Lisp code.
For more substantial programs, you can create a C file with Zmacs. Here, we’ll go back to the Document Examiner and pull out this sample program, and then mark it to copy.
We highlight it (underlined) with the mouse and then push it on the kill ring, which you can think of as Genera’s system clipboard.
#include <stdio.h>
#include <math.h>
main_quad()
{
int a, b, c, d;
double drt, x1, x2;
printf("\nSolves the equation ax(2) + bx + c = 0");
printf("\nfor x.");
printf("\nEnter values for a, b and c: ");
scanf("%d %d %d", &a, &b, &c);
d=((b*b)-(4*(a*c)));
if (d <= 0)
{
printf("This program cannot solve a quadratic formula whose");
printf("\nresult is an imaginary number.");
}
else {
drt = sqrt((double)d);
x1=(-b+drt)/(2*a);
x2=(-b-drt)/(2*a);
printf("The value of root one is %f ", x1);
printf("\nThe value of root two is %f ", x2);
}
}
One thing that is particularly interesting about Symbolics C is that you can call existing Lisp functions from it, using declarations like
lisp "global:reverse" lispobj reverse(lispobj list); lisp "global:print" void print(lispobj anyobj);
You can also create your own Lisp functions that C can call, too. Consider this Lisp code:
(defun c-user::|listarray| (array-pointer-object array-object-byte-offset count)
(loop for i from (floor array-object-byte-offset 4)
for count from count above 0
collect (aref array-pointer-object i)))
This creates a function |listarray| in the C-USER package (not the default Lisp USER package). The prototype extern lispobj listarray(int a[], int count); then allows you to call it, and the Symbolics C runtime handles the call and marshalling the parameters and arguments. It’s possible to call C code from Lisp, but again this isn’t nearly as straightforward.
Finally, there are other activities on the system to play with other than the ones that turn up in the system menu. The Select Activity command launches these, and of course there is a completion menu for it. We’ll select the Terminal.
The Terminal is in fact a Telnet client and here we’re connected to the POWER9 system (yes, I need to update the Linux kernel, thanks). Again, any system you want to connect to should have already been defined in your site in the Ivory System Folder and marked as having the Telnet service.
Mac Genera has some tricks up its sleeve too which are themselves part of a Genera system. Remember that HyperCard stack I pointed out way the heck earlier? That stack uses an external function (XFCN) module to do RPC with Lisp, letting you drive the MacIvory card from the Mac side. You can create your own native Mac C applications that do the same, too.
The HyperCard support is in the HyperCard-MacIvory system, so we load that. If you intended to do this a lot, you’d save the world in advance so that it’s ready to go when your application is.
Next, we’ll start the stack in HyperCard.
This portion here, where you can send Lisp to the card and have it executed, does seem to work, at least for simple Lisp. For example, I’m having it evaluate
(defun fact (x) (if (< x 2) 1 (* x (fact (1- x))))) (fact 6)
which defines the function fact (factorial) and then correctly computes 6!, which is 720. Math wouldn’t be the strong suit for a setup like this: the 50MHz 68030 in this IIci runs rings around the slower Ivory at integer math, and this MacIvory doesn’t even have an FPU. However, the Ivory can handle much larger data sets than the ’030 can and it can do it separately of the ’030, which is free to maintain the console and other Mac applications. That sort of large-set data crunching could be very useful to hand off, though I wouldn’t likely create such an application purely in HyperCard, of course.
A more fragile one is the demo portion that lets you send commands to a Dynamic Lisp Listener. Something straightforward like listing files works.
On the other hand, a more complex command like Show Users @MACIVORY will apparently bug out or stall. What seems to happen is that some commands’ typeout will throttle the RPC link until the typeout is cleared (you can go into Genera and press FUNCTION-0-S to unblock the RPC client, as you’ll see when you switch apps back). That makes this facility less useful for arbitrary commands, though I guess you could make some sort of script to drive the Lisp Listener with commands you know will work. Unfortunately, the other demos seemed to be unable to make any RPC link at all.
By the early 1990s the AI Winter’s frosty bite was acutely felt through the industry, and while Symbolics largely had the Lisp AI market to itself, there wasn’t much market left to have by then. Nevertheless, as Ivory finally fumbled towards the surface in 1987 a second project was already trying to create its successor. Sunstone’s performance was intended to be over triple Ivory’s and up to twenty times faster than the 3600s, yet it could serve as a drop-in replacement in a future XL400-type system that could additionally be sold as an upgrade to existing ones. It was also a 40-bit machine and used the same data structures as Ivory, but instead of the classic stack architecture was a more conventional RISC load-store design with specialized Lisp operations in the instruction set. This was intended to make Sunstone much faster at Lisp but make it more feasible than Ivory for running other programming languages if desired as well. Although simulations showed promising performance against Ivory and competing RISC designs like MIPS-X, it never reached prototyping because Symbolics was running low on dough, and Sunstone ended up cancelled allegedly the very same day it was supposed to tape out.
Instead of a hardware Lisp machine, Symbolics instead turned their waning development resources to creating a software one. DEC Alpha’s emergence in 1992 shocked the industry with its high speed and exceptional performance, achieving 192MHz in the first version of the 21064 at a time when the Intel Pentium could only eke out 66MHz a year later. For Alpha systems running Digital UNIX and later Tru64, Symbolics developed a Virtual Lisp Machine which could directly interpret Ivory opcodes and, with emulated devices, run a standard Genera world. Although not as fast as Sunstone was claimed to be, the VLM was still ten to fifteen times faster than the 3600s even on the first Alpha chips, and thus was shipped the 1.0 release of so-called Open Genera in 1993 (simultaneously with Genera 8.3, the last release for hardware Symbolics systems, and the version we were using here). On my AlphaPC 164LX with a 600MHz 21164A, Open Genera runs pretty spiffy indeed in Tru64, and it serves as my second “Lisp machine” even though it’s only so in software and I’m not usually running it.
Sadly, Open Genera couldn’t save Symbolics; even as a much cheaper emulator it was still too pricey for what was regarded as a legacy product. As a desperation effort Symbolics’ assets were sold to a new company headed by none other than Russell Noftsker himself in 1995, but this next iteration quickly had cash flow problems of its own and reorganized under Chapter 11 bankruptcy in 1996. In 1998 the modestly upgraded Open Genera 2.0 was released, the last official version for the Alpha, and in 1999 the remnants of “new Symbolics” were finally bought outright by the reclusive Andrew Topping. Topping retained the rights to Symbolics hardware and software while licensing sales and maintenance contracts to David K. Schmidt. As many of these contracts wound down and were not renewed, most of the few remaining facilities were closed, and Topping himself passed away in 2005.
Schmidt provided service and remaindered sales to contract customers and some end-users as (now) symbolics-dks.com, which is at least ostensibly still in business, and the $4500 doorstop I bought in 2015 was one of his systems. DKS, however, has no rights to the hardware or Genera itself; these were bought at Topping’s 2009 estate auction by MIT CSAIL’s John Mallery, who to date despite plans to open them has yet to do so. The former symbolics.com domain name, the first .com domain in 1985, was purchased separately and now is such a shadow of its former self that I refuse to link it here. Today the Lisp spirit lives on in two major ways: an unofficial port of the Virtual Lisp Machine, first to x86_64 by changing the code generator to emit C instead of Alpha assembly, and then to PowerPC G5; and Portable Genera, an official port of the VLM to Intel and ARM done under contract for existing customers. While this version isn’t publicly available as of this writing, it’s still actively developed.
As a footnote, it should be mentioned that the LMI/TI and Symbolics lineages were hardly the only Lisp machine families out there, though they were available in the largest numbers and are certainly the best known. Probably the most notable of the also-rans was BBN’s Jericho, based on Interlisp, which never shipped as such but strongly influenced the 1979 Xerox 1100 (“Dolphin”) and its successor line of Lisp machines. These machines became more famous as the hardware basis for the Xerox Star, among others. Xerox itself had plans for its own Lisp RISC chip but it’s not clear if it ever got past the design phase. Some smaller efforts occurred in Japan and Europe, including from Fujitsu, Toshiba and Racal-Norsk.
But as for me personally, I’ve finally got the damn thing stable and fully configured. I would further argue this IIci is the smallest practical true-hardware Lisp box you can build: a IIsi with an MI3 on a NuBus bridge can’t network and has to rely on anaemic internal video, the Q700 is the same size, and everything else is larger. In fact, it runs pretty well now, enough even to do some other tasks on it, so my fury at last has receded.
Somewhat, anyway.
https://oldvcr.blogspot.com/2024/10/refurb-weekend-symbolics-macivory-lisp.html
date: 2024-10-11, from: Linux Magazine
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
http://www.linux-magazine.com/Online/News/The-Gnome-Foundation-Struggling-to-Stay-Afloat
date: 2024-10-11, from: Digital Antiquarian
The Voyage of Magellan, Chapter 16: The Happy Thieves
https://www.filfre.net/2024/10/this-week-on-the-analog-antiquarian/
date: 2024-10-10, from: Richard Murray’s blog
That’s it, I’m dead, you’re dead, we’re all dead.
https://heyrick.eu/blog/index.php?diary=20241010
date: 2024-10-10, from: RiscOS Story
This coming Saturday – 12th October – is the next opportunity for anyone with an interest in RISC OS and software development to gather together in front of the virtual fire for an informal chat. These meetings, which take place more or less monthly using the Zoom video conferencing system, are a way for people with that interest to get together and discuss anything related to programming on and for RISC OS. There is no pre-set agenda for these meetings, and no speaker arranged ahead of time. Instead, their informal…
https://www.riscository.com/2024/developers-fireside-chat-12th-october/
date: 2024-10-09, from: Richard Murray’s blog
My friend is fine, Hurricane Kirk, Printer Weirdness, Writers have no sense of scale.
https://heyrick.eu/blog/index.php?diary=20241009
date: 2024-10-09, from: Linux Magazine
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
date: 2024-10-09, from: Icon Bar, RISC OS News
The next ‘fireside’ chat is on 12th October (this saturday). It starts at 7:30pm UK time and the event is on Zoom. Stay for as long or as short a time as you like.
http://www.iconbar.com/comments/rss/news2102.html
date: 2024-10-07, from: Richard Murray’s blog
Hello?, Tilley?, The drain is done, ADHD and sleep, Mood adjustment basket, Writers have no sense of scale.
https://heyrick.eu/blog/index.php?diary=20241007
date: 2024-10-06, from: RiscOS Story
Issues with the venue at which it has been hold since its inception meant that the RISC OS London Show hasn’t been held for a couple of years, and that following one brief reappearance after the hiatus caused by COVID. However, this year it’s back in a new location, and it’s time to get your travel plans sorted if you wish to attend – and why wouldn’t you? Getting the most important information out of the way first, the show is set to take place on Saturday, 26th October –…
https://www.riscository.com/2024/london-looms-just-three-weeks/
date: 2024-10-06, from: RiscOS Story
An updated version of the Hexen port to RISC OS is now available from R-Comp. Version 1.08 of the port has been released to resolve a number of issues reported by players, and also brings the code into line with that of the updated Heretic. Players with very high resolution screens will enjoy the support for up to 8K screens, but there are also a number of fixes – such as improvements to the enhanced widescreen support that appeared in versions 1.07, which extends the view horizontally, filling in detail…
https://www.riscository.com/2024/hexen-port-1-08/
date: 2024-10-06, from: RiscOS Story
Kevin Wells has released a new version of TimeZones, his application that can be used to establish whether, if you called someone elsewhere in the world, it’ll be stupid o’clock in their time. Version 2.00 of the software marks a rewrite, which Kevin undertook due to changes to the application programmer interface (API) that the application uses (by way of Wget to communicate with a remote site – in this case WorldTimeAPI to relay the information requested by the user. In addition to supporting the revised API, when launched the…