Slashdot Mirror


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.'"

14 of 159 comments (clear)

  1. Those were fun by certsoft · · Score: 4, Interesting

    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.

  2. And best of all by Dusty · · Score: 4, Funny

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

  3. slashdot headline, 2057: by circletimessquare · · Score: 4, Funny

    "Historians Recreate Source Code of First 404 Error Message"

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

    --
    intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
  4. Re:Only 1024? by DragonWriter · · Score: 5, Funny

    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.
  5. Re:I hate to be a pendantic jerk, but... by urcreepyneighbor · · Score: 5, Funny

    Your hand?

    zing!

    --
    "The fight for freedom has only just begun." - Geert Wilders
  6. Quickly -- someone send this to MS by Eberlin · · Score: 4, Funny

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

  7. the output is by geekoid · · Score: 4, Funny

    58008

    --
    The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
  8. Commander Keen by QuantumG · · Score: 5, Interesting

    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 up.

    --
    How we know is more important than what we know.
    1. Re:Commander Keen by Cheesey · · Score: 4, Interesting
      Carmack's code is always interesting. Most famously, there's the infamous square root approximation from Quake. 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!
      --
      >north
      You're an immobile computer, remember?
  9. Amazing! by Reality+Master+101 · · Score: 4, Insightful

    '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.

    --
    Sometimes it's best to just let stupid people be stupid.
    1. Re:Amazing! by dmonahan · · Score: 4, Interesting

      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.

  10. Where's the update? by lseltzer · · Score: 5, Funny

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

  11. Re:Something is wrong...... by bpharri2 · · Score: 4, Informative

    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 = "

  12. Re:Only 1024? by TDRighteo · · Score: 5, Interesting
    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...