Brasstacks

I've been playing around with the MacIvory FEP (Front-End Processor) to learn more about how the Symbolics Ivory environment gets started. Not everything is yet clear to me, but I wanted to record some information about the "cold load" environments files. The Ivory chip uses 40-bit words, where 32 bits make up the "address" or immediate portion of the word and the upper 8 bits are a combination of type tagging and "cdr code" flags which allow for compact representation of lists and, in code, program counter sequencing flags to allow for half-word instructions to be compacted around full-word instructions in the stream. A lot more information can be learned from a number of sources. The previous generation "3600" machine was disclosed pretty widely in the literature, and ideas like type-tagging and cdr-coding are very similar between the machines. Bitsavers has a few files scanned from internal documentation. Most informative are I-Machine Ar...

The previous notes don't seem to work in all circumstances. In particular, trying to enable a CHAOS networking port in .VLM configuration causes NFS to fail in the writing of the Site file. I have been unable to diagnose this as it appears the VLM stops trying to use NFS to access the file after starting a write, and then times out, not even showing any activity on tcpdump when a restart is attempted. It's possible the presence of a CHAOS interface causes it to expect NFILE or perhaps it decides to prefer FTP over TCP. In principle, it should be possible to invoke the debugger on the VLM to understand what is going on, but all the networking is very flexible and elaborate and I have no idea how to debug Genera at this point. On the Linux side, I can find nothing at all that shows an error or misconfiguration or anything at all once the problem starts. After defining the site and saving an incremental world, adding a CHAOS interface seems OK, but I have been stumped trying to ge...

There are some existing guides to setting up the (unauthorized) Open Genera VLM on x86-64 Linux, but I wanted to tweak them a bit, and came up with a couple of items that diverge from the existing advice. Note that a bunch of URLs on that link should point to https://archives.loomcom.com/  not the static.loomcom.com address. My general goals were to avoid having to run the genera binary as root, and run as a distinct user to have some sense of security (even if the sense is misplaced). I also wanted to change the network addresses, and don't want to use the standard pathnames for the Unix system files and the user directories, and the changes to do so were only in screenshots. My setup Ubuntu 18.04.4 LTS, amd64 My Linux machine is named ubuntu I want all this simulated Genera stuff to happen on  subnet 10.0.10.x  with my Linux host under the name  genera-ubuntu  at 10.0.10.1  and the virtual Lisp machine genera  at 10.0.10.2  (...

Hans Hübner has been at it again, and has developed code to allow a  Teensy AVR development board to adapt a Symbolics keyboard to USB . I ordered a Teensy board of my own, and was hoping to develop a small adapter to avoid cutting up my keyboard cable, but Teensy does not work with my old Mac OS X 10.4 system.

I wanted to post a link referring to recent progress on adapting Symbolics keyboards to modern PCs. Hans Hübner announced that the kbdbabel project (apparently based on 8051 microcontrollers) was able to be adapted to support the slim-line (Rev. C) Symbolics keyboard, adapting it to PS/2 protocol . My own work in this area ground to a halt pretty soon after I received the ADB adapter from DKS. I'm happy to see that others have been able to make progress! UPDATE: Rainer Joswig has commented on his experience using the kbdbabel adapter to connect a Symbolics keyboard to a Macbook running Mac OS X . UPDATE 2: Hans has developed a USB adapter solution .

As I alluded to in an earlier post, Symbolics Genera takes a slightly different approach to packages than most current environments (such as SLIME under Emacs). Part of that is because, unlike GNU Emacs today, the editor and all its intelligence is running inside the Lisp environment; another part is due to Genera supporting multiple dialects of Lisp, each slightly compatible with the other. One consequence is that Zmacs pays close attention to the "file attributes line" in your Lisp source files. (That's the line at the beginning of the file which contains the marker "-*-"). Other Lisp environments use a heuristic, like looking for the first IN-PACKAGE form. A chicken-and-egg problem arises when loading a file that expects to be read in a particular package. What if the package doesn't exist? Well, it isn't possible to use that package to read the file. But the package itself is defined in a file. For me this caused a bit of confusion, because i...

Having hacked on the COMFY code for a while in Emacs Lisp, I got the itch to move it over to my MacIvory, which has been waiting for real work to do. I've crafted some tests in the Emacs Lisp using elk-test (trying to add heirarchical suites-of-suites along the way), and wanted to port them to one of the Common Lisp test frameworks (I'm thinking of checking out Stefil, LIFT, and rt, which I've used briefly). While copying the files, I ran into a few issues. I couldn't figure out an automatic way to handle line-ending issues in the text files. I ended up locating the file on the Mac OS side in the file browser, Mouse-R clicking to Edit the file, then M-%, C-q [LINE key] [Return] C-q [Return] [Return] ! in Zmacs, then saving to a file on the Ivory file system. (I like the offer to create non-existent directories on a save.) There is probably a Copy File(s) command I could have used to move them en masse, and I should have been able to code up a quick conversion routine...

Working with ResEdit and DeRez, I believe I have traced out the keyboard protocol used by the MacIvory ADB adapter . My adapter is on the blink, probably because of the small screw I found rattling about inside. I hope DKS can bring it back to life, or the PIC-based project I had begun will make its way back to the front burner.

The ADB adapter has not just given me some help uncovering the behavior of the Rev. C Symbolics keyboard protocol, but also works when attached to my MacIvory. Along the way (and with the help of David K. Schmidt) I encountered some glitches, mostly stemming from my original accidental trashing of the System file DKS installed. There are a few software components the ADB adapter box needs to convert the Symbolics keyboard to something the Mac OS 7.6.1 (including the "FEP" window which communicates to the Ivory board on a low level) will accept as a keyboard with the right keymapping, and furthermore to something the Genera application will recognize with all the Symbolics-specific keys. Without these components, you will see one of the following two stages of malfunction. Stage 1: The mouse connected to the ADB adapter works fine. In the Mac OS (including the FEP window), there is total keyboard confusion, with the keys all scrambled. On the Genera side, things are less ...

The ADB adapter has fulfilled its main purpose: providing an example of hardware which can speak to my Rev. C Symbolics keyboard. The apparent trick is that the clock pulses must be narrow, without being too rapid (i.e., a relatively low duty cycle.) A 10 microsecond long low pulse on /CLR, followed 30 microseconds after the beginning of that pulse by the clock going low for roughly 9 microseconds, continuing with a clock period of approximately 50 microseconds does the trick. The ADB adapter pauses somewhat between groups of 11 clock pulses, corresponding to the natural "section breaks" of the keyboard mapping; I don't know if that is strictly necessary. My first crude approximation, using bit-bashing for the PIC with timing loops resulted in Caps Lock and Mode Lock that felt a bit sluggish---needing to be held down relatively long to "lock" or "unlock." The overall cycle time may be important in that regard. In any event, I reconstructed the key...

David K. Schmidt evidently scrounged up another ADB converter box which he just sold to me. Assuming I haven't blown up my Symbolics keyboard, I may finally have what I wanted: a piece of hardware that knows how to talk to my Rev. C keyboard! I hope that will shorten the time to coerce my PIC circuit to do the same.

Step 1 in the Symbolics keyboard to PIC project was not as quick as I had hoped. It was pretty easy to generate the reset pulse, and get the serial port to send a clock signal to the keyboard. I then was using an oscilloscope to look at the keyboard response, but various attempts to get the PIC code to light up LEDs in response didn't work at all. In fact, I was being bitten by two bugs, which I used the PICkit 2 in-circuit debug to discover. An array overrun bug (it seems the default radix in MPASM is hex, so reading 16 bytes into a sixteen element array doesn't work! Unfortunately, my byte counter was located after the array, was stomped directly from 6 to zero, missing the "decrement and skip if zero" termination test until the array covered well into register bank 1.) Safety tip of the day: put your counter before the array! Something not addressed in the early lessons: ANSEL. The RX/DT pin of the 16F690 is shared with AN11, and the low bits of PORT C drivin...

The first step is to connect the Symbolics keyboard to the PIC. I am using the 16F690 which comes with the PICkit 2 starter kit on the low pin count demo board (Microchip DM164120-1). The keyboard cable mates to a 6-pin modular jack (such as Digikey part number 609-1061-ND), which I tacked onto the side of the board. Unfortunately, this mod jack has pin spacings of 50 mil "horizontally" between successive pins, so I bent up the odd pins and soldered the even pins to the demo board. Mod jack pin Keyboard function PIC function PIC pin marking 6 GND 5 GND (N/C) 4 Vdd 3 Key Data RX/DT RB5 2 CLK TX/CK RB7 1 /CLR RC5 RC5 My first task will be to power up the keyboard, code a scanning loop, and try to detect keystrokes for a single key, such as the Left Control Key, displaying the count of key-down events in binary to the LEDs connected to RC0-RC3. If the keyboard is not debounced by the internal microcontroller, the count will not inc...

I made a little exercise out of compacting the example "switch debounce" code that the PIC tutorial examples uses. My next exercise will be to improve the debouncing in the "reverse variable speed LED rotation by pressing switch" by interleaving the debouncing check into the delay loop. As it stands, when the rotation is slow, the example can miss brief switch pushes. My glorious savings of three instructions is documented on a separate page . One nifty trick I found through Google that might be very helpful if I have to debounce 88 keys on a Symbolics keyboard (naturally, the same number as on a piano) is called " vertical counters ." This consists basically of replacing counter increments with boolean operations, which can be easily performed in parallel, if the corresponding bits for multiple counters are grouped in register-sized words. This page shows how to use a four-count two-bit vertical counting scheme to debounce eight switches in paralle...

A few comments about the PICkit 2 learning experience. There's a slight bit of polish that could be applied to the example code. A few redundant instructions, such as Extraneous operations setting register pages In A-to-D examples, the data sheet seems to say the 5 microsecond settling time is needed only when changing the input source, not for every conversion, as in the examples For the 5 microsecond interval, a few of those microseconds are covered by the non-NOP instructions before the conversions In one of the variable-speed rotating bits examples, the carry flag is not explicitly cleared when it needs to be clear. When I modified the example to change the sign of the pot setting-to-delay conversion, I would sometimes set the carry, putting extra bits into the display. Took me a good fifteen minutes to debug that. I think a few extra instructions are wasted using the W register and an explicit move to the file register when the file register destination could be...

My latest diversion is a Microchip PICkit2. The idea is to make something that can understand the Symbolics keyboard I have, and then connect that something to other things that can speak Apple Desktop Bus (ADB), PS/2 keyboard protocol, or USB, in roughly that order. If I can make something that takes a multi-button PS/2 mouse and a Symbolics keyboard and connects both to a MacIvory, I could be set for beautiful three-button mousing and classic keyboarding on my Lisp Machine. I've mostly traced out the schematic of my Rev. C Symbolics slim-line keyboard (thank god for simple two-layer boards!). Rev. C has LED's in the Caps Lock and Mode Lock keys, in contrast to this picture of the similar Symbolics Rev. B keyboard . Compared to the Symbolics 3600 keyboard schematic , mine is roughly similar, but unfortunately has a 40-pin microcontroller (an Intel 8749H, a member of the MCS-48 family) soldered in. I am certain I could make something work with the simple protocol the 3600 key...

I've only had a bit of time to play with my MacIvory, but already things are getting interesting. One is getting used to the system administration style: typical UNIX system configuration resides in text files, and the boot process reads them. Genera is different. The state of the system is contained in the memory image ("world"); you change it through various operations---some interactive, some by loading Lisp files---and preserve it by saving a new world as a file, which can be defined incrementally based on an existing world. The boot process involves loading that saved file back into the living Lisp machine. I haven't yet developed the sense to complete a block of tasks before saving the world, and how much change pushes one from incremental to a complete world. Another was getting the network to speak, and part of that is the timewarp of working in Mac OS 7, an era in which Mac networking was going through the introduction of Open Transport, and an AppleTalk era ...

Just sent off the Paypal payment for a MacIvory II system with 2.6 MW of memory. I'm hoping also to get a Symbolics keyboard, although Symbolics is apparently out of the ADB box that allows the keyboard to be used with the vintage Macs. It was a tough call whether to splurge for this or, for about twice the money, a new MacBook Pro. I'm hoping the Symbolics machine will be much more entertaining. My main idea of a project is to use the Lisp Machine as a Chaos FILE host, in order to allow development on the CADR simulator with a versioned file system, without having to simulate and learn ITS or TOPS-20.  To get that to work, I probably will need to do a little bit of investigation to understand how the Symbolics box gets configured to talk on the network, what Chaos packets look like on the Ethernet, how to get those to my Python/Lisp code on the modern machine, and, for data security what would be needed to talk to a CD-ROM drive on a remote computer, or to use a remote com...

My blogging has been much less frequent of late, mostly because of an unfortunate abundance of non-computer issues. Despite those, I believe I have made some progress in my Chaosnet-on-OpenMCL work, but I've switched most of my hobby-development to Python, mostly to get in touch with trends outside the Lisp Universe. My current main project circulates around ChaosNET emulation; the main thing going for Python here is a socket interface that is roughly compatible between UNIX-like and Windows operating systems. Lisp can support that as well, but not for my favorite and familiar implementations. (One thing I hope to try before I get through this is to get an asyncore-like framework set up in CLISP.) So far, I have implemented a `chaosd' process in Python that simulates multiple ChaosNET `ethers' in the form of localhost TCP streams (on Windows or UNIX-like) or UNIX-domain sockets (on UNIX-like); each stream corresponds to a subnet. The idea has manifold goals: Allow the...

Just wanted to capture a few more thoughts; over the weekend, I experienced what I think was my first case of deadlock. My chaosnet-on-OpenMCL implementation had worked just fine when the two sides of a connection were careful to exchange only one packet at a time, taking turns. When I tried to listen to a SEND (the Lisp machine analogue to an instant message), the CADR emulator sent two packets in quick succession, and my OpenMCL process would freeze trying to receive it. As an aside, I get the feeling that I don't really know how to debug this kind of thing in OpenMCL: looking at backtraces does not always make it completely obvious which semaphore or lock is being waited for in the various threads, and I don't think it is possible to look at semaphores to see which thread(s) are waiting. In any case, I concluded that my somewhat haphazard use of a "count lock" to protect access to packet number information in a connection was either being used recursively, or v...