IBM’s 1969 Educational Computing

September 11, 2024 by Alexander Rowsell 13 Comments

IBM got their PCs and PS/2 computers into schools in the 1980s and 1990s. We fondly remember educational games like Super Solvers: Treasure Mountain. However, IBM had been trying to get into the educational market long before the PC. In 1969, the IBM Schools Computer System Unit was developed. Though it never reached commercial release, ten were made, and they were deployed to pilot schools. One remained in use for almost a decade! And now, there’s a new one — well, a replica of IBM’s experimental school computer by [Menadue], at least. You can check it out in the video below.

The internals were based somewhat on the IBM System/360’s technology. Interestingly, it used a touch-sensitive keypad instead of a traditional keyboard. From what we’ve read, it seems this system had a lot of firsts: the first system to use a domestic TV as an output device, the first system to use a cassette deck as a storage medium, and the first purpose-built educational computer. It was developed at IBM Hursley in the UK and used magnetic core memory. It used BCD for numerical display instead of hexadecimal or octal, with floating point numbers as a basic type. It also used 32-bit registers, though they stored BCD digits and not binary. In short, this thing was way ahead of its time.

Continue reading “IBM’s 1969 Educational Computing” →

PC Floppy Copy Protection: Softguard Superlok

September 9, 2024 by Maya Posch 16 Comments

Many have sought the holy grail of making commercial media both readable and copy-proof, especially once everyone began to copy those floppies. One of these attempts to make floppies copy-proof was Softguard’s Superlok. This in-depth look at this copy protection system by [GloriousCow] comes on the heels of a part one that covers Formaster’s Copy-Lock. Interestingly, Sierra switched from Copy-Lock to Superlok for their DOS version of games like King’s Quest, following the industry’s quest in search of this holy grail.

The way that Superlok works is that it loads a (hidden) executable called CPC.COM which proceeds to read the 128 byte key that is stored on a special track 6. With this key the game’s executable is decoded and fun can commence. Without a valid ‘Play’ disk containing the special track and CPC.COM executable all one is instead left with is a request by the game to ‘insert your ORIGINAL disk 1’.

As one can see in the Norton Commander screenshot of a Sierra game disk, the hidden file is easily uncovered in any application that supports showing hidden files. However, CPC.COM couldn’t be executed directly; it needs to be executed from a memory buffer and passed the correct stack parameters. Sierra likely put in very little effort when implementing Softguard’s solution in their products, as Superlok supports changing the encryption key offset and other ways to make life hard for crackers.

Sierra was using version 2.3 of Superlok, but Softguard would also make a version 3.0. This is quite similar to 2.x, but has a gotcha in that it reads across the track index for the outer sector. This requires track wrapping to be implemented. Far from this kind of copy protection cracking being a recent thing, there was a thriving market for products that would circumvent these protections, all the way up to Central Point’s Copy II PC Option Board that would man-in-the-middle between the floppy disk drive and the CPU, intercepting data and render those copy protections pointless.

As for the fate of Softguard, by the end of the 1980s many of its customers were tiring of the cat-and-mouse game between crackers and Softguard, along with issues reported by legitimate users. Customers like Infographics Inc. dropped the Superlok protection by 1987 and by 1992 Softguard was out of business.

The Hidden Crystal Method

September 8, 2024 by Adam Fabio 25 Comments

Ever been working on a project and get stuck on one of those last little details? That’s what happened to [Empire of Scrap]. He’s building an Ohio Scientific (OSI) superboard II replica. He wants it to be accurate down to the dates on the chips. It is quite an impressive build. The problem is the crystal. OSI used large crystals, even by early 1980s standards. The crystal is in a large can with thick pins, like something you’d expect to find in old radio equipment. The problem is that this crystal package isn’t made anymore.

The crystal had to be exactly 3.932160 MHz, and while [Empire] has a huge collection of vintage crystals, he didn’t have the right one from the 70s. He did, however, have that value in a modern crystal.

The solution? Hide the new crystal in the can of an older one. The only problem is that crystals are sealed. The bottom appeared to be some sort of plastic or resin. Gong after it with a side cutter, [Empire] realized it was glass! Thankfully, none of it got in his eyes, though his hands may have taken a bit of a beating.

With the old crystal’s shell hollowed out, [Empire] installed the modern device and potted everything in resin. The transplant worked. Now, all that’s left is to fire up the OSI and start hacking.

Want to build a replica computer but don’t want to hunt down the parts? Check out [Taylor] and [Amy’s] build of this minipet. Regardless of the size of the case, crystals all work in the same way.

Continue reading “The Hidden Crystal Method” →

Building A DIY MSX Mega Cartridge

September 7, 2024 by Dave Rowntree 9 Comments

[Mike] from Leaded Solder has a soft spot for old computers, and a chance encounter with a friend sent them deep down the deep hole that is the world of 80s and 90s-era Japanese home computers. Many people playing with these machines have all kinds of issues to deal with, such as rotting cartridges, failing components, and just dirt and mank in critical places. [Mike] decided that working on an MSX-standard custom programmable cartridge would be sensible, but then got stuck on how the MSX cartridge mapping works.

The Konami 128K scheme uses 4 to 4-of-8 mapping.

You may recall that the MSX platform is not a single computer but a standard to which many (mainly Japanese) manufacturers designed their products. This disconnected the software writers from the hardware makers and is essentially a mirror of the IBM-PC clone scene.

The MSX is based around the Z80, which has a 16-bit address bus, restricting it to 64K of ROM or RAM. The MSX has two cartridge slots, an ‘internal’ slot for the BIOS and RAM and a fourth for ‘misc’ use. Each of these is mapped internally into the physical address space. The cartridge slots have 64K of addressable space mapped into the Z80 physical space.

If this was not complicated enough, many MSX games and applications exceeded this restriction and added a layer of mapping inside the cartridge using bank switching. A register in the cartridge could change the upper bits of the address allowing ROMs larger than 64K.

Continue reading “Building A DIY MSX Mega Cartridge” →

It’s Spreadsheets All The Way Down For This 80s Handheld

September 5, 2024 by Bryan Cockfield 9 Comments

Unlike the today’s consumer computer market, the 1980s were the wild west in comparison. There were all kinds of different, incompatible operating systems, hardware, and programs, all competing against one another, and with essentially no networking to tie everything together. Some of these products were incredibly niche as well, only running one program or having a limited use case to keep costs down. Such was the Convergent WorkSlate, a computer that ran only a spreadsheet with any programs also needing to be built into a spreadsheet.

Upon booting the device, the user is presented with a fairly recognizable blank spreadsheet, albeit with a now-dated LCD display (lacking a backlight) and a bespoke keyboard and cursor that wouldn’t have allowed for easy touch typing. The spreadsheet itself is quite usable though, complete with formatting tools and the capability to use formulas like a modern spreadsheet program would. It also hosted a tape deck for audio and data storage, a modem for communicating with other devices, and an optional plotter-style printer. The modem port is how [Old VCR] eventually interfaces with the machine, although as one can imagine is quite a task for a piece of small-batch technology from the 80s like this. After learning how to send and receive information, a small game is programmed into the machine and then a Gopher interface is built to give the device limited Internet connectivity.

The investigation that [Old VCR] goes into on this project to get this obsolete yet unique piece of hardware running and programmed to do other tasks is impressive, and worth taking a look at especially because spreadsheets like this aren’t Turing-complete, leading to a few interesting phenomenon that most of us wouldn’t come across in the modern computing world. Since only around 60,000 units were ever made it’s difficult to come across these machines, but if you want to take a look at the spreadsheet world of the 80s without original hardware you can still run Lotus 1-2-3 natively in Linux today.

Thanks to [Cameron] for the tip!

The Computer We All Wish We’d Had In The 8-Bit Era

August 31, 2024 by Jenny List 38 Comments

The 8-bit home computers of yore that we all know and love, without exception as far as we are aware, had an off the shelf microprocessor at heart. In 1983 you were either in the Z80 camp or the 6502 camp, with only a relatively few outliers using processors with other architectures.

But what if you could have both at once, without resorting to a machine such as the Commodore 128 with both on board? How about a machine with retargetable microcode? No, not the DEC Alpha, but the Isetta from [RoelH]— a novel and extremely clever machine based upon 74-series logic, than can not only be a 6502 or a Z80, but can also run both ZX Spectrum games, and Apple 1 BASIC. We would have done anything to own one of these back in 1983.

If retargetable microcode is new to you, imagine the instruction set of a microprocessor. If you take a look at the die you’ll find what is in effect a ROM on board, a look-up table defining what each instruction does. A machine with said capability can change this ROM, and not merely emulate a different instruction set, but be that instruction set. This is the Isetta’s trick, it’s not a machine with a novel RISC architecture like the Gigatron, but a fairy conventional one for the day with the ability to select different microcode ROMs.

It’s a beautifully designed circuit if you’re a lover of 74 logic, and it’s implemented in all surface mount on a surprisingly compact PCB. The interfaces are relatively modern too, with VGA and a PS/2 keyboard. The write-up is comprehensive and easy to understand, and we certainly enjoyed digging through it to understand this remarkable machine. We were lucky enough to see an Isetta prototype in the flesh over the summer, and we really hope he thinks about making a product from it, we know a lot of you would be interested.

Exploring PC Floppy Protection: Formaster Copy-Lock

August 27, 2024 by Dave Rowntree 35 Comments

[GloriousCow] has started working on a series of investigations into the various historical floppy disk copy protection schemes used in the early days of the IBM PC and is here with the first of these results, specifically Formaster’s Copy-Lock.

This is the starting sector of track 6. It looks empty, but it’s not quite.

The game in question is King’s Quest by Sierra Entertainment, which used a ‘booter disk’ with the Copy-Lock protection scheme. Instead of having to boot DOS separately, you could just insert this disk and the game would launch automatically. Early copy protections often used simple methods, like adding sectors with non-standard sizes or tampering with sector CRC values to create disk errors. Copy-Lock employed several such tricks together, making it challenging for standard floppy disk hardware to replicate. In the case of Copy-Lock, Sector 1 on track 6 was intentionally written as only 256 bytes, with a 256-byte blank section to fill the gap. Additionally, the CRC was also altered to add another layer of protection.

When attempting to read the disk, the PC BIOS interrupt routine assumes it’s looking for a standard 512-byte sector, so when a “read sector” command is issued to locate the sector, it never finds it. To detect a dodgy copy, the game bypasses the BIOS and talks directly to the floppy disk controller using some custom code. The first part of the code uses the standard INT 13h routine to seek to track 6, sector 1, where it expects a fail since there is no valid sector there. Next, the floppy controller sends the “read track” command to perform a raw dump of all 512 bytes at this address and looks for a magic number, 0xF7, sitting in the final byte. That empty second half of the short sector is indeed not empty and is the check the game makes to determine if it was written with the Copy-Lock capable hardware. That last point is pertinent; you can’t create this disk structure with a standard IBM PC floppy disk controller; you need specialized hardware that can write different-sized sectors and incorrect CRCs, and that costs money to acquire.

We recently covered the copy protection scheme used for Dungeon Master on the Atari ST and the Amiga. If you’re thinking less about how a floppy got cracked and copied and more about how to preserve these digital relics, check this out!