@bhabbott

Quote:

The A1000 wasn't a Mac? Oh no, it's doomed!

A1000 wasn't a Mac, but it can fake a Mac via the AMax solution.

AMax with OCS shows a lack of stable high business resolution mode, hence ECS is a must in 1988.

Demo'ing ECS productive mode in Q4 1988 is a useless tokenism. A ROM switcher is not hard.

1988-era A500 rev5 and 1987-era A500 rev3 would require bodge wires for 512 KB ROM.

1989 era A500 rev 6A is ECS-ready without the need for bodge wires. Commodore management decided the ECS/AmigaOS 2.x to be timed exclusive for A3000's 1990 release.

The market didn't wait for ECS's 1990 release.


Quote:

The Mac was introduced in January 1984. It had a 68000 CPU running at an effective 6MHz, 128k of RAM which was not expandable, a single display resolution of 512x342 with 1 bitplane that only worked with the built-in built in 9 inch monochrome CRT, single PCM sound channel, and a 400k 3.5" floppy drive - for a retail price of US$2,495.

On September 10, 1984, the Mac 512K was released. Mac 512K's release is the Mac configuration that mattered for business software vendors like Microsoft and Aldus.

Mac's GUI version for MS Excel, MS Word, and Page Maker was released in 1985. This is an important factor for the Mac platform i.e. the killer GUI apps for the GUI platform.

Apple started color Mac R&D in 1985.

Unlike Commodore, Apple wasn't frozen in time.

Staring at A1000's beauty is not productive.

Quote:

@bhabbott By the and of 1987 the Mac had been on the market for 4 years, while the Amiga had only been out for a little over 2 years - with the more popular 'consumer' A500 model priced at US$699 only being out for 3 months.

Mac had a major sales ramp when major business software releases in 1985 and 1986 gained traction.

https://pegasus3d.com/total_share.html
All figures in 1,000's of units

Mac,
1984: 372, Postscript was released in 1984.
1985: 200, Flopped with decline, Steve Jobs' Apple invested in Adobe, and a PostScript controller was created.
1986: 380, Returns to growth. Mac 512K and Mac's business software releases are gaining traction. Aldus Pagemaker 1.2 "killer app" was released with PostScript font support. 952K install base.
1987: 550, QuarkXPress "killer app" was released. Color Mac release. MS Word 2.0 and MS Excel 2.0 for Mac were released.
1988: 990,
1989: 1100,
1990: 1300,
1991: 2100,
1992: 2500,

After 3 years = 952K install base reached
After 4 years = 1,602K install base reached.
After 5 years = 2,495K install base reached.

Amiga,
1985: 100, A1000 was released.
1986: 200,
1987: 300, A500 and A2000-CR released. Install base at 600K.
1988: 400,
1989: 600, A500 game bundle starter kits. A500 Rev6 release.
1990: 750,
1991: 1035, starting for A500Plus (Rev 8).
1992, Collapsed. Sales data conflict. Best selling A500 was cancelled in early 1992. Damage to "Amiga 500" nameplate.

After 3 years = 600K install base reached.
After 4 years = 1,000K install base reached.
After 5 years = 1,600K install base reached.

Meanwhile, in 1989, Windows 2.x reached 2 million sales, not including floating pirated Windows 2.x copies. Windows 2.1 and WinWord releases in 1989 led to 1990's Windows 3.0 with MS Office double nukes.

Atari ST,
1985: 50
1986: 200,
1987: 400, The last year for Atari ST beating the Amiga in sales.
1988: 350, with decline,
1989: 300, with decline. STE was released.
1990: 300,
1991: 300,
1992: 150,

After 3 years = 650K install base reached.
After 4 years = 1,000K install base reached.
After 5 years = 1,300K install base reached.




Quote:

@bhabbott, The Amiga 1000 was announced on July 23 1985, but didn't start shipping until September. It had a 68000 CPU running at 7.1MHz, 256k of RAM (expandable to 512k internally, up to 9MB with external expansion), standard resolutions up to 640x200 noninterlaced and 640x400 interlaced in 16 colors or 320x200/400 in 32 colors (more with overscan) - all TV compatible, 4096 color palette, hardware blitting, sprites and 'split-screen' modes, 4 channels of PCM sound with independent programmable sample rates, and an 880k 3.5" floppy drive. It came with built-in NTSC composite output for use with a TV, and analog RGB. With a high resolution RGB color monitor the retail price was US$1,485, US$1000 less than the Mac.

Where's MS Excel GUI and MS Word GUI?

Is staring at the beautiful A1000 productive for the larger back office markets?

Quoting hardware specs is nothing without killer software.

Atari ST game ports on Amiga have dampened Amiga's hardware superiority until exclusive Amiga games started to show Amiga's hardware superiority. This is why successful Japanese game platforms have strong 1st party game studios.

Both 3DO and Amiga releases have weak launch software titles.

Windows 3.0's 1990 release was synced with a strong MS Office release and Wing Commander's release helped as gaming PC's "Defender of the Crown" moment. Wing Commander 1990 demo made a lasting impression on Jeff Porter.

Jeff Frank doesn't give a damn about the Amiga's 2.5D and 3D gaming i.e. buy a Commodore PC instead mentality.

Quote:

@bhabbott, By the and of 1987 the Mac had been on the market for 4 years, while the Amiga had only been out for a little over 2 years - with the more popular 'consumer' A500 model priced at US$699 only being out for 3 months.

Mac
After 3 years = 952K install base reached
After 4 years = 1,602K install base reached.
After 5 years = 2,495K install base reached.

Amiga
After 3 years = 600K install base reached.
After 4 years = 1,000K install base reached.
After 5 years = 1,600K install base reached.

Per year unit sales pacing, Mac's business-centric software relationships for the win.


Quote:

@bhabbott, The Amiga wasn't a Mac and the Mac wasn't an Amiga - they were quite different products targeting different markets. The Mac was a good choice for producing documents for publishing or printing on a laser printer, or for classroom use where the all-in-one design was portable and secure, and that was about it.

MS Word and MS Excel GUI dominance in the Mac platform has aided Microsoft's Windows 2.x development and set a situation to displace the DOS application establishment with 1990's MS Windows 3.0 / MS Office double nukes on IBM, Lotus, and Word Perfect.

You haven't factored in the GUI craftmanship difference between Amiga's Easy Ledge vs Mac's Quicken Quickbooks.


Quote:

@bhabbott, The Amiga was a general purpose 'home' computer with the usual expected uses, including exceptional gaming capabilities and an advanced preemptive multitasking GUI OS that was unique in that market.

Commodore didn't address the business's stable high resolution until too late.

Commodore wasn't serious about GUI craftsmanship until Workbench 2.x and GUI design style guides.

A2024's 5000-unit production scale is just a tokenism for Amiga OCS i.e. good for demos, but not good for mass production. Blame Commodore management's Henri Rubin.

After the ECS productivity mode demo in 1988, Commodore delayed ECS Denise for a timed exclusive A3000's 1990 release. ECS Denise is operational with 1989 era A500 Rev6A's 1 MB ECS Agnus. Delayed 2 MB ECS Agnus is not required for ECS Denise.

Quote:

It was the ultimate 'hobbyist' computer and forerunner in the emerging 'multimedia' sphere. But it wasn't a business computer. Most importantly it wasn't IBM compatible, didn't run MS-DOS and didn't have an x86 CPU, making it unattractive to business users. It was targeting home users who weren't concerned about that, and for its multimedia capabilities - especially the accurate NTSC video with genlocking that would make it a favorite for video production companies and TV studios.

The Macintosh platform says Hi.

Note that Amiga's golden years of 1990 and 1991 were during 1990 PC's Windows 3.0, MS Office, and Wing Commander tripe nukes.

VGA clone's cost reduction and Windows 2.x have addressed the business's stable high-resolution use case in greater numbers when compared to the Amiga platform.

PC's partitioned graphics architecture allowed for asynchronous graphics hardware upgrades from any X86 CPU upgrades. No game console-style hard new generation switchover.

Bill Sydnes and Jeff Frank have damaged the "Amiga 500" sub-brand which is Commodore's "Toyota Corolla" or "BMW 300" series sub-brand equivalents.

Commodore Germany's AA500 with hard disk capability ASAP is the correct call. Think of the Amiga 500 as the BMW 300 series.

For Amiga CAD and DTP software revisit, Amiga 500 Rev6 without ECS Denise wasn't an ideal user experience. I had an A3000 flicker fixer for my CAD and DTP use cases with a PC VGA monitor, but the A3000 production scale is only a few thousand units which is tokenism.

Jack Tramiel's gaming for mass volume low-end and business for low volume high-end product segmentation mindset is evident in Commodore's 1990 era.

The gaming PC breaks Jack Tramiel's gaming for mass volume low-end and business for low volume high-end product segmentation mindset.

Last edited by Hammer on 09-Jan-2025 at 04:52 AM.
Last edited by Hammer on 09-Jan-2025 at 04:49 AM.
Last edited by Hammer on 09-Jan-2025 at 04:46 AM.
Last edited by Hammer on 09-Jan-2025 at 04:38 AM.
Last edited by Hammer on 09-Jan-2025 at 04:36 AM.
Last edited by Hammer on 09-Jan-2025 at 04:26 AM.
Last edited by Hammer on 09-Jan-2025 at 04:21 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

Let's talk about what is really wrong with 68K:

1. Loading address registers doesn't affect condition codes. At the very least it would have been beneficial for it to set the Z flag since all bits zero is an almost universal representation of the null address and it makes it simpler to check before dereferencing.

Anyon got a 2?

_________________
Doing stupid things for fun...

nobody care about affecting condition codes during loading adress registers.
nobody use this.

What is really wrong with 68k is there was no real progress active elements
in Amiga graphics since 1983.
C= and after that 68k camp never ever provide better graphics
as good as fast and as usable as OCS was.
something like blitter updated to 16 bit color

@ppcamiga1

Wrong. If you are loading something into an address register it's almost always because you intend to use it as part of an effective address, i.e. a pointer. Before you do that, you almost always want to make sure the pointer isn't null.

Not setting the Z flag means you can't just rely on checking the condition code after doing a movea to the register. Instead, you need to either explicitly do a tst.l on the operand first or move it to a data register and test the condition before moving from the data register to the address register. All extra steps to detect that the pointer you have is null. It's a bit sucky.

Quote:

C= and after that 68k camp never ever provide better graphics as good as fast and as usable as OCS was. something like blitter updated to 16 bit color

This has nothing whatsoever to do with the 680x0 CPU. But even if we allow the complete irrelevance, people were using 64-bit blitters on chunky 8/16/24 and 32 bit display modes on their 68K Amigas before PPC was even a wet patch in your pants.

Last edited by Karlos on 09-Jan-2025 at 06:38 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Loading address registers doesn't affect condition codes. At the very least it would have been beneficial for it to set the Z flag

True.

2nd

The alignment error on the original 68000 CPU.

3rd

MOVE from SR in User mode could be seen as an minor error

4th

The TAS instruction could freeze the Amiga.

Last edited by OneTimer1 on 09-Jan-2025 at 07:32 PM.

@OneTimer1

I'd say that the 68010 was the first working implementation. The 68000 itself was more of a release candidate, lol.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @OneTimer1 I'd say that the 68010 was the first working implementation. The 68000 itself was more of a release candidate, lol.

But with 68010 comes another error, the 68010 could execute short loops in its prefetch queue, that was great because it brought some speed improvement, but made some games with self altering code (used for copy protection and decrunching) fail. And if you used the MOVE from SR you got an exception leading to an Guru because there was no code for the simulation of the former behavior.

The 8088/86 did always guarantee backwards compatibility, they would even copy old errors because of compatibility, they learned this with the 80186 that was an improvement to the 8086 but used some exception codes that where used in MS-DOS (or many MS-DOS programs).

Last edited by OneTimer1 on 09-Jan-2025 at 07:43 PM.
Last edited by OneTimer1 on 09-Jan-2025 at 07:41 PM.

Karlos Quote:

Let's talk about what is really wrong with 68K: 1. Loading address registers doesn't affect condition codes. At the very least it would have been beneficial for it to set the Z flag since all bits zero is an almost universal representation of the null address and it makes it simpler to check before dereferencing.

Not setting the CC register for all MOVE and ALU operations is the default on most RISC architectures so how is it a problem on the 68k for address registers? The 68k always setting the CC register for data register destination MOVE and ALU operations is more likely to be criticized. The decision was a trade off that improves code density and decreases the number of executed instructions but makes instruction scheduling more difficult and complicates CPU core designs. It was one of the three challenges for the 68060 design as Joe Circello wrote in the following paper.

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

Application of Superscalar Design Techniques to CISC Instruction Sets Implementation is complicated by: o Variable-length instructions o Multiple instructions formats o Traditional "condition code" indicators

All three complications were overcome minimizing the disadvantages while gaining the advantages of each. The increased complications are better than the alternative of fetching more code and executing more instructions.

I believe it would be a bad idea to set the CC on address register writes. Another possibility would be to have separate CC-D and CC-A flags for the different registers. The best solution may be to combine the TST and branch instructions.

bsr function
move.l d0,a0 ; no CC set with An destination
tst.l a0 ; 68000 may use move.l a0,d0 to set the CC
beq error ; usually a long forward branch

It may be possible to fold/fuse instructions to be executed as one instruction and this is a reasonable solution for legacy 68k code. However, requiring instruction folding/fusion for a new/enhanced architecture may be undesirable (a RISC-V mistake?) and the code is not dense knowing that most branches are not short. A new TBcc (CC=EQ and NE only) instruction assuming at least a 16-bit displacement may be worthwhile.

bsr function
move.l d0,a0 ; no CC set with An destination
tbeq a0, error ; test a0 and branch equal

Allowing Dn as well for when the CC has been lost or is desirable to preserve, could be useful too but at the cost of an extra encoding bit.

@matthey

Nobody is talking about what risc chips do, most of them don't have the concept of separate address registers anyway. The point is, the 68000 designers decided to update CC for move operations generally and it's useful. Setting the zero flag for address loads would've been useful and I strongly doubt would have added any significant complexity.

_________________
Doing stupid things for fun...

@OneTimer1

Quote:

The TAS instruction could freeze the Amiga.

This is not the problem of m68k which uses special bus cycle for that, which is necessary if TAS shall be an atomic operation. This is a problem of Amiga chipset which does not support this kind of bus cycle.

@michalsc

Quote:

This is a problem of Amiga chipset which does not support this kind of bus cycle.

I know, the 68k used a different bus cycle for this command, incompatible to the Amiga specific way organizing the DMA slots, TAS was meant to be 'atomic'.

This is one of the few things where I would say: F__k compatibility, I'm curious what you are doing in Emu68k or what the Apollo team does?

Alignment error is another one, it could have been fixed over the exception handler, but I never heard it was done. Later versions of the 68k (MC68SEC000, 68020 or higher) doesn't have this problem AFAIK.

Just imagine a Unix like OS, where an illegal command could freeze a productive computer, things that where acceptable on an A500 would cause a major security issue today.

Oh the 'move from SR' on 68SEC000 causes an exception when used in user mode unlike the original 68000, they have fixed this 'error' but caused a compatibility issue.

Last edited by OneTimer1 on 10-Jan-2025 at 08:56 AM.

@Karlos

Wrong. setting Z flag is not important.
nobody care about this.

What is really wrong with 68k is chipset was never really upgraded.
68k camp promise to upgrade chipset.
whole natami/apollo/vampire point was to upgrade chipset.
all of this was pure BS.
17 years passed.
vampire maggie is just cheap copy of atari jaguar blitter.
and don't reach even 3d0 blitter level.

@ppcamiga1

Do be quiet, grown ups are talking.

_________________
Doing stupid things for fun...

@OneTimer1

Quote:

I'm curious what you are doing in Emu68k

On CHIP memory the TAS/CAS/CAS2 are **not atomic** since the bus does not allow it but also they do not crash Amiga. In case of FAST memory they are atomic.

@Karlos

Quote:

Karlos wrote: @ppcamiga1 Wrong. If you are loading something into an address register it's almost always because you intend to use it as part of an effective address, i.e. a pointer. Before you do that, you almost always want to make sure the pointer isn't null.

No, you only want to test for null when null is a valid possibility. The OS generally doesn't do it because what can it do if a null pointer is found when it needs a valid pointer?

Testing a pointer for null isn't hard, just load it into a data register or 'cmp' the address register to 0 or 'tst' the memory location - not a big deal.

Quote:

Not setting the Z flag means you can't just rely on checking the condition code after doing a movea to the register. Instead, you need to either explicitly do a tst.l on the operand first or move it to a data register and test the condition before moving from the data register to the address register. All extra steps to detect that the pointer you have is null. It's a bit sucky.

Other popular CPUs of the day only set flags when loading the 'accumulator', which tends to be a bottleneck. The 68000 doesn't have this restriction, but going the other way (where every operation affects the flags) can be annoying too, especially when doing operations on pointers.

There is also a performance advantage. On the 68000 the address registers have their own execution unit that runs in parallel to the data execution unit. That's how you can have auto incrementing/decrementing by various amounts with no penalty, because it doesn't have to go through an ALU.

@bhabbott

I think people overestimating the complexity of checking all bits 0 when loading an address register and equally underestimating the value of knowing if it's null "for free" i.e. without additional test/compare/move via a data register first.

I'm certain nobody would be complaining if it had set the Z flag since day 0, it would just be accepted as a sensible behaviour for dealing with addresses.

Last edited by Karlos on 10-Jan-2025 at 11:20 AM.

_________________
Doing stupid things for fun...

@michalsc

So your Emu68k did some kind of fix for this instruction ... nice done.

@Karlos

Quote:

I'm certain nobody would be complaining if it had set the Z flag since day 0, it would just be accepted as a sensible behaviour for dealing with addresses.

I regretted the differences of address and data registers, understanding and remembering the differences, made assembler programming harder.

But maybe it made it easier for CPU designers, AFAIK they could do address calculations parallel (or was it pipelined ?) to data register handling. The 8086 had to use the ALU for address calculations.

Last edited by OneTimer1 on 10-Jan-2025 at 11:32 PM.

@Karlos

stop trolling

nobody care about loading 0 to adress resgisters
everybody check explicity in C code or use mmu

biggest annoing thing in 68k is lack of nice fast usable graphics at rational price
something as good as fast as ocs in ex 1992
in 2008 natami/apollo/vampire start this whole thing about upgrading chipset
but 17 years later 68k camp still has nothing

I bought my NTSC CD32 in the states from a store that dealt with a Canadian supplier.
If you wanted a CD32 in the states - you could get one. I also bought an SX-1 with it and was running 8MB of fast ram and a 2.5" harddrive. I was surfing the web with IBrowse and a 28.8k modem in 1994.

What's wrong with 68k?

Too little (performance)...
Too late (releasing improvements)...
Too much (cost)...

That's why ARM won and 6502 derivatives are still in production. If you're wearing a pacemaker - thank the 6502.

The fact that 'hombre' was gonna dump 68K should tell you something. More than 8-bitplanes? Yeah - time to dump this architecture!

It was great/good enough from 1984-1988. Then it just became a boat anchor. Blame Motorola. That's what I do.
A500/2000 should have been 020 machines.
The CD32 would have been a good games machine in 1990, not 1993/4.
The A3000 should have been cheaper and released in 1989. The A4000 was not enough of an upgrade compared to the competition. Then Commodore died.

'060LC chips didn't get cheap until the late 90's when they were being used in the first Motorola cable modems. How do I know? I used to assemble and test them at the Motorola ISG plant in Massachusetts. The Amiga was already quite dead in 1998.

Too little, too late - for too much!

Emulate 68k and revel in your fond memories.
Too many old farts around here hanging onto the Titanic lifeboats.
Support AROS/MOS/OS4 on your platform of choice if you really want progress. Forget about this cpu.

I've been on this site for OVER 20 years waiting for 'progress'. It's insane. At this point I think I'm better off with a Mega65.

By the way, my hat's off to people like Michael Shultz and others for their work... But at the same time - the rest of you need to realize it's a hobby, not a future computing platform...and the in-fighting is not worth it.

Last edited by Lou on 10-Jan-2025 at 11:16 PM.
Last edited by Lou on 10-Jan-2025 at 11:14 PM.