Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A600 Memory

AuthorTopic: Os 3.2 development preview  (Read 29213 times)

0 Members and 8 Guests are viewing this topic.

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?
 

Offline Thomas Richter

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

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
 

Offline amigapassion

Re: Os 3.2 development preview
« Reply #109 on: September 18, 2019, 08:43:03 PM »
Great news!!
Offering Amiga 500,600,1200,4000,4000T as well as Amiga 500,1500,2000,3000 recapping services as well as minor repairs.
 

Offline Thomas Richter

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 ?
 

Offline Thomas Richter

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 »
 

Offline Thomas Richter

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
 

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 »
 

Offline Thomas Richter

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 on: 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