> From: George Neuner <[EMAIL PROTECTED]> > A friend of mine had an early 8080 micros that was programmed > through the front panel using knife switches
When you say "knife switches", do you mean the kind that are shaped like flat paddles? I think that would be the IMSAI, which came after the ALTAIR. Those flat paddle-shaped switched would presumably be much more comfortable on the fingers than the standard metal toggle switches on the ALTAIR. I had an ALTAIR, which made front-panel programming rather painful on the fingers. > ... toggle in the binary address, latch it, toggle in the binary > data, latch it, repeat ad nauseam. For manually loading software in sequential locations, you have to enter the binary address only once. After that, you press the EXAMINE-NEXT toggle to increment the address by one. That reduced the effort by nearly a factor of 3. Instead of toggling a 16-bit address and EXAMINE and 8-bit datum and STORE each time, you toggle just EXAMINE-NEXT and 8-bit datum and STORE for each consecutive memory location after the first. Note the address and data toggles are bistable, stay in whatever position you left them in, whereas the three control toggles (EXAMIME EXAMINE-NEXT STORE) are spring loaded, making momentary contact when you force them then spring back to inactive when you release them. > It had no storage device initially ... to use it you had to input > your program by hand every time you turned it on. Almost but not quite true. With static RAM, most of the data can survive power-downs of hours or even days. I had 28k bytes of static RAM on my ALTAIR, so if I needed to start it up after it had been shut down I'd toggle in the starting address by hand, EXAMINE that, compare what shows with what's on my printed listing, and if it matches just EXAMINE-NEXT to compare the next. In the few cases I saw a bit or two flipped, I'd re-enter that one byte of data. I had to do that only for my BOOT1 loader, which was hand-loaded from front panel and took text input in 3n+1 form from Beehive 3A terminal connected to serial port, maybe also for BOOT2 loader which had been loaded in 3n+1 form and took input in hexadecimal form, and maybe also for BOOT3 loader which had been loaded in hexadecimail form from Beehive and automatically downloaded the next bootstrap loader from modem. If only a few bytes (of BOOT2 or BOOT3) had been damaged by days of power down, comparing binary against listing to verify it's 99% correct, and then manually patching just one or two bytes, would be faster and safer than manually entering 3n+1 or hexadecimal from keyboard. But once BOOT3 was loaded, I always downloaded all the rest of the software from the PDP-10 over the modem. > I did a little bit of programming on it, but I tired of it quickly. Did your friend's machine have two serial ports, one for local terminal and one for modem, and did you have access to a remote PDP-10 or other mainframe for running a cross-assembler? Or did you have some other computer locally available, where you could use that other computer both to store your library of code and to perform automated file transfer from archive on other computer to where it's needed on IMSAI? > As did my friend - once he got the tape storage working (a new > prom) Yeah, I never had the money to buy that, and with the PDP-10 available for both cross-assembling and archiving/downloading, I didn't need it. > Machine coding is not relevant anymore - it's completely > infeasible to input all but the smallest program. That's not totally true. For some educational purposes, like *really* understanding pointers (not the kind in C so much as the kind that are inherent in all pointer-linked data structures such as linked lists and binary search trees etc.), it helps to have some "hands-on" experience writing and executing machine-language code, in a sense actually "seeing" a register first point to the first byte of a CONS cell then by indexing with offset pointing *through* the *second* pointer of that CONS cell to whatever the CDR points to. Then "mission impossible" when your instructor tells you to see if there's a way to reverse that process, whereby you are given the register pointing to whatever the CDR points to, and you are supposed to find the address of the original CONS cell. Instant enlightenment, no lecture/sermon needed! -- http://mail.python.org/mailman/listinfo/python-list
