Being an early adopter is great if you enjoy showing off new gadgets to your friends. But any new technology also brings the risk of ending up at the wrong side of a format war: just ask anyone who committed to HD-DVD fifteen years ago. If, on the other hand, you were among the few who invested in CD-ROM when it was first released in the mid-1980s, you definitely made the right choice when it came to storage media. However, it was a bit of a different story for the interface that hooks up the CD drive to your computer, as [Tech Tangents] found out when he managed to get his hands on a first-generation CM100 drive. (Video, embedded below.)
That wonderful piece of 1985 technology is not much smaller than the IBM PC it was designed to connect to, and it originally came with its own CM153 ISA interface card. But while most eBay sellers recognized the historic value of a pioneering CD-ROM drive, the accompanying PC was typically a dime-a-dozen model and was thrown out with the rare interface card still inside. Even after searching high and low for over a year, the only information [Tech Tangents] could find about the card was a nine year old YouTube video that showed what the thing looked like.
Luckily, the maker of that video was willing to take high-resolution pictures of the card, which allowed [Tech Tangents] to figure out how it worked. As it turned out, the card was entirely made from standard 7400 series logic chips as well as an 8251 USART, which meant that it should be possible to design a replacement simply by following all the traces on the board. [Tech Tangents] set to work, and after a few weeks of reverse-engineering he had a complete schematic and layout ready in KiCAD.
After the PCBs were manufactured and populated with components, it was time to test the new card with the old drive. This wasn’t a simple process either: as anyone who’s tried to get obscure hardware to work in MS-DOS will tell you, it involves countless hours of trying different driver versions and setting poorly documented switches in CONFIG.SYS. Eventually however, the driver loaded correctly and the ancient CD-ROM drive duly transferred the files stored on a Wolfenstein 3D disk.
If you’re lucky enough to own a CM100 or a similar drive from that era, you’ll be happy to know that all design files for the CM153 clone are available on GitHub. This isn’t the first time someone has had to re-create an interface board from pictures alone: we’ve seen a similar project involving a SCSI card for a synthesizer. Thanks for the tip, [hackbyte]!
Interesting. Someone offered the VCFed group an IOMEGA drive, no not a Zip-drive, the other one. Also a batch of drives for it. I pointed out on the mail list that it normally worked with a specially designed SCSI card for it. The response, was that the original owner had binned the card inside the computer who normally used it. Eventually they tracked down a computer and software and the card to make use of it. The computer was a Compaq P3 and its backpockets slots. After a fashion it worked.
A Bernoulli Box?
Probably Jaz if it was Iomega
It may have used a SASI interface, a precursor to SCSI.
I spent a summer many years ago fixing these early CD ROM drives. The primary fixes were of two types –
1) Turn up the brightness of the read head LED by way of a small pot.
2) Disassemble the spindle assembly, flip over the plate the thrust bearing pushed against [and tried to wear a hole thru], and re-assemble the asssembly.
That fixed [well enough for them to work for another year or so] 90% of the malfunctioning units.
[They were hot sellers at local computer shows.]
I just saw that. What a heroic effort!
Especially when dealing with…software.
ISA cards were popular among DIYers, you could interface electronics much easier then PCI.
Definitely. ISA just hands you the bus, a GAL or a PLA or heck even some simple MSI to recognize your addresses and you’re in business. Whack the IRQ line of your choice. It’s all on the poor system owner to make sure you don’t conflict with some other ISA h/w. Of course, as a DIY’r, you’re on top of that.
PCI otoh is a monster, not entirely unlike VME. You need this rather complex chunk of h/w logic just to exist on the PCI bus, above and beyond any application specific h/w logic you had in mind. It’s got to recognize PCI protocols, which are much more complicated than simple memory or I/O cycles. Device enumeration, for example. But if you wanted to make your device at scale and sell it to the widest possible audience, all that removed the burden on the users to deconflict addresses and interrupts.
Deconflicting bus things didn’t fully happen in PC land until Windows 98SE. All variants of Windows 95 would happily mis-assign two supposedly Plug N Play devices to the same resources, mostly parallel ports and soundcards. Even more fun was when I’d manually re-assign the sound card to absolutely not-conflicting with the standard LPT resources, and Windows would reassign the LPT port to non-standard resources, the same ones I’d just switched the soundcard to. So I’d have to manually set the LPT back to what it should be.
Windows 98 made a start on resource sharing. 98SE perfected it. I don’t recall ever having to manually force 98SE to stop assigning the same address, IRQ, or DMA to two devices, because Windows had finally learned how to share things.
I could have sworn I still had a few conflicts in 98SE myself. That was so long ago… maybe I am misremembering. I don’t know. I used a lot of mixed hardware from different generations and often mixed in non-plug and play devices so maybe it took longer for that sort of setup to work.
It seems to me that people who are used to Plug and Play that actually works tend to think the old days of setting IRQs and memory addresses manually via jumpers were a terrible dark age but they have no idea what the first several years of PnP (aka Plug and Pray) were like and how much better jumpers were. I mean sure, nobody expects to have to understand all the details of IRQs and memory addresses to use a modern computer but “just don’t pick the same number in two places” isn’t exactly rocket science.
“the old days of setting IRQs and memory addresses manually via jumpers”
Yeah those days where you had to identify in your BIOS if the address was still free, and set the jumper on the card accordingly! I had a SCSI ISA card from Adaptec where this was the first hurdle, after it was the terminators on the SCSI bus. That was for my first CD burner, I was too poor to buy a PCI adapter.
In my experience the PCI hardware went through several iterations from manually assigned, through early Plug’n’Play pre-ACPI that was a roulette wheel, slgihtly mature ACPI which was better but had some issues, through to late/modern ACPI where it actually worked 99% of the time and various OS had variously successful interactions with it. That was about up to ’95, ’96 , ’97 and ’98 up with overlap depending on how on the ball various manufacturers were and whether your “new” motherboard was last years model with a fresh application of lipstick. And your specific mix of devices.
I miss ISA. Never quite understood the need for its removal, especially because internal motherboard logic still uses ISA/LPC. The temperature sensors, for example.
Why had the bus to be removed after the Pentium III era ? Why was there no header on the motherboard left, at least? Like there are for COM and LPT. PC/104 was a possibility, too. With am optional converter, traditional ISA cards could still be interfaced, if needed.
IMO the most interesting part is how the traces under the chips were reverse-engineered. Just… wow!
Soooo, when is someone going to re-create the not-quite LPT special interface cards for Hewlett Packard’s first two models of ScanJet flatbed scanners?
There were three variants of the interface card. V1 only works with the ScanJet. V2 only works with the ScanJet II. V3 works with both. Pretty sure the V3 version was created as a service replacement for both, and shipped with the later ScanJet II packages.
IIRC the ScanJet is either 1 or 4 bit monochrome and ScanJet II is 8 bit monochrome. (TLTG)
Despite the controllers being full length (or nearly full length) ISA monsters, the exterior port is an ordinary female DB25. Thus many of the controllers were assumed to be ordinary LPT port connectors or cards and got tossed out with the PCs they were in and the scanners assumed to be parallel port interface.
The only one of these I had personal experience with was a ScanJet II at a small town computer shop I worked at circa 1996-97. The boss asked me if I could do anything with the scanner so I hunted around the web to dig up the technical info, then eventually found a V3 card at a steal of a price. Then I dug out an old 486 and set it up with Windows, a 14.4K FAX modem and FAX software plus some older inkjet printer we had laying around. Might have had to use Windows For Workgroups 3.11 on it. I don’t remember if the HP software for those two scanner models worked in Windows 95.
When I was done with it, it made a speedy FAX machine that was capable of doing the best FAXes the technology was capable of. It also made a pretty good copy machine. I don’t recall if we sold it all together or if we eventually sold the scanner and card and computer and printer separately. The computer minus scanner would’ve had Windows 95 on it.
I suspect that the likely eventual fate of that hard to come by V3 ScanJet controller was getting thrown away with a computer because it got mistaken for an ordinary parallel port, though I just remembered I did mark the outside of it next to the DB25 that it was for ScanJet. Might have put not LPT on it too.
I thought ScanJets were SCSI… HP even calls their card SCSI…
http://www.hpmuseum.net/display_item.php?hw=880
This is also what I recall. Same DB25 SCSI that was also used by Apple Mac computers that had an external SCSI interface. Actually, quite logical as that would be the go-to computer for Image editing around that time.
Laser Magnetic Storage International sounds like a pretty sweet band name
I like how the silk screen labels the chips.
I see this was uploaded to youtube just 4 days ago, and the reverse engineering effort took some time.
On 2022-07-17 KiCad-nightly has been blessed with the ability to load bitmap images (and set transparency) directly into the PCB editor.
https://forum.kicad.info/t/post-v6-new-features-and-development-news/32633/58
This should make such reverse engineering jobs a lot more streamlined. Especially when reverse engineering the schematic and the PCB at the same time. The combination of ERC and DRC can be used as a continuous sanity check during the effort.
Note that projects made in KiCad-nightly can not be opened in older KiCad versions (such as the current stable version). It’s the intention of the KiCad project to release a stable version once a year, and this should then become part of KiCad V7 somewhere around January 2023.
Thank you so very much for mentioning this new feature!
I’ve long wanted to be able to load a scan of a circuit diagram from an old electronics magazine or photos of PDP-11 Flip Chips as a subdued background layer, and then be able to ‘overdraw’ the connections and place components.
Exactly as Jerry Walker shows here, using the ‘Reverse Engineering’ feature of a proprietary program called ‘Easy PC’ to produce a new Hazeltine terminal board:
https://www.youtube.com/watch?v=YeEP9vVMfx4
I had asked this before about how to do it in KiCad but as a newbie I found the explanation I got was too finicky for me to follow and I couldn’t get it to work.
So, looking forward to this reverse engineering type of feature in KiCad very very muchly!