VOGONS


First post, by RayeR

User metadata
Rank Member
Rank
Member

Hi,
I'm playing with this nice board. A have plugged in CPU Alpha 21064 at 275MHz , 48MB of RAM, no cache module. I jumeped to disable cache. I have attached serial terminal at COM1 because until I made cable for KBD it doesn't display to VGA but serial console only. I also have ISA POST card to see what it's doing and it sends some POST codes like normal x86 PC. The RTC battery in soldered DS12887 is dead so it always boots to Debug Monitor by defalt. Then I switch to NT FW via bootopt 1 command (with VGA and KBD connected) and short reset jumper to reboot. I can see VGA BIOS gets initilaized and after some seconds it displays "BIOS Emulation V1.15, Copyright..." message but then nothing else and nothing output on serial console. The POST code sequence is different that when booting Debug Monitor (last code FBh) so it does something. The last POST code with NT FW where it hangs is 77h and previous 78h.

But once previously I played with it it booted to NT FW after several minutes of waiting. I don't remember the last POST code. There was menu where I can install OS and other stuff. But then I disassembled the setup and assembled again later and cannot boot it. I also tried more VGA cards (PCI and ISA). BTW I found one suspicious behavior when in Debug Monitor I use romlist command, when there's no PCI VGA or ISA VGA is used then I got list of firmware images as expected:

ROM image header found at offset: 0x000000
Header Size......... 0x38 (56) bytes
Image Checksum...... 0x6bc2 (27586)
Memory Image Size... 0x2EB10 (191248 = 186 KB)
Compression Type.... 0
Image Destination... 0x0000000000300000
Header Version...... 2
Firmware ID......... 0 - Alpha Evaluation Board Debug Monitor
ROM Image Size...... 0x2EB10 (191248 = 186 KB)
Firmware ID (Opt.).. 0200009601181619 ........
ROM offset.......... 0x00000000
Header Checksum..... 0x666f

ROM image header found at offset: 0x030000
Header Size......... 0x34 (52) bytes
Image Checksum...... 0x7ce2 (31970)
Memory Image Size... 0x42B78 (273272 = 266 KB)
Compression Type.... 0
Image Destination... 0x0000000000300000
Header Version...... 1
Firmware ID......... 1 - Windows NT Firmware
ROM Image Size...... 0x42B78 (273272 = 266 KB)
Firmware ID (Opt.).. 0442009511091409 .....B.
Header Checksum..... 0xbafb

But when a PCI VGA card is plugged in (tried different ones and different PCI slots) then the command displays that no images was found and also romboot command doesn't work. Is it normal behavior? I can't remember if it bahaves same when NT FW booted before. I didn't any FW update or manipulation with flashchip.

Does someone have Alpha PC64 or similar system who could help?
What is the POST code sequence of successfull NT FW boot?
How long does it boot on your system?
Does it need to attach other peripherals as floppy/HDD? Maybe it's trying to init them but I didn't have attached it yet and it booted NT FW at least one time before...

Last edited by RayeR on 2022-10-19, 15:31. Edited 1 time in total.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 1 of 12, by davidrg

User metadata
Rank Member
Rank
Member

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.

Reply 2 of 12, by RayeR

User metadata
Rank Member
Rank
Member

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.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 3 of 12, by GL1zdA

User metadata
Rank Oldbie
Rank
Oldbie

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).

getquake.gif | InfoWorld/PC Magazine Indices

Reply 4 of 12, by dionb

User metadata
Rank l33t
Rank
l33t

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:

AXPpic33_VGA.png
Filename
AXPpic33_VGA.png
File size
34.36 KiB
Views
383 views
File license
Fair use/fair dealing exception

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.

Reply 5 of 12, by davidrg

User metadata
Rank Member
Rank
Member
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.

Reply 6 of 12, by RayeR

User metadata
Rank Member
Rank
Member
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.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 7 of 12, by RayeR

User metadata
Rank Member
Rank
Member
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.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 8 of 12, by davidrg

User metadata
Rank Member
Rank
Member

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.

Reply 9 of 12, by RayeR

User metadata
Rank Member
Rank
Member

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...

Attachments

Last edited by RayeR on 2022-08-10, 01:54. Edited 1 time in total.

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 10 of 12, by RayeR

User metadata
Rank Member
Rank
Member

NT FW:

NTFW1.jpg
Filename
NTFW1.jpg
File size
27.31 KiB
Views
296 views
File license
CC-BY-4.0
NTFW2.jpg
Filename
NTFW2.jpg
File size
42.58 KiB
Views
296 views
File license
CC-BY-4.0
NTFW3.jpg
Filename
NTFW3.jpg
File size
46.62 KiB
Views
296 views
File license
CC-BY-4.0
NTFW4.jpg
Filename
NTFW4.jpg
File size
43.18 KiB
Views
296 views
File license
CC-BY-4.0

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 11 of 12, by RayeR

User metadata
Rank Member
Rank
Member
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 😀

Gigabyte GA-P67-DS3-B3, Core i7-2600K @4,5GHz, 4GB DDR3, 128GB SSD, GTX670(GF7900GT), SB Audigy + YMF724F + DreamBlaster combo

Reply 12 of 12, by red-ray

User metadata
Rank Oldbie
Rank
Oldbie

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.