Apple LaserWriter IIg - 68881?

[absurd_engineering]

While recently restoring a LaserWriter IIg logic board, I remembered that these boards have an unpopulated, but apparently fully connected, pad for a 68881 FPU.

Has anybody installed a 68881 to see if the board will make use of it? I'd expect that it would provide some significant speed improvements if the onboard code was written with floating-point operations, but I'm not sure how to determine if this is the case.

I've got a spare 68881 from a dead IIci, and I'm tempted to solder it on and see what happens..!

(Sorry about the broken image(s), server seems not to like image uploads at the moment.)

 

[croissantking]

Solder it in and report back! This is interesting. You could maybe use a PLCC socket in case you want to make it easier to remove the 68882 afterwards.

 

[Melkhior]

I'd expect that it would provide some significant speed improvements if the onboard code was written with floating-point operations, but I'm not sure how to determine if this is the case.

I doubt they would use native FP instructions in the embedded code without an actual FPU being present. Each instruction would trap and then be emulated by software, which is possible (e.g. SoftFPU, NetBSD, ...) but very slow. If you're knowingly going for soft-float, it's much more efficient to compile a soft-float library directly in your code. It avoids the overhead of the traps, and it has more opportunity for optimization (not that the compilers back then would have had a lot of optimizations in that area, but still).

An interesting experiment for sure, but don't expect any differences in practice. Would love to be proven wrong though

EDIT: also, *beware$ the '881/'882 have an 'enable' pin; normally some combinations of the relevant signals is used to generate it (4 bits of coprocessor space in A[16:20[, 3 of coprocessor ID in A[13:16[, plus FC[0:3[ for the CPU space function). If the logic for that is missing on the board (which is probable is they didn't intend to put a '881/'882 on production design), then the coprocessor won't be used or may cause the system to malfunction due to a floating 'enable' pin.

 

[absurd_engineering]

I doubt they would use native FP instructions in the embedded code without an actual FPU being present. Each instruction would trap and then be emulated by software, which is possible (e.g. SoftFPU, NetBSD, ...) but very slow. If you're knowingly going for soft-float, it's much more efficient to compile a soft-float library directly in your code. It avoids the overhead of the traps, and it has more opportunity for optimization (not that the compilers back then would have had a lot of optimizations in that area, but still).

An interesting experiment for sure, but don't expect any differences in practice. Would love to be proven wrong though

EDIT: also, *beware$ the '881/'882 have an 'enable' pin; normally some combinations of the relevant signals is used to generate it (4 bits of coprocessor space in A[16:20[, 3 of coprocessor ID in A[13:16[, plus FC[0:3[ for the CPU space function). If the logic for that is missing on the board (which is probable is they didn't intend to put a '881/'882 on production design), then the coprocessor won't be used or may cause the system to malfunction due to a floating 'enable' pin.

I have the ROM dumps from both versions of the IIg ROMs, would it be possible to examine them to see if they include any F-line instructions?

And would it be possible to check if the enable pin is set prior to installation?

 

[Melkhior]

I have the ROM dumps from both versions of the IIg ROMs, would it be possible to examine them to see if they include any F-line instructions?

Yes, disassembling the ROM with e.g. the Retro68 version of 'objdump' might give a clue - though the ROM format might not be properly understood, leading to potential 'false positive' (e.g. data disassembled as instructions). The heavy artillery would be to use a tool like Ghidra to reverse-engineer the ROM, but it might be overkill.

And would it be possible to check if the enable pin is set prior to installation?

Enable should only be asserted during coprocessor-accessing cycle. You should be able to trace it back from the relevant pin of the '881/'882 (I dno't have the manual handy, but it's documented by Motorola, for Macs it connects directly to the FPU pin of the PDS connector, I have the appropriate schematics for PLCC and PGA in https://github.com/rdolbeau/IIsiPDSAdapter if you have KiCad). It should reach to some discrete logic/PAL/ASIC that is also connected to the previously mentioned signals.

 

[absurd_engineering]

Excellent!

I do have Ghidra but I'm not really sure how to use it. When I load any of the four ROM images, looking at 68000 or 68030 code, it doesn't appear to find any instructions.

I see from your KiCAD files that the CS pin (25 on the PLCC 68882) connects to the FPU pin (A2) on the 030 PDS. That pin does have a good trace on the IIg board, which vanishes under an Apple VLSI chip in the direction of a resistor pack. I'm at work right now and can't trace it further but I will do so later.

 

[absurd_engineering]

The ROMs might be interleaved..?

 

[Melkhior]

The ROM could be organized a number of ways. And it also depends how they were extracted to produce the image. If you can't find super common instructions like RTS (hexa: 4E 75), then it's likely the image you have needs some post-processing.

For the CS signal, does the VLSI chip have markings you could check? It could be repurposed from a Mac. Does it also connect to the relevant signals from the '020/'030? Also, is there any other obviously missing chips in the vicinity? If it has the signals and there's no missing chips, then the VLSI chip likely handle decoding of the '881/'882 CS signal.

Another thing to check is the clock signal to the FPU - it likely is connected to the same clock as the CPU, but it's allowed to have its own clock, so better to make sure it is connected to a valid clock signal. Without a clock, it won't do anything either.

 

[absurd_engineering]

I'd say this board was *definitely* designed with adding the 68882 in mind. Everything appears connected.

Pin 11 (CLK) on the 68882 pad is tied directly to pin 6 (CLK) on the 68030.

CS on the 68882 goes to pin 52 of the VLSI chip marked 343S1031-A. That appears to be a glue chip of some sort, and connects to the RAM banks as well as to other VLSI chips and the CPU.

D9-D15 on the 68882 run to octal buffer UJ11 and ROM UM.

There are no other missing components on the board save a pair of pads for a capacitor behind the print engine connector, that does not appear to be used in any images of the IIg board I can locate.

 

[Phipli]

I'd say this board was *definitely* designed with adding the 68882 in mind. Everything appears connected.

Pin 11 (CLK) on the 68882 pad is tied directly to pin 6 (CLK) on the 68030.

CS on the 68882 goes to pin 52 of the VLSI chip marked 343S1031-A. That appears to be a glue chip of some sort, and connects to the RAM banks as well as to other VLSI chips and the CPU.

D9-D15 on the 68882 run to octal buffer UJ11 and ROM UM.

There are no other missing components on the board save a pair of pads for a capacitor behind the print engine connector, that does not appear to be used in any images of the IIg board I can locate.

Given it is a postscript printer, there is a huge amount of stuff that an FPU would help with. I would time it printing a complex vector file before fitting the FPU (Illustrator example file? Something with lots of curves), then time the same file again afterwards. See if it preprocessed it faster.

 

[absurd_engineering]

Given it is a postscript printer, there is a huge amount of stuff that an FPU would help with. I would time it printing a complex vector file before fitting the FPU (Illustrator example file? Something with lots of curves), then time the same file again afterwards. See if it preprocessed it faster.

That's the idea. But I need to check if there are F-line instructions in the ROMs before installing the FPU, if there aren't then the FPU won't do anything.

 

[joeventura]

Any updates on this?

 

[absurd_engineering]

Any updates on this?

No, I’m not skilled enough with such things to determine if the ROMs include FPU instructions (not even sure how to merge the ROM dumps, tbh), and I haven’t had the time to just solder on the FPU.