modelrail.otenko Trains, computers, vintage, retro, model railways… the lot…

IO-DATA CDBOX

I found this at Beep in Akihabara in the junk pile whilst in Tokyo a few weeks back. It had a label saying "No Power", but I couldn't resist after all the effort I'd spent in the past on 110-pin junk for PC98.

At first glance, it could just be a box containing an CD drive... but flipping around to the back shows some interesting ports! CRT in and out seems to imply there's a window accelerator inside? There's also a C-BUS slot!

The switches underneath definitely indicate that there's a window accelerator. Opening up the unit shows that it's Cirrus Logic-based.

No Power?

The power supply inside smelled fishy, so it was (at least) time to replace some capacitors. I removed and re-inserted a few of the caps, as they didn't seem too bad. I replaced three that I felt were suspect, but the daughter-board only let out a sad squeak/sigh when power was applied.

The wiring between the power supply and the main unit seems to have 12v, 5v and a blue line to power up the relay which is probably something like a power-good signal. The voltages were all non-existent... so I decided to go the sneaky route.

Thanks to PC-standards, we know the pinout of the molex power to the CD unit, so let's just use a splitter and inject +12/+5v there via a Pico ATX supply.

Ok, it works. The LED even lights, meaning the power is flowing into the bus appropriately from this connector!

Installing It

In true IO-DATA style, the drivers are still available on their site. And, of course, in true IO-DATA style, the archives only contain updates to disks you're already meant to own. Fortunately, the archives can be expanded in 7-zip. Inside you'll find all the drivers you need.

The Matsushita version of the CD-ROM Driver was installed (there's a Creative driver there too!) and the Atlas CD was read...

To the point where it even wanted to install...

Using the original power supply

I heard the relay on the board switch when the attached notebook was turned on. It then occurred to me that the "junk" "no power" status was probably a lie. I bet the shopkeepers had just plugged the unit into the wall and not actually tested with a laptop connected. It turns out that the laptop needed to be connected AND powered-on for the relay to throw and the power flow from the internal power supply. Otherwise you'd get nothing. If you do have a totally dead power supply, this is the pin-out:

Note that 5v is on the orange wires and gets two wires. 12v is the red wire and only needs one wire. Finally, the power supply is switched by the blue wire. When the power supply sees the -12v from the Notebook then it'll engage and provide +5 and +12.

Cirrus Logic 98 Graphics Accelerator

This 'just worked'. Doom 2 has drivers for it already, so it was a matter of choosing the right one and booting in.

Excuse the image quality!

Nostalgia: Two Animations From The 90s

I don't know where to start... was it the eBay auction for a cheap DX4/100 in Canberra, perfectly timed to end the weekend that I was in town... or the random discussion of what olive-oil-naming conventions ACTUALLY mean, at work, that lead me to remember a random video on a random cover CD from the 90s that lead me to try and think of the brand that sponsored that 3D animation demo on a CD from the past that I've long lost and long forgotten?

Either way, here are the two vivid memories, of two pieces of animation from the family 486 DX2/66, purchased from Harvey Norman Fyshwick (even though Woden had already opened, replacing Normal Ross, when it was above The Model Shop... damn I miss that shop and thank you for repairing (removing the track nail from the electric motor's brushes) my HO Scale Hornby Maroon Princess Elizabeth which I bought at a basement-bargain price from Mr Odd, father of David who lived off McTaggart Crescent in Kambah back in the 1990s when we went to St Anthony's and... well... he also had Load Runner going on his Apple II which I drooled over.. but he also wanted to sell me a full Candy set Lima XPT in HO which I have also just been recently re-buying) on a 24-month loan from let-us-take-all-your-money-if-you-fail-the-interest-free-period shitty finance company.

Can you believe Gerry Harvey is still going and still offering the same shit? No computer repair corner though... where we took our copy of Free DC which had already been virus-trashed...

I do believe I might have digressed.

The mission today is to find two animations which are most-possibly lost to time...

1. The first is something that ran on Windows 3.1+. It was an EXE and was literally a demo app for windows. An encapsulated animation in an EXE that ran when you executed it, took your whole screen... played the animation and then returned you to where you were prior. This is what I remember:
   • A red parrot is flying on a blue sky background (no clouds) left to right.
   • It is a simple cartoon animation and it has a yellow beak.
   • From the right, a bi-plane zooms in, chews up the bird and just the beak is left.
   • The beak then falls through the bottom of the viewport.
   • The credits scroll and the authors are Huon and Maverick.
2. The second is a sepia-toned 'birds-eye view' of a bird flying into a spanish/greek vineyard/olive-plantation, discussing the qualities of the olive-oil/wine that the company produces. It was a movie file (not an EXE!) sitting in the videos/movies/demos folder on a magazine cover CD. Maybe it was quicktime? But I think it was AVI as I don't recall codec issues when watching it. Either way, the hints are:
   • From a Cover CD from an Australian Magazine in the 90s.
   • Sepia-toned landscape, dry, vineyard/orchard ... somewhere middle-europe.
   • Following right on the tail of a bird (maybe a swallow?)
   • Either an Olive Oil or Wine advertisement.
   • It's actually meant to showcase the video compression technology, fitting on a Cover CD with all of the other bloatware.
   • The brand could be: Martelli, Martell, Mortell

With all of this in mind, I started scouring the web. I quickly landed on the APC Mag Cover CD Stash on Archive.org. Sheesh, I definitely bought a few of those mags and used their CDs... but they didn't have what I was after. A quick goog' of "aus mag cover cd" brought me to Australian PC User (now TechLife) and ... woah.. I think I was a subscriber? This was 30 years ago. Am I meant to care/remember? Either way... One of those cover CDs hit me like a sack of bricks. Maybe I wasn't a subscriber and maybe I might have only bought one of those mags from Wanniassa Newsagency with its cover CDs?!

Why do I have this photo? I bought the same fkn Cover CD from eBay 4 days ago. It's all still circulating... But I actually bought it as I want to archive it all. archive.org has a good selection, but it's not as clean-and-tidy as the APC Mag CDs are.

Anyway! The CDs I could find did not contain the olive-oil/wine (herefore known as OOW) demo.. nor the BIRD demo. At this point I was chatting to my Brother, Rodger, who is awake when I sleep in Amsterdam. I do believe I triggered a dragon when I mentioned I was looking for a bird flying on a blue background in Windows 3.1... He proceeded to go for a stroll down memory lane and list the games he remebered from our childhood, but none matched what I was digging for. I thoroughly enjoyed adding to his memory games like Xenon 2 Megablast, but it didn't get me to where I needed to go. One thing though... during his search of nostalgia-ware... he mentioned that I might be thinking of something from "one of those 100000'in'one shareware compilations....".... oh.

Walnut Creek

This actually hit a nerve. At this point I would've written a new blog post asking about a "random shareware operator in the late 90s with a wizard on the cover." and ... well ... I don't expect any comments on this post, let alone a ficticious wizard post. Fortunately, buried in the depths.. I had a hint of "Warlock" software, with a wizard.. then "Walmart".. and then ... don't ask me how, but I came up with "Walnut CD". A quick search of that lead me straight to a suite of CDs on archive.org. Get out of here...

It's that #$%#$%#$%#$% wizard. Time to digress: Back in Canberra in the 90s, we had BitStorm in the Canberra Centre, ACTCom in Belconnen Mall and Boomerang Software in the Tuggeranong Hyperdome. The first sold me Screamer. The second showed us Doom I running on a demo PC in the store and the last sold me countless shareware floppies, Settlers I, a Dreamcast and so much more. Whatever happened, Boomerang Software, when it was in the Hyperdome near The Candy Shoppe and Cafe Rendezvous, was at its peak selling shareware with its own branding. It also had an amazing selection of second-hand software and hardware and I'd check it out every friday night.

It was at Boomerang that I bought a Walnut Creek shareware CD and I could not tell you why... but I'm sure there was something lucrative on the title. The cover art was navy/purple and the wizard was on it, and this was all I had to go by as I had no method to check the quality of the media as the cases were shrink-wrapped. I vividly remember their price-tags being 20mmx20mm and split horizontally. Top half having the current sale price and bottom half showing the price you'd get if you traded the same item in?

Either way... this CD had the bird animation on it. I'm only sure now as I went through the entire ISO collection on archive.org looking for a file with BIRD in the name. I had expected BIRDFAIL or BIRDDIE or BIRDPLANE... but it seems I should have been searching for BIRD_ANM. It was just this name that appeared on the September 1994 version of Walnut Creek CICA Windows Shareware. Interestingly, I don't remember the CD art in that listing's shot... however I do click with the cover art from April 1994.

Regardless, I ripped open the zip archive and inspected the BIRDY.TXT text file...

FINALS WEEK PRODUCTIONS
=======================

PROUDLY PRESENTS THE 1RD INSTALLMENT OF THE "NATURAL SELECTION SERIES"

TITLE: Survival of the Fittest!!
COMPLETED: May 1, 1993
AUTHORS: Jeffrey Cubillos and Alfredo Rojas

Bird, vs. Plane?, Survival? How can this not be it? The names don't match... but... wait... how do we even test this? Install Virtual Box, Install Windows 95...

It'll crash when trying to boot.. so install the "Fix CPU" patch...

And keep fighting...

So, Windows is running... mount the CD and..

It has an interactive text menu? and it UNZIPS THINGS FOR YOU? WHY DOn'T I REMEMBER THIS PART? Screw the animation... this is actually the systems integration part that pays the bills!

Because I'd found the location of the ZIP in archive.org, I knew which folder and which ZIP to extract. It was quickly deployed to C:\

The moment was then upon us... was this the file?

No way. It was. That's it! I got the names slightly wrong and the bird was also flying in the wrong direction... but the rest wasn't far off... at all?

The worst part? It was all of 4 seconds of animation! Those 4 seconds, on a CD-ROM, in ~1994 stuck.. and somehow in 2025 (do the maths.. that's 31 years?) I wanted to see it again... and.. it existed?

.. now to find the other animation! ... but in the meantime, here's the backyard tree that has also had 40 years to grow:

Enjoy.

Toshiba T3200 + Fairy YL-23 IC Tester

This beast happened to be in a store-room at work and was about to go into the e-waste bin... rest assured I prevented that from occurring! Thanks to my eagerness, I was then tasked with taking a backup of the HDD. Would it even boot?

Sorry, yes, it was already in pieces on the workbench... I should care more about blog photography, I suppose.

Don't apply power, check the caps first!

I didn't want to send unwieldly voltages into the motherboard, so I pulled the unit apart. The unit was caked in factory 'dust', so this also gave me a good chance to clean it. Thankfully there were actually no problems detected internally.

I had planned to extract the data by extracting the IDE HDD, but it turns out this unit is MFM! I'm going to have to do something trickier.

First boot in 25 years

Although this unit seems to have had a hard life, I was quite sure it hadn't been turned on in ~25 years. Knowing that the capacitors in the power supply were stable, I plugged in the 240v cable and sent it. The fans, display and HDD all came to life!

Look at that glorious screen! I've seen numerous posts where these screens have expired, so I was very happy to see this come to life.

Floppy woes

The floppy disk would seek to track zero and nothing else. As I've done on the PC-98s before, the first bet is to clean the heads with isopropyl. That didn't work, so I then extracted the drive and checked out the drive-speed sensor circuit.

Oh sure, that cap is crap... I touched it with tweezers and it took the pads with it! Fortunately the traces could be beeped out and a ceramic cap was installed instead. With my bodge in place, a DOS 5.0 boot disk loaded!

Backing up the HDD

The HDD was loading fine, so I had to find a way to get the data off the system. Via floppy would be a last-resort as it'd take a few of them. As nostalgic as spanned-volume pkzip'ing is, I'd rather not. Instead, I grabbed my trusty XT-IDE and found a 48mb CF card. I used the default configuration on the card, only setting the CF to 'slave' via the dip-switch.

Sure enough, with the CF as master, the card booted into it's copy of DOS 5.0 and XCOPY was used to transfer the entire HDD contents (all 19.4mb!) onto the CF card. Success!

Games!

The CF was also used to bring games to the system. Police Quest, Space Quest, Kings Quest, Alleycat and... A-Train? Railroad Tycoon?

Everything of the correct vintage worked fine!

Fairy YL-23 EPROM Programmer And Chip Tester

I'd purchased this ages ago via FB Marketplace and hadn't found a need for it yet. Also, being ISA, I'd have to keep my P2 in an accessible location to be making use of this device. What better host than a chunky 286 laptop? Yes, this laptop has ISA slots!

With the card in the slot, I realised I had no idea how to orient the cable! I extracted it again and checked for grounding. Here's a clear example for anyone else:

Back in, with the laptop powered on, no life was shown in the unit. The software was downloaded (two exe files, only YL.EXE is really needed!) and copied over via CF card.

Cool! The menu was easy enough to navigate. I chose to test some 74LS00 chips first:

Running the IC Tester (option 1) made the software try and guess the model of IC:

You could also force a test of a specific chip:

I then grabbed some SRAM and tested that:

Very nice. It all just worked!

PC-98 – 110-Pin Cables And External I/O

This was something I had always wanted to try: I had my trusty PC-9801N NS/A and the 110-pin port worked, as I'd tested it with both an Ethernet Adapter and SCSI Adapter.

What else can you do with this port? Well, it turns out that it's a full interface to the PC-98's C-BUS. I mean, that's why the Ethernet and SCSI adapters work so easily... they're actually mini C-BUS cards built to fit the portable asthetic of the 98-Note and its 110-pin connector.

It turns out that NEC released an entire external chassis, known as the PC-9801N-08 External I/O Unit, to hold three C-BUS cards. This connects to any 98-Note with a 110-pin port (later 98-Notes have a much larger port!) via a chunky cable, of which I've never seen one in the flesh. What I have seen are 110-pin to Floppy Drive cables, but these have a centronics 50-pin plug at the far end, instead of the required 110-pin at both ends.

The moons aligned: The right items appeared on Buyee at the right time for the right place... so I collected them.

Can I make a cable?

I set off to find the appropriate 110-pin connectors, but the best I could gather were 'external floppy cables' for the 98-NOTE. Fortunately, these have the correct connector on one end!

Look at that tiny-centronics goodness! Before-long, I had the casing off and the plugs dismantled with minimal damage.

The plastic casing can be prised off...

As expected, the floppy interface didn't need to use all pins, so only a small amount of wiring existed. The plugs are actually crimp-style, so further dismantling occurred to get them apart.

Ok, we're torn-down with minimal damage... a few broken clips, but nothing structural! I grabbed the nearest 50-pin IDC SCSI ribbon and tried to make it fit...

And it was never going to work as the cable was too thick. I couldn't think of viable alternatives... so I went down the solder route. DON'T DO THIS!

I ended up wrecking that plug, so jumped back on the auction site and shelled out too much for yet another 110-pin to floppy cable... it's in the mail.

The proper way to re-wire!

I ended up murdering a few data cables, that had been happily chilling in my box'o'junk, whilst looking for appropriately-girthed wires of a proper length. First up was a 50-pin Centronics SCSI cable... how could that not be tiny-strand?

Crap photo... but that far-left light-blue is the SCSI wire and you can see it's double the thickness. What else? Apple Serial cables were also too thick...

And then I hit the gold mine! DVI cables! Who doesn't have 6 million of the ugly things sitting in a box? And so I got started...

Some of the internal wiring of the DVI cable was twisted pair, probably for the colour video signals. These could still be used, you just needed to strip back more shielding...

The wires locked in to the rail nicely and even happily bent 90-deg, as required for the plug.

And look at that! It happened. I then realised I hadn't recorded the colouring, or even started on the other end... so I had to BEEP OUT the entire thing to wire it up. I mean, this was also a good quality verification process!

Meanwhile, as that I'd murdered the plug for the other side with solder, I couldn't even finish it. 75% done though!

Why was it never going to work?

Whilst waiting for the next cable to arrive, I decided I should investigate the I/O Unit end. Whilst beeping out the pins on the 110-pin connector, I realised that both extremeties of both rows of pins were ALL grounded. ALL GROUNDED. Looking at the pinout of the 110-pin port, these should all be +5v or other signals.... there's no way that these should be grounded on the I/O end?

A quick further googl' pointed out the obvious. In this Japanese forum post, one user asks if they can connect the unit straight through and is quickly told (via googl's bad translator):

However, looking at itp's post, it seems that there are cables (2 pieces) and an interface adapter for the expansion box. Without this, it is practically impossible (to connect a laptop directly). If you look closely at the connector on the back of the I/O Unit, it is not 110 pins. The manual says "100-pin connector".

It's what?

Haha... that's one of my 110-pin Ethernet modules lined up against the 100-pin (Yes, NOT 110-PIN!) connector on the I/O side. All that hard work above was NEVER going to work. Then again, maybe I'll finish the cable as it could still function as one-of-two of the cables needed if I ever manage to find/build the interface box! But then I'll still need a 100-pin amphenol plug!?

We'll chalk this one down as a huge (mildly-expensive) time-sinking failure!

RUNTIME_CONFIGURATION_ERROR_VHDOVERRIDENOTFOUND: Livy session has failed. Session state: Error. Error code: RUNTIME_CONFIGURATION_ERROR_VHDOVERRIDENOTFOUND. Cannot find vhd based on override: Message=The system did not find a VHD copy in the system for creating the ClusterName=12341223-5555-4444-3333-63c446fe4d8b, Workspace=synws-d-e-v-d-e-v-01, Subscription=, Location=australiaeast, isVhdOverride=True Source: Dependency.

Update-AzSynapseSparkPool -WorkspaceName ws_name -Name pool_name -SparkVersion 3.4

3Com EtherLink II 3C503 – Boot ROMs

The XT-IDE Universal BIOS is a very cool project, enabling older hardware to support much newer storage devices. The safest way to use it is with a dedicted 8-bit ISA controller card, but there are other ways to get started. If you have an Ethernet card with a spare ROM slot on it, you can program an EPROM with their BIOS and boot from there! Or so I thought... enter the 3Com 3C503.

Willem EPROM Burning: 101

I've discussed using the Willem Programmer before and, since working out the caveats, it's relatively straight-forward. Firstly, make sure you have a known-working version of the burning software installed on a known-working machine with a known-working parallel port. Next, check that you have the EPROM-specific dip switches correct, the power at a suitably-high (with enough current!) level and TOTALLY erased EPROMS. I usually leave my EPROMs to cook for around 20 minutes in my super-dodgy Ultra-Viole(n)t eraser.

Another good note is to make sure that you write them more-than-once when programming. Press the program button on the programming software again and again... so that the EPROM is written and verified multiple times. The software will write a byte and check it, and I've had it where the second programming run will fail. The usual reason is that the EPROM wasn't erased well enough, and that the initial write tinkered with residual data/current in the chip's cells, which then settled. The second write will write/read/check and fail as that cell has changed to another value. Erasing and programming again might work, else that chip needs to go in the bin.

Preparing an XT-IDE Boot EPROM

The default ROM can be downloaded from here. Choose the folder whose name begins with an 'r' and has the highest number. This'll be the most-recent release of the software and should be bug-free on all supported hardware. There's a miriad of flavours of the software, so you'll need to choose the one that's right for your hardware.

Burn it to an EPROM. I chose a 27C256 as I had a spare truckload.

Testing it in known hardware

This is paramount. Don't just slap this in marginal hardware and expect things to work. I found a boring Realtek PCI 8139 NIC and slapped the freshly-minted EPROM in.

It was installed in my PIII-500 workhorse and worked first time!

Just for fun, I inspected the area of system memory where it mentioned the ROM was hosted:

Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\WIN98JP\DESKTOP>debug
-d d000:0000
D000:0000  55 AA 10 E9 B5 03 58 55-42 32 31 30 2D 3D 58 54   U.....XUB210-=XT
D000:0010  49 44 45 20 55 6E 69 76-65 72 73 61 6C 20 42 49   IDE Universal BI
D000:0020  4F 53 20 28 41 54 29 3D-2D 00 00 00 72 36 32 39   OS (AT)=-...r629
D000:0030  20 0A 28 32 30 32 34 2D-30 37 2D 32 30 29 00 00    .(2024-07-20)..
D000:0040  61 FC 00 00 04 00 00 00-02 80 00 01 00 00 F0 01   a...............
D000:0050  F0 03 00 0E 1D 00 00 00-00 00 1D 00 00 00 00 00   ................
D000:0060  70 01 70 03 00 0F 1D 00-00 00 00 00 1D 00 00 00   p.p.............
D000:0070  00 00 E8 01 E8 03 00 00-1D 00 00 00 00 00 1D 00   ................
-d d197:0000
D197:0000  89 55 12 89 5D 14 31 C9-89 4D 16 C7 45 18 00 02   .U..].1..M..E...
D197:0010  2D 01 40 81 DA EC 00 19-CB 73 04 80 4D 02 02 26   -.@......s..M..&
D197:0020  8A 54 0A 30 F6 89 55 08-89 4D 0A 26 8A 54 0B 89   .T.0..U..M.&.T..
D197:0030  55 0C 89 4D 0E 26 8B 54-0C 89 55 04 89 4D 06 91   U..M.&.T..U..M..
D197:0040  E9 4F FB 81 7E 18 AA 55-75 14 C6 46 1F 21 F7 56   .O..~..Uu..F.!.V
D197:0050  18 E8 0D 00 89 4E 1C 80-66 24 FE E9 3A FB E9 CD   .....N..f$..:...
D197:0060  FA B9 01 00 80 7D 14 04-73 03 80 C9 04 C3 FF FF   .....}..s.......
D197:0070  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................

Nice, there it is. I dumped it (great tutorial on dumping over here at MESS) for safe-keeping, so I could use it for any comparison in the future:

-n pci-d000.bin
-r bx
BX 0000
:0000
-r cx
CX 0000
:2000
-m d000:0 2000 0100
-w 0100
02000 BYTES WRITTEN
-q

Note that you need to hit enter at the end of any line starting with "-". 0x2000 is 8kb (aka 8192) in HEX. Debug also only cares for 8.3 filenames, so don't give it anything longer.

3Com EtherLink II 3C503

The actual card to test was this 'trusty' 100yen purchase from a Hard Off in Japan. The 3Com 3C503 was detected and installed under Win98 and worked fine. I then put in the EPROM and nothing happened during a restart!

This card has one thing going for it: configurable jumpers. The ROM location can be easily specified and I'd put it at 0xCC00.

I have no idea if this was a good location, but I went for it. A reboot saw absolutely nothing get executed! To test if it had actually been loaded into memory, I used debug once more:

Microsoft(R) Windows 98
   (C)Copyright Microsoft Corp 1981-1999.

C:\WIN98JP\DESKTOP>debug
-d cc00:0000
CC00:0000  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0010  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0020  FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF   ................
CC00:0030  FF FF FF FF FF 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0040  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0050  BF 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
CC00:0060  08 00 45 00 CA 00 8F 02-60 E8 12 01 00 00 32 FF   ..E.....`.....2.
CC00:0070  8A DA 66 D1 E3 66 50 66-BA D4 03 66 B8 1F 57 66   ..f..fPf...f..Wf
-q

Ah yeah, that's not it. I tried a few other locations, landing on D800, but it seems that Windows 98 was stealing the memory back after DOS had loaded. I ended up having to F8 to DOS when booting and debug from there:

That's still not it! But at least it's blank. What am I doing wrong? Turns out this card only supports 27C64 EPROMs and I've shoved a 27C256 in it! Ok, lift the address pin that could be conflicting:

And what do we see?

We're literally a half-step closer! I spent a lot of time googlin' what the @#$ was going on, but then I looked at the card again:

DATA MODE has an option between 16 and 8. I had thought this was Twisted Pair or BNC... but I was wrong. Setting it to 8 (finally) revealed:

Ok, the 'top end' looks good... what about the rear end? The ROM is 8kb, but there's a bit of filler at the end. The ROM data is around 1D7 bytes:

Ok good, but what about the very end? The ROM is 8k, and that's 0x2000 in hex. It's based at 0xD800, so we also need to check up to 0xD9FF:

What... what is that 0x04 0x04? I only had to ask the internet, because... as I keep saying, nothing is new on the internet. Someone has almost always had an issue in the same vein as anything and everything I've ever encountered. The strange thing with this forum thread is that they say that the 3C503 returns 0x80 0x80 as the last two bytes. Above, as you can see, we're getting 0x04 0x04. How broken are we? I dumped the ROM and compared everything with HxD and we're not bad! It really just is the last two bytes.

Ok, so there are the two bad values right at the end. The card is always reporting them and we need to find a work around.

BIOS Option ROM Checksums

We know the EPROM data is being loaded into memory, but we don't know why the system BIOS isn't executing it. I had to dig a bit to find a thread on Option ROM checksums which lead me to a great howto on Etherboot ROM booting. This latter document contained a great list of dot-points that need to be met for an Option ROM to be seen and booted:

How does the main BIOS know that the code in the ROM is to be executed and why does it not execute some random code by accident? The ROM code has several conditions placed on it:

1. The ROM must start on a 2kB boundary in the memory space, between 0xC8000 and 0xEE000, although some main BIOSes scan outside these limits.
2. The first two bytes of the ROM must be 55 AA hex.
3. The third byte of the ROM should contain the number of bytes in the ROM code divided by 512. So if the ROM code is 16kB long, then this byte would hold 20 hex (32 decimal).
4. All the bytes in the ROM (specified by the length byte just mentioned) must checksum to 8 bits of binary zero. The sum is formed by 8 bit addition of all the bytes, throwing away the carry. Note that there is not a particular location designated as the "checksum byte". Normally the ROM building process alters an unused byte somewhere to fulfil the checksum condition.

From the dump above, we can confirm that we tick the first and second point. For the third point, our third byte is 0x10, meaning that we're 8192 bytes long. This means that if we add together every byte in our 2k ROM, we need to sum to a total of 0. Fortunately, we don't have to do this manually! If we use the checksum calculator over here, it'll run throught the ROM and adjust the last byte to fulfil the checksum zero-sum requirement.

I fed it the ROM dumped from memory, as loaded by the 3C503. Why bother using the correct binary on disk if that's not the way it'll show in RAM?

C:\Users\steve\Downloads>romcksum32.exe \\yadayada\....\3comd800.bin

ROM Checksum Calculator  VER: 0.2 REV: D
Copyright (C) 1998-2021 Microprogramming TECHNIQUES
Programming/PC Code: Alexandru Groza
All rights reserved.

ROM file     : 3comd800.bin
Disk size    : 8192 (8 KiB)
ROM usage    : 100.00% (8192/8192)
ROM checksum : 0x4h (8-bit)

ROM file checksum updated.

So, what's it done?

It replaced the final 0x04 with an 0x49? So it decided that, once summed, we were missing 0x45 to sum back around to zero... sure... but our card is going to whack that final 0x49 back to 0x04. We'll need to 'spread' this checksum'd difference around spare bytes, but they're all 0xFF, so let's change the third-last byte to 0x00 and use it to store the remainder. Running the checksum again after making this change saw:

So, with an 0x00 instead of 0xFF, we now have a final byte value of 0x48. So the FF was worth 0x01? Regardless, if we know the last 0x48 will become 0x04 in the physical machine, we can store the 0x44 difference in the third-last byte:

And you know what? I wrote this version of the binary (DOWNLOAD HERE) to an EPROM, inserted it into the 3C503 and IT BOOTED! Of course, this was a stock-standard XT-IDE BIOS ROM. What you ACTUALLY need to do is to run the XTIDECFG.COM file from a floppy with a machine-relevant BIOS loaded and then customise it to the configuration on your machine. This default BIOS tries to load a second ATA controller and causes no end of lock-ups as the hardware isn't actually attached!

I can't believe it worked.

Apricot Xi PC

This Apricot Xi (further info) (Service Manual) appeared on eBay and the seller was willing to ship it! He descibed it as the following:

It was tested to power up only. The hard drive spins up and a red light is visible inside through the floppy drive slot. It did not appear to boot. A minute or so after first powering up some caps blew in the power supply, likely filter capacitors. It did not stop and later could be powered up again to the same state.

That latter concept of why not try turn it on again after it exploded left me a little bemused... but what could I lose by trying to get it going?

The tear-down was nice and simple. A few screws here and there and things just nicely came apart.

The power supply was out first and the damage was blindingly obvious.

Those two nuts on the wall were not fun to remove, but with them out the base board came out cleanly.

With the new capacitors back in, the unit was re-assembled.

Of note, in the middle shot above, make sure to line up the carry-handle with the slot it fits through. In the last shot, make sure to re-connect the speaker cable to the motherboard before screwing down the drive-bay plate.

With it all together, voltages were checked and the 12v rail was quite high! With no load, this was mildly expected. I slapped in a sacraficial HDD and hit the power... it spun up and the motherboard speaker even beeped! I was good to continue the testing.

Video Out

Long-story-short... it's a 71.9hz vertical sync signal at 15.978khz horizontal. This doesn't match MDA, CGA or EGA... let alone anything higher.

The video port is a 9-pin male DB-9 with both syncs, video and a dangerous -12v pin. Don't just hook this up to anything non-Apricot!

I attempted with some logic to invert the vertical sync as it was mentioned somewhere that it might be negative and needs to be positive, but that didn't work.

The GBS-8200 didn't work either! So, what to do? Let's test something that's been on the shelf for a while...

I hadn't tested out the oscilliscope before and I still don't know how to use it. I was happy to see it seeing signals... but I couldn't work out if the frequencies were at the numbers I needed. I then realised my retro-corner LCD supports 15khz and threw together a test-wire straight through to VGA plug:

Hello there! It's totally failing to work out the vertical refresh rate... but that's fine... this thing is running a VGA vertical refresh with an EGA horizontal... it was never expected to 100% work without some kind of conversion. Just for fun, here's the specifications:

----CRT DATA DISPLAY SPECIFICATIONS---
PHYSICAL CHARACTERISTICS
Dimension	174mm max.
Height	241 ±1.5 mm
Width	226±5.0 mm
Depth	6.2 Ibs (2.8 kg)
Weight	240AMB39 polish
Picture Tube	Visual 9" 90° def. 20 mm dia.
Tilt	10° ± 1°
ELECTRICAL CHARACTERISTICS OF CRT DISPLAY MONITOR
Power Requirements	DC 11.8V 1.0A
Video Input Signal Requirements	Black level = 0 + 0.4 -O.OV White level = 4 ± 1.5V
Input Impedance	300 ohms min 40pF max.
VERTICAL INPUT SYNC SIGNAL REQUIREMENTS
Active Polarity	Positive
Pulse Rate	71.9 Hz
Pulse Width	158us
Amplitude	Low = 0 + 0.4 -O.OV High = 4 ± 1.5V
Input Impedance	1 Kohm min. 40pF max.
HORIZONTAL INPUT SYNC SIGNAL REQUIREMENTS
Active Polarity	Positive
Pulse Rate	15.79 kHz
Pulse Width	8.0us
Amplitude	Low = 0 + 0.4 -O.OV High = 4 ± 1.5V
Input Impedance	2 Kohms min. 40pF max.
Video Amplifier Band Width	25 MHz typ
Resolution	>= 800 TV Lines at center >= 650 TV Lines at corner
Vertical Character Area	120 ±5mm
Horizontal Character Area	150 ±5mm * According to the attached timing chart * +B = 11.8 ± 0.05V
BLANKING TIME REQUIREMENTS
Vertical	1200us min.
Horizontal	lOus min.
Vertical Deflection Linearity	10%
Horizontal Deflection Linearity	10% ((max - min)/(max + min) x 100)

So, what next? Find someone else that's built a 15khz VGA adapter. Writing this now, after building the MCEBlaster, I can't help but wonder if I should not have gone the simpler route and built the qiqitori analog-RGB to VGA adapter?

The MCEBlaster is multi-purpose for MDA/CGA/EGA, but none of those suit this display output! MDA is close, but it's still a reach from the resolution this unit is outputting. Using qiqitori's adapter, I could've just customised the code directly for this machine.

REGARDLESS, I didn't have this hindsight and built the MCEBlaster. In fact, I built it to the the schematic... expecting my video pin display data to be fed into all three coloured RGB TTL lines at once...

This was wrong, and with code changes forcing the EGA lines to 72hz vertical (which the code was picking up as the input signal, correctly), I got the following:

With a silly amount of tinkering (as this was never going to work as EGA is too limited to display the full EGA picture), I eventually got quite a bit of the picture to display!:

As mentioned, trying to fit 800x400 in 320x240 was never going to work. We're an MDA-esque signal and the board had full provision for such. I should have, from the start, fed the image into the input as if it was an MDA plug. This meant we needed to input video data on pin 7 and intensity on pin 6.

Unfortunately, the Apricot doesn't output an intensity pin, so pin 6 can be grounded. My wiring between the 74LVC245 and Pico could stay, as per the schematic, as the Pico knew to look on pins 26 and 27 if the vertical frequency was correct. I adjusted the MDA modeline config to look for 72hz (rounded-up) sync and we started getting somewhere...

I already had that encroaching feeling of Why am I doing this? If/when it works, what will I do with it?... so this was a good enough video output to test the rest of the peripherals. The error shown above is Error 31 and it means that Keyboard diagnostics failed.

Keyboard Input

As always, someone has already done this before. I built the circuit and plugged everything together expecting things to just-work, but I still got Error 31!

With the arduino connected, there was no data showing as coming from the Apricot? I checked the MAME source code for the Apricot keyboard and you could see that the keyboard was meant to receive a reset command from the computer and respond with an ACK:

		case CMD_KEYBOARD_RESET:
			logerror("System requests keyboard reset\n");
			transmit_byte(ACK_DIAGNOSTICS);
			break;

The computer stayed silent towards everything I threw at it. No amount of forced-sending of control codes from the keyboard to the computer worked, so I hooked up the oscilloscope to the data pin 2 of the keyboard port and yeah, the transmit signal from the computer to the keyboard was held high and had a not of noise. Interestingly though, pressing CTRL+ALT+DEL on the keyboard actually did reset the Apricot? The apricot-kbd arduino code has a special block where sees a reset request and holds the transmission line to ground for 100ms. Is this the required signal? I checked the schematics again and noticed that there was a special path for a system reset request.

Above, you can see the keyboard connector in the green box on the left. The two standard paths are orange and blue and they travel through respective MC1489/MC1488 paths to the Z80 SIO/0. I'm getting nothing from, and seemingly sending nothing to, this chip... so the only reason reset would work is via the purple path down the bottom.

Just for fun, I dismembered the trace between the SIO and the MC1488 on the outbound TX line to see if the MC1488 was the issue. Doing so still saw a high and messy voltage on the Z80A SIO/0 side, meaning something was wrong it, or with a chip further towards the CPU. Whilst doing all this, I happened to press my finger down on the SIO and found that it was hot enough to fry an egg! No wonder it's lid is so smooth and shiny.

It was a very quick removal. A socket was installed and... I found a pair of ICs (supposedly new-old-stock) on eBay. The machine was put back in the corner of the room... unscrewed, but neatly stacked. The ICs came in due course and one was installed.

And...?

PS2 to Xi
Value FA - Status Bits 0  Code 0xFA [�]   --  .
Value AA - Status Bits 0  Code 0xAA [�]   --  5F
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
----------From Apricot:
0 [] 
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 2B - Status Bits 0  Code 0x2B [+]   --  60
Value 802B - Status Bits 80  Code 0x2B [+]   --  FFFFFFE0
Value 11E - Status Bits 1  Code 0x1E []   --  40
Value 811E - Status Bits 81  Code 0x1E []   --  FFFFFFC0
----------From Apricot:
E8 [�] 
----------From Apricot:
E8 [�] 
----------From Apricot:
E2 [�] 
----------From Apricot:
D0 [�] D4 [�] AA [�] E3 [�] 0 [] E2 [�] 81 [�] 52 [R] 41 [A] 4D [M] 20 [ ] 35 [5] 31 [1] 32 [2] 4B [K] 
Value 11E - Status Bits 1  Code 0x1E []   --  40
Value 811E - Status Bits 81  Code 0x1E []   --  FFFFFFC0

Wowzers... it's reporting 512K RAM to the non-existent Keyboard LCD! The paired values are from the PS/2 Keyboard keypresses and the data from the Apricot is self-explanatory once you've read the opcodes over here.

  if (Serial1.available()) {
    Serial.println("----------From Apricot:");
    while (Serial1.available())
    {
      uint16_t b = Serial1.read();
      Serial.print(b, HEX);
      Serial.print(" [");
      Serial.print((char)(b & 0xff));
      Serial.print("] ");

      switch (b)
      {
        //keyboard reset. just ACK
        case 0xe8: Serial1.write(0xfb); break;

      }
    }
    Serial.println("");
  }
}

Above is the only bit I changed when compared to the git repo.

Floppy Disk

This thing is a monstrosity, and didn't work at the start. It wasn't until I replaced the ZIO above that the floppy started seeking on boot and showing other signs of life. I haven't got a floppy disk formatted for this unit yet, but it really does seem that a catastrophic event occurred to wreck a whole bunch of chips in this machine. With one fixed, the data bus may well have been free'd up to communicate. It does still seem that once the machine has warmed up, that more faults start occurring. I'm guessing RAM? Either way, here's the beast of a drive:

If I can get it working more-consistently then I'll use apridisk to write disk images and have fun... but that's for another post. This one has gone on long enough!

Heat-Activated Gremlins

It seems that there are still issues with this machine. With the keyboard responding with an ACK, the system is finally reporting System OK on a cold boot, but starts to lose it once it's warmed up. After hitting enter at the prompt, the following message was displayed:

You can tell it's coded into the autoexec.bat file. Whilst trying to search for files on the Winchester Disk that others may have left behind, I initially received proper disk directory listings... until I didn't.

Letting the machine cool down again saw those same error'd directories list fine... so it's not the HDD itself... it's heat. I left the machine on for 20 minutes and touched all the chips... only the main CPU and its friend were (burningly) hot.

Could I be bothered replacing it? Should I heatsink the crap out of it to test further? Why am I even doing all of this? No idea.