This is a tale of old CPUs, intensive SMD rework, and things that should work but don’t.
Released in 1994, Apple’s Powerbook 500 series of laptop computers were the top of the line. They had built-in Ethernet, a trackpad instead of a trackball, stereo sound, and a full-size keyboard. This was one of the first laptops that looked like a modern laptop.
The CPU inside these laptops — save for the high-end Japan-only Powerbook 550c — was the 68LC040. The ‘LC‘ designation inside the part name says this CPU doesn’t have a floating point unit. A few months ago, [quarterturn] was looking for a project and decided replacing the CPU would be a valuable learning experience. He pulled the CPU card from the laptop, got out some ChipQuick, and reworked a 180-pin QFP package. This did not go well. The replacement CPU was sourced from China, and even though the number lasered onto the new CPU read 68040 and not 68LC040, this laptop was still without a floating point unit. Still, it’s an impressive display of rework ability, and generated a factlet for the marginalia of the history of consumer electronics.
Faced with a laptop that was effectively unchanged after an immense amount of very, very fine soldering, [quarterturn] had two choices. He could put the Powerbook back in the parts bin, or he could source a 68040 CPU with an FPU. He chose the latter. The new chip is a Freescale MC68040FE33A. Assured by an NXP support rep this CPU did in fact have a floating point unit, [quarterturn] checked the Mac’s System Information. No FPU was listed. He installed NetBSD. There was no FPU installed. This is weird, shouldn’t happen, and now [quarterturn] is at the limits of knowledge concerning the Powerbook 500 architecture. Thus, Ask Hackaday: why doesn’t this FPU work?
The holy scroll passed from Motorola to Freescale to NXP states just a few differences between the FPU-less 68LC040 and the FPU-equipped 68040. They’re both pin compatible with each other, object code compatible (except for FPU instructions), and timing requirements are the same. This should be a drop-in replacement. It isn’t, and there is no satisfactory explanation for why that’s the case.
The first step to diagnosing a problem is eliminating possible problems, and in this case it’s probably not a software issue. The CPU reports no FPU in both Mac OS and NetBSD. The FPU-equipped Powerbook 550 exists and the Mac OS uses the same Gestalt ID for the entire Powerbook 500 series. Since [quarterturn] tested the CPU under NetBSD, there’s probably nothing weird going on in the ROM, either; Mac ROMs are dedicated almost entirely to the Macintosh Toolbox and the Mac OS. The problem probably isn’t software.
According to the Motorola, Freescale, and NXP documents, the problem probably isn’t hardware. This is the second new CPU in this computer, and this time the CPU probably has a floating point unit. We can probably trust the NXP support rep. We can also trust the PCB that has been reworked several times over the course of this project. If it works with an FPU-less CPU, it should work with an FPU-equipped CPU.
Without an obvious solution to this problem apparent in the software, hardware, or even the ROM for this laptop, this project has turned into a mystery. Surely there’s some errata tucked away in a datasheet somewhere that will tell us what’s going on. There might be a handful of wizened Apple engineers who know what the problem is. The explanation to this problem is going to be very hard to find, which is why this project is an Ask Hackaday column. The comments are open, and the eventual answer will assuredly be very interesting.
Dumb question, but why not just try some bytecode to use the FPU and see what happens?
Alternately use assembler to query the CPU capabilities yourself and check the output.
This seems like the most direct way to check it, rather than relying on other pieces to try to tell you if the FPU exists.
If it’s designed to be backwards compatible with the non-FPU unit, there may be a code sequence or pin that has to be pulled down (or up) to activate the FPU, so that for exactly this situation (using the CPU in a system that was designed for the non-FPU equivalent) it truly becomes a drop-in replacement.
Reading through the gospel, it would appear that there’s no hardware difference – so I assume that it’s down to how the OS is detecting the FPU as the problem.
I noticed this “There are some F-line instructions that the MC68040 recognizes as valid MC68881/MC68882 floating-point instruction patterns, but as floating-point instructions that the processor cannot complete in hardware. Table 9-10 lists the floatingpoint instructions that are unimplemented and therefore cause an unimplemented instruction exception”.
I wonder if whatever detection mechanism is using one of those, which although strictly MC68881/2 compliant, are not implemented here, and thus it thinks that there is no FPU at all?
Easiest way to tell is just try to run some basic FPU code yourself and see if it exceptions out.
With the possible exception that it wouldn’t be the first time a component from China was mis-labeled I agree. There would be no reason to write the BIOS to detect whether the CPU was floating point capable or not. This BIOS in the laptop would assume it is not and the 500 would not have the same BIOS as the 550. Apples are not designed to be as consumer configurable as Generic PCs are.
Beautiful solder work BTW.
Re: nice solder work. Thanks! I can’t recommend chipquik enough if you’re going to do just a little desoldering and don’t want to invest in a rework station. Even if I used a hot-air station, I’d still probably go with the chipquik, just because you don’t have to heat up the board as much.
I’ve gone about as far with this project as I have patience for. My guess is “no FPU” is hardcoded into the Mac ROM on the laptop, though I am surprised netBSD would care about that. If someone wants to give it a try, I do have an extra Freescale CPU to give away.
PS Hey Brian, finish your 68K computer already! :-)
BIOS handles power up and configuration. The OS will load after that. So the deed is already done. I’m wondering if you could overwrite the settings right after the BIOS loaded but before the OS started. Little short assembly script.
Great work though.
My laptop’s BIOS is blocking AES-NI extension on my laptop. Previously, they’d block VT-X. Seems like you’ve met the beginning of it =)
I have been watching [Benchoff]’s 68000 project for a long time and it looks like it’s too time consuming for him to fit in. He did a “re-factoring” and made a 68000 driven led display by using the CPU as a binary counter (address bus).
Sadly I caught *the bug* and have bought 50 odd right angle 50 pin DIP headers and screws and female connectors for them and it looks like I have to decide on 150mm x 100mm or 180mm x 120mm cards (PCB’s). So here we go – a card rack with small cards, single sided, old style chips and lots of CPLD for glue logic. So I am going to let the insanity flow through me and see what happens lol. version 1.01 will be Z80. but being a rack I just have to change the CPU card for a 68xx / 68xxx system.
This comment shows that half a clue can be just as dangerous as no clue. Mac’s have ROMs, not bios’ but that, is only the beginning. Research system enablers. Suggest start with inside Macintosh… Not assumption.
The FPU doesn’t seem to have any externally accessible control signals, so there is nothing to pull up or pull down or activate using some special code. The linked “magic scroll” (reference manual) is quite clear about it. The only way the CPUs differ is that if you try to execute FPU instructions on a CPU that doesn’t have FPU, you will get a floating point exception.
So if the sw isn’t detecting the FPU, it means it is likely getting some exception for whatever reason. Why that is the case would likely require some digging and perhaps a logic analyzer.
Probably the simplest way to test this would be to try to build a simple test case in assembler using the FP instructions and run it under a debugger, watching whether an exception gets triggered – and which one. It is well possible that the FPU detection routines could be buggy.
I’d be happy to offer up my remaining Freescale 68040 to whoever wants to mount it on a breakout and try to get the FPU working.
It is so easy to write a piece of assembly code using FPU registers & instruction, exec it, and see if it triggers an illegal instruction exception or not, according to the presence of the FPU or not, that I don’t see what your problem is indeed.
To me this does sound like a software problem.
Floating point ops can execute in three ways: in the FPU, by tripping an interrupt to an emulation ISR, or by simply calling an emulation subroutine. The first thing to find out is which does happen. FPU and an emulation will differ by orders of magnitude in execution speed. Non-interrupt calls probably means object files do not contain any FPU instructions at all.
If I had to guess, I’d say you’ve already succeeded.
When the FPU-less 68k encounters a FP instruction, it raises a special exception, meant to invoke a software routine to emulate the instruction’s results. The need to handle such exceptions is the only functional difference as far as FP is concerned. So if the OS is expecting to have to emulate FPU instructions, but in fact the CPU can take care of it, those exceptions never get raised. That is, the OS doesn’t choose to enable or disable the FPU, it just has to be ready to handle no-FPU exceptions.
So the OS may simply be seeing the Powerbook ROM, saying to itself “this looks like an FPU-less system”, and installing the exception handlers. In this case, the CPU would still actually be doing all the FP computations, unbeknownst to the OS.
Also my gut feeling (about the ROM).
Hopefully we get some closure on this – I’d love to see what worked.
I’d read this sort of thing was in System 7 as ‘system enablers’ and that they went away with System 8, but alas, the behavior persisted at System 8.
It could be that so far, all the tests I’ve run have asked the OS about the FPU, and not actually checked for the exception. If I knew how to do assembler in Mac OS I’d have tried that myself. As for netBSD I think the booter really is running a kernel outside MacOS, and should, in theory, do its own exception checking.
System 7.5.x was enabler free, having incorporated all the system enabler patches previously released for all Macs able to run 7.5. Then Mac OS 7.6 added in all the enablers released between 7.5 and itself.
On many CPU architecture families there is also some FPU state that must be preserved during context switches for correct operation (FP registers, if present, but also result bits and rounding control data and the like) so the OS probably does want to know if it is responsible for (or even able to) saving and restoring those data during context switch.
You can try to check the output of TattleTech (running unter MacOS), if you haven’t done so already: http://gryphel.com/c/sw/sysutils/tattle/
About 8 years ago I swapped a 68LC040 for a real 68040 in a Mac LC630 (or similar). All I had to do was pull the old chip and plug in the new one. Both MacOS and Linux directly recognised the new chip.
Perhaps these newer 68040s need some more/different init code to enable the FPU which IIRC is implemented as a kind of coprocessor on 68k arch.
I took a peek at NetBSD’s fpu_probe code and it seems straightforward. It executes an FNOP and only if that triggers an exception there is no FPU. So no clue why netbsd does not detect an FPU.
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/m68k/m68k/fpu.c?rev=1.1&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
From memory as a kid so subject to revision…In the early Mac II days some machines you could get an FPU coprocessor for. Ours had one. In the even earlier Mac 512k days you had to get a ROM upgrade if you upgraded the floppy drive. FPUs were not very prevalent, ROM was God. I would not be surprised at all that the FPU would go unseen, unreported and unutilized if the ROM didn’t say or expect it was there. Others have said effectively this so I cast my vote for the same.
If there was a PowerBook of this model line with an FPU I would compare the ROMs but I don’t know if there was.
The cheapest version of the Macintosh II (it and the LC were the only two Apple systems to use the 68020) had an “Apple Memory Unit” plugged in place of the “Memory Management Unit”. The AMU was essentially a dummy chip and the ROM checked for it or the MMU. If there was an AMU then (IIRC) no virtual memory option appeared in the Memory control panel, or it was greyed out.
The Mac II was initially released without support for 1.44M floppy drives and it had bugs that prevented large SIMMs from being used in Bank A. Apple released a ROM update and a SWIM chip (Super Woz Integrated Machine) to replace the IWM chip (Integrated Woz Machine) which added 1.44M support and fixed the RAM capacity bug.
Apple also released a ROM and SWIM kit for the SE, which converted them into the same as an SE/FDHD.
What Apple deliberately chose NOT to do with those upgrades was give the II and SE full 32bit ROM code. Full 32bitness was reserved for the upcoming IIci and IIsi. Dig around online and you can turn up an old article or two about the “Mr. Clean” project. They were full 32bit ROM code chips developed for various Macintosh models, used for development of System 7 while the IIci and IIsi were in development. Some Mr. Clean ROMs may also have been sent to various software companies along with beta versions of System 7 so they could get new versions ready.
Unlike so many other prototype products, there seem to have been zero leaks of Mr. Clean ROM chips or code. I found one old TidBITs article mentioning someone who saw some foil wrapped chips in a box, labeled Mr. Clean, in a closet at an Apple office. IIRC the person asked about them and was told a bit about their history. Wouldn’t be surprised if the box and contents were destroyed shortly after.
Apple could have sold 32bit ROM upgrades for most models prior to the IIci and IIsi, but likely for the same silly reason they chose to severely hobble the IIsi, they chose not to. The IIsi runs 5mhz slower than the IIci, has 4 meg soldered to the board for Bank A and Bank B can only take (IIRC) up to 8 meg. It has only the PDS for internal expansion. The IIci can take up to 128 meg RAM (even though 30 pin SIMMs that large didn’t exist when it was released) and it has three NuBus slots plus a “cache card” slot which for some reason was made incompatible with the SE30 slot which was carried over to the IIsi.
The idea that having the IIsi run at the same speed as the IIci would “cannibalize” sales from the IIci was ludicrous. All the hobbling of the IIsi did was result in fewer sales of the IIsi. Selling ROM upgrades for the SE, SE/30, Mac II, IIx and IIcx would have brought in money from those sales and even more money from sales of the new System 7.
I was going to go with “Well if BSD doesn’t…. ” but then remembered Ubuntu wouldn’t detect PAE on a Dothan (Pentium M) so obviously not all detection routines are infallible.
However, I do seem to remember from dealing with Amiga Accelerators back in the day, that the 68040 went hyper rare, the full on 040 “RC” being of limited availability for a couple of years, and then being discontinued completely with the EC and the LC being the only 040s available when the 060 came out. I think I recall hearing that after a year they dropped the EC designation and just called it a 68040 being the default one now, so later ones aren’t indicated on package that they have no FPU.
Another thing is, that the 040 did not contain a fully IEEE compatible FPU anyway, had no transcendental function support, so motorola supplied a “Floating Point Support Package” code blob to fully enable an entire set of IEEE compatible FPU functions… so, if that’s not present in BIOS/EPROM on board, then maybe FPU not showing as present because there’s code missing somewhere.
Harking back to Amigas, that was done at the OS level, with libraries supporting various CPU/FPU, although I assume firmware may have had problems if it included deprecated opcodes.
How it all works on a Quadra… https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/hw/hw_23.html
Seems to be saying you need that FPSP “installed at boot time” which I am not sure whether to interpret as residing in firmware or not.
The PAE is because there is a simple bit in the CPU features that tells if you have PAE support. However, some CPUs do not properly report this, and thus linux does not use it per default. However, you can force it with a kernel command line option.
IIRC, Apple used the MC68040RC33A, not the MC68040FE33A
Likely FPU has to be enabled in software.
Does this version of MacOS try this at all?
It is quite possible that given that i knows this exact hardware is “Powerbook 500” which is knows to not have an FPU, it does not try.
The FPU detection code is actually looking for an FPU but it’s not looking where you are expecting. The Powerbook 500 series has an expansion bay where you can install a FPU module with a 68882 FPU co-processor made by Sonnet. As other people have pointed out, the an exception is raised when you issue a command to the chips without an FPU. Normal behavior would be to use this exception to reissue the command to the FPU module (if installed) or emulate it with software.
The Powerbook 520, 520c, 540 and 540c all use the same ROM, the Powerbook 550c uses a different rom. It’s likely this ROM is being referenced for detecting hardware like the FPU.
Like so many people suggest, try running FPU code and I would say time it to see if the results are emulated.
The sonnet product, that was never made, not even as a prototype, would have allowed an 68882 to run on the 540c bus in peripheral mode, which is a mode that the 68882 supports. However. it would be a very slow and cumbersome implementation, nowhere near the same as having an FPU as part of the CPU, or even the same as enabling a 68882 to run on the same bus as the CPU, such as in a 68030 augmented with a 68882.
I have a Quadra 605, and I had successfully swapped the 68LC040 with a full 68040. It was just a drop-in replacement. With no other hardware or software adjustments, I just started it up and was able to run FPU-only software. I would have assumed this project would have worked, too.
isn’t it just looking for a 68882 ? the 500 has an expansion slot for a 68882 to go along with the LC, that may have been a tad easier and its a better combo.
the 68040 FPU doesn’t support everything the 68882 does, so it might just be trying one of the instructions it doesn’t support.
Hey I wonder if it’s implemented like intel did the 487sx…. Basically gave you a DX and a dummy to fill the copro slot… To enable a line that told the mobo that it had a fpu. … On later boards you just set the right jumper no need for fpu socket.
Meaning if you don’t have a 68882 you need to fudge a line high or low to make it think it has one… Still might fall afoul of lack of firmware support for missing instructions though.
Nope. 68K CPUs never did such shenanigans like the “487”.
The point being that the boards were made thinking there was going to be a 487 like a 387, and then there wasn’t. In the situation of a 68882 socket existing, because Apple assumed they would be using the EC, then it’s a fair assumption that the presence of a 68882 needs to be dummied in some way.
No I think the “487” actually being a 486DX was the plan from the start, otherwise it’d have been a hell of a job to fit a CPU into a socket designed for an FPU. Since they got decent yields of the 486DX, CPU + FPU, why bother making a separate FPU chip? Which would be outside the die and therefore slower.
A real FPU socket is different.
Well that was what happened yes, decent DX yields made making a 487 stupid. But for a very limited time there was a 486sx/487 board… Confusing the issue was that there were surface mounted 486SX board with a socket that disabled onboard CPU, meaning you could stick a DX in it. But the “487” upgrade was a two piece, and the 487 that went in the CPU slot was a DX and the 487 that went in the “FPU” slot, just said it was there, and batted the FPU exceptions back to CPU.
I was hoping this would be the long-lost update to the 68k Backplane Computer that you guys were working on to host the Retro Edition.
As was I. :/
Btw, anyone want to sell an ST BOOK? ;)
https://en.wikipedia.org/wiki/ST_BOOK
If collector nevermind, but if you just want to get your portable ST jollies on, roll your own with a MIST board… http://www.harbaum.org/till/mist/index.shtml
Portable ST jollies, you can probably just emulate it with a phone. I remember how thrilled I was when the first Pacifist emulator came out for the PC, and I could play all those old ST games! At full speed, too! Just about.
Right or pick up an early-mid 00’s ~1.5GHz laptop with 4:3 screen for under $50, run a custom linux on it to boot it to ST emulation.
Are we sure it’s not something simple like jumpers? The back of the board seems to have a set of solder jumpers between the LSI chip and the connector.
Considering some of the ‘LC040 series were known to have FPU trap problems, I could see Apple designing a fool-proof hardware detection system to bypass that problem.
I can only find pictures of the back of 520/540 CPU cards, but a photo of the back of a 550 card would confirm/deny this.
As an aside, I know that 500 series RAM cards have jumpers to tell the system their size.
I was wondering about that myself… what are the odds that there’s a jumper on the board to indicate that it has floating point capabilities, and it just needs to be set?
I think the key here is to research what’s different about the 550C’s board.
I’ve thrown a plea out on 68kmla.
https://68kmla.org/forums/index.php?/topic/28267-5x0c-cpu-card-differences/
Maybe this will come up with something!
I have indeed narrowed where the problem is to the CPU Daughter card itself, using my own 540c that is running an Apple Original 550c CPU Daughter card with the FPU detected by the OS and running correctly according to Norton Utilities FPU benchmark.
Allrighty then! Just need to figure out a way to mod non-550c CPU cards to operate as though they’re for a 550c, and solder full 040 CPUs to them. What’s the difference between the RC and EC 68040 chips? Which one is on the 550c board?
I’m really interested in upgrading my 520c with an FPU, but the full 68040 CPU boards are impossible to find.
Could you please share high resolution photos of both the front and back of the 540c and the 550c CPU boards?
“The replacement CPU was sourced from China, and even though the number lasered onto the new CPU read 68040 and not 68LC040…”
It’s hard to say from the available photos and it is not clear what [quarterturn] may have done in terms of cleanup (removal of flux residue) but that chip surface looks rather odd. Residue from cleaning solvents? What did the part look like when it was received? Did that laser marking have excessively burned areas at noon on the 8 and 3, 4 and 5 o’clock on the following 0?
And, what’s with that logo. When did Motorola change from their classic M logo to that rather odd looking logo. Admittedly, I’ve never been a fan of Motorola processors, and I have not tracked their parts since they stopped dealing to the high-reliability market, but something does not add up here. The laser marking of the logo is poorly done as well; that is something I would not attribute even to Motorola.
Ever stop to think the part may be counterfeit? (Note this is using the broad term of counterfeit, which includes re-marked re-cycled parts that were not sourced from the manufacturer as marked.) It might be a “real” Motorola part, but not the part it was originally sold and marked as.
I’ve bought AMD processors from a well-known and trusted Internet computer supplier that came in what looked like real AMD packaging, complete with holographic tape seals. These parts were NOT what was marked on the device package – the internal chip ID identified the parts as a lower speed grade than marked on the package. With parts like that from reputable companies, how could anyone absolutely trust a source of supply from one of the most prolific suppliers of counterfeit parts in the world – China?
I think you’re referring the CPU #1 – the FE33V. It looks bad because it wasn’t stored properly by the person I bought it from, though I can’t comment on the lasering. The residue on the top is probably flux washed up there by the fluorocarbon solvent my friend used after he touched up the solder job under the microscope. Anyhow, Motorolla/Freescale themselves confirm that FE33V has no FPU, despite having no “LC” designation in the part number.
The Freescale 68040FE33A part definitely contains an FPU. It’s possible what I have is fake. Hard to imagine they’d fake that, it’s such an obscure and yet not very valuable part.
Parts with far less value have been faked/reclaimed/recycled. Never underestimate the counterfeit market!
Search Google for “smt corporation counterfeit pdf” and look for the presentation starting with “Uppermidwest_VendorExpo…” SMT Corp. (I am in no way affiliated with them) is a commercial leader in the anti-counterfeit movement and they have been the source for some amazing evidence of the Chinese counterfeit market.
Perhaps this is an opportunity for Hackaday to enlighten the maker community to the proliferation of counterfeits – it’s mind boggling how much of it is going on!
A link for those interested (like me):
http://www.smta.org/chapters/files/Uppermidwest_VendorExpo_SMTAI-Upper-Midwest-Presentation-06-09-11.pdf
Wow, yeah, super interesting, thanks for sharing!!
I just recently got burned by my first batch of counterfeits – the venerable 7447. Oddly enough the 7448s from the same vendor were fine.
Wow. I have had some fake chips myself and I had no idea how bad things were.
That PDF is a *must read* and a real eye opener about fake chips from China.
+1 [CRImier]
Thanks! That PDF is really informative!
I’ll place my remaining “MC68040FE33A” under the video microscope and get a clear image of what it looks like unsoldered.
I guess I should be glad they used an actual 68LC040 as a fake, and not something that would immediately trash the laptop.
I’m fairly certain Apple used the RC version, but I don’t want to download the very large 68040 family data book just to see what the differences are from the FE version. I did find that it caused issues for some 3rd party Amiga upgrades because the RC version was hard to get.
RC is for the PGA. FE is Quad Flat Pack. So, its just a packaging difference.
i dont know if this will help, but another option is to use SoftwareFPU https://www.macupdate.com/app/mac/1963/software-fpu
its the ROM. You need a copy of the 550c ROM. the ROM is on the CPU daughter card as well as the CPU, and Apple knows the CPU isnt replaceable so the code in the ROM is written in such a way that the FPU is never in the CPU, so its hard-coded to be FPU-Less. Period. So the FPU traps/exception handlers that are loaded from ROM into the RAM are likely ones that use the expansion/PDS bus for an FPU instead of the CPU of course. However the 550C card isnt like that. So with a dump of the 550c ROM, you can probably get this running.
The only other way around this is custom coding that executes F-Line instructions expecting the FPU to be there, and of course to patch-out the apple exception handlers for the FPU system that ROM loads.
Anyone that needs a copy of the 550C ROM, I’m happy to provide it, since the ROM is on the CPU Daughtercard.
Ahhhh!
Why would you put a ROM on a CPU card if not for the reason that they need to be changed together.
Why would NetBSD care about the ROM? AFAIK there’s no need to enable the FPU in order to use it, the standard way to detect FPU support would be executing a FPU instruction. It is works the hardware is there, if not an exception will be generated. In other words it is easier for a portable OS to just do the check at initialization instead of relying on firmware support.
It is even common that the initialization code for an OS makes sure to generate an exception to make sure the processor is properly initialized. If that pattern is used then checking for FPU support is simply a dummy instruction before the ILLEGAL (or equivalent) instruction.
looks like a case of modding something that is broke and expecting it to work. most likely there was something else wrong with the unit that needs fixed. there is no mention on if it worked before the mod, it was in his parts bin for a reason.
Sounds like the answer is already amongst the above, but I’ll add my two cents. What are you doing to detect the presence or absence of the FPU? Write some assembler and find out for yourself, don’t rely on the BIOS. I see some answers above that the BIOS is expecting an FPU in an entirely different place. My bet is your current CPU indeed has an FPU and the detection code in BIOS isn’t expecting a bonafide 68040. Could be that your original chip from china was ok too, who knows? I don’t remember any FPU enabling code being required, it just works. All this guessing about apple software is unlikely to go anywhere. Give NetBSD a whirl if you can and/or write some assembler (or convince your C compiler to generate some floating point instructions, which ought to be dog easy).
Looking up the “F45F” mask gives a Freescale note that that it belongs to the MC68040V family.. and NXP’s page for the 68040 reports “MC68040V is a Low Power (3.3V) Version of MC68LC040 ” .. Note the “LC” :/
AFAIK, the MC68040FE33A should be an L88M mask.
Have the remarkers struck again ?
You’d think it would have barfed due to lack of MMU though… unless no virtual memory enabled…
I dunno for sure, but earlier Mac System software would run on a plain 68000, so didn’t need an MMU. Didn’t have pre-emptive multitasking, or proper memory protection. So maybe that doesn’t matter.
Presumably BSD would have an issue though.
If it really is a remarked MC68040FE33V then it has a MMU, just no FPU.
bingo, its a fake cpu again
http://cache.freescale.com/files/shared/doc/pcn/PCN6471.txt
“MC68040V F54F MASK”
http://www.nxp.com/files/32bit/doc/ref_manual/MC68040UM.pdf
“When reading this manual, remember to disregard information concerning floating-point
in reference to the MC68040V and MC68LC040”
That’s just their current -040 mask they use across all their processors in the -040 family. It’s not specific to the FE33V, it is also used with the FE33A, which has an FPU.
http://cache.freescale.com/files/shared/doc/pcn/PCN4397.txt
Shows the F54F introduced in Jan 1999, and mentions the F54F as a mask set specifically for the MC68040V.
http://www.nxp.com/files/shared/doc/pcn/PCN8219.htm
This shows the introduction of the L88M mask in Nov 2002 and mentions the FE33A as one of the parts shifted onto this newer mask. It also states L88M replaces mask K63H.
http://www.nxp.com/files/shared/doc/pcn/PCN5606.txt
The FE33A is listed as a part made with the K63H mask.
So from that, we know the FE33A was made from August 2000 to Nov 2002 using mask K63H. And then from Nov 2002 until 2014 using L88M
Since the date code on the chip is from late 2009, it should be L88M.
I’m 99% sure this chip is a remarked FExxV
Hell, I wouldn’t even put it past them to remark a FE25V as a FE33A to make a few more bucks !
I have agree, your documentation seems to prove your original assertion. Sounds like the OP got screwed twice with another FPU-less processor.
The software side unfortunately strongly points in the same direction. Barring the existence of some undocumented way of disabling the FPU done by Apple’s OS, the detection by BSD seems bullet prove to me.
Wow, so many thoughts! Just want to get emails of others… nevermind this comment.
I have a 540c that is running an original Apple 550c daughtercard from Japan (as in, I actually ordered it from a Japanese company and had it shipped here to the US and it has the original Apple part number, etc… on it) and the FPU is detected and runs quite well. I ran a benchmark using Norton Utilities, and the only system that handily beat it was the Quadra 840AV. The only way that would be possible is if the FPU was functional. The software emulation of System 7 software from that time could never produce a result like that if the FPU was non-functional. So, we now know its not the CPU, and not the system, it has to be a difference on the daughtercard itself, either physical, as in the placement of resistors, etc… or the ROM, as the ROM on my 550c is indeed different from that in the 540c, as evidenced by the difference in the MD5 and CRC32 checksums. I’d be happy to provide a ROM image so you can investigate this further.
Do we know the CPU does actually have an FPU? Before that is verified a fake or bad chip are more likely than anything else.
I too have a 540c and would like to obtain a copy of the 550c ROM. Could you send me a copy?
My favorite MCU of all time. 68030. Great instruction set. Not indexed addressing like Intel. I still have a bunch of 68030 in PGAs formate – new old stock.
qssqsqsqs
Being an older Apple device, surely it’ll be the position of one or two resistors on the motherboard to determine the model/features? :)
It’s got to be at least related to the software. The 550c has its own one-off version of the Macintosh Toolbox ROM, the rest of the 500 series share a different version.
The issue is most likely caused by the Gestalt ID. Both MacOS and likely NetBSD are using the Gestalt ID which identifies the system to determine capabilities. The Gestalt ID identifies the system as a PowerBook 500 which does not have floating point. The 550c daughtercard would actually have a different Gestalt ID that would identify it as a PowerBook 550c which does have floating point. I seem to recall that at one time there was a software program for System 7 that would imitate a different Gestalt ID to the system.
Can’t be gestalt. The 500 series of Powerbooks all share the same gestalt ID, including the 550c, which has a full 68040 with integrated FPU.
no, here is netbsd bootlog on 550:
http://www.re.soum.co.jp/~fukaumi/ml/netbsd/199910/msg00161.html
>NetBSD 1.4.1 (GENERICSBC) #0: Wed Aug 11 07:03:00 CDT 1999
>Apple Macintosh PowerBook 500 (68040)
>fpu0 at mainbus0 (mc68040)
same “Apple Macintosh PowerBook 500 (68040)” identifier
Note that OP’s picture of NetBSD booting doesn’t actually get as far as this boot does, and the fpu message is a little bit later in the boot sequence…
https://hackaday.io/project/9150-68040-upgrade-for-powerbook-520c/log/43395-netbsd-shows-no-fpu
It should be noted that the 68040’s FPU does not implement the complete set of instruction of the 6888x floating point coprocessors, so a software emulation is still required to perform transcendental functions and some of the most exoteric operations.
550c uses 68040’s FPU so this should not be the cause.
hmmm, if he (or someone) has the soldering-patience again, it’d be an interesting test to desolder one from a 550 and plop ‘er into the 500… assuming they’re the same package…
The CPU’s are actually on removable daughtercards, and I have indeed put an original Apple 550c daughtercard into a US 540c, and the FPU is detected and completely functional. No need to solder.
Wait, do I understand this correctly…? The 540c didn’t have an FPU on the original CPU… (like most of the 500-series). So had an additional slot for an FPU-add-on-card… Certainly since they designed it with the intent to replace the CPU daughter-card then there’d have to be a way to determine whether to use the FPU-add-on or the (replacement) CPU’s inbuilt add-on, if both were installed… Sounds to me like either a jumpered-pin on the daughter-card(s), and/or something in the firmware…
after reading all replies, I’d bet it’s a fake again, such a waste for that soldering skill :(
This concept seems strange to me… Why would they go to all the trouble to re-mark a chip that doesn’t have the functionality…? I could see, maybe, re-marking an older revision as a newer one, or for weird one-offs remarking an *entirely different* or even dud/null-chip, for *one-offs*… but they’d never get away with doing this en-masse, as it’d be noticed right off the bat by manufacturers. And who would go to *that much* trouble for a one-off? It’s not like there’s a huge market out there for people doing this hack, or even similar ones… There may be fakes out there, but this seems like a *really weird* thing to fake.
Then you would think this is a genuine part, and doubt your software side, like the OP does :P
It’s simple, if you send it floating point instructions directly to the processor and it gives you a floating point fault, than there is no functional floating point unit in the chip
What the chip is marked and what nxp tells you at this point is irreverent
I severely doubt any software or rom can tell the processor to ignore the fact that it has an fpu … This is just pointless waste of die and software space and would be new to me
Gosh, like early 80’s… All I remember about the 68000 series was 4E75 was a return statement in assembler. (Used it to help decompile the system on an HP 9836 workstation.)
After four days and almost one hundred comments, I’m still trying to understand why this post is still here; for that matter, why it was even considered valuable enough to post. You think, maybe, hackers-in-training don’t recognize time-wasters?
My considered opinion is that your article on “How to Kill Yourself by Building a Scuba Pressure Regulator” was MUCH more informative, educational, and socially relevant, but I notice that you pulled IT after a very short lifetime on your site.
–a Motorola 68xxx assembly-language programmer (“ex”-programmer)
I don’t know what you mean by an article being “still here” as they don’t go anywhere – they’re *all* still here on the blog. Perhaps you read HAD.com where a lot of us read HAD.com/blog/
In any case this article and many other articles by [Benchoff] and some other authors are of interest to older people that ‘cut their teeth’ coding on ancient hardware (well at least vintage lol). I personally have no experience with any of the 6802 or 6502 or 68000 type CPU’s but I still enjoy reading about other peoples experiences.
So the interest in the article and the number of comments is justification enough for this article to be “still here” – whatever “still here” means lol.
Then you commented on this post anyway.
This means that you have a dual fpu on the board.. my friend.