Building A DIY MSX Mega Cartridge

[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

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

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

[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!

Using The Pi Pico As ‘Programmable Hardware’ For The Apple II

When we think of programmable hardware, we think of FPGAs. But they’re not the only option. [Oliver Schmidt] has been exploring how the Raspberry Pi Pico can serve in such a role for the classic Apple II. The talk was presented at the KansasFest event this year, and it’s well worth diving into!

[Oliver] has developed A2Pico. It’s a series of Apple II peripheral cards that are based around the Raspberry Pi Pico, as you might have guessed. [Oliver] has been working in the area since 2021 with one [Glenn Jones], with the duo experimenting with connecting the versatile microcontroller directly to the slot bus of the Apple II. [Ralle Palaveev] then chimed in, developing the A2Pico hardware with solely through-hole components for ease of assembly.

A number of cards have been developed based on A2Pico, including a storage device, a Z80 CP/M card, and a specialized card to play Bad Apple on the IIGS. It’s all thanks to the versatility of the programmable I/O (PIO) peripheral inside the Raspberry Pi Pico. This device enables the Pico to be reprogrammed to handle all sorts of complicated tasks at great speed. This is particularly useful when using it to bit-bang a protocol or talk with another machine, and it serves perfectly well in this role. Basically, by reprogramming the Pico and its PIO, the A2Pico design can become any one of a number of different add-on cards.

It’s well worth diving into this stuff if you’ve ever contemplated building your own peripheral cards for 8-bit and 16-bit machines. We’ve seen some other great add-on cards for vintage machines before, too.

Continue reading “Using The Pi Pico As ‘Programmable Hardware’ For The Apple II”

The Macintosh Plus Sounds Great If You Do Exactly This With It

The Macintosh Plus is not exactly known as particularly relevant in the worlds of chiptune or electronic music more broadly. That’s not to say it can’t do anything that sounds cool, however. As [Action Retro] demonstrates,  it’s got some really impressive tricks up its sleeve if you know what you’re doing.

The video centers around “Music Mouse”, a piece of software created by Laurie Spiegel for the Macintosh Plus all the way back in 1986. Spiegel saw the Macintosh Plus as a potential instrument for musical expression, with the then-innovative mouse as the key human interface.

[Action Retro] shows off the software, which is able to create rather pleasing little melodies with little more than a swish and a swash across the mousepad. The software makes smart use of scales so you’re not forever dodging around dissonant notes, so it’s quite easy to play something beautiful. He then makes things more interesting by pairing the Macintosh Plus with his favorite guitar pedal—the Old Blood Noise Endeavors Sunlight. It’s a dynamic reverb that really opens up the sonic landscape when paired with the Mac Plus. If you’re looking for a weird avant-garde setup to take on stage at your next noise show, this has to be it.

We’re usually used to seeing Nintendo and Commodore products in the retro computer music space. The Mac makes a nice change. Video after the break.

Continue reading “The Macintosh Plus Sounds Great If You Do Exactly This With It”

Everything You Wanted To Know About Early Macintosh Floppies

Using a disk drive today is trivial. But back “in the day,” it was fairly complex both because the drives were simple and the CPUs were not powerful by today’s standards. [Thomas] has been working on a 68000 Mac emulator and found that low-level floppy information was scattered in different places. So he’s gathered it all for us in one place.

Low-level disk access has a lot of subtle details. For example, the Mac calibrates its speed control on boot. If your emulated drive just sets the correct speed and doesn’t respond to changes during calibration, the system will detect that as an error. Other details about spinning disks include the fact that inner tracks are shorter than outer track and may require denser recordings. Laying out sectors can also be tricky since you will lose performance if you, for example, read sector one and then miss sector two and have to wait for it to come back around. Disk sectors are often staggered for this reason.

Adding to the complexity is the controller — the IWM or Integrated Woz Machine — which has an odd scheme for memory mapping I/O. You should only access the odd bytes of the memory-mapped I/O. The details are all in the post.

In a way, we don’t miss these days, but in other ways, we do. It wasn’t that long ago that floppies were king. Now it is a race to preserve the data on them while you still can.