Welcome, Guest. Please login or register.

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

Description:

0 Members and 4 Guests are viewing this topic.

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #389 from previous page: December 05, 2019, 06:22:52 AM »
Ah, so the feature has already been made since 20 years ago but not enabled.

Can't wait for 3.3 where it is enabled, like 3.1.4's optional new intuition in 3.2
Once again, you have that feature already as of 3.1.4, and it will not be enabled by default.I am not clear about the details, but it seems that there were two reasons for that: First of all, it seems likely that H&P did not want to canibalize the Idefix market, and second, the detection algorithm does not seem to be 100% fool proof, it is a heuristic. So you have to get it enabled itself by a resident module of the name Gulliver already mentioned. It is equally easy to get one into the system, without modifying the kickstart.

It would be easy to write one, though our two "insult swordfighting heros" will probably continue to argue for another day instead of getting active themselves...
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #390 on: December 05, 2019, 06:38:07 AM »
Another day, another component: Graphics.

There is not much new about graphics. There are two old bugs we found, namely when attempting to render VSprites on a NULL ViewPort which caused MuForce hits. It seems unlikely that this happens, but there are a couple of games that load their own view by LoadView(NULL). If, at that point, you are still holding an icon on the workbench - happens quite easily by an erratic mouse button - and then quit the game, the workbench is already continuing to move the icon even though the graphics view is not yet loaded. The gels functions have been updated to handle this case now gracefully.

There is also some news on AllocBitMap() and RTG support. AllocBitMap() has been enhanced a little bit to use its "friend bitmap" pointer differently in case a specific "flag" combination is set. In such a case, the "friend bitmap" becomes a taglist, and carries information such on the display ID. Previous versions of the operating system act gracefully on this flag combination and return NULL, i.e. fail the allocation.

Now, why is this important? Consider an RTG graphics scheme where a software needs to open a screen in a non-native graphics mode. At this point, there is no "friend bitmap" because the screen is not yet open, yet the system calls into AllocBitmap() for the screen. AllocBitMap() is now patched over by the RTG software, and is supposed to take the bitmap to the graphics RAM of the RTG board. Unfortunately, it cannot really know as there has not been an indicator on AllocBitMap() where the screen is supposed to go, and which graphics mode it is going to be.

P96, at least, "went fishing": It looked at the stack frame from the call, used a heuristics, and if the heuristics said that the call is likely coming from intuition, it checked the stack frame for the display ID where it was laying around - by pure chance, not by design - and then used the display ID from there.

Of course, this is not a robust algorithm, and as the stack layout changed with intuition V45 as it was recompiled by another compiler, P96 would have been broken. So V45 of intuition contains a special "kludge", a short piece of assembler stub, that prepares a stack frame within OpenScreen() that looks like the one from V40, and then called into AllocBitMap() to make P96 happy.

Needless to say, this is all a fragile design and need to go, and so it does now. Intuition v47 (more to be said about this) uses now the new AllocBitMap() interface with tags prepared to list the display ID, and the latest P96 versions (2.3 and up) grab the displayID now through the new interface. Actually, this interface was already put into P96 years ago (around ~2000 or so), but wasn't activated as its counterpart in intuition and graphics was missing. Not any more.

It is likely that cgfx requires a similar kludge, probably for additional functions, but we don't know what exactly, and Frank hasn't reacted on the request to document them, so users of CGfx wil have to downgrade intuition to v40. Just put it in LIBS: and System-Startup will pick it up there. No need for reboot, but no new intuition functions either.
 
The following users thanked this post: Tygre

Offline ronniebeck

  • Newbie
  • *
  • Join Date: Feb 2018
  • Posts: 18
    • Show only replies by ronniebeck
Re: Os 3.2 development preview
« Reply #391 on: December 05, 2019, 12:28:40 PM »
@Thomas Richter
I am trying to get my head around how RTG is sticky tapped to AOS.  The more I read, including your comments just now, the more the feeling grows that at some point Amiga OS will need a clean approach to RTG.  Or perhaps better said, that RTG needs to be added as a fundamental assumption of graphical Libraries in Amiga OS.  Is my view valid or do you see it differently?  I guess my thinking goes into the direction of: if I want to have RTG, I am reliant on 3rd party libraries (P96 for example) and hacks (albeit well written and mostly reliable) to make traditional software work.  Does it make sense to so something in Amiga OS itself to do away with the need of such hacks?  Or ares such ideas best left to the realms of  OS4/AROS/MorphOS.......

Just curious how you see it technically.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #392 on: December 05, 2019, 02:19:53 PM »
The more I read, including your comments just now, the more the feeling grows that at some point Amiga OS will need a clean approach to RTG.  Or perhaps better said, that RTG needs to be added as a fundamental assumption of graphical Libraries in Amiga OS.  Is my view valid or do you see it differently?
That's difficult because there are two conflicting goals. Goal number 1 is to have a well-maintained architecture that is robust and extensible. The current construction of RTG graphics patching into the system and replacing half of graphics is not suitable to match this goal, even more so in that you depend on some third parties to keep their RTG stack updated. Goal number 2 is not to loose any customers because technical details how to support them are no longer available, and thus it becomes impossible to write drivers for them. My view is that #2 is more important that #1, but all within limits.

In a sense, we already have that because CGFx seems to be out of support and we have a situation where its owner is not willing to cooperate, so we try the best to work around this situation, but one has to apprecate that the further the project progresses, the more features users depending on CGFx will loose. For 3.1.4, it was the ability to drag windows out of the screen. For 3.2, it will be more (iconfication will be lost, some GUI decoration items will be lost), so it's not a way how we can possibly progress in the future.

Option #1 is, from the perspective of the software developer the better option because we would get rid of a lot of legacy junk in graphics, and would re-build a better system. But a better system helps little when it means that half of the user base cannot use their graphics cards anymore.

So, at this point, we can try to either convince CGfx owners to invest into udpating the system, hopefully by enough users winking with their pockets. If this is going to work, we'll keep the current "binary" system.
If that's not going to work, well, what can we do? We cannot wait forever, and then go for a new RTG system, probably integrating more and more parts of P96 into graphics to get a more consistent graphics library.

My personal view: Users first, go try to get CGfx active again, though I cannot do much here. It is a matter of the user base to become active enough to demand an update from CGfx.
But one thing for sure: The Os  will not be taken hostage of CGfx and the good will of some third parties. If this is not going to work, then 3.2 is probably the last version that has a fall-back for CGfx. I like to keep doors open as much and as long as I can, but not forever.
 

Offline kamelito

Re: Os 3.2 development preview
« Reply #393 on: December 05, 2019, 02:35:24 PM »
Aren’t all Amiga legacy gfx boards compatible with  both system?
If so they just need to replace CGX by P96.
How many CGX users bought 3.1.4? If the number is low then I don’t see a problem here.
Many OS upgrade from CBM broke 3rd party RTG so why change now? If F. Mariak do not care about its customers why should you?. We need to move forward and not create a kludge OS.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #394 on: December 05, 2019, 02:57:27 PM »
Aren’t all Amiga legacy gfx boards compatible with  both system?
No, that's not the case. For some boards, we don't have a P96 driver at all, or only in experimental stage (non-working). I don't have access to such boards, so cannot update the driver.
Also, note that some people use CGfx because it allows to drag screens, a feature P96 does not support.

How many CGX users bought 3.1.4? If the number is low then I don’t see a problem here.
I do not have any data on this, but 3.1.4 worked on CGfx.

Many OS upgrade from CBM broke 3rd party RTG so why change now?
The situation changed. We no longer have an "active ecosystem", but a "retrosystem". So users don't buy new hardware to get a better system, but to preserve what they have. That implies that we should avoid to break things because it conflicts with the goals of the owners of keeping what they have.

If F. Mariak do not care about its customers why should you?. We need to move forward and not create a kludge OS.
I believe it is a matter of his customers. I believe if enough of them would approach them, maybe he would move. If there would be sufficient money to be collected, to either provide specifications (i.e. what is exactly needed on the intuition side to get CGfx needed) or to upgrade CGfx, or to release its sources, or to find an independent developer, then the economic situation may make it worthwhile to invest into it, and Frank would be silly not to take the money.

So yes, I believe users could do something to get CGfx back in service. Or to help develop drivers for their cards on P96. Or get sufficient specifications to include kludges in intuition to keep CGfx happy.
Either solution works for me.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #395 on: December 05, 2019, 03:40:04 PM »
One should know that CyberGraphX is not abandoned, it lives on as part of MorphOS.
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
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #396 on: December 05, 2019, 05:23:45 PM »
One should know that CyberGraphX is not abandoned, it lives on as part of MorphOS.
That's abandoned enough for 68K users, I afraid.
 

Offline kamelito

Re: Os 3.2 development preview
« Reply #397 on: December 05, 2019, 07:38:14 PM »
 Back in the day a friend of mine got a Domino which was not working under AmigaOS 3.1 might be 3.0. I was tracing the crash under Monam with a prog of mine which basically disabled interrupt to trace the driver it was many long hours but in the end I didn’t really fixed it properly. A freemem call was crashing the driver so what I did was skipping the freemem but then the mouse pointer was not displayed but it didn’t crashed anymore then we had to return the card so I cannot go further.
 

Offline CBH

Re: Os 3.2 development preview
« Reply #398 on: December 05, 2019, 09:06:55 PM »
Back in the day a friend of mine got a Domino which was not working under AmigaOS 3.1 might be 3.0. I was tracing the crash under Monam with a prog of mine which basically disabled interrupt to trace the driver it was many long hours but in the end I didn’t really fixed it properly. A freemem call was crashing the driver so what I did was skipping the freemem but then the mouse pointer was not displayed but it didn’t crashed anymore then we had to return the card so I cannot go further.

And you were wearing an onion on your belt, as was the fashion of the time?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #399 on: December 06, 2019, 05:35:15 AM »
Another component: Intuition.

First, as already said, intuition OpenScreen() uses now the new graphics.library AllocBitMap() tags-based interface to allocate bitmaps from graphics, or from the graphics system, which is RTG friendly as all the missing parameters such as the target display ID are passed in.

We have two new intuition functions, namely ShowWindow() and HideWindow() which, well - as the name suggests - make an entire window visible or invisible. It can be used for iconification purposes. The functions are also present in AmigaOs 4.0, at the same LVO vector offsets, though the Os 4 implementation was rather hacky (not to say borken). Actually, someone took the code from my "tech demo" I made for the V45 layers library in 2002 or so and integrated exactly that code into intuition, though this was never considered to be the correct design for it as it did not integrate into the intuition state machine. It now does.

Concerning iconification, intuition gets a new first class citicizen window gadget you can request to get added to your window, and this is the iconification gadget. WFLG_ICONIFY enables it. If the user presses on the gadget, intuition sends an IDCMP_CLOSEWINDOW with a "CODE=1" instead of CODE=0 to the application, which can then react accordingly. All the system tools, preferences, utilities and the console window use it to iconify themselves on the workbench.

Off-window screen dragging was refined as windows show now a slight "persistence" to be dragged out of the screen. It can also be turned off in the icontrol preferences (though, I wonder, why would you want to turn it off...)

The frameiclass got another mode, namely "CONTEXTFRAME", which is the double-outlined frame with a headline on top. It is used quite a lot by the preferences editors, and gadtools. Which also means that the preferences will now lack some of their decoration if run with intuition v40.

We also made a slight change in the menu rendering. Mutual exclusive menu items are no longer rendered with a check-mark, but with a round circle - filled or unfilled - so they remind users a bit of the radio buttons - or look close to them. This makes it a lot easier to spot such items, and it should be quite immediate how they operate. The checkmark remains to be used for the "on-off" items.

Finally, intuition can now be expunged from memory, i.e. can be told to vanish. This is mostly useful for System-Startup where it is used to either update intuition to a new version, or downgrade it to v40 for the CGfx users.

 
The following users thanked this post: Tygre

Offline kolla

Re: Os 3.2 development preview
« Reply #400 on: December 06, 2019, 12:26:51 PM »
That's abandoned enough for 68K users, I afraid.
I would say it is the other way around - the 68k users were abandoned, not the software :-)

Anyways, considering history and all the badmouthing Hyperion people have served MorphOS and its developers, I very much doubt that anyone from "the blue side" has any interest in supporting anything that is related to Hyperion.

Another one of those things that may change if Cloanto wins the ongoing court cases.
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
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #401 on: December 06, 2019, 01:29:25 PM »
Another one of those things that may change if Cloanto wins the ongoing court cases.
No, because then a lot of other bad things will happen. Maybe you still do not understand, but as long as the two parties don't come to a mutual agreement, everybody looses.
 
The following users thanked this post: Tygre

Offline kamelito

Re: Os 3.2 development preview
« Reply #402 on: December 06, 2019, 03:31:11 PM »
@Thomas Richter is it planned to add memory protection as done in AmigaOS 4.x?
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #403 on: December 06, 2019, 06:00:26 PM »
@Thomas Richter is it planned to add memory protection as done in AmigaOS 4.x?
No, it's not.
 

Offline kolla

Re: Os 3.2 development preview
« Reply #404 on: December 06, 2019, 07:12:11 PM »
No, because then a lot of other bad things will happen.

Scaremongery much?

I don’t see anything bad about Cloanto taking over, only a lot of positive things.
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