RiscPC palette weirdness

discuss the archimedes & risc pc, peripherals and risc os/risc os on pi
Post Reply
Boydie
Posts: 458
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

RiscPC palette weirdness

Post by Boydie » Sun Nov 03, 2019 1:35 pm

I'm trying to fully resurrect a RPC 600 (0197,100) following battery leakage. There are a few issues, probably best dealt with one at a time. The first one is a somewhat bizarre colour palette in RO 3.6/3.7. In RO 3.5, all colours are fine. However, in 3.6 the palette goes seriously screwy:
VRAM startup.JPG
Startup
VRAM splash.JPG
Splash screen
VRAM desktop.JPG
Desktop
Edit: Startup screen is now showing black on red rather than white on red.

I've continuity tested all the way from ICs 22/26/30/33 to the relevant pins on VIDC, and all is fine. Changing VRAM also has no effect.
What would make the palette fine in one version of riscos, but not in another?

What may (or may not) be a linked issue is that, whilst the machine is fine with VRAM fitted, the display has vertical bars in some areas if the VRAM is removed. I'm assuming this suggests some error in the pathway between the normal ram and the video bus?
This is in RO 3.5:
RAM 35.JPG
3.5 no vram
RAM 35 desktop.JPG
3.5 novram desktop
And in 3.6:
RAM splash.JPG
ram splash
RAM desktop.JPG
ram desktop

Boydie
Posts: 458
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: RiscPC palette weirdness

Post by Boydie » Sun Nov 03, 2019 8:23 pm

This has been a day of *very* tedious tracing.
So far, I have found:

All pins of D0-D31 have continuity, from the RAM socket, to the relevant buffer IC (22/26/30/33), to the relevant resistor pack (which has appropriate resistance), to the relevant Vcd input on VIDC.
Pins 1 and 19 on the buffer ICs all have continuity to cdoe on IOC, so they should be switching okay between VRAM and no-VRAM.
On the VRAM socket, all D0-D31 pins have continuity to the equivalent pin on the RAM socket, and all Vcd pins have continuity to the relevant resistor pack feeding into the corresponding Vdc on VIDC.

So, although this smacks of a bad link between VIDC and the resistor packs, everything appears to be peachy.

Any suggestions where to look next?

philpem
Posts: 524
Joined: Fri Apr 04, 2014 6:42 pm
Contact:

Re: RiscPC palette weirdness

Post by philpem » Mon Nov 04, 2019 2:25 am

Assuming you've done a Delete-POR and cleared the CMOS...

My first port of call would be checking the SIMM sockets, SIMMs and so forth. Swap in a couple of known good SIMMs, try different amounts of RAM and so on.

The next thing would be to check not just the wiring of the VIDC <--> bus buffers, but swap them out. They can fail, and most failures won't pop up on a continuity test.

Resistor packs - I'd check them individually. Also look for any signs of damage (or green traces) around the battery and CMOS.

Boydie
Posts: 458
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: RiscPC palette weirdness

Post by Boydie » Mon Nov 04, 2019 7:46 am

Yeah, resetting the CMOS is the only way I can get it to show anything.
Both simm sockets have been tested, right the way from the individual pins, and are fine to both the buffers and the equivalent D pin in the vram socket. I’ve not tested the other pins in the simm sockets yet...
Symptoms are the same in either simm socket, with any one or two of half a dozen simms (all FP, not EDO). Also the same with a different vram stick.
I’ve also checked out the upper 32b input to the vidc - that’s all fine too.

I also think I’ve discovered a collective misconception (or a personal error in my interpretation of it) regarding the buffer chips and resistor packs. Looking in the TRM and circuit diags, isn’t the role of these to switch whether D0-31 from the system bus can become Vcd0-31?
Ie No vram fitted, these are activated (via cdoe) and Vcd0-31 come from D0-31, going through the resistor packs. Obviously, clash with Vcd from the veam isn’t an issue because it isn’t there.
Whereas, if vram is fitted, cdoe deactivates the buffers so D0-31 cannot reach Vcd. In this case, Vcd from the vram pins is directly wired to the relevant pins on vidc, and the condition/presence of the buffers and RPs is irrelevant. This would seem to be the case because there isn’t 68 Ohms resistance between the vram and vidc.

If this is correct, you may well be right about the buffer chip causing the vertical lines when no vram is fitted.

But what on earth is causing the palette issues, and why doesn’t it happen in RO 3.5??? Surely a dodgy Vcd trace would manifest in all versions of the OS? What do later versions do that 3.5 doesn’t?

Boydie
Posts: 458
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: RiscPC palette weirdness

Post by Boydie » Mon Nov 04, 2019 9:33 am

It's now not recognising the keyboard that it was quite happy with yesterday.
The list of issues is growing, and I suspect it's time to take it down to the bottom of the garden and shoot it. :(

I'd still dearly love to know why there's a difference between RO3.5 and later variants in terms of colours.

User avatar
danielj
Posts: 8331
Joined: Thu Oct 02, 2008 5:51 pm
Location: Manchester
Contact:

Re: RiscPC palette weirdness

Post by danielj » Mon Nov 04, 2019 9:52 am

RO 3.5 is a smaller ROM IIRC? Could be something around that?

d.

User avatar
BeebMaster
Posts: 3520
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: RiscPC palette weirdness

Post by BeebMaster » Tue Nov 05, 2019 12:08 pm

Some of those pictures look like something has gone awry with the logical to physical colour mapping (assuming it's the same principle as used in Beebs): it looks like somebody has been playing about with VDU 19 to change black (and green) to red, for example, and the everton mint stripes remind me of a GCOL 16 graphics fill pattern.

PRM suggests the ColourTrans module governs all this in RISC OS, maybe something is wrong with that (or it's using corrupt RAM)?
Image

Post Reply

Return to “32-bit acorn hardware”