I've never seen one of these boards before so I can't really comment on how they normally behave and my small Alphas are all in need of repair (bad PSUs). None of mine ever crashed at the VGA BIOS though - if drives or disk controllers or anything like that were missing or not working it would just complain during POST in the ARC/AlphaBIOS firmware. I don't recall startup time being noticeably slow either - no worse than a PC of a similar age.

I guess it might be worthwhile trying a different PCI VGA card. All the Alphas I have seen have a 386 emulator in ROM to let them run option ROMs on standard PC expansion cards so any VGA card of a similar age will probably do. If the DS12887 was working fine last time you were able to boot to Windows NT then I'd try replacing that next. I know some PCs will refuse to work with a dead one, perhaps this Alpha board doesn't like it either.

The DS12887 was dead all the time as I bought the board - no wonder it was ~25 years old. I tried to replace it with DS1287 with OK batt but no change. Without RTC it doesn't boot neither to Debug Monitor (hangs soon at POST code 00).

Please could you take and upload some video of your booting system? If you have ISA/PCI POST card it would be helpful to film POST display during boot too.

What VGA cards are you using? The BIOS emulation is a bit picky, I run my Alphas with Permedia 2 based cards which tend to work with everything (AlphaBIOS, NT and Linux).

ATi cards were also supposed to be supported, sort of. One of my to-do projects is an AXPpci 33 board. I received it with an ATi Mach64 which was supposed to work. Reading up on it, it turns out to be more complex: it does show output in ARC (BIOS emulation) and MILO (Linux loader), but not the SRM console. To get that, you need to monitor the serial port.

For what it's worth, this is the official list of supported cards on the AXPpci33:

Not exactly the same system of course, but I'd expect firmware/BIOS interop to be similar. Linux follows Digital Unix, fwiw, as it's an ARC/SRM thing.

RayeR wrote on 2022-08-08, 05:03:

The DS12887 was dead all the time as I bought the board - no wonder it was ~25 years old. I tried to replace it with DS1287 with OK batt but no change. Without RTC it doesn't boot neither to Debug Monitor (hangs soon at POST code 00).

Please could you take and upload some video of your booting system? If you have ISA/PCI POST card it would be helpful to film POST display during boot too.

My AlphaStations all have bad PSUs - I'm hoping a recap will bring them back to life but at the moment they won't power on. I do have a DEC Multia VX42B but its also pretty intermittent - also hoping a recap will solve it. I could film that but its using an integrated DEC TGA graphics chip with proper alpha firmware - no BIOS emulation or anything. Its an odd machine. All my other Alphas are big servers (800, 1200, DS20, 4100) and it would be a few days before I could dig one out and fire it up (assuming it still goes).

That said, every Alpha I've seen booting into ARC or AlphaBIOS firmware looks the same. Normal VGA BIOS comes up just you'd see if you put the card in a PC along with any other PC Option ROMs, plus a banner talking about the ROM-based x86 emulator thats making it all work. From there depending on the age of the machine you may or may not get a graphic splash screen, then it starts going through POST - testing memory, initialising SCSI and network devices, complains if there were any errors, then goes to the boot menu if everything was fine. You can see a DEC Personal Workstation 433a going through that process starting the AlphaBIOS firwmare here: https://youtu.be/g0Qc5RDTQmQ?t=1072.

The ARC firmware used on older machines is functionally identical to AlphaBIOS, it just doesn't look as flash. You can see an older Alpha booting ARC firmware here: https://youtu.be/q6_s7OJu9mU?t=425 - pretty much the same, just no graphics.

I guess its possible something may have happened to the firmware - perhaps its been corrupted somehow? If the debug monitor has some way of verifying the firmware image its probably worth checking for it. Also worth checking all the jumpers are set correctly - no clear CMOS jumper accidentally left in or anything. If needed: The motherboard manual, SRM firmware and ARC firmware. I'd try reprogramming the firmware as a last resort though I'm not sure exactly how you'd even go about doing so on a non-bootable machine without the failsafe loader.

GL1zdA wrote on 2022-08-08, 05:54:

What VGA cards are you using? The BIOS emulation is a bit picky, I run my Alphas with Permedia 2 based cards which tend to work with everything (AlphaBIOS, NT and Linux).

I tried with ELSA GLoria (Permedia 2) and it booted once before to AlphaBIOS (NT FW) with this card. Also tried with Matrox Millennium II.

Is it possible that when some byte in RTC's NVRAM is not set properly it hangs? Debug Monitor complains about invalid NVRAM date even when I set it via date command and use reset jumper to keep RTC under power.

davidrg wrote on 2022-08-08, 08:35:

My AlphaStations all have bad PSUs - I'm hoping a recap will bring them back to life but at the moment they won't power on.
...

Neither I have any original DEC PSU. I just made a simple wire-adapter from common ATX PSU to 2 AT connectors with std. pinout and 3rd connector with 3.3V for CPU and it's fine.

Mine Alpha doesn't has any fancy graphics just blue text mode UI. The second video gives a hint. His 1st boot also was not successfull after 2 minutes hanging on BIOS emulation banner. After he replaced the DS battety the blue firmware come on quite fast!
In my case, when it booted to blue NT FW it took several minutes, I don' t remember, may be 3-5min. Later it didn' boot neither after a half of hour. So I will repair the original DS12887 first. Maybe the DS1287 that I used later is not fully compatible. It already happened to me on other x86 MB that some works with wide range of RTC chip but some boards need exact the same type. I wish it would be this kind of issue not else...

So other users doesn't have Debug Monitor on theirs Alpha ststems? I don't know if it is common or rare. Seems the Alpha PC64 board was some kind of devkit for system developers so it was equipped with this first-stage firmware. This firmware resides in xilinx serial rom/flash. There's other parallel 1MB intel flash that holds the NT firmware. It can hold multiple firmware images like SRM and Milo if they can fit inside and you select them by bootopt command. Every image has it's header and chcecksum so integrity is verified. It would be good idea to make a backup but the flahsh is SMD wide TSSOP so not easy even I have a flash programmer. The Debug monitor also can load firmware from a floppy or via serial in SREC format, but I cannot find any files related to Alpha FW. Anyway I probably cannot use FW for other alpha board as it would be some kind HW specific. I already have a PDF manual for the board and for debug monitor.

I've never seen the debug monitor on any of my Alphas but I've never gone looking for it either - I just get the normal firmware (SRM or ARC/AlphaBIOS, what ever is set as the default) out the serial port if I turn that on. They may well have it though - one of my AlphaServers (perhaps a few of them?) have an MMJ connector inside the machine on the CPU card (have to have the case off to get at it) and I've often wondered what it was for. MMJ was used by DEC for connecting terminals rather than regular DE9/RS232 (they called it the DECconnect system and it used RS422 IIRC). So perhaps if I connected a terminal to one of those internal MMJ connectors I might get the Debug Monitor. Its possible that its the debug monitor that implements the failsafe loader too - install a jumper and the machine starts the firmware from floppy disk or CD-ROM instead of ROM.

As for firmware - the two pages I linked to on my mirror of ftp.digital.com should have firmware images for ARC and SRM firmware for the Alpha PC64. I guess you could try see if it would boot pc64srm.rom or pc64srm.sys from a floppy. Or the ARC rom thats in 400B4494.zip. I'm guessing the .SYS file which is the same size as the .ROM file is probably a network-bootable firmware image (via the MOP protocol). There are utilities for making bootable firmware disks which may or may not be useful: https://ftp.zx.net.nz/pub/archive/ftp.digital … ware/utilities/

And yeah, I think most of those motherboards were effectively devkits (or based on them). Digital Semiconductor wanted to as many CPUs as they could - not just put them in high-end workstations and servers. So they provided all the chips you needed to build Alphas plus reference designs or full system boards, as well as all the necessary documentation and special software (FX!32) to let Windows NT on the Alpha run x86 software to encourage uptake. That's what all the Alpha PC boards are - they were for/are out of 3rd-party systems not made by DEC or were reference/example boards for companies designing their own which chips bought from DEC.

Well, I repaired the Dallas RTC via common grinding method (Vbat was too low ~0,3V) and thankfully it booted NT FW. So the FW is not compatible with neither DS1287 nor DS12C887A it seems only original DS12887 working. I can set date&time in Debug Monitor and it no longer complains about "Invalid NVRAM: Bad date Feb 4 11:33:30 19166".
The NT FW now boots quite fast, cca 35s from power up to first blue screen, BIOS emulation banner is visible just for a second. The final POST code is 00h. But I have a problem that now NT FW complains about bad date&time and boot config. Even if I set new date&time (tried 2022 and 1992 for case of Y2K bug) and restart it still complains but the date&time is set properly as seen in System info screen. Also tried to load default settings and didn't change...

NT FW:

davidrg wrote on 2022-08-08, 08:35:

The ARC firmware used on older machines is functionally identical to AlphaBIOS, it just doesn't look as flash.
....
If needed: The motherboard manual, SRM firmware and ARC firmware. I'd try reprogramming the firmware as a last resort though I'm not sure exactly how you'd even go about doing so on a non-bootable machine without the failsafe loader.

Thanks for the links. I finally had some time to browse the FTP archive thoroughly. It's good there still exist some DEC archive but there are not all documents. I'm unsuccessfully looking for PC64 board design files and schematics or at least this documents referenced in manual:
EC–N0301-72 - Designing a Memory/Cache Subsystem for the DECchip 21064 Microprocessor: An Application Note
EC–N0107–72 - Designing a System with the DECchip 21064 Microprocessor: An Application Note
I'd like to reverse-engineer and replicate L2 cache module and need at least cache slot pinout.
I only found design files for newer PC164 but it has already L2 chache onboard so it doesn't help.

At least I downloaded the latest ARC and SRM firmwares for PC64. It seems that AlphaBIOS FW never existed for this old board but don't mind. Also there should be some MILO image for booting Linux but I found only some MILO floppy images instead ROM image to flash. So I put ARC and SRM on a floppy and performed FW update (I didn't have SRM installed before, just NT FW). It flashed without any problem and I can select both FWs. But the problem with SYSTEM TIME - must be fixed issue still persist. I tried again go back in time and found that any date after 1.1.2021 fails. This is quite weird break value, I would mostly expect well known Y2K problem. But it is not the RTC HW limitation! When I set 31.12.2020 23:59:50 I can watch successful rollover to 1.1.2021 0:00 in console so it seems to me like they put intentionally a timebomb inside the FW - this calls to be cracked but I don't have knowledges about ROM image format and how it's protected by some CRC, etc...

So I just set year 2012 and now I'm able to continue to WinNT install menu finally. I have to hook up some IDE HDD and CDROM drive and look for NT4 CDROM, I have it somewhere...
This would be one of rare living APC64 system on the world I didn't find anybody else running this board 😀

I would not worry too much about the BIOS Date Time, just do net time /set /y \\<W10 system> once the system is running to set the correct Date Time. I would also try and set the correct Date Time before installing NT4.

I wonder if it will run Windows 2000 RC1 or RC2. If you do install W2K I recommend setting the Date Time as now + 50 years as RC2 stops running a while after it's installed, I can't remember exactly how long. Back in 2009 when I installed W2K on my PWS 600a I set 2059-08-27 and all is still OK.

RayeR wrote on 2022-08-08, 17:08:

Neither I have any original DEC PSU. I just made a simple wire-adapter from common ATX PSU to 2 AT connectors with std. pinout and 3rd connector with 3.3V for CPU and it's fine.

Hi. I have almost the same board (bare metal, no PSUs, but with Alpha 21064) and I'm unable to start it up. Obviously due to absence of 3rd connector. Are you sure it is intended for powering CPU and not for PCI lines?

P.S. As you I also use ATX->AT adapter. Unfortunately PCI POST card outputs nothing. Either Dallas chip is faulty or SIMMs parity wrong or 3rd connector is a must have...

Hi, the CPU is powered from 3.3V connector so don't wonder you get nothing.
Just cut some MB PWR connector from old/dead AT PSU and solder it to ATX connector 3V3 and GND. My Alpha board had two aux. 3V3 connectors, 3 wires are 3V3 and other 3 wires are GND. One connector has 3V3 and GND flipped opposed to other connector so one must be careful what PSU connector plug to what MB connector.