front panel display for a modern PC

[Vincent Slyngstad]

From: "Roy J. Tellason":
> On Sunday 02 March 2008 00:44, Vincent Slyngstad wrote:
>> I think of blinkenlights as way ahead of a ROM with a debugger in it,
>> and not for just the aesthetic reasons folks are talking about.  It's
>> a little like Tony's fondness for "things he can understand".  When I
>> use a front panel, there's no question what's going on in the hardware
>> or what's in the register.  The front panel is such a simple device
>> there is no way for it to lie to me.  No way is it going to miss my
>> breakpoint and wander into the weeds, etc.  I'm not acting through
>> an intermediary -- I really am in control of the machine, and I'm
>> seeing the real machine state.
> 
> I think that's a pretty good point,  there.

Thanks :-).

>> Later, this got stretched a bit.  The actual workings of an IMSAI
>> front panel leave some potential for strange things to happen, as
>> what going on there is a little like a debugger activated by switches.
>> At least you can really stop the machine, etc.
> 
> Which aspects of the IMSAI are you referring to here?  The one I have 
> does not 
> have the original CPU board in it,  and the front panel functions are 
> seriously limited,  as in most of it doesn't do much of anything.

I'm speaking from memory, so I may have the details wrong, but what I 
remember is that the way the front panel works, is that the "Examine" 
key works (for example) is that it forces a "JMP xxxx" onto the CPU 
bus, then returns the CPU to the halted state, ready to fetch the 
new location.  Of course, this only works if the CPU understands an 
8080 JMP instruction, etc.

My understanding is that other front panel functions were implemented 
by this sort of strategic lying to the CPU.  That makes it a different 
beast than the front panels of old :-).

>> I do use debuggers in core, of course, but I percieve that as a
>> trade of ease-of-use vs knowing what's really going on.
> 
> It all depends on what you're trying to do.  Get hardware working 
> at all?  Or something just a bit beyond that...

Generally, I'm assuming working hardware, but want to see how the 
software went wrong.  But whatever software I'm running is interacting 
with the hardware (device drivers or the sort of low level programs 
we wrote back then).

Remember that those old machines didn't have a debugged operating 
system under them, with a virtualization or protection layer to 
catch them when they crashed and save their memory and registers.
Most of the programs ran stand-alone and directly controlled relevant 
hardware resources.

    Vince