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”
I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.
So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.
Not only do I get to watch my mistakes in near real time, I get to make a video about it.
Getting Data Out of a Vehicle
I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).
To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.
At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.
Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.
Any maker worth their bits will look for new ways to challenge themselves. [Robert Fotino], a computer science student at the University of California, is doing just that: designing and building his own lightweight hobbyist game console that he has appropriately named Consolite.
[Fotino] wrote his own compiler in C++ that converts from C-like languages to a custom-designed assembler that he has dubbed Consolite Assembly. To test his code, he also wrote an emulator before loading it onto the Mimas V2 FPGA board. Presently, Consolite uses 64KiB of main memory and 48 KiB of video memory; a future version will have 32 bit support to make better use of the Mimas’ 64 MiB of on board ram, but the current 16-bit version is a functional proof of concept.
An SD card functions as persistent storage for up to 256 programs, which can be accessed using the hardware switches on the Mimas, with plans to add user access in the form of saving game progress, storage outside of main memory, etc. — also in a future update that will include audio support.
As it stands, [Fotino] has written his own versions of Breakout, Tetris, and Tron to show off his project.
Not wanting for diligence, [Fotino] has provided thorough documentation of nearly every step along the way in his blog posts and on GitHub if you are looking for guidelines for any similar projects you might have on the back burner — like an even tinier game console.