On May 27, 11:10 am, VAXman- @SendSpamHere.ORG wrote:
> I'm trying to boot an old AlphaStation. The console initialization
> countdown stops at F4. The LEDs on the rear apron of the AS200 also
> mirror this code [**** o*oo] F4. I've googled and haven't found any
> definitive answer on this code. One document said "reserved to DEC"
> which is not very informative.
>
> Any pointers, help, etc. greatly appreciated.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
>
> "Well my son, life is like a beanstalk, isn't it?"
>
> http://tmesis.com/drat.html

The service doc I have shows the same; 'reserved for future use' but I
did find the following snippet: "When power is applied to the system,
the diagnostic LEDs start decrementing as tests complete successfully
If a test fails, the display does not change. Therefore, when a
failure occurs , the LED code is pointing to the test which last
passed."

That means its test F3 that failed; the service guide says "Load the
DROM code into memory.". F2 apparently continues that, and F1 should
be "Successful load and checksum of DROM".

The popup says that in the event the DROM load fails, SROM will
attempt to load the selected firmware (ARC or SRM), and failing that
will drop into a "mini console" that is apparently available to
manufacturing. Is that the serial port on the MLB in the back? The
docs do not say.

There's also this note: "Check J3: If "normal", then HW_REI to PAL.
If J3 is set to S-Port, go to the SROM mini-console."

That does happen after the test that failed but perhaps the J3 jumper
setting may be worth checking to see if you can get access to further
diagnostics.

I wonder if you have had a firmware corruption. Perhaps even to the
point that you need to use a failsafe boot...

VAXman- @SendSpamHere.ORG wrote:
> I'm trying to boot an old AlphaStation. The console initialization
> countdown stops at F4. The LEDs on the rear apron of the AS200 also
> mirror this code [**** o*oo] F4. I've googled and haven't found any
> definitive answer on this code. One document said "reserved to DEC"
> which is not very informative.
>
> Any pointers, help, etc. greatly appreciated.
>

Other than finding a copy of the service manual, or finding the "secret
decoder ring", I think you're out of luck. Even if you knew what it
meant it might not be economically repairable.

On May 27, 6:22 pm, Rich Jordan wrote:
> On May 27, 11:10 am, VAXman- @SendSpamHere.ORG wrote:
>
> > I'm trying to boot an old AlphaStation. The console initialization
> > countdown stops at F4. The LEDs on the rear apron of the AS200 also
> > mirror this code [**** o*oo] F4. I've googled and haven't found any
> > definitive answer on this code. One document said "reserved to DEC"
> > which is not very informative.
>
> > Any pointers, help, etc. greatly appreciated.
>
> > --
> > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
>
> > "Well my son, life is like a beanstalk, isn't it?"
>
> >http://tmesis.com/drat.html
>
> The service doc I have shows the same; 'reserved for future use' but I
> did find the following snippet: "When power is applied to the system,
> the diagnostic LEDs start decrementing as tests complete successfully
> If a test fails, the display does not change. Therefore, when a
> failure occurs , the LED code is pointing to the test which last
> passed."
>
> That means its test F3 that failed; the service guide says "Load the
> DROM code into memory.". F2 apparently continues that, and F1 should
> be "Successful load and checksum of DROM".
>
> The popup says that in the event the DROM load fails, SROM will
> attempt to load the selected firmware (ARC or SRM), and failing that
> will drop into a "mini console" that is apparently available to
> manufacturing. Is that the serial port on the MLB in the back? The
> docs do not say.
>
> There's also this note: "Check J3: If "normal", then HW_REI to PAL.
> If J3 is set to S-Port, go to the SROM mini-console."
>
> That does happen after the test that failed but perhaps the J3 jumper
> setting may be worth checking to see if you can get access to further
> diagnostics.
>
> I wonder if you have had a firmware corruption. Perhaps even to the
> point that you need to use a failsafe boot...

and if by magic on Hoffman Labs
AlphaStation 200 Firmware Failsafe Loader
http://64.223.189.234/node/871

Rich Jordan wrote:
> On May 27, 11:10 am, VAXman- @SendSpamHere.ORG wrote:
>> I'm trying to boot an old AlphaStation. The console initialization
>> countdown stops at F4. The LEDs on the rear apron of the AS200 also
>> mirror this code [**** o*oo] F4. I've googled and haven't found any
>> definitive answer on this code. One document said "reserved to DEC"
>> which is not very informative.
>>
>> Any pointers, help, etc. greatly appreciated.
>>
>> --
>> VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
>>
>> "Well my son, life is like a beanstalk, isn't it?"
>>
>> http://tmesis.com/drat.html
>
> The service doc I have shows the same; 'reserved for future use' but I
> did find the following snippet: "When power is applied to the system,
> the diagnostic LEDs start decrementing as tests complete successfully
> If a test fails, the display does not change. Therefore, when a
> failure occurs , the LED code is pointing to the test which last
> passed."
>
> That means its test F3 that failed; the service guide says "Load the
> DROM code into memory.". F2 apparently continues that, and F1 should
> be "Successful load and checksum of DROM".
>
> The popup says that in the event the DROM load fails, SROM will
> attempt to load the selected firmware (ARC or SRM), and failing that
> will drop into a "mini console" that is apparently available to
> manufacturing. Is that the serial port on the MLB in the back? The
> docs do not say.
>
> There's also this note: "Check J3: If "normal", then HW_REI to PAL.
> If J3 is set to S-Port, go to the SROM mini-console."
>
> That does happen after the test that failed but perhaps the J3 jumper
> setting may be worth checking to see if you can get access to further
> diagnostics.
>
> I wonder if you have had a firmware corruption. Perhaps even to the
> point that you need to use a failsafe boot...

I agree. Try to reload the firmware first with the failsafe option.

In article <483c325b$0$15183$607ed4bc@cv.net>, VAXman- @SendSpamHere.ORG writes:
>I'm trying to boot an old AlphaStation. The console initialization
>countdown stops at F4. The LEDs on the rear apron of the AS200 also
>mirror this code [**** o*oo] F4. I've googled and haven't found any
>definitive answer on this code. One document said "reserved to DEC"
>which is not very informative.
>
>Any pointers, help, etc. greatly appreciated.

Thanks for the replies here and the private emails. Strangely, I have this
machine working again. Don't ask how, I don't rightly know myself.

On one of the teardowns, reconfigs and restarts, I did NOT connect the key-
board up. The machine booted (configured with console=serial). I am not
sure what went wrong here but after checking that the connections were all
tight (this particular machine has a DECwand augmenting the keyboard), the
keyboard was reconnected and the firmware test countdown continued past F4.
It may have been something with the DECwand causing the countdown to hold.

This machine was completely torn apart in this effort. It's now clean like
a brand new machine. It also has a new power supply. It's been in use for
13 years. I wonder if it can run 13 more!

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

"Well my son, life is like a beanstalk, isn't it?"

http://tmesis.com/drat.html

In article
<8c6029fb-e87a-48c3-ba26-71042bc20077@r66g2000hsg.googlegroups.com>,
Rich Jordan wrote:

> On May 27, 11:10 am, VAXman- @SendSpamHere.ORG wrote:
> > I'm trying to boot an old AlphaStation. The console initialization
> > countdown stops at F4. The LEDs on the rear apron of the AS200 also
> > mirror this code [**** o*oo] F4. I've googled and haven't found any
> > definitive answer on this code. One document said "reserved to DEC"
> > which is not very informative.
> >
> > Any pointers, help, etc. greatly appreciated.
> >
> > --
> > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
> >
> > "Well my son, life is like a beanstalk, isn't it?"
> >
> > http://tmesis.com/drat.html
>
> The service doc I have shows the same; 'reserved for future use' but I
> did find the following snippet: "When power is applied to the system,
> the diagnostic LEDs start decrementing as tests complete successfully
> If a test fails, the display does not change. Therefore, when a
> failure occurs , the LED code is pointing to the test which last
> passed."
>
> That means its test F3 that failed; the service guide says "Load the
> DROM code into memory.". F2 apparently continues that, and F1 should
> be "Successful load and checksum of DROM".
>
> The popup says that in the event the DROM load fails, SROM will
> attempt to load the selected firmware (ARC or SRM), and failing that
> will drop into a "mini console" that is apparently available to
> manufacturing. Is that the serial port on the MLB in the back? The
> docs do not say.

The mini-console is a feature built into the SROM firmware of most
(all?) alpha systems. Sometimes the mini-console is only available if
you move a jumper to a different position to load alternate SROM code.

On power-up or reset, Alpha CPUs load the SROM (Serial ROM) code, 1 bit
at a time, using 2 dedicated pins (clock + data) on the CPU chip. The
code loads directly into the CPU's instruction cache. The the CPU
starts executing instructions from the cache.

This code normally finds the SRM firmware in ROM, decompresses it,
copies it to RAM, and transfers control. If something goes wrong,
NOTHING is available except those 8 KB of instructions in the cache. No
memory, no I/O devices, no SRM firmware -- nothing.

The alpha designers added a debug tool for this contingency -- the SROM
mini-console. The two pins that load the SROM code at power-up are
reused to make a 2-pin serial interface directly into the CPU. The pins
are usually connected to a header somewhere on the motherboard or CPU
board. They aren't routed to a real connector on the back of the
machine. The voltage is nonstandard, but if you have the right
connector and circuit, you can connect a terminal. The serial port runs
at 9600 baud, with timing via delay loops in the code. You end up with
a little command-line debugger, dumber than XDELTA, that lets you
examine and deposit memory. With that, you can load any diagnostics you
need into main memory and transfer control to something smarter.

Some versions of the mini-console were documented in the manuals that
came with the old-time Alpha developer boards.

>
> There's also this note: "Check J3: If "normal", then HW_REI to PAL.
> If J3 is set to S-Port, go to the SROM mini-console."
>
> That does happen after the test that failed but perhaps the J3 jumper
> setting may be worth checking to see if you can get access to further
> diagnostics.
>
> I wonder if you have had a firmware corruption. Perhaps even to the
> point that you need to use a failsafe boot...

In article , Robert Deininger writes:
>In article
><8c6029fb-e87a-48c3-ba26-71042bc20077@r66g2000hsg.googlegroups.com>,
> Rich Jordan wrote:
>
>> On May 27, 11:10 am, VAXman- @SendSpamHere.ORG wrote:
>> > I'm trying to boot an old AlphaStation. The console initialization
>> > countdown stops at F4. The LEDs on the rear apron of the AS200 also
>> > mirror this code [**** o*oo] F4. I've googled and haven't found any
>> > definitive answer on this code. One document said "reserved to DEC"
>> > which is not very informative.
>> >
>> > Any pointers, help, etc. greatly appreciated.
>> >
>> > --
>> > VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
>> >
>> > "Well my son, life is like a beanstalk, isn't it?"
>> >
>> > http://tmesis.com/drat.html
>>
>> The service doc I have shows the same; 'reserved for future use' but I
>> did find the following snippet: "When power is applied to the system,
>> the diagnostic LEDs start decrementing as tests complete successfully
>> If a test fails, the display does not change. Therefore, when a
>> failure occurs , the LED code is pointing to the test which last
>> passed."
>>
>> That means its test F3 that failed; the service guide says "Load the
>> DROM code into memory.". F2 apparently continues that, and F1 should
>> be "Successful load and checksum of DROM".
>>
>> The popup says that in the event the DROM load fails, SROM will
>> attempt to load the selected firmware (ARC or SRM), and failing that
>> will drop into a "mini console" that is apparently available to
>> manufacturing. Is that the serial port on the MLB in the back? The
>> docs do not say.
>
>The mini-console is a feature built into the SROM firmware of most
>(all?) alpha systems. Sometimes the mini-console is only available if
>you move a jumper to a different position to load alternate SROM code.
>
>On power-up or reset, Alpha CPUs load the SROM (Serial ROM) code, 1 bit
>at a time, using 2 dedicated pins (clock + data) on the CPU chip. The
>code loads directly into the CPU's instruction cache. The the CPU
>starts executing instructions from the cache.
>
>This code normally finds the SRM firmware in ROM, decompresses it,
>copies it to RAM, and transfers control. If something goes wrong,
>NOTHING is available except those 8 KB of instructions in the cache. No
>memory, no I/O devices, no SRM firmware -- nothing.
>
>The alpha designers added a debug tool for this contingency -- the SROM
>mini-console. The two pins that load the SROM code at power-up are
>reused to make a 2-pin serial interface directly into the CPU. The pins
>are usually connected to a header somewhere on the motherboard or CPU
>board. They aren't routed to a real connector on the back of the
>machine. The voltage is nonstandard, but if you have the right
>connector and circuit, you can connect a terminal. The serial port runs
>at 9600 baud, with timing via delay loops in the code. You end up with
>a little command-line debugger, dumber than XDELTA, that lets you
>examine and deposit memory. With that, you can load any diagnostics you
>need into main memory and transfer control to something smarter.
>
>Some versions of the mini-console were documented in the manuals that
>came with the old-time Alpha developer boards.
>
>>
>> There's also this note: "Check J3: If "normal", then HW_REI to PAL.
>> If J3 is set to S-Port, go to the SROM mini-console."
>>
>> That does happen after the test that failed but perhaps the J3 jumper
>> setting may be worth checking to see if you can get access to further
>> diagnostics.
>>
>> I wonder if you have had a firmware corruption. Perhaps even to the
>> point that you need to use a failsafe boot...

Thanks Robert,

I have the AlphaStation 200 up and running... in fact, I now have two up
and running. I cannibalized an old 100MHz AS200 that I'd acquired along
the way for the power supply to replace the P/S in the unit I first had
this issue with thinking that maybe the P/S was bad. It turned out that
it wasn't the AS200 at all but the DECwand that was augmenting the key-
board input to the AS200. I'll miss it as it came in handy for testing
postscript forms I make with barcodes. I discovered this when I powered
up the AS200 during one cycle with the keyboard and mouse removed.

The other AS200 was out of commission becasue the fan in the P/S gave up
the ghost. I cannibalized the fan from the P/S I removed from the first
AS200 to get that unit working.

I put new CR2032 cells in place whilst these units were open. Both had
a mfg date in early 1995. I thought it was a good idea, after 13 years
of service, to replace the batteries.

The suggestions to reflash the unit were appreciated but, since the unit
never made it to the 'dead sarg', there was little hope of that. There
is also no need now since both units are functioning with the contents of
their flash still in tact.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

"Well my son, life is like a beanstalk, isn't it?"

http://tmesis.com/drat.html