Force changing the screen mode on Risc PCs

discuss the archimedes & risc pc, peripherals and risc os/risc os on pi
Post Reply
lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Force changing the screen mode on Risc PCs

Post by lista6559 » Sat Aug 01, 2020 6:14 pm

I have a large heap of old Risc PC hardware... including six motherboards! - in varying levels of condition and corrosion. I've removed the leaky batteries, thoroughly cleaned the PCBs, soldered new battery holders etc... Hopefully each of these can become a full working system. I have two motherboards (seemingly) fully working now - as in, booting to a desktop from a CF card. Of the other systems, one motherboard suffered the most corrosion damage - the most I've ever seen - and I suspect a dead CMOS chip on another.
Anyway, sheer pride of stock aside :D the main problem I face is forcing the PCs to output in a 31khz or greater resolution. I saw a post some time ago by Z80 about shorting pins to force the mode change - unfortunately no avail. I have a cheap CGA-VGA converter board (GBS8200-compatible) that works but fails to sync lock - I also found an article about swapping sync pins, which I may find/post link to/try if there is no better option. Just wondering if there's any failsafe way to change the resolution on boot. Thanks in advance for any advice!

User avatar
DutchAcorn
Posts: 2265
Joined: Fri Mar 21, 2014 9:56 am
Location: Maarn, Netherlands
Contact:

Re: Force changing the screen mode on Risc PCs

Post by DutchAcorn » Sat Aug 01, 2020 6:45 pm

Is

*condigure wimpmode

what you are looking for? I thought mode changes using the desktop configuration tool were persistent on a RiscPC?
Paul

Image

steve3000
Posts: 2254
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: Force changing the screen mode on Risc PCs

Post by steve3000 » Sat Aug 01, 2020 6:53 pm

lista6559 wrote:
Sat Aug 01, 2020 6:14 pm
...the main problem I face is forcing the PCs to output in a 31khz or greater resolution. I saw a post some time ago by Z80 about shorting pins to force the mode change - unfortunately no avail. I have a cheap CGA-VGA converter board (GBS8200-compatible) that works but fails to sync lock - I also found an article about swapping sync pins, which I may find/post link to/try if there is no better option. Just wondering if there's any failsafe way to change the resolution on boot. Thanks in advance for any advice!
If you perform a CMOS reset on switch-on (hold Delete), with the RiscPC plugged into a VGA/SVGA monitor, it will detect the monitor and select 31khz output... assuming it's working :)

lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Re: Force changing the screen mode on Risc PCs

Post by lista6559 » Sat Aug 01, 2020 7:29 pm

Sorry - in my rush to reply before my laptop's battery depleted, I missed the key detail #-o - I can get the machines to 'boot' by holding down delete (otherwise nothing happens at all). The drive clicks and the keyboard lights flashes, with CAPS LOCK becoming responsive. The card light flickers so I know the machine is booting from disk. If I use the CGA-VGA adapter I can occasionally see a cursor fly past on the unsynced video, and once I believe I saw the icon bar - though unfortunately I didn't think to access Supervisor to semi-blind bash in *Configure commands. I've never got that far again, so I guess the machine is showing a Floppy Boot dialog. What I really want to know is if there's a better way to try and change the monitor type to 31khz; when I plug the monitor in directly nothing seems to remedy the dreaded signal out of range error. I've tried holding numbers down to set a mode but nothing seems to work. I know ROMs, RAM etc. is good though I don't really know how that would be relevant here as the operating system is clearly loading correctly. I've tried many monitors, even one supposedly working as listed on http://15khz.wikidot.com/, though only the Australia model is quoted as reliable.
This problem seems specific to Model 1 MBs, so I wonder if they default to the lower resolution modes.

Thanks again!

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

Re: Force changing the screen mode on Risc PCs

Post by philpem » Sat Aug 01, 2020 7:41 pm

If they'll boot when you do a delete-power-on but won't boot after, then you have an issue with the CMOS RAM area of the board, near the battery.

There are a few possibilities -- the battery power isn't getting to the CMOS when the power's off, the machine can't communicate with the CMOS chip, or the chip is dead.

Stopped clock (bad crystal/bad chip) won't usually prevent booting but the clock will do weird things (usually lose time when the OS tries to sync up with the CMOS chip).

Cheers
Phil.

steve3000
Posts: 2254
Joined: Sun Nov 25, 2012 12:43 am
Contact:

Re: Force changing the screen mode on Risc PCs

Post by steve3000 » Sat Aug 01, 2020 7:43 pm

Even the earlier A5000, A30x0, A4, etc. running RISC OS 3.1 all detect a connected VGA/SVGA monitor and select 640x480@60Hz, 31.5khz, after a CMOS reset, if the PCB is working. So the Risc PC running RISC OS 3.5 or later will be doing this, if the CMOS reset is completing correctly (ie. holding Del from before switching on, and keeping held down until after you hear the beep) and the PCB is OK. You can also try holding 3 or 4 on the keypad at startup in the same way, which is how VGA and SVGA were selected on earlier Archimedes, and may still work?

Also worth confirming your screen is compatible with 640x480@60Hz? Some modern LCDs don't like early VGA modes.

lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Re: Force changing the screen mode on Risc PCs

Post by lista6559 » Sat Aug 01, 2020 8:25 pm

Thanks guys for getting back so quickly!
philipem - that's exactly what happens, delete must be pressed for the machine to boot at all. I'm pretty sure the chip is dead, as I can measure a voltage across the pins, though not quite sure which ones 8) . I was hoping I'd be able to get to a desktop anyway though, as then I could at least try the 'kick': in viewtopic.php?t=9296#p107138 Z80 seems to suggest this can sometimes help...
...but I couldn't get settings to stick (I later realised the CMOS needed the clock kick trick)...
steve3000 - the beep sounds fine so I guess it thinks it's successfully flashed. Holding down numbers has never worked for me, and I must say I'm beginning to doubt its authenticity as I've never heard of it actually working successfully... :wink: whatever I do results in a timing error. I've switched to a monitor that should definitely support that resolution, and still to avail. It's particularly frustrating as I've seen the cursor so at least something is running fine, and therefore there should be a solution!

Once again, thanks for your help thus far! It may come to me ordering some new CMOS chips from China (yes, I know CJE does expensive boards :P , though their service does make up for that).

Cheers!
L

User avatar
helpful
Posts: 603
Joined: Tue Sep 22, 2009 1:18 pm
Location: London
Contact:

Re: Force changing the screen mode on Risc PCs

Post by helpful » Sat Aug 01, 2020 11:42 pm

lista6559 wrote:
Sat Aug 01, 2020 8:25 pm
Holding down numbers has never worked for me
Just checking that you are holding down the numbers on the numeric keypad, not on the main keyboard?

To check if it really has started up ok, try pressing F12 and then Ctrl-G which should beep. Then try entering "WimpMode 28" to switch to VGA mode, which any monitor should display.
If I use the CGA-VGA adapter
???
I guess the machine is showing a Floppy Boot dialog
What floppy boot dialog? After a delete-power IIRC it willl go to the desktop without trying to boot from anything.

Bryan.
RISC OS User Group Of London - http://www.rougol.jellybaby.net/
RISC OS London Show - http://www.riscoslondonshow.co.uk/

lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Re: Force changing the screen mode on Risc PCs

Post by lista6559 » Sun Aug 02, 2020 8:18 am

Thanks Bryan - I think we might be getting somewhere!
helpful wrote:
Sat Aug 01, 2020 11:42 pm
Just checking that you are holding down the numbers on the numeric keypad, not on the main keyboard?
Yes, though in this case I'd prefer to have been stupid and have everything work by correcting that! I actually tried both the main keyboard and the numpad with no effect.
To check if it really has started up ok, try pressing F12 and then Ctrl-G which should beep. Then try entering "WimpMode 28" to switch to VGA mode, which any monitor should display.
The Ctrl-G test works! Therefore we're clearly in the shell. Unfortunately WimpMode 28 does not help, though with my adapter (see below) I can see a distinctive change in the flicker.
If I use the CGA-VGA adapter
???
Aah yes, this should be a solution to all everyone's mode problems ever... but it doesn't work! it is a cheap (under £20) board from China - the GBS-8200 - which can supposedly take in 15khz video (through a VGA cable) and output in a higher (selectable) resolution. Unfortunately, it doesn't work even with a fully functioning machine.
Image

Image

- two stills from the GBS-8200's continuous scrolling, flickering display - like an out-of-sync CRT. The only similar issue I could find is with viewtopic.php?t=10244, but I couldn't see anything in the technical reference for the Risc PC about a similar sync pin swapping issue. However, I tried using the RGB header on the board, poking the six small jumpers into the corresponding pins on the VGA and connecting the relevant ground pins in order to try swapping the sync - but no picture even with them the right way round.
What floppy boot dialog? After a delete-power IIRC it willl go to the desktop without trying to boot from anything.
Makes sense... and proven as above! I can never quite remember where in the process different dialogues, prompts etc. will appear!

I think knowing we're in supervisor is a key phase - I wonder if it's a *Configure issue - MonitorType, Sync etc. but nothing I've tried helps! That's why I tried shorting pins 4,10 and 11 (which I think Z80 said worked) which did seems to give me a red screen while one Motherboard was flashing out a floppy post code, but then the same problem after. Even leaving the jumpers in after getting the beep then switching back to VGA doesn't seem to work.

This is one of the weirdest problems I've ever encountered - the system works but nothing I do seems to give a display output that works...

VRAM. Writing that I just wondered if adding some VRAM (which I'd left out to reduce variables) in would allow it to display in a mode that I could see... the first boot no difference, the second something a bit different. So I tried removing the GBS-8200 from the equation, giving the first picture I'd ever got directly on the monitor:
Image

Yuck. Vertical banding, off colours and pointer flickering and ghosting. Moving the mouse results in variations in this and it seems to be limited to a box in the top-right - like a lower resolution being padded out. The F12-beep still works. I'm split between this being a configuration or hardware fault. I wonder if a single resistor or other simple SMD has been damaged due to corrosion - I'll have a closer look at the PCB at some point.

That's basically where I'm at - I think I've covered everything I've tried so far. Thanks in advance for any further assistance!
L

lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Re: Force changing the screen mode on Risc PCs

Post by lista6559 » Sun Aug 02, 2020 8:34 am

A debugging summary for reference, including some more quick tests:

System won't boot without DEL being depressed
Desktop is clearly reached as F12 and Ctrl-G makes a beep
No *Configure commands appear to have any effect - including mode changes and beep volume/voice
I think something makes the system hang after a few minutes, but this is not confirmed
Ctrl-BREAK seems to hang the system on reboot
Adding VRAM gives a horribly distorted display at VGA resolutions; without it something (unknown of what quality - the GBS never gives a good picture even with a working system) is output at 15khz
To me, this is definitely pointing to a dead CMOS chip, but the video issues may point to something far more fundamentally serious

Thanks again.

lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Re: Risc PC video faults

Post by lista6559 » Sun Aug 02, 2020 3:59 pm

I'm wondering if this could be related to the infamous RP16 and its connection to VIDC - I wonder if anyone in the know could point me in the right direction with testing this.
After/if I fix this, as I said, I'll write up a post of sorting out similar issues as I've seen lots of threads on video problems but no single place for debugging and fixing.
Cheers,
L

Kazzie
Posts: 1782
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Risc PC video faults

Post by Kazzie » Sun Aug 02, 2020 7:32 pm

lista6559 wrote:
Sun Aug 02, 2020 3:59 pm
I'm wondering if this could be related to the infamous RP16 and its connection to VIDC - I wonder if anyone in the know could point me in the right direction with testing this.
After/if I fix this, as I said, I'll write up a post of sorting out similar issues as I've seen lots of threads on video problems but no single place for debugging and fixing.
Cheers,
L
RP16 is effectively a pack of eight resistors side-by-side. One end of each goes to the VIDC, the other end is connected to the adjacent buffer chip (a 74ACT244), which can connect or isolate it from the main data bus. This arrangement is duplicated four times along the gap between the VRAM slot and the first DRAM SIMM (on my issue board), to buffer all 32 bits of the data bus. The only reason RP16 gets all the attention is because it's nearest to the battery area, and first in the firing like for battery damage.

To check RP16, follow the pinouts from the RiscPC technical manual, and check for continuity between the relevant VIDC pins and RP16. Then check for continuity between the pins on the other side of RP16 and the '244. Finally, measure the resistance across each pair of pins on RP16, all eight should measure 68 ohms, plus or minus tolerance.

If any of the continuity tests fail, there may be damage to a via going through the board, possibly underneath RP16 itself. You could bypass it with a patch wire of your own along the board's surface, or you could remove RP16 (if needed) and attempt to repair the via itself. A failure of one of the resistors would mean replacing the resistor pack itself.
BBC Model B 32K issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
RiscPC 600 under repair
Acorn System 1 home-made replica

lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Re: Risc PC video faults

Post by lista6559 » Mon Aug 03, 2020 7:35 am

Thanks Kazzie - that was very useful, and as soon as I found the schematic it was plain sailing :D , and apart from a false negative when I realized the VIDC jumped pin 52 in sequence from VCD 5 to 6 =D> everything turned out fine. Hmm. Not what I was expecting. I haven't really heard of anything else that can give a similar problem, though the resistors directly under the battery look at bit questionable. Not really sure where to go next from here!

Cheers, L

Kazzie
Posts: 1782
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Force changing the screen mode on Risc PCs

Post by Kazzie » Mon Aug 03, 2020 8:01 am

I'm glad that explanation was useful: I've only just started to repair a RiscPC, so I'm regurgitating what I've only just learned myself. ;) Mine is also currently in a state of having no video, but apparently running fine in the background when the POST errors are bypassed.

Is your RiscPC spewing out any POST errors on the floppy drive? I've got a POST Box (after PhilPem's LCD-based design), but the flashes on the floppy drive LED do convey most of the same information.

Damage to the resistors near the battery can leave the CMOS chip disconnected from the board's power supply. In the absence of a battery too, that'll give "CMOS unreachable" errors. Alternatively, with the board power present, but no replacment battery fitted, you'll have CMOS checksum errors at every boot, which need a delete-boot to bypass at every power on. (That's where mine is right now; I haven't fitted a new battery as there are other issues to sort out.)

In order for the VIDC to generate an image, it needs to have its registers set up correctly via the IOMD. This data goes in 32-bit chunks from the main data bus to the VIDC, through the four '244 buffer chips and four resistor packs that are found between the VRAM slot and the SIMM slot. If any of these eight are flaky, then the VIDC won't get the right instructions to turn itself on and start outputting a picture.

On my board, I think I've found a progressive failure on one of the '244s. The end result is that the VIDC isn't set up with a vertical sync, and never requests any DMA transfers of screen data. (This lack of Video DMA requests is what causes the Virq failure on POST for me.)

Do you have access to a 'scope? I found my faulty '244 by comparing the input and output waveforms of each bit going through the buffer chip.

If you haven't already looked through my repair thread, I suggest you take a glance, particularly the bits on fixing the CMOS power connections and later diagnosis of the VIDC's faults.

Feel free to raise any questions on what I've typed up: I'm happy to help clarify anything. :)
BBC Model B 32K issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
RiscPC 600 under repair
Acorn System 1 home-made replica

lista6559
Posts: 14
Joined: Sat Aug 01, 2020 1:16 pm
Contact:

Re: Force changing the screen mode on Risc PCs

Post by lista6559 » Mon Aug 03, 2020 9:11 am

Haha - seems like we're at a similar place in terms of repairs... however, reading back through, I don't think I made it clear - the two threads I have going (this one and viewtopic.php?f=16&t=20117) are for different motherboards! Sorry. The other one seems in a very similar state to yours, and I'll see if I can get access to a scope to check the '244s. With this one it seems even weirder - good MB condition and (as we've established) no immediate problems with track and/or resistor packs going into the VIDC. And while I can get 31khz video out (albeit only with VRAM - otherwise I can't get any better than 15khz, which I can't easily display a picture of) it's horribly distorted (as above). The CMOS doesn't store anything [-X as far as I can tell, and your resistor under battery advice seems plausible here - one of the only spots of potential damage visible. And, like with yours, it only boots with DEL. Other than that, it *seems* to work fine, though not having usable video is certainly a big problem.
So it doesn't seem like the '244s in this case - as there is video output, albeit very patchy (I can try and post a video if useful - though the pictures I posted before should give a good idea) and I don't expect a buffer fault would give any video at all.

Once again, thanks for everything so far and in advance! :D

Cheers,
L

Kazzie
Posts: 1782
Joined: Sun Oct 15, 2017 8:10 pm
Location: North Wales
Contact:

Re: Force changing the screen mode on Risc PCs

Post by Kazzie » Mon Aug 03, 2020 10:06 am

My subconcious tends to assume that each repair thread is not only a separate machine, but also a separate person too, so I'd probably ended up thinking that you were two people! :oops:

Don't be too dismissive of the '244 theory: At one (brief) point in my board's progressive failure of video, it could configure the VIDC correctly for the initial text-based screen (Mode 0?), and show a garbled screen for the later VGA resolutions. Then the display output went altogether. :(

Earlier symptoms had consisted of occasional gargle / jet engine sounds from the speaker for a few seconds, or one corrupted column in the cursor sprite. Given that the cursor is capped at 32 pixels wide, that could be one stuck bit that affected the cursor data coming through the buffer, but didn't happen to affect the register configuration because of where it was. (Display data was coming direct from VRAM, bypassing the buffer.)

I didn't have any reason at all to suspect the '244 until probing its inputs and outputs: it had good continuity to RP16 and the data bus, but it turns out a fault was hiding inside the chip.
BBC Model B 32K issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM, ZIDEFS with 512MB CF card
RiscPC 600 under repair
Acorn System 1 home-made replica

Post Reply

Return to “32-bit acorn hardware”