The great 2024/2025/2026 tech firings, and what happens to all that clue

So yeah, I was caught up in the Meta/Facebook layoffs in March 2026.

There are a lot of parallels to the 2001 dot com bust, and I'd like to just briefly touch on one of them now.

There's been a lot of layoffs over the last year or three in tech. I think the tech market has seen what, more than 100,000 in the last year alone? And most of those aren't due to performance. There are a lot of very smart people who've spent quite a few years learning how to build, debug and maintain all kinds of interesting stuff.

And they're now in the marketplace.

When this happened in 2000/2001, you had a whole lot of people who learned how to build internet tech and infrastructure at companies that were pushing the boundaries with things. And they were let go, due to downturns, change of focus, all kinds of reasons.

A lot of those people went off to eventually build the new stuff that likely overtook a lot of those internet and telco companies in the 90s.

I think this is going to happen with the layoffs from Meta/Facebook and other technology companies. Meta ran (runs?) a huge research arm in Reality Labs pushing the boundaries in AR, XR, wearable/portable technology. There have been plenty of public technology demonstrations showing all the stuff going on before the current AI trend.

Just over in Reality Labs - people learned how to build stuff from ASIC design up through optics, display, camera technology, highly miniaturized electronic design and power, all the fun stuff around 2D/3D audio and video stuff on wearable glasses (how do you provide head and world locked surfaces to your applications and not have it be so laggy that it gives people headaches?), making it all work over wifi, and then .. well imagine the lessons learned in what can and can't work in manufacturing the devices and where the pain points are in current technology. (And yes, a lot more I can't talk about, for hopefully obvious reasons.)

That knowledge is now embedded in a few hundred people, soon to be a few thousand people, who are being laid off. And that's just reality labs - the other people spread throughout the company and other technology companies have gathered a lot of experience about how to make and grow technology "stuff", what works and what doesn't.

At some point some of those people are going to make startups that do really amazing things. The technology underpinning a lot of what people have been trying to make now will get better (and I will argue that right now it is good enough - if you're willing to shift your focuses a little) and things will appear that will knock the socks off the current offerings. They're not what you would view as "founders" in the bay area tech scene. They're the people who know how to make things work, not necessarily the people who got rich early on in the scene.

Just like what happened after the dot com bust of 2001.

I've heard from a few people now that those they're hiring from Meta and other large technology companies are top notch and know what they're doing. You can't spend 10 years at a company that heavily invested in cutting edge R&D and not learn a thing or two.

I think its their loss, and .. eventually, everyone elses gain.

 

Being accused of taking down a Data Centre, or "what happens when adrian is the only one who isn't oversubscribed on power?"

This happened circa what, 2008? 2007? I forget now. Anyway, it was a while ago now - and it wasn't my fault - but at the time it was pretty "wtf oh shit I'm in so much trouble" scary levels of scary.

So here we go.

Around that time I was running a little consulting / hosting company. I went into the data centre which hosted my equipment to install a second hand Dell I had acquired and tested. I plugged it into the rack, then plugged in the power, then pushed the on button.

Then bang. Then everything went dark. Then bang again.

Then I get a phone call on the VOIP phone in the data centre. It was their owners, asking me what the fuck I had done.

Anyway, it turned out that everything was dead. It wasn't just that the circuit breakers had tripped. A large part of their power equipment in the DC had also gone.

So yes, I was blamed for taking out a whole data centre. By plugging in one Dell server.

But why was I not in court over it? Why am I not still paying back the damages? Well, it turns out there's way, way more to the story.

First up they added a new rule - "You need to test equipment at this outlet/breaker before you install it." Cool, my server definitely passed that test. It worked just fine.

But then it turns out that although my rack was perfectly under the rated current limits, the other racks were not. Like, in any meaningful way. There were some other customers way, way over their allotted power. So when I plugged in my server - again, I'm way way under my own rack power allotment - I tripped some breaker on the distribution board.

Tripping that breaker meant that the other phase now took the brunt of the load. Again, my rack is fine, but everyone elses was apparently not, so it .. pulled very hard on that rail. And it immediately tripped the second phase breaker.

But that wasn't it.

Then, the second click was when they tried remote flipping the breakers back on.  The massive draw of power on phases when the computers in the data centre were powered back up caused some part of their power distribution setup to just plain fail. I forget the exact details here; I think the UPS was pulled on pretty hard too in that instant and I vaguely recall it also got cooked.

I had like, four? servers, a router and a switch. I was definitely not going to cause inrush problems. But the big hosting customers? Apparently they .. had more. Much, much more. Now this isn't my first rodeo when it comes to power sequencing of servers in a data centre - I had done this for like, a LOT of Sun T1s in circa 2000, staging how to turn them on a rack at a time upon a full power-off / power-on cycle event. But apparently this wasn't done by either the data centre or the hosting customers. All power, all on, all at once.

Now, I'm a small fry customer with one rack still paying the early adopter pricing. The companies in question had a lot more racks and were paying a lot more. So, this was all mostly swept under the rug, I stopped being blamed, and over the next few months we all got emails from the data centre telling us about the "new, very enforced power limits per rack, and we're going to keep an eye on it."

Anyway, fun times from ye olde past when I was doing dumb stuff but people were making much more money doing much dumber stuff at times. 

Installing a 32k DS1386 into an SGI Indy that expects an 8k DS1386

 The TL;DR is - you can't just plug a 32k DS1386 into an SGI Indy and have it work, as a bunch of stuff is wrong.

 The longer version!

Here's a picture from the datasheet:

Now, at the outset it looks like A13 and A14 on the 32k module need to at least be grounded - if they're floated or high then the RAM will be selected when you don't want it to be, and you'll just fail to see the RTC.

 However, if you just do that your Indy won't boot because it turns out that pin 3 on the 8k module is an undocumented (in this datasheet) auxiliary Vcc input - the 5v auxiliary / always-on rail is actually there. Shorting it to ground will just make the Indy super sad. Don't do that.

So, in lieu of making up a PCB (which I think I'm going to do anyway just to be "clean" - I used some pin headers to raise the DS1386 above the Indy PCB.

 Note that pin 3 on and pin 28 don't have pins (and I'm going to put some tape over the pins just to be super clear nothing shorts out).

Then, I did a quick bodge wire job on the underside of the DS1386-32K module:

 Where pin 3 and pin 28 are tied to pin 16.

 Then, well, plug it in, align it right, and it should just work! It did for me!

Blinking the SGI Indy Power Light

I figured out what broke in netbsd to make the R5000SC I have here poweroff during startup.

In any case, the hack for blinking the front panel LED, inspired from their BLINKY driver, shouldn't be lost when i clean up my tree.

 

So, I give you all:

+void
+blink_led(void)
+{
+       uint32_t reg;
+       uint32_t i;
+
+       reg = *(volatile uint32_t *)MIPS_PHYS_TO_KSEG1(0x1fbd9870) & 0xff;
+       reg = reg ^ 0x10; /* toggle? */
+       *(volatile uint32_t *)MIPS_PHYS_TO_KSEG1(0x1fbd9870) = reg;
+       asm(".set mips3; sync");
+
+       for (i = 0; i < 20 * 1000 * 1000; i++)
+               asm(".set mips3; nop ; nop");
+}

It's terrible but it works!

Also, amusingly, the ARC BIOS console IO was available at this point but nothing was being printed early enough for it to be seen! Debugging was quite a bit faster once I realised I was getting far enough for the ARC BIOS entrypoint to be initialised so I could printf().

Reverse Engineering the SGI Indy Monitor Detection, or "thank god someone added SGI indy / indigo 2 support to MAME"

 I have a bit of a soft spot in my heart for the SGI Indy and (purple, not teal, heh) Indigo 2.

So imagine my surprise when NetBSD "almost" booted just fine on the Indy I have acquired. R4600PC-100, XL8 graphics .. and wonky console colours in netbsd / wonky xorg.

The first deep dive is "why are the monitor colours so unpredictable?" and that got me into a fun deep dive into how the SGI Indy Newport graphics works, the whole SGI Indy Linux project circa 2000, hardware shortcuts and software shortcuts.

Anyway.

The TL;DR is here - https://erikarn.github.io/sgi/indy/monitor_detection  . I've listed the monitor resolution/refresh rates the internet and my reverse engineering based on what MAME was programming.

So the long version.

First up - I've put all the hardware documentation I've found so far at https://erikarn.github.io/sgi/indy/notes . 

The Indy was booting NetBSD in either correct colours - green kernel text, white userland console text - or incorrect colours - green kernel text, but blue console text. It was random, and it was per boot. X11 was no better - sometimes it had the correct colours, sometimes everything was wonky.

The NetBSD console code tries to setup the following things for 8 bit graphics mode (which is used for console, even for 24 bit cards):

• Program in an 256 entry colourmap table, matching what the NetBSD RGB 332 colour scheme is;
• Add in a 1:1 RGB ramp in another colour table (RGB2);
• A bunch of "XMAP9 mode" lines mapping 32 entries of "something" to RGB8 pixel format, RGB2 colourmap.

I was very confused as to what was and what should be going on, and I don't want to dig into the journey I took to get here. But the TL;DR here is that everything in the NetBSD console setup path is wrong and when it "worked", it ended up with the wrong colours. And when it "didn't work", it sometimes ended up with the wrong colours.

I'll write a separate post later about how the whole newport graphics system holds together, but fixing this requires a whole lot of driver changes to correctly program the hardware, and then some funky monitor timing specific programming.

The 13W3 port on the Newport graphics boards have a 4 bit monitor ID which compatible monitors will output. There's more details available at https://old.pinouts.ru/Video/sgivideo_pinout.shtml . 

The "universal 13W3 interface input cable" that I bought has a bunch of DIP switches controlling this.

 

If you have the four monitor ID bits set on or off, then you still get 1024x768 @ 60Hz.

The "fun" part of this story is if I were using 1280x1024 straight off the bat then I'd likely not have seen these problems happen so often.

Anyway.

Depending upon the settings, the Indy will boot with a bunch of different possible monitor setups:

• 1024x768, 60Hz
• 1024x768, 70Hz
• 1280x1024, 60Hz
• 1280x1024, 72Hz
• 1280x1024, 76Hz

I enumerated this list and threw them up on the monitor detection link at the beginning of the article.

So, the firmware reads these four bits at boot (via 4 IO bits on one of the CMAP chips - again, see the links at the top of the post) sets up the monitor timing and then displays stuff. But when NetBSD's console programming is getting the colours wrong when I'm using 1024x768 60Hz.

It turns out that the XMAP chips - which handle the final mapping of incoming framebuffer pixel data to what 24 bit RGB is sent to the CMAP chip and then the RAMDAC -  were being programmed inconsistently. (again, they were being programmed incorrectly too in NetBSD, but I've got a big diff to fix that. With that, they're programmed correctly inconsistently.)

There's a "display control bus" that the Newport raster chip (REX3) has to peripheral chips. The peripheral chips - the XMAPs, the VC for timing, the RAMDAC, the CMAP for 8/24 bit colour table mapping - they're all DCB peripherals. The DCB has some address lines, 8 data bits, programmable chip select line, chip select setup, hold and release timing, optional request/ACK signaling, and register auto-increment functionality.

However!

• The REX3 chip runs at 33MHz;
• The XMAP chips run at 1/2 the pixel clock (they're interleaved);
• The DCB has support for explicit ACK signaling from the peripheral, but as long as the peripheral uses it;
• The XMAP does not have an ACK line, just an incoming chip select line, and
• When writing the XMAP mode table lines - which map the display information to pixel format / colour table selection - it's done as back to back bursts to the same register, not an auto-increment and NOT using an ACK line.

This means that if the XMAP chip is running at a speed that doesn't entirely line up with the programmed chipselect timing, the mode writes will be junk. The normal 8 bit read/writes are "mostly fine" as they just show up as multiple 8 bit read/writes to the same register and for all the OTHER registers that is just fine. But for the mode register - where the DCB needs to write 4 bytes to the same individual address - it's absolutely not fine.

And that's the kicker.

After spending some quality time with the MAME emulator and some local hacks to enable the newport peripheral IO logging and setting the monitor ID, I found out that the timing used for the XMAP chips is different for 1024x768 60Hz versus 1280x1024 76Hz.

Everything worked just fine when I adjusted it.

So ok, I went back to the Linux and X11 drivers to see what's going on there, as I know the C code wasn't doing this. And I found this gem in the Linux newport.h header file:

 static __inline__ void
xmap9SetModeReg (struct newport_regs *rex, unsigned int modereg, unsigned int data24, int cfreq)
{
        if (cfreq > 119)
            rex->set.dcbmode = DCB_XMAP_ALL | XM9_CRS_MODE_REG_DATA |
                        DCB_DATAWIDTH_4 | W_DCB_XMAP9_PROTOCOL;
        else if (cfreq > 59)
            rex->set.dcbmode = DCB_XMAP_ALL | XM9_CRS_MODE_REG_DATA |
                    DCB_DATAWIDTH_4 | WSLOW_DCB_XMAP9_PROTOCOL;
        else
            rex->set.dcbmode = DCB_XMAP_ALL | XM9_CRS_MODE_REG_DATA |
                        DCB_DATAWIDTH_4 | WAYSLOW_DCB_XMAP9_PROTOCOL;
        rex->set.dcbdata0.byword = ((modereg) << 24) | (data24 & 0xffffff);
}

It's choosing different DCB timing based on the pixel clock. It lines up with what I've been seeing from MAME and it adds a third one - WAYSLOW - which I bet I'm only going to see on the PAL/NTSC timings or if something really wants to do something like 1024x768 50Hz.

The timings are in the header file, but .. nothing is using xmap9setModeReg(). It was likely copied from some internal SGI code (the PROM? X server? Who knows!) as part of the code bring-up but it was never used.

Anyway! With this in the NetBSD console code the console finally works reliably in all the modes I've tested. I'm going to try and get my big diff stack landed in NetBSD and then I'll work on the X11 newport code so it too supports 8 and 24 bit graphics at 1024x768 reliably.

• Read the CMAP1 register (and PROM on SGI Indy) to determine the monitor type
• The default monitor on SGI Indy is 1024x768 60Hz, and for Indigo2 its 1280x1024 60Hz
• Select an XMAP9 mode DCB timing set based on the pixel clock
• 8 bit mode for console and X11 needs the colour index table programmed into the CMAP at CI offset 0, and appropriate XMAP config for the display mode table to use 8 bit pixels, PIXMODE_CI, offset 0, NOT 8 bit RGB
• 24 bit mode for X11 needs the 24 bit RGB ramp programmed into the CMAP RGB2 table (which is not a colour index table!), and no CMAP
• Importantly, the X11 server uses truecolour for 24 bit mode, and pseudocolour / colourmaps for 8 bit mode, so all of this need repeating in the X11 server code! 

Here's how the console looks, complete with the correct XMAP9 mode table:

And here's how x11 looks:

 

 

(And the X11 support is even more fun, because I had to fix some stuff to make acceleration in the driver work, and that's going to be a whole fun DIFFERENT post.)

Addendum:

Oh, and the sync on green? It's generated by the RAMDAC. Once this all has landed in NetBSD I'm tempted to try to add a sysctl / boot parameter to disable the sync on green bit so normal monitors work on the SGI Indy. Let me know if you'd like that! 

A tale of an SGI Indy, a Sony power supply, and how to keep the fan spinning

Let's not dwell on why I bought an SGI Indy. Anyway.

One of the common things that I've seen is failure due to power supplies or heat death. The irony is:

• The Nidec power supply has dirty power, fails hilariously, but the fan is at least always spinning, and
• The Sony power supply has clean power, less hilarious failures, but the fan only comes on when the unit is hot. Sometimes.

 The fan in the Sony PSU is a 12V fan, and it turns on based on a thermal control line from the Indy. There's been plenty of research into the behaviour of that signal, and I'm not going to go into it here. What I instead want to talk about is a quick way to actually just get the fan constantly spinning, without having the open up and modify the power supply itself.

The TL;DR is this:

• Make a small voltage gate using two diodes - one from the 3.3v power supply rail (via a resistor, I used 100 ohms; (1Kohm was too high) but I may try something smaller like 56 ohms to make sure enough current is flowing) and the other from the Indy board;
• That way the Sony PSU is always fed at least 3.3v into that thermal sensor input.

 

So!

• There will always be a minimum 3.3v voltage into the Sony PSU fan control, which is enough to turn it on; 
• The fan will always spin at a minimum voltage;
• if it DOES get warm enough for the Indy thermal sensor circuitry to feed above 3.3v (+ diode drop) into the thermal control line, it will also increase the fan speed.

It's not too hard - tie two diodes together at the cathode side, cut the brown control wire, feed it into the power supply, and then tie the two anodes in as above.

 

(The grey wire in the image is going from one diode anode to the 3.3v (white) wire in the Indy main PSU connector; there's 100 ohm resistor at the end of said grey wire that's temporarily jammed in for testing.)

With this the Sony PSU fan is always spinning, and your SGI Indy should die less of a heat death. 

Installing FreeBSD-15 directly on an SSD, or "wait this 2007 era AMD K8 1RU server doesn't boot from USB flash?"

I .. ok let's not talk about why I'm putting freebsd-15 on an old K8 era box. (it's for network hijinx testing with old realtek PCI cards, don't ask.)

Anyway it's an award BIOS from 2007 that has the following USB options:

• USB FDD
• USB ZIP
• USB CD-ROM

.. and doesn't like whatever FreeBSD is doing to the USB flash drives these days.

Anyway, that meant I needed to figure out how to bootstrap FreeBSD directly onto an SSD.

First up, creating partitions:

# gpart create -s mbr da0
# gpart bootcode -b /boot/boot0 da0


# gpart add -t freebsd da0
# gpart set -a active -i 1 da0

# gpart create -s bsd da0s1
# gpart bootcode -b /boot/boot da0s1

Then, filesystems

# gpart add -t freebsd-ufs -s 230g da0s1
# gpart add -t freebsd-swap -s 4g da0s1

Then, newfs w/ FFS journaling:

 # newfs -j  da0s1a

Then mounting it:

# mount /dev/da0s1a /mnt

Then, bootstrapping from my local pkgbase repo (see https://wiki.freebsd.org/PkgBase for more info): 

# pkg --rootdir /mnt --repository FreeBSD-base --glob '*'

Which did a great job of bootstrapping it.

Then, I rebooted it, and discovered I needed /etc/fstab, so I did some manual stuff to boot it into single user mode and get it working.

 

Anyway, that was a fun trip down 2007 era hardware lane, and I found some bugs in ethernet drivers that use miibus (see kern/286530 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286530 - for more info.)

Getting a Gotek working on a PCW9512

I acquired a PCW9512 motherboard a year or so ago and I really wanted to get it up and going so I can build a little case for it and turn it into a proper CP/M plus hack machine.

The challenge? Getting a Gotek working on the PCW9512. There are some .. issues.

Specifically - the flash floppy support needs some extra options and board modifications to support the drive detection that the PCW boot block / CP/M loader wants.

The PCW8256/PCW8512 and earlier CP/M versions only support booting from the 180k single side 3" drive. However the later models have a different floppy drive controller and support booting from the 3" 180k drives or 3.5" 720k double sided drive. So, it does some drive detection based on drive behaviour to guess what's going on. For more information take a read of https://www.seasip.info/Unix/Joyce/hardware.pdf.

The drive detection requires emulating the specific drive motor behaviours that FlashFloppy by default is not done. There are workarounds available - have a look at https://github.com/keirf/flashfloppy/wiki/Host-Platforms#amstrad-pcw. The "supported" modification is written in https://github.com/keirf/flashfloppy/wiki/Hardware-Mods#motor-signal.

Unfortunately my spare Gotek is one of the smaller footprint microcontroller ones which doesn't support it - see https://github.com/keirf/FlashFloppy/issues/557 for more information.

So off to the external logic modification at https://fabriziodivittorio.blogspot.com/2018/05/installazione-gotek-su-amstrad-pcw-9512.html - which after a bit of thinking, I realised I didn't need it. I just needed the M0 jumper! If I wanted to support two drives then I would need to do the modification, but for one drive I just need that jumper.

So here's the jumper config on my little sordan.ie floppy pinout conversion board. Note that Drive 0 -> A: is set, and the Side jumper is set to the top. I haven't got a B: drive jumper set.

And then the jumpers on the Gotek - only the M0 jumper.

I then needed a 720k DSK image of the PCW9512 compatible CP/M. I finally found one - I'll go set up some links on my website to the relevant images soon - and then plugged it in. The system seemed to boot fine - the tracks seeked like it was booting.

But, I couldn't see anything! So, off to build a video buffer and keyboard attachment. Luckily I have a full PCW8256 setup, a spare PCW8512 keyboard and a PCW9512+ keyboard.

First up - over to the PCW wiki to look at the PCW-IO schematic - https://www.habisoft.com/pcwwiki/doku.php?id=en:hardware:perifericos:pcw-io

It's just some buffer gates and a pull-up / pull-down resistor on the SYNC input from the mainboard so you can select PAL and NTSC at boot. (Yes, I did test it. It does actually select PAL or NTSC.)

Yes, you need a pull up / pull-down resistor.

Then I built my own MVP version - starting with the schematic and some wiring notes.

And then the veroboard prototype!

.. it wouldn't be complete without a picture of the bottom side wiring.

I later added a keyboard adapter - another 4 pin connector next to the keyboard connector (at the top of that image, with the red/black/grey/purple wiring) to a 4 pin DIN socket. Nothing fancy.

Anyway, that's enough to get it to boot and work, as seen here.

This isn't the prettiest PCW9512 setup, but it's mine, and it takes much less space - and much less power - than the rest of the full PCWs I have here. Although I must point out that the monochrome white and monochrome green screens are quite lovely to use.

In any case - it works fine, and I'm completely happy with it. Now I need to build a little plastic box to put it all in, add a DC converter so I can feed it "stuff" and have a nice regulated 5v supply, and then start on the IDE interface.

Fixing a dead Amstrad PCW9512+, Part 2

In my previous post I yanked enough of the PCW9512+ apart and debugged why the power supply just plainly wasn't working.

Now it's time to see if the rest of the board was working.

The first thing to do is test the power supply without having the 9512+ logic board (and the CRT side) powered up. The switch mode supply may not be happy with a load, so an initial failure isn't necessarily fatal.

So it mostly looked like this whilst I was testing it - with that EHT anode cap moved out of the way (just in case - it shouldn't have been powered!)

And honestly? The power supply just worked fine. The caps I tested were fine. All the rails tested fine. I'd have to test them under load to calibrate them, but before doing that I should verify that the 9512+ board and CRT hardware works fine.

So after a bunch of cleaning up, it was ready to put aside and test the mainboard. Testing the mainboard only required 5v - 12v is required for the earlier 3" drives but this drive doesn't require it, and the 28v rail is only used for the 9512+ daisywheel printer. I needed neither, so I just hooked up the 5v rail for testing.

.. and again, the mainboard tested fine. Here it is with the disassembled floppy drive for testing.

The board initialised and showed video/sync on the output side. Ok, great. It needed 800mA at 5v to power up, and it would peak above 1A to load from floppy disk. So pay attention to your power supply!

Next up the floppy drive. It had something in it.

I don't know how or why a sunglasses lens showed up in here, but ... well now I am its proud owner. So I removed that and plugged it all back in.

The motherboard and drive worked enough to fail booting a non-boot disk - and beeped loudly whilst doing so. That tells me the hardware is starting up fine and running the boot ROM code, but it's not reading from the drive.

And well, the drive was dead. The floppy drive rubber band was toast.

.. I could figure out the belt width (~2mm) and thickness but I couldn't figure out the size. The drive is a Citizen UODC-45A and I couldn't find any service manual / documentation on this drive at all.

But luckily someone had! And the belt he ordered from DataServe Retro is for a cassette deck - flat, 71mm diameter, 2.8mm wide, 0.6mm thick! And to make life easier, here's the link to the belt in question.

 

I recommend watching the video to get an idea of how to get the belt correctly around the capstan to line up the belt between the small motor and the large drive shaft. It's quite a squeeze.

First up was cleaning up the old bits.

First, the motor spindle.

Finding all the fun bits of the belt stuck in the drive - I had to shake it multiple times to get it all out.

And here's some on the drive spindle itself. In fact, after doing all of this I found more stuck UNDER the spindle which kept the drive from reliably spinning at the right RPM, resulting in loads failing! (Phew, I wasn't looking forward to having to calibrate it.)

In any case, once I had assembled the unit and stuck in a disk, it made the right kinds of seeking noises and .. well, I guess it had booted.

And .. well, it started booting fine. But the keyboard didn't work, and the display was way too bright and over-sized. Let's tackle the keyboard... oh it's just cracked solder joints. Easy.

And now the picture!

Now the important part - this is now under load, so I need to double and triple check the power supply calibration. If it's getting > 12v then this'll happen. So before you go and try re-calibrate your monitor, check the power rails.

And yup - it was dumping 14.5v into the monitor B+ rail. Things look MUCH better after calibrating this back to 12v.

No obvious calibration needed!

And finally, running a basic RAM test.

So, it boots fine, RAM tests fine, copies disks fine. I haven't yet dumped CP/M software on here to use - I think I'll make up a disk full of CP/M games.

The next post will cover MAKING a 720k CP/M boot disk for this thing - more of a pain in the rear than I'd like, even with a suitable MS-DOS 80386 IBM PC clone available.

fixing a dead Amstrad PCW9512+

I'm on a bit of a "i wish I had a PCW as a kid" kick. So yeah, I have a working out of the box PCW8256 that has been upgraded to a PCW8512 (but with only one floppy drive for now. Stay tuned.) I got lucky; that one was in the US and didn't need any modification to work here. (And, amusingly, although it's setup for US power - and shipped with locAscript instead of locOscript, it's still configured for 50Hz UK and 256 line display!)

But yes, finding PCW's in the US - well, any Amstrad really - is super difficult. So when I saw a PCW9512+ for sale by someone in Florida, I jumped at it.

... unfortunately although the seller was listed in Florida, it came from Cairo! So would it survive the trip? who knows. It was sold as "didn't power on", the internal photos didn't show any evidence that the tube was cracked, so .. maybe I'd get lucky.

Coming from Cairo meant that it would be wired for 240v power, and indeed it was. So, up on the bench it went. And yes, it was very dead. So, I pulled out the boards and started testing the switch mode power supply.

First - start by discharging all the AC side capacitors and EHT side capacitors - and the tube, just in case! - and then start checking components from the AC line input all the way to the big switching coil. If you're lucky, it'll be something stupid like the fuse. If you're unlucky, the coil is open or the switching transistor is dead. (Or in the case of the PCW, a big honking integrated switchmode controller hybrid IC which is unobtanium in 2024.)

Here's what I started on:

This covers the AC input, EMI filtering, switching and AC -> DC rectification. The output of that rectification from 240v AC RMS is around 330v DC peak. So be careful, that stuff will definitely kill you dead!

Basic continuity tests of each of those components in circuit didn't show anything obviously wrong. But since there's a rectifier there, it's not always obvious that something's bad. So it's best to lift the parts out to test. So I did that, and .. oh look. R5001 is very, very dead.

I spoke with Jaz (https://mstdn.social/@coregaze) about it a bit to figure out why it's there. They pointed out it's very likely a damper resistor to stop any ringing that may happen between the filter coil on the left side, the capacitors in the circuit around it and the diodes switching on and off. It likely would get hot in normal use, so the fun question was - did it die because the whole unit was just running for too long in a hot room, or is something else dead / shorted and the power supply was being over-taxed?

In any case I wanted to test the rest of the power supply with that fixed, but I didn't (yet) want to light up the monitor circuitry. If there's a problem with the monitor circuitry - eg a shorted power transistor or hybrid IC - I didn't want to risk further power supply damage. So, back to the circuit diagram I go to see how the monitor side is powered up.

On the power supply side, there is a separate 12v DC supply to the monitor, called B+:

And on the monitor side, there's a few places it branches off of that B+ net:

Ok, so off to the layout diagram!

Now, see the track there with W2? That goes off to the horizontal deflection circuitry and flyback input to feed the tube EHT.  The rest of that W2 track/net is all of the other monitor circuitry. So how's it hook up into the Q5003/VR5002/C5026 net? The actual 12v monitor B+ line?

The answer - a solder blob! Here's how it looks after I was Very Intentional about cleaning around it after desoldering it.

So, with that blob removed, the 12v B+ output from the power supply doesn't feed the B+ input into the monitor, so none of the CRT related hardware is energised!

Well then! Off to test the rest of the power supply circuitry I go!

(Stay tuned for part 2.) 

On "repairing this commodore 1551 drive" and "don't plug in the head cable backwards"

I bought a "dead" 1551 drive a few months ago. It's a european model, only 220v, and they said "it smoked when it was on". Well, i figured it was dead but I figured maybe not dead dead.

So, step one was removing the .. huge ass transformer.

I stripped off the regulators and hooked it up to a pair of bench supplies to feed 5v and 12v with a current limit.

(And yes, by this stage I had done a bunch of debugging already, so i had taken out the ROM, PLA and RAM and socketed the PLA / RAM.)

I unplugged the drive head cable and measured it - the heads measured just fine. So, I left them off whilst I debugged everything else.

Then I fired it up - the drive spun, a bunch of CPU pins were blinking on the oscilloscope, but nothing quite worked. The drive constantly spinning is a sign that even the early boot code isn't running.

So I then wanted to know if the CPU worked. The problem? All the pins kinda looked fine. Except A15.

It looked very sus. Like ok, NMOS has some fun rise times, but the other pins weren't this fun.

I decided to socket everything so I could pull the RAM and address decode gate array out. I thought about the 42 pin drive gate array IC but I figured if that was fried I was in for an unfun time.

The next thing was to figure out how to test that the CPU kinda worked. I figured I could write a little program to toggle the activity LED quickly and see it on my scope. I started with the disassembly here - http://www.cbmhardware.de/show.php?r=7&id=21 - to see how the LED is blinked. The 6510T CPU has an 8 bit IO port (versus the 6 bit IO port on the 6510 CPU).

The program looked roughly like this:

.org $ff00
SEI ; disable interrupts
CLD ; clear flags
LDA #$6F ; IO direction bits
STA $00 ; program IO direction bits
loop:
LDA #$60 ; turn on LED
STA $01 ; program IO port
LDA #$68 ; turn off LED
STA $01 ; program IO port
JMP loop

.org $fffa
.byte $00, $ff, $00, $ff, $00, $ff

This didn't work. So, I got a new CPU. A15 on that CPU was much better.

Then this did work. The LED was blinking at a few hundred kilohertz. Ok, but the original ROM? Nothing. My guess is the ROM is also busted, so I programmed another 27128 EPROM with the right image and inserted it into the drive.

Everything worked! So, time to plug in the head cable OH CRAP I PLUGGED IT IN BACKWARDS. Bang, I blew the head coils. Crap.

Anyway, the rest of the drive seemed fine. Stepper motor, drive motor control. Now, the challenge - it's a mitsumi drive. I went on ebay to find a replacement drive - lots of "untested" 1541's everywhere. But I did find a "tested, guaranteed works" SX-64 drive. However, it's an Alps drive. They're supposed to be more reliable, but .. well, it arrived a few days later.

The main physical difference between the two is the connector. The thing I remember is that the write current is slightly different and some 1541 drives have a jumper to change said current.

Luckily there's a 1541 service manual and it has the Alps drive pinout for the 1541, which is surprisingly exactly what I need for the 1551:

So I followed this guide, verified at each step that it worked, and connected it all up.

And yes, I put superglue in the key hole for the head connector so I didn't plug it in backwards.

And .. well, it works!

Well, kinda. I had the commodore 16 drop into the monitor after HEADER (which formats a blank disk) completed. I've also had some issues with commands hanging and not running on the drive. So, there may be some other issues lurking.

I also want to figure out a suitable mod for the write head current change.

But hey, I guess I do have a working Alps drive in my 1551.

And yes I did tear the head apart to see how it's put together... :-)

Reinstalling AmigaOS 3.1.4 on my Amiga 2000 or "oh crap it didn't boot"

This post is about AmigaOS 3.1.4 on my Amiga 2000. AmigaOS 3.1 from Amiga works fine. However, there are a few interestingly subtle differences between 3.1 and 3.1.4 that are worth knowing about, and they stem from both OS and ROM changes that you need to be aware of.

Let's start with why I reinstalled it.

I did it a few months ago and didn't notice that I had only allocated a 10 megabyte OS partition. Oops. So, I figured I'd install it again before I started doing more work on it, and I remembered the hilarity from last time. This time, though, I took more photos to demonstrate it.

First up, the Amiga 2000. It has the 3.1 ROM from Amiga Forever. I think it doesn't include workbench.library and icons.library in the ROM due to size restrictions. So, you need to have that installed onto your boot media. AmigaOS 3.1.4 does that for you. If you use 3.1 ROMs with earlier installs of AmigaOS then you need to grab those libraries and put them in your SYS: folder yourself.

So, yes I bought some.

Then, the install disk. I have a TF536 in here and 8MB of Zorro-II RAM, hence the large amount of RAM.

Anyway, I started off by re-partitioning the drive using the HDToolBox program. It's supplied on the installation disk. Now, the 3.1.4 ROM includes a scsi.device that works with Amiga 600 style IDE, so I don't need any extra stuff to use the CF adapter on the TF536.

Oops. My boot partition is too small. Let's delete and reinitialise this.

Ok, that's better. Let's save and reboot.

Next - we reboot and reinitialise the disks with a fast format. Here's workbench:

Easy. Now, we run the installer. And, we select "Intermediary" install - or it won't correctly the detect the machine I am installing on, and thus won't install the right version of libraries that are no longer on the 3.1.4 ROM.

And now we begin.

Now after a bunch of disk swaps, it'll ask which version of hardware you have.

The first time I did this on the Amiga 2000 I did the Novice install and it asked for my Amiga 600 disks. Well, obviously I didn't have an Amiga 600.  But when I bought the disks I didn't have the modules disks either! I had to sleuth around on the internet to find them. So now I have them for my Amiga 500/1000, 1200 and 2000.

Anyway, it goes and installs the extra bits and pieces.

Finally it's done and I am told that I have a 32 bit CPU (which I do) and I need to do some extra work after reboot (which I will.)

I reboot, and here we are, basic install done. I'm warned again that I should go and install the CPU support stuff.

That's it for now. Next time (if I remember) I'll take photos of installing the CPU support toolkit, the network interface driver and then run AmigaTestKit and SysInfo to show it all together. Then after that it'll be reinstalling the network stack, and then on to music editing stuff.