Quote:

megol wrote: The big thing about x86 have been the backwards compatibility so of course AMD wanted to show that their extension was compatible. But it was also not completely accurate as real mode (segmented 16bit* mode as in the 8086) wasn't supported and would require emulation. Note that e.g. Windows simply dropped MSDOS support in 64 bit installations for this reason. So even the architecture that have kept compatibility even when requiring extra effort have dropped complete compatibility. (* undocumented but supported is also a 32bit mode a.k.a unreal mode/extended real mode)

The AMD literature is a sales brochure. AMD64 could have been more compatible with x86 and had better performance and code density too.

http://www.emulators.com/docs/nx05_vx64.htm

It is funny that this article suggests a better x86 64 bit encoding but compares to the 68k giving the "Intel weaknesses". Cdimauro suggested the AMD64 ISA is inferior to his alternate encoding NEx64T ISA as well.

Quote:

However this is all something not really related to what I wrote which was about the Amiga situation. We have an operating system that doesn't support some things people expect, that makes porting software harder than necessary and was designed for an architecture that is long gone. So a modern update will need to break compatibility for several reasons so that software can be ported and that a user will be able to connect to the internet without worrying that even a scriptkiddie could read all their private data. But breaking compatibility doesn't mean old programs can't run just as MSDOS programs could be run on a native 32bit operating system. Of course there would need to be an emulator to run 68k programs on e.g. AMD64 but they could still be part of the system.

Best case, old programs would not run or be sandboxed with security levels turned up. It would still be an advantage to have BE and 68k support. Introducing a new architecture with broken compatibility would be another major AmigaOS fork to support while leaving most existing Amiga users behind again.

Quote:

I wouldn't call AARCH64 fat, what designs are you comparing to?

The original ARMv1 had 23 mnemonics. One of the major reasons it was chosen for embedded was because it was lean with tiny cores.

ADC, ADD, AND
B, BIC, BL
CMN, CMP
EOR
LDM, LDR
MOV, MVN
ORR
RSB, RSC
STM, STR, SBC, SUB, SWI
TEQ, TST

AArch64 has 177 mnemonics by my count which is more than 7 times more. There are almost twice the number of mnemonics starting with 'S' as ARMv1 had total mnemonics. FPU, SIMD unit and crypto mnemonics *not* included, most of which are requrired.

ADC, ADCS, ADD, ADDS, ADR, ADRP, AND, ANDS, ASR, ASRV, AT
B, BFI, BFM, BFXIL, BIC, BICS, BL, BLR, BR, BRK
CBNZ, CBZ, CCMN, CCMP, CLS, CLZ, CMP, CMN, CSEL, CSINC, CSINV, CSNEG, CSET, CSETM, CINC, CINV, CLREX, CNEG
DC, DCPS1, DCPS2, DCPS3, DMB, DRPS, DSB
EON, EOR, ERET, EXTR
HINT, HLT, HVC
IC, ISB
LDAR, LDARB, LDARH, LDAXP, LDAXR, LDAXRB, LDAXRH, LDNP, LDP, LDPSW, LDR, LDRB, LDRSB, LDRH, LDRSH, LDRSW, LDTR, LDTRB, LDTRH, LDTRSB, LDTRSH, LDTRSW, LDUR, LDURB, LDURSB, LDURH, LDURSH, LDURSW, LDXP, LDXR, LDXRB, LDXRH, LSL, LSR, LSRV
MADD, MNEG, MOV, MOVI, MOVK, MOVN, MOVZ, MRS, MSR, MSUB, MUL, MVN
NEG, NEGS, NGC, NGCS, NOP
ORN, ORR
PRFM, PRFUM
SBC, SBCS, SBFM, SBFIZ, SBFX, SDIV, SEV, SEVL, SMADDL, SMC, SMSUBL, SMNEGL, SMULL, SMULH, STLR, STLRB, STLRH, STLXP, STLXR, STLXRB, STLXRH, STNP, STP, STR, STRB, STRH, STTR, STTRB, STTRH, STUR, STURB, STURH, STXP, STXR, STXRB, STXRH, SUB, SUBS, SVC, SXT, SYS, SYSL
RBIT, RET, REV, REV16, REV32, ROR, RORV
TBNZ, TBZ, TLBI, TST
UBFM, UBFIZ, UBFX, UDIV, UMADDL, UMSUBL, UMNEGL, UMULL, UMULH, UXT
WFE, WFI
YIELD

Quote:

Protection requires breaking compatibility to some degree, there's no alternative. Increasing software availability by making software porting easy will most likely require going from a single address space design to private address spaces, this is a significant change and will break compatibility. Resource tracking could be retrofitted with minor changes (some incompatible) but going for private address spaces as mentioned above would make it easier.

A single address space design would require an MMU which would decrease the performance and increase the memory footprint for small systems. It may make porting easier if choosing to support .so/.dll libraries which I would like to avoid. The Amiga library system is superior and allows more resource shariing. Preferably, I would like security/protection settings that can be turned down to gain more compatibility.

Quote:

I wouldn't call that mixed endian and even if it were proper (I reserve it for the PDP11) it doesn't matter. Why should the instruction bits change order when changing endianess? Also are AMD64 REX prefixed instructions BE because the highest register bits come before the lower bits? Yes it's bad for compatibility but that's the state of things. When even IBM move towards LE and all new designs are either natively or generally run as LE one have to accept it as a fact.

I guess I'm a purist who likes things simple. Bi-endian is a mixed endian half breed bastard. It is kind of like metric vs English measurements. Metric is best and English is tolerable but mixing and having to do conversions is horrible.

The order of hardware bits is mostly transparent to programmers. Different serial transmission standards start at different ends of bytes but the hardware is wired correctly. Endianess is *not* transparent to programmers unless they are using an 8 bit CPU.

Last edited by matthey on 06-Mar-2019 at 01:36 PM.
Last edited by matthey on 06-Mar-2019 at 03:13 AM.

Quote:

davidf215 wrote: The custom Amiga chips had their time. The industry eventually produced better chips.

The Amiga custom chips became outdated because they weren't updated. The logic in them is more efficient than most chips today. Every transistor counted back then. They are not going to be as high of performance as modern chips due to the fab die size just like with the 68060. There are 15 die shrinks from the last 500nm rev6 68060s to the Raspberry Pi 40nm "outdated" SoC die size and another 8 die shrinks to the state of the art 7nm process (23 total die shrinks). I believe I have adequately covered how much different one or two die shrinks can make in competitiveness already.

Quote:

OneTimer1 wrote: Please show me a trustworthy source for this claim. Every time I was asking for a source about Vampire numbers, I was ignored.

Look at Majsta's web site which is basically a history log.

http://www.majsta.com/modules.php?name=News&file=categories&op=newindex&catid=1

UPDATE: August 6, 2013
"It is quite confusing situation to me. I didn't believe that I would need to produce more than 20 boards."

October 25, 2013
"Now, 30 more boards left for me to send, next 300 will be done by kipper2k in short period of time. At the end it is nice to see that people are selling your accelerators to order mine."

In between the 2 dates above was about a 10 times performance increase from the TG68 core to the Apollo Core. This gave performance competitive with a 68060 at under 200 Euros. The Vampire accelerator was only for the Amiga 600 and the FPGA was too small for full 68020 Apollo Core support but performance and price draws customers just like any other market.

I was part of the Apollo Team at that time. I convinced Gunnar to help a frustrated but determined Majsta. One of the reasons I picked him was because I believed he could be trusted. Also, he was the little guy struggling to change the Amiga situation. Read through his journals and then decide if he is a "trustworthy source".

@bhabbott

Quote:

The Amiga 1000 was buggy as hell even 2 years after launch.

That's not my recollection. Kickstart 1.0 was buggy, but that was soon replaced by 1.1, which was a lot better. The hardware was fine.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bhabbott

Quote:

I agree. They should have dropped the Amiga entirely and just concentrated on PC clones.

They would have had to put MS-Windows on those PCs; otherwise, CBM would still have failed. As Be, Inc. discovered that to compete with Microsoft on x86 is close to suicide. Aros is available for x86 CPUs.

Quote:

Why would we buy an overpriced dead end that's an Amiga in name only, when we still have our real Amigas?

Why did you buy your over-priced A1000 and A3000 when they were a dead end, too?

Quote:

Eventually I sold my A3000 because too many websites were inaccessible. The problem as ever was... PC compatibility!

As BigD has already mentioned, I think it wasn't PC compatibility but more like lack of software to do the tasks you wanted to do.

Quote:

bhabbott wrote: I agree. They should have dropped the Amiga entirely and just concentrated on PC clones.

Quote:

davidf215 wrote: They would have had to put MS-Windows on those PCs; otherwise, CBM would still have failed. As Be, Inc. discovered that to compete with Microsoft on x86 is close to suicide. Aros is available for x86 CPUs.

Dave Haynie, Carl Sassenrath and RJ Mical talked quite a bit about the C= PC at the Amiga 30th anniversary celebration in Amsterdam.

https://www.youtube.com/watch?v=fur2quOIufs&feature=youtu.be

Mehdi Ali brought in Bill Sydnes who wanted to convert C= to a PC manufacturer. Instead of the Amiga 3000+ entering production, PC motherboards were produced only to find out that C= could buy them cheaper than they could make them. The PC market was saturated making this a terrible time to enter it (C= could have rebadged discount motherboards for customers wanting one vendor though). Maybe the Amiga 3000 wouldn't have been so overpriced if it had AGA and 16 bit sound with a DSP.

Dave Haynie talked about missed opportunities in video. This would have moved the Amiga toward the embedded market which could have saved C=. The Amiga Toaster is an example of a major embedded product win which C= didn't understand or gain the full benefit from. After Dave left C=, he worked for a company which made an Amiga like OS for hardware using ColdFire and the ARM7TDMI which I mentioned earlier in this thread as the game changer for ARM due to Thumb compressed encodings which allowed electronics to go smaller and cheaper. This should have been the 68k Amiga allowing electronics to go smaller (the 68k can go smaller than Thumb2 and ColdFire).

I asked Dave Haynie what he thought about the Natami over on Amiga.org back in 2010.

Quote:

Originally Posted by hazydave: Actually, of all the recent hardware things I've seen in the post-Amiga world, this is the only one I see as being of much value. Or, in my usual terms, "It's cool". For one, you can claim real Amiga cred there -- doing things the Amiga way. You're not just a PC with a PowerPC CPU and some VGA chip trying to make the claim of being an Amiga. I was a little skeptical when I first heard about it, but I'm totally convinced at this point: if you want a new Amiga, this is the true way. It's also sustainable... you can make as many of these as there's demand for. If this X1000 thing was the second coming of the A1000 (it's not, and honestly, not that interesting), it has a built-in limit, since the CPU is already discontinued. And add to that the FPGA basis... there's some serious hacking potential there, I think. Particularly if they're not full yet This isn't going to replace everyone's need for a fast PC, but then again, running original AmigaOS, you don't really need to be. As long as the cost stays in reach of the hobbyist, this could do well.

It was re-posted here on Amigaworld.net back when the PPC fanboys were more active and resulted in a thread with 34 pages (new hazydave comments starting on page 6).

https://amigaworld.net//modules/newbb/viewtopic.php?mode=viewtopic&topic_id=33564&forum=25&start=0&viewmode=flat&order=0

Too bad the Amiga developers didn't choose product development for C=. These ex-Amiga developers still know more about products, marketing and technology than many current Amiga people today. There are some good history lessons here.

Quote:

davidf215 wrote: They would have had to put MS-Windows on those PCs; otherwise, CBM would still have failed.

But Commodore did put MS-Windows on their PCs - like all the clone manufacturers did. Compared to developing their own OS for the Amiga, this was cheaper and much less risky. High volume manufacturers got 'OEM' software at very low prices, and since Microsoft included drivers for popular hardware they didn't have to do anything except make their machines compatible.

Quote:

As Be, Inc. discovered that to compete with Microsoft on x86 is close to suicide.

Exactly. So Commodore made two fatal mistakes - producing incompatible hardware and an incompatible OS to run on it. If only they had put all their resources into making PC clones they could have cut development costs, increased profitability and lasted a lot longer.

Quote:

Why did you buy your over-priced A1000 and A3000 when they were a dead end, too?

Young and foolish, cash to burn...

The A1000 was touted as the ultimate home computer, so I had to have one. I had the choice of an A500 which was technically superior, but I preferred the styling of the A1000. WB1.1 was very buggy and crashed regularly, however I figured (correctly) that a more stable Kickstart would soon become available. 256K RAM wasn't enough so I immediately bought the ChipRAM upgrade, then later a Microbotics 2MB FastRAM expansion, and finally a second-hand 20MB hard drive and PC controller card which I interfaced to the Amiga. I had this setup until 1991 when I got the A3000. The very next day thieves broke into my house and stole the entire A1000 system (luckily they didn't spy the A3000 still sitting in its box).

I justified buying the A3000 on the basis that a similarly configured Compaq 386DX-25 was about the same price, that I needed it for software development, and that I would easily recoup the cost when we made it big. If I had been following PC trends instead of ignoring them I might have realized that these were just rationalizations. Less than 3 years later the home computer market was dead, Commodore went bankrupt, and I had to sell PC clones to make a living.

Quote:

As BigD has already mentioned, I think it wasn't PC compatibility but more like lack of software to do the tasks you wanted to do.

It's the same thing! MS-windows only runs on a PC, and the software which does the 'tasks I want' requires Windows. But my PC isn't powerful enough to run Windows 10 so even it can't do all the tasks I want, which is why I have another PC running Linux dedicated to a single task (watching TV programs online) - and even that stopped working for a while because the Linux version of Firefox wasn't fully compatible.

We can't have PC software on Amigas because they aren't PC compatible. Of course if they were compatible then they would be PCs (or so close to a PC that they might as well be one). And it's not just the software. You want to browse the latest web pages at a reasonable pace, or run the latest programming IDE without annoying delays - better have an i7 with oodles of RAM and an SSD. Want to play the latest 3D games at a competitive frame rate - add the most powerful PC video card you can buy or else. With PCs It has always been this way, and any other platform will struggle to keep up.

Anyone who still thinks the Amiga can compete in this environment is deluding themselves. But I am not worried because I don't want to compete. So long as my Amiga does the Amiga stuff I want to do on it I'm happy. Downloading files from Aminet, posting on Amigaworld.net, programming in 68k asm, playing classic games - all the stuff I ever wanted to do on the Amiga. And now with the Vampire I can run Wolfenstein 3D just like I remember it on a 386, only better! Who cares that no modern PC user would bother...

Last edited by bhabbott on 07-Mar-2019 at 07:22 AM.

@bhabbott

I see it this way...

Amiga is retro. That is also true for what is called "NG". Competing on the mass market is impossible, even if the OS would be on the same level as the big platforms there would be still be the problem of no software.

For retro purpose Vampire and related developments are perfect solution. Another project I have high hopes for is the RPi port of Aros because the RPi community certainly is different compared to average users.

A revival of 68k as CISC at the mass market sounds nice of course but that is nothing I believe. And even if you get such hardware at low price there is no modern software for it. We would need big investors and lots of developers who we do not have. So we should be happy what we have and what we will get (hopefully soon) and not dream unrealistic dreams (like many do).

@OlafS25

Quote:

Amiga is retro. That is also true for what is called "NG". Competing on the mass market is impossible

And no-one denies that. In the past few years I haven't seen anyone with an NG machine and at least one brain cell to seriously claim an ambition to replace their daily-work computer. It's retro, it's a hobby and we all know that, so I think there's no point in constantly bringing it up.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

Quote:

OlafS25 wrote: I see it this way... Amiga is retro. That is also true for what is called "NG". Competing on the mass market is impossible, even if the OS would be on the same level as the big platforms there would be still be the problem of no software.

Dave Haynie, Carl Sassenrath and RJ Mical were involved in the following projects after leaving C=.

Atari Lynx (console: RJ Mical, Dave Needle, Dave Morse), Panasonic 3DO (console: RJ Mical and Dave Needle), PS3 and Playstation Vita (console: RJ Mical), Scala (kiosk: Dave Haynie), Metabox/PIOS (set top box: Dave Haynie, Dr. Peter Kittel, Andy Finkel, John Smith), Nomadio R/C controllers (sensors/controllers/networking: Dave Haynie), CDTV (set top box: Carl Sassenrath), Viscorp Ed (set top box: Carl Sassenrath), Roku (set top box: Carl Sassenrath)

They made careers of making embedded products using Amiga like hardware and software. In many cases, they would have been more successful had they been able to use Amiga technology. Embedded hardware and software is not as difficult to support, the technology does not age as fast and it is a huge market which can improve economies of scale to drastically lower costs. Why do Amiga people keep ignoring the 5000 pound Gorilla in the room?

Quote:

For retro purpose Vampire and related developments are perfect solution. Another project I have high hopes for is the RPi port of Aros because the RPi community certainly is different compared to average users. A revival of 68k as CISC at the mass market sounds nice of course but that is nothing I believe. And even if you get such hardware at low price there is no modern software for it. We would need big investors and lots of developers who we do not have. So we should be happy what we have and what we will get (hopefully soon) and not dream unrealistic dreams (like many do).

The Raspberry Pi is barely retro. It is hobbyist, educational and *embedded*. Let's not underestimate the value of embedded for this product. The Raspberry Pi has been a game changer in the huge embedded market with the Pi board form factor now becoming the standard! The Raspberry Pi sales are just a drop in the bucket for ARM core sales though!

The PPC NG guys want to go bigger into the desktop. The last successes in the desktop market were x86, AMD64 and Windows. Gunnar wants to go bigger into the niche retro desktop. This is a little better but the 68k can go smaller into embedded and doesn't have to be niche. Niche equates to minimal software development in any case but that seems to be the plan and end goal for both the AmigaOS and Vampire. I talked to embedded people who were interested in the 68k in large enough scale to potentially move the 68k and the Amiga out of the niche rut. There is a chance at success or guaranteed failure with the current plans. Call me a dreamer for wanting to take a chance at success but it is more realistic than thinking something good will happen to the Amiga in the current niche market.

@matthey

You are right, the Amiga platform needs to go embedded.
Desktop market is biggest but is also the one with less spaces.
The best result we could have in desktop are portings from other platform apps, nothing more. Why someone should prefer an expensive and much less powerful Amiga to any windows or Linux pc, to make same jobs?

I think AmigaOS have a great opportunity with internet of things, robotics and any niche specialized task. Just like video toaster did.
We needs only right hardware to go, for me reassuming choices in few words: x86 have no sense, ppc boards costs are too much high and so remain only arm as modern well developed cpu.
I see no alternatives.

Last edited by Fl@sh on 08-Mar-2019 at 07:19 AM.

_________________
Pegasos II G4@1GHz 2GB Radeon 9250 256MB
AmigaOS4.1 fe - MorphOS - Debian 9 Jessie

@bhabbott 

Quote:

Young and foolish, cash to burn...

Well, I wouldn't go that far. It seems like you had other reasons for buying it. Such as that the A3000 was similarly priced to the Compaq for your software development and for the Amiga experience. Bummer that your A1000 was stolen.

Quote:

And it's not just the software. You want to browse the latest web pages at a reasonable pace, or run the latest programming IDE without annoying delays - better have an i7 with oodles of RAM and an SSD. Want to play the latest 3D games at a competitive frame rate - add the most powerful PC video card you can buy or else.

This has always annoyed me. Always having to have the latest graphics card to play new PC games. It's different on the game consoles as games are designed with the existing graphics card for the console. I never understood why PC games never followed suit.

Quote:

But I am not worried because I don't want to compete. So long as my Amiga does the Amiga stuff I want to do on it I'm happy. Downloading files from Aminet, posting on Amigaworld.net, programming in 68k asm, playing classic games - all the stuff I ever wanted to do on the Amiga. And now with the Vampire I can run Wolfenstein 3D just like I remember it on a 386, only better!

I would call this the Amiga Experience. It's one of the reasons I bought an A1200, and I continue to run AmigaOS as often as I can, even if it's emulated.

@OlafS25 

Quote:

Another project I have high hopes for is the RPi port of Aros because the RPi community certainly is different compared to average users.

I'll have to try out Aros on my Rpi3. Gotta buy another memory card for it. I have an Amiga emulator for my RPi3 but a native option would be better.

@matthey
Quote:

matthey wrote: The AMD literature is a sales brochure. AMD64 could have been more compatible with x86 and had better performance and code density too. http://www.emulators.com/docs/nx05_vx64.htm

The programmer that thinks punting everything hard to software emulation is the way forward?
While an interesting read what he proposes isn't more compatible and have some large problems on its own.

Quote:

It is funny that this article suggests a better x86 64 bit encoding but compares to the 68k giving the "Intel weaknesses". Cdimauro suggested the AMD64 ISA is inferior to his alternate encoding NEx64T ISA as well.

Have he shown that it's better as implemented in real hardware? Going to two types of decoders carry a cost that AMD obviously thought to high (sadly).

Quote:

Best case, old programs would not run or be sandboxed with security levels turned up. It would still be an advantage to have BE and 68k support. Introducing a new architecture with broken compatibility would be another major AmigaOS fork to support while leaving most existing Amiga users behind again.

So what's the alternative? AOS4 or perhaps better MorphOS is as far as one can push a compatible enough system. But neither solves the hard problems, the problems that makes e.g. a proper browser port hard to do.

Quote:

The original ARMv1 had 23 mnemonics. One of the major reasons it was chosen for embedded was because it was lean with tiny cores.

Nobody used ARM1 for embedded work, it had a limited release mostly as a test. ARM2 have multiplication too but wasn't released as a single chip design suitable for embedded applications.
ARM6 was IIRC the first design used outside Acorn with the possible exception of the ARM250 system on chip.

Quote:

AArch64 has 177 mnemonics by my count which is more than 7 times more. There are almost twice the number of mnemonics starting with 'S' as ARMv1 had total mnemonics. FPU, SIMD unit and crypto mnemonics *not* included, most of which are requrired.

Some of those mnemonics are aliases, the conditional operations are what ARM2 (and 1) would encode as a normal instruction with a condition. Others would be using another syntax in the original architecture which results in less mnemonics.
AARCH64 have better support for multiprocessing which adds instructions and there are some other changes. But the difference isn't that large and AARCH64 is more hardware efficient.

I wouldn't call that fat.

Quote:

A single address space design would require an MMU which would decrease the performance and increase the memory footprint for small systems. It may make porting easier if choosing to support .so/.dll libraries which I would like to avoid. The Amiga library system is superior and allows more resource shariing. Preferably, I would like security/protection settings that can be turned down to gain more compatibility.

An MMU is required for a modern system, no choice. Performance impact wouldn't be noticeable while one program writing an address it shouldn't is (or even worse isn't immediately).

If breaking direct compatibility isn't acceptable AmigaOS 4.x and MorphOS is as good as it gets, if breaking compatibility for new programs is acceptable however why not design something that can have a future?

Quote:

I guess I'm a purist who likes things simple. Bi-endian is a mixed endian half breed bastard. It is kind of like metric vs English measurements. Metric is best and English is tolerable but mixing and having to do conversions is horrible. The order of hardware bits is mostly transparent to programmers. Different serial transmission standards start at different ends of bytes but the hardware is wired correctly. Endianess is *not* transparent to programmers unless they are using an 8 bit CPU.

The order of instruction bits in a RISC architecture are visible only to the hardware and code generators, they can be seen as a bunch of bits. In a CISC code generators and disassemblers would have to swap some data but it isn't visible to normal programmers. While endianess isn't transparent in a lot of cases it isn't really relevant.

Quote:

davidf215 wrote: It's different on the game consoles as games are designed with the existing graphics card for the console. I never understood why PC games never followed suit.

There's a fundamental divide between consoles and PCs. Consoles are designed with everything built in, so game developers have a standard platform to work with. This suits a market which expects 'plug-and-play' operation on low cost hardware.

The original IBM PC had almost nothing standard - graphics, sound, disk drives, I/O ports, even RAM was an option chosen by the purchaser. This was a nightmare for game developers, so they responded by designing games to particular hardware configurations which the user had to match in order to play them. That freed developers from having to work within hardware limitations, allowing them to produce more sophisticated games with flashier graphics etc. - and if a game taxed the machine too much it didn't matter because the user could just upgrade again.

To those of us who were brought up on consoles and home computers it may seem puzzling, but to PC gamers it's natural. We might appraise a machine by what features it has built in, but they are more interested in what slots are on the motherboard and the size of the power supply - and can't understand why we would lock ourselves into a non-upgradeable design.

Last edited by bhabbott on 09-Mar-2019 at 04:34 PM.

@matthey Quote:

matthey wrote: The 68060 was clock for clock similar integer performance to the 601 and outperformed the 603 and 603e. It was also clock for clock better integer performance than the most comparable Pentium.

Do you have SPECint/fp for that processors? It'll be good to take a look at some numbers.
Quote:

The 68k may also have been a victim of the “don’t eat your own children” principle with the choice of 8088 CPU at IBM. There is a theory that the 68000 would have been too competitive with IBMs higher performance and margin minicomputers. This is suggested by Paul DeMone in the following article. https://www.realworldtech.com/escape-from-x86/

It's just a theory: it was very well know that Motorola wasn't production ready with its 68000 at the time that IBM decided to build its PC.
Quote:

PPC made sense for the desktop after the 68k (unless C= had been able to license the 68k and stay in business).

Yes, but only in the first period when PowerPCs were introduced, because x86s filled the gap at the end of 90s, becoming more competitive (and cheaper).
Quote:

The "ten years" with the 68k were the golden years. It wasn't just Apple that killed off PPC. Intel with an ugly old CISC ISA that consistently outperformed PPC may have played a part.

Exactly. Apple wanted to kill PowerPCs already on 2000, because of Intel's advantage which was quite evident at the time. In fact, the first MacOS X version should have been x86 based. Apple didn't jumped into Intel's wagon only because an IBM's rampant manager promised the G5 to Steve Jobs. But the transition to Intel was just delayed some years, as we know.

So, porting the Amiga o.s. to PowerPC after 2000 was just another plain, completely wrong decision which post-Commodore management did. As usual...


@michalsc Quote:

michalsc wrote: All I wrote is valid for aarch32. Soon I will test how it changes on aarch64. But, even if it changed there, there is no need to worry about endianess of amiga-like systems beyond 32-bit...

Is there any reason why you started using AArch32 instead of directly go to AArch64? With the latter, and its 31 registers, you can map all 68K registers to a (fixed) subset of available registers, and still have plenty of free registers to be used for temporary data & calculations.


@bhabbott Quote:

bhabbott wrote: Quote: Hypex wrote: a redesigned Amiga could have used an Intel as a new CPU. A new Amiga running on an Intel, but it still wouldn't be a PC! But just having a new CPU isn't enough. To be price competitive your 'Amiga' would also need to work with the same graphics cards etc. as a PC, so it would need to be 100% PC compatible - IOW it would be a PC.

Well, that's what happened with Amiga anyway: plenty of graphic cards using PC graphic chipsets. And some audio cards as well.

Shouldn't be some reason for this, or not?
Quote:

Quote: But of course AMD couldn't let x86 go. Of course not, because x86 compatibility was essential and any deviation was doomed to fail. Everyone knew that even before the A1000 was released. Amiga was a dead man walking from day one.

I don't think so. The Amiga 1000 was a revolutionary computer at the time when it was introduced. The problem is that Commodore slept too much not improving its chipset and o.s. to remain competitive, and PCs quickly filled the gap after. What Commodore did was just recycling the original design for some years, trying to squeeze as much as possible its new golden goose...
Quote:

Quote: But in 1987 256 colour palettes were becoming standard and by 1990 24-bit framebuffers were in existence. IBM introduced VGA in 1987 with their PS/2 line, which were horribly expensive and used an incompatible bus. The main attraction of VGA was not 256 colors (in 320x200 low resolution only)

Which was, more or less, the resolution used by Amiga games as well. Except that Amiga games were using 32 colors or 8+7=15 colors (in dual playfield mode. Plus an additional 15 colors used for sprites); the Copper allowed to changed the palette on the fly, as we know, but there were limits. 64 colors were possible too on Amiga, but only a few games used them, due to more space required and particularly for the more bandwidth which was needed both by the display logic and the Blitter (which had less bandwidth available).

Quote:

but the flicker-free high resolution 16 color graphics and text that business users liked.

Not true. Even the original VGA was able to offer higher resolutions: up to 360x480 with the so called Mode X. Using 256 colors, high-refresh rate (72hz AFAIR), and flicker-free (no interlace).

The problem is that this trick was discovered very late (by Michael Abrash), so coders took advantage only at the beginning of '90s.
Quote:

SVGA cards introduced 256 colors in hi-res, but performance sucked. SVGA didn't hit it's stride until 486 motherboards with VL bus arrived in 1992,

Come on Bruce, we already talked about it quite recently: even the crappiest graphic card that you reported had enough performance in 8-bit ISA mode to run 320x200 3D games at >30FPS.
Quote:

but that didn't matter because you didn't need 256 colors to run Microsoft Word and Excel. Business software compatibility was always the driving force for hardware development in the PC world, and anything different was never going to make it.

Then how do you explain the boom of PC games? And we discussed also about it...
Quote:

Yep. Anything that wasn't a PC was doomed to fail. [...] If Apple had stuck to Macintosh they would have failed, and they nearly did. The only thing that saved them was moving out of the PC market into phones etc..

And this isn't true as well: Apple proved it, as someone else already pointed-out. In fact, Apple saved a niche market from the very beginning with its Macintosh, and maintained it even before introducing the first iPhone.
Quote:

And now with the Vampire I can run Wolfenstein 3D just like I remember it on a 386, only better! Who cares that no modern PC user would bother...

Really?
https://www.dosgamers.com/dos/dos-games/wolfenstein-3d
https://www.youtube.com/watch?v=aCP4ST23NV0


@matthey Quote:

matthey wrote: The AMD literature is a sales brochure. AMD64 could have been more compatible with x86 and had better performance and code density too. http://www.emulators.com/docs/nx05_vx64.htm It is funny that this article suggests a better x86 64 bit encoding but compares to the 68k giving the "Intel weaknesses". Cdimauro suggested the AMD64 ISA is inferior to his alternate encoding NEx64T ISA as well.

Actually it's not only a suggestion: I've solid numbers which show it.

I studied the link that you provided, and it was an interesting reading, but it's clearly evident that the guy has not much experience on designing an ISA, and thinking about the consequences of some design choices.

He bet for its "VX64" (second) design... which unfortunately it's a complete crap. He wanted to fix some x86/x64 bad design choices, but the only thing which is better on VX64 is the easier instructions decoding. Code density, which is one of the x86/x64 (less for x64) winning point, is WAY WAY WAY worse due to 32-bit granularity for all opcodes components: even a simple RET instruction required 4 bytes! Instructions displacements can be only 0 or 4 bytes, and the same for immediates (with no support for 64-bit immediates, from what I've seen. But it might be introduced with some hack, anyway). What's worse, is that this design doesn't support other x86/x64 features (LOCK for some instructions, segments overrides, address overrides). So, it's even not feature-complete.

Much better is it's first design, with a nice mod/rm encoding and room for 16 GP registers, as well as a ternary reg-reg-reg encoding. However this ALWAYS costs one additional byte compared to the regular x86 design, and even compared to x64 (which required the additional REX prefix only for accessing the extra 8 registers, or to enable 64-bit. Otherwise, the instruction encoding is exactly the same as x86). So, code density becomes worse, and IMO would be comparable to x64 (even for 32-bit code / execution mode).

Finally, he compared x86 to 68K for other reasons. I think that the guy is not aware of the issues which 68K has for instructions decoding, including the problems with double-indirect memory modes.
Quote:

Quote: davidf215 wrote: The custom Amiga chips had their time. The industry eventually produced better chips. The Amiga custom chips became outdated because they weren't updated. The logic in them is more efficient than most chips today. Every transistor counted back then. They are not going to be as high of performance as modern chips due to the fab die size just like with the 68060. There are 15 die shrinks from the last 500nm rev6 68060s to the Raspberry Pi 40nm "outdated" SoC die size and another 8 die shrinks to the state of the art 7nm process (23 total die shrinks). I believe I have adequately covered how much different one or two die shrinks can make in competitiveness already.

Unfortunately that's not true. Jay Miner did several mistakes designing the Amiga chipset, but the biggest one was using bitplanes instead of packed/chunky graphics.

Bitplanes were a bit easier to implement on the Blitter, but they are much worse in general due to the alignment requirements and mask usage, which caused a big waste of both space and (especially) bandwidth. Packed/chunky graphics is almost always better (MUCH better in the most common cases) than bitplanes, except in the case of accessing single bits/bitplanes (which is not that common).
Quote:

Dave Haynie, Carl Sassenrath and RJ Mical talked quite a bit about the C= PC at the Amiga 30th anniversary celebration in Amsterdam. https://www.youtube.com/watch?v=fur2quOIufs&feature=youtu.be Mehdi Ali brought in Bill Sydnes who wanted to convert C= to a PC manufacturer. Instead of the Amiga 3000+ entering production, PC motherboards were produced only to find out that C= could buy them cheaper than they could make them. The PC market was saturated making this a terrible time to enter it (C= could have rebadged discount motherboards for customers wanting one vendor though). Maybe the Amiga 3000 wouldn't have been so overpriced if it had AGA and 16 bit sound with a DSP. Dave Haynie talked about missed opportunities in video. This would have moved the Amiga toward the embedded market which could have saved C=. The Amiga Toaster is an example of a major embedded product win which C= didn't understand or gain the full benefit from. After Dave left C=, he worked for a company which made an Amiga like OS for hardware using ColdFire and the ARM7TDMI which I mentioned earlier in this thread as the game changer for ARM due to Thumb compressed encodings which allowed electronics to go smaller and cheaper. This should have been the 68k Amiga allowing electronics to go smaller (the 68k can go smaller than Thumb2 and ColdFire).

Did he talked also about the missed opportunities with AGA? The only enhanced things compared to OCS/ECS were the display and sprites subsystems, leaving ALL the rest (Blitter, audio, and disk) EXACTLY the same! What a shame!!!


@megol Quote:

megol wrote: @matthey Quote: matthey wrote: The AMD literature is a sales brochure. AMD64 could have been more compatible with x86 and had better performance and code density too. http://www.emulators.com/docs/nx05_vx64.htm The programmer that thinks punting everything hard to software emulation is the way forward? While an interesting read what he proposes isn't more compatible and have some large problems on its own.

Indeed. The only thing which makes sense talking about software emulation is for implementing legacy, complex instructions.
Quote:

Quote: It is funny that this article suggests a better x86 64 bit encoding but compares to the 68k giving the "Intel weaknesses". Cdimauro suggested the AMD64 ISA is inferior to his alternate encoding NEx64T ISA as well. Have he shown that it's better as implemented in real hardware? Going to two types of decoders carry a cost that AMD obviously thought to high (sadly).

AMD (as well as Intel) already had to use more decoders for x86/x64, due to the tangible differences between 8086/real-mode, 32-bit and 64-bit mode.

I don't think that the first design of the guy would have hurt the decoder implementation. The second design, instead, is pure crap.

Regarding the rest, I agree.


@bhabbott Quote:

bhabbott wrote: The original IBM PC had almost nothing standard - graphics, sound, disk drives, I/O ports, even RAM was an option chosen by the purchaser.

Again, that's not true: disk drives, I/O ports, the beeper and part of graphic were standard (SVGAs are VGA-compatible; VGA is EGA-compatible; EGA is CGA-compatible).

Regarding RAM, even Amiga had options, with the stupid decision to introduce the slow-ram: a memory which is NOT fast neither chip ram! You had absolutely NO benefits, but only the worst of the two different memory types!!! Another very bad design decision by Commodore...
Quote:

This was a nightmare for game developers, so they responded by designing games to particular hardware configurations which the user had to match in order to play them. That freed developers from having to work within hardware limitations, allowing them to produce more sophisticated games with flashier graphics etc. - and if a game taxed the machine too much it didn't matter because the user could just upgrade again.

As we already discussed, this did NOT stopped developers to produce games for PCs.

Yes, they had to make more work to support more sound cards and joysticks/joypads, which were the primary sources for differences.

On the graphic side the situation was much better, because they had VGA and SVGA (which used the VESA standard).

Quote:

Fl@sh wrote: You are right, the Amiga platform needs to go embedded. Desktop market is biggest but is also the one with less spaces. The best result we could have in desktop are portings from other platform apps, nothing more. Why someone should prefer an expensive and much less powerful Amiga to any windows or Linux pc, to make same jobs?

Actually, the embedded market is much bigger than the desktop market. There are several times more chips with ARM cores sold each year than there are people on the planet earth. The profit margins for the embedded market are often lower than the desktop market but the volumes have resulted in very cheap hardware.

The Amiga needs higher volumes to lower prices too. Economies of scale could lower the cost of hardware and software making it more competitive. Sales into the embedded market can help. This can be seen with the Raspberry Pi which has some nice features for embedded but the most attractive feature is price. Their success came from pushing the price of hardware down.

Quote:

I think AmigaOS have a great opportunity with internet of things, robotics and any niche specialized task. Just like video toaster did. We needs only right hardware to go, for me reassuming choices in few words: x86 have no sense, ppc boards costs are too much high and so remain only arm as modern well developed cpu. I see no alternatives.

ARM is a good choice for cheap hardware and the embedded market. However, it may not be the best choice for the Amiga. We need to look at what we have on our side of the fence before we jump the fence to what looks like greener pastures.

The AmigaOS 68k is more optimized for the 68k and big endian.
The 68k AmigaOS has a tiny footprint exceeding most computers today.
The 68k Amiga has the largest Amiga user base and software due to compatibility.
Amiga developers are more experienced with the 68k.
+====+=====+====+
AArch64 is the most popular and standard ARM ISA but can have 50% larger code than the 68k.
A 68k JIT emulator and run in UAE will use more memory.
ARM requires dividing the Amiga user base and development again (stop supporting the PPC & 68k?).

Quote:

Embedded Systems Design: An Introduction to Processes, Tools, and Techniques reads: Choosing the RTOS - along with choosing the microprocessor - is one of the most important decisions the design team or system designer must make. Like a compiler that has been fine tuned to the architecture of the processor, the RTOS kernel should be optimized for the platform on which it is running. A kernel written in C and recompiled (without careful retargeting) for a new platform can significantly reduce the system performance.

The 68k Amiga was designed to use as little as 256 MiB of memory and can have a full GUI and TCP/IP stack with a few MiBs. A 68k Amiga or embedded system could run completely in SRAM caches the size of some high performance CPU L2 and L3 caches today. A GiB of memory costs about $8 U.S. which is a substantial percentage of hardware cost in the $20-$40 range. One of the most requested features of Pi users is more memory which may increase to 2 GiB for the Raspberry Pi 4 but if the memory miser 68k Amiga could stay at 1 GiB of memory it would have an $8 cost advantage. The 68k Amiga could significantly reduce the footprint of the Amiga with compiler improvements, ISA/ABI upgrades and CPU features.

Another potential cost advantage is to reduce the markup from chip vendors which is usually double digit. Sharing development and production costs with other chip consumers can avoid the markup. The embedded market has some high quantity chip consumers.

There is a chance for the Amiga to be competitive on low end hardware. I see more opportunity for the 68k than ARM but it would require new hardware. ARM already has cheap hardware but the Amiga would be competing in their turf against experienced ARM developers and without as much advantage from 68k software.

@cdimauro

Quote:

Jay Miner did several mistakes designing the Amiga chipset, but the biggest one was using bitplanes instead of packed/chunky graphics.

Yeah. One of the first things I'd do if I had a TARDIS would be to go back and fix this.

If Amiga had had something like Wolf3D before the PC, things may have turned out different.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bison: then be prepared to receive tons of stones. Some Amigans don't like that their totems to be touched.


Now going back to the topic and after reading the answers, I think that the discussion should be split in two parts: the Amiga o.s., and the processor to be used.

After that much time I think that we can more or less agree that the Amiga o.s. (the original, 68K-based) entered the "retro" status. He had some development after Commodore bankrupt, and in the last months it had some fixes with the so called 3.1.4.
However this "maquillage" wasn't able to address the original issues. The o.s. is essentially the same, and no modern features were implemented: no memory protection, resource tracking, SMP, 64-bit support, and last but not really least the fact that you have to set a stack size (with the consequences that can be imagined. First of all, the possibility to generate memory corruption). All of that stuff will break compatibility, and needs sensible and/or much heavy rewriting/redesign of both o.s. AND software.

Looking at the software (applications, games), the situation is quite similar: very little updates or new ones. But no new "killer apps/games".
Talking about the games, the vast majority directly hits the hardware, so here the compatibility is very very important. And the most compatible platforms are plain Amiga 500/2000 with 512KB of chip ram and 512KB of "slow-ram" (sigh!) for OCS/ECS, and plain Amiga 1200 for AGA ones. Only some games used more memory, and for many having a faster CPU is even a big problem (a faster CPU is welcome only for some 3D games).
Applications can take advantage of more memory, but usually don't need faster CPUs (albeit it's welcome). Only some data-crunch intensive applications required faster CPUs, and more memory. Some applications can take advantage of RTG and/or AHI, but they are the vast minority.

Anyway, and putting everything together, I think that we can safely conclude that the overall Amiga o.s. 68K platform/ecosystem has to be considered "retro". It has none or very little development, and we cannot expect a revival even if someone puts a lot of money (which is quite unlikely to happen: to whom sell 68K stuff, in order to get back at least the expenses, and gain something?).

The good old Amigas (500/2000, 1200) are the hardware systems to be used for Amigans which like to dive back to the good old days and thinkering with games and/or applications. Vampire can be another option, but especially for the Amiga o.s. & applications (because has compatibility issues: the CPU is neither a plain 68000 neither a 68EC020).
WinUAE is a very valid alternative for the ones which cannot or don't want to afford such systems. It has the added value that can emulate any hardware platform with almost perfect compatibility (which cannot be achieved with the original Amigas: a 500 is NOT compatible with the 1200, and viceversa), or to emulate top notch high-end systems to burst A LOT number-crunching applications, and with a very reduced cost.

matthey suggested that the Amiga o.s. can be used and has very good value for the embedded market. I respectfully beg to differ, because it's too much tight to the Amiga chipset, and this not only has little or no value in the embedded market (many times you don't even have a screen to display something, neither you have to play music/sound, or control a disk drive, etc.), but actually represents a big burden which such platforms NEEDS to carry in order to work.

Paradoxically AROS has much better chances from this point of view, because it's a complete rewriting of the Amiga o.s., and it's not tight to the Amiga chipset. Even the 68K port can be run in a completely different hardware platform, with little effort.

Regarding AmigaOS4, conclusions similar to the ones made for the Amiga o.s. can be drawn. This o.s. shares more or less the same issues of the original one, since it's roughly a port to a different processor and hardware platform. A sensible difference is that it has been developed, albeit in the last years it stalled, since the developers weren't able to fulfill the features proclaimed to the four winds. It has a small customer base, as well a smaller application base.

BTW, a backport of some (or all) AmigaOS4 features to the Amiga o.s. (68K) is not possible, due to the ownership of part of the AmigaOS4 by different third-parties, the lack of interest on this operation, and the lack of money to back it.

OK, the biggest part was dedicated to the o.s. and its applications. Now it's time to shortly talk about the processor.

I think that the 68K can have some chances to go back to the embedded market (which is VERY VERY BIG), but without being bounded to the Amiga o.s. due to the above reasons which I've explained.

However there are some issues which need to be solved. The lack of compiler support is the biggest one. The second, less important (in the embedded market), is the lack of o.s. support (especially Linux. Even if I don't like to use such big beast on embedded systems). The third is the lack of 64-bit support, which is not used so much in this market, but in the last period it has grown considerably (so, should be added).

Personally I believe and already expressed the opinion that it's better to redesign the 68K ISA, while maybe keeping the full 68K source-compatibility, in order to simplify the instructions decoding and "isolate & reduce to the minimum impact" some complex/legacy issues. 68K programmers don't need a full binary-compatibility, but it's enough to write the code in exactly the same way.

This source-level compatibility can open the door to more easily introduce the 64-bit support.

I believe also that another set of 8 data registers can be added, while reducing only a bit the source-level compatibility, and making the registers fully separated as data and address ones (data where data is needed, pointers where pointer as needed, and no mixture allowed).

Last edited by cdimauro on 09-Mar-2019 at 11:14 PM.
Last edited by cdimauro on 09-Mar-2019 at 11:14 PM.

@cdimauro

I think AROS is a lot more interesting than AmigaOS in this aspect. As you say, AROS is not tied to the Amiga hardware in the same way and offers more flexibility. You also avoid the ownership issues we have be seeing way too much of.

If you change 68k a lot, it is not really 68k anymore. Source compatibility helps reusing low level stuff like math libraries and arch specific OS code, but little else. Most people do not care so much about it as they are not writing in assembly language anyway. I think binary compatibility is important. Some minor changes can be made with unusual instructions and there can later be a path to 64-bit which breaks compatibility when used. If you make a new encoding, you end up with a new Coldfire, something that looks similar but isn't. Motorola did this with the 6811 to 6812. It helped reuse of some existing assembly code, but otherwise they are very different from a tooling perspective. 6812 was quite successful I believe and eventually killed the 6811 (but that was more likely due to decision on the Motorola side than anything else). It was more like an evolutionary transition in a given segment. They may look a bit similar but they are really quite different.

Having said that, I do not really mind going the source level compatibility path if there can be significant improvements or other motivations (64-bit as you mention), but I think there are also significant risks with it. Maybe it is not worth fixing what is not broken?

@cdimauro

Quote:

BTW, a backport of some (or all) AmigaOS4 features to the Amiga o.s. (68K) is not possible, due to the ownership of part of the AmigaOS4 by different third-parties, the lack of interest on this operation, and the lack of money to back it.

I don´t think this is such a major issue. Major problems would be performance and memory requirements of said OS components. You can´t market OS requiring 16+ MB RAM for A500 users.

Quote:

I think that the 68K can have some chances to go back to the embedded market

Glad I´m not the only one with rose-tinted glasses.