Debugging AST Premium/286 POST and lack of Beep codes

[sqpat]

I came upon a trio of AST Premium/286es today. They are (as the name implies) 286-based desktop machines with some proprietary technology based around faster memory access and the like. Anyway, I tried two power supplies including one from a working IBM 5150 with a working VGA card from that same machine.

All 3 machines have no video signal, and no beep codes from the speaker when I power them on. (Well, one had no internal speaker). Front panel LEDs were powered. Upon further inspection one machine had no BIOS chips. The fact that it behaves the same as the other two with bios chips makes me think it might be bad BIOS chips (That would suggest no POST/beeps right?)
Another thing, though is that the motherboards don't have memory. I don't yet have the proprietary AST FastRam card. I'm wondering if an owner of this machine knows if you get a silent boot/no error without that card? I tried an ISA memory board and it didn't change boot behavior, and I've seen a forum post that suggested the FastRam card was required - I don't know if that means normal ISA bus memory doesn't work for some reason?

Anyway, I was hoping someone with the machine or manual could chime in if they know anything about boot/post behavior with/without the FastRam card, and if someone might have a working BIOS for this machine. I don't know a lot about replacing BIOS chips and if it can be any old generic 286 bios or not.

 

[mR_Slug]

is this your board? https://www.ultimateretro.net/en/motherboards/674

if so one of these bioses may work:

The Retro Web

The Retro Web hardware database

www.ultimateretro.net

We don't have the se variant. Do you have a board picture? From what i can tell you need the RAM card unfortunately.

 

[sqpat]

Yes, that's the board. The good news is I got a BIOS programmer yesterday and dumped the AST labeled BIOS chips in one of the motherboards yesterday - so I may be okay on the BIOS front. (I'll try to get that uploaded to some of these database websites at some point). However, I still have a seemingly dead board without the ram card. I ordered the ram card and have that on the way and can test it out in two weeks when it arrives. I don't want to purchase 3 of them for the 3 machines yet, since there's a chance the boards really don't work. I'll have more info then.

My guess is, the motherboard connects the 286's memory lanes directly to the proprietary slot on the memory board, and the memory board forwards that to the ISA bus. So without this proprietary card your 286 can't reach any other ISA ram boards, VGA cards, etc.

 

[mR_Slug]

Yes I think you are right. Can we at ultimateretro.net have the BIOS image, and if possible an image of the board? RAM card would be great too. Don't know what the SE part indicates, any idea?

 

[sqpat]

Sorry, I was confused by what you meant by "SE" in the past two posts. It may be that I said I had "a trio of AST Premium/286es", the "es" i just meant as a plural of the "286", not part of the part name.

That said I think among the 3 desktops are two separate motherboard revisions (002 and 003). I will post some photos in a bit, and the bios image. I do want to caution that without the memory card yet, I can't say 100% sure that these bios chips actually work. I do see some "AST" copyright text at the top of the BIOS file though.

EDIT: Added photos of the boards and the BIOS chips.
EDIT 2: Let me add that these BIOS chips were numbered 107000-656 and 107000-657. Their versions are "AST BIOS version 2.0"/"AST Phoenix BIOS - version 3.03" and they were an upgrade. You can read about it here: Windows Problems on AST Premium/286 . The 656 goes in the ODD bios slot and the 657 goes in the EVEN. (confusing, yes)

 

[mR_Slug]

Thank you. I have updated the page. "es" ah I see I thought it might be a 386sx version. I have been documenting the PS/2 model 56 & 57 today, and have been dealing with SLC, SX, SLC2 etc. I must have got my wires crossed.

 

[sqpat]

OK - I got a new working one from ebay. I dumped that BIOS and it worked on one of the other motherboards (the other two seem to be bad.) The previous BIOS, despite being AST labeled seems to not work on the working machine either, so it was a bad dump. Please go ahead and remove that from the page.

Meanwhile, this working BIOS is an older revision - i will keep doing some research on this and figure out if another phoenix BIOS might work. I think the original I have working is an AST, and the updated one was an "AST/Phoenix BIOS"... One problem is I can't do user HDD settings, so Im not sure I can get my CF card to work as a HD right away.

BIOS files (and new picture!) attached.

 

[mR_Slug]

OK - I got a new working one from ebay. I dumped that BIOS and it worked on one of the other motherboards (the other two seem to be bad.) The previous BIOS, despite being AST labeled seems to not work on the working machine either, so it was a bad dump. Please go ahead and remove that from the page.

Thanks. I will update the page. Can you give me the BIOS version, I tried to extract it but can't find it.

You can set an IDE drive to a capacity lower than it's total. In the BIOS choose a large capacity number, partition and format the drive in the system and it should work. This used to be the only way to install some drives back in the day without DDO software. I'm not sure how this will affect a cf card that is also being put in another system. It might just work, it might cause the other system to freak out.

 

[sqpat]

Thanks for the suggestion on the CF card. May give that a try as a stopgap measure, or may try an XT-IDE universal bios chip in an option ROM (and post about how it goes)

The BIOS version is 1.1. I actually believe this BIOS version may have some Windows and keyboard issues based on AST bulletins. I'll check some other sources and see if I can get anyone else to produce a dump of their working chip.

Some notes:
- The keyboard controller seemed to be an Intel P8742AH - it was missing from 2 of my machines that aren't POSTing, so I'll try getting some of those chips and see if that fixes the issue.
- I also had one machine missing a UART chip (U57) and that was a 16450 based on the other machines.

 

[modem7]

The keyboard controller seemed to be an Intel P8742AH - it was missing from 2 of my machines that aren't POSTing, so I'll try getting some of those chips and see if that fixes the issue.

Are you aware that:
* The 8742 is not a dedicated keyboard controller chip.
* To be a 'keyboard controller', the 8742 needs to be programmed with suitable keyboard controller code.
* The keyboard controller code used in the 8042/8742 of the IBM AT motherboard is suitable for a lot of early AT clones.
* The P8742AH is the windowless version of the P8742 EPROM.

 

[sqpat]

Actually, those were all things I wasn't aware of! There's a lot I don't know about this. I only just learned how to use an EPROM programmer to dump and program my motherboard BIOS chips (and that already fixed one of my non-working machines)

I don't know if its possible to dump the ROM contents of the P8742AH's I have and for instance, flash them onto a D8472(?) or other programmable version and drop them in to the two machines missing them. Even then, I can't seem to get the ICs out of the socket of the motherboard with my IC puller (i can literally lift the 35+ lbs of the case and motherboard by the IC puller..) , and I don't want to break any legs, so I hoped to see if a generic replacement might work first on the non-working machines before doing anything risky. Otherwise I'd just move them to the non-working motherboards and see if that gave me a POST or at least an error.

The IBM AT motherboard version sounds like a good idea but I don't have one, I don't see the BIOS dump of it online and I'm not sure my EPROM programmer supports it out of the box either. If I can figure out how to setup the programmer to support it and find a dump, I can try that out.

In the meantime I'm going to try the XT-IDE Universal BIOS on the Option ROM slots.

 

[modem7]

The IBM AT motherboard version sounds like a good idea but I don't have one, I don't see the BIOS dump of it online and I'm not sure my EPROM programmer supports it out of the box either. If I can figure out how to setup the programmer to support it and find a dump, I can try that out.

It is a 'try it and see' thing.

A dump of the code from the IBM AT's (IBM 5170's) 8042/8742 is at [here]. There, scroll to the IBM section, then within the section, look for 'U126'.

I don't know if any modern EPROM programmers support the 8742. For some old chips, I have an old Willem programmer, and together with a suitable adapter, can read/write the 8742 - see [here] and [here].
Some companies/people at [here] can help.

 

[sqpat]

Happy occurrence today - I encountered an AST/Premium 286 motherboard at the local electronic recycler's shop today! It had all the socketed chips in there.

Purchased it, was able to easily remove the keyboard controller from this one and try it in the 2 non-working motherboards. No luck. Put it back in the original motherboard and it booted fine.

I guess it's fair to assume at this point that the lack of post/beep/etc codes is not related to this keyboard controller... I'll hold off on buying Willem programmer and MCS-48 adapter for now and consider possible problems on the motherboard. Will keep working on these machines and update anything i discover.

 

[sqpat]

Another update - The earlier 2.00 motherboard BIOS I had dumped actually WAS okay. The Odd/Even BIOS stickers were reversed, but the contents were also reversed, so it was actually okay all along - I actually made it not work when I assumed they were backwards and reversed them. I took a look at them in a hex editor today, realized my mistake, and re-programmed it and it worked. So, the first BIOS I posted is a 2.00 BIOS and the 2nd one is the 1.10 BIOS.

As for the XTIDE universal BIOS, I built the binary from source, split the "AT large" build up into odd/even binaries, programmed and stuck those chips in the motherboard's option ROM slots. With debug I confirmed that it got loaded into memory, but those addresses range from E000-FFFF, and it seems to not run at boot unfortunately. I did some digging, learned about how the checksum is expected to add up to 0 for a boot BIOS to run. The "AT large" had has 18h (12 KB) defined as the BIOS size at 0x02, so I padded the binary with FF, up until I changed the byte at 0x2FFF to 6D to make the checksum of this range add up to 00. I had to then pad with FF up to 0x7FFF, then mirror that entire binary to get to 0xFFFF since I was writing to a 27C256 where a 27C128 was expected. (Does this sound right?)

 

[modem7]

With debug I confirmed that it got loaded into memory, but those addresses range from E000-FFFF,

FFFF ?
The motherboard BIOS has to be in there somewhere.
For example, [here] is the memory map of another early 286, the IBM AT. In that, the motherboard BIOS starts at address F0000 ('segment' F000).

 

[modem7]

I did some digging, learned about how the checksum is expected to add up to 0 for a boot BIOS to run.

With the XTIDE universal BIOS (XUB), normally one downloads a pre-built binary, then uses the XTIDECFG.COM tool to:
1. [XTIDECFG] Import the downloaded XUB binary; then
2. [XTIDECFG] Configure that XUB; then
3. [XTIDECFG] Either: Export the configured XUB to a new binary file, or flash the configured XUB to an EEPROM.

XTIDECFG.COM automatically makes an alteration so that the checksum is 00.

See the notes at [here].

 

[sqpat]

The motherboard BIOS has to be in there somewhere.

Oops, yes, It's from E000-EFFF (if 27C256), E800-EFFF, or F000-F7FF depending on jumpers. The motherboard bios can reside in F000-FFFF or F800-FFFF depending on jumpers.

[XTIDECFG] Either: Export the configured XUB to a new binary file, or flash the configured XUB to an EEPROM.

Thanks for the advice. I didn't realize the binary file export option was there, that makes things easier.

I went and tried that on all 3 working machines (which have various motherboard revisions and BIOS revisions at this point) and none of them still want to run the BIOS. The Video BIOS runs fine before the Motherboard BIOS - which then goes straight to trying to boot from floppy (or disk if defined). There seems to be no fallback to option BIOS in the case of no floppies, non-bootable floppies, etc.

I downloaded the Utils/Diagnostics diskette for the machine and tried it out. It has some diagnostics (nothing significant came up) and some programs are there related to caching, changing the CPU speed, detecting memory, etc. There's a tool that brings up the BIOS menu within MS-DOS, but it's the same settings you can normally change by hitting Ctrl+Alt+Esc at boot. There are some tools that seem to have undocumented flags and options and it says to refer to the manual. I can only find the MS/DOS reference for this machine, though.

 

[modem7]

I went and tried that on all 3 working machines (which have various motherboard revisions and BIOS revisions at this point) and none of them still want to run the BIOS.

Each computer has its own requirements, peculiarities, nuances.

An example is the 'option ROM/BIOS' sockets on the IBM AT (IBM 5170) motherboard. If populated, the power-on self test (POST) motherboard BIOS will see 55AA at address E0000. Seeing that, the POST then ignores the 'ROM size' byte, and goes on to calculate the 8-bit checksum of the entire 64 KB at E0000. If that checksum is not 00, the POST ignores the ROM. More on that at [here]. Did AST perhaps copy IBM's behaviour !

The Video BIOS runs fine before the Motherboard BIOS ...

Maybe you meant "displays" rather than "runs".

... - which then goes straight to trying to boot from floppy (or disk if defined). There seems to be no fallback to option BIOS in the case of no floppies, non-bootable floppies, etc.

In regards to BIOS expansion ROM (a.k.a. boot ROM) and disk booting, normally, the order/sequence is something like:

1. Computer powered on. Power-on self test (POST) starts.

2. At some point in the POST, the POST looks for BIOS expansion ROM's on video cards (e.g. VGA card). If found, and the POST considers the ROM content to be 'valid', the POST passes execution to the initialisation code in the ROM. The code does whatever initialisation it needs to do, which may include displaying something on-screen. The initialisation code then then passes execution back to the POST.

3. At some point in the POST, the POST looks for BIOS expansion ROM's on other types of cards (e.g. SCSI card). If found, and the POST considers the ROM content to be 'valid', the POST passes execution to the initialisation code in the ROM. The code does whatever initialisation it needs to do, which may include displaying something on-screen. The initialisation code then then passes execution back to the POST.

4. At some point in the POST, the POST looks for BIOS expansion ROM's in motherboard hosted option ROM /BIOS sockets . If found, and the POST considers the ROM content to be 'valid', the POST passes execution to the initialisation code in the ROM. The code does whatever initialisation it needs to do, which may include displaying something on-screen. The initialisation code then then passes execution back to the POST.

5. POST does 'bootstrap' (e.g. boot from disk, and if applicable, on-board BASIC).

In the case of the IBM AT (IBM 5170), the POST is written specifically for the IBM AT motherboard, and therefore, the POST only looks at address E0000 for BIOS expansion code in motherboard hosted option ROM sockets.

BIOS expansion ROM can change boot behaviour.

Before any attempt to boot from disk, you should be seeing the banner/splash screen that the initialisation code within the XTIDE universal BIOS (XUB) displays.

 

[sqpat]

Just as a sanity check, I tried a standalone XT-IDE card and it did work fine.
I have an Etherlink III with a boot rom socket, too. I got the XT-IDE bios to run from it with the same binary (minus the odd/even interleave).

An example is the 'option ROM/BIOS' sockets on the IBM AT (IBM 5170) motherboard. If populated, the power-on self test (POST) motherboard BIOS will see 55AA at address E0000. Seeing that, the POST then ignores the 'ROM size' byte, and goes on to calculate the 8-bit checksum of the entire 64 KB at E0000. If that checksum is not 00, the POST ignores the ROM. More on that at [here]. Did AST perhaps copy IBM's behaviour !

Aha! So if it does actually behave this way, I would (assuming a "zeroed out" padding) move the byte currently at offset 2FFF of the 12kb binary over to offset FFFF (or 7FFF, whatever it's expecting.)

EDIT: But thinking about it - wouldn't the 8 bit checksum end up 00 regardless, as I am zero-padding? So it's probably no different.

 

[modem7]

Aha! So if it does actually behave this way, I would (assuming a "zeroed out" padding) move the byte currently at offset 2FFF of the 12kb binary over to offset FFFF (or 7FFF, whatever it's expecting.)

EDIT: But thinking about it - wouldn't the 8 bit checksum end up 00 regardless, as I am zero-padding? So it's probably no different.

Maybe the question in your edit is rhetorical.

If not: You can pad with anything you want. And then to get an 8-bit checksum (for the area looked at by the POST) you could even adjust multiple bytes rather than one byte (obviously, anywhere but used code/data) - not that anyone would; one byte is enough. Anything that does not damage the code/data areas, and achieves an 8-bit checksum for the area looked at by the POST.