Hi Chris,

Although I’m not familiar with these industrial Fujitsu/ICL machines, I do know a lot about socket 3/5/7 boards from the nineties and their BIOSes.
So I hope I can be of assistance with your nice Ergo pro x453 machine.

In the 1993/1994 486 era, the BIOS usually fitted in a 64KB EPROM. But when the PCI bus came along, 128KB BIOSes had to be used to house all the BIOS code. These BIOSes however were still uncompressed.

From about 1996 the 128KB (E)EPROM size was not sufficient anymore to contain all BIOS routines, so BIOS developers started to use compressed BIOSes. These compressed BIOS "BIN" or "ROM" files are flashed directly into the flash ROM.
The upper 20KB or so from such a BIOS is not compressed and contains the boot block code and decompression engine. This boot routine checks the checksum of all compressed modules and decompresses them in memory and shadow RAM. Then control is passed to the POST routines in shadow RAM to start the whole boot process.

When more and more functions were added to the BIOS in later years, the BIOS size kept growing to 256KB and more. In your x453 machine with its on-board VGA chip, the VGA BIOS is present as custom ROM in the main BIOS and the BIOS size will need to be at least 256KB.

Because of this required BIOS size, I’m convinced the CAT28F002 chip is the BIOS Flash ROM. This chip contains a separate protected section for the boot block. As the BIOS boot block also houses a recovery routine for when the compressed BIOS modules are corrupted, this allows a BIOS recovery after a bad flash and identifies the CAT28F002 chip as the BIOS ROM.

The UM61256A - 32Kb CMOS SRAM is probably the NVRAM to store system and BIOS configurations parameters.

Finally, when I look at the handbook at https://www.yumpu.com/en/document/read/279936 … k-fujitsu-uk/45 and navigate to page 5-4, it shows POST code 61 as “Harddisk controller error”. By this time during POST you should see something on the screen and be able to enter the BIOS Setup.

Regards, Jan

Chkcpu wrote on 2024-01-15, 11:21:

Finally, when I look at the handbook at https://www.yumpu.com/en/document/read/279936 … k-fujitsu-uk/45 and navigate to page 5-4, it shows POST code 61 as “Harddisk controller error”. By this time during POST you should see something on the screen and be able to enter the BIOS Setup.

Thanks a lot for the reply Jan, its just what I needed. This is obviously a lot more nuanced than ROM/BIOS behaviour of the Amiga era machines. So...

I take your points, apart from the above, the section I am looking at is page 5-10 "BIOS CHECKPOINTS, values in hex". I think these are the codes with correspond with the values shown on my POST CODE card, no? To be clear, this the sequence, and what its values mean, accordingly

06 - Chipset Unique Code i.e. DRAM config (no idea what this actually means)
CA - Not in manual 🙁
C6 - Not in manual 🙁
28 - Fill lower 65k with FFFF
25 - Test first 64k with values, then verify
88 - Setup Floppy drives
25 - Test first 64k with values, then verify
52 - Scan base memory start at 64k to end of mem
52 - Scan base memory start at 64k to end of mem (not sure why it checks the ram twice...)
61 - Decompress BIOS

So... 62 in this BIOS, which I assume would happen next is DEPLOY BIOS, does that give a clue

Cheers

Chris

Retronaut wrote on 2024-01-15, 16:03:

Chkcpu wrote on 2024-01-15, 11:21:

Finally, when I look at the handbook at https://www.yumpu.com/en/document/read/279936 … k-fujitsu-uk/45 and navigate to page 5-4, it shows POST code 61 as “Harddisk controller error”. By this time during POST you should see something on the screen and be able to enter the BIOS Setup.

I take your points, apart from the above, the section I am looking at is page 5-10 "BIOS CHECKPOINTS, values in hex". I think these are the codes with correspond with the values shown on my POST CODE card, no?

Yes, you are correct. The BIOS check points on pages 5-8 to 5-11 of the on-line handbook are indeed the POST codes!
I was mislead by the elaborate list of error messages starting at page 5-2 and didn’t read on past this list. Consumer PC socket 7 BIOSes seldom have more than 10 error messages. 😉

The logic with POST codes is that the BIOS issues the code at the beginning of each test.
So your x453 hangs at POST 61 when decompressing the compressed modules in shadow RAM. This could be caused by a corrupt BIOS or by flaky RAM. The later can also be caused by bad or corroded SIMM slot contacts.
Another thought is that this system doesn’t work well with EDO RAM and needs FPM RAM to work correctly.

Do you have the speaker connected and do you hear any beep codes? Page 5-7 shows the beep list and if you hear any of these codes, this would help a lot.
I hope you don’t hear the dreaded beep code for “The checksum of the BIOS ROM is not correct”.

Cheers, Jan

Chkcpu wrote on 2024-01-15, 18:46:

Do you have the speaker connected and do you hear any beep codes? Page 5-7 shows the beep list and if you hear any of these codes, this would help a lot.
I hope you don’t hear the dreaded beep code for “The checksum of the BIOS ROM is not correct”.

Yes, I do have a speaker...

Not heard the corrupted BIOS beeps yet....

Chkcpu wrote on 2024-01-15, 18:46:

The logic with POST codes is that the BIOS issues the code at the beginning of each test.
So your x453 hangs at POST 61 when decompressing the compressed modules in shadow RAM. This could be caused by a corrupt BIOS or by flaky RAM. The later can also be caused by bad or corroded SIMM slot contacts.
Another thought is that this system doesn’t work well with EDO RAM and needs FPM RAM to work correctly.

Question, what is Shadow Ram? Is that a discreet chip, or is it using the RAM on the main system DIMM?

The 32MB, non EDO DIMM (FPM) that came with it (from factory), (which it previously worked with), I THINK is ok. If its removed, it emits a beep * * - -, saying addressing first 64 has an issue, which makes sense, as there is NO RAM.
If you pop the 32MB DIMM in, it continues until it hits the 61 Post Code, no beeping.
I have bought 2 more DIMMS, non EDO, same behaviour.

So, would it be decompressing the BIOS into this SRAM, the 32k chip? A friend of mine thinks this is faulty, and causing the hang, but I guess this is ONLY used to store BIOS settings and so non vital for boot?

I guess it NOT being able to decompress the VGA Bios into that chip (etc) might cause this right.
there is ZERO video on this machine eight now..

If it IS the RAM at fault, I am at a bit of a loss. The DIMM slots seem ok, and WERE working, I suppose some kind of supporting chip might have failed, and yet, no DIMM in produces no RAM error and it carries on when DIMM is in, suggesting RAM is not the issue and it also suggests at least SOME of the non compressed BIOS is intact, as its making those beeps right. I have tested with all 3 DIMMs, same behaviour.

Cheers

Chris

Retronaut wrote on 2024-01-15, 20:19:

The 32MB, non EDO DIMM (FPM) that came with it (from factory), (which it previously worked with), I THINK is ok. If its removed, […]
Show full quote

The 32MB, non EDO DIMM (FPM) that came with it (from factory), (which it previously worked with), I THINK is ok. If its removed, it emits a beep * * - -, saying addressing first 64 has an issue, which makes sense, as there is NO RAM.
If you pop the 32MB DIMM in, it continues until it hits the 61 Post Code, no beeping.
I have bought 2 more DIMMS, non EDO, same behaviour.

If it IS the RAM at fault, I am at a bit of a loss. The DIMM slots seem ok, and WERE working, I suppose some kind of supporting chip might have failed, and yet, no DIMM in produces no RAM error and it carries on when DIMM is in, suggesting RAM is not the issue and it also suggests at least SOME of the non compressed BIOS is intact, as its making those beeps right. I have tested with all 3 DIMMs, same behaviour.

Chris

Reading what you have tried with the DIMMs, I agree that it is not the RAM that’s at fault.
And yes, shadow RAM is provided by the main system DIMM(s).

Shadow RAM was invented in the 286 days to increase performance by copying the slow system and/or video ROM to fast DRAM at the same memory address during POST. After this copying, the ROM was disabled and the RAM section now containing the ROM code was write-protected.
Remember that in those DOS days, the OS depended heavily on the Interrupt service routines in the BIOS to do the low-level talk with the hardware. Each time the screen, keyboard, floppy, harddisk, serial- and parallel ports, and mouse were accessed, DOS called the BIOS to do the dirty work. So the BIOS was not only used during boot-time but also at run-time.

Note that with later OSes, especially since Windows 95 and Linux, these BIOS services were only used during boot-time because these OSes came with their own low level kernel-mode drivers to directly control the hardware.

Now, irrespective of the OS used, with the compressed BIOS Shadow RAM is essential. But to get the ROM code in Shadow RAM, a 2-step process has to be used.
First the compressed ROM modules have to be decompressed to a free spot in main RAM. (No, the 32KB SRAM is not used for this.)
Secondly, after an integrity check, these decompressed blobs are copied to their allocated place in Shadow RAM.
Then the bootblock code jumps to the start address of the BIOS in Shadow RAM and disables itself.

The first decompression part is obviously what happens during POST_61 and the second copy part probably as well.
Starting the BIOS code in Shadow RAM is probably what POST_62 is doing, but we never get that far.
This is also why you never see anything on the screen. The code that initializes the VGA chip and puts the first messages on the screen is performed later by the BIOS in Shadow RAM.

Thinking about what could be the cause of the POST_61 hang, well there are numerous possibilities.
Lets start with the BIOS itself. We know the bootblock is fine and working, but we know nothing about the state of the compressed modules. Unfortunately the system doesn’t boot so you can’t read the flashchip contents with Uniflash, and to add insult to injury the flashchip is soldered to the board and can’t be simply pulled from its socket to be read in an (E)EPROM programmer.
(Yes, I watched the nice video on your YouTube channel.) 😉

A question: do you know if a BIOS flash-update was performed, or did the system previously work with the present BIOS? I was thinking that maybe the wrong BIOS LDB file was used. This would explain this behavior without triggering a BIOS checksum error.

Other things to try:
- use a fresh Lithium battery
- Reset the CMOS
But you probably have done that already.

Okay, hopefully I have more thoughts about the issue in my next reply.

Cheers, Jan

Once again Jan, thank you for your clear reponse, info about how the whole BIOS dance happens is pretty crucial here....

Chkcpu wrote on 2024-01-17, 13:20:

(Yes, I watched the nice video on your YouTube channel.) 😉

Thank you very much for watching! 😀
For anyone else reading in, the channel is https://www.youtube.com/@RetronautTech and the video in question is https://www.youtube.com/watch?v=buB_9r7s6DM

A quick question, I get what you are saying, that the BIOS gets decompressed into shadow RAM, which is the main system RAM
So, the 32kb SRAM, thats just used for...? storing the BIOS values?

Chkcpu wrote on 2024-01-17, 13:20:

Thinking about what could be the cause of the POST_61 hang, well there are numerous possibilities.
Lets start with the BIOS itself. We know the bootblock is fine and working, but we know nothing about the state of the compressed modules. Unfortunately the system doesn’t boot so you can’t read the flashchip contents with Uniflash, and to add insult to injury the flashchip is soldered to the board and can’t be simply pulled from its socket to be read in an (E)EPROM programmer.

Yes, quite, the package has a very fine leg pitch. I guess if I KNEW it was at fault, it could be de-soldered, and a socket installed, but certainly not an easy task for a journeyman solderer (me)
And the issue is this, I DONT have any new BIOS to flash into it, if it were corrupted. This is a 1998 Fujitsu PC, so getting any BIOS for it is proving difficult
It (apparently) is a custom ICL(Fujitsu) BIOS, so I cant just flash in a very similar one
Of course, it could just be a re-branded AMI or other BIOS, but to be fair, its POST codes do seem distinct from other BIOS's, so maybe its is as they say, custom

Chkcpu wrote on 2024-01-17, 13:20:

A question: do you know if a BIOS flash-update was performed, or did the system previously work with the present BIOS? I was thinking that maybe the wrong BIOS LDB file was used. This would explain this behavior without triggering a BIOS checksum error.

No BIOS flash, as I dont have anything to flash with.
I would only do that anyway, if it were needed, and right now, not sure if its needed due to it being flatlined like this.
Also, to flash this BIOS, you need to use a floppy, so MAYBE that could be done in this state, really not sure
One of the POST codes is check the floppy, before reaching 61, so it might actually function to allow flashing the BIOS if it failed like this
But again, I have no BIOS file at hand to try this, or I would, in a flash 😀

Chkcpu wrote on 2024-01-17, 13:20:

Other things to try: - use a fresh Lithium battery - Reset the CMOS But you probably have done that already. […]
Show full quote

Other things to try:
- use a fresh Lithium battery
- Reset the CMOS
But you probably have done that already.

Yes, I have tested the current battery and its 3v, so I think the seller put a fresh one in. And I have followed the procedure to reset the CMOS, probably 5+ times now, with no visible difference.

Just to be clear about the timeline for you

• I made the video you watched
• Took the machine apart, taking care
• Washed case and logic board in a bath, using shower head, with low pressure. I had removed ALL pluggables on it before I did this, the CPU incuded
• Dried the logic board with an compressed air gun, taking car to jet under chips until no more streaks of water could be seen on the board anywhere
• Let it air dry for one day afterwards
• Plugged the CPU back in and the the PSU and a VGA monitor
• Turned it on
• Fans spun up, no video * * - - Beeps, meaning no RAM found
• Turned it off
• Inserted the DRAM
• Turned it on
• No beeps, no video, nothing

Then I probed it, but that was stymied as I only had a 25mhz scope, and I needed to check 66mhz values. However, I did ascertain that it was VERY likely the CPU was good, as it was issuing no ram beeps, which needs CPU. AFAIK
Then I had to wait for a Post Analyser card to turn up from Ebay, as I was largely in the dark, and probing only got me so far.

Once that arrived, I tested it again,

• Without RAM = * * - - Beeps
• Put the RAM DIMM back in
• With RAM It ends with 61 as we have discussed

A friend, something of an engineer, has his bets on the 32kb SRAM, but Im not sure. It feels to me, 80% ish that maybe something in the BIOS got borked somehow, and now I have no BIOS file to fix it with 😒

I think Ill put in a bit more effort to find the BIOS, who knows, it MIGHT be out there somewhere, but its a VERY tall order...
Cheers

Chris

Hi Chris,

Thanks for clarifying the timeline of your experiences with this machine.

As the x453 worked before you dismantled and cleaned it, I now think it is less likely that the BIOS is borked. Perhaps some bad solder joints finally let loose during cleaning of the mainboard. Happened to me once where the chipset southbridge legs came loose from their solderpads during washing.

So before attempting a BIOS flash, I would do a close inspection of the mainboard with a microscope or strong magnifying glass. Carefully trying to wiggle the legs of large chips with a needle will quickly show if they are still bonded with their solderpads.

About the 32KB CMOS SRAM, yes it is used for storing BIOS data and Plug&Play tables for the OS. Being an industrial machine, this SRAM probably holds more elaborate machine configuration data as well.

Last night I found the x453 BIOS on the Fujitsu support website, exactly the same file you showed in your other thread. So we must have found it at the same time! 😉
The BIOS in this self-extracting zip-file is the B56_K.LDB (256KB) file. I put this BIOS in the 86Box emulator and used a 430VX virtual machine of comparable design (Compaq Pressario 4500). The BIOS worked fine so B56_K.LDB is a valid BIOS file. Although this Compaq virtual machine has no emulated UM61256A SRAM and the BIOS Setup data couldn't be saved, the BIOS booted without issue so I believe that a problem with the 32KB SRAM will not cause the POST_61 hang you see.

Jan

Chkcpu wrote on 2024-01-19, 08:57:

As the x453 worked before you dismantled and cleaned it, I now think it is less likely that the BIOS is borked. Perhaps some bad solder joints finally let loose during cleaning of the mainboard. Happened to me once where the chipset southbridge legs came loose from their solder pads during washing.

So before attempting a BIOS flash, I would do a close inspection of the mainboard with a microscope or strong magnifying glass. Carefully trying to wiggle the legs of large chips with a needle will quickly show if they are still bonded with their solderpads.

Yes, I agree, I had considered this, though I was gentle during the wash. This machine DOES have some VERY fine pitch chip legs, and I suppose these would be weaker.
I have done the pin wiggle treatment on the SRam and the BIOS chips, nothing appeared awry, for the BIOS though, it has VERY fine pin pitch so there could of course me an issue. I suppose push come to shove, I could try and re-flow each in turn, to see if it fixes things. But its possibly destructive, so Ill hold off for now...

Chkcpu wrote on 2024-01-19, 08:57:

About the 32KB CMOS SRAM, yes it is used for storing BIOS data and Plug&Play tables for the OS. Being an industrial machine, this SRAM probably holds more elaborate machine configuration data as well.

Well, a bit of a development here, in the manual it says you can shadow various devices, and it then goes on to list how it works... look on page 4-2 bottom 3rd
m64vtedo - On-board video BIOS for e452/652 (EDO RAM) - not this machine..., but on the e machines (cheaper) video is shadowed to system RAM
m64vtsd - On-board video BIOS for x series(SGRAM)

SGRAM is where the Video BIOS should be shadowed, not main system? Suggest the 32k chip would be this place, and if it were to be borked, then you would have no video, right?
the chip is a 32k, high speed, 12ns CMOS SRAM (not SGRAM?). Seems overkill for high speed, 12ns chip to be used just for settings. But would make a lot of sense for the video BIOS shadow location right?

Chkcpu wrote on 2024-01-19, 08:57:

Last night I found the x453 BIOS on the Fujitsu support website, exactly the same file you showed in your other thread. So we must have found it at the same time! 😉
The BIOS in this self-extracting zip-file is the B56_K.LDB (256KB) file. I put this BIOS in the 86Box emulator and used a 430VX virtual machine of comparable design (Compaq Pressario 4500). The BIOS worked fine so B56_K.LDB is a valid BIOS file. Although this Compaq virtual machine has no emulated UM61256A SRAM and the BIOS Setup data couldn't be saved, the BIOS booted without issue so I believe that a problem with the 32KB SRAM will not cause the POST_61 hang you see.

You know, its kind of crazy that 26 years after this machine was launched, they STILL have its BIOS and other related docs on their support site. I earlier tried the wayback machine to find the files and no luck. So lucky they still keep these up there. I wonder where I could store these files, for retro peeps, to make it independent from Fujitsu. I have mainboard pics, etc. Would be good to add those to a resource...

So, I bought a 3,5" floppy drive, it arrived today and I have the BIOS files ready to go, but, I think I will be unable to carry out flashing the BIOS as there is no video. Anyway, Ill hold off for now. Read above, maybe the focus has shifted back to that SRAM chip being the fault. it DOES seem a bit dead (not shorted) but its pretty inactive on power on, whilst the main BIOS chip has signals, so maybe this IS the Video shadow chip?

Cheers

Chris

The SRAM is what contains the standard CMOS table, and the extended ESCD configuration table, as well as the value of the RTC, and any other board specific registers the bios needs to set itself up.

I would investigate the system memory, as suggested.

The DOS system architecture maps the system roms, including the shadowram, into the 384kb of address space just after the bottom 640kb of ram.

On most (all?) motherboards that do hardware mapper functions for this, the chipset doubles as a programmable mapper chip, and digitally disables the system ROM chip, and maps in a block of DRAM on the appropriate address lines.

This functionality can be used after system bootup on some older boards, like chips&tech based 286/386 boards, to get hardware upper memory blocks.

Since under original design considerations, the 384k 'adapter rom region' was purposefully left unpopulated (other than the last 64k of it, reserved for the system bios rom), the ability to arbitrarily put RAM there, to house TSR programs, or software device drivers/handlers, the abuse of this mapper capability to put RAM in unused blocks there, and disable the write protection, was a useful kludge.

Many programs exist to do that, all the way up into the PCI era, which is what UMBPCI does with the southbridge.

In legacy systems, like the C&T based ones I mentioned, dedicated utilities to do this exist, and can be found in droves in places like the simtel bbs archive.

The location being mapped by the mapper function of the chipset can be either the system ram (most probably), or the video ram (only probable if the igp has discrete memory.)

I would investigate the memory sockets, and inspect the legs of any dedicated ram used by the igp.

Other potential places impacted that might cause this are debris in a card slot (ISA bus exposes low memory address lines, etc.) Or debris underneath/behind the chipset chips, shorting the bus.

I just skimmed through your video and around 29:40 you indicate this big chip with lots of pins is the bios... I disagree and would like to know the id of the chip.
edit: I believe it to be the multi IO controller that is there to support the floppy, serial, parallel, ps2 ports...
The bios chip is normally the (e)eprom and is likely the CAT28F002 you mentioned. In systems such as this one it also likely contains the VGA BIOS as well as the system BIOS

Do you have any photos of the mainboard where the chip ids can be read ?
I tried to find it on theretroweb but it's not there and a quick google didn't turn up anything useful.

edit2: also the UM61256A is likely the TAG RAM for the cache.

Hi Chris,

Now that I have the x453 BIOS running in 86Box, I can show you some pictures.
This is the initial boot screen:

It is indeed an OEM Fujitsu system BIOS, unlike any AMI/Award/Phoenix BIOS I’ve ever seen.
Note the two error messages due to lack of COP and CMOS SRAM support in 86Box.
Another nice thing I’ve noticed is the present POST code indication in the righthand top corner. 😀

Retronaut wrote on 2024-01-19, 16:19:

Well, a bit of a development here, in the manual it says you can shadow various devices, and it then goes on to list how it work […]
Show full quote

Well, a bit of a development here, in the manual it says you can shadow various devices, and it then goes on to list how it works... look on page 4-2 bottom 3rd
m64vtedo - On-board video BIOS for e452/652 (EDO RAM) - not this machine..., but on the e machines (cheaper) video is shadowed to system RAM
m64vtsd - On-board video BIOS for x series(SGRAM)

SGRAM is where the Video BIOS should be shadowed, not main system? Suggest the 32k chip would be this place, and if it were to be borked, then you would have no video, right?
the chip is a 32k, high speed, 12ns CMOS SRAM (not SGRAM?). Seems overkill for high speed, 12ns chip to be used just for settings. But would make a lot of sense for the video BIOS shadow location right?

Cheers

Chris

I agree that page 4-2 of the manual is not very clear.
The text under Shadow option proms and BIOS modules are two different blocks about two different Setup pages and have little to do which eachother.
Now that I have the BIOS running, I can show you these pages.
The Shadow option proms text talks about this page:

On this Setup page you can Disable or Enable shadowing of option ROMs. In this example, the only ROM that can be shadowed is the Video ROM at address C000h. As indicated before, Shadow RAM is always taken from main memory.

The BIOS modules text tries to explain this Admin/Module page:

This is really low level stuff and best left alone. 😉
But it is interesting to see that there are 2 different versions of the Video ROM to cater for different videochip revisions, just as indicated on page 4-2 of the manual.
Your x453 has the version with SGRAM video memory. SGRAM stands for Synchronous Graphic RAM. SGRAM is a special kind of SDRAM that speeds up typical block move patterns often used on graphic data in video memory.

So SGRAM is the Video memory (2MB on your board) and has nothing to do with Shadow RAM or CMOS SRAM.

Hopefully I explained this more clearly than the manual. 😉

Cheers, Jan

OK, for anyone concerned, here is a photo of the logic board
https://www.dropbox.com/scl/fi/mun5j1vhemhmho … djvhjco4j0&dl=0

So, there are some competing views, and others not so much. But what I need to really focus in on here, is WHAT do I do next.

Right now, it appears that the 32kb SRAM chip (UM61256A), near the BIOS (CAT28F002T) chip, is probably not the issue. Others have suggested that the BIOS chip itself is probably not at fault.

BTW, I originally though the chip labelled Megatrends was the BIOS, as American Megatrends is AMI, right? But it turns out they made other chips like this
I have the data sheet for it now, and yes its an input output chip. CAT28F002T appears to be the actual BIOS chip

I have already tested the system RAM, on a basic level, by inserting the original, previously seen working DIMM, and two new 32mb DIMMs (exact same spec), and they all show the same behaviour.
When there is no DIMM inserted, the machine complains/beeps, there is an issue in base RAM aka, where is the memory Joe?

You plug in the DIMM and the beeping stops and more post codes flow until the last code, 61 stating its decompressing the BIOS
The next post code would be 62, Deploying BIOS, but it never gets there
There is no corrupt BIOS warning, no beeps, nothing, it just halts and hangs

So, it appears there is SOME kind of basic BIOS in place, as beeps are issued when no ram is plugged in, and it also cycles through what look like valid POST codes, testing ram, testing floppy etc
This is what they call the BOOT BIOS I think, and its protected in the chip, it says it has that feature in the product info sheet

I have had advice from an engineering perspective, to whip out the SRAM and replace it. But others now feel that's not likely the issue, at all

I'm a bit at a loss.

On the plus side.
I do now have the BIOS update files on floppy, and this machine supports low level, no video needed flashing of the BIOS, which is great
So I could try flashing it, to see if the BIOS became corrupted, but this may be a risk
However, I'm assuming that boot BIOS, is locked, and will not be flashed, only the compressed section of the BIOS, which its failing on
So it feels pretty low risk at this point, as is worth a try maybe, lets face it, its failing to unfurl the compressed BIOS, maybe that's because its corrupted....

So, finger in the air, any votes on what to do next?

Cheers

Chris
Retronaut

Yes, there ISA slots on the riser, try a simple ISA video card (I did not see you tried one yet) just to see if anything comes up. And in the future: do not wash and compress air blow a board, I ruined one same way, and Chkcpu (Jan) also mentioned.
added: Too bad the eeprom is soldered. Intel, Micron and a few other did that too but most all Asus, Giga, etc of same era were socketed (even ECS socketed)....

That's a nice photo. What camera did you use?

Considering you tried different memory modules, the POST code indicates the bios hanging somewhere around the shadowing.
I don't think the cache is already enabled. ChkCPU can probably verify this.
That would likely leave the big intel chip next to the battery as a probable cause, or a signal coming/going to it. I guess.

You do might want to use another ground point, while not your main problem, the one you're using now has a trace running right next to it on the edge of the board and some wiggling of the clamp might cause a short of it to ground. Just an fyi.

I did find a manual on theretroweb that says it's for the ergopro e x and s series but the mainboard depicted therein is an older model using an opti chipset.
There is a procedure for updating the bios flash, though it mentions shorting two pads somewhere on the mainboard which looking at the photo don't really jump into view.

I doubt trying an ISA video card will give any different results, but it likely also won't break anything.

edit, that odd yumpu site has the manual with the correct mainboard in it.
The flash procedures seem a bit odd to me.
pages 2-14 & 2-16 https://www.yumpu.com/en/document/read/279936 … book-fujitsu-uk
but no location of the " force flash load pads " for the AC41733 mainboard model. Maybe that model doesn't have those ?

Retronaut wrote on 2024-01-20, 01:26:

So, finger in the air, any votes on what to do next?

Cheers, Chris

When a thorough inspection of the motherboard, both front and back side, doesn’t reveal any suspicious solder joints or damaged traces, then I would vote for the Force FLASH load procedure from page 2-16 of the handbook. Although it is very unlikely you washed the BIOS away, I wouldn’t know what else to try at this point. 😉

weedeewee wrote on 2024-01-20, 04:32:

The flash procedures seem a bit odd to me.
pages 2-14 & 2-16 https://www.yumpu.com/en/document/read/279936 … book-fujitsu-uk
but no location of the " force flash load pads " for the AC41733 mainboard model. Maybe that model doesn't have those ?

I agree this is a peculiar flash procedure but it all depends on how the Bootblock code was written. Note that this BIOS recovery procedure calls for a blank pre-formatted floppy with only ONE file on it: the B56_K.LDB BIOS load file. So no need for a bootable floppy or a dosflash.exe program. All work is done by the Bootblock BIOS recovery code.

The location of the Force Flash Pads on the AC41733 board are indicated on page 2-17 of the handbook, in the lower half of picture 32. They are between DIMM slot 2 and the edge of the board.

I will keep my fingers crossed! 😉

Jan

Chkcpu wrote on 2024-01-20, 10:23:

The location of the Force Flash Pads on the AC41733 board are indicated on page 2-17 of the handbook, in the lower half of picture 32. They are between DIMM slot 2 and the edge of the board.

Oh FFS, I totally overlooked that.

nice catch.

weedeewee wrote on 2024-01-20, 04:32:

That's a nice photo. What camera did you use?

IPhone 14 Pro Max, using its 3x optical zoom, to avoid too much perspective.
If my @RetronautTech Youtube channel takes off, Id like to get a professional camera, and a decent ZOOM lens which would make these kinds of shots, with the right rig and lighting even better
I did photography in college, my tutors were mostly industrial photographers (food/cars etc) and there is certainly a technique to taking good flat shots like this
e.g. as little lense distortion as possible using a zoom lens, and multiple diffuse lights to avoid shadows, specular highlights
This is just me with my little old iPhone on my dining table, with winters daylight, which is quite diffuse...

weedeewee wrote on 2024-01-20, 04:32:

edit, that odd Yumpu site has the manual with the correct mainboard in it. The flash procedures seem a bit odd to me. pages 2-14 […]
Show full quote

edit, that odd Yumpu site has the manual with the correct mainboard in it.
The flash procedures seem a bit odd to me.
pages 2-14 & 2-16 https://www.yumpu.com/en/document/read/279936 … book-fujitsu-uk
but no location of the " force flash load pads " for the AC41733 mainboard model. Maybe that model doesn't have those ?

Yes, that site is a PITA, as they have grabbed that manuals PDF, converted it into individual images, and effectively locked it all behind a pay wall
The pay in this case is copious adverts and they have smothered all over the shop, some even OVER the manual.
Gah!
Anyway, I downloaded each page by hand, at high res, and I have converted it into a PDF, I just need somewhere decent to post it now, so this is open for future users to access fully.
In the meantime if anyone wants it. Send me your email via my email shown on @RetronautTech on Youtube , and Ill send it to you...

Cheers

Chris

Retronaut wrote on 2024-01-20, 12:53:

...Yes, that site is a PITA, as they have grabbed that manuals PDF, converted it into individual images, and effectively locked […]
Show full quote

...Yes, that site is a PITA, as they have grabbed that manuals PDF, converted it into individual images, and effectively locked it all behind a pay wall
The pay in this case is copious adverts and they have smothered all over the shop, some even OVER the manual.
Gah!
Anyway, I downloaded each page by hand, at high res, and I have converted it into a PDF, I just need somewhere decent to post it now, so this is open for future users to access fully.
In the meantime if anyone wants it. Send me your email via my email shown on @RetronautTech on Youtube , and Ill send it to you...

Cheers

Chris

You've got something now, but the original PDF is available on the FSC archive...

Chkcpu wrote on 2024-01-20, 10:23:

I agree this is a peculiar flash procedure but it all depends on how the Bootblock code was written. Note that this BIOS recovery procedure calls for a blank pre-formatted floppy with only ONE file on it: the B56_K.LDB BIOS load file. So no need for a bootable floppy or a dosflash.exe program. All work is done by the Bootblock BIOS recovery code.

The location of the Force Flash Pads on the AC41733 board are indicated on page 2-17 of the handbook, in the lower half of picture 32. They are between DIMM slot 2 and the edge of the board.

I will keep my fingers crossed! 😉

Well, locating those pads was a little iffy. Despite ICL doing a good job on MOST of the board, the two pads in question are un-marked. Maybe ICL wanted to stop people idly shorting these, but id rather they just have labelled them, anyway. they are very near the edge of the board, right next to the DIMM slots.

I shorted these, and.... nothing. Odd. Bit of panic set in, was I shorting something else, that might cause damage. No schematic here, so there a tiny bit of guess work involved, not ideal...

So I tried to short it again and... it went into its beeps, indicating it was shorted. I removed the short, as the manual said, and now it changed to insert the disk beep sequence
I inserted the disk, with JUST 56_f.ldb, the earlier bios, and the disc did its thing. In about 10 seconds, it appeared to reboot, and the POST code showed NEW CODES!

I checked the manual, and these were to do with checking the CMOS, and specifically the bit that indicates where the hard disk config 😀

So I plugged in my VGA monitor and turned it on, and

https://www.dropbox.com/scl/fi/8sjn1q0l1qd041 … q46cakffw2&dl=0

It BOOTS!

Got to say everyone, especially Jan. Thank you for your patience and clarity in explaining all this info. Recently I have repaired battery damaged Amiga 2000s and 4000s. But that was a whole different ball game. Those machines, especially the 2000 are from roughly 10 years earlier in terms of tech arch. So quite a lot about this PC was unfamiliar to me.

Im not quite out of the woods yet, its moaning about a battery not being plugged in, even though there IS one, and I tested it and it has 3v, so thats a bit of a worry. Also, I guess I should now try and installed the 2nd .exe based BIOS, as that was rev K, so I am assuming its a newer BIOS, but I think first, Ill make sure other things are working before getting that done.

Lets try plugging in the hard disk next, and a keyboard and see how far I can get this fella going.

Looks like there may be a pt2 to this video soon.

😀

Cheers

Chris