@Rob

szulc should work for free on mui on aros
instead of wasting time on trolling and emu68

@matthey

mui is one and only part of Amiga os worth use on x86 and arm
and original cannot be used because of legal risk
so the only way forward is to hard work on mui clone on aros
stop trolling start working

@ppcamiga1

MUI is not a part of AmigaOS, it's a third party contribution. It is a part of MorphOS.

_________________
Doing stupid things for fun...

@ppcamiga1

Quote:

szulc should work for free on mui on aros

Ha, ha ha! I told you, i have so much laugh reading your ridiculous farts of your brain :) you are the best!

Btw, MUI was never part of AmigaOS, Reaction was and is part of AmigaOS. Go, learn a bit :)

terminills Quote:

option 3 is dead in the water and not as many people want it as you seem to think.

Option #3 has not been attempted. It has not been properly investigated, evaluated, developed or backed. Option #2 has been attempted with AROS x86-64 and has failed to gain momentum despite powerful available hardware with more desktop features than AmigaOS 4. Maybe the "AmigaOS" name would be somewhat more successful but the market would likely be divided between AROS x86-64, MorphOS x86-64/ARM and AmigaOS x86-64/ARM with the latter being late to the game and needing to sell adequately to pay for development. Expensive x86-64/ARM Amiga hardware like PPC hardware is unnecessary so Amiga NG survival would be based solely on OS software development in a market with many free alternatives with better desktop features. Option #3 can continue until the Amiga disappears but it is no more NG than AmigaOS 4 with only better performance and I/O support but lacking more modern OS features.

The 68k Amiga market is no doubt larger than the current Amiga NG market. There are likely many tens of thousands of 68k Amiga users/customers compared to a few thousand Amiga NG users/customers. The 68k Amiga hardware available has so far been lackluster and could be better value and cheaper increasing the market size. A 68k SoC ASIC would allow to dominate, unite and expand the 68k Amiga market. Back Porting AmigaOS 4 to cheaper 68k hardware is easier and more compatible than porting it to a new LE architecture. AmigaOS 3 could be developed as far as it can go with AmigaOS 4 improvements while retaining compatibility and a true NG AmigaOS with compatibility breaking improvements like SMP support, process isolation and improved security could be alternately booted into on the same hardware. The choice between option #3 and option #2 is to leverage the large retro 68k Amiga market or to further divide the tiny AmigaOS NG market.

@matthey

Quote:

Option #3 has not been attempted. It has not been properly investigated, evaluated, developed or backed.

Why is that, do you think?

_________________
Doing stupid things for fun...

@matthey

Quote:

Option #3 has not been attempted. It has not been properly investigated, evaluated, developed or backed.

There were license clones for many 68000 and a few 68020. 68000 license cloners are Hitachi, Rockwell, Signetics, Thomson/SGS-Thomson, and Toshiba.

None of the 68K licensees has a CPU R&D depth like x86 cloners like AMD, NextGen, Cyrix, and VIA.

The Richardson, Texas office of VLSI Technology was also instrumental, as they provided workstations, EDA tools, and ASIC design expertise to Cyrix engineers for their early design work.

VLSI Technology also aided Acorn's initial ARM R&D.

https://www.rocelec.com/part/01t4w00000PPjCGAA1-MC68040FE33A
Rochester Electronics' 68040 @33 Mhz license clone for $350.64 for 1 to 24 units. $298.04 for 1000+ units.


------------------------------------
For Amiga's context, VLSI Technology aided the A500 Gary's logic gate array design since CSG is slow.

Commodore - The Final Years,

CSG was able to produce Agnus, Denise, and Paula for $5.49, $5.19, and $7.91 respectively.

Curiously, Gerard Bucas did not trust CSG to produce the Gary chip on time. “MOS Technology, I would say, eventually became a millstone around Commodore’s neck,� he
says. “Jeff Porter and I, but especially me, decided, ‘Listen, I'm not going to do the gate array with them. I don't believe they can meet the timeline and I don't believe they can make it in volume at the right price.’�

This was not politically popular at Commodore, but Bucas felt it was the correct move. “We designed it, but the manufacturing of that, we actually outsourced to someone else,� he says. “We outsourced the chip to VLSI Technology, which was a third-party chip company.�

It was up to Bucas to negotiate with suppliers and make sure Commodore received the best prices. A few years ago, the 68000 sold for $15 in quantity. Now Bucas negotiated it down to $5 per unit. “I was personally responsible for every component that was more than fifty cents,� he says. “Jeff Porter’s nickname for me was ‘the Dutch trader’.


Amiga's Gary chip was part of the cost reduction improvements.

ARM Ltd was formed in 1990 as a semiconductor intellectual property licensor, backed by Acorn, Apple, and VLSI.

Last edited by Hammer on 25-Dec-2024 at 01:57 AM.
Last edited by Hammer on 25-Dec-2024 at 01:57 AM.
Last edited by Hammer on 25-Dec-2024 at 01:55 AM.

_________________

@Karlos

Quote:

Where does the boundary between Amiga-like end and posix-like begin? Could a system be both?

I don't think so, it would too confusing. Much like when Mac went from Mac OS to OSX they dumped Mac path semantics. Mac paths are separated by a colon, OS/UniX used slashes. I don't recall Mac paths being accepted at all, even though there should be no clashing.

On OS4 there is no shell I'm aware of that can run any configure script. ABC shell is the closest that with both Amiga and Posix path semantics. But it eventually fails to convert paths because both colons and slashes are used in both which clashes.

Quote:

If the only way to run legacy AmigaOS applications (including older 32-bit PPC binaries for WarpOS etc) is by whole system emulation and newer software ends up being mostly ports of software from Linux, etc, at what point does it just become better to just run Linux and UAE on commodity hardware than on expensive PPC kit?

Although integration was a feature initially, it might be time to sand box. MorphOS sand boxed it and from a user point of view I could not tell the difference.

I thought it strange at first, but when I saw how OSX ran Mac apps, it first booted Classic OS then the apps could run as part of the system. It still seems strange now, booting an OS, then it disappears and old looking apps open up. Perhaps something like that is needed, a classic environment, that launches itself to run the apps sand boxed.

It may be similar to a UAE, then it hides, and apps after appear in the system. I don't think it would need to be as complicated as booting an old OS to run apps. Just enough that a isolated environment could be set up to run older apps. And as it happens, to also run OS4 native PPC apps. On a newer cleaner OS design both 68K and PPC would need sand boxing, likely together, the way I see it.

@Hans

Quote:

There are also those who want me to bend over backward and practically sacrifice myself for the cause of enabling modern GPUs to warm-reboot. Yep, warm rebooting is such a "killer feature" that no expense must be spared to maintain it.

I know I've been over this but why does the graphic chipset need to be warm booted? Why can't it just stay on or have screen mode changed? It seems to me resetting a working chipset is over the top. There should be a way to retain existing display without disturbing if a warm reboot is not a full reboot.

Related, I noticed that my laptop puts the display to sleep, then wakes it up. So, it puts the graphic chipset to sleep, then later wakes it up. My point was that it is similar to warm boot, in that a working chipset is suspended, then later brought back up without a full reset. At least it looks like it's being brought up without a full reboot since the system state is restored. So, could this then need Radeon mobility features? I suppose desktop cards would lack mobility features that could help.

Last edited by Hypex on 26-Dec-2024 at 01:56 AM.

@Hypex

Back in the days NetBSD had a /dev/reload and if you output a kernel to that device, the system would warmboot to that new kernel without resetting the hardware (akin to kexec on Linux), the new kernel output would just continue using the existing framebuffer output and you could scroll back the to output from before the warmboot. Oh, and this was on Amiga (A1200, Blizzard 1230 III at the time)

Last edited by kolla on 25-Dec-2024 at 02:43 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hypex

You don't notice the sandboxing in MorphOS because the entire thing you think of as MorphOS is in a sandbox - the ABox. Lower down, Quark is what's running the show and providing the hardware abstraction. As far as I know, it's an L4-type kernel and has no issues with 64-bit or SMP and can theoretically run multiple such sandboxes concurrently. But it doesn't (at least in the end user versions), it just runs the ABox and inside the ABox, you've got an exec.library implementation running the show. Trance provides the 68K emulation in a manner broadly similar to how Petunia does it in OS4, with the ability to call native ppc libraries from 68K and vice versa.

You never really see or interact with Quark, but I assume it's very relevant to the core team when adding support for new hardware.

That's all from memory, but I'm sure there are people here that can correct it if I've made any mistakes.

_________________
Doing stupid things for fun...

@kolla

Sounds like a security nightmare in 2024 :D

_________________
Doing stupid things for fun...

@michalsc

szulc stop trolling and start working on mui on aros

@Hypex

Quote:

Much like when Mac went from Mac OS to OSX they dumped Mac path semantics.

Many years ago I have mac ppc with Mac OS X 1.0 and on 1.3
Mac OS X up to 1.3 support old Mac path semantics in carbon apps.

Quote:

Where does the boundary between Amiga-like end and posix-like begin? Could a system be both?

yes
geek gadgets on Amiga 3.x has translation from amiga paths to unix
newlib on Amiga 4.x also

@Hypex

Quote:

On a newer cleaner OS design both 68K and PPC would need sand boxing, likely together, the way I see it.

I agree. On x86 or arm everything below MUI should be cut off.
Old software should be put to sandbox.

@ppcamiga1

What about BOOSI and Intuition?

Merry Xmas.

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: The 68k Amiga market is no doubt larger than the current Amiga NG market. There are likely many tens of thousands of 68k Amiga users/customers compared to a few thousand Amiga NG users/customers. The 68k Amiga hardware available has so far been lackluster and could be better value and cheaper increasing the market size. A 68k SoC ASIC would allow to dominate, unite and expand the 68k Amiga market.

We can already do the equivalent of 68k SoC ASIC with FPGA or bare metal software emulation, so what is the actual market for this chip? I doubt it's enough to justify the expense, so it won't be better value and cheaper.

Quote:

Back Porting AmigaOS 4 to cheaper 68k hardware is easier and more compatible than porting it to a new LE architecture. AmigaOS 3 could be developed as far as it can go with AmigaOS 4 improvements while retaining compatibility

Agreed. And some of us won't even go that far. My A1200 is stuck on 3.0 and A500 on 1.3 because I need compatibility and can't see any reason to 'upgrade'.

Quote:

and a true NG AmigaOS with compatibility breaking improvements like SMP support, process isolation and improved security could be alternately booted into on the same hardware. The choice between option #3 and option #2 is to leverage the large retro 68k Amiga market or to further divide the tiny AmigaOS NG market.

Who cares if the NG market gets divided? Let them do whatever they want (provided they leave us alone).

@Hammer

Quote:

Hammer wrote: Curiously, Gerard Bucas did not trust CSG to produce the Gary chip on time. “MOS Technology, I would say, eventually became a millstone around Commodore’s neck,� he says. “Jeff Porter and I, but especially me, decided, ‘Listen, I'm not going to do the gate array with them. I don't believe they can meet the timeline and I don't believe they can make it in volume at the right price.’� This was not politically popular at Commodore, but Bucas felt it was the correct move. “We designed it, but the manufacturing of that, we actually outsourced to someone else,� he says. “We outsourced the chip to VLSI Technology, which was a third-party chip company.�

A smart move. Gary was a consolidation of TTL logic that suited a 'standard' gate array. I'm not sure about the VLSI Tech reference though. Early A500's had a Toshiba Gary chip, which was buggy. Later Gary chips are marked MOS or CSG.

Perhaps Bucas or Bagnall got mixed up here. On page 358 of "Commodore the Final Years" Bagnall says:-
Quote:

"On March 19, Robbins finished the the design... for Budgie (a budget version of the Bridgette chip... By May 18 1992, Robbins had all the schematics completed for the gate array chips and his motherboard. Unlike previous Amiga computers, the gate arrays would not be manufactured by Commodore. Ted Lenthe began looking for a company to manufacture the Budgie chip, offering bids to... VLSI Technology, with the latter winning the bid".

Quote:

Hammer wrote: Amiga's Gary chip was part of the cost reduction improvements.

Yes, along with putting more stuff in Agnus. Jay Miner was skeptical, but 'fat' Agnus worked as intended.

@ppcamiga1

Copy-And-Paste is boring, you can do better.
Merry X-Mas :)

Last edited by michalsc on 25-Dec-2024 at 10:04 PM.

matthey Quote:

Option #3 has not been attempted. It has not been properly investigated, evaluated, developed or backed.

Karlos Quote:

Why is that, do you think?

Originally, there may have been an understanding by the Hyperion, A-Eon and AmigaKit alliance that the retro 68k Amiga was Cloanto's licensed area and not particularly valuable. Then THEA500 Mini was released showing a much larger retro market and Amiga Corporation was created. This is when the HAA alliance went from ignoring and road blocking the retro 68k Amiga market to force Amiga users to upgrade to expensive NG Amiga hardware, to competing in the 68k Amiga market. Hyperion started selling 68k kickstarts and then the 68k AmigaOS to survive where PPC AmigaOS 4 was not profitable. AmigaKit started selling the A600GS and A1200NG. A-Eon is the only member of the HAA alliance that has stuck to PPC even with outdated PPC silicon and users realizing PPC Amiga1 was not anymore NG than higher performance 68k Amiga hardware with more modern I/O. PPC AmigaOS 4 SMP is likely impossible after more than a decade of development and looks like a scam. There is no 64-bit support or process isolation either for a "desktop" OS. PPC Amiga1 had slipped to retro too and 68k Amiga hardware has better compatibility, a larger market and is cheaper.

Arrogance and incompetence led to this point. The problems started with how Hyperion strong armed and illegally coerced a financially distressed Amiga Inc., likely with Trevor/A-Eon funding instead of buying the Amiga IP like was done later for Amiga Corporation. The shenanigans, uncertainty and financial draining lawsuits reduce the chances of the needed investment to become competitive. Amiga Market analysis was likely inadequate. Targeting the desktop market with an inadequately enhanced AmigaOS was a mistake and PPC was a poor choice for the embedded market. Micro production is not competitive with mass production. There is minimal innovation. The importance of compatibility was greatly underestimated. The Hyperion, A-Eon, AmigaKit alliance is disorganized. Trevor is too rigid, narrow minded and stubborn to lead. Ignoring and encroaching on Michele business owned Amiga IP has been a huge mistake as Michele has outmaneuvered the alliance. Instead, Ben was allowed into the alliance and his shenanigans were a major liability. A-Eon's conman like false promises and behind the scenes unethical funding makes Trevor far from an "angel" investor. AmigaKit aggressively challenges Amiga IP with the use of "Amiga Store", "AmigaKit", "A1200", etc. including with computer hardware. The alliance reputation is ruined and the broken business model and lawsuits have drained finances. They should give up, end the embarrassment and let the Amiga IP and AmigaOS 4 owner do something for the benefit of the Amiga rather than sabotaging the Amiga.

bhabbott Quote:

We can already do the equivalent of 68k SoC ASIC with FPGA or bare metal software emulation, so what is the actual market for this chip? I doubt it's enough to justify the expense, so it won't be better value and cheaper.

Emulated 68k performance is a fraction of native performance, made worse by different endianness and load-to-use stalls that do not exist on 68k CPUs. High performance FPGA CPU performance is even worse with clock speeds limited to about 100MHz in affordable FPGAs. Power and price are improved with an ASIC. Nothing else comes close to competing with the value of an ASIC. Memory requirements of native code are a fraction of JIT compilation allowing further reductions in price. There is no question of the huge ASIC value advantage but it does need mass production volumes which are less clear for the Amiga. ASIC production has risks while there is no risk in micro production for the desktop market which is guaranteed failure.