Is it the 505 or 540 Board at fault?

[lowrybt1]

I have a C8PDF that was working great until today when I did the following:

- Remove and reseat the A-12 board (I was taking photos of it)

- While removing and reseating the A-12 board, I dislodged (without noticing) the white wire that goes from the J1 connector of the 540B board to the R1 Fine Color Adjustment dial at the back of the case (see pics)

- Powered up the C8PDF with the aforementioned white wire out of place and presumably in contact with the bottom of the case (I have now reattached the wire with the appropriate contact on the R1 Fine Color Adjustment dial.)

When the machine powers up, I get the expected graphics mashup screen
When I press the reset button, I see the expected H/D/M but a few lines below there is a row of characters that reads (/$/-/

20240304_200904.jpg (638.03 KiB) Viewed 360 times

When I press D, I get the following:

20240304_200952.jpg (1.25 MiB) Viewed 360 times

I have reseated the 505 and 540 boards and reattached the wire to the R1 fine color adjustment. I still continue to see the same (/$/-/ text when I press reset and there is no action with the A drive when I press D. Perhaps there was an electric short due to the loose white wire that did damage to some component on the 505 and/or 540 boards.

Any thoughts on next steps for diagnosing and repairing the damage would greatly appreciated!

[Mark]

Does the OSI boot prompt normally show up off the top of your monitor?

(/$/-/ = H/D/M? but bit 6 -> bit 5 ($48->$28, 2F is unchanged, $44->$24 ... then 3F->2F

The mirroring looks like its 4 lines down or $100 bytes That is strange as the video counters seem to be correct, but the addresses from the CPU are writing to two memory locations? The fact that the screen cleared means the CPU seems to be able to access all the display memory locations, or at least half with mirroring...

When you press any key at H/D/M? other than H or D, OSI will go into ROM monitor. So OSI is thinking D is some other character. It's also not going into monitor right at reset so it can read "no key pressed". (BTW, Is shift-lock down?)

Are you able to find any keys that change the ROM monitor display? What do they display vs what did you type? If you can find an L key equivalent, you could manipulate ROM monitor via serial port to read and write memory locations etc.

Seems like a data bus problem maybe. Try swapping 8T26s around and see if the problem changes? Just guessing...
Good Luck!

[lowrybt1]

Thanks Mark.

Yes, the OSI boot promptly normally shows up off the top of the HDTV and offset left slightly. When I press M, it goes into the monitor and there is a similar mirroring going on, meaning 4 digits for the memory location, a space, and two digits for contents. A few lines below, alphanumeric characters appear aligned with the memory-space-contents above but I can't discern a pattern. The shift lock is down.

I'll try switching the 8T26s. Is there someway, a short could have fouled up a component on the 542?

[lowrybt1]

Thanks Mark.

Yes, the OSI boot promptly normally shows up off the top of the HDTV and offset left slightly. When I press M, it goes into the monitor and there is a similar mirroring going on, meaning 4 digits for the memory location, a space, and two digits for contents. A few lines below, alphanumeric characters appear aligned with the memory-space-contents above but I can't discern a pattern. The shift lock is down.

I'll try switching the 8T26s. Is there some way, a short could have fouled up a component on the 542?

[lowrybt1]

Update.... The C8PDF is booting and responding as it should to all keyboard inputs BUT..... There continues to be a screen mirroring or memory overwrite issue affecting the top half of the screen/video memory. See pics below. Based on a layperson's reading of the SAMS manual, this sounds like an issue with video address decoding but I really don't know circuits well enough. Mark has proposed swapping around the 8T26s (i assume on both boards) which is my next step. I also have a spare 540 board but the molex connector for the video/sound/color adjustment broke off and I'm waiting for a replacement part to see if the spare solves the issue.

Based on confirmation that the power-on screen shows the traditional graphics mashup, that the system resets and boots as it should (and provides access to the Monitor) and that the mirroring/video issue seems to be confined to the top half of video memory, is there any indication here (in the pics) that the issue can be narrowed further to specific components on the 505 or 540 boards?

Thanks, Tom

20240305_135403.jpg (3.08 MiB) Viewed 340 times

20240305_135521.jpg (2.62 MiB) Viewed 340 times

20240304_200904.jpg (638.03 KiB) Viewed 340 times

[Mark]

Well if you have it booting, and the data buffers seem to be working, and the corruption only occurs in the 1st half of the screen and only for the upper bits, my next guess is a bad 2114 RAM chip - U2F. I can't really explain the video mirroring otherwise unless there is some sort of short in the screen address generation.

If you enter ROM monitor and write $FF to and address of the screen, say $D244 what do you read back?
type .D244/FF
<RETURN> 00<RETURN> 55 <RETURN> AA
then
.D244/ & read value press <return> read next value & so on.

My guess is lower 4 bits are correct, upper 4 are mangled & you might see duplicate rows on screen

D244.gif (1.92 KiB) Viewed 337 times

[lowrybt1]

Mark,

Thanks for sharing your expertise. The following is a link to my youtube channel and a video of the test you proposed.

https://www.youtube.com/shorts/dXQRsvvOeLE

Tom

[Mark]

Truly bizarre....

Try swapping 2114s U2F (high nibble of low video ram) & U1F (low color ram) unless you have a spare one to use instead. They should be socketed.

[lowrybt1]

Thanks Mark. I have some spare 2114L's stored away and will go find them and try them out. If there is a short in the screen address generation/decoding, that would be on the 540, right?

[Mark]

Yeah, also check the lower 4 bits of the 1st 1K video RAM U2C...

What is causing the mirroring? Bad RAM? Flakey multiplexer- U5I 74LS157? Stray bit of wire?

If you still have issues, besides writing to $D244 as before, then also try writing to D344 with the same sort of data as before. Does writing to higher addresses affect lower addresses?