AmigaOS 3.2 and beyond

[Yulquen74]

Can I ask:
The 3.2 ROM, like many others automatically autodetect the ranger memory starting at 0xC00000. Does it also autodetect any RAM above the 24 bit address area, given an A500 with a real 32 bit CPU (020-060), or is Z3 autoconfig way to go to achieve this?

[Steady]

AutoConfig is what to use for identifying extra memory. The C00000 memory is an exception to the rule along with CHIP memory. All other memory should be AutoConfig

[Thomas Richter]

It is a little bit more complicated than that because expansion also detects the motherboard RAM of the A3000 and A4000 which are not autoconfiguring. However, this memory detection is model-specific and hard-coded into the particular kickstart versions for the models. Probably non-ideal - the RAM *should* really be following autoconfig protocols.
RAM expansions for Zorro follow autoconfig, though RAM on turbo boards is often added to the system through more or less "adventurous" constructions, for example through the F-space vector. Some turbo-boards actually add RAM through a modified autoconfig chain.

[looseether]

One thing I'd like to see implemented is a way to create icons for iconless objects from the system default icons they are given when 'showing all files' from the Workbench Window menu.

Most likely also accessed via a system menu (Icon perhaps?) - select the object(s) via its/their default 'phantom' icon(s) then select the 'add default icon' menu item.

I've written simple DOS/Arexx scripts to achieve this for myself but it just seems like a glaring omission not to be included as a default Workbench function.

[boemann]

Originally Posted by looseether

One thing I'd like to see implemented is a way to create icons for iconless objects from the system default icons they are given when 'showing all files' from the Workbench Window menu.

Most likely also accessed via a system menu (Icon perhaps?) - select the object(s) via its/their default 'phantom' icon(s) then select the 'add default icon' menu item.

I've written simple DOS/Arexx scripts to achieve this for myself but it just seems like a glaring omission not to be included as a default Workbench function.

The snapshot function already does that.

[looseether]

Originally Posted by boemann

The snapshot function already does that.

So it does. I'm pleased, thanks

[ppeter]

Would it be possible to make the String gadgets of WBPattern and Sound editable?

As an example:
1. open WBPattern
2. Click SelectPicture
3. In de ASL-Requester select a picture in e.g. SYS:Prefs/Backdrops/awesomebackdrop.ilbm
4. Choose "OK", the file requester closes
5. The File name is shown in the textfield
6. Click on "SelectPicture" again
7. The string gadget in the ASL-Requester shows "OS3.2:Prefs/Backdrops/awesomebackdrop.ilbm"

It does not make a difference if the path is chosen by navigating to the file with the mouse pointer, or by typing the file name in the string gadgets. Either if I choose "OS3.2" or scroll the list to the "SYS:" entry, once the ASL-Requester is closed, it automatically reverts back to the Volume name.

Would it be possible to have the Sound and WBPattern Preferences Editors updated in order to keep the name or device the user sets it to? Or to make the StringGadged editable.
Maybe it's the ASL-Requester who needs an update?

[boemann]

When we replace the WB prefs in 3.3 the getfile.gadget will be used - that should make it possible to hand edit it

[EAUniW]

..

[jman]

@Boemann

From time to time I use the CLI and these are my observations:
- Port the Date command to feature parity with the OS4.x version (see here for example)
- I would love a new command Move in the shell CLI built-ins. I'm sure I can move files and directories in other ways but having a built-in blessed tool would be great.

(I am not sure how AOS3.x developers can keep up with suggestions and sort things posted here but I am glad this thread exists )

thanks

[boemann]

Originally Posted by jman

@Boemann

From time to time I use the CLI and these are my observations:
- Port the Date command to feature parity with the OS4.x version (see here for example)
- I would love a new command Move in the shell CLI built-ins. I'm sure I can move files and directories in other ways but having a built-in blessed tool would be great.

(I am not sure how AOS3.x developers can keep up with suggestions and sort things posted here but I am glad this thread exists )

thanks

The move command does sounds nice but the underlying dos does not make it easy

A format option for date sounds nice. Not promising anything but your suggestion is noted.

[Tpod]

A couple more things I would like to see in OS3.3 if possible:

1. The number of files in a draw being displayed on the title bar (or somewhere else) of its window on opening.

2. Non Standard bootblock ADF support

Old floppies (no new ones being produced) combined with old disk drives is making working with real disks something to be avoided wherever possible. I don't know if one or both of the following would be possible to implement:

A) Being able to boot ADF games disks from Workbench that have an unknown bootblock.

B) Booting these ADF's via the Early Startup Control; have a special partition with ADF's that you can access & select to boot from. Whether the partition needs/can be booted into, to start these ADF's I don't think matters much IMHO it's a case of whatever would be easiest/possible to implement.

I know there's obviously Gotek, however OS 3.2 is very good handling standard bootblock ADF's & there's WHDLoad (with its added benefits) &/or hard drive installers for most games. Every now & then though you have to resort to using those darn (now) unreliable floppies which can be pretty frustrating, hence the request.

[Daedalus]

I've found the RAD: device is excellent for booting from as a virtual floppy drive, and is already included. Just mount RAD: and the ADF, diskcopy the ADF to RAD: and reboot. An ARexx script could probably combine those steps into a single menu entry without too much trouble.

[paraj]

Originally Posted by Tpod

2. Non Standard bootblock ADF support

99.9% of the time a non-standard bootblock means it will take over the system in a short while and try to load from the floppy using direct hardware access, so unfortunately something like that is not feasible.