Electronics > Repair

What more i can do?

<< < (99/112) > >>

222Lab_Test222:

--- Quote from: asis on December 19, 2024, 01:13:46 am ---Hi,

Please tell me - what chips are on the FRAM bar (x4).

--- End quote ---
MX B190415 29F040C11-70G5C531600 TAIWAN

222Lab_Test222:

--- Quote from: m k on December 18, 2024, 03:18:33 pm ---
--- Quote from: 222Lab_Test222 on December 18, 2024, 07:56:19 am ---After the High and Low EROMS swap in Non Working Board.

--- End quote ---

Measured from where?

What say CPU BS8, BS16, BNE0 and BNE1?

--- End quote ---
I do not understand can you clarify a bit?

m k:
BNE should be BE.

You've only measured 8 bits, other ROM is missing.

All data lines rice when power comes on and nothing changes until all of them are dropping down.
If data is FFFF it becomes invalid and generates an exception, that means that program execution jumps to other location.
No jumps are present, exception location is in low RAM, so other side of 16 bit data must be something else than FF.

Your 486 manual p.105/224 has a table 7.4.
There you have how memory is accessed compared to those four mentioned signals, there are also situations when only D15-D8 are used.
Your original data and address scopes for faulty board have first data bytes 0D 0D, if we believe that Harry didn't do any mistakes.
Same data for functioning board is 0D E9, but we know that this can't be right, there must be a jump and 0D as first byte will eat the next byte.
So data order is swapped and E9 is the first byte, so next byte pair is also swapped and so first program code is jump to F800, relative and backwards, jump address is negative, and its byte order is swapped again.

Next we can check the combined ROM image and see that F800 has
F800 FA (CLI)
F801 E4 (IN)
F802 35 (port)(irq controller)
F803 A8 (test)
So completely rational start of a code.
We can also be pretty sure that Harry didn't do any mistakes.

Same page of the manual has also figures 7.3 and 7.4.
There you can see how Intel think the situation should be handled.
Native style is 32 bit memory, there both BS8 and BS16 are high all the time, that is not your case.
So those signals can tell whether your system has a possibility to operate or not.

From table 7.4 you can see that there is a possible situation where only D15-D8 is constantly in use.
So our earlier 0D 0D data situation is totally plausible.
But before you go any further you must verify the situation.
And only after then, if the situation really is that, you start figuring out how your system has generated the addressing of figure 7.4.

Bus Size signals should probably be BS8 up and BS16 down, those are inputs, so you can't be sure just simply measuring their levels.
If BS8 is down from the beginning you can be pretty sure it's a fault, there should be 16 bit ROM data first.
Byte Enable signals are outputs, so if any of them is constantly down you be pretty sure again that it is a fault.
Next page of the manual has more examples how data access can be made.

One more thing, page 108/224 and unaligned transfer, it's not very straight forward what data bus should contain at certain moment.
But it is certain that first functioning pair of bytes can't be 0D 0D.

Normally data bus is empty first.
For 16 bit operation another bus cycle is needed, table 7.3 has them.
So first D15-D0 is read and BE0-3 are all down, then D31-D16 is read and BE0-1 are up.

222Lab_Test222:

--- Quote from: m k on December 18, 2024, 03:18:33 pm ---
What say CPU BS8, BS16, BNE0 and BNE1?

--- End quote ---
Here are signals for Non-Working Board

222Lab_Test222:
Continue Images for Working Board

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod