Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 135387 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline kolla

Re: Os 3.2 development preview
« Reply #104 on: September 06, 2019, 09:41:06 PM »
Presets can already be loaded via scripts.
Yes, and then you need to have them available. Meaning you have to enter whatever prefs program, set parameters and save to file all possible settings you may wish to have available.

Quote
Can you explain the need for more control from the command line?

Sure.

* different palette settings depending on what daylight there is, with darker settings at night - currently I do this by juggling preset files, I would prefer to send RGB values regarding the various pens directly.
* sounds prefs, audio bell - I wish to control at least the volume without having one setting file per possible volume setting.
* ASL prefs - depending on context, I want to control how ASL requesters sort files so I don't have to do it manually every time
* screenmode/overscan - I want to control certain screen properties.. width, height, depth.. in one go, without needing to keep dozens of preset files around
* serial - I wish to easily change properties like baud rate from CLI/ARexx, as AUX:, SER: etc. AFAIK do not have parameters for such.
  (Yes, I know there are options, like using http://aminet.net/package/util/libs/DigNet)

Quote
I've always liked the way AmigaOS handles prefs and I like the env/envarchive 'thing' which I think is rather elegant and efficient.

Me too.

Quote
Also, why would I want other software to be mucking around with my preferences? Any software mucking around with my preferences gets deleted!

I don't know where you get this from, I am talking about the user - me - being able to control the preferences of my computer from my preferred user interface. There is nothing that prevents programs from mucking with your preferences already.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline paul1981

Re: Os 3.2 development preview
« Reply #105 on: September 08, 2019, 07:29:36 PM »
@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

  • Guest
Re: Os 3.2 development preview
« Reply #106 on: September 08, 2019, 08:37:11 PM »
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.
 

Offline SamuraiCrow

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 2280
  • Country: us
  • Gender: Male
    • Show only replies by SamuraiCrow
Re: Os 3.2 development preview
« Reply #107 on: September 08, 2019, 09:29:59 PM »
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  :o ).
 

Offline kolla

Re: Os 3.2 development preview
« Reply #108 on: September 08, 2019, 10:11:00 PM »
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.
Quote
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.
Quote
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.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline RetroPassion

Re: Os 3.2 development preview
« Reply #109 on: September 18, 2019, 08:43:03 PM »
Great news!!
Offering complete Amiga recapping  services including add-ons, mods. We also cater for other makes and models of consoles and computers.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #110 on: September 18, 2019, 09:14:37 PM »
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.
 

Offline x303

Re: Os 3.2 development preview
« Reply #111 on: September 18, 2019, 10:03:58 PM »
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

  • Guest
Re: Os 3.2 development preview
« Reply #112 on: September 19, 2019, 12:30:46 AM »
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?
 

Offline dalek

Re: Os 3.2 development preview
« Reply #113 on: September 19, 2019, 02:06:48 AM »
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!
 

Offline Minuous

Re: Os 3.2 development preview
« Reply #114 on: September 19, 2019, 04:31:05 AM »
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.
« Last Edit: September 19, 2019, 04:32:36 AM by Minuous »
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #115 on: September 19, 2019, 10:22:32 AM »
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?
 

Offline kolla

Re: Os 3.2 development preview
« Reply #116 on: September 19, 2019, 12:41:01 PM »
All of this is of little use for the average user.

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

Quote
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.
« Last Edit: September 19, 2019, 12:46:38 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline TribbleSmasher

Re: Os 3.2 development preview
« Reply #117 on: September 19, 2019, 12:58:24 PM »
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
Quote
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:
;) :o

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.
« Last Edit: September 19, 2019, 01:19:13 PM by TribbleSmasher »
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #118 on: September 19, 2019, 02:07:54 PM »
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.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #119 from previous page: September 19, 2019, 02:44:21 PM »
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
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.
« Last Edit: September 19, 2019, 02:46:48 PM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS