Os 3.2 development preview

[CBH]

(Will there be a PPC product line? I do not know.)

In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

[CBH]

In itself that's quite a bold statement for a developer of a hyperion product. I'm glad I never moved away from the 68k.

No, it just means what I said: "I don't know". Nothing more, nothing less.

If there was going to be a 4.2 you'd know for sure. It's normal to always expect that there will be a new version of a successful OS, if there's any room for "not knowing" it can only be for bad reasons.

Imagine if we could've skipped the PPC misadventure. We could've had 3.1.4 or equivalent 18 years ago. Are you getting paid this time around?

[CBH]

I struggle to see the problem with correcting and extending the operating system in a backwards compatible way. Other than bugfixes, it's the entire point of making a new release.

It's definately better than the 3.5/3.9 approach of "here's some shit we downloaded off amibay, hope you have a thousand euros worth of upgrades to run it properly".

[CBH]

@CBM

You know who wrote a lot of that “shit” that was tossed into OS 3.5 and 3.9?

Also a lot of that “shit” is what is now further developed in OS 3.2 - 3.1.4 was not a “clean cut” start from OS 3.1 sources, many components came from OS 3.9, because why not.

The shit in question is not updated OS components, those are a good idea.

The shit I mean is all the extra bundled stuff trying to make amigas dress up like a PC running windows 98. preinstalled glowicons, the dock, a cd player and a winamp clone both with hideous skins. This stuff is no use to anyone as it needs an RTG environment and fast CPU to be useful (open the CD player and watch your chipram vanish), and there's better alternatives out there.

These releases didn't improve the OS functionality where it counts (RTG, RTA, TCP/IP), it just included third party solutions on the CD. I can download Picasso96, I don't need pay someone for it on a CD.

Compare this to 3.1.4/3.2 which are purely about improving the OS itself, not throwing it into a package with some third party stuff.

[CBH]

For intuition, we have to use a special trick because it is already initialized. 3.2 will come with intuition 47 in ROM. For those that need to use CyberGfx, System-Startup checks the boot volume - and only there - for intuition v40 in LIBS:

Ah, so everyone's first thought on 3.1.4 release

[CBH]

And another warning: Some people still use IDEFix. First, this is unnecessary as the scsi.device implements ATAPI now fine

As of 3.2 or 3.1.4?

[CBH]

I am not aware of several different protocols - could you elaborate?

Several variants exist how such adapters identify themselves as being present.

Someone is going to have to do something eventually. IDE splitters being incompatible with the OS drive handling improvements means that the people most interested in those improvements can't use them.

Even something basic for the scsi.device to say "hey is there any more IDE ports down there?" so that something third party can yell back "over here, here's how you talk to them" -hopefully without needing a reboot.

Else we're forever going to see the new os refinements, cd filesystem etc ignored in favor of inserting elbox disk and clicking next repeatedly until all the drives start working.

[CBH]

Why don't you talk to Elbox then? It's their product, and it's their duty to keep it updated. Is there any reason why the work of third party developers has to be offloaded to the core development team? We cannot even maintain their product - there is no specification I have, there is no hardware to test with we have, we cannot give any guarantee that such a code would be correct.

So, frankly, how could this possibly work? A hardware developer not taking his products and clients serious, but we should help out to fill the gap?

The answer you seek is in the post you replied to

Someone is going to have to do something eventually. IDE splitters being incompatible with the OS drive handling improvements means that the people most interested in those improvements can't use them.

Even something basic for the scsi.device to say "hey is there any more IDE ports down there?" so that something third party can yell back "over here, here's how you talk to them" -hopefully without needing a reboot.

Else we're forever going to see the new os refinements, cd filesystem etc ignored in favor of inserting elbox disk and clicking next repeatedly until all the drives start working.

Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.

[CBH]

What specs do you think was followed for implementing the support in Linux, NetBSD, AROS, Minimig, UAE etc?

Once again: I DON'T KNOW AND I DON'T CARE. This is not Linux, NetBSD, AROS Miniming or UAE.

THOR: there's no solution to this problem. It's totally impossible, insurmountable problem
kolla: what about this well proven solution?
THOR: I DON'T KNOW OR CARE ABOUT SOLUTIONS

[CBH]

Any solution requires both you and third parties to work together, even if it just means you giving them an API to write their stuff to. If you don't put out the olive branch then the userbase will continue to throw your scsi.device in the trash.

But that is exactly the problem: There is no API at the scsi.device level to get that supported.

That is exactly the point, numbnuts. There is no API for scsi.device right now.

However: YOU ARE A DEVELOPER. YOU COULD MAKE ONE.

That's all you would have to do. You don't have to include OS support for IDE splitters or buffers, you just need to provide an API for third parties to develop this support themselves.

99% of the functionality the third party hardware/software provides is now in your updated AmigaOS. All we want is a safe way to enable the last 1% ourselves. Otherwise we have to throw away your 99% and your endeavour was pointless.

As it is this is my compromise argument, where you don't have to support any hardware you already don't, just provide a new (and rather small) API. But as kolla points out your arguments against actually supporting such thirdparty HW is bad - you say there's no specs and it can't be tested properly, but it's all documented and implemented by everyone else 100%, so it's obviously not that hard. "I don't care" is not an adult response to being proved wrong.

[CBH]

Great. And then how do we get /generic vendor/ to support it?

Just to remind you: The problem is with the existing hardware that has been abandoned by its vendors. So how likely is it that this strategy will help users?

If you build it they will come, who "they" is doesn't matter.

I don't consider this hardware to be abandoned because it's still made and sold. They see no software updates because there is, until the OS changes in a usefully relevant way, nothing for them to update.

[CBH]

There is some logic in some branches of Os 4 that attempts to identify them, and actually, more than one. I don't know why I need this, I don't know how they work exactly, I don't know how the drive switch works, and I have no hardware to test with. My experience with Os 4 source is "rather mixed", so I don't grab something and "hope the best".

Do you finally understand why I don't want to merge some untested code into the development branch without having a chance to test that it does what it was supposed to do, and validate that it works as it should?

In England if we don't understand something at work, we can ask a coworker who knows about it. Perhaps not a German tradition?

[CBH]

perhaps you can test it by writing an ide splitter driver which uses it

it would go well with the 68030.library nag screen that goes away when we install your third party mmucrap.

[CBH]

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

[CBH]

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?