Os 3.2 development preview

[paul1981]

@kolla
Though I don't feel as if I have a need for those features, those do seem reasonable requests for OS3.2, and it can be done without changing anything noticable to the average user too.

So it's tweaks to the prefs programs for command line control. Can it be done Thomas without too much difficulty?

[guest11527]

The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities, it also requires the creation and integration of a robust parser into the system, wasting development resources we really need for more important issues.

[SamuraiCrow]

Likely not. I do not even know what this should mean (what is a "copperlist fade"? What is a dynamically updated copperlist? UCopperListInit and friends exist already, so you can certainly update them) Essentially, the way how the graphics.library code looks, it is more at the end of its lifetime, and we should really replace that by something different and more "cleaned up".

For 3.2, no major works on graphics are planned, except a better integration of AllocBitMap() into the P96 model that doesn't change a thing for native graphics. I believe this is about it.

MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.  At least I agree that Graphics.library is EOL.

Personally, I think that a full VM like what AmigaDE started to be would allow such things as inline code contained in the graphics drivers.  This would allow demo-code like capabilities to be accessible to what otherwise would be considered system-friendly code.  The AOT style JIT of AmigaDE did that (or would have done if Amiga Inc. had ever targeted their own systems  ).

[kolla]

The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities

And I wasn't suggesting to change the format.

it also requires the creation and integration of a robust parser into the system

Yes, something that should exist at some point sooner or later anyways.

wasting development resources we really need for more important issues.

Nothing prevents this from being implemented by someone else - as you wrote - the preferences format is a well-document open IFF format.

[RetroPassion]

Great news!!

[guest11527]

MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.

I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.

However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.

So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.

As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.

[x303]

The preferences format is a well-document open IFF format. Changing the format not only risks incompatibilities, it also requires the creation and integration of a robust parser into the system, wasting development resources we really need for more important issues.

Why not use xml for that and use iff (import) as 2nd option ?

[guest11527]

Why not use xml for that and use iff (import) as 2nd option ?

Why not use json as third option?

Ok, now, be serious: All of this is of little use for the average user. In those cases where it is of use, it is equally well possible to scan the binary prefs as they are, or for those that love ASCII, write a converter tool between an ASCII representation and the binary representation. It shouldn't be too hard to write up a small service program that keeps a notification on an ASCII representation (I like json) of the prefs, and in case this changes, updates the binary prefs. Or vice versa. There is no need to touch the prefs programs for that, it could all work transparently with a daemon program in the background.

Now, are there still volunteers for this idea?

[dalek]

Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!

[Minuous]

Why not use xml for that and use iff (import) as 2nd option ?

That would be contrary to the official Style Guide: "It is recommended that you use an IFF FORM for preferences files." Also, XML would be much less efficient.

[guest11527]

Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!

No - why? Did IDEFix stop working in 3.1.4?

[kolla]

All of this is of little use for the average user.

You just summed up all the work you ever did to Amiga shell.

It shouldn't be too hard to write up a small service program that keeps a notification on an ASCII representation (I like json) of the prefs, and in case this changes, updates the binary prefs. Or vice versa. There is no need to touch the prefs programs for that, it could all work transparently with a daemon program in the background.

Now, are there still volunteers for this idea?

That was exactly my idea in the first place - and with such a daemon (IPrefsNG for teh lolz) in place, it is easy to write all kinds of new prefs programs without much hassle.

[TribbleSmasher]

Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.

Possibly bubbob42 is already working on such thing, as he stated a suspicious line on EAB

I just had a similar problem because I wanted to exchange gadgets in a window depending on the item selected in a listview gadget (which itself would stay visible all the time. Here’s what I did:

I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.

[guest11527]

I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.

For that, you wouldn't even need to modify IPrefs. IPrefs just reads the IFF files it monitors, and forwards the chunks it finds to the corresponding system components. Which chunks are in which files does not even matter to it.

[kolla]

Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.

Or OS 1.x

I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.

Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.