For my peg2 i not have this kind of problem.. Just can boot to os4.1 or to mos 2.2 when i want. Even from soft/cold reset or even from poweroff-on machine. (i have radeon 9250 if it make sense for)
If you play something with Tunenet or other players and will perform a soft-reset by pressing (Amiga left - Amiga right - Control) will freeze the system and your hear the soundbuffer playing again and again sounds like a machine gun.
I've notice a few issues while testing my new SAM Flex with OS 4.1 and thought they might be worth mentioning:
1. As I pointed out it other forums, mounting a 64MB RAD drive (recoverable ram drive) causes some programs like AmiPDF to freeze the entire system. I have several PDF files that cause AmiPDF to freeze the system at a certain page if I have 64MB RAD installed. With a 32MB or smaller RAD AmiPDF works fine. It should either be fixed or a size limit for RAD should be published in the OS 4.1 docs.
2. The ENV-Handler doesn't seem to work as advertised. After a boot or reboot, ENV: contains all variables except the default icons instead of loading them as requested. That includes some old variables that are no longer even used on my system. If the handler is going to copy everything to ENV: at startup, why not simplify the system by using the old method of creating an ENV: directory in RAM: and copy everything from ENVARC:
3. The USB mouse on SAM Flex seems to be eating about 8192 bytes of memory for every large mouse movement. Rene Olsen pointed out on the OS4 ML that the buffers are currently not reused but it is planned to change that. I only mention it here as a reminder that it's something that should be fixed. I don't have the patience to rotate my mouse for 10 hours but eventually it could use a noticeable amount of memory.
2. The ENV-Handler doesn't seem to work as advertised. After a boot or reboot, ENV: contains all variables except the default icons instead of loading them as requested. That includes some old variables that are no longer even used on my system. If the handler is going to copy everything to ENV: at startup, why not simplify the system by using the old method of creating an ENV: directory in RAM: and copy everything from ENVARC:
I think this is a compatibility thing - it was changed in one of the OS4 updates, and used to work as you describe (it would only contain items that had been accessed). I doubt it is copying everything from ENVARC: to ENV: - you'd notice if it was - but merely holding the entire list of files that can be accessed from ENV: in the directory catalog.
Chris wrote: I think this is a compatibility thing - it was changed in one of the OS4 updates, and used to work as you describe (it would only contain items that had been accessed). I doubt it is copying everything from ENVARC: to ENV: - you'd notice if it was - but merely holding the entire list of files that can be accessed from ENV: in the directory catalog.
I tested your hypothesis. I reassigned ENVARC: to an empty directory and then copied the entire contents of ENV: to another directory. All the files in ENV: were copied in their entirity. If the files in ENV: were just a list of what's in ENVARC: I should not have been able to copy all the files. With ENVARC: assigned to an empty directory, ENV: could not have pulled them from there.
Why on earth do you claim this change in behaviour as a bug?? Yes, it has changed since the OS3 days. Yes, it is to increase system performance. No, it won't affect any existing programs.
xenic wrote: 2. The ENV-Handler doesn't seem to work as advertised. After a boot or reboot, ENV: contains all variables except the default icons instead of loading them as requested. That includes some old variables that are no longer even used on my system. If the handler is going to copy everything to ENV: at startup, why not simplify the system by using the old method of creating an ENV: directory in RAM: and copy everything from ENVARC:
Using an ENV directory inside another file-system is not as efficient as having a dedicated ENV variable system. Added to that, you don't actually know if the "files" that you see in ENV: are actually in memory, or just the filenames. I have no idea how ENV is implemented, but there's no reason why seeing a file listed means that it's in memory; it certainly isn't the case with any other file-system.
Strictly speaking software is supposed to access environment variables via dedicated functions in the DOS library, and not through the ENV-handler. How deficons are handled, I don't know (and don't care really, so long as they work).
Using an ENV directory inside another file-system is not as efficient as having a dedicated ENV variable system. Added to that, you don't actually know if the "files" that you see in ENV: are actually in memory, or just the filenames. I have no idea how ENV is implemented, but there's no reason why seeing a file listed means that it's in memory; it certainly isn't the case with any other file-system.
Did you read my response to Chris? I booted, reassigned ENVARC: to an empty directory and copied all the files from ENV: to another directory. If ENV: were simply a list of what variables are in ENVARC: then I should not have been able to copy them if ENVARC: is empty. I think the whole concept of using a device for ENV: started with HappyEnv (available on Aminet), was replaced by envhandler (also on Aminet) and the same or similar device was introduced into OS4. The docs for both earlier ENV: replacements and the promotional docs for OS4 specifically state that the main advantage of using such a device is that environmental variables are not all copied to ENV: to ENVARC: during a bootup but are retrieved from ENVARC: and added to ENV: as they are requested by various programs. That's how those handlers work if installed on OS3 but something seems to have gone wrong with the OS4 implementation. Besides, ENV: does work as it should when it comes to default icons. Check out the ENV:sys directory. You will only see the default icons that have been requested by the system or programs. Look in ENVARC:sys and you will see scores of default icon files that don't appear in ENV: That's how ENV: is supposed to work for ALL environmental variables. They should only appear in ENV: if they have been requested by the system or a program.
Why on earth do you claim this change in behaviour as a bug?? Yes, it has changed since the OS3 days. Yes, it is to increase system performance. No, it won't affect any existing programs.
I don't know why everyone is so sensitive about the word "bug", Call it a "shortcoming" or "deleted feature that should not have been deleted" if you want. The fact is that OS 4.1 ENV: does not work the way OS3 versions or the OS4 prerelease versions worked. I think that it may have been an accidental change or ommission and that bringing it to the devs attention may have some positive results.
Using an ENV directory inside another file-system is not as efficient as having a dedicated ENV variable system. Added to that, you don't actually know if the "files" that you see in ENV: are actually in memory, or just the filenames. I have no idea how ENV is implemented, but there's no reason why seeing a file listed means that it's in memory; it certainly isn't the case with any other file-system.
Did you read my response to Chris? ...
Yes I did, and it changes NOTHING in my reply to you. I explained to you why it might behave the way that it does, and why the new behaviour doesn't mean that we should go back to creating an ENV assign in RAM.
It doesn't matter why the ENV device was originally created; we're not in the 90s any more, and technology progresses. Changing the behaviour for better performance is NOT a bug. If the OS4 documentation for the ENV handler hasn't been updated, then it needs to be; if it's the OS3 documentation that you're reading, then you're simply out of date.
Quote:
Besides, ENV: does work as it should when it comes to default icons.
Icons aren't normal environment variables, and may be handled differently. IMHO, ENV wasn't the right place to put these in.
The fact is that OS 4.1 ENV: does not work the way OS3 versions or the OS4 prerelease versions worked. I think that it may have been an accidental change or ommission and that bringing it to the devs attention may have some positive results.
Yes, that functionality has changed, and for the better. ENV: is now handled as a virtual device by the env-handler in a similar way to the old "happyenv" system did on OS3.
This is just another reason why inward system mechanics should be hidden from the user, this system is not designed to be altered by the user at any level.
The fact is that OS 4.1 ENV: does not work the way OS3 versions or the OS4 prerelease versions worked. I think that it may have been an accidental change or ommission and that bringing it to the devs attention may have some positive results.
Yes, that functionality has changed, and for the better. ENV: is now handled as a virtual device by the env-handler in a similar way to the old "happyenv" system did on OS3.
This is just another reason why inward system mechanics should be hidden from the user, this system is not designed to be altered by the user at any level.
It works as it is intended.
Simon
Good Grief. Why is it so hard to get through to you OS4 cheerleaders? First you quote me saying that OS4 ENV: isn't working like OS3 env-handler and happyenv, then you explain that OS4 ENV: is handled in a similar way to the old "happyenv". Read the env-handler and happyenv docs on Aminet that explain that they save memory and boot-time by not copying all of the ENVARC: files to ENV:. Read my next post for a description of how to make OS4 ENV: work the way it's supposed to and why I think it currently does not.
xenic wrote: Good Grief. Why is it so hard to get through to you OS4 cheerleaders? First you quote me saying that OS4 ENV: isn't working like OS3 env-handler and happyenv, then you explain that OS4 ENV: is handled in a similar way to the old "happyenv". Read the env-handler and happyenv docs on Aminet that explain that they save memory and boot-time by not copying all of the ENVARC: files to ENV:. Read my next post for a description of how to make OS4 ENV: work the way it's supposed to and why I think it currently does not.
Similar does not mean the same. What's similar is that it's a virtual device. Good grief, why is it so hard to get it through to you that it's not a bug. Nor is it a "deleted feature that should not have been deleted," a "shortcoming" or anything else that you've said that assumes that it's a bug.
@Hans If you want an idea of how ENV: is supposed to work you can try this on a spare boot partition:
1. Backup your boot partition or use a spare one. 2. Clone the SYS:Prefs/Env-Archive as "SYS:Prefs/env-arc". You should then have 2 directories with the same contents. 3. Remove all files from SYS:Prefs/Env-Archive except those in SYS:Prefs/Env-Archive/sys and SYS:Prefs/Env-Archive/usb. Do not delete any directories; only files. The directory structure must remain intact. 4. Add the line "Assign ENVARC: SYS:Prefs/env-arc" beneath the line "Failat 21" in the startup-sequence. 5. Reboot into the partition you just changed but don't start any programs. 6. Check the size of ENV: by entering info ENV: and you will see that it is much smaller than it is if you boot from a normal OS4 partition. 7. List the files in the ENV:MUI directory (with list ENV:MUI in a shell) and it should be empty (unless you have MUI programs in your WBStartup). 8. Start IBrowse and list the files in ENV:MUI again. You should now see the files IBROWSE.prefs, Global.prefs and possibly others. 9. You can start other programs that store their prefs and variables in ENV: and they will appear there even though they were not there after booting.
That's how ENV: is supposed to work. Only variables that have been accessed should be there. I think that the reason all the variables/prefs are copied in a current OS4 boot is because there was a problem in OS4 prereleases with some programs that couldn't manipulate their variables/prefs; probably because they weren't doing it the right way. I think the "quick and dirty" solution was to have all the ENVARC: files copied to ENV: during a boot. That's speculation on my part but whatever the reason, it needs to be changed to work the way it's should.
A simpler way to demonstrate how ENV: is supposed to work is to simply delete some prefs before starting a program and watch them reappear in ENV: when the program is started. For example, your can delete ENV:MUI/IBrowse.prefs before starting IBrowse and ENV:MUI/IBrowse.prefs will reappear after the program is started. The IBrowse prefs don't need to be copied to ENV: at boot but they are; along with all the other ENVARC: files except the deficons.
If you guys try any of the above demonstrations and still don't get it, then go to the WEB page of the author of the OS3 & OS4 version of env-handler, Stephan Rupprecht, and read the docs included in the env-handler archive. It states and I quote:
-quote- The advantages of env-handler over RAM:Env are:
- low memory usage - faster access to env variables - a "delete ram:#? all" doesn't hurt ENV vars. - faster booting (no need to copy envarc: to env:) -unquote-
Do you get it? NO NEED TO COPY ENVARC: TO ENV: Whether all the ENVARC: files are being copied during bootup or whether some stupid Linux port is scanning every single variable in the system causing them all to be copied to ENV:, the point is that it shouldn't be happening.
I repeat: - You do not know what the ENV handler does and doesn't store in memory internally - What you see in directory listings does not tell you what is and isn't held in memory - The behaviour of the ENV handler has been changed for improved performance
Added to this: - None of your experiments show what the ENV handler is actually doing, because you're assuming that it's a normal file system - The version of ENV-handler on Stephan's website is from 2001; it's 2009 now. Things change - The current Amiga OS 4.1 release for Amigaone's has the old behaviour that you so desperately want. This rules out your "dirty little hack" theory - Amiga OS 4.1 beta for SAM boards is newer than the A1 release, so the changes have been implemented since the A1 version was released
I don't care how it used to be done, or how you think it should be. The behaviour has changed, and for a reason. Do you get it?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
