Historians Recreate Source Code of First 4004 Application

mcpublic writes "The team of 'digital archaeologists' who developed the technology behind the Intel Museum's 4004 microprocessor exhibit have done it again. 36 years after Intel introduced their first microprocessor on November 15, 1971, these computer historians have turned the spotlight on the first application software ever written for a general-purpose microprocessor: the Busicom 141-PF calculator. At the team's web site you can download and play with an authentic calculator simulator that sports a cool animated flowchart. Want to find out how Busicom's Masatoshi Shima compressed an entire four-function, printing calculator into only 1,024 bytes of ROM? Check out the newly recreated assembly language "source code," extensively analyzed, documented, and commented by the team's newest member: Hungary's Lajos Kintli. 'He is an amazing reverse-engineer,' recounts team leader Tim McNerney, 'We understood the disassembled calculator code well enough to simulate it, but Lajos really turned it into "source code" of the highest standards.'"

Those were fun

[certsoft (442059)]

Somewhere around 1975 or 1976 I wrote software for a 4004 (using a teletype connected to a modem connected to a mainframe someplace that had the assembler) to run a X-Y table. You would place a wafer with thick-film resistors on it and it would test each one to make sure it was within tolerance and if it wasn't it would mark it with magnetic ink. I think we were probably still using the infamous 1702 EPROMs but there might have been something newer at that time.

Re:

[jacquesm (154384)]

somewhere around 1982 a buddy of mine and myself disassembled and commented microsoft's basic for the trs-80 color computer. Then we improved it with tons of new statements via the hook in ram. Documenting a bloody calculator is childs play compared to that and we weren't especially proud of it, just curious.

Re:

[PopeRatzo (965947)]

somewhere around 1982 a buddy of mine and myself disassembled and commented microsoft's basic for the trs-80 color computer.

And you lived to tell the tale.

And best of all

[Dusty (10872)]

You can still run it on the latest Intel x86 chips. ;)

slashdot headline, 2057:

[circletimessquare (444983)]

"Historians Recreate Source Code of First 404 Error Message"

(truth be told, quick scanning the headlines, that's what my brain registered)

I hate to be a pendantic jerk, but...

[gatekeep (122108)]

"...an authentic calculator simulator..."

What the hell is an authentic simulator?

Re:I hate to be a pendantic jerk, but...

[urcreepyneighbor (1171755)]

Your hand?

zing!

Re:I hate to be a pendantic jerk, but...

[Vegeta99 (219501)]

Na way man, Jill never needs flowers or taken out to dinner. She's better than authentic!

Quickly -- someone send this to MS

[Eberlin (570874)]

Quick, someone send this over to the folks who wrote Excel!

the output is

[geekoid (135745)]

58008

Commander Keen

[QuantumG (50515)]

I once reverse engineered the classic id software game Commander Keen. John Carmack did some cool stuff in that code.. each sprite had two function pointers in it, one was called when the sprite came into contact with another sprite, the other was called every frame to animate the sprite (he called it the "think" function). When you killed a monster the sprite was replaced with a "body" which was just like a sprite but had a few less fields (so it took up less memory). One of the neatest things he did was use this exact same framework of sprites and bodies to animate the "static" parts of the game. For example, the color coded doors that you have to get the key cards to open were sprites with a contact function that checked if the player had the right key card, at which time they would "die" and be replaced by a body that had a think function would make them slide out of the way.

For anyone who would like to take a look, I've put the re-engineered source code [insomnia.org] up.

Re:Commander Keen

[Cheesey (70139)]

Carmack's code is always interesting. Most famously, there's the infamous square root approximation from Quake [codemaestro.com]. But I'm still impressed by the original Doom render loop, with it's self-modifying code.

The loop is drawing columns (vertical slivers of wall). It needs to interpolate between two things: the input wall texture, and the output part of the screen. Carmack uses something like Bresenham's line drawing algorithm to do this, but because the 386 has such a limited register set, he stores the fractional increment in an immediate attached to the "addl" instruction:

doubleloop:
    movl ecx,ebp // begin calculating third pixel
patch1:
    addl ebp,12345678h // advance frac pointer
    movb [edi],al // write first pixel
    shrl ecx,25 // finish calculation for third pixel
    movl edx,ebp // begin calculating fourth pixel
patch2:
    addl ebp,12345678h // advance frac pointer
    movl [edi+SCREENWIDTH],bl // write second pixel
    shrl edx,25 // finish calculation for fourth pixel
    movb al,[esi+ecx] // get third pixel
    addl edi,SCREENWIDTH*2 // advance to third pixel destination
    movb bl,[esi+edx] // get fourth pixel
    decl [loopcount] // done with loop?
    movb al,[eax] // color translate third pixel
    movb bl,[ebx] // color translate fourth pixel
    jnz doubleloop

and elsewhere... :)

movl ebx,[_dc_iscale]
    shll ebx,9
    movl eax,OFFSET patch1+2 // convice tasm to modify code...
    movl [eax],ebx

A similarly impressive trick is used to draw floors, where 3D interpolation is required because each texture needs to be crossed diagonally, not vertically. I never understood how Doom drew floors until I looked at the code, and I still think it's deep magic. And that's without even mentioning the BSP code!

How to build a CPU -- transistor level up!

[compumike (454538)]

Take a look at this set of videos from MIT's 6.004 Computation Structures [mit.edu] class. They basically walk through the design of a simple 32-bit CPU from transistors, to gates, to functional blocks, to a full processor.

Anyway, reading about how hard it was to recreate the source code from the 4004 makes me wonder how easily we could find source code for some apps from even a decade ago. Lots of companies have gone bankrupt / discontinued products / been sold / etc, and we all know that lots of people aren't good about backing up their code. It's neat to go to the Linux Kernel Archives and look at the Historic Linux sources [kernel.org].

--
Educational microcontroller kits for the digital generation. [nerdkits.com]

Amazing!

[Reality Master 101 (179095)]

'He is an amazing reverse-engineer,' recounts team leader Tim McNerney, 'We understood the disassembled calculator code well enough to simulate it, but Lajos really turned it into "source code" of the highest standards.'

No disrespect to Lajos, but have we really fallen so far in programming standards that it's considered "amazing" to disassemble a 1024 byte program? Back in my day (and stay the hell off my lawn!) we used to disassemble programs all the time. I reverse engineered the operating system for a computer I developed for because we wanted to hook into places that weren't accessible.

Disassembly is apparently a lost art in these decadent days of some programmers never using anything but scripting languages (e.g., Java, Python, Perl) and having no clue what goes on under the hood.

Re:Amazing!

[dmonahan (957638)]

Sometime in the early 70s, a Honeywell division, one of our steady clients, called with a strange request. They had built a small number of special machines for the Navy. Now the Navy wanted more. Honeywell had the circuit drawings and the bootable tape (which they got from the Navy). They had no documentation (not even the instruction set). They asked us to rebuild the code. We did. Dick.

Re:Amazing!

[be-fan (61476)]

"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Susman

From a theoretical point of view, assembly knowledge isn't particularly useful because it doesn't lend itself to rigorous analysis (the "science" part of "computer science"). From a practical point of view, since very few programs are written in assembly language anymore, knowledge of it has limited utility. Further, from a practical point of view, I'd much rather deal with a programmer who can explain his work in terms of data structures and algorithms than one that is stuck thinking in terms of registers and memory locations.

There is certainly a place for assembly knowledge*. It's just a niche, and not a particularly important one anymore. Meanwhile, there are lots and lots of diverse applications for the theory they teach you in those classes instead of assembly. In my own work, I've had to bust out the graph theory way more often than I've had to bust out my knowledge of asm tricks for fast line-rendering...

*) Interestingly enough, one of those places is inside the language runtimes of high-level languages. There are usually lots of neat tricks inside those things (eg: using the NaN space of double-precision floats to store unions of floats and 51-bit integers without extra variant tags!)

Where's the update?

[lseltzer (311306)]

I found a buffer overflow. Exploit code to follow...

Re:

[jfengel (409917)]

The original lacked a gui.

And scientific functions.

And the ability to convert hex.

And store/recall.

The original had 4 functions. This one has at least 40. Would you rather the MS guys spend time seeing if they can force their 114k application down into 10k, or perhaps writing an operating system that doesn't suck?

Re:Only 1024?

[DragonWriter (970822)]

Would you rather the MS guys spend time seeing if they can force their 114k application down into 10k, or perhaps writing an operating system that doesn't suck?

It'd be an improvement if MS did either.

Re:

[geekoid (135745)]

I'm pretty sure it had a GUI. I'f I were to guess, I'd say it was buttons...possibly with numbers on them.

Re:

[ppc_digger (961188)]

They put all the actual code in a shared library:

# ldd /usr/bin/kcalc
libkdeinit_kcalc.so => /usr/lib/libkdeinit_kcalc.so (0x00002b1351db8000)
...

# ls -lh /usr/lib/libkdeinit_kcalc.so
-rw-r--r-- 1 root root 436K 2007-07-03 19:15 /usr/lib/libkdeinit_kcalc.so

Re:Only 1024?

[TDRighteo (712858)]

Floating-point math doesn't fix itself. Let's not be hard on Microsoft when:

Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 10.1-10-0.1
-3.6082248300317588e-16

and...

$ perl
printf("%s\n", 10.1-10-0.1);
-3.60822483003176e-16

and...

$ php
<?php
echo (10.1-10-0.1);
?>
-3.6082248300318E-16

Note that the answers vary across languages too...

Re:

[Cassius Corodes (1084513)]

That is the correct answer - all modern calculators are descended from a competitor's model which incorrectly calculated 9+9 to be 18.

Re:

[by Anonymous Coward]

Did it, but the ATI drivers still sucked.

Re:Something is wrong......

[bpharri2 (173681)]

Of course if you had bothered to read the article, you'd know that it doesn't work like todays calculators but like the old adding machines:

"The electronic calculators that accountants used 35 years ago worked differently than the familiar four-function calculator we use today. These were designed to behave much like mechanical adding machines of the 1960's. After every number you want to add to the total, you need to press +, so = doesn't work like you'd expect. Here are some examples:

To add three numbers: 61 + 79 + 83 + = (if you forget the last +, the 83 won't get added)
To subtract two numbers: 2007 + 1971 - =
To multiply two numbers: 125 x 5 = (this is more like we're used to)
To divide two numbers: 625 / 5 = "