What ho, pre!
No, neither of those boot codes originate from Puppies, although I've seen the vga=normal suggested somewhere about six months or more ago on this Forum. They were codes I used to use with Knoppix 1.0.0 ! But it was said somewhere that these are common to the Linux kernel. Any road up, they don't do any harm and I have had them work occasionally in the situations you describe.
As for the 754, - No. Mind you, I've had endless trouble with 939 BIOSes. Had to unsolder one once with an electric paint stripper, flash it externally using the /F (force) switch on an alien board, fit a socket and put the BIOS chip in that. It worked for a while, but it gradually dawned on me that the 939 is a design disaster, probably a stop-gap until the Phenom and multiple cores arrived. Not like AMD to pull a fast one like that. Shame really because the multiple core designs are an even bigger disaster, some of Intel's latest are devouring 120W. So much for their lies about running cooler. That is one dud company that has never conquered the thermal issues associated with faster, smaller and thinner - sometimes I even wonder if there's anyone there familiar with Ohm's/Kichoff's/ all-those-other-guys-Laws in school physics?!
The big attraction of 754 and 939 is they have two IDE ports. I was reading elsewhere today the old urban myths about SATA being trotted out again. Now, I'm not sure about SATAIII, but there is NO actual speed gain between ATA100 (ATA133 is like hen's teeth) and SATAI&II. If one reads very very carefully. it's the spec. for SATA that's a lot faster - real drives barely manage ATA transfer rates. It's the old rotating machinery paradox. In principal, SSSD s should be faster, but only if the bus can handle it and their lifetimes in terms of read-write cycles might be uncertain? Early flash memory was suspect in that regard, although I've had no problems with multiple writes. Perhaps we won't know for some years yet?

Many thanks for you patience with this new kennel member. I am trying to find out about the security and accessibility of windows 7 64-bit drives which are seen as icons on the desktop of fatdog64 601 booted from a live cd.
Could you please help me understand the following: Clicking on said icons, mounted or unmounted, then right-clicking "edit item", a "locked" check box appears. Just exactly what will be locked. Does it lock the win 7 drive only in linux or does it carry over to windows?
Are there other methods available in fatdog64 to limit acces of windows drives?
I'appreciate your reply

Next problem, tried this with and without graphics card, and never succeeded in configuring much of anything. I keep getting the defective report screen with resolution and refresh rates missing at the end.

Yep, xorgwizard-old is broke, I haven't used it for ages. Fatdog64 by default runs without an xorg.conf. We really don't want use a xorg.conf file. So I think we'll do away with xorgwizard and xorgwizard-old. Xorg determines which resolution to use based on the EDID data from the monitor, so if monitor doesn't report EDID data or reports it in correctly, Xorg has to guess about the resolution. For non vesa drivers (drivers that are xrandr compliant) resolution can be set with xrandr or the Display Properties in the control panel. I'll fix the pfix=vesa boot option to make an entry in /usr/X11R7/lib64/X11/xorg.conf.d/. That's where want to make changes to Xorg. Thanks for reporting this.

Quote:

Can I get VESA to go beyond 1024x768 in FATDOG? If so, how?

Maybe, you'll need to find out if your card supports vesa modes of that resolution and if your monitor supports that resolution. You can look in /var/log/Xorg.0.log or run ddcprobe, which will list both. Then you'll need to make a file, /usr/X11R7/lib64/X11/xorg.conf.d/20-gpudriver.conf:

After that make sure there's no /etc/X11/xorg.conf file. You may or may not have to use the nomodeset kernel boot option depending on your hardware, but nomodeset is a safe bet with vesa. We need to update our FAQs with this information. I expect most 64bit systems (probably less than 5 years old) to be EDID compliant and setting the resolution won't be needed for vesa. Well, hopefully we won't need vesa ether, usually that happens Nvidia or something really new.

I'm about to install Lazarus from debian packages and went out of space.
Freepascal ist already running fine.
Now i'm trying to find the program to resize pupsafe file.
I think i need new glasses ( already -17 dpt ) .

It works, but I would like to do this:
Put Fatdog64 in a folder, and have the .sfs and save files there too.

Now say I make a folder called "fatdog", put the vmlinuz and initrd files in there, I can easily add /fatdog/ to the lines in the grub text that load the above mentioned files and it works, I've already tried this and it works fine.

But the problem is that it won't load any save or .sfs files I put in the folder, as opposed to other Puppies where this works fine.

Is there any commands I can add to the grub to make it load the save and .sfs files placed in a folder and not the higher level of the directory?

...Xorg determines which resolution to use based on the EDID data from the monitor, so if monitor doesn't report EDID data or reports it in correctly, Xorg has to guess about the resolution...

The monitor in question is a 21" perfectly-flat CRT manufactured by Sony and rebranded by SGI. It reports that it is a GDM-5411. Something in Fatdog 610 must recognize that it has 1600x1200 resolution because that is what leads to the microscopic fonts.

It does report EDID data, just not the version you are expecting. A look at the history of EDID indicates the current version will not have a long product life. Windows can recognize it after drivers for nVidia or ATI are loaded. Prior to that it defaults to generic.

Aside: I use the old CRT because of the good dynamic range of the phosphors. This one can be calibrated to a known gamma for retouching work on photographs. Getting this on modern LCD displays can be hard, expensive or impossible. You can also find these CRTs still in use among various graphic designers.

One incidental side benefit is that any thief who makes off with it can be caught when he ruptures himself.

Something in Fatdog 610 must recognize that it has 1600x1200 resolution because that is what leads to the microscopic fonts.

If that's the highest supported resolution, then that's what we want. If the fonts are too small, switching to a lower resolution is not a good solution. Open the Control Panel, click on the Desktop tab and click on Set global font size. Select a higher dpi for your fonts and restart X to see what it looks like.

Or Xorg can automatically calculate the font size, maybe we will do that. You just delete or rename /root/.Xresources and restart X and see if that looks good.

I think there is a misunderstanding here. I was talking about font sizes outside of the X window system. I know about adjusting font sizes under X. (In that case, adjusting icons, etc. is also necessary. Reducing the resolution may be a sensible option in some cases, even if it isn't in the case you are thinking about.)

Even when the frame buffer does not get messed up, the text console fonts, which were previously readable, suddenly become microscopic during the boot sequence, making it hard to tell what is going on when there is a problem in getting to X and a desktop, or in the reboot/shutdown sequence, when there is a failure to save.

The general problem I'm getting at is one of robustness when things go wrong. This applies not just to software, which can't anticipate every problem, but to the system of software, hardware and people dealing with issues. If I wanted software which does everything for me when things go right, and leaves me helpless when something goes wrong, I might have stayed with M$.

Puppy has always impressed me with the ability to fall back to some lower level of operation where it is possible to isolate a problem well enough that knowledgeable people can fix it quickly.

For example, Barry's Simple Network Setup was not the first try at that function, or even the second. It would not have come into existence without considerable preceding history. Even today, when things go wrong, I check on how Dougal's network setup handles it. At least this narrows the range of places to check for faults. Sometimes it works when SNS fails. Those cases are becoming rarer, but both tools remain available in 5.4.2. I've known experienced network people to become very frustrated while trying to make Windows automatic network tools work.

Losing the ability to fall back to text console video setup strikes me as a mistake.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum