@agami

Quote:

Attacking ppc hardware is senseless. After all, AmigaOS 4 doesn't suck because ppc sucks, it sucks because Hyperion doesn't care to make it very good.

*slow clap*

(And porting it to 68k wouldn't make it any better.)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Would it be that slow even on pistorm with native GFX drivers?

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@matthey


Quote:

David Patterson suggested that rather than ucode, "the entire system performance might improve more if silicon area were instead used for on-chip caches, larger and faster transistors, or even pipelining." The Case for the Reduced Instruction Set Computer https://www.cs.utexas.edu/users/fussell/courses/cs352h/papers/risc.pdf

RISC is good for building small CPUs.

Pro-RISC academics don't care about the customers' software investments when their expenses are paid by taxpayers and student fees.

Most embedded CPU deployment has a single-purpose use case, hence the customer's legacy software library investments weren't a high priority.

Quote:

At that time, some CISC CPUs wasted too much silicon for complex and specialized instructions and addressing modes.

When RISC first came out, X86 was half microcode i.e. half of the chip was ROM'ed.

Quote:

This did not leave enough space for ILP performance enhancements which RISC savings allowed. RISC could do more with less and had a performance advantage for a short time until Moore's Law kicked in. It's not like ucode is evil and takes over as different amounts of it can be used. SuperH used ucode and still had small RISC cores with early caches. The ucode may have even been used for 68k like features of SuperH, or at least 68000 like features seeing as how Hitachi was a 2nd source supplier of the 68000.

It depends on the ROM'ed microcode area vs actual compute hardware on a given chip area.

Last edited by Hammer on 25-Apr-2024 at 12:03 AM.
Last edited by Hammer on 24-Apr-2024 at 11:55 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

In 1984, the 68000 price had already dropped to about $15 for his dream CPU. I'm not sure how much the 80286 cost but the wiki says the higher clocked 10MHz version was released in 1985 for $155 although there are large markups for up clocked chips, especially when first released. I have DataQuest data for 1990 where the 68000 was still cheaper (ASP). 68000 $6 68008 $7 80286 $16 Motorola had economies of scale for the low end 68k chips because of the embedded market. C= leveraged these embedded chips well but, failing to use higher end 68k CPUs too, left only high margin Apple against IBM compatibles and there was inadequate economies of scale to lower prices for high end 68k CPUs. The 80286 would have been more expensive to use as well. The 68000 interrupt handling was better while Intel had a separate chip.

80286 had MMU, hence functional Xenix 286.

https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf
Page 119 of 981

For 1992
68000-12 = $5.5
68EC020-16 PQFP = $16.06, it's $15 in 1993 Q1.
68EC020-25 PQFP = $19.99, it's $18 in 1993 Q1.

68EC030-25 PQFP = $35.94 (no MMU)
68030-16 CQFP = $70.00
68030-25 CQFP = $108.75

68EC040-25 = $112.50 (no MMU, no FPU)
68040-25 = $418.52

From 68EC020 or higher, the 32-bit front-side bus is enabled with MMU being an optional premium.

68LC040 is not listed in Dataquest's price guide.

---
Competition
80286-10 PLCC = $4.50
80286-16 PLCC = $7.64

386SX-16 PQFP = $47.4
386SX-20 PQFP= $61.60

AM386-40 = $102.50
386DX-25 PQFP = $103.00

486SX-20 PQFP = $157.75 (no FPU)
486DX-33 = $376.75
486DX2-50 = $502.75

All X86 CPUs from 286 have MMU while 386SX has a cost-reduced 16-bit front-side bus.

Commodore had deep discounts for 68EC020.

For 68040-25 wasn't price competitive against 486DX-33 in 1992.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@pixie

Quote:

Would it be that slow even on pistorm with native GFX drivers?

Is "speed" all that matters?

My point is that OS4 is a big bloated mess, without bringing anything to the table, so to speak.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @agami *slow clap* (And porting it to 68k wouldn't make it any better.)

I agree, porting it to high-performance 68k would not make the OS any better, but it would make it available to a user base orders of magnitude larger.

_________________
All the way, with 68k

Hammer Quote:

80286 had MMU, hence functional Xenix 286. https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf Page 119 of 981

See page 564 of your Dataquest link above for historical prices.

year | 80286 | 68000 | 68020
1985 $72.00 $10.40 ?
1986 $48.00 $9.50 $184.00
1987 $47.00 $5.25 $125.00
1988 $32.00 $4.30 $106.50
1989 $16.37 $3.24
1990 $9.37 $3.32
1991 $6.54 $3.81

The launch price of the 80286 in 1982 was $150 and the 68020 launch price in 1984 was $487 according to various sources. The 68EC020 didn't come until 1991 so no lower priced option until then. Atari considered the 68000 to be too expensive for a video game machine in the early 1980s at around $100. When Amiga development was in the early stages of 1983-1984, the 80286 was likely over $100 while the 68000 was $15 in 1984. The 80286 price may have been acceptable for a high end PC for the classes but it was expensive for a video game machine with custom chips designed to offload the CPU for the masses. The 68000 was still competitive with the newer 80286 and was superior in several ways.

Last edited by matthey on 25-Apr-2024 at 04:41 AM.

@agami

Quote:

but it would make it available to a user base orders of magnitude larger

Indeed, that was the point. If it could be run in a way not that slow, introduce more software into a larger platform it could have some positive impact overall.

Last edited by pixie on 25-Apr-2024 at 06:56 AM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Hypex

Quote:

Hypex wrote: Also, I found MorphDOS, as I call it, is not AmigaDOS compliant. DOS scripts go faulty on MOS. I found writing a script working on both AmigaDOS and MorphDOS was a lot of work.

Uhmm... do you mean "MorphDOS" isn't AmigaDOS v4.x compliant, with extensions that's been made after 3.1/3.9? Because in my experience MorphOS is very AmigaOS 3.1 compliant regarding DOS support, and that's been the goal of MorphOS developer always.

I have written many 3.1 compatible scripts and never had any issues on MorphOS with them. They've always worked on both MorphOS and OS4, but the only compatibility issues have been with AROS and Hyperion's OS 3.x (3.1.4 - 3.2).

In any case if you aim for multiplatform scripts, it's better to stick with 3.1 standards. After that everyone has gone in their own directions with new DOS commands etc. There aren't common agreements for new AmigaDOS (or any other) features and OS4 developers don't look what's been made in MorphOS, and vice versa.

But if you know any incompatibility with OS3.1 scripts, please make bug reports to the MorphOS team and they'll fix it quickly, because they really care about backwards compatibility to Commodore's OS versions.

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

@agami

41 years ago in 1983 Jay Miner and his team choose 32 bit big endian cpu as Amiga cpu.
No 16 bit little endian, no 8 bit but 32 bit big endian cpu.
accept that and stop trolling.

Last edited by ppcamiga1 on 25-Apr-2024 at 10:10 AM.

@matthey

stop trolling

@Karlos

We amiga users use ppc amiga because it works like amiga from commodore
only better because hundreds or even thousand times faster. accept that.

if you want to switch to pc which means x86 or arm provide something worth of use on pc
something no more than 10 years behind windows macos android.

stop trolling and start working

@jPV

AROS has incompatbilities at DOS in comparation to 3.1? Where? Do you know examples? I would look at it because I work on a new version of my distribution and one of the goals is to get it compatible to AmigaDOS. And I would report it to get it fixed.

@ppcamiga1

Quote:

We amiga users use ppc amiga because it works like amiga from commodore only better because hundreds or even thousand times faster. accept that.

There's no bad hardware, only bad prices. PPC in itself isn't the problem....

Quote:

if you want to switch to pc which means x86 or arm

The irony being that arm is big endian, remember... The CPU kind Jay Miner has chosen... ?

Quote:

41 years ago in 1983 Jay Miner and his team choose 32 bit big endian cpu as Amiga cpu. No 16 bit little endian, no 8 bit but 32 bit big endian cpu.

Last edited by pixie on 25-Apr-2024 at 09:11 PM.
Last edited by pixie on 25-Apr-2024 at 03:08 PM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

kolla Quote:

Is "speed" all that matters? My point is that OS4 is a big bloated mess, without bringing anything to the table, so to speak.

AmigaOS 4 may be a big bloated mess but I believe it brings many things to the table that can be used for enhancing the 68k AmigaOS. There are parts that need to be changed and changed back to be more compatible. AmigaOS 4 for the 68k would not be fully compatible with AmigaOS 4 for the PPC but there are advantages to making them more similar. For example, more similar APIs should simplify the porting of the AmigaOS 4 version of NetSurf to the 68k. The 68k AmigaOS developers are rumored to already benefit from back porting parts of AmigaOS 4 to the 68k AmigaOS while avoiding much of the bloat. Is there enough to gain with the legal nightmare of Hyperion which is now bankrupt or will development have to start over like after AmigaOS 3.9? I don't know.

agami Quote:

I agree, porting it to high-performance 68k would not make the OS any better, but it would make it available to a user base orders of magnitude larger.

Jay Miner made the 68k Amiga for the masses not the classes. Recent revelations are looking more and more like Trevor and his fixer Ben stole the PPC AmigaNOne for the elite classes not the masses. After 20 years of PPC AmigaNOne failure, Trevor is down to producing a few hundred units of the A1222+ without a standard FPU or SMP for AmigaOS 4 that promotes 3D capabilities. A $15 RPi Zero 2W outperforms this junk for a tiny fraction of the cost. Can it get anymore elitist or absurd?

ppcamiga1 Quote:

41 years ago in 1983 Jay Miner and his team choose 32 bit big endian cpu as Amiga cpu. No 16 bit little endian, no 8 bit but 32 bit big endian cpu. accept that and stop trolling.

The 68000 is not a 32 bit CPU.

68000
16 bit ALUs and internal data paths
16 bit data bus
24 bit address bus (32 bit addresses in registers and memory)
32 bit registers (16x 32 bit GP registers)
32 bit max integer datatype size

The classification of a CPU is based on data bits not addressing bits making this a 16 bit CPU. Motorola called it a 16/32 bit CPU because it is clearly more powerful than a typical 16 bit CPU and the 32 bit ISA makes a 32 bit CPU upgrade easier and higher performance. We can compare to the 80286 which some people wish Jay Miner had selected instead.

80286
16 bit ALUs and internal data paths
16 bit data bus
24 bit address bus (16 bit addresses + 16 bit offset/segment)
16 bit registers (7x 16 bit GP registers)
16 bit max integer datatype size

The IBM PC designers messed up selecting the 8 bit 8088 which is inferior to the 80286 when the 68000 could have easily been used. Jay Miner did not make the same mistake. The 68000 was greater than 80286 but IBM was greater than CBM even with IBM's poor CPU selection for the IBM PC. IBM made several mistakes with the IBM PC but CBM was too incompetent to take advantage. Jay Miner was a great visionary who foresaw integration making the 68k Amiga possible and competitive technology into the future while CBM ignored him and was only focused on cost reducing the Amiga down to a C64 replacement and when it finally got there it was obsolete and CBM was bankrupt.

Last edited by matthey on 25-Apr-2024 at 04:21 PM.

@matthey

Quote:

matthey wrote: We can compare to the 80286 which some people wish Jay Miner had selected instead.

I hope you're not referring to me.
I don't wish that Jay Miner chose the 286, I was more just wondering since the essentials of the Amiga is more in the OS & custom chips than it is in the CPU, could the A1000 not be achievable with another 16-bit CPU, such as the 286 (were it available in the same time-frame) or the Z8010.

_________________
All the way, with 68k

@agami

I agree, porting it to high-performance 68k would not make the OS any better, but it would make it available to a user base orders of magnitude larger.

I'm not sure where the draw would be.. The OS has been effectively dead for so long now (minus tweaks to make processors work and work outside of the OS for video drivers), what is the point? I do give credit to those who still hang on and develop software for OS4. They seem to be a tight group that just enjoy what they have and move on.

I don't even have interest in 3.x these days and still prefer 3.1/.9 for some things.

As mentioned the hardware is not at all the issue, so attacking the PPC hardware makes little sense. When all the problems are in the OS and software around it.

@Karlos
"PPC doesn't suck at all. Neither do OS4 or MorphOS. What sucks is the situation that PPC is as dead as a doornail and that OS4 and MoprhOS are nailed to the wall with that doornail."

The issue isn't so much that PPC is dead, it's that OS4 is dead.

But it would greatly help the narrative if some movement on the OS4 front was positive and progressive. I mean just touching the code to make a processor work being the only change to the OS in a ton of years really isn't much to hang your hat on... I get it that all new code has to be written to try and stay away from drive by attorneys and by not paying enthusiast coders that may or may not have any experience with the original OS to begin with. Even if they got multicore working, it would be something but I suspect given the many years of delays that will never reach the light of day...

Last edited by Matt3k on 26-Apr-2024 at 04:01 AM.
Last edited by Matt3k on 26-Apr-2024 at 03:59 AM.

@NutsAboutAmiga

Quote:

Most people talking about this topic, don’t understand it, but this YouTube video explains a lot of it.

Ah, the HackADay x86 must die. Where someone also commented that RISC is inside CISC. The beat goes on.

Well, his big claim is a big bluff really, because his argument isn't for x86 to die at all.

His argument is based on removing legacy code and cleaning it up. So that it just supports modern features and codes. So, in a manner of speaking, what he wants is a pure x64 ISA. And also, x86 is already dead, x64 replaced it.

@OlafS25

Quote:

OlafS25 wrote: @jPV AROS has incompatbilities at DOS in comparation to 3.1? Where? Do you know examples? I would look at it because I work on a new version of my distribution and one of the goals is to get it compatible to AmigaDOS. And I would report it to get it fixed.

Unfortunately I haven't made any proper notes about the issues I've come across and I didn't also investigate issues deeply enough to make actual bug reports. Hard to remember them now...

When googling a bit now, I found my report about non-working STDERR redirection here. I've thought it's been on AmigaDOS "always", but now I got a bit uncertain that has it actually been in 3.1... at least it does work on AmigaOS 3.9, OS4, and MorphOS. In any case it's a bit annoying when AROS has some Unix ported programs, even crucial ones like LhA, that usually do output to STDERR, and you can't capture that output in any way on AROS.

Then I've had issues with some shell commands, like the Which command not finding all files it should, IIRC it didn't even find some commands from SYS:C/ ... but as said, I didn't investigate them better and just skipped with work-arounds. Maybe these could be related to which platform you run AROS on... emulated, hosted, real hw?

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO