Minor problems with update5

[xenic]

Some commands in user-startup can fail because the current directory is now changed in the startup-sequence. All references to system directories must now explicitly include SYS: as the root directory. (e.g. SYS:ExtraDevs/Datatypes instead of ExtraDevs/datatypes).

Update5 replaced "C:SetPatch ADDCHIPRAM 2 QUIET" with "SetPatch QUIET WAITFORVALIDATE" in my startup sequence. Does that mean that the Chip Ram for emulation is now automatically set to 2 or do I need to edit
my startup-sequence to add "ADDCHIPRAM" back in?

The PlayCD icon is apparently replaced so any user-set prefs are lost.

No important problems so far. Great work OS4 devs!

[ChrisH]

Some commands in user-startup can fail because the current directory is now changed in the startup-sequence. All references to system directories must now explicitly include SYS: as the root directory. (e.g. SYS:ExtraDevs/Datatypes instead of ExtraDevs/datatypes).

That would be the fault of whatever commands you added to the User-Startup. If you are going to assume the current directory is SYS: then you need to add a CD SYS: before your commands... but it is probably safer to just use the full path instead.

[tonyw]

You will have to add the "CHIPRAM" option again - it is not built in.

Sorry about the PlayCD icon - people complained that it was missing the "(USEAHI)" option, so the new one includes that. You should have the docs there somewhere, too.

You should be able to copy your saved icon from your Update 4 backup.

[xenic]

You will have to add the "CHIPRAM" option again - it is not built in.

O.K. Just wanted to be sure before I add it back in.

Sorry about the PlayCD icon - people complained that it was missing the "(USEAHI)" option, so the new one includes that. You should have the docs there somewhere, too.

Check with ssolie. He uploaded a program at OS4Depot to read, replace or add TOOLTYPES in icons. I would expect that program could be used to update icons with the Installer instead or replacing them. It might not be a bad idea to add that program (changetooltype) or a similar one to the OS4 C: directory so it can be used by future installations.

You should be able to copy your saved icon from your Update 4 backup.

I recognized the problem and fixed it because the icon was moved over the top of another one. You probably should have unsnapshotted it. I only mentioned it here in case somebody wonders why their PlayCD is working differently with Update 5.

[chris]

Sorry about the PlayCD icon - people complained that it was missing the "(USEAHI)" option, so the new one includes that. You should have the docs there somewhere, too.

Check with ssolie. He uploaded a program at OS4Depot to read, replace or add TOOLTYPES in icons. I would expect that program could be used to update icons with the Installer instead or replacing them. It might not be a bad idea to add that program (changetooltype) or a similar one to the OS4 C: directory so it can be used by future installations.

Of course the old Installer had that functionality built-in

[xenic]

Some commands in user-startup can fail because the current directory is now changed in the startup-sequence. All references to system directories must now explicitly include SYS: as the root directory. (e.g. SYS:ExtraDevs/Datatypes instead of ExtraDevs/datatypes).

That would be the fault of whatever commands you added to the User-Startup. If you are going to assume the current directory is SYS: then you need to add a CD SYS: before your commands... but it is probably safer to just use the full path instead.

I mainly mentioned the issue in case other people wonder why their user-startup doesn't work the way it did previously. Since the current directory for startup has been SYS: for the 25+ years I've been using an Amiga, I never saw any reason why I would need to include CD SYS: or specify SYS: in a user-startup command. Besides, what purpose was there to making an unnecessary change like the current directory in the startup-sequence? It looks to me like change for the sake of change.

[nbache]

Besides, what purpose was there to making an unnecessary change like the current directory in the startup-sequence? It looks to me like change for the sake of change.

The purpose (AFAIK) is to save the explicit C: in front of every following command. It is apparently faster to start a command in the current dir (or the search path) than by explicit path.

Best regards,

Niels

[xenic]

The purpose (AFAIK) is to save the explicit C: in front of every following command. It is apparently faster to start a command in the current dir (or the search path) than by explicit path.

Maybe changes like that made a difference when Amiga was booting from floppies but with todays faster processors, hard drives and memory the difference is probably insignificant. In fact, I ran some tests using the timer command from OS4Depot and it shows that the difference IS insignificant. I renamed my startup-sequence as "MyStartup-Sequence", created a single line script with the command: timer "execute MyStartup-Sequence" >>DH2:result and named the script "Startup-Sequence". Then I rebooted 10 times with the "CD C:" command and ten times without it. Here are my results:

Results with CD C: in startup-sequence
Command duration: 2.8580 sec.
Command duration: 2.8247 sec.
Command duration: 2.7831 sec.
Command duration: 2.8164 sec.
Command duration: 2.7748 sec.
Command duration: 2.7926 sec.
Command duration: 2.7843 sec.
Command duration: 2.7667 sec.
Command duration: 2.8043 sec.
Command duration: 2.7998 sec.
Total of all tests: 28.0047 sec.
Average time: 2.80047 sec.

Results without CD C: in startup-sequence
Command duration: 2.8082 sec.
Command duration: 2.7980 sec.
Command duration: 2.7581 sec.
Command duration: 2.7901 sec.
Command duration: 2.7499 sec.
Command duration: 2.7998 sec.
Command duration: 2.7719 sec.
Command duration: 2.7748 sec.
Command duration: 2.7998 sec.
Command duration: 2.7736 sec.
Total of all tests: 27.8242 sec.
Average time: 2.78242 sec.

Difference in avarage boot times: 0.01805

As you can see, the difference in the average boot times is insignificant (less than 2 hundredths of a second). Contrary to popular belief, the times that I got by replacing all the startup-sequence commands with complete paths (explicit paths) in a third test showed that to be the slowest method.