@cdimauro

Quote:

It's incredible: you miss no opportunity to show your ignorance. https://theamigamuseum.com/amiga-kickstart-workbench-os/kickstart/kickstart-1-2/ Kickstart 1.2 first appeared in October 1986 [...] this was the first version of Kickstart that not only came on a floppy disk for the (newly renamed) Amiga 1000 https://theamigamuseum.com/wp-content/uploads/2016/10/A1000-Kickstart-v1.2-rev-33.166.txt Kickstart 1.2 (33.166) for Amiga 1000 Size: 256 kB Year: 1986 Checksum: OK (F989BAC3) Resident modules: 23 https://wandel.ca/homepage/execdis/exec_disassembly.txt The following is a complete disassembly of the Amiga 1.2 "exec", as found on a kickstart disk for an Amiga 1000. WHEN you will SERIOUSLY STUDY something in your life?

That's useless when A1000's unit sales are pretty pathetic.

Are you claiming Kickstart 1.2 was publicly available in 1986?

From Commodore - The Final Years

Easter Egg

In early 1987, the Amiga software team was nearing completion of
AmigaOS 1.2. The new system, which would be released along with
the A500 and A2000 computers, was a much more complete
operating system compared to the previous two releases. But it also
contained a nefarious message.

According to RJ Mical, “In the end, we were feeling that we had
done this beautiful work of art, and then Commodore, for their lack
of experience or their lack of knowledge about the computer
industry, let us down.�

When working on Workbench 1.2, an Amiga engineer inserted a
message expressing his feelings towards Commodore. “This
happened when I was director of the whole effort,� explains Mical.
“One day, one of the guys showed me with great delight what they
had put in there. It was this thing where you had to press a certain
number of keys on the keyboard and it would bring up this message
that said, ‘We made the Amiga, they fucked it up.’ I saw that and I
made a sort of nervous chuckle.�

Mical knew the parting shot at Commodore could not remain. “I
said, ‘This is cute but we can’t really put this in the machine. That’s
just not acceptable.’ They said, ‘Aw, come on!’ I said, ‘No way, man.

We’re just not putting this in the machine. You’ve got to take it out.’�
Mical double-checked before signing off on the code. “The final
release of the OS was done, and with great fear I did the keystrokes
to make sure that it wasn't there,� he recalls. “When you put in that
keystroke, a line of text came up, but it said, ‘The Amiga, born a
champion.’�

Unknown to Mical, the offending text remained. “They didn't take it
out,� he says. “All they did was bury it one level deeper and encrypt
it.� Now it remained to be seen if anyone would discover the secret.

With the Amiga team’s impending departure, Commodore engineers
now had to take full responsibility for any further AmigaOS
development. This was difficult but not futile because many of
Commodore’s programmers had already been developing parts of
the AmigaOS; generally low-level support modules such as printer
drivers. The team included former VIC Commandos such as Andy
Finkel and Eric Cotton, as well as other programmers like Benny
Prudin and Judy Braddock. They had gone from learning C-language
to mastering the AmigaOS library.


From your link
https://theamigamuseum.com/amiga-kickstart-workbench-os/kickstart/kickstart-1-2/


but due to frustrations with Commodore within the Amiga team, an Easter Egg was hidden in
Kickstart 1.2 that was, well, not complimentary to Commodore. Commodore management
found out about it and stopped rollout of machines with the new Kickstart while they
removed the offending message and changed it. Unfortunately, this meant that the new
Amiga 500 was unavailable to most of those who wanted it for Christmas 1987.


Production delays due to anger against Commodore's management.


Quote:

It's incredible: you miss no opportunity to show your ignorance.

Look in the mirror, TURD. You didn't read your link's rollout delay with the Easter Egg message. LOL

Try again.


Furthermore, ALL full 32-bit CPU accelerated Amigas with OCS/ECS are unable to join the 256 color gaming standard during the critical 1992 to 1994 date range.


It doesn't pay to be on the bleeding edge with the Amiga while the full 32-bit PC counterpart was able to join the fast VGA gaming standard.

Only Commodore made it possible to place 68030/68882 @ 25MHz class machines like the A3000 unable to play 256 color games standard i.e. obsolete before its time.

Igouring Commodore Germany's AGA ASAP wasn't good for the platform's evolution.

Ignoring Dave Haynie's modular Amiga with a partitioned Amiga multimedia card wasn't good for the platform's evolution. AGA Amiga platform was ground zero reset like a games console.

CGX RTG was a 1995 experience.
P96 RTG was a 1996 experience.

During 1992, the main reason why I had a 386DX33/ET4000 gaming PC was due to the dead-end A3000 from 256 color gaming.

Last edited by Hammer on 02-Apr-2025 at 06:31 AM.
Last edited by Hammer on 02-Apr-2025 at 06:27 AM.
Last edited by Hammer on 02-Apr-2025 at 06:25 AM.
Last edited by Hammer on 02-Apr-2025 at 06:09 AM.
Last edited by Hammer on 02-Apr-2025 at 06:00 AM.
Last edited by Hammer on 02-Apr-2025 at 05:57 AM.
Last edited by Hammer on 02-Apr-2025 at 05:54 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

My CD32 with SX-1 w/8MB fastram running OS3.1 became a turd when I turned on 256 color Workbench. The 65C02-powered Commander X16 runs circles around it with better graphics and sound.

AGA was a turd. The C65 had AGA capability in 1990.

When I worked at Motorla's ISG division in the late 90's...I saw the 68LC060's going into cable-modems. (yes years before they were mainstream...) I managed to snag a spare one and sell it on ebay.

Fast-forward to the 2000's and it's the 6502 powering Motorola set-top boxes...go figure!

Renesas Electronics who produced the SuperH for Hitachi - they also make water-heater controllers... Guess what cpus are in those? It's Renesas' 6502 variant.

If 68K is so cool...and you know you can't do anything without 16 or 32 bits...then why isn't it still alive?



Instead of moving on let's just:



ARM won.

Port to ARM and just emulate the old turd. Move on!
Meanwhile, let's wait 136 cycles for that super-cool DIVU command to finish.
ARM UDIV executes in 12 cycles.

Tell me again how great 68k is ... I'm listening...

Hammer Quote:

IBM's Power 4-based PPC 970 wasn't a shallow pipeline design. PPC 970 the following: # 10 stages for simple integer and permute instructions. # 13 stages for complex integer instructions. # 16 stages for floating-point instructions.

The PPC 970 (G5) had a very deep pipeline but it was not practical for general use and was very expensive. It was kind of like the earlier PPC 604e that was too expensive for the masses except the PPC G5 was less practical. The more practical PPC G4+ had finally moved to a 7-stage pipeline that allowed higher clock speeds by the time the G5 was released.

year | CPU | type | int pipeline | max clock | process | transistors (millions)
2002 PPC970 OoO 16-stage 1.8GHz 130nm 52
2001 PPC7450 OoO 7-stage 1.25GHz 180nm 33
1999 PPC7400 OoO 4-stage 550MHz 180nm 10.5
1997 PPC750 OoO 4-stage 700MHz 220nm 6.4
1996 PPC604e OoO 6-stage 233MHz 350nm 5.1
1995 PPC603e OoO 4-stage 300MHz 350nm 2.6
1993 PPC601 OoO 4-stage 80MHz 600nm 2.8

1997 P55C in-order 6-stage 233MHz 350nm 4.5
1995 P6 OoO 14-stage 150MHz 500nm 5.5
1995 6x86 in-order 7-stage 133MHz 650nm 3
1995 5x86 scalar 7-stage 120MHz 650nm 2
1994 68060 in-order 8-stage 50MHz 500nm 2.5
1993 P5 in-order 5-stage 66MHz 800nm 3.1

The PPC 604e was not limited by a shallow pipeline but likely the large L1 caches as the PPC 604 with half the caches clocked higher than the PPC604e. A L2 cache solved the problem but it was late and introduced with a shallow pipeline due to deeper pipelines using more transistors and power. CISC 68k and x86 CPUs started with or moved to deeper pipelines earlier and used smaller L1 caches but better code density could make a 68k 8kiB L1i have the performance of a PPC 32kiB L1i based on RISC-V research. Code density for x86 started worse than the 68k and more was lost moving to 32-bit and then 64-bit. All the time and effort was wasted to convert Apple from 68k with a 8-stage 68060 that was practical enough for the masses to PPC with practical 4-stage embedded PPC CPUs for the masses and later expensive PPC CPUs for the classes. The shallow pipeline PPC 603 Macs are the worst Macs ever giving PPC and Apple a bad reputation. They were replaced by shallow pipeline PPC CPUs with larger caches and die shrinks which was more expensive than a deeper pipeline to allow higher clock speeds. Sabotaging the 68060 clock speed was effective at stopping people from saying Motorola and Apple should have stayed with the 68k but it did not help shallow pipeline embedded PPC CPUs compete against x86 desktop CPUs. Another joke is PPC A1222 embedded PPC CPU cores for the masses which received a deeper pipeline but the standard PPC ISA and FPU had to be sacrificed for the masses and the cost of the A1222 is still too high for the classes.

Hammer Quote:

Cyrix 5x86 is a 486-class CPU with a single ALU pipeline, despite what Cyrix's marketing material's "586" class. Pentium class needs two ALU pipelines, and the 6x86 and 6x86L were not completely compatible with the Intel P5 Pentium instruction set.

The scalar Cyrix 5x86 was higher tech than the 486 or 68040 which improved performance. If only old code is executed it is a smarter upgrade than most in-order superscalar CPUs which require recompiles with instruction scheduling for max performance.

https://datasheets.chipdb.org/Cyrix/5x86/5X-DPAPR.PDF Quote:

Unfortunately, initial superscalar designs have been frustrated by the problems of inter-instruction dependency checking and resource usage contention. To manage these conflicts, some designs imposed instruction-issuing constraints on the theory that application programs could be recompiled quickly and easily (based on knowledge of the instruction issuing rules and restrictions) to optimize code flow. Examples of this approach include the PowerPC 601, HP-PA7100 and the Intel Pentium processor - CPUs that can issue two instructions simultaneously but only under restrictive, special-case conditions. These conditions are more of a limitation for the Pentium since the majority of the software it executes will be from the installed base of x86 operating systems and applications. This limitation reduces the effectiveness of issuing and executing multiple instructions. The cost of the second execution pipeline and the complexity of dual pipe control will probably never be justified by application performance benefits in fifth-generation processors that do not have guaranteed access to recompiled software. In the x86 market, recompilation simply has not occurred and will likely never occur. (Note: The sixth-generation M1 avoids this by design - it does not assume recompilation to achieve a high level of multiple issue and execution.)

"The sixth-generation M1 (superscalar Cyrix 6x86) avoids this by design", is true of the similar 68060 design as well. I believe the 68060 will execute legacy code better than the 6x86 because the 68k has a 32-bit ISA from inception so fewer partial register write stalls and better code density with better alignment makes superscalar execution more efficient.

https://old.hotchips.org/wp-content/uploads/hc_archives/hc06/3_Tue/HC6.S8/HC6.8.3.pdf Quote:

45%-55% of instructions issued as pairs/triplets (existing 680x0 code) 50%-65% of instructions issued as pairs/triplets (targeted 68060 code)

The superscalar 68060 can execute another instruction half the time with "existing 680x0 code", only a 4B/cycle instruction fetch and only 500k (25%) more transistors than the scalar 5x86 . This makes the low cost of in-order superscalar hardware compared to OoO hardware worthwhile and is very impressive! This is much better than "two execution pipelines can cost 40% in transistor count while providing an increase of less than 20% in instructions-per-clock performance" of some superscalar cores.

https://datasheets.chipdb.org/Cyrix/5x86/5X-DPAPR.PDF Quote:

The increased complexity, transistor count, and power consumption of superscalar designs led Cyrix engineers to re-examine the benefits of the superscalar approach. Clearly the power dissipated in a second execution pipeline plus the added power dissipated in the control logic to oversee two execution pipelines should be minimal to achieve performance that will justify the transistors added. Analysis has shown that the increased complexity of two execution pipelines can cost 40% in transistor count while providing an increase of less than 20% in instructions-per-clock performance.

The in-order superscalar Motorola 68060, Cyrix 6x86 and SiFive 7 series designs make compiler development and programming easier as well which is important as these 3 designs have received poor compiler support yet have good performance. An older SiFive U74 core outperformed the PPC 970 (G5) in 7-Zip compression and decompression per MHz.

7-Zip benchmark (higher is better)
single core | compression/MHz | decompression/MHz
IBM_Cell_PPE 0.23 0.33 (PS3)
Cortex-A53 0.56 0.92 (RPi 3, A500 Mini, A600GS)
Cortex-A55 0.63 1.03
SiFive_U74 0.70 0.92 (RISC-V 2.64 DMIPS/MHz core)

IBM_PPC_G5 0.49 0.82 (PPC 2.9 DMIPS/MHz core)
IBM POWER9 1.08 0.83

https://www.7-cpu.com/

The SiFive 7 series design removes load-to-use stalls making instruction scheduling easier for RISC cores too. The OoO PPC 970 should be more powerful than a simple in-order SiFive 7 series core but obtaining peak performance is very difficult while the 7 series is much easier to program which shows in the results here. Too many people and architects want and design for maximums when averages and ease of programming are more important.

cdimauro Quote:

Reusing existing/used opcodes for something else is CRIMINAL. Unfortunately, that's what Gunner does (see the CALLM instruction as another example). Specifically, he used LINE-A for such instructions which ColdFire has smartly placed on a different lane. LINE-A could have much better being used for a SIMD/Vector extension! No words...

ColdFire MVS, MVZ, BYTEREV, BITREV and SATS do not use line-A and are open encodings on the 68k but MOV3Q does use line-A.

MOV3Q
%1010 imm 101 EA

Gunnar and I discussed ColdFire support long ago. I came up with the idea to use "OP.L #d16,EA" instead of using MOV3Q. MOV3Q saves 4 bytes per instruction where it can be used but immediates are limited to -1 and 1-7. My idea only saves 2 bytes but immediates can be -32768 to +32767 and it can be used for more than MOVE.L #d16,EA but also OP.L #d16,Dn instructions. Maybe I should have patented that idea but Gunnar did not use it even though he created OPW.L #d16,Dn instructions for some forms in a non-orthogonal way. Anyway, my suggestion was not to use line-A for MOV3Q and it sounded like he was in agreement along with supporting MVS and MVZ which he changed his mind on completely multiple times it seems. Moving MVS and MVZ to line-A moves them with MOV3Q which is likely the logic and he added a SR bit to toggle them on and off for compatibility.

http://www.apollo-core.com/documentation/AC68080PRM.pdf Quote:

Apollo bit. Multitask & additional line-a instructions. ApolloOS always saves the new registers on task switching. A program that sets SR bit 11 keeps e-registers intact when switching task on an rom patched OS like amiga or coffin. The 080 allows it to be set in user-mode. Other bits will of course give a privilege exception as expected. LineA-instructions become valid when the apollo-bit in SR is set. LineA $a000..$a00f will not be used to be atari-os compatible. “LineA� instructions are: clr.q , mov3q , moviw.l , mov(s/z) Ori #$800,sr sets the apollo-bit. Andi #$f7ff,sr clears the apollo-bit. The apollo-bit affects only the program that sets it. Setting it and expecting another program to behave if the apollo-bit is set does not work. So restoring the bit on exit is not needed.

I would rather keep MVS and MVZ where ColdFire has them and move MOV3Q if wanting to keep it. MOV3Q does provide better code density with my idea but my initial conclusion was that it was not worthwhile to find a new encoding.

cdimauro Quote:

Indeed. Nice effort, but nothing really new, "game changer". I also find it weak on some critical areas: constants limited to only a few instructions. Loads/stores only with 4-bit unsigned immediate. And only zero-extended byte/half-word loads/stores. So, I strongly doubt that it can reach very good code density. And it's more suitable for embedded: not so much general-purpose, with a crippled future for extensions.

I agree that MCore is another weak minimalist MCU ISA with mediocre code density and likely poor performance metrics. Maybe Motorola should have negotiated a license for SuperH from Hitachi rather than suing them for innovating 68k like designs. SuperH borrows from the 68k and is more acceptable to 68k fans even though they seriously should have made it a 16-bit/32-bit variable length encoding like Thumb-2. Also, Motorola did not need a lower end ISA than ColdFire. ColdFire could have been lower power but it retained much of the 68k good performance, performance efficiency and power efficiency when scaled down so far. The grass in always greener on the other side of the fence though.

cdimauro Quote:

Yes, it was and still is a very nice architecture. It's a pity that it was killed. But it's missing two important things: a 64-bit extension and a SIMD/vector unit.

The AC68080 has 64-bit support and a SIMD unit. It may not be the ultimate 68k ISA but it is the ultimate FPGA only 68k ISA.

cdimauro Quote:

Those weren't rumours: I've written an article about that, some years ago. Apple was switching to Intel at the very beginning of 2000s. The switch was just delayed because IBM promised the G5 to Jobs. But it was a delay, as we know (G5 flopped).

The people behind PPC AmigaOS 4 were zealots, propagandists and con men with minimal technical knowledge. AmigaOS 4 could have maintained 68k compatibility and been prepared for ports to other architectures. Instead, AmigaOS 4 is still stuck on PPC 20 years after it died on the desktop and 15 years after PPC died for embedded use. The 68k AmigaOS is the only profitable AmigaOS remaining and that only because Hyperion does not pay their developers.

cdimauro Quote:

Commodore is another great example...

And A-Eon. Trevor still loves his PPC, even the antiquated embedded PPC crap. He is King of the zealots, propagandists and con men.

Lou Quote:

If 68K is so cool...and you know you can't do anything without 16 or 32 bits...then why isn't it still alive?

Calculating with 16 bits at a time instead of 8 bits is usually at least twice as fast when needed and calculating with 32 bits at a time when needed is usually at least 4 times as fast as using 8 bits. The 68k is not alive anymore because someone lacking knowledge like you used the 68k profits to invest in new PPC designs instead of new 68k designs.

Lou Quote:

ARM won. Port to ARM and just emulate the old turd. Move on! Meanwhile, let's wait 136 cycles for that super-cool DIVU command to finish. ARM UDIV executes in 12 cycles. Tell me again how great 68k is ... I'm listening...

ARM originally did not have a DIV or MUL instruction like most simplified RISC ISAs. If you think it is better not to have MUL and DIV instructions, show us a 32b/32b=32b assembly routine using original ARM or 6502 assembly. ARM went from the original ARM ISA to Thumb to Thumb-2 and to AArch64 while all of them added MUL and DIV instructions like the 68k. Thumb-2 added a variable length 16-bit encoding with good code density like the 68k. AArch64 added complex addressing modes like the 68k. Modern ARM is more like the 68k than the original ARM that was abandoned/deprecated.

@Lou

Quote:

Lou wrote: My CD32 with SX-1 w/8MB fastram running OS3.1 became a turd when I turned on 256 color Workbench. The 65C02-powered Commander X16 runs circles around it with better graphics and sound.

The X16 sucks. Not C64 compatible. Crappy 6502 CPU. Not retro. Why anyone would want one is beyond me.

Quote:

AGA was a turd.

No, it wasn't. AGA is wonderful. It works fine in 256 colors on my A1200. But I don't run WorkBench in 256 colors because that's silly.

Quote:

The C65 had AGA capability in 1990.

No, it didn't.

Quote:

If 68K is so cool...and you know you can't do anything without 16 or 32 bits...then why isn't it still alive?

Because 'cool' doesn't always mean profitable.

Microchip makes a particularly crappy 8-bit MCU called PIC. Its claim to fame is being the first to feature reprogrammable Flash ROM. Microchip promoted it to hobbyists, as a result of which it became very popular. The PIC's architecture sucked, but this didn't stop it from being widely adopted.

Chip Hall of Fame: Microchip Technology PIC 16C84
Quote:

Back in the early 1990s, the huge 8-bit microcontroller universe belonged to one company, the almighty Motorola. Then along came a small contender with a nondescript name, Microchip Technology. Microchip developed the PIC 16C84, which took an 8-bit microcontroller and added a type of memory called EEPROM, for electrically erasable programmable read-only memory. EEPROM doesn’t need UV light to be erased, as did its progenitor, EPROM. Such read-only memory is generally used to store program code or small bits of data. Eliminating the need for a UV light meant that “users could change their code on the fly,� says Rod Drake, the chip’s lead designer and now a director at Microchip. Even better, the whole chip cost less than US $5, or a quarter the cost of existing alternatives at the time. The 16C84 was used in smart cards, remote controls, and wireless car keys. It was the beginning of a line of microcontrollers that became electronics superstars among Fortune 500 companies and weekend hobbyists alike.

Microchip is still going strong with 8-bit MCUs today, and sales are expected to increase as more devices require 'smarts'. This despite 32-bit ARM MCUs having taken over most of the embedded market. How did they do it? Firstly because they were first. Secondly because they were very cheap and easy to use. I worked with the PIC12C508 which has a whole 512 words of ROM and 8 bytes of RAM. Extremely limiting, but it also came in a tiny 8 pin package which was important for my application. Since I developed very efficient code for that, I stuck with PICs even though other MCUs are now technically much better.

Let me repeat - PIC architecture sucks. But it made a lot of money for Microchip. Motorola's MCUs had a much better ISA, but they weren't as easy for hobbyists to get into so they lost popularity. Often the technically best architecture doesn't win, the one that gets into engineer's heads does. That's why you still see stuff using ancient chips that were superceded decades ago.

Quote:

ARM won.

No, it didn't. I tried ARM and didn't like it. ARM lost!

Quote:

Meanwhile, let's wait 136 cycles for that super-cool DIVU command to finish. ARM UDIV executes in 12 cycles.

The number of cycles is irrelevant. Put an ARM in your Amiga and see how it performs. Oh no, it doesn't understand 68k instructions - won't even get past go! Most people don't even know that it has UDIV because they don't code it in asm, which is fair enough because ARM asm sucks.

Quote:

Tell me again how great 68k is ... I'm listening...

68k is great. I love coding in 68k asm, and it's in the Amiga which I also love. I like the Z80 too, and x86 is passable. AVR is quite nice. Some day I want to do 6809. But 68k will always come first because it's so much nicer.

I've done very little 6502 coding. This probably won't change because what I have seen of it doesn't look good. I have several retro computers with 6502's, but why should I waste my time struggling with them when there is so much I want to do on the Amiga?

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: https://en.wikipedia.org/wiki/Lotus_1-2-3#PC_version_history "Release 2 brought add-in support, better memory management and expanded memory support, supported x87 math coprocessors, and introduced support for the Lotus International Character Set (LICS). Introduced in September 1985." What you don't get is that Lotus 123 2.0's x87 support was in the marketplace from September 1985 with large existing install base and PC hardware sales rivaling C64's unit annual sales, while mainstream 68K competition is largely missing in action or starting ground zero or sales stalling, despite your "68k + 68881 is WAY EASIER to develop for" argument. The fight among the 68K platforms is reaching the number 2 business desktop computer platform position.

Again, you're not able to understand that the install base was totally irrelevant for the new machines, like the Amiga, which quickly received support from the software houses with software of any kind.

As I've already said several times, Amiga was the machine that opened the doors for professional software (especially, but not only, for video and 3D).
Quote:

[...]

Usual Hammer's PADDING which this time I've preferred to remove, because it was a very long WoT that brought nothing to the discussion.
Quote:

You missed the big picture on the platform's general situation.

I've to say that you missed the history of the platforms which were alternative to the PCs. Especially about the Amiga, which was milestone for a lot of professional software.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: It's incredible: you miss no opportunity to show your ignorance. https://theamigamuseum.com/amiga-kickstart-workbench-os/kickstart/kickstart-1-2/ Kickstart 1.2 first appeared in October 1986 [...] this was the first version of Kickstart that not only came on a floppy disk for the (newly renamed) Amiga 1000 https://theamigamuseum.com/wp-content/uploads/2016/10/A1000-Kickstart-v1.2-rev-33.166.txt Kickstart 1.2 (33.166) for Amiga 1000 Size: 256 kB Year: 1986 Checksum: OK (F989BAC3) Resident modules: 23 https://wandel.ca/homepage/execdis/exec_disassembly.txt The following is a complete disassembly of the Amiga 1.2 "exec", as found on a kickstart disk for an Amiga 1000. WHEN you will SERIOUSLY STUDY something in your life? That's useless when A1000's unit sales are pretty pathetic.

LOL (plus Red Herring).

Which OTHER Amiga machines were available on 1986?!?

And guess what: you try to change the context moving it to the install base... --> Red Herring.

"You can't handle the truth!" (cit.).
Quote:

Are you claiming Kickstart 1.2 was publicly available in 1986?

Of course! Have you at least OPENED the links that I've shared?

Kickstart 1.2 arrived for the Amiga 1000 first!

Which, BTW, was WAY EASIER for its development (well, it's the only available machine!), since you didn't have to burn EPROMs and trying them to non-existing machines...

Again, you don't know what you were talking about!
Quote:

Quote: From Commodore - The Final Years Easter Egg In early 1987, the Amiga software team was nearing completion of AmigaOS 1.2. The new system, which would be released along with the A500 and A2000 computers, was a much more complete operating system compared to the previous two releases. But it also contained a nefarious message. According to RJ Mical, “In the end, we were feeling that we had done this beautiful work of art, and then Commodore, for their lack of experience or their lack of knowledge about the computer industry, let us down.� When working on Workbench 1.2, an Amiga engineer inserted a message expressing his feelings towards Commodore. “This happened when I was director of the whole effort,� explains Mical. “One day, one of the guys showed me with great delight what they had put in there. It was this thing where you had to press a certain number of keys on the keyboard and it would bring up this message that said, ‘We made the Amiga, they fucked it up.’ I saw that and I made a sort of nervous chuckle.� Mical knew the parting shot at Commodore could not remain. “I said, ‘This is cute but we can’t really put this in the machine. That’s just not acceptable.’ They said, ‘Aw, come on!’ I said, ‘No way, man. We’re just not putting this in the machine. You’ve got to take it out.’� Mical double-checked before signing off on the code. “The final release of the OS was done, and with great fear I did the keystrokes to make sure that it wasn't there,� he recalls. “When you put in that keystroke, a line of text came up, but it said, ‘The Amiga, born a champion.’� Unknown to Mical, the offending text remained. “They didn't take it out,� he says. “All they did was bury it one level deeper and encrypt it.� Now it remained to be seen if anyone would discover the secret. With the Amiga team’s impending departure, Commodore engineers now had to take full responsibility for any further AmigaOS development. This was difficult but not futile because many of Commodore’s programmers had already been developing parts of the AmigaOS; generally low-level support modules such as printer drivers. The team included former VIC Commandos such as Andy Finkel and Eric Cotton, as well as other programmers like Benny Prudin and Judy Braddock. They had gone from learning C-language to mastering the AmigaOS library. From your link https://theamigamuseum.com/amiga-kickstart-workbench-os/kickstart/kickstart-1-2/ but due to frustrations with Commodore within the Amiga team, an Easter Egg was hidden in Kickstart 1.2 that was, well, not complimentary to Commodore. Commodore management found out about it and stopped rollout of machines with the new Kickstart while they removed the offending message and changed it. Unfortunately, this meant that the new Amiga 500 was unavailable to most of those who wanted it for Christmas 1987. Production delays due to anger against Commodore's management. But that was for the Amiga 500/2000 machines, because the Kickstart image was on ROMS! So it wasn't possible to update their content once the machines were delivered. Quote: [quote] It's incredible: you miss no opportunity to show your ignorance. Look in the mirror,

No, you've to look at the Amiga HISTORY, which you completely missed! IGNORANT!

There are TWO Kickstart 1.2 versions: the one developed with and for the Amiga 1000, and THEN the one which was developed for the Amiga 500/2000.

And they are DIFFERENT! As it can be easily verified by checking that their content.
Amiga 1000: https://theamigamuseum.com/wp-content/uploads/2016/10/A1000-Kickstart-v1.2-rev-33.166.txt

Kickstart 1.2 (33.166) for Amiga 1000
Size: 256 kB
Year: 1986
Checksum: OK (F989BAC3)
Resident modules: 23

Kickstart 1.2 (33.180) for Amiga 500/1000/2000
Size: 256 kB
Year: 1986
Checksum: OK (56F2E2A6)
Resident modules: 23

@Lou

Quote:

Lou wrote: My CD32 with SX-1 w/8MB fastram running OS3.1 became a turd when I turned on 256 color Workbench. The 65C02-powered Commander X16 runs circles around it with better graphics and sound. AGA was a turd. The C65 had AGA capability in 1990. When I worked at Motorla's ISG division in the late 90's...I saw the 68LC060's going into cable-modems. (yes years before they were mainstream...) I managed to snag a spare one and sell it on ebay. Fast-forward to the 2000's and it's the 6502 powering Motorola set-top boxes...go figure! Renesas Electronics who produced the SuperH for Hitachi - they also make water-heater controllers... Guess what cpus are in those? It's Renesas' 6502 variant. If 68K is so cool...and you know you can't do anything without 16 or 32 bits...then why isn't it still alive? Instead of moving on let's just: ARM won. Port to ARM and just emulate the old turd. Move on! Meanwhile, let's wait 136 cycles for that super-cool DIVU command to finish. ARM UDIV executes in 12 cycles. Tell me again how great 68k is ... I'm listening...

The poor blind fanatical is back ranting in his parallel universe.

@bhabbott

I know it's going off on a tangent ...

Quote:

Microchip makes a particularly crappy 8-bit MCU called PIC. Its claim to fame is being the first to feature reprogrammable Flash ROM. Microchip promoted it to hobbyists, as a result of which it became very popular. The PIC's architecture sucked, but this didn't stop it from being widely adopted.

Well, yes. But that was a small part of it.
I worked in a company that used PIC18s for some of their products. And having been present at meetings with Microchip representants, they offered another great advantage. For sales of about 10k p.a. or more, they offered you a variant with the exact combination of peripherals the customer wanted, and for a very reasonable price. An offer that opened the door to many large-scale appliance manufacturers (mine was in the lighting business). Which explains the huge variety of PIC variants, by the way. Very few of those PICs are for their initial customer only, they sell them to the open market as well. But those commercial customers are the reason you find that elaborate and expensive read-out and reverse engineering protection in many of their parts.
The instruction set, toolchain and performance you got were crappy, but acceptable for most customers. BOM costs always trumped development and maintainance costs.

Had Commodore been a bit more open to customers - like Microchip - the story might have anded differently. But it is what it is...

@codis

Quote:

codis wrote: I worked in a company that used PIC18s for some of their products.

PIC18 was better than PIC12 and PIC16, but they came and later were more expensive so I didn't get into them.

Quote:

And having been present at meetings with Microchip representants, they offered another great advantage. For sales of about 10k p.a. or more, they offered you a variant with the exact combination of peripherals the customer wanted, and for a very reasonable price.

Later PICs had more and more of those peripherals built in 'off the shelf'. Compared to some other manufacturers Microchip's peripherals were easier to understand and get working. They kept the hardware the same in different MCUs, so once you had the code sussed out it was easy to migrate to a different chip. The documentation was pretty good too. That was one of the PIC's strengths. The CPU wasn't the fastest but with good peripherals it didn't have to be - a bit like the Amiga 500!

ST had powerful ARM chips with lots of great looking peripherals, but many were full of bugs which they tried to hide via a software layer. Developers had just gotten used to that when ST changed to a different framework. Experienced developers threw away the frameworks and hit the hardware directly, which was a very steep learning curve due to confusing documentation and numerous bugs.

Quote:

The instruction set, toolchain and performance you got were crappy, but acceptable for most customers. BOM costs always trumped development and maintainance costs.

I thought the toolchain was pretty good actually, until they decided to develop a Java version so it could run in Linux. My PC wasn't powerful enough to run it at a reasonable speed, so I stuck to the earlier version. Atmel did something similar and again I stuck to the older toolchain - only in their case it was worse because the debugger wasn't compatible with code generated by later compilers. Now Microchip owns Atmel... I wonder why?

Quote:

Had Commodore been a bit more open to customers - like Microchip - the story might have anded differently. But it is what it is...

Commodore was open to customers. Anyone could buy the RKMs or any of the numerous 3rd party books on programming the Amiga. Anyone could register as a developer for $25 to get advance information and support. Commodore worked closely with smaller developers too, not just those making 10k+ sales.

The only thing they weren't open about was products in development. Many of those projects were in a state of flux so getting advance information wouldn't have helped much. Take AGA for example. Commodore didn't release detailed hardware specs because even the engineers themselves weren't sure what the final form would be. However they did give out enough information for hackers to quickly figure it out once AGA machines were released.

@matthey

Quote:

matthey wrote: cdimauro Quote: Reusing existing/used opcodes for something else is CRIMINAL. Unfortunately, that's what Gunner does (see the CALLM instruction as another example). Specifically, he used LINE-A for such instructions which ColdFire has smartly placed on a different lane. LINE-A could have much better being used for a SIMD/Vector extension! No words... ColdFire MVS, MVZ, BYTEREV, BITREV and SATS do not use line-A and are open encodings on the 68k but MOV3Q does use line-A. MOV3Q %1010 imm 101 EA

Another DUMB idea from Motorola, which had missed no opportunity to show how it doesn't care, at all, about backward-compatibility.
Quote:

Gunnar and I discussed ColdFire support long ago. I came up with the idea to use "OP.L #d16,EA" instead of using MOV3Q. MOV3Q saves 4 bytes per instruction where it can be used but immediates are limited to -1 and 1-7. My idea only saves 2 bytes but immediates can be -32768 to +32767 and it can be used for more than MOVE.L #d16,EA but also OP.L #d16,Dn instructions.

Indeed. That's a much better solution. AND backward-compatible.
Quote:

Maybe I should have patented that idea

It was worth, yes.

As I've said another time, I've developed something similar for NEx64T, which could be applied to 68k as well, but I keep it for me until I'll file a patent. CPU vendors are continuously filing patents and taking profits from them, even for much less important features, and I don't see why I've to give my ideas for free.
No Mike Clark:
"And of course we would also like to get feedback from you guys - “if we just had this instruction or this concept, we could really leverage that in our software� and so on. We're constantly open to that, too."
I'll NOT approach you.
Quote:

but Gunnar did not use it even though he created OPW.L #d16,Dn instructions for some forms in a non-orthogonal way.

Yes, I've seen it. Another dumb idea...
Quote:

Anyway, my suggestion was not to use line-A for MOV3Q and it sounded like he was in agreement along with supporting MVS and MVZ which he changed his mind on completely multiple times it seems. Moving MVS and MVZ to line-A moves them with MOV3Q which is likely the logic and he added a SR bit to toggle them on and off for compatibility. Quote: http://www.apollo-core.com/documentation/AC68080PRM.pdf [quote] Apollo bit. Multitask & additional line-a instructions. ApolloOS always saves the new registers on task switching. A program that sets SR bit 11 keeps e-registers intact when switching task on an rom patched OS like amiga or coffin. The 080 allows it to be set in user-mode. Other bits will of course give a privilege exception as expected. LineA-instructions become valid when the apollo-bit in SR is set. LineA $a000..$a00f will not be used to be atari-os compatible. “LineA� instructions are: clr.q , mov3q , moviw.l , mov(s/z) Ori #$800,sr sets the apollo-bit. Andi #$f7ff,sr clears the apollo-bit. The apollo-bit affects only the program that sets it. Setting it and expecting another program to behave if the apollo-bit is set does not work. So restoring the bit on exit is not needed.

Indeed. It's his usual attitude: apply quick and dirty patches to achieve his limited goal, without thinking at the consequences...
Quote:

I would rather keep MVS and MVZ where ColdFire has them and move MOV3Q if wanting to keep it. MOV3Q does provide better code density with my idea but my initial conclusion was that it was not worthwhile to find a new encoding.

Absolutely! That should have been the way to go!!!
Quote:

cdimauro Quote: Indeed. Nice effort, but nothing really new, "game changer". I also find it weak on some critical areas: constants limited to only a few instructions. Loads/stores only with 4-bit unsigned immediate. And only zero-extended byte/half-word loads/stores. So, I strongly doubt that it can reach very good code density. And it's more suitable for embedded: not so much general-purpose, with a crippled future for extensions. I agree that MCore is another weak minimalist MCU ISA with mediocre code density and likely poor performance metrics. Maybe Motorola should have negotiated a license for SuperH from Hitachi rather than suing them for innovating 68k like designs. SuperH borrows from the 68k and is more acceptable to 68k fans even though they seriously should have made it a 16-bit/32-bit variable length encoding like Thumb-2.

Even SuperH wasn't good with its fixed 16-bit opcode. J-Core added 32-bit opcodes, if I recall correctly, but not like Thumb-2. So, they can't get a good code density as well.

ARM did a GREAT work with Thumb first, and Thumb-2 after, because this new architecture has very carefully designed the 16-bit opcode space (leaving the 32-bit one for all ARM32 instructions, but suppressing the 4 bits for the predicated instructions, when Thumb-2 was introduced).

Code density is HEAVILY influenced by the number of 16-bit opcodes which are used/generated, but not only for that: they should be USEFUL instructions as well, which REDUCE as much as possible the number instructions which are generated / executed.

For this reason and to evaluate how a good work was made for an architecture about this topic, I think that it's also important to consider to how many 16-bit instructions were generated compared to how much opcode space is used for 16-bit opcodes.
So, this ratio, basically: % of 16-bit instructions / % of 16-bit opcodes in the ISA. The greater the value, the better is the architecture: its architects have well designed it (e.g.: they made a good use of the available opcode space).

To give an example, if 40 % of the generated instructions are 16-bit, and the ISA has reserved 30% of its opcode space for 16-bit opcodes, then 40 / 30 = 1.33 -> they made a good work.
Viceversa, if 30% of generated instructions is 16-bit and the opcode space for 16-bit instructions is 40%, then 30 / 40 = 0.75 -> not so good work.

Just an idea (which obviously only applies to architectures with variable-length encodings).
Quote:

Also, Motorola did not need a lower end ISA than ColdFire. ColdFire could have been lower power but it retained much of the 68k good performance, performance efficiency and power efficiency when scaled down so far. The grass in always greener on the other side of the fence though.

Indeed. Motorola didn't need such castration or to invent anything new: they already had the best architecture (at the time).
Quote:

cdimauro Quote: Yes, it was and still is a very nice architecture. It's a pity that it was killed. But it's missing two important things: a 64-bit extension and a SIMD/vector unit. The AC68080 has 64-bit support and a SIMD unit.

64-bit support, but it's not a 64-bit ISA, since it's lacking a 64-bit execution model.

The SIMD unit is there, but it's poor and very badly designed.

A 68k successor deserve much, much better.
Quote:

It may not be the ultimate 68k ISA but it is the ultimate FPGA only 68k ISA.

There are other FPGA projects. Unfortunately, far from 68080 performance.
Quote:

cdimauro Quote: Those weren't rumours: I've written an article about that, some years ago. Apple was switching to Intel at the very beginning of 2000s. The switch was just delayed because IBM promised the G5 to Jobs. But it was a delay, as we know (G5 flopped). The people behind PPC AmigaOS 4 were zealots, propagandists and con men with minimal technical knowledge. AmigaOS 4 could have maintained 68k compatibility and been prepared for ports to other architectures. Instead, AmigaOS 4 is still stuck on PPC 20 years after it died on the desktop and 15 years after PPC died for embedded use.

In fact, AmigaOS4 was effected by very bad decisions, from a technical perspective. Along all its life and all machines which were produced.

An horrible job which is perfectly in-line with what was made by Commodore engineers after that the original way left the company...
Quote:

The 68k AmigaOS is the only profitable AmigaOS remaining and that only because Hyperion does not pay their developers.

Quote:

cdimauro Quote: Commodore is another great example... And A-Eon. Trevor still loves his PPC, even the antiquated embedded PPC crap. He is King of the zealots, propagandists and con men.

The Amiga Documents reports very bad stories about Hyperion, Trevor, and all "OS4 parties".

Amiga is the land of missed opportunities, and we've to "thank" them for the last missed chance...

@matthey & bhabbott: you're trying to explain technical things to a guy which is a complete ignorant and which invents stories only to bash the architectures / projects which he hates, to defend his beloved 65xx and the machines that used such crappy architectures.

In short: he only write non-sense, moved by pure envy and hatred.

@codis

Quote:

codis wrote: @bhabbott I know it's going off on a tangent ... Quote: Microchip makes a particularly crappy 8-bit MCU called PIC. Its claim to fame is being the first to feature reprogrammable Flash ROM. Microchip promoted it to hobbyists, as a result of which it became very popular. The PIC's architecture sucked, but this didn't stop it from being widely adopted. Well, yes. But that was a small part of it. I worked in a company that used PIC18s for some of their products. And having been present at meetings with Microchip representants, they offered another great advantage. For sales of about 10k p.a. or more, they offered you a variant with the exact combination of peripherals the customer wanted, and for a very reasonable price. An offer that opened the door to many large-scale appliance manufacturers (mine was in the lighting business). Which explains the huge variety of PIC variants, by the way. Very few of those PICs are for their initial customer only, they sell them to the open market as well. But those commercial customers are the reason you find that elaborate and expensive read-out and reverse engineering protection in many of their parts. The instruction set, toolchain and performance you got were crappy, but acceptable for most customers. BOM costs always trumped development and maintainance costs. Had Commodore been a bit more open to customers - like Microchip - the story might have anded differently. But it is what it is...

Indeed. Microchip is a clear example of what's possible to achieve if the company has good plans / management and products with a good value.

PICs gained a very good slice of the embedded market because Microchip offered very-low cost products, with a very good customer support, which included customized chips according to their need.

The PIC is a pure crap as an architecture (I've even developed an high-level assembler with a completely new syntax, when I worked with those processors, because I've hated the official assembly language), but it made absolutely sense when you wanted to spend a bunch of cents and develop thousand or million of pieces.

Another very fresh example is AX-E0, a project from a new Italian company which developed a super low-power SoC (with a new architecture called Leonardo. But unfortunately there's no information about it):
AX-E0, il chip Made in Italy di Arox, consuma 10 volte meno degli altri
The article is Italian, but can be easily translated in any language.

In short: good ideas can still find ways on the market, to take some slice.

@cdimauro

Quote:

Which OTHER Amiga machines were available on 1986?!? And guess what: you try to change the context moving it to the install base... --> Red Herring.

Not a red herring. A2024 has 5000 production scale for Amiga OCS, which is a meaningless tokenium.

Quote:

And they are DIFFERENT! As it can be easily verified by checking that their content. Amiga 1000: https://theamigamuseum.com/wp-content/uploads/2016/10/A1000-Kickstart-v1.2-rev-33.166.txt Kickstart 1.2 (33.166) for Amiga 1000 Size: 256 kB Year: 1986 Checksum: OK (F989BAC3) Resident modules: 23

You have damaged your "easier" argument when you cited that 68020/68881 supported 3D software was released in 1988.

On January 1989, Sculpt 3D was released on the Macintosh platform with higher resolution support.

Last edited by Hammer on 04-Apr-2025 at 08:26 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@cdimauro


Quote:

AX-E0, il chip Made in Italy di Arox, consuma 10 volte meno degli altri The article is Italian, but can be easily translated in any language. ...

My search engine came up with that (in English): https://www.arox.com/ax-e0
Interesting, although I have far too many microcontroller boards already. But I will watch it for sure.

But from the scarce information the site reveals (e.g. 32 interrupts at 4 levels), it doesn't sound like ARM. My bet would be RISC-V - why inventing the ISA wheel anew, into an already overabundance of architectures, when decent toolchains already exist ?
I suppose there are some parallels to what EnergyMicro did with ARM.

As a side note, I had been an Amiga user from '91 to about '98 (A2000 and A4000/EC020), and enjoyed the time. I liked the 68000 architecture, not only because is shedded compatibility with paleolithic predecessors like the main competitor.
I even wrote my diploma thesis on the Amiga, with FinalWriter.
But I will avoid to join the fray this thread now mostly is ...

@cdimauro

Quote:

Which OTHER Amiga machines were available on 1986?!? And guess what: you try to change the context moving it to the install base... --> Red Herring.

https://www.gregdonner.org/workbench/wb_12.html
Added: "V1.2" version number added to the Kickstart screen (as of v33.180).

Try IGNORANT TURD.

And guess what: Workbench 1.2 came with the Amiga 1000 from September 1986 onwards, accompanied by Kickstart 1.2 on disk.

Kickstart 1.2 doesn't autoboot with a hard disk. 1986 PCs can boot from their hard disk.


Kickstart 1.2 (v33.180) did not have autoboot capability. Although it contained AutoConfigTM code, it was broken due to a simple bug: the AutoConfigTM init code jsr had a wrong a6 register (the base register at the jsr time should be expansionbase but is execbase instead). Robert Miranda adds that: "Hardware AutoConfig was functional (related to Note 3). The loading of the I/O PIC's ROM driver was what was broken in expansion.library (the register issue). Hard disks (among others) needed to therefore use a Binddrivers-loaded driver from SYS:Expansion off a floppy boot, and then transfer the system assigns to the (now) loaded hard disk interface/environment. (Side Ref: That's the purpose of the FastPrep Kickstart 1.2 boot floppy option, and also the original GVP Impact boot floppy v1.0 (scripted) setup routine.) I recall that it was (later) reported as internally fixed at Commodore, but they never released it to a ROM (or maybe was the 1.2.1 Kickstart?). It later made it into official Kickstart 1.3 release."

Version 33.56 was the first AmigaDOS release to support a battery backed-up clock via the Date command.


Apple's January 16, 1986 released Macintosh Plus can boot from its SCSI hard disk.

https://archive.org/details/amiga-world-1986-09/page/n111/mode/2up
Amiga World Magazine, September 1986 issue, no advert for Workbench/Kickstart 1.2.

Commodore wasn't serious enough for the native Amiga's business market targets.

For Commodore Germany's early A2000 model, the 1986 released A2088XT bridgeboard + PC ISA hard disk controller in the second ISA slot can boot its hard disk. The focus wasn't fully on the Amiga.

Quote:

No, only Commodore engineers of the Amiga team: your great heroes you continuously defend! They are the only responsible for that.

That's a FALSE narrative.

From Commodore - The Final Years,

Porter specifically wanted 1000 by 800 resolution with 8 bit planes
and 16 million colors—something to exceed the current competition.
Of importance would be keeping the new video technology
compatible with existing commercial Amiga software.
All of these plans would be discussed at Commodore’s worldwide
engineering meeting, scheduled for September 22, 1987 at the
Embassy Suites hotel in New York. The meeting was called by Henri
Rubin, and those invited included the main West Chester engineers,
along with engineers from Germany and Japan.


Jeff Porter's argument before the September 1987 meeting is closer to AGA's 8 bitplanes with
16 million colors palette. Henri Rubin is out of his depth.

From Commodore - The Final Years,

Goodbye Henri

Henri Rubin had been brought to Commodore in order to enter the
business market. His central plan had been to use the Bridgeboard
as a way to sneak Amiga computers into the business world by
claiming MS-DOS compatibility. “The stuff that came from
management was all really bizarre and most of it didn't really
happen,� says Bryce Nesbitt.

Rubin also banked on “Productivity Mode� in the new Amiga 3000
as a way to stay current with the VGA capabilities of PC clones.

-------------
Herni Rubin is part of Commodore's upper management. That's "read my lips, no new chips."

PC focus is from Herni Rubin.

Banking on the ECS mistake will be repeated by Jeff Frank and Bill Sydnes with ECS-based A300/A600 and A2200/A2200/A3200/A3400 projects.

Apple didn't have Herni Rubin.

Try again IGNORANT TURD.

Last edited by Hammer on 04-Apr-2025 at 11:45 AM.
Last edited by Hammer on 04-Apr-2025 at 11:43 AM.
Last edited by Hammer on 04-Apr-2025 at 11:35 AM.
Last edited by Hammer on 04-Apr-2025 at 11:31 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@codis

Quote:

codis wrote: @cdimauro Quote: AX-E0, il chip Made in Italy di Arox, consuma 10 volte meno degli altri The article is Italian, but can be easily translated in any language. ... My search engine came up with that (in English): https://www.arox.com/ax-e0 Interesting, although I have far too many microcontroller boards already. But I will watch it for sure. But from the scarce information the site reveals (e.g. 32 interrupts at 4 levels), it doesn't sound like ARM. My bet would be RISC-V - why inventing the ISA wheel anew, into an already overabundance of architectures, when decent toolchains already exist ? I suppose there are some parallels to what EnergyMicro did with ARM.

I don't know if it's based RISC-V. On the above site they continuously compare it with OTHER architectures, making a distance.

Architecture usually means ISA, but in different contexts it's also used for microarchitecture (SIGH!).

So, it's not that clear. However, and since I'm very curious, I've registered on their site for getting a copy of developers manuals. Let's see.
Quote:

As a side note, I had been an Amiga user from '91 to about '98 (A2000 and A4000/EC020), and enjoyed the time. I liked the 68000 architecture, not only because is shedded compatibility with paleolithic predecessors like the main competitor. I even wrote my diploma thesis on the Amiga, with FinalWriter.

You were a bit late, but better enjoyed our beloved platform.

I got my diploma on 1990, but honestly I don't recall which Amiga program I've used for writing the two thesis (one technical -> controlling a robot with 6-axis of freedom. One literary -> Industrial Revolution).

I had an A2000 on 1987 and an A1200 on 1992. Both unexpanded, unfortunately.
Quote:

But I will avoid to join the fray this thread now mostly is ...

You can just skip some posts and enjoy the others which carry nice and interesting information.

If I'm still here it's because I can learn something from a few skilled guys.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Which OTHER Amiga machines were available on 1986?!? And guess what: you try to change the context moving it to the install base... --> Red Herring. Not a red herring. A2024 has 5000 production scale for Amiga OCS, which is a meaningless tokenium.

Another red herring...
Quote:

Quote: And they are DIFFERENT! As it can be easily verified by checking that their content. Amiga 1000: https://theamigamuseum.com/wp-content/uploads/2016/10/A1000-Kickstart-v1.2-rev-33.166.txt Kickstart 1.2 (33.166) for Amiga 1000 Size: 256 kB Year: 1986 Checksum: OK (F989BAC3) Resident modules: 23 You have damaged your "easier" argument when you cited that 68020/68881 supported 3D software was released in 1988.

Oh, and wasn't that true? When do you plan to read AND understand what the people are writing (see on the previous comment the proof that I've brough).
Quote:

On January 1989, Sculpt 3D was released on the Macintosh platform with higher resolution support.

Irrelevant + Red Herring.

As usual, with you: hopeless...
Quote:

Hammer wrote: @cdimauro Quote: Which OTHER Amiga machines were available on 1986?!? And guess what: you try to change the context moving it to the install base... --> Red Herring. https://www.gregdonner.org/workbench/wb_12.html Added: "V1.2" version number added to the Kickstart screen (as of v33.180).

That was the release for the Amiga 500 and 2000, whereas the context was about the Amiga 1000.

Do you understand that there were TWO different Kickstart 1.2, one for the A1000 and one for the A500/2000?

Clearly no, because bots do NOT understand.
Quote:

Try IGNORANT TURD.

LOL Other free, personal offences because the bot didn't understand the discussion, continue to derail, and was upset due to critics.
Quote:

And guess what: Workbench 1.2 came with the Amiga 1000 from September 1986 onwards, accompanied by Kickstart 1.2 on disk.

Thanks for confirming it, BOT!
Quote:

Kickstart 1.2 doesn't autoboot with a hard disk.

Irrelevant, BOT!
Quote:

1986 PCs can boot from their hard disk.

PADDING + Red Herring, BOT!
Quote:

Kickstart 1.2 (v33.180) did not have autoboot capability. Although it contained AutoConfigTM code, it was broken due to a simple bug: the AutoConfigTM init code jsr had a wrong a6 register (the base register at the jsr time should be expansionbase but is execbase instead). Robert Miranda adds that: "Hardware AutoConfig was functional (related to Note 3). The loading of the I/O PIC's ROM driver was what was broken in expansion.library (the register issue). Hard disks (among others) needed to therefore use a Binddrivers-loaded driver from SYS:Expansion off a floppy boot, and then transfer the system assigns to the (now) loaded hard disk interface/environment. (Side Ref: That's the purpose of the FastPrep Kickstart 1.2 boot floppy option, and also the original GVP Impact boot floppy v1.0 (scripted) setup routine.) I recall that it was (later) reported as internally fixed at Commodore, but they never released it to a ROM (or maybe was the 1.2.1 Kickstart?). It later made it into official Kickstart 1.3 release." Version 33.56 was the first AmigaDOS release to support a battery backed-up clock via the Date command.

Irrelevant, BOT!
Quote:

Apple's January 16, 1986 released Macintosh Plus can boot from its SCSI hard disk.

Totally irrelevant, BOT!
Quote:

https://archive.org/details/amiga-world-1986-09/page/n111/mode/2up Amiga World Magazine, September 1986 issue, no advert for Workbench/Kickstart 1.2.

And?
Quote:

Commodore wasn't serious enough for the native Amiga's business market targets.

Sure. CBM -> Commodore BUSINESS Machines...

And it wasn't so serious with the business market, that it has NOT released this:
https://bigbookofamigahardware.com/bboah/product.aspx?id=327



right?
Quote:

For Commodore Germany's early A2000 model, the 1986 released A2088XT bridgeboard + PC ISA hard disk controller in the second ISA slot can boot its hard disk. The focus wasn't fully on the Amiga.

Guess what: the company was doing OTHER businesses, and Amiga was ONE of them.

Messier de La Palice.
Quote:

Quote: No, only Commodore engineers of the Amiga team: your great heroes you continuously defend! They are the only responsible for that. That's a FALSE narrative. From Commodore - The Final Years, Porter specifically wanted 1000 by 800 resolution with 8 bit planes and 16 million colors—something to exceed the current competition. Of importance would be keeping the new video technology compatible with existing commercial Amiga software. All of these plans would be discussed at Commodore’s worldwide engineering meeting, scheduled for September 22, 1987 at the Embassy Suites hotel in New York. The meeting was called by Henri Rubin, and those invited included the main West Chester engineers, along with engineers from Germany and Japan. Jeff Porter's argument before the September 1987 meeting is closer to AGA's 8 bitplanes with 16 million colors palette.

That was the BEGINNING of the PAPER WORK which I've mentioned.
Quote:

Henri Rubin is out of his depth.

Really? Then why Rubin promoted this paper work, as per the above writing that you've reported?

The meeting was called by Henri Rubin
Quote:

From Commodore - The Final Years, Goodbye Henri Henri Rubin had been brought to Commodore in order to enter the business market. His central plan had been to use the Bridgeboard as a way to sneak Amiga computers into the business world by claiming MS-DOS compatibility. “The stuff that came from management was all really bizarre and most of it didn't really happen,� says Bryce Nesbitt. Rubin also banked on “Productivity Mode� in the new Amiga 3000 as a way to stay current with the VGA capabilities of PC clones. -------------

So, it was Commodore's management which hired Rubin for improving the DOS compatibility. Which he did, right?
Quote:

Herni Rubin is part of Commodore's upper management.

AFTER that he was hired: see above.
Quote:

That's "read my lips, no new chips."

Please, tell me more about the C65: who from Commodore's upper management asked to start this project? Rubin? Ali? Gould?
Quote:

PC focus is from Herni Rubin.

Which was the reason why it was hired -> perfectly coherent with his mandate...
Quote:

Banking on the ECS mistake will be repeated by Jeff Frank and Bill Sydnes with ECS-based A300/A600 and A2200/A2200/A3200/A3400 projects.

Irrelevant. The context was the Amiga 1000 time and after that the missed opportunity to improve the chipset after that, because the Amiga engineers were so incompetent that they weren't able to add TWO miserable bitplanes to the chipset which ALREADY HAD SPACE FOR THEM!
Something that any Amiga "hardware bashing" developer knows, but NOT you because you've never opened the Amiga Hardware Manual in your life, hopeless BOT!

Whereas the LSI team in more or less the same time of the above PAPER WORK has produced a prototype of the C65 chipset which added COMPLETELY ALIEN TECNOLOGY (8 bitplanes, 256 colours from a 4096 palette) to the VIC-II (which you've no idea on how it worked, of course), which shocked the above incompetente team.

Those are the FACTs and the CONTEXT of this part of the discussion, BOT!
Quote:

Apple didn't have Herni Rubin.

Right, and it was about to go bankrupt and was saved by... rolling drum... Microsoft / Bill Gates.
Quote:

Try again IGNORANT TURD.

Again free, personal offences from a BOT which is unable to understand the context of discussion.

Evidently you aren't able to do anything else, and that's the only way that you've found for miserably trying to satisfy your violated ago.

Poor BOT:

@cdimauro


Quote:

Architecture usually means ISA, but in different contexts it's also used for microarchitecture (SIGH!).

Not that I'm an expert in this field.
But AFAIK, Risc-V is relatively open, much less restrictive than ARM licences. It would make sense, I would say. Having been employed in the "low power / low budget" niche of the embedded market, I came across a lot of proprietary architectures and ISAs that are obsolete today. Maintaining such stuff is a nightmare. Just saying ...
Quote:

You were a bit late, but better enjoyed our beloved platform.

But for good reasons. Growing up on the other side of the fence, Amigas were not accessible until early 1990, like a lot of other stuff. OTOH, I stuck with Amiga up until about 2000, when I bought my first x86 PC. And it took me less than a year to begin experimenting with Linux.
The diploma thesis topic is still fresh on my mind, especially how my mentor looked down on me, suggesting he will borrow me a PC. Needless to say, M$-Word had it's reputation even back then. The FinalWriter worked quite flawless. It took me about 6 weeks to get it finished, with about 120 pages and 20% diagrams. I only experienced one minor crash. And in difference to equally or more expensive PC text processing packages, FW could import EPS graphics, e.g. from Gnuplot. A huge plus for me.

While I had a few games, this part was less significant for me. Work and hobby coding projects more so.

Quote:

You can just skip some posts and enjoy the others which carry nice and interesting information. If I'm still here it's because I can learn something from a few skilled guys.

Exactly ...