When [Ezra Thomas] needed inspiration for his senior design project, he only needed to look as far as his own robot. Built during his high school years from the classic 1979 Frank DaCosta book “How to Build Your Own Working Robot Pet”, [Ezra] had learned the hard way the many limitations and complexities of the wire wrapped 74xx series logic chips surrounding its 8085 processor.
[Ezra] embarked on a quest to recreate the monstrosity in miniature, calling it Pet on a Chip. Using a modern FPGA chip allows the electronics to shrink by an order of magnitude and provides flexibility for future expansion. Implementing an 8 bit CPU on the amply sized FPGA left plenty of room for a VGA GPU, motor controller, serial UART, and more. Programming the CPU is handled by a custom assembler written in Python.
The results? Twelve times less weight, thirteen times less power draw, better performance, and a lot of room for growth. [Ezra] hints at an I2C bus expansion as well as a higher level programming language to make software development less of a hurdle.
The Pet On A Chip is a wonderfully engineered project and we hope that we’ll be seeing more such from [Ezra] as time goes by. Watch his Pet On A Chip in action in the video below the break.
If [Ezra]’s FPGA escapades have you wondering how to get started, you can check out this introduction to FPGA from the 2019 Hackaday Superconference. And if you have your own FPGA creation to share, please let us know via the Tip Line!
Continue reading “Robot Pet Is A Chip Off The Old Logic Block”
David Letterman made the top ten list famous. [Creel] has a top ten that should appeal to many Hackaday readers: the top 10 craziest x86 assembly language instructions. You have to admit that the percentage of assembly language programmers is decreasing every year, so this isn’t going to have mass appeal, but if you are interested in assembly or CPU architecture, this is a fun way to kill 15 minutes.
Some would say that all x86 instructions are crazy, especially if you are accustomed to reduced instruction set computers. The x86, like other non-RISC processors, has everything but the kitchen sink. Some of these instructions might help you get that last 10 nanoseconds shaved off a time-critical loop.
Continue reading “Oddball X86 Instructions”
Imagine you’re time-warped back to 1979 and tasked with constructing a personal computer. Could you do it? [RadicalBrad] thinks he can, and his 6502-based “Super VIC” build looks like it’s off to a great retrocomputing start.
Most emulations of old hardware these days go the FPGA route, and while we respect those projects immensely, there’s something to be said for applying a highly artificial constraint at the outset of a project. [RadicalBrad] chose to design like it’s 1979, and limited his ode to the machines of his youth to the 6502 CPU and logic and RAM chips available before 1980. The computer will support NTSC video output and 4-channels of 8-bit sound. No circuit boards will be used – everything is to be assembled on solderless breadboards. So far he has 48 (!) of them ganged together, which sounds like an enormous amount of space to work with, but he still found things crowded enough that some of the DIP bodies were trimmed a bit to fit more closely on the breadboards. The SRAM posed a problem, though, in that the 512K chips he wanted were not available in DIPs. To stay faithful to the constraints, he soldered the SOJ-packaged RAM chips into 40-PIN DIP headers – all 25 chips! We can’t recall a PC of the era sporting 12 megabytes of RAM, but no matter – it’s too cool not to love.
[RadicalBrad] has his work cut out for him, and this could take years to finish. We’re keen to follow his progress and can’t wait till it boots for the first time. Until it does, we’ll just gaze upon such discrete computing wonders as this almost-as-simple-as-possible computer, or even this delightfully noisy adder for a relay computer.
Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.
So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.
We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.
Continue reading “35C3: A Deep Dive Into DOS Viruses And Pranks”
You have a clean MSDOS system, and you need to write some software for it. What do you do? You could use debug, of course. But there are no labels so while you can get machine code from mnemonics, you’ll still need to figure out the addresses on your own. That wasn’t good enough for [mniip], who created an assembler using mostly batch files. There are a few .COM files and it looks as if the first time you use debug to create those, but there’s also source you can assemble on subsequent builds with the assembler.
Why? We aren’t entirely sure. But it is definitely a hack. The technique sort of reminded us of our own universal cross assembler — sort of.
Continue reading “Bootstrapping An MSDOS Assembler With Batch Files”
Imagine having to program your computer by rewiring it. For a brief period of time around the mid-1940s, the first general-purpose electronic computers worked that way. Computers like ENIAC initially had no internal storage for code. Programming it involved manipulating thousands of switches and cables. The positions of those switches and cables were the program.
Kathleen Booth began working on computers just as the idea of storing the program internally was starting to permeate through the small set of people building computers. As a result, she was one of the first programmers to work on software and is credited with inventing assembly language. But she also got her hands dirty with the hardware, having built a large portion of the computers which she programmed. She also did some early work with natural language processing and neural networks. And this was all before 1962, making her truly a pioneer. This then is her tale.
Continue reading “Kathleen Booth: Assembling Early Computers While Inventing Assembly”
While discussing the design, [Francis] reveals his first pass at the instruction set, discussed what he found wrong about it, and then reveals the final set composed of real instructions and some macros to handle other common cases.
Continue reading “Virtual CPU Stays On Script”