Historians Recreate Source Code of First 4004 Application 159
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.'"
How to build a CPU -- transistor level up! (Score:4, Informative)
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]
large function in small code (Score:2, Informative)
Re:Something is wrong...... (Score:4, Informative)
"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 = "
Re:Only 1024? (Score:3, Informative)
Re:Commander Keen (Score:2, Informative)
Now what Carmack wants to do here is to have an extra register to hold a constant so he overwrites the constant in the instruction. Patch1+2 is where the constant is So essentially the code becomes What I'm not sure is why he didn't do addl ebp,[FractionalIncrement]. That would take the FractionalIncrement from a memory location. Then he wouldn't need the self modifying code, he could just write _dc_iscale << 9 there.
On the other hand, maybe the code is memory limited anyway and this will slow it down.
On a recent x86 processor self modifying code will be correct but not too fast. If code is not self modifying it will execute from the instruction cache and writes will be buffered and stored in writeback data cache. Self modifying code screws with this - the write needs to end up in the i cache somehow. And x86 opcodes are converted into a Risc like internal format for execution, and if these are cached you need to flush that cache too. And since they have to do it on old code they have to do all steps automatically with no hints from the programmer.
On an ARM you just need to clean the dcache, flush the write buffer and flush the icache as ARM instructions are a executed directly. And all these are things the programmer has to ask for explicitly using MCR and MRC instructions. Actually ironically the ARM has more registers 13 instead of 6 so you have less need for this and you can encode shift counts for free, so in ARM you could do this