System 7 Accessing Mac OS X file servers

Using my MacIvory, until now, I have been using an old Mac Powerbook running Mac OS 9 with AppleTalk file-sharing to allow me to copy files from a USB key to the Mac IIfx host running 7.6.1. Trying to access shared folders on my newer laptop running Mac OS X failed, as did sharing in the opposite direction.

Presumably, the problem is that Mac OS X uses a revision of the AFP file-sharing protocol which is incompatible with the version used by the default Mac OS 7.6.1.

It turns out there is a fix for this issue:

1. Install Open Transport 1.1.2 (a dependency for the next step) on the 7.6.1 Mac
2. Install AppleShare Client 3.8.3 on the 7.6.1 Mac

The Apple article on AppleShare Client 3.8.3 has more information on this release of the software.

Apparently AppleShare 3.8.8 requires System 8.

MacIvory ADB Adapter Protocol

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.

Learning more about PIC

A few comments about the PICkit 2 learning experience.

There’s a slight bit of polish that could be applied to the example code.

1. 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
2. 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.
3. 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 used instead

I also got bitten by the issue mentioned briefly in the PICkit 2 release note: if you program the examples from the IDE, the IDE forces the line controlled by the push-button low, meaning the push-button examples fail to work, unless you program the device from the dedicated programming application and the .HEX file produced by the IDE.

I am slightly disappointed that there doesn’t seem to be any visible progress getting the PICkit 2 with version 2 firmware to work under Mac OS X.

Also, I find a real lack of documentation of the PICkit 2 “Debug Express” support for in-circuit debugging. This may be because Microchip doesn’t want to undercut sales of the MPIDE 2 hardware. I think, however, one can use a combination of the AC162061 (containing an ICD version of the 16F690) and AC164110 (to convert the ICSP six-pin interface to the modular plug used by the usual ICD interface) to do in-circuit debugging of 16F690 applications with the PICkit 2, at an additional cost of about $50.

I’ve started sketching out some ideas for interfacing the Symbolics keyboard on a dedicated page.

[UPDATE: Microchip does, after all, document the PICkit 2 Debug Express hardware requirements (scroll down a bit to see what I missed before.) I ordered the combination even before I found the document, and when the backorder is filled, I will be giving it a try myself.]

[UPDATE: Jeff Post announced that he releasing alpha code supporting v2 firmware for the PICkit 2 on Linux/Mac OS X]

Making lights blink…

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 keyboard apparently implements, but if the microcontroller does anything beyond driving the LEDs on and off based on simply counting the corresponding keystrokes, I might be sunk. I’ve fired off a few questions to people who can hopefully tell me that all of these are plug- and wire-compatible.

As for the 3600, it is pretty obviously a matter of pulling the reset line low to clear the counters, and clocking through the other 127 counter states to read off the switch matrix closures on the 16 X by 8 Y (I surmise that high on the output would mean the corresponding key is down.) I’m not sure how frequently I have to collect the bits to avoid missing keypresses, and what debouncing I might have to do.

The strange thing about my Rev C is that the ICs driving what I guess is the X direction are a pair of 74145 devices with what the datasheet claims are open-collector outputs, and the IC connected to what I guess is the the Y direction is a 7442 with conventional TTL outputs. That seems to mean that scanning an X column with a pressed key causes an open-collector pulling low to compete with the TTL high output on the Y row, except when the Y scan tests that line with a TTL low. What good that does is a mystery. That, and I haven’t finished tracing out the part of the circuit with an LM319 comparator. The 3600 schematic drives the X columns (one low, the rest high) and muxes the Y rows (driving ordinary inputs through any pressed keys) to the readout.

[UPDATE: Seems that the keyboard protocol should be identical, so I’m going to forge ahead with the plan, and assume the circuit knows how to work itself.]

[UPDATE 2: fixed the link to the online 3600 schematic.]

[UPDATE 3: I probably should have given more explicit acknowledgment for the inspiration of the project. If I had not seen asciilifeform‘s schematic revealing the simplicity of the protocol, I’m sure I would have been far less tempted to start this project.]

MacIvory speaks!

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 which Mac OS X refuses to acknowledge. Luckily, I’ve got a PowerBook G3 that runs Mac OS 9. My first ethernet card didn’t work, either because I screwed up some software setting or because the hardware was bad. (More embarrassing disclosure later.) DKS sent me a replacement, which worked immediately. I’ve only got ChaosNet configured on the MacIvory side at this point, and my ChaosNet work isn’t up-to-date on my Powerbook, so I’ve only seen raw ethernet packets in tcpdump, but my archaeology is already progressing—documentation to follow soon, as well as getting some Python software (with libpcap or Mac OS X kernel packet filters?) to respond to Chaos-formatted Ethernet packets.

As for the embarrasing disclosure, one of the first things I did was try to set the video card to a mode not supported by my Sony Multisync 15sf monitor. Instead of waiting for the change to timeout and revert, I hit Esc or Command-. or some other key which confirmed the change, leaving me with a blank screen. I tried various reboot, PRAM zapping, or magic key sequences to force the Radius Precision Color 24X to a good mode, but none of that worked, and at some point I screwed up the system. Once I hooked up the Dell 2007fp that understood 1152×870, I saw the floppy-with-blinking-question-mark. Recovery without a working network card involved the ancient hassles of multiple-floppy installs.

I have a Kensington ADB multi-button mouse, but all the drivers I have downloaded are either for Mac OS 8 or cause serious bugginess: system freezes or error -192 when launching the configuration application. I hope I don’t have to roll my own software to get multi-button goodness to work with the Ivory. (At this date, few vendors pay much attention to 68k Macintosh support.)

UPDATE: I’ve captured a bit of the tcpdump results in my ChaosNET information page.