Since I recently got my HP Apollo 9000 Series 735 up and running, and it’s March, I decided to have a little Marchintosh fun and load MAE (the Macintosh Application Environment, a real officially-licensed Apple product) on to it this evening. As you can see from the photo (because I don’t have a device that can capture the video this thing outputs, and haven’t figured out screenshots under HP-UX 10.20), it works.
Over a year ago I started working on an inert HP Apollo 9000/735 a friend gave me from their collection to avoid moving it cross-country. I’ve recently got it working, and am posting notes about the fun.
At the end of my first post about it, I had recapped the power supply, but had not found a monitor that would talk to the enormousCRX-24z video board with its 1280×1024@72Hz Sync-on-Green via 3x BNC output, or verified the condition of the discs. As you can see from the splash image, all of those things have been remedied.
I spent the last two afternoons procrastinating from other work doing a deferred maintenance project, porting the labs for UK’s CPE287 Introduction to Embedded Systems from the “V5” armcc to the “V6” armclang compiler, since the most recent releases of Keil (the IDE we use in the class) have dropped support for the older compiler, and all our materials were written against V5. It has been a somewhat interesting porting exercise for a “same vendor, same platform” situation.
We have some slightly unusual circumstances: First, because the class starts in writing pure assembly, proceeds through manual bit manipulation in C, and eventually starts to write high-level software driver model code, we hit all the styles and interfaces. Secondly, we have an inexpensive textbook and supporting materials we rather like, but all the examples use the old style assembly syntax, which differs significantly from the more modern GCC/LLVM style, and for pedagogical consistency reasons we’d like to write our code in that style.
For the time being, Keil with the V6 toolchain includes the older armasm binary, so separate pure-assembly .s sources written in the old syntax can still be ingested, you only have to port inline assembly.
Keil’s debugger doesn’t appear to be able to keep source lines of inline assembly and the disassembly view synchronized for GCC-style inlined assembly the way it could with armcc. Unfortunate, and a bit klutzy for setting breakpoints, but not a deal-breaker.
armclang defines __ARMCC_VERSION as 6something so various pieces of existing code have pre-processor directives that will decide to use the armcc style inline assembly instead of the gcc style ones. Particularly irritating, TI’s first party TivaWare library has this problem in both cpu.c and sysctl.c, so I had to make a hacked version with the #ifdef s swirled around appropriately. The code in TivaWare intended for IAR ewarm is suitable for armclang … as long as you remove some spare ewarm-specific pragmas embedded here and there for suppressing return value warnings; I ended up putting -Wno-return-type in the extended compiler options for projects depending on those files.
armclang is much more aggressive about optimization by default than armcc was. In particular, you could get away without marking variables used in busy wait loops or ISRs volatile in armcc, and armclang will happily optimize them out if you forget.
armclang is more vocal about implicit type conversion than armcc, especially where it might affect signedness. This is triggered a lot by the REGISTER_NAME &= ~0xMASK bit-specific addressing idiom. I sprinkled in lots of UL suffixes on literals to avoid the issue.
Long term we might try to get off of Keil, though my experiences with CodeComposerStudio have been sufficiently frustrating that I’m in no hurry to move to it for the TI TivaC boards we’ve been using, and while I like ST’s Cube environment, it would both be a major change of materials and a potential supply-chain nightmare (when is the last time you saw a legitimate major electronics vendor with STM32 parts in a stock status other than “Expected Date: Eventually”?)
Last summer I posted about some tiny stepper motors from the internet, thinking about them as an alternative to mechatronic standbys like those terrible SG90 type servos or larger and differently terrible 28BYJ-48 geared steppers driven through a ULN2003.
At the time, I tried one with an A4988 stepstick from the top of my parts bin, and it didn’t work, so I figured there was some limitation and stuck to directly driving with H-bridges. …it turns out the “limitation” was that the cheap current-setting potentiometer on that particular stepstick was broken so it was driving no output current.
Discoveries:
Those little bipolar stepper motors work fine with bipolar stepper drivers.
Generational gains in bipolar stepper driver ICs are substantial (eg. A4988 -> TMC2208).
The venerable 28BYJ-48 unipolar stepper motor is easily modified to run from bipolar drivers.
I’ve been biking a fair amount lately after a 20-odd year hiatus; I decided last year that I wanted to start biking, bought a Giant Escape 3 Disc near the end of summer, but didn’t get confident enough riding to use it around campus last year among the students texting their way to their first (next?) vehicular manslaughter charge before they flocked back.
This summer, I’ve been dong my commute into campus on it, plus a significant amount of fun/exercise riding, and the top fixable annoyance has become getting sprayed at the slightest hint of wet. I did some hackin’ that I haven’t seen on the interwebs to fit the fenders I picked to the frame, which is the point of this post.
The Latitude E7250 I’ve been carrying around since 2017 is one of my favorite machines I’ve ever had; it’s small, robust, has perfect hardware support under Linux… and is starting to get a little too feeble for some tasks I’d like to use it for, experienced a few spurious shutdowns, and has a screen crack causing delamination.
I continue to be a fan of having a small, relatively inexpensive machine for carrying around, and a believer in “The only Dell laptops with acceptable build quality start with a 7”, so in the tradition of the $400 for a refurb and RAM upgrade I spent on the E7250, I ordered one of its more-or-less direct successors, a refurbished Latitude 7390 on a half-off sale a few weeks ago for about $470.
After a few weeks, it looks to be an excellent successor. Nitpicky details and comparisons below the fold.
Setting up a new machine, I was reminded that the default Firefox tab style after 89 is “utter lack of visual separation, but with lots of useless empty space.” I’ve hacked sloppy solutions on several other machines, but it looks … Continue reading →
I have an Onn Surf 8 (One of the surprisingly-not-that-shitty ultra-cheap Walmart tablets) that my research group bought a couple of to use as Android dev testbeds. I’ve been occasionally using it as a normal tablet since I have it around, and have been consistently irritated by the collection of bloatware it comes with…. so I decided to hack it. To tl;dr this whole thing, ignore the collection of typically scammy Android dev forum and blogspam crud, and use the open-source mtkclient for your MediaTek Android device hackin’ needs.
I’ve wanted a hard-copy terminal for a while – both to play with and to use for explaining why serial works the way it does, but they tend to be expensive. Most of the common hard-copy terminals also aren’t really convenient objects to own: loud desk-sized machines (Teletype 33 family, most DECWriters), additionally clockwork nightmares (IBM 2741, earlier Teletype devices), which speak ridiculous protocols (…ditto). This only leaves a handful of reasonable options, the most common of which are portables like TI Silent 700s and DEC LA12s, or one of the dasiywheel-printer based terminals (which are often non-period-correct things like a WheelWriter with a modern serial interface card in it).
So, of course, I’ve been idly keeping an eye out for a deal on one on the auction sites, and mid-October last year I got lucky: I scored a TI Silent 700 Mod. 745 for $34.00+S&H (about $47 all in) from a Shopgoodwill auction, and got it working.
An old friend of mine was moving cross-country and got in touch about taking “Some of his old computers” a while ago. I of course agreed, and it turned out to be quite a growth event for my hoard. There will be several posts about machines that arrived in this process as I get to them.
The list of things to be re-homed included “an Apollo” which I was hoping was a pre-acquision DN-something or a HP 300/400 series because I’ve had a long fascination with Domain/OS. What showed up is… not that. This is a later HP Apollo 9000/735 PA-RISC workstation, ca. 1992, which is easily the most exotic piece of hardware that transaction made me steward of. The OS options are HP-UX 7-10.20, a few BSDs, or a second-class NextStep 3.3 port; I’ll probably go with HP-UX10.2. It came with the requisite HP-HIL keyboard and mouse (thank goodness) and a DEC branded 5xBNC to VGA cable.
This thing was serious rarefied-air hardware when it was new: PA-7100 99 MHz processor, 208 MB of RAM in 12 obscene proprietary 16MB RAM modules + 16 soldered to the processor board, a HP CRX-24Z video board, a full-height SCSI HDD, and an AUI Ethernet daughter card. Probably in the ballpark of $60,000 new. It is also built like a piece of high-end industrial equipment, with big sheet-metal frames with handles that pull out of the back of the system for every major component.
My first attempt to power it resulted in …a feeble blink of the power light. That suggested to me that the PSU was bad, probably due to defunct electrolytic capacitors. So, in standard “old electronics troubleshooting” fashion, I pulled the PSU, tore it down, read labels off the most suspicious capacitors, and ordered replacements. The HP Museum folk also suggest the AC line filter module is a time bomb on all of these, so since it’s still made, I grabbed one of those too.
List with Mouser links, since they were the vendor with everything I needed in-stock: 8x 2200uF 25V, 12.5mmD 40mmH, 5mm lead spacing , Nichicon UPJ1E222MHD 8@1.09 1x 220uF 35v, 10mmD, 20mmH, 7mm lead spacing, Nichicon UPM1V221MPD1TA 1@$0.72 1x 1x 22uF, 25V, 5mmD, 12mmH: Nichicon UPS1E220MDD1TA 1@0.30 1x 12uF, 35v, 5mmD, 10mmH, Panasonic EEA-FC1V120B 1@$0.39 1x AC Power Entry Module, Schaffner FN9222R-10-06, 1@$6.50 I also ordered a couple 470uF 25V, 10mmD, 20mmH, 5mm lead spacing caps, but ended up not installing them because there was no sign of damage and they were hard to get a good angle on.
I passed on dealing with a couple smaller electrolytics with no signs of damage, and also two gigantic 2x 1200uF, 250v, 35mmD, 47mmH, 10mm lead spacing input caps that cost $7.50 a piece, since they looked both fine and like a fight to get out without damaging the PCB. One of these days I really need to invest in a proper pump-driven desoldering gun to make this kind of task safer and easier.
I of course picked up an extra 1-2 of each since it was noise over paying for shipping, and it’s a good thing because I dropped one of the new 220uF/35V parts and it instantly disappeared forever, presumably to wherever my cat has been hiding toys recently. The new input filter is slightly longer than the original and required a bit of creative terminal bending to fit around the caps, but it made it back into the case. After the recap, it powered right up, and on a second try after giving the hard disc a gentle thump to unstick the heads from park, everything spun right up.
Full Status LEDs. 8,6,3,1 = “Autoselection Failure to Find Boot Device”
It booted to status LEDs at that point, and shows “8,6,3,1” which according to the service manual indicates “Autoselection Failure to Find Boot Device” – probably meaning the HDD is dead and/or wiped. The appropriate HP/UX media is easy enough to find. Unfortunately, the monitor on my basement bench doesn’t seem to want to sync with the presumed 1280×1024@72Hz Sync-on-Green coming out of the video card, so I’m stuck for now until I can find a workaround. There is a 4th BNC labeled “Stereo” that might somehow be useful for sync? Or I need a scan converter/sync stripper gadget? … further research required.