At some point, I think I will upload a YouTube video about this.  This is weird!  Either Ed Roberts was a truly mad genius, and he invented something that even he didn't know about, or else, in some other form or fashion there is something else really weird, and perhaps undocumented about just this particular Altair's front panel, which is acting like another one of those not quite yet discovered but begging to be appreciated and therefore also "undocumented feature" lurking in the Altair series all these years, that, as stated nobody seems to have discovered - as of yet, or at least until now.  Or it is really just something balky about the front panel on this particular machine that nonetheless begs to be understood, and of course, hacked, and therefore - exploited!

Let me explain further.  I bought this particular machine off of eBay something like twenty years ago, or thereabouts, knowing that the seller was selling it, AS-IS, even after disclosing, that it "powers up", but address LED A10 never comes on, neither does data LED D2, and it may have been otherwise impossible to test because although RUN-STOP seemed to work, Examine did nothing and so on.  

I found that the problem was a defective IDC connector on the Interface board that was refusing to make consistent contact with the ribbon cable.  So I had to replace the IDC connectors and the ribbon cable with a new set of IDC connectors (which were a bear to remove and replace) and a "new" set of ribbon cables made from a set of standard 34-pin floppy connectors.   So far so good.  Everything seems to work so far, except for LED D2, which MIGHT actually be a problem with the front panel, like maybe a bad 7404 or perhaps an actual bad LED.  I don't know yet.  But I just discovered something that seems hauntingly familiar, on the one hand, based on what I think I remember about these machines from back in my college days if you know what I mean - but then again? Well - suffice it to say that I would have never guessed what was about to happen - that is besides the half a dozen other things that have gone wrong in the last couple of weeks, that I will discuss later - like the fried bridge rectifier, the shorted capacitors on the video board, and so on.  Yet that's not the really interesting part.

O..K, then, this is where things just got really weird.  I started working on an Interrupt driven set of I/O routines since I have not only the REV 0, dual serial board, but also a genuine Vectored Interrupt board, and something that might be fun to try would be writing a simple MIDI sequencer, where I could perhaps burn a MIDI file of something like Beethoven'f fifth symphony to an EPROM and then set the RTC to fire off interrupts every 1000 microseconds, or so so that it can pump out MIDI messages over one of the serial ports, which I could then hook up to any actual MIDI instrument.  That should seem simple enough to implement, right?  Just wait for an interrupt to fire, increment a counter, and then compare the "tick count" against the MIDI time associated with the next event in the "file" that I might have to read from EPROM since I don't have an Altair floppy.

Well then, so I started toggling in some hand-crafted machine language, just to test things, on the one hand, and for proof of concept on the other - and then things got weird as I said, and which I will explain further, soon enough.

So I toggle in something like this, and I never expected to see what happened next!

; data values in OCTAL

0000:  333 377          IN 377        ;  read sense switches
0002:  323 377          OUT 377       ;  display on data LEDs
0004:  303 000 000      JUMP 000 000  ;  loop forever
0007:  166              HALT

 Now, when this is toggled in just like what you see here, it works simply enough.  The 8080 goes into an infinite loop reading the "sense" switches, A8-A15, and updating the data LEDs with whatever is toggled in at the time.  Simple enough, that is until I try running it without the JMP 000 000 statement, i.e., so that it should simply read the sense switches from A8-A15, and then after displaying the data on the data LEDs. it should HALT, which it does, which is fine - except for one thing.  Oh, it halts just fine, but then something strange happens, and no it does not catch fire.  No, it not only HALTS, but it completely locks up.  RESET stops working.  RUN-STOP doesn't work either.  The whole front panel just simply locks up and the only way to actually reset the machine is to power off and then turn it back on.  And that was not something that I was expecting!  Wow!  

But it gets weirder.  If I use the "single step" or "slow" execution feature, it works exactly the way that I thought it would work, and that is that when it hits the HALT instruction, that HALT LED comes on, the data LED's continue to display the DATA that was written to them by the last OUT 377 instruction, and then I can use the RESET switch to reset the address bus back to zero, and then run it again.

Oh, and LED D2 is still not working.

Here, of course, is an example of how I loaded some quick machine code that reads some bits from sense switches and then outputs them to the data LED's before halting.  To reproduce this, that is if your Altair has this "bug", you just enter the version that halts and then Examine 0x0000 to get to the starting address, but then before you run it, of course, you are going to want to toggle in some "data" on lines A8-A15, and THEN and only then, WITHOUT pressing Examine again, you can run it - in order to verify that it correctly outputs the "data" to the front panel, and then it apparently HALTS, as it should - which in turn causes all of the address LED'S to light up, even though it continues to display the data that was previously output to "port 255", along with the HALT LED, which also lights up.  All very interesting - except as noted - now RESET doesn't seem to be working - even though it does work if I use the "single step" or "slow mode".  Of course, I haven't tried this yet on an Atmega 2560, but I suppose that I could, and most obviously probably should.

This, of course, gives me an idea, because right now I don't know if all Altairs had this issue, or if there is something weird about this particular machine that I need to try to understand while on the one hand, this could completely screw up my interrupt-driven MIDI driver, as least as far as writing it the way that I want to write it goes, even though I am sure that I can get it working, one way or another, and that is because what I want to do is use interrupts the way that they are meant to be used, i.e., I want to have the RTC board fire off periodic interrupts, and then have some kind of scheduler check to if it is time yet for the next MIDI event, and increment some counters, and so on, and do whatever work needs to be done for that time slice, and the have the machine HALT, like the way that the 8080 was originally designed to do, that is until it gets awoken by the next IO event or time slice.  Because, that is cool, elegant and awesome, and beautiful, and anything else would be ugly, feckless, and disgusting.

Have I made my point?

O.K., then.

Yet, what if this particular machine has a bug, and yet what if is not a bug, it might just be an undocumented feature. You see, while I don't particularly like the prospect of having the whole machine freeze up, so that there is nothing that can be done except to power cycle it, and try again, I can see how such a feature might be useful because there is an amazing hack lurking in here somewhere, underappreciated, and begging to be understood.

And why is that?  Well, imagine using an 8080 or a Z80 to do something like controlling a furnace for example, and then maybe there could be a carbon monoxide sensor or an exhaust gas manifold temperature alarm or something, that might not only fire off an alarm condition, but also let's say by illuminating some status LEDs, but then maybe, for obvious reasons the whole thing needs to be shut down, and there IS NO RESET button, except that there is, but it has been "disabled", and "run-stop" has been locked out also, for obvious reasons.  This is HUGE because it seems to imply a method for forcing a physical machine into some kind of safe mode, on the one hand, and where you still get diagnostic data on the other hand, and yet there would be no simple "easy bypass" or override.  For obvious reasons.

Got it?

Oh, but it gets better.  Because for reasons that I still don't understand, I CAN run this machine the way that I always thought that it is supposed to work by single stepping or using "slow" mode.  This makes me wonder if there is a way to "speed up the slow mode" to something like 10000 instructions per second, which would allow for debugging of embedded applications, on the one hand, without having to power cycle during testing - also for obvious reasons.

To be continued . . .