Subj : Remmina RDP To : Ky Moffet From : Barry Martin Date : Sun May 19 2024 08:22:00 Hi Ky! KM> Boo! Boo who?!! ....Thought I figured soming out but now makes less sense. If a 'boo' is a boyfriend/girfriend/lover ("he/she is my boo") and 'boo' is said by a ghost or to scare someone, why is it good to be a 'boo'? > KM> It's the description of the fault that tells me it's most likely > KM> bad video RAM. > KM> That's quite distinctive -- you get a solid mass of random ASCII > KM> characters. We used to see that a lot in the Olden Tymes. > KM> When the card is loose, or the GPU is failing, you get random > KM> lines. > Ahhh! I don't recall the random characters part. The make-and-break of > the data stream would cause the card to try to make sense of it and output > what it thought it was told. KM> I think it happens when the amount of usable RAM is so KM> constrained (probably to just the first address bank) that it KM> can't process more than the first few pixels, and the result is KM> Random ASCII Characters in 25-line textmode (usually the bottom KM> 32 bytes of the ASCII table at that, so it's hearts and spades KM> and such), having displayed all it managed to scrape up. That makes sense. I'm thinking it could also mean a faulty bit which is causing a bad instruction and so garbage output. That one based on years ago when I built a Heathkit TV and the overlay display (time, channel, etc.) was sometimes scrambled. A little analysis and only certain letters: let's say "C" so "Channel" might display as "Thannel" and "MAY" as "MAR". Figured out via ASCII Chart the problem was a certain bit level was being set wrong: let's say 3rd LSB (out of the 8). Figured out where the problem was on the schematic (between encoder and decoder) but which was LSB and MSB? (I'm not that good and pre-web access to get the chip specs.) So ended up making four reair solders: two on each end of the trace and two since I wasn't sure which was LSB and MSB. Ta-dah! No more misspellings! > KM> When the cable is loose, you'll lose some color (and have frex a > KM> pink screen). > Right. KM> Why it's usually pink, I dunno, tho I have seen blue and green, KM> just not as often. Probably depends on the layout of the cable KM> head, and which side is pulling loose, and how it sits on the KM> board, that sort of thing. Ie. which pins are being pulled out, KM> more likely on the side typically away from gravity. KM> Gravity always wins! At least I don't have to go looking for dropped parts on the ceiling too! > KM> This isn't absolute but it's a pretty good guideline. > Good starting points which usually work. KM> Usually good enough, if it's hardware. If it's software, can be KM> any damn thing. Though even software follows rules. I remember one script I was creating, and since just self-trained a lot of pluck some code from here, some other code from there.... Something wasn't working so put in an echo statement to display the output at a certain level of the script. That helped figure out the problem, so now getting the correct result per the echo statement but the next step was always displaying "0". Used to semi-work before! Ends up the following statement was taking the output of the echo statement: echo finished its job properly so outputted a '0' for 'good out'. Comment the test echo and now worked! > > Doesn't eliminate video addressing statement as a possibility. I don't > > recall how to look up; guessing "all f's" in the range end-point would > > mean it's at the far end. > KM> Addressing shouldn't cause this kind of visual screw up; it would > KM> cause a lockup or no video at all due to the conflict. And if > KM> you're not a modern gamer, or rendering video, you're not gonna > KM> fill up that video RAM anyway. > Probably so: this is another of my Black Box areas and so stuff in, > something happens, stuff out. On the -- guess could call it > 'clarification' area know there are maximum resolutions so I would guess > there is some sort of upper limit. Doesn't seem to be pertinent as the > video card and monitor seem to always adjust to each other. KM> Modern OSs probe the vidcard and the monitor, which proceeds to KM> tell the OS what it is capable of, producing a range of options KM> that if wrong will do no worse than look goofy, but with neither KM> damage the hardware nor leave you with a blanked-out display that KM> needs a reinstall or CLI magic to fix. ....Trying to piece that together with a problem I have here: took an old computer out of service here as a Frontend (view recorded show via MythTV) because of a problem with the video, which right now not recalling exactly what -- there's a note on the case. "Everything" pointed to the video card so swapped that out with something current. Nope! Same problem! ...Just left the Raspberry Pi in it's place. KM> Modern OSs now understand this stuff, and have done so pretty KM> reliably for about 25 years. Part of the longstanding problem KM> with linux was that until about 10 years ago, or a bit longer for KM> some of the more advanced distros, you had to know your hardware KM> parameters and sometimes input them manually. It seems to have KM> finally got this right. When you're doing it for free, as has KM> mostly been the case, hardware programming is not near as sexy as KM> cute apps and games, so it gets way less attention. Yes, I vaguely recall having to initially configure the video settings. Now pretty much does it itself, though that occassionally creates a problem when using a 4K TV and so viewing from ten feet away! ....Even the resolution selectrion GUI is teeny-tiny when standing right in front of the TV! > So if I remember correctly Mike's problem was after a while his monitor > would go black and need a reboot to get things going again. I don't > recall if he stated a time but seemed he implied weeks or months. I > want to get in on the thread because I have a similar problem with one > essentially headless system which tends to not talk to a monitor after > some time -- I'm thinking around 1.5 to 2 months. KM> Fedora used to do that, tho the problem seems to have gone away KM> as of v39. Except it would decide to not speak to the outside KM> world after about a week, unless regularly rebooted. Meanwhile KM> PCLOS had been running for several months, and WinXP for about a KM> year and a half, with no such issues. Almost seems like 'something runs out of room'. I have some computers around here rebooting themselves on a weekly basis because of that kind of issue. Not necessarily an OS issue -- may have been years ago, but now more like a problem with some utility causing the lockup/overrun. (Thinking of a couple years back when had three RPi4's running a previous version of Motion and other RPi4 running same OS but Motion not installed. The Motion ones needed frequent rebooting, the others not running Motion would run for months. [Important note: Motion has been corrected since then!]) KM> As we skeap ?? speak Fedora is sitting there upgrading to v40. KM> It's been at it since 11pm last night, tho a lot of the time was KM> 5GB of downloads on a 3Mbps connection. Had to do a full update KM> first, then run the upgrade (fortunately the commands are still KM> handy in the console buffer... it started life as v32). It is now KM> running the final step and will be done in about an hour. You can KM> see why I find rolling a lot less trouble. Better hope that connection maintains!! ...The long time to do an update/upgrade was one reason I only did one machine at a time: besides multiple connections slowing down the limited bandwidth if something went wrong like an extended power failure I have only one computer to recover. KM> And I get my first look at KDE Plasma v6. Given the newness KM> thereof (just released) for the next while there will be a lot of KM> updates, possibly to the point of a Whole New Monkey. But they KM> are usually pretty good about getting the major bugs out (not KM> least because unlike say Xfce, which is one guy and change, it's KM> a team of a hundred-plus folks.) More people seems to be better as a couple might be experts in video, others, audio, etc. Plus if only if one or two doing the whole job and something happens..... KM> http://www.wholenewmonkey.com/ Huh: under maintainence -- guess the upgrade and update data is stil lrolling in! ¯ ® ¯ BarryMartin3@MyMetronet.NET ® ¯ ® .... A group of flamingos is called a stand. --- MultiMail/Win32 v0.47 þ wcECHO 4.2 ÷ ILink: The Safe BBS þ Bettendorf, IA --- QScan/PCB v1.20a / 01-0462 * Origin: ILink: CFBBS | cfbbs.no-ip.com | 856-933-7096 (454:1/1) .