This page last updated Aug 27 2013. (c) Herb Johnson. Here's a HTML text file of email discussions between Kyle Owen and myself, where he describes his activities to restore the 4/40 to operation. More information is on another Web page about Kyle's work and mine on our 4/40 systems. - edited by Herb Johnson
Aug 13 2013, Kyle Owen:
[Herb] I hope you're doing well. I've been experimenting more with my Intellec 4/40 these days. Here's a summary of my discoveries:
1. The (4) 1702As for the monitor program cannot be downloaded from the front panel. The architecture of the 4040, along with the way it's wired, prevents you from accessing those particular ROMs where they currently reside. The only thing you can do is watch (from single-stepping or simply running) the monitor from the front panel, which means any jump prevents you from seeing the code directly after a jump (or a skip), as well as the last byte for two-byte instructions.
2. My teletype interface works, or at least the punch side does. I've written a short assembly program to configure the output port to be RAM 0 on the main board, and toggle it over and over as quickly as possible. Sure enough, I see a wonderful looking square wave on both pin 10 of the 37-pin D-sub connector, top-right from the backside, as well as from pins 1/2 on the Jones connector for the teletype interface (short those two together to see a proper square wave; that's the current loop).
3. My first 1702A (labeled MON 4 000 V2.1) shows up as all zeros, or in other words, a whole bunch of NOPs. I have removed them (very carefully) from the board and were able to dump the contents to four Intel HEX files. Removing those four ROMs was a very easy operation; the TI sockets they used don't grip the pins too tightly, and putting them back in was also as easy. Not so with all sockets, but these were fine.
4. With my monitor being corrupt, I can't do a whole lot more with my machine as it stands. Next step is to start disassembling what I have and see if I can make sense of it.
So all in all, it's been an exciting venture. I was finally able to track down some proper replacement LEDs from a good friend of mine, so I replaced the three that were dead. I hope yours doesn't have this problem.
How interested would you be in dumping the contents of MON 4 000 on your CPU board? That will greatly help me in my quest to better understand the monitor. Another nice note about the 4004/4040 is that there's only one restart vector, so there's only one possible starting location for the monitor: 000. That makes the first chip pretty important, not to mention there's only 2kB to begin with.
Please find attached two handy test programs (both with a starting address of 000) and my four HEX dumps.
Hope this helps, and looking forward to hearing from you. - Kyle
Herb asks: 1) Were all the ROMS covered with lables to keep light out? What exactly is the brand and model and date for your four ROMS?
No they weren't. What bugs me though, is I'm reading back the inverted data of what my Intellec shows on a Prolog 980. I'll check my schematics (and check the Prolog settings), but I would've expected to read back the same way, both ways. But again, I can't read back *all* of the data with the Intellec; only the operators that are to be executed via single-stepping. The ROMs are 1702As from Intel, seen here: http://i.imgur.com/EQsd4.jpg Looks like 1974 to me.
Thus, I may have a bad 1702A, or it has been erased at some point. I can't think of why else it's being read back as all FFs. I may remove it again and compare it to another device and see if it's consuming the same amount of power as a known good one. Either way, though, I'm not about to decap the chip and do on-die maintenance. I've done enough of that for the summer, thank you!
Herb: 2) Since you are writing 4040 code and I'm not, will you be hand-disassembling your monitor ROMS? Otherwise I'd have to grab teh 4040 book and do it myself. It's not an awful lot of work to do by hand, it's only 128 X 3 bytes, right? Also a good way to see if you have bit dropouts.
Kyle: I can disassemble by hand, but I think someone has already written a 4004 disassembler. There's only a handful more instructions provided by the 4040, and otherwise are machine-code compatible. The Busicom 141-PF was reverse-engineered and disassembled, so I presume someone has already written one. If not, it's only 2kB (or for mine thus far, 1.5kB).
Herb: 3) I'ver never powered my 4040 system. I will look at the physical 4040 cards I have sometime this week. What I'd have to do is pull the card, pull the ROMS, put each on my Prolog brand 1702 programmer, and hand-list the op codes. That's the simplest method as the interface is current loop. It's not that much work. Let's see what my site shows about my 4040:
kyle:Do you have to hand list the opcodes? I was able to dump the contents directly to Intel HEX, as you saw. I did this over the RS-232 adapter on the 980. That way, it's a lot less work on your part. Or, if you're feeling old-school like I am most of the time, fire up the 'ole ASR-33 and send me the printout! :) Just kidding, of course. I think it'd be a lot easier to disassemble everything once all four ROMs are dumped. I'll gladly do it once I have the complete HEX files.
4) Have you established a Web site for your 4040 system, and for that matter your 8/e? You suggested you might, last year. Up to you, but if you don't I'm inclined to make a Web page on my site from your notes and dialog with me. This is sort of a thing I do. But I really encourage restorers and owners to "get their work on the Web". It encourages dialog and other owners to get to work!
Gah, no I haven't...I really, really need to. [Lists a number of projects.] All of this should be shared with others, in some easy-to-use format, like a website. But I just haven't had a chance to sit down and work with Wordpress enough to get something going. Eventually, I swear I will.
[discussion about ROMs containing inverted data]
Herb:[Inverted ROM data is] not unusual in really early systems. If the ROM dump op codes don't make sense in disassembly, invert them. If they make sense then - that's just how it is. YOu can look at data sheets and old old systems to see how this happens. I don't have time immediately to say more than this.
Just checking: is this image of YOUR board? There's no covers on ANY of these ROMS. Kyle, I'm accumulating evidence of how long PROMS hold data under what conditions. Nobody in 1974 expected to read these FOUR DECADES later. Casual evidence suggests a ROM can be erased in on the order of a year of room lighting; a week of bright sunlight outside. Of course, depends on the ROM, room and decade.
Kyle:Yes, it's my board. It never had labels covering the quartz from the looks of it. Even the manuals stated that this wasn't necessary. Guess after some more research, folks finally figured out that it is needed. Yes, I understand [about erasure with time.] I seem to recall most modern EPROMs emitting FFs in an erased state, but I checked the datasheet for the 1702A: it is in fact 00s. Thus, I'd say inverting the output from the Prolog is necessary.
[disassembly discussion]
Kyle:I can disassemble by hand, but I think someone has already written a 4004 disassembler. There's only a handful more instructions provided by the 4040, and otherwise are machine-code compatible. The Busicom 141-PF was reverse-engineered and disassembled, so I presume someone has already written one. If not, it's only 2kB (or for mine thus far, 1.5kB).
Herb: It would probably take me 90 minutes maybe less [to hand disassemble the op codes for the three PROMs]. It would take me longer to find and use that disassembler, I'd bet. Plus I'd not learn the 4040 op codes. But... more power to you to invert all that data into new hex records and feed it into a disassembler and edit the resulting file.
KyleWell, yes. It shouldn't take too long to do it by hand. I just figured a disassembler would put it in a format which the assembler will recognize right away for when I go to reassemble it. But I have the "cheat sheet" booklet for the 4004/4040 instruction set, so that's good for me.
I have a few ideas [about recovering the "empty" PROM 0]. If your ROMs are labeled MON 4 v. 2.1, the first ROM has non-zero data on it, and the other three ROMs match mine, I'd think we'd be in good shape. That is, if you're willing to dump all the ROMs while you're at it. I'll get to hand disassembling mine today, likely.
[Herb, Aug 15-16: I dumped the first two 1702A ROMs in my system, and updated my 4/40 Web pages with Kyle's ROM dumps and mine.] Kyle comments:
Kyle: I went ahead and burned your dump of ROM 0, and to my surprise, the computer is actually doing some different stuff! The lights are blinking every second or so, until you connect the teletype keyboard input loop together; then the lights flicker a lot. I think things are definitely looking brighter!
I have an idea: if you can dump the rest of your ROMs, I can AND them all together to get the best possible case of what the ROMs would've been initially, without partial erasures. If we are reading erased chips as FFs, then 00 is fully programmed. Thus, if all of our chips are the same revision (let's hope they are!), then we can simply AND the sets together to get as much of the original code as possible.
Herb: I can "AND" by eyeball and see already some differences. I'll have the ROMs dumped later today.
I suggest not a simple "AND", but a disassembly and then a "merge". I suspect my remaining ROMS are patched versions of our mutual V2.1 code set. This is not rocket science, to at least disassemble the code and see where differences lie. Also - if I have a transscription error, or if either of us have bit errors, the code will "look funny". that's informal, but I think this method will do.
NOtes by Herb:
I eventually read and dumped all four ROMS of mine, and corrected some hand-transcription errors in the ROM 0 that Kyle used. He was able to run his 4040 system accordingly. See the Web page about our 4/40 ROM dumps for details.- Herb
Copyright © 2013 Herb Johnson