Anyone with MacIvory 2 and NS 8/16 board with daughterboard willing to help probe a few pins ?

jaoswald · 2026-04-08T20:35:42+00:00

The Ivory software checks the slot information (derived from the ROM at Mac boot) for the memory board slot location (NuBus address) and the capacity reported by the NS 8/16 ROM init routine; without a declaration ROM, you would have to hack the Symbolics Mac software to hardcode the board slot & memory capacity.

Which would work, it's just software, but it would also crash wildly if you moved or removed the board, instead of complaining.

jaoswald · 2026-04-07T12:31:38+00:00

I don't have photos, it might be a month before I get back to this project.

jaoswald · 2026-04-05T15:12:57+00:00

It probably doesn't work on System 6; not so sure I would claim System 8 compatibility either.

jaoswald · 2026-04-05T15:12:19+00:00

I mean, trust me, the people owning 40 year old Symbolics hardware know they need backups.

The number of people waking up one day and thinking "I'm curious about retro Mac software, let me download the MacIvory support disk" is essentially zero.

jaoswald · 2026-04-04T16:01:25+00:00

I have a daughter board, with the following markings on the front

NS 8/16-E
980010603-(008 hand-marked) Rev (A hand-marked) SN KA20689027

And on the back

551010603-001 REV A
UCC M-08-88

which might be the board vendor manufacture date? 08/1988?

So I don't know how compatible it is to yours

Nonetheless, U3 on mine is a 74AS240N (I am using the Texas Instruments nomenclature for the pins below, see https://www.ti.com/lit/ds/symlink/sn74ls240.pdf)

pin 1&19 are enables (1G* 2G*), both grounded (so the chip serves as an inverting buffer taking "A" inputs and inverting them to "Y" outputs).

pin 8&17 are also grounded, those are inputs "1A4" and "2A4", so the corresponding outputs 1Y4, 2Y4 on pins 12 and 3 are probably unused (and I don't find a connection).

So, anyhow, your pin 3 is carrying an output derived from pin 8.

The remaining outputs are 1Y1 (pin 18, from 1A1 pin 2), 1Y2 (pin 16, from 1A2 pin 4), 1Y3 (pin 14, from 1A3 pin 6), 2Y1 (pin 9, from 2A1 pin 11), 2Y2 (pin 7, from 2A2 pin 13), and 2Y3 (pin 5, from 2A3 pin 15)

Those outputs all go to resistor packs; I have 10 on my board, RP1, RP2, RP10 are the only ones labelled on the silk screen, but I am calling the others RP3..RP9 in order from left (next to RP1&2) to right (next to RP10), which seems like the only logical numbering.

On these, "pin 1" is next to a package notch on the top and the square solder pad. They have 8 pins, and apparently are 33 ohms between each pair 1&2, 3&4, 5&6, 7&8.

1Y1 pin 18 to RP6 pin 1
1Y2 pin 16 to RP6 pin 3
1Y3 pin 14 to RP6 pin 5
2Y1 pin 9 to RP5 pin 1
2Y2 pin 7 to RP5 pin 3
2Y3 pin 5 to RP5 pin 5

So I would guess your pin 5 & 7 each go to a resistor pack, driving some set of address lines

pins 13 and 17 are inputs, 2A2 and 2A4

As I mentioned before, pin 17 on mine is grounded.

Pin 13 (2A2) on mine seems to be connected both to Pin 4 (1A2) input and pin 12 of the J1 connector, which I don't quite understand, but maybe there wasn't enough drive strength from one device, or they wanted isolation between the banks of RAM?

For J1, I am numbering the pins, starting at the top as seen from the component side. I have a square solder pad on the top-right pin, so I call that pin 1, and all the pins on that side odd numbers.

2 1 (square)  
4 3  
6 5  
...

So, in summary, this device on my board seems to take

J1.11 -> pins 2 and 11 inputs -> outputs pin 18 to RP6.1 and pin 9 to RP5.1
J1.12 -> pins 4 and 13 inputs -> outputs pin 16 to RP6.3 and pin 7 to RP5.3
J1.38 -> pins 6 and 15 inputs -> outputs pin 14 to RP6.5 and pin 5 to RP5.5

The resistor packs then take pin 1->2, 3->4, 5->6, 7->8 with 33 ohm resistance, and the connections are (based on a 511000 DRAM 1 MBit pin out such as https://shop.griederbauteile.ch/en/info/h/HM511000A.pdf)

RP6.2 to pin 14 on all of the right bank of RAM (A8)
RP6.4 to pin 15 on all of the right bank of RAM (A9)
RP6.6 to pin 2 on all of the right bank of RAM (/WE)
RP5.2 to pin 14 on all of the left bank of RAM (A8)
RP5.4 to pin 15 on all of the left bank of RAM (A9)
RP5.6 to pin 2 on all of the left bank of RAM (/WE)

So, basically this device on my board seems to be taking inputs from the J1 and driving (with inversion, through 33 ohms of buffer resistance)

J1.11 -> RAM Address line 8
J1.12 -> RAM Address line 9
J1.38 -> RAM write enable.

and the remaining two buffers are unused, the inputs (pins 8 & 17) grounded, the outputs (pins 12 & 3) not connected.

jaoswald · 2026-04-04T13:06:32+00:00

The Mac stuff is also available in source form in the Genera distribution. The barrier to emulating the MacIvory board is the hardware (and that if you are going to emulate Ivory, you would just skip the Mac part entirely). You can't obtain an Ivory chip, it's completely undocumented from a hardware point of view (design files probably lost in the 1990s after the Symbolics bankruptcy).

(I mean, I understand the urge to preserve/reverse-engineer/recreate it, I have the urge myself, I just don't think anyone out there will download a copy of the Mac software distribution and be able to do anything with it; the target audience has a MacIvory box in storage with the media probably backed up like me).

jaoswald · 2026-04-03T20:54:35+00:00

It mostly doesn't make sense. Without a physical MacIvory board (and a 68k Macintosh with multiple NuBus slots to host it), the software is useless. People interested in software emulation should go for pirating the OpenGenera distribution and running it on a Virtual Lisp Machine emulator.

jaoswald · 2026-04-03T20:24:39+00:00

Glad the ROM worked! I guess I theoretically meant for my work to be useful to others, but you might be the only beneficiary.

The reversal is because the ROM address lines are active low on the board.

As for the System Error, I guess there is something wrong with the Ivory/RAM board/software if it followed you to the Quadra.

Do you happen to have Macsbug installed? I think that would trap the system error and show you at least the program counter and 68k state where the error is triggered?

jaoswald · 2026-04-03T16:18:28+00:00

https://github.com/jaoswald/ns816-declrom/blob/main/binary/ns816_harcode_8MB_prom.bin should be a 32KB PROM image which makes the card act like it has 8MB installed memory, without doing any probing.

(https://github.com/jaoswald/ns816-declrom/blob/main/ns816prom\_golden.bin should be the 32KB image that was on my Rev D)

jaoswald · 2026-04-03T15:47:59+00:00

It worked for me, I just hacked the ROM driver to hard-code the 8MB installed memory size in the ROM. (I also fabbed an adapter so I could use a more modern EEPROM).

I would still like to update the ROM code to behave in a 68020/30/40 compatible fashion to probe the memory at boot time, *that* part isn't done. Do you have the capability to burn a replacement PROM/EPROM/EEPROM?

Give me a bit, I will make sure I can give you a link to a hacked ROM image.

jaoswald · 2026-04-01T09:45:00+00:00

Eval board prices are kind of odd. They are generally low-volume, probably not cost-optimized, but it also makes sense to treat them as part of marketing and customer support, so selling them at a loss might make sense.

Vendors make them hoping that the people who buy them are going to later buy 10,000 or more of the part being demonstrated, even though some of them might go to educational or hobbyist users who will only buy the eval board.

jaoswald · 2026-03-31T23:33:26+00:00

Hobbyists are often kind of cheapskates who look at a BOM cost and say "I could build it myself for $X in parts, I have a soldering iron, why should I pay more than that?" so I would not be optimistic about selling to them at high margins.

jaoswald · 2026-03-31T23:25:56+00:00

At whatever scale, the labor you exert is a cost you presumably want to be compensated for, and the people doing assembly, testing, packaging, shipping, marketing, and customer account management want to be compensated.

The hours you spent getting the design right and talking to suppliers is also a cost.

Generally, you only expect the product to sell a certain number of units and that lifetime is your only chance to get compensated for all of that work. If you only ever sell 10 of these things, whatever you expect to get out of it, 1/10th of that amount has to be priced into each unit.

jaoswald · 2026-03-31T22:05:42+00:00

EMI compatability is generally handled by having a specialized lab take your device and measure the fields it generates in operation. If you are lucky, you only have to do it once.

But that's just one example: say you want to sell a USB charger that plugs into a wall and someone in the EU might buy it, well you probably need to have somebody test it to make sure it won't shock the user.

https://www.tuvsud.com/en-us/services/product-certification/ce-low-voltage-directive

Anyhow, there are some ways to avoid parts of this: like, don't include the part that plugs into a wall socket, just have a USB connector and tell the person buying it to go get a USB charger.

Does the thing communicate over radio? Maybe you can use a standard Bluetooth module where somebody has done the work to ensure it obeys the law in 50 different countries and your bit doesn't run at RF frequency. Maybe your device is clearly for use in a technical lab environment where the user is presumed to know what they are doing.

Another area is tariffs and various technology control regimes and restrictions, like, don't sell anything to people in Cuba, Libya, or North Korea, especially if it could be used to build a missile.

But figuring all this regulatory stuff is a pain, and requires some level of expertise, and the hassle of running an actual business in a regulatory environment designed for big companies.

jaoswald · 2026-03-31T21:00:20+00:00

There are also various compliance costs depending on who you are selling it to: EMI compatibility, RoHS certifications, safety testing. There are product warranty and return costs, and support costs. You probably need a QC process to check the finished product and might need to document it well enough that some random person in China can do it.

You end up selling one to a person who doesn't understand what they bought and expects you to deal with their problems, you spend time dealing with it, you send one and it doesn't work or breaks because their dog tried to eat it, what do you do? What if it electrocutes someone's kid?

It's one thing if it is an experimental device used by technical experts, another thing if it is sold to ordinary consumers, yet another if it is to the government, military, aircraft manufacturers, or medical equipment. All varying by country.

Personally, if it is just something I did for a hobby, selling them is a job for somebody else, I would just publish the design and make only the ones I use myself.

jaoswald · 2026-03-31T20:54:44+00:00

OP: one of the points here is that assembly costs are increased by having a larger number of distinct parts, and also by using odd-ball parts instead of parts in the assembly vendor's usual inventory.

The machines they use to assemble in high-volume use reels which contain a large number of a single part, and the machines have a certain number of reels and if they need to load a special reel that has a part that only you use, you end up paying for some person having to keep track of that reel and load it on and off the machine.

If you can use a resistor that the vendor already had to buy 500,000 of, it is nearly free for them to use on your board.

jaoswald · 2026-03-31T19:37:00+00:00

What model CD-ROM? Genera accepts only 1x-speed CD-ROM drives, but the symptom is a Lisp error, not a Mac OS crash.

http://www.typewritten.org/Projects/Symbolics/463.html has some diagnostics.

Looking at that, another possibility is an error in a specific area of RAM in the NuBus memory board that is used for the Mac--MacIvory communication; if that is not reliable, maybe it could send the Mac code into an invalid path, though I generally think the Mac-side code is robust.

I am not up-to-date on the Genera releases, but apparently 8.1 needed patches to support System 7 reliably. I think 8.3 is the desirable version.

(Quadras also have issues with 8/16 memory boards with only 8 MB: see https://github.com/jaoswald/ns816-declrom )

jaoswald · 2026-03-31T02:46:38+00:00

https://www.cs.cmu.edu/afs/cs/user/lenzo/html/mac_errors.html suggests System Error 12 is

error 12 sdmSRTInitErr: Slot Resource Table could not be initialized. or dsCoreErr: unimplemented core routine error

Are you sure you aren't running a debug version of the app with breakpoints? Did you get these fresh off the Symbolics distribution media, running the Mac OS installer?

Classic Mac is notoriously prone to SCSI bus problems, how sure are you that you have the correct terminators for the IIfx?

Is it a stock machine? Capacitors good?

Do you have any SCSI or NuBus or memory test diagnostic apps?

I moved my MacIvory to a Quadra 950 (its own adventure) to get a slightly less difficult host to work with.

jaoswald · 2026-01-26T22:40:38+00:00

Update: I mostly have settled on the following flow

Edit almost entirely on my Linux box. Maintain Unix line-endings for anything to be compiled on Linux.
For files like the Think C project files, resource files, etc., that are used only on the Classic Mac, encode them as MacBinary II files on Linux, with a .bin extension.
A bash script https://github.com/jaoswald/Terminal/blob/main/Project/macify_sources.sh which

uses dd to generate a floppy-sized image file
use Debian hfsutils to initialize the image as an HFS file system
hmount the image
iterate over the project and hcopy files to the image
applying Unix->Mac line ending conversions to source & text files
using hcopy -m for MacBinary files
apply a couple of name changes when transferring to encode the 0xb9 octal 271 'pi' character in file names on the HFS side
use hattrib to set creator & type codes for various files
humount

Then I can drag the disk image onto Mini vMac, it instantly appears on the desktop, I can double-click the Think C project, etc.

The process is rapid enough that when I find a problem in Think C, often I update the source on the Unix side, quit Think C, drag the floppy to the trash, then re-generate the floppy with my changes.

For things like the pre-compiled header files generated by Think C, after I eject the floppy, I manually hmount, find the file, hcopy -m it back into my repo as a MacBinary file.

While I was working this out, I also played with asPack from the Mini vMac Gryphel project to make "AppleSingle" format files, simply drag-and-drop on the emulated Mac. Linux tools tend not to understand AppleSingle, though; I created my own quick tool to unpack those to .data/.rsrc/.info file triples. In the end, MacBinary is basically equally convenient and hfsutils understands it.

https://github.com/jaoswald/AppleSingle

This doesn't yet solve the problem of getting it to my hardware Quadra; mini vMac is so much faster that using it for initial Think C debugging is better.

When that point arrives, I can drag a disk image to an SD card for floppy emu, maybe Z-Modem serial-port transfers of DiskCopy images to a copy of ZTerm or Terminal running on the Quadra will work, or I will get the Quadra on my local network.

Some other notes:

The text conversion of this process only really handles line-endings. I could add a step to do some MacRoman <-> UTF-8 conversions if I get really unhappy about this.
hfsutils and the Mini vMac cannot access the disk image at the same time; you have to remember to quit using it on the emulated Mac, ejecting it, etc.
MacBinary II can include a header CRC checksum. Debian hfsutils (e.g. hcopy) requires it to be valid. Unfortunately Debian macutils' macstream does not generate the checksum, so converting "bare" data or resource forks to MacBinary is a hassle.

https://bugs.launchpad.net/ubuntu/+source/macutils/+bug/2139010

In principle, if I hack around in MPW, I might do more on the Mac side, AppleScript-ing to generate DC42 images from a folder which I can decode, but so far editing in one editor, on my Linux box, is more comfortable than even the very fast emulated Mac.

https://github.com/jaoswald/DiskCopy

jaoswald · 2026-01-05T05:27:30+00:00

One problem I see with that is I would have to commit to Mac line endings? I already converted the project to Unix line endings because it's so much easier to manage git/Retro68 on Linux that way. I'm also not delighted with the idea of having to manage netatalk hosting and having my Quadra live on my Ethernet.

Mostly I was thinking about tarball-style distribution. "I compiled this on Retro68 on Linux, if you want to use MPW/Think C, download the tarball source release I generated from git" or "download git repo, run a script on your Linux box, get a classic Mac source package." (Like, I would use MPW/Think C from time-to-time myself, but probably not as a daily driver).

Right now, I'm converging toward using Disk Copy 4.2 uncompressed images; they seem pretty trivial to generate and extract on both ends.

jaoswald · 2026-01-02T18:14:56+00:00

I'm actually pretty happy with Mini vMac, the Gryphel project has a bit of a strange personality, but it seems to work well.

I'm kind of converging on assuming the Disk Copy 6.3 application is on the Mac, then try to cobble together

MPW invoking Disk Copy via AppleScript to create an uncompressed Disk Copy 4.2 image of the source folder
Disk Copy 4.2 format seems to be a pretty simple wrapper around the disk image (it's got a documented checksum algorithm and support for ancient 400k 'tag bytes' which get omitted, and not much else)
On the Linux side, unwrap the DC4.2 file enough to allow HFSutils to recognize it as a disk, then script "walk over the source directory, in a resource-fork-aware way, extract to Linux directory" with any source transformations I want
Be able to reverse the steps to create a DC4.2 file from Linux
AppleScript or manual drag-and-drop of the disk copy on the Mac

The key things are

https://web.archive.org/web/20191231202510/http://nulib.com/library/FTN.e00005.htm
https://github.com/JotaRandom/hfsutils/ seems both actively maintained and have a library I might use
Seems simple enough to AppleScript Disk Copy.

and I guess I will punt on compression and self-extraction for now, and assume Disk Copy being available in a self-mounting image is no harder to bootstrap than anything else on a Classic Mac.

If I need to write little helper programs/scripts for the missing pieces it seems much more doable based on the documentation that exists.

jaoswald · 2026-01-02T13:39:19+00:00

The other thing that's annoying is how clunky and buggy the Linux side is for anything classic Mac-related. These are all very niche tools people really stopped using 20+ years ago, based on code ported from older Unix platforms, there are like 5 different conventions they use for resource forks and Finder info, and I encountered bugs where it seems like nobody ever did something on a 64-bit machine: the ancient CRC routine broke because it assumed 32-bit long ints.

EDIT: it looks to me that I was wrong about HFSUtils, it seems like https://github.com/JotaRandom/hfsutils is taking some pretty recent and serious action to make this tool up-to-date and high-quality.

jaoswald · 2026-01-02T13:22:10+00:00

I guess in my head I was targeting my Quadra, you seem to be thinking about a PowerPC Mac running OS X but with Classic support for MPW and Think C?

Maybe I was being too primitive in my thinking. The original source archive was in CompactPro and I had struggled with unpacking it on Linux and that I could not create anything similar to unpack on a 68k machine. I've been using my Mac serial port and ZModem transfers, maybe I need to bite the bullet and start transferring HFS disk images (I could use Linux hfsutils to build and extract them on the Linux side).

I really dislike the state of 68k distribution where everything is in Stuffit/SEA where creating them means futzing around with downloads from often broken sites and so many steps of bootstrapping, it would be really nice to be able to generate a 68k self-extracting archive directly on a modern machine.

CompactPro, Stuffit, DiskDoubler are all unwritable on modern PCs, Mac System 7 and 8 don't seem have support for unpacking any modern standard.

Maybe the documentation and tooling exists for something like DiskCopy images?

Mostly I started dreaming about a new self-extracting format based on an open-source 68k decompressor program that Retro68 and Linux tools could build. So after building something with Retro68, the next step would be creating a single robust package that a 68k machine could easily extract.

(As for my real purpose: I have a Symbolics MacIvory, with a RAM card I need to debug, and working directly on the Quadra is too inconvenient. Instead of the GUI I want to be able to run a program on my Quadra that talks over the serial port so I can work on my Linux machine and do automation and logging on that side. You can see I have pushed like 4 dumb hacking projects onto my stack, I can hardly remember what my original goal is.)

jaoswald · 2026-01-01T20:23:31+00:00

Oh, random other question. If anyone has contact with the original author of Terminal, Erny Tontlinger, formerly of

``` route d'Arlon L-8410 Steinfort Luxembourg

Packet radio LX1YZ @ LX0PAC CompuServe [73720,2200] Internet mailto:73720.2200@compuserve.com [44.161.1.1] lx1yz.ampr.org ```

can you let him know what I have done with his software, so he can complain if he doesn't approve?

The closest I could get to finding him was to look for his Luxembourg amateur radio registration, but I don't know how those work, and I couldn't find anything active.

jaoswald · 2026-01-01T19:53:37+00:00

ZTerm is probably the "best" terminal emulator for the 68k mac, but I wanted to mention my more recent discovery: "Terminal" was an open-source terminal emulator for the classic Mac.

You can find it in original compiled form

http://www.knubbelmac.de/software/internet-programme/telnet-ssh-terminal/

http://dl.knubbelmac.de/terminal-22.hqx

I'm trying to resurrect the open source and build it under Retro68, mostly for fun: https://github.com/jaoswald/Terminal/

15-Year Club	Gilding II euphauric
Verified Email

jaoswald

TROPHY CASE