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.
If we have to make a list of Projects that are insane and awesome at the same time, this would probably be among the top three right up there. For the past few years, [James Newman] has been busy building Megaprocessor – a huge micro-processor made out of transistors and LED’s, thousands of ’em. “I started by wanting to learn about transistors. Things got out of hand.” And quite appropriately, he’s based out of Cambridge – the “City of perspiring dreams“. The Why part is pretty simple – because he can. We posted about his build as recently as 10 months back, but he’s made a ton of progress since then and an update seemed in order.
How big is it ? For starters, the 8-bit adder module is about 300mm (a foot) long – and he’s using five of them. When fully complete, it will stretch 14m wide and stand 2m tall, filling a 30 sq.m room, consisting of seven individual frames that form the parts of the Megaprocessor.
The original plan was for nine frames but he’s managed to squeeze all parts in to seven, building three last year and adding the other four since then. Assembling the individual boards (gates), putting them together to form modules, then fitting it all on to the frames and putting in almost 10kms of cabling is a slow, painstaking job, but he’s been on fire last few months. He has managed to test and integrate the racks shown here and even run some code.
The Megaprocessor has a 16-bit architecture, seven registers, 256bytes of RAM and a questionable amount of PROM (depending on his soldering endurance, he says). It sips 500W, most of it going to light up all the LED’s. He guesses it weighs about half a ton. The processor uses up 15,300 transistors and 8,500 LED’s, while the RAM has 27,000 transistors and 2,048 LED’s. That puts it somewhere between the 8086 and the 68000 microprocessors in terms of number of transistors. He recently got around to calculating the money he’s spent on this to date, and it is notching up over 40,000 Quid (almost $60,000 USD)! You can read a lot of other interesting statistics on the Cost and Materials page.
Continue reading “Megaprocessor is a Macro Microprocessor”