It's possible that later A/UXs required booting MacOS - but when we started we got 1/2 the initial prototype production run of Mac 2s (no cases, bugs in pals, probably no standard ROMs yet)
Our standard agreement for porting Unix to new hardware (we did something like 150 different boxes, not just macs) required a minimal ROM monitor that could download code from a serial port (we could provide source), we'd take it from there, write S/A code to store data on the harddrive, download a file system, start downloading kernels into ram debugging the disk and serial drivers until we got a shell prompt ... then moving development onto the box
I'm pretty sure the ROMs loaded a boot sector booter and jumped into that, it's been a long time but I'm pretty sure that's what we handed over to Apple
Not really (I wrote the mouse/display drivers and kernel event queue driver for A/UX 1.x) - A/UX has it's own kernel ADB (and mouse/kbd on top of that) and display drivers, it will happily boot from hard drive, and throw up a non-mac terminal on a Mac display card without executing anything from the Mac ROMs.
The later MacOS running on A/UX ran in a single A/UX (system V) process
These are NiMH cells (7V) wired in series (not parallel so matching is less of an issue) - one bad cell and the series resistance of the whole string is shot
The original Prius batteries can easily have individual cells replaced (mine is 20 years old, we've replaced 2 cells) - of course Toyota want to sell you an entire battery, the wrecker will sell you a whole bunch of spares
(do this with care, an entire pack is hundreds of volts)
It's not really so much a book on how to get electronics done, more sort of an electronics specific phrase book, full of the names of things you can point at when looking for stuff in the markets.
The original was written by Bunnie Huang (a name to be sneezed at in his own right) who (I assume) grew up speaking Mandarin at home. Naomi is a local though and probably has broader local knowledge.
The original Shenzhen markets are still there (I've been going for a decade or so, they haven't changed that much), they're getting a bit crowded out by consumer electronics - I can still go and buy great tools in HQB at same places I was 10 years ago, reels of resistors at the same places, people will still sell you cut tape from part reels on the street - the big change are the electric bikes, you take your life in your hand each time you turn around :-)
This is a vaccine that does contribute to herd immunity, if enough people get it then transmission goes to 0 and it dies out, even unvaccinated people wont get it, because of the vaccine. The article says "0 cases" in the entire population, in this case the people who get vaccinated are carrying the unvaccinated
reads an instruction from x, increments the PC to x+2, then decrements the PC back to x and reads the same instruction, then decrements it again to x-2 and writes it, then it executes from x-2 ......
there were no GPUs at that time. What we were building in the late 80s/early 90s were the first generation of Mac graphics accelerators, really just glorified blit engines, a class of things that eventually grew into what we now call GPUs as people started to push CPUs into them
Yeah those low core global system variables (including a readable/writeable 0) at fixed addresses were very much a thing, they were a bad design decision made for the original Macs with almost no memory, and made running more than one app (switcher/multifinder) a difficult transition back in the day. Someone wasn't planning ahead
I also worked on the original A/UX port for the Mac II, some hardware (like the IWM) required tiny buzzy loops, we ran into one bug where using the floppy caused ADB to freeze, but only on the release machines, not the prototypes all our engineers had, turned out there was hardware that made access to the VIA faster by pulling the clock in for 1 cycle, if you sat in a loop reading the timer in the via to measure a sector time for the IWM in too tight a loop it upped the output clock from the VIA to the ADB chip and over clocked it ....
Well all they needed to do was erase the screen with white and draw on it, but their app's internal logic meant that they erased it more than once.
I was capturing QuickDraw library calls - the low level graphics primitives, to figure out where the graphics time in apps was going and found out sometimes excel did it 9 times
Of course users didn't see it more than once, but our hardware made all that wasted time run faster
I was probably not the first to have to do that, we knew what apps our customers used, making them better was the whole point of the operation
I did the architectural design for the SuperMac cards. I figured out what needed to be accelerated, dropping code into people's machines to see where the cycles were going. Others did the physical design for the first 2 cards, I did the design of the chip in the Thunder and later cards (designed the data paths and state machines and a full simulation, someone else actually laid the gates)
If your card has a SQD01 on it it's my work. It peaks at 1.5Gb/s on solid fills
To be fair this was Excell 25 years ago, may no longer be true.
One of the other bugs (the Quark/ATM one) was also because of the programmers were worried about writing over stuff that hadn't been completely erased, the Quark guys wrote a string with 2 spaces at the end through a box that masked the end of the string, the ATM font renderer saw it couldn't fit the text so it split it in half and tried again so it drew N/2 N/4 N/8 ... strings. It spent all it's time in the 68k's multiply instructions figuring out how wide the strings (and substrings) were, our fancy 24-bit character rendering hardware was an afterthought
I used to be a graphics card/chip architect for macs in the early/mid 90s - our chips were the fastest, but some programs were resistant because they did stupid stuff: pagemaker invalidated the font cache every time it went thru its main loop, quark with ATM did an n*2 thing every time it wrote text etc etc. We had special hardware to accelerate text drawing and it did nothing because the software pissed it away. We considered creating a plugin that fixed all these things, it would have been hard to maintain, in the end we travelled around to the people who made these apps and talked them through their problems
To be fair excel would erase places white that it wanted to write up to 9 times before it drew any black pixels, we made that very fast! we didn't tell them :-)
At the time 24-bit framebuffers were so slow that before we built graphics acceleration hardware people would switch back to 8-bit to get stuff done, making 24-bit/true colour your daily driver was a big step forward.
There is also the true story from the first Scientology vs. Internet clash, someone trolled them that their files were being hosted on 127.0.0.1, under a court ordered deposition they tried to find out who was running this server with their secret files (because yes, they'd looked, and they were there)
Our standard agreement for porting Unix to new hardware (we did something like 150 different boxes, not just macs) required a minimal ROM monitor that could download code from a serial port (we could provide source), we'd take it from there, write S/A code to store data on the harddrive, download a file system, start downloading kernels into ram debugging the disk and serial drivers until we got a shell prompt ... then moving development onto the box