The Intel 8085 microprocessor was introduced 40 years back, and along with its contemporaries — the Z80 and the 6502 — is pretty much a dinosaur in terms of microprocessor history. But that doesn’t stop it from still being included in the syllabus for computer engineering students in many parts of the world. The reason why a 40 year old microprocessor is still covered in computer architecture text books instead of computer history is a bit convoluted. But there’s a whole industry that thrives on the requirements of college laboratories and students requiring “8085 Microprocessor Training Kits”. [TisteAndii] just finished college in Nigeria, where these kits are not locally built and need to be imported, usually costing well over a 100 dollars.
Which is why his final year project was a low cost Intel 8085 Microprocessor Trainer. It’s a minimalist design with some basic read/write memory, program execution and register inspection, with no provision for single stepping or interrupts yet. The monitor program isn’t loaded in an EEPROM. Instead, a PIC18 is used and connected to the 8085 address, data and control pins. This makes it easier to write a monitor program in C instead of assembly. And allows use of a 1.8″ LCD with SPI interface instead of the more usual 7-segment displays used for these kind of kits. [TisteAndii] built a 6×4 keyboard for input, but couldn’t solve debounce issues and finally settled on a 5×4 membrane keypad.
Being a rookie, he ended up with a major flaw in his board layout — he missed connecting the SRAM and the PPI devices to the data bus. A bunch of jumper links seemed to solve the issue, but it wasn’t perfect. This, and a few other problems gave him a lot of grief, but towards the end, it all worked, almost. Most importantly, his BoM cost of about $35 makes it significantly cheaper compared to the commercial units available in Nigeria.
While some hackers may consider this a trivial project, it solves a local problem and we hope the next iteration of the design improves the kit and makes it more accessible.
With ubiquitous desktop computing now several decades old, anyone creating an operating system distribution now faces a backwards compatibility problem. Each upgrade brings its own set of new features, but it must maintain compatibility with the features of the previous versions or risk alienating users. If you are a critic of Microsoft products for their bloat, this is one of the factors behind that particular issue.
As well as a problem of compatibility, this extra software overhead creates one of security. A piece of code descended from a DOS word processor of the 1980s for example was not originally created with any idea that it might one day be hiding in a library on a machine visible to the entire world by the Internet. Our subject today is a good example, just such a vulnerability hiding in an old piece of code whose purpose is to maintain an obscure piece of backward compatibility. [Chris Evans] has demonstrated a vulnerability in an Ubuntu version by playing an NES music file that contains exploit code emulated by the player on a virtual 6502 processor.
The NES Sound Format is a music file standard that packages Nintendo game music for playback. It contains a scripting language, and it is this that is used to trigger the vulnerability. When you open an NSF file on the affected Ubuntu system it finds its way via your music player and the gstreamer multimedia framework to libgstnsf.so, a gstreamer plugin for playing NSF files.
Rather unbelievably, his plugin works by emulating a real 6502 as found in a NES to derive the musical output, and it is somewhere here that the vulnerability exists. So not only do we have layer upon layer of backward compatibility to play an obscure music file format, there is also a software emulation of some 8-bit silicon from the 1970s. [Chris] comments “Is that cool or what?“, and while we agree that a 6502 emulator buried in a modern distro is cool, we can’t help thinking something’s been lost along the way.
A proof-of-concept is provided for Ubuntu 12.04. It’s an older version, but he points out that while he thinks the most recent releases should not contain exactly the same vulnerability, it certainly exists in more than one still-supported version. There’s also a worrying twist in that due to the vagaries of Ubuntu’s file manager it auto-opens when its folder is accessed from the GUI. The year 2000 called, they want their auto-opening Windows ME worms back.
Sadly we suspect the 6502 lurking in this music player can’t be put to more general-purpose use. If you manage it, please do share it with us! But if emulated 6502s are your thing, take a look at this 150MHz 6502 co-processor for an Acorn BBC Micro that someone made using a Raspberry Pi.
6502 image, Dirk Oppelt, (CC BY-SA 3.0) via Wikimedia Commons.
If you are of the generation who were lucky enough to use the first 8-bit home computers in your youth, you will be familiar with their use of cassette tapes as mass storage. Serial data would be converted to a sequence of tones which could then be recorded using a standard domestic cassette recorder, this recording could then be played back into the machine’s decoder and loaded into memory as a complete piece of software. Larger programs could take a while to load, but though it was rather clunky it was a masterful piece of making the best of what was at hand.
[Mike Kohn] was working with some microcontroller infra-red communication projects when he saw that the same techniques could be used to produce a tape interface like those on the home computers of old.
Over the years he has returned to the project a couple of times, and his original Atmel processor has been supplanted by a W65C265SXB development board based on the 16-bit derivative of the 6502. This made generating the tones as straightforward using his processor’s built-in tone generator, but decoding still presented a challenge. His earlier attempts used an LM2917 frequency to voltage converter to decode tones to logic levels, but on further consideration he decided to move to the LM567 tone decoder. This chip is designed specifically for an on-off logic output rather than the 2917’s analogue voltage output.
His recording device was originally a hi-fi separate cassette deck after experimenting with microcassettes, but eventually he used a data recorder designed for a Radio Shack TRS-80. All his code can be found in his GitHub repository.
It’s probably true to say that [Mike] has made a better cassette interface than the one you could have found on your home computer back in the day. We’ve featured a few data cassette hacks over the years, including this Commodore tape deck with an LED counter, and a tape deck emulator capable of holding an entire software archive.
If you are a gamer of A Certain Age, it’s probable that you retain a soft spot for 8-bit computers and consoles of your youth. For a time when addictive gameplay came through the most minimal of graphics, and when gaming audio was the harshest of square waves rather than immersive soundscapes.
Does the previous paragraph sound familiar? Then we may just have the device for you. The Dodo is a handheld console that harks back to that era with a 6502 processor and a 128×64 pixel OLED screen. Games are loaded from plug-in EEPROM cartridges, and sounds are suitably period-digital square wave tones. It’s the brainchild of [Peter Noyes], and he says he will consider it complete when it sports a game fun enough to entertain his 4-year-old.
The prototype Dodo is a handheld form-factor made from two stacked PCBs. The upper one has the display and buttons while the lower has the classic 6502 and associated chipset in through-hole DIP format. A Game Boy Micro it ain’t, but miniaturization is not the name of the game with these consoles. Best of all though, all the console’s resources are available in a GitHub repository, so you can all have a play too.
The 6502 has featured in a huge number of projects here on Hackaday over the years. Now it’s turned up in the Hackaday Prize.
If you are familiar with ARM processors, you may know of their early history at the 1980s British home computer manufacturer Acorn. The first physical ARM system was a plug-in co-processor development board for Acorn’s BBC Micro, the machine that could be found in nearly every UK school of the day.
For an 8-bit home computer the BBC Micro had an unusually high specification. It came with parallel, serial and analog ports, built-in networking using Acorn’s proprietary Econet system, and the co-processor interface used by that ARM board, the Tube. There were several commercial co-processors for the Tube, including ones with a 6502, a Z80 allowing CP/M to be run, and an 80186.
As with most of the 8-bit generation of home computers the BBC Micro continues to maintain a strong enthusiast following who have not stopped extending its capabilities in all directions. The Tube has been interfaced to the Raspberry Pi, for instance, on which an emulation of original co-processor hardware can be run.
And thus we come to the subject of this article, [Hoglet] and [BigEd]’s 150MHz 6502 coprocessor for the BBC Micro. Which of course isn’t a 6502 at all, but a 6502 emulated in assembler on an ARM which is in a way the very distant descendant of the machine it’s hosted upon. There is something gloriously circular about the whole project, particularly as the Pi, like Acorn, the BBC Micro, and modern-day ARM, has its roots in Cambridge. How useful it is depends on your need to run 8-bit 1980s software in a tearing hurry, but they do report it runs Elite, which if you were there at the time we’re sure you will agree is the most important application to get running on a BBC Micro.
We’ve featured the Tube interface before when we talked about an FPGA co-processor with a PDP/11 mode that was definitely never sold by Acorn. And we’ve also featured an effort to reverse engineer the primordial ARM from that first BBC Micro-based co-processor board.
BBC Micro image: Stuart Brady, Public Domain, via Wikimedia Commons.
There is no CPU that is better understood than the 6502 and its cousins the 6510, 6507, 6509, and whatever we’re calling the CPU in the NES. With this vast amount of documentation, just about anything can be done. Want a discrete and un-discreet 6502? Sure thing. It’s the NMOS version, though. Want an emulated version. Sure. With libraries porting the 6502 to every platform ever, there’s only one place left to go: putting a 6502 in a Commodore 64. Make it dual-core, too, so we can run CP/M.
This build is based on one of [telmomoya]’s earlier builds – a soft-core 6510 running on an ARM Cortex M3. The inspiration for this build came from a 6502 emulator running on an Arduino, which got [telmomoya] wondering what would happen if he attached some external RAM, CIA or a SID. Doing this on an Arduino is hard, but there are a few 5 Volt tolerant ARM chips out there, and with a few banks of SRAM, [tel] quickly had an emulated 6502 running EhBasic.
Running an emulated 6502 on an ARM chip is nothing new. What makes this build spectacular is the adaptation to the C64 motherboard. Since [telmomoya] was already breaking out the data and address lines to go to the SRAMs, it didn’t take much extra work to simply build an adapter for the DIP40 CPU socket on a C64. A few 74-series logic chips made the interface easy, and after a bit of soldering, [telmomoya] had a Commodore 64 powered by an ARM chip.
If you’re emulating one chip, you can emulate two, and with the Commodore 64, this leads to a few interesting possibilities. The C64 had a CP/M cartridge — a cartridge that contained a Z80 CPU, sharing the data and address bus with the 6510. This cartridge allowed the ‘toy computer’ C64 to run the ‘business’ CP/M operating system (and the Z80 made the Commodore 128 much cooler). Since [telmomoya] was already emulating a CPU, emulating a second CPU wasn’t really that hard.
It’s a phenomenal build, and great if you’ve ever wanted to speed up VisiCalc.
I made a bee line for one booth in particular at this year’s Bay Area Maker Faire; our friend [Eric Schlaepfer] had his MOnSter 6502 on display. If you missed it last week, the unveiling of a 6502 built from discrete transistors lit the Internet afire. At that point, the board was not fully operational but [Eric’s] perseverance paid off because it had no problem whatsoever blinking out verification code at his booth.
I interviewed [Eric] in the video below about the design process. It’s not surprising to hear that he was initially trying to prove that this couldn’t be done. Unable to do so, there was nothing left to do but devote almost six-months of his free time to completing the design, layout, and assembly.
What I’m most impressed about (besides just pulling it off in the first place) is the level of perfection [Eric] achieved in his design. He has virtually no errors whatsoever. In the video you’ll hear him discuss an issue with pull-up/pull-down components which did smoke some of the transistors. The solution is an in-line resistor on each of the replacement transistors. This was difficult to photograph but you can make out the soldering trick above where the 3-pin MOSFET is propped up with it’s pair of legs on the board, and the single leg in the air. The added resistor to fix the issue connects that airborne leg to its PCB pad. Other than this, there was no other routing to correct. Incredible.
The huge schematic binder includes a centerfold — literally. One of the most difficult pieces of the puzzle was working out the decode ROM. What folds out of this binder doesn’t even look like a schematic at first glance, but take a closer look (warning, 8 MB image). Every component in that grid was placed manually.
I had been expecting to see some tube-based goodness from [Eric] this year. That’s because I loved his work on Flappy Bird on a green CRT in 2014, and Battlezone on a tube with a hand-wound yoke last year. But I’m glad he stepped away from the tubes and created this marvelous specimen of engineering.