@OneTimer1

Quote:

OneTimer1 wrote: the way video is treated in studios had switched from analog to digital and a fast ethernet card was the best video adapter you could get.

That terminology is kinda misleading as it really was about going from linear to non linear video editing (which kinda had to be digital).

Stuff like the Draco (and the separate Z3 cards that could work in an A4000) did a minimal 1st step in that direction but just couldn't keep up with PPC Macs or x86 PCs

Quote:

And don't forget, Video Toaster was NTSC only.

It was a linear video tool fine for live low level broadcasts (the weather) but mostly useless for anything else.

Back in 2001 there were talks about a commercial non linear video editor for MorphOS that just never made it out of beta (or even alpha). All it would have needed is a driver for a PCI based digitizer and a way to output PAL/NTSC on a video card (this is before broadcast went HD).
The Draco/VLabMotion could not do this in a quality acceptable for 2001 broadcast and were barely good enough for wedding videos at that time.
Time passed and the cap in CPU between NG vs. Mac/PC started to grow to the point that handling the ever higher bitrates (once the race to HD started) would have made it a poor contender even if good (and exclusive) SW had been a thing.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

cdimauro Quote:

That's not correct. Thumb and Thumb-2 have both 16 and 32 bit instructions, which they can freely mix. So, those ISAs are both variable length. The only thing is that Thumb completely lacks the ARM (native) 32-bit instructions, so if you want to use them then applications using this ISA should switch back and forth between Thumb and ARM mode. Thumb-2 eliminated this problem, since it integrated the 32-bit instructions (but without conditional execution).

Thumb, Thumb2, RISC-V, POWER and PowerPC with VLE all use variable length encodings and incur an increased decoder penalty. Did they gain all the advantages of a VLE though? RISC VLEs have mainly focused on code compression while ignoring the potential advantages of fewer instructions and reduced processing of variable length constants and displacements in the code. Keeping the number of VLE sizes to two is more important as it is more RISC like, for now. RISC features keep eroding away over time to gain competitiveness though.

Hypex Quote:

On no! What was that big deal about the Pentium all about then? I recall back then what would have been the 80586 became the Pentium and blew the 68K out of the water!

Intel Pentium associations with RISC were hype and propaganda. Freescale claims that ColdFire is a "variable-length RISC architecture" are similar (some 3rd party literature extends to variable-length RISC 68K Family architecture). There may be some RISC like features but the Pentium, 68060 and ColdFire are far from RISC architectures.

Hypex Quote:

Okay I understand. It's somewhat semantics and using RISC as a simplified term to explain it. Where, as usual it's more technical under the hood, and somewhat misleading using an ISA term to describe internal microops.

CISC mem-reg and reg-mem uops instead of only RISC load/store uops are enough to say that there is no RISC core hiding inside a CISC facade.

Hypex Quote:

I wonder where the 6502 sits? It could be described as RISC with load/store to registers. But works as CISC with memory direct. Also, some people I've spoken too have described it as big endian, even though the data width is only 8 bits. But, addresses are in lo/hi order so I would call it little endian. I would call the copper true RISC. 32 bit codes. 16 bit data. 3 instructions.

Accumulator architectures are their own separate category. In my opinion, they are more CISC like. Both CISC and accumulator architectures need to do memory loads to start with. The name of the instruction is often LOAD for an accumulator architecture and MOVE to a register on the 68k which resemble RISC loads. Unlike RISC architectures, most CISC and accumulator architectures have instructions that then perform mem-reg operations involving a load+ALU operation to a register. Accumulator architectures are sometimes simpler by only allowing mem-reg operations while CISC usually allows mem-reg and reg-mem operations which improves code density and reduces the number of instructions. CISC was the answer to accumulator architectures to reduce the number of instructions to execute, improve code density and reduce memory traffic thus improving performance.

Accumulator architecture
+ simple and easy to develop
+ tiny cores with few registers
- many instructions to execute
- poor code density
- high memory traffic

CISC architecture
+ few instructions to execute
+ good code density
+ low memory traffic
- more complexity and difficulty to develop
- large cores but offset by cache savings in high performance cores

RISC architecture
+ simple and very easy to develop
+ small cores but partially offset by the need for many GP registers
+ orthogonality improves instruction level parallelism (ILP) and eases compiler development
- many instructions to execute
- moderate memory traffic requires many GP registers
- poor code density with fixed length RISC encodings

Accumulator and RISC architecture advantages and disadvantages more closely match. While CISC is the original performance answer to inefficient accumulator architectures, RISC is the low cost answer with substantial performance improvements. In some ways, RISC is more efficient than CISC but CISC can be mostly orthogonal too gaining ILP, for example the 68k.

https://en.wikipedia.org/wiki/Instruction-level_parallelism

Even the less orthogonal x86(-64) has been able to achieve enough ILP to outperform the RISC competition.

Last edited by matthey on 21-Apr-2024 at 03:34 AM.

@matthey

Quote:

Intel Pentium associations with RISC were hype and propaganda. Freescale claims that ColdFire is a "variable-length RISC architecture" are similar (some 3rd party literature extends to variable-length RISC 68K Family architecture). There may be some RISC like features but the Pentium, 68060 and ColdFire are far from RISC architectures.

One of the key RISC concepts is to remove ROM'ed microcode and implement instructions with at least 1 IPC goal.

With the transistor budget increase, X86 vendors implemented its complex instructions without the slow microcode path. Fast path, secondary fast path, and slow path instruction's determination need to be tied with instruction usage statistics and compliers. As the transistor budget increases, more instructions are moved into the fast path.

The RISC threat is real when the CISC competition is heavily ROM'ed microcode 68030 or 80386.

RISC is good for small transistor budget CPUs.

Unaccelerated Doom on 3DO is running on ARM60 at 12.5 Mhz which rivals 68030 @ 50 Mhz.

Modern X86-64 CPUs still have microcode engines with updatable firmware for in-the-field bug fixing instead of a product recall.

Last edited by Hammer on 21-Apr-2024 at 11:19 AM.
Last edited by Hammer on 21-Apr-2024 at 11:17 AM.

_________________
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)

@Gunnar

Quote:

Gunnar wrote: @Hammer Quote: IBM's POWER8 has 64 x 128-bit VSR SIMD instruction set with an 8,192 bits total. Intel's current client Raptor Lake and Meteor Lake SKUs are stuck in 16 register AVX2 with 4,096 bits total. And IBM CELL has 8 x 128 x 128-bit Vector register = 131,072 bits total!

SPU is not a proper CPU since it can't pointer exchange with the host CPU. SPU only supports user mode.

For NVIDIA's GeForce Fermi generation: each SM (Streaming Multiprocessor) has 4096 x 32 bit registers which is 131,072 bits.

GeForce GTX 580 has 16 SM, hence 2,097,152 bits i.e. 262 KB register storage.

Radeon R9 290X's "Hawaii" CU has 256 KB vector registers and there are 44 CUs, hence 11,264 KB or 11.2 MB vector register storage.

AMD GCN can accept X86-64 pointers from the host X86-64 CPU, cache coherent, unified memory capable with the host CPU. Needs a large register file due to Wave64 having four clock cycles compute completion.

Sony has ported their CELL SPU library to PS4 Liverpool GCN's 8 ACE (Async compute engines) which is similar to Hawaii GCN generation. PS4's GPU is Pitcairn GCN 20 CU scale with Hawaii GCN improvements.

For NVIDIA GeForce Ada Lovelace generation: each SM (Streaming Multiprocessor) has 65,536 x 32-bit registers which is 2,097,152 bits.

RTX 4090 has 128 SM, a total of 268,435,456 bits of register storage or 33.55 MB (megabytes) of register storage!!!!

----------
AMD RDNA 3 generation, 192 KB vector registers for each CU. 1.5X increase from the previous generation.

RX 7900 XTX has 96 CU, hence 18,432 KB vector registers or 18.4MB registers storage.

-------------

Last edited by Hammer on 21-Apr-2024 at 12:19 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)

Quote:

Kronos wrote: Quote: OneTimer1 wrote: the way video is treated in studios had switched from analog to digital and a fast ethernet card was the best video adapter you could get. It was a linear video tool fine for live low level broadcasts (the weather) but mostly useless for anything else. Back in 2001 there were talks about a commercial non linear video editor for MorphOS that just never made it out of beta (or even alpha). All it would have needed is a driver for a PCI based digitizer ...

That's also a point for not supporting Z2/Z3 , PCI was available and those cards became cheap.

And the next step was totally digital, if I want to do video today I would use something digital, something supporting Wifi, memory cards or USB and using free software under Mac, Windows or even Linux for editing.
Some are even using only their phones and making professional content in HD for Youtube (TikTok / Twich / OF) with their phones.

All this has changed so fast, Wifi/Ethernet is king for video and streaming might have surpassed TV now, but people here are still talking about Amiga and the toaster, that never went beyond NTSC.

@matthey

Quote:

matthey wrote: Accumulator architecture

Accumulator oriented instructions might have some benefits on 8-bit machines, because you don't need additional bits for addressing a target register.

If you have an architecture with 16, 32 or even 64 bit data bus, you will drop this concept very fast, instead you will ask how many registers are really useful, how can I support high level languages.
Supporting accumulator oriented architectures like the i386, is only useful for backwards compatibility.

@Kronos

Quote:

Kronos wrote: ... talks about a commercial non linear video editor for MorphOS ...

Back in the time when BBRV where negotiating about SetTop Boxes as IMHO the last time an Amiga related OS could have made some kind of impact in the market. Pay TV and teleshopping was one side of the idea, the other side could have been games under MOS. IMHO

Well this is OT and most people here think STBs where a stupid idea from the 90ies, before switching on their Smart-TV, AppleTV or Fire TV Stick for streaming.

Hammer Quote:

One of the key RISC concepts is to remove ROM'ed microcode and implement instructions with at least 1 IPC goal.

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

At that time, some CISC CPUs wasted too much silicon for complex and specialized instructions and addressing modes. 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.

The RISC IPC goal with pipelining was one at that time although rarely achieved. At the time ucode was being eliminated to save silicon, most cores were scalar. Historically, the hardware ILP order of general adoption was something like the following.

o Instruction pipelining
o Branch prediction/Speculative execution
o Register renaming
o Superscalar execution
o Out-of-order execution

The silicon cost of the latter techniques were too high for general adoption until later. IPC improved toward one but did not surpass it until superscalar cores were introduced. It is possible to do more work in a cycle which is a CISC philosophy as many CISC memory access instructions are the equivalent of two RISC instructions and can be pipelined together avoiding the common load-to-use stall of RISC. The RISC philosophy was to shorten the cycle time instead.

Hammer Quote:

With the transistor budget increase, X86 vendors implemented its complex instructions without the slow microcode path. Fast path, secondary fast path, and slow path instruction's determination need to be tied with instruction usage statistics and compliers. As the transistor budget increases, more instructions are moved into the fast path. The RISC threat is real when the CISC competition is heavily ROM'ed microcode 68030 or 80386. RISC is good for small transistor budget CPUs. Unaccelerated Doom on 3DO is running on ARM60 at 12.5 Mhz which rivals 68030 @ 50 Mhz. Modern X86-64 CPUs still have microcode engines with updatable firmware for in-the-field bug fixing instead of a product recall.

Pipelining, ALUs and barrel shifters use transistors which the early 68k and x86 CPUs did not have enough of so they had to loop back through fewer stages using limited resources as necessary, with more complexity and using additional cycles for what would normally be free on later CPUs. Even the 68040 did not have single cycle throughput for all common simple integer instructions and some common addressing modes cost additional cycles. The 68060 finally had single cycle throughput for most common integer instructions and most addressing modes were free, except (bd,An,Rn*SF) and double memory indirect modes which are broken into 2 instructions. There is also a rather artificial 6 byte/instruction limit for single cycle throughput instructions as Motorola tried to be more RISC like. ColdFire lopped off support for instructions greater than 6 bytes all together calling it a "variable-length RISC architecture" including the resulting RISC like performance loss and user loss due to RISC like annoyances the 68k did not have. At least the pipelining and resources of the 68060 are finally adequate to unlock the performance of the 68k without ucode and looping through a too short pipeline. Unfortunately, it was too late to make a difference for the desktop and consoles due to delays with 68040 development. Unlike the Pentium, there was even enough silicon left to double the 68060 caches from ucode and other savings if there had been high end markets to support it.

OneTimer1 Quote:

Accumulator oriented instructions might have some benefits on 8-bit machines, because you don't need additional bits for addressing a target register. If you have an architecture with 16, 32 or even 64 bit data bus, you will drop this concept very fast, instead you will ask how many registers are really useful, how can I support high level languages. Supporting accumulator oriented architectures like the i386, is only useful for backwards compatibility.

Inferred register non specifications reduce code size due to saving encoding bits but the lack of orthogonality limits ILP and memory traffic may increase. Yes, x86 is a CISC and accumulator architecture hybrid that x86-64 attempts to make more orthogonal with more GP registers added. The 68k is a CISC and mem-mem architecture hybrid instead. A mem-mem architecture reduces instructions executed, reduces code size and reduces memory traffic even compared to CISC. Also, 68k orthogonality is unaffected and even applies to mem-mem accesses.

Architecture | Instruction Count | Code Size | Memory Traffic
Accumulator 10 240 560
Load/Store (RISC) 10 266 458
Reg-Mem (CISC) 8 210 402
Mem-Mem 5 171 363

Classifying Instruction Set Architectures (see page 9 for table above)
http://cs.uccs.edu/~cs520/S99ch2.PDF

@senseless

While catching up on the latest posts in this thread my mind wondered over to this idea of "senseless".

While we have proven over and over again that any attacks on PowerPC, imagined or real, are all thoroughly justified with mountains of sense beneath them. I did remember a time when we did sling senseless sophomoric attacks over the trenches, aimed at our brute-force little-endian-that-could: intel.



Really? This was the pinnacle of our collective 68k badassery? How is this even an insult?
If a person came up to you and mockingly stated "Looks like you have intelligence on the outside".
Thanks, I guess?

It was all so senseless.
In reality, what about the awesomeness of the pre-emptive multitasking Amiga OS was specifically so because of the tight 16/32-bit elegance of 68k? Could it no be equally sector defying on a 286?
Is there something special in the 68k CPU without which the custom chipset would literally just be "too much hardware"?

Seems to be just a matter of timing. When the team were dreaming up the Amiga, the 68k existed and it was in the favourable price/performance bracket. Were they to have started later or intel moved to CPUs earlier and therefore the 286 available earlier, there's an equal chance that the A1000 dream machine could've been a 16-bit, little-endian x86 @ 6MHz with OCS.

Windows on the other hand sucked major balls. Every attack on MS Windows up until XP was entirely rational.

_________________
All the way, with 68k

@agami

Quote:

Could it not be equally sector defying on a 286?

No, it couldn't, you'd have to start with 80386.

In the 90s, the only "Intel systems" I owned personally, were a few StrongARMs - I assure you, when I started my "ARM adventures", StrongARM was still DEC!

In general, for me at least, anything was fun and interesting, as long as it wasn't x86. I believe the only "Intel x86" system I have ever bought myself was the original Xbox (of which I have two). Not saying I don't have them (well, amd64), but all that I do have are outdated stuff that were on their way to destruction.

Last edited by kolla on 23-Apr-2024 at 12:24 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@agami

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

https://www.youtube.com/watch?v=xCBrtopAG80

Its not about hating x86 or not, but yeh, the old assembly was not as readable as 68K or PPC assembler or whatever. Everyone writes C/C++ code, no one cares.

Supporting obsolete 386 opcodes, 486 opcodes, is irrelevant, because they are broken down into micro-opcodes (And you need micro opcodes for newer more useful instruction anyway, so you get legacy support for free.).
the process of braking down instruction into micro-opcode, that is the bottleneck, one of problem is that instructions have different length, so you can’t start decoding next instruction at same time as current, so fixed length like PowerPC or ARM instructions, is easier to decode.
Breaking down instruction into simple sub task, instruction makes it easier to run instructions in parallel.

Last edited by NutsAboutAmiga on 23-Apr-2024 at 04:39 PM.
Last edited by NutsAboutAmiga on 23-Apr-2024 at 04:34 PM.
Last edited by NutsAboutAmiga on 23-Apr-2024 at 04:20 PM.
Last edited by NutsAboutAmiga on 23-Apr-2024 at 04:18 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Gunnar

Just on the subject of atomics I could tell from the context what Hammer meant without using specifically atomic instructions.

Quote:

Famous examples: ADD.l #$123456,myvariable

This would be an atomic operation in basic form. WRT to the internal read, addition and write back. It completes as one read-modify-write operation.

OTOH PPC has no direct equivalent. Since it must load to register, add, then write register back. It does have lwarx and stwcx. But there seems mixed info on that, as Apple recommended against it. It's only on PPC and not Power. Without it I don't know how atomic code could execute on PPC or Power. How would PPC or Power be a SMP compliant CPU without any RMW used at all?

On AmigaOS/4 it's also rather awkward as Forbid() relies on it to be atomic. Even without any mult core support it needs that RMW on the Forbid counter to be atomic. Even using lwarx and stwcx isn't efficient as the counter is a byte and PPC likes longs. The code would likely need a few more than 3 instructions masking off an add or subtract to a byte. But at least in AmigaOS it wouldn't need to keep looping around until a reservation was cleared like in common examples. Which just looks like a bad example and bad design.

Quote:

The RISC CPU has some disadvantages mainly for the users, the customers but they give the manufacturer a big advantage that they are faster and cheaper to design and to verify.

But, in the case of PowerPC, not cheaper to sell!

Last edited by Hypex on 23-Apr-2024 at 05:05 PM.

agami Quote:

In reality, what about the awesomeness of the pre-emptive multitasking Amiga OS was specifically so because of the tight 16/32-bit elegance of 68k? Could it no be equally sector defying on a 286? Is there something special in the 68k CPU without which the custom chipset would literally just be "too much hardware"? Seems to be just a matter of timing. When the team were dreaming up the Amiga, the 68k existed and it was in the favourable price/performance bracket. Were they to have started later or intel moved to CPUs earlier and therefore the 286 available earlier, there's an equal chance that the A1000 dream machine could've been a 16-bit, little-endian x86 @ 6MHz with OCS.

The 68000 was a huge part of the Amiga history and the 68k Amiga would not be nearly as good today without it. The Amiga may not have happened without the 68k. Jay Miner seriously wanted to do a 68000 based system when he worked at Atari.

http://www.bambi-amiga.co.uk/amigahistory/jayminerinterview.html Quote:

The year was 1979 and Atari was rolling in money. However, they made a decision to write off all the development costs in that first year of production. This allowed them to show just enough profit that year to not quite trigger the bonus payments they promised to the engineers and programmers. The chief programmer on the projects name was Larry Caplin and a half a dozen of his team went off to start Activision. This was the beginning of the end for the old Atari however, I wanted to do an advanced 68000 machine at the time to compete with Apple but Atari decided that they did not need another computer. They decided not to pay the bonus they promised me and the engineers. So I quit, as did many of the engineers and programmers. Atari then decided to produce a bunch of junk cartridges, thinking the public would buy anything I guess. I blame them in large part for the crash in the video game business that happened a few years later. I spent the next 3 years in a chip company called Zimast doing special purpose computer chips for heart pace makers.

Jay was willing to forego his bonus for an opportunity to create a 68000 computer at Atari. Jay took the "m68k idea" all the way up the ladder to Nolan Bushnell and left Atari when "the m68k idea was rejected".

https://www.lemonamiga.com/forum/viewtopic.php?t=12673 Quote:

The next project he set himself was in 1979, when he got the idea to create a sixty-eight thousand machine using the new Motorola 68000 (sixty-eight-thousand) also called the m68k chip. But due to internal dealings within Atari, some of the money the engineers and game designers were promised for designing the chips and making the games wasn't being paid, so the games guys left Atari to form Activision, and the tech guys left Atari, often to form other companies. Jay went to Nolan directly with his ideas, but the m68k idea was rejected, so he left to spend the next three years in the medical industry with Zimast; including inventing the chips for a remote-control pacemaker. (please dont sit on the controller).

http://www.projectfirestart.org/interviste/jay_miner_eng.html Quote:

Jay: The story starts in the early 1980`s with a company not originally called Amiga, but Hi Toro, which was started by Dave Morris, our president, but before all that I used to work with Atari and I wanted to do a 68000 machine with them. We had just finished the Atari 800 box and they were not about to spend another umpteen dollars on research for a 16-bit machine and the processor chip itself cost $100 apiece. RAM was also real expensive and you need twice as much. They couldn’t see the writing on the wall and they just said “No�, so I quit!.

When Jay was approached to work on what would become the Amiga, he had two requirements.

1. 68000
2. computer (in addition to game machine)

https://youtu.be/ciEe5nNrTXM?t=160 Quote:

It started with the idea of a video games machine and I was working at Zymos for Burt Braddick, and they wanted me to design the chips, so that Zymos could build the chips and Amiga could sell the games, and everybody would make money, that was the idea. But when Larry Kaplan left, they needed some help, so they asked me if I would take over and be the vice president of engineering of Amiga. And I said "sure", provided, number one, we get to use the 68000, and number two I get to make it not only a game machine, but a computer. I had a lot of ideas for a computer, that Dave Morse and the investors seemed to like, even though they were primarily interested in a video games machine. As long as we could make it expandable and it didn't cost too much extra, they were willing to go along with it also being a computer.

It is reasonable to believe Jay Miner may not have worked on the Amiga without a 68000 CPU and it would not be what it is today if it had received a lesser alternative. The battle was not over to cheapen the 68k though.

https://youtu.be/n-MqC35aWrQ?t=545 Quote:

There was a lot of pressure at first to use the 8-bit version of the 68000 microprocessor that was called the 68008 because it was a little cheaper at that time and because it had less pins and a smaller package. It was only 8 bits out instead of 16. We won that battle I'm happy to say because later the price of the 68000 came down to be equal to the price of the 68008. Almost nobody uses that first one anymore. But we had to give up on the idea of having sockets for future math co-processors and future memory expansion management units because of the socket cost and the space that they required inside the box and their uselessness to video games. ... The early choice of the 68000 microprocessor was very important to the Amiga as a personal computer. This choice has helped to give the Amiga superior computing power and has allowed continuous user upgrades with the new Motorola microprocessors such as the 68020 and the 68030. These upgrades give the Amiga the speed and processing power of expensive workstations. What is generally not appreciated however, is that this processing power can be very important and useful for games and simulations making them faster and more complex. And guess what, the next generation is in the works, the Motorola 68040 chip will be available on the Amiga, real soon now. ... In addition, all present Amiga software is compatible with all Amigas, big and small old and new. I want to repeat that because I think that's one of the most important features of the Amiga. All present Amiga software is compatible with all Amigas, big and small old and new. Those two features, expandability and software compatibility are, I think, unique in the personal computer industry and in the game industry and a big advantage in both of those fields yet it isn't even advertised.

The 68k Amiga would not have been a full 16 bit system with a 68008. Accessing 16 bit registers could not have been done in a single cycle. Memory would have been limited to 1MiB instead of 16MiB using the early 48 pin 68008 (68000 has 64 pins). The 68008 is internally 16 bit with 32 bit registers and a 32 bit ISA but 8 bit data bus (memory, register) accesses would have gimped the system. Jay would probably have liked to go in the other direction for the 68010 or full 32 bit 68020 but that was added expense, the 68010 was a minor upgrade, the 68020 was in low supply and the Amiga chipset is only 16 bit anyway.

There weren't many good alternatives to the 68000. The 80286 was a larger CPU (about double the logic), more expensive (more than double?) and still didn't have a flat address space. It was one of the earliest CPUs to have an on chip MMU but memory addressing was still a mess. The 80386 is the x86 CPU that finally brought sanity to the x86 address space but it was too late to consider for the Amiga. The 8086 was cheap enough to be worth considering but Jay likely liked the 68k at least in part because of the flat memory space and 16MiB address space (8086 is 1MiB). The 1982 NS32016 was worth consideration being a mostly 32 bit CPU, one of the earliest, with a highly orthogonal clean 32 bit ISA and flat address space with an optional MMU but it was hampered by bugs allowing the similar 68k to gain most of the 32 bit ISA market share.

https://en.wikipedia.org/wiki/NS32000

The 68k clean 32 bit ISA and flat address space are major reasons the 68k Amiga seems so modern today in emulators with memory sizes unheard of during the C= Amiga lifetime. Some systems based on other CPU architectures after the 68k Amiga was released were more limited like the 1987 Acorn Archimedes with RISC OS and ARMv2 CPU that was limited to a 26 bit address space (64 MiB). A 808x or x86 CPU would have been worse. Jay Miner knew exactly what CPU he wanted for his computer and his interviews document his struggle to obtain it. The 68k really was the best choice for an expandable computer at that time and his choice holds up today. It's not Jay's fault pencil pushers at Motorola threw out their 68k baby with the bath water anymore than it is his fault that pencil pushers at C= committed financial suicide.

Last edited by matthey on 23-Apr-2024 at 07:07 PM.
Last edited by matthey on 23-Apr-2024 at 06:58 PM.
Last edited by matthey on 23-Apr-2024 at 06:33 PM.

@vox

Hello and welcome back.

Quote:

In practice, a lot of clean WB software, simply does not work on OS4 but does work on MOS.

What would be some examples? Some software may look clean but under the hood was a different story. Even 68K stuff I wrote had issues, that ended up crashing, when I found I had misused some functions unintentionally.

Quote:

On PayBack: It does not work properly under OS4, I have tried, even with latest updates. Does Petunia have penalty to native PPC software? I suppose to some extent.

I had it working okay. years ago on my XE. I'm sure I was running the WOS version as well but need to check that. But, the sound was always missing, because the game banged hardware. Like most games did. Anything playing modules banged it.

I also tried the OSX version on Mac. Another PPC version. Where it worked fully and brought me back to the Amiga again as it was like how it was meant to be. It was also rather disappointing. He ported it to Mac so where was the AmigaOS4 port back for the Amiga community?

Quote:

NallePuh is not part of OS4 and is not perfect Paula replacement. Tried to use NallePuh and CIA Agent to make OS4 more Amiga friendly, but did not help.

They shouldn't be used together as they both patch the same function. But the agent does check and won't quit if another program patched it. Don't know what NallePUH does in that case. Well now NallePUH can do both audio and CIA. Plus I contributed to it despite the conflict of interest and now CIAgent is way behind.

The only support the OS has is audio.device. Which caused confusion as people thought it meant module players would work. No, but even OS4 audio.device is buggy now, since the lock command is faulty.

OS4 is a strange mix. It has design and implementation with a focus on backward compatibility. But at the same time goes against it.

MOS also has issues. OctaMED is one and always froze. I found out why is that MOS cannot run an interrupt that hits the hardware. The MED module interrupt checks for mouse buttons and this instantly freezes. I am surprised because this is basic emulation. On OS4 it just ignores it. It's not an issue any more since I released a patch called OctaMEDIC.

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. Plus, it was made worse by Enhancer, with their own DOS command replacements that initially had faults as well!

Quote:

On side-note, I wonder how much more progress would be made if MorphOS was made official.

Well, they would need to clean up the above problem for a start. There are other issues, such as it doesn't use a system standard GUI. But the biggest would be, MorphOS is not AmigaOS and isn't based on the AmigaOS code base. It's a copy. So, at this point, any proposed replacement would need to be AmigaOS compliant. If AmigaOS was turned into a standard. From which AmigaOS compatible OS could be produced if that was the future.

Last edited by Hypex on 24-Apr-2024 at 07:12 AM.

@matthey

I get that that is the way it happened, and I totally appreciate being passionate and borderline single-minded about building something around some extremely cool tech. I'm sure there's a whole bunch entrepreneurial engineers who are geeking out on some project based on RISC-V right now.

While in the early '80s Motorola's 68000 was THE object of tech desire, I'm more wondering had intel released the 286 in the same time-frame, and perhaps it was a bit cheaper, would it not be able to serve the purpose of building a 16-bit computer with 256MB RAM and custom chips, providing it with industry defining video and audio capabilities?

I appreciate that it might have been a bit more challenging for the team in light of x86 assembly not being as programmer friendly, but does that mean that it would've been outright impossible?

If the Amiga was just another 68k computer with custom chips and a multitasking OS, could it not have also been another x86 computer with custom chips and multitasking; if the 286 was available in that time-frame, at the right price, and Jay Minor did not have such a hard-on for 68k?

It's worth examining this cult-like behavior, because all that senseless intel/x86 hate in the late '80s and through the '90s didn't amount to anything.
Some of intel's business practices of the time were quite reprehensible, but I knew nothing of that then. My disdain for intel was synonymous with the lameness of DOS-based computing, and even ugly and expensive Windows-based computing.
But Windows didn't suck because x86 sucked. It sucked because MS didn't care to make it very good. Which IBM proved to be possible with OS/2.

So maybe, and I can't believe I'm even thinking this, maybe @ppcamiga1 has a point. 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.

_________________
All the way, with 68k

@agami

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.

I was just as enthusiastic about PPC back when 68K ceased to be developed as the next guy. It was a proven migration path, PPC was relevant as a desktop CPU and the future looked pretty bright.

The situation is a bit different now. PPC is dead as a desktop platform, just as dead as 68K was then. Hell, maybe even more so. Yet we don't seem to have learned the crucial lesson that the answer to this problem is to move to something else that isn't dead. Whatever that is, we aren't getting away from the need to emulate 68K if we want to stay compatible with the largest majority of Amiga software. So we are left with only one question, which is, what to do with the PPC software?

PPC emulation isn't great. It's not as terrible as it was, but expectations matter and many people have used PPC machines that are fast enough that emulation of them is not going to be as good.

On the flip side, almost all PPC software still has source code and that source code is mostly written in portable languages. So it could mostly be recompiled for whatever architecture you want to move to.

Attacking PPC hardware is senseless, but so is sticking to it.

_________________
Doing stupid things for fun...

@Kronos

Quote:

Stuff like the Draco (and the separate Z3 cards that could work in an A4000) did a minimal 1st step in that direction but just couldn't keep up with PPC Macs or x86 PCs

And follow ups like the Casablanca, after they ditched the 68K Amiga architecture, didn't even migrate to PPC or any other similar architecture. They just went the PC and went x86. They were ahead of Apple.

@OneTimer1

Well, of course they ignored UAE, since OS4 already had built in 68K emulation that worked directly in the OS. Plus with UAE you could just run it on a cheap PC so it wouldn't offer much. However, with OS4.1 or at some point, they included OS3.1 and ROMs, with RunInUAE as contrib.

An AGA FPGA on board instead of X1000 XCore or Sam Lattice would have helped. But, there is still a problem as 68K code would still need isolation. Most code banging hardware would have needed emulation isolated from the native OS but able to access chip space.

@agami

Quote:

While in the early '80s Motorola's 68000 was THE object of tech desire, I'm more wondering had intel released the 286 in the same time-frame, and perhaps it was a bit cheaper, would it not be able to serve the purpose of building a 16-bit computer with 256MB RAM and custom chips, providing it with industry defining video and audio capabilities?

A 16 bit 286 wouldn't be able to access 256MB of memory, since it has access to 16MB with a 24 bit address bus!

In addition, the 286 is still a 16-bit CPU, from reading about it online. So it still lacks in the data department. Though the Amiga chipset is 16-bit oriented with 16-bit hardware registers, the 68K it is designed with has fully 32-bit registers. Aside from the CIA, which is a little endian chip, with 8 bit design. So, to fully match even the 68000, an x86 Amiga would need a 386 with full 32-bit registers. Looking back at this, given Motorola had a lead with a hybrid 16 bit/32 bit CPU with full internal 32 bit registers from the first model, it's disappointing it was beat in the end by a CPU that needed its register width extended and memory extended to linear model while playing catch up to those features.

Quote:

I appreciate that it might have been a bit more challenging for the team in light of x86 assembly not being as programmer friendly, but does that mean that it would've been outright impossible?

Going by PC history, I would say not. Google ASM and you will see plenty of articles about x86. Many people became keen x86 assemblers. They could count the x86 register alphabet in their sleep. Where as the only x86 ASM I did was playing with DEBUG.EXE emulated in PCTask which I found interesting to play with. But the sensibility of 68K ASM made x86 ASM look cryptic and it isn't a hobby I would want to pursue. It help to shine some light on the 20-bit x86 memory extension. I had a book describing it and never understood it, since the 68K made such extensions look senseless. When I did understand it years later, how a 4-bit shift value extended 16-bit to 20 bits, it looked even more senseless and I thought it was totally stupid! Why didn't they just make it a 16 bit shift, extended to 32 bits, but limited to a 4 bit shifting at present? Of course, even the 68000 didn't need this extended memory hacking since it was 32 bit address registers from the get go, so it all looked stupid to me taking a crippled design and extending it beyond what it was designed to do.

agami Quote:

I get that that is the way it happened, and I totally appreciate being passionate and borderline single-minded about building something around some extremely cool tech. I'm sure there's a whole bunch entrepreneurial engineers who are geeking out on some project based on RISC-V right now. While in the early '80s Motorola's 68000 was THE object of tech desire, I'm more wondering had intel released the 286 in the same time-frame, and perhaps it was a bit cheaper, would it not be able to serve the purpose of building a 16-bit computer with 256MB RAM and custom chips, providing it with industry defining video and audio capabilities?

IBM released their model 5150 PC in 1981 with the 8088. What did Jay Miner think of the IBM PC? He was asked in 1990 a question whether the Amiga technology was vulnerable to competition.

https://youtu.be/n-MqC35aWrQ?t=2816 Quote:

It's definatly vulnerable. It's always a problem when you come out with a machine as backward compatibility and IBM has been has had that albatross around its neck for a long time now backward compatibility and has cost them in future developments. And it happens to every company that gets into this business. The technology moves so fast but what you can do and what will happen I think and is happening with IBM is that you can maintain backwards compatibility by keeping the present chipset and future versions of that chipset, keeping them in there, and adding new processor architecture around it, like I understand people are now working on a version of the Texas Instruments frame buffer display handler card for the Amiga. That is an example of a microprocessor that is dedicated to display that is separate from the core Amiga which is backward software compatible, and I think you will see that in almost all the older computers such as the Amiga the Mac and the Atari and the IBM. You'll see that in all those and as new companies start up to make new computers based on the new technology and the new cost of rams and the density of integration, as these companies come along, they put those older companies in a bad position and eventually the older companies have to say the heck with it. At this point it's more important to be competitive than it is to be backwards compatible. At that point, and only then, is when these new companies will come out with this new technology.

The question was specifically about graphics, but it applies to all the computer technology. The IBM PC designers made poor hardware choices that made the hardware difficult to upgrade while maintaining backward compatibility. Jay Miner made choices that made the 68k Amiga easy to upgrade with backward compatibility, even though C= killed his Ranger chipset upgrade as he knew the Amiga would become vulnerable without maintaining its position ahead of the competition. The Amiga could have used most 16 bit CPUs but it wouldn't still be viable hardware to upgrade today. Users aren't using the same 808x software with MDA/CGA graphics today. It may be possible with a huge amount of baggage in x86-64 CPUs and a smaller amount of baggage in graphics boards, BIOS, etc. The 68k Amiga has less baggage and even 68000 software performance is good enough that the Hyperion 68k AmigaOS releases optimize for it. Can you imagine Windows optimizing for a 8088 or even a 80286? The software performance would be very poor and would lack many modern features. A 68060+AA+ SoC could be produced for less than $1 today that holds all the 68k Amiga baggage for backward compatibility. With a few more modern upgrades, this would be a viable low end system today and could be produced for not much more. What is the cheapest x86(-64) hardware on the market with all their baggage? Where is it competitive except high performance high end markets?

agami Quote:

I appreciate that it might have been a bit more challenging for the team in light of x86 assembly not being as programmer friendly, but does that mean that it would've been outright impossible? If the Amiga was just another 68k computer with custom chips and a multitasking OS, could it not have also been another x86 computer with custom chips and multitasking; if the 286 was available in that time-frame, at the right price, and Jay Minor did not have such a hard-on for 68k?

I don't you think you fully understand the knowledge and vision of Jay Miner. His 68000 choice was perfect as was his choice for 512kiB of memory as he correctly predicted that integration would bring the prices down like it would for the Amiga custom chips. Jay talks about the 68000 cost of $100 when he wanted to start the project at Atari.

http://www.projectfirestart.org/interviste/jay_miner_eng.html Quote:

Jay: The story starts in the early 1980`s with a company not originally called Amiga, but Hi Toro, which was started by Dave Morris, our president, but before all that I used to work with Atari and I wanted to do a 68000 machine with them. We had just finished the Atari 800 box and they were not about to spend another umpteen dollars on research for a 16-bit machine and the processor chip itself cost $100 apiece. RAM was also real expensive and you need twice as much. They couldn’t see the writing on the wall and they just said “No�, so I quit!.

Actually, the 68000 price had already dropped significantly by that time as new chips are much more expensive.

https://www.nytimes.com/1984/06/29/business/motorola-s-powerful-new-chip.html Quote:

Initially, the chip will be quite expensive. Motorola said the first models will sell for $487 each, close to the price of the 68000 when it was first brought out in 1979. But as with all semiconductor products, the price of the 68000 plummetted as volume production began, and it now sells for about $15. ''We have every reason to believe the experience with the 68020 will be the same,'' said Murray A. Goldman, corporate vice president and general manager of Motorola's microprocessor division, in a recent interview. In 1985, he said, the company would likely ship only 100,000 units of the new chip.

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.

https://en.wikipedia.org/wiki/Intel_80286#Support_components Quote:

82230/82231 High Integration AT-Compatible Chip Set - The 82230 covers this combination of chips: 82C284 clock, 82288 bus controller, and dual 8259A interrupt controllers among with other components. The 82231 covers this combination of chips: 8254 interrupt timer, 74LS612 memory mapper and dual 8237A DMA controller among with other components. They are available by second-sourced with Zymos Corp. Both set are available USD $60 for 10 MHz version and USD $90 for 12 MHz version in quantities of 100.

Does that 2nd source chip provider, Zymos, sound familiar? Guess who worked for Zymos?

Jay Miner knew hardware and knew exactly what he wanted which was the 68000. Marketing people tried to talk him out of the decision but thankfully he stood his ground and finally got what he wanted. From a hardware perspective, the 68000 was the best choice for a personal computer and video game machine at that time. There were CPUs which had better software support but he was a hardware guy and the 68000 just happened to be one of the friendliest to program in assembly of all time too, which was another reason to double down on it.

agami Quote:

It's worth examining this cult-like behavior, because all that senseless intel/x86 hate in the late '80s and through the '90s didn't amount to anything. Some of intel's business practices of the time were quite reprehensible, but I knew nothing of that then. My disdain for intel was synonymous with the lameness of DOS-based computing, and even ugly and expensive Windows-based computing. But Windows didn't suck because x86 sucked. It sucked because MS didn't care to make it very good. Which IBM proved to be possible with OS/2.

The Intel outside slogan may be childish in a way but it is also a joke. If it makes people laugh, then mission accomplished. The 8086 CPU was actually a good 16 bit CPU for an upgraded 8 bit CPU but it had limited upgrade potential. This caused growing pains with attempts to upgrade it as Intel seemed lost with the 80186 and 80286 which were underwhelming. The 80386 turned around Intel's x86 fortunes showing that it could be upgraded by deprecating many of the 808x 8/16 bit features which were retained as baggage for backward compatibility. The 68000 has a relatively clean 32 bit ISA with only a few ISA mistakes made here and there. It could certainly be argued that more of the ISA mistakes were made with the 68020 ISA upgrade which has some important upgrades but missed the mark in some ways and was too complex for the time. The 68060 shows that the ISA did not limit performance and the small core size compared to x86 and elimination of ucode demonstrates significantly less baggage than x86. There is the saying that it is better to be lucky than good. Intel was lucky that IBM chose them for the IBM PC but they deserve some credit for being persistent, at least until the Itanic mistake when AMD took over being persistent. At least Intel was smart enough not to throw out their ugly baby like Motorola did with their beautiful baby as they bet on the wrong race horse.

agami Quote:

So maybe, and I can't believe I'm even thinking this, maybe @ppcamiga1 has a point. 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.

Attacking PPC is senseless because PPC is dead, nobody cares about PPC because it sucks and an Amiga is still the more compatible 68k Amiga preferred by retro fans. As bad as PPC sucks, the PPC hardware choices suck more everyday even as they become more expensive. Hyperion sucks as it is flushed down the drain with PPC. Trevor is the only investor on earth that would still invest in PPC hardware after two decades of failure and with a hot retro 68k Amiga market. AmigaOS 4 may have some usefulness for modernizing the 68k AmigaOS but I predict the PPC AmigaNOne era is over. Some Amiga users may want to port the AmigaOS to other architectures but it only divides the user base and MorphOS and AROS have a head start with minimal success. The Amiga lives or dies on the 68k and emulation of the Amiga is dying.