Quote:

bhabbott wrote: [quote] Then you must think other CPUs are horrible. x86 for example doesn't set flags for any Move, Load or Store operation. 8080 and Z80 don't set flags on inc or dec of any register except A (to test a 16 bit register pair for zero you do eg. LD A,B : OR C).

Yes, they are horrible.

It was acceptable on an Accu oriented 8-Bit CPU, they couldn't do better. Programming he 68k was nearly as comfortable as writing code in a high level language.

Quote:

Karlos wrote: Something that would have been nice to have is byteswapping.

The 8086 had very practical instruction for single bytes access in the registers, maybe because it was just a tuned-up 8-bit CPU. those single byte commands are very usable if you are working with GFX. On the 68k you had to fiddle around with shift operations and masks, consuming a lot of code and time. Some DSPs have great commands for Byte and Word arithmetic, things that are important for signal processing, on the 68k you will need a lot of code instead, but still they call the 68k a CISC where those DSPs are RISC.

Quote:

ppcamiga1 wrote: 68K lack nice fast easy to use graphics at rational price.

Yes there are no 68k chips with build in GPU, you should switch to a nice motherboard with AMD instead but the MPC85XX is considered to be a failure.

Quote:

bhabbott wrote: A tiny cache wouldn't be much use unless you had FastRAM (unlike the ST, ChipRAM may be modified by the Blitter, so caching it is dangerous).

OK, there is problem with this DIY cache and ChipRam, it might not have been the best idea.

Quote:

bhabbott wrote: At least 4 RAM boards were produced that could plug into both the A1000 and A500 (some had a different case for each).

I know, you could use the same board but the connector was upside down, making the usage of A1000 cards for A500 very complicated.

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

@bhabbott

Quote:

2. It's debatable that a 1995 PC was as great as you say.

I had PC in 96/97 running Windows 95. It sucked.
The hardware was far more powerful than my Amiga (A1200 / 030) but Windows 95 was slow and unstable. I don't remember Windows 98 being much much better.

Later I tried BeOS and it was awesome, just like the Amiga. Very responsive, you could run loads of stuff at the same time and it didn't crash.

Quote:

Today you only have to spend the equivalent of US$100 in 1995 money for a PiStorm with RPi3a, giving your Amiga equivalent power to a 2000+ era PC. And unlike a PPC 'Amiga' it's still fully 68k, so you can continue to enjoy the platform you are comfortable with.

Or, if your A1200 won't boot (like mine) there's the A500 mini and A600GS both at similar prices. If you want a bit more oomph, (and are prepared to do the setup), the Raspberry Pi 5 is also a similar price and runs the same as a 2015 PC. I did this and have it overclocked @2.8GHz. It runs as fast as my 2016 MacBook Pro (i.e. posts much the same Geekbench numbers).

Quote:

However many of us are quite happy with performance similar to what our Amigas had back in 1995.

For backwards compatibility with games and the like that makes a lot of sense.
However, if there's additional performance available why not use it. It's very useful for compute intensive tasks, e.g. I used to play around with ray tracing but it took forever, one low-res render I did on an A1000 took 96 hours! On the RPi5 I'm counting render times in seconds.

Quote:

Talking about speed, I can boot my A1200 from cold in 15 seconds,

From pressing start in Amiberry, 3.1 compete boot in under a second. The fact it's basic install, and the NVMe drive probably helps

Total boot is slower because it's booting into Linux first of course but that's not exactly slow either.

Quote:

My Amigas are now my 'fun' machines.

Same for me, I got the RPi to use as an Amiga, just to mess around with.
Emulating on a PC or Mac just never grabbed me for some reason, not sure why. This is more like the real thing, possibly because it's a separate box, it's even connected to the TV.

Last edited by minator on 12-Jan-2025 at 01:17 AM.

_________________
Whyzzat?

@minator

Quote:

minator wrote: @bhabbott I used to play around with ray tracing but it took forever, one low-res render I did on an A1000 took 96 hours! On the RPi5 I'm counting render times in seconds.

Yes, but it's not really ray tracing unless you can it see drawing each line across the screen one pixel at a time. :)

@Karlos

stop trolling start working

ppc has nice fast graphics.
graphics cards are standard on Amiga PPC.

Amiga 68k has worse graphics.
vampire still not reach even PS1 level.
pci slots are expensive and works very slow
except ridiculously overpriced GREX hardware

68k trolls should working on better graphics.
something that will be on PS1 level native and at rational price

@minator

Quote:

minator wrote: I had PC in 96/97 running Windows 95. It sucked. The hardware was far more powerful than my Amiga (A1200 / 030) but Windows 95 was slow and unstable. I don't remember Windows 98 being much much better. Later I tried BeOS and it was awesome, just like the Amiga. Very responsive, you could run loads of stuff at the same time and it didn't crash.

This mythical beast speaks the truth!

A trough of the finest ambrosia for our sensible compatriot!!!

_________________
All the way, with 68k

Karlos Quote:

Now that clarification is made, the other problems I have with the 68000 as an implementation of the 68000 architecture were pretty much addressed (pun half intended) with the 68010. Most importantly the ability to recover from various otherwise dead-end error cases, incomplete separation of supervisor and user mode due to the ability to mess with the status register and finally the ability to relocate the vector base. This is why I consider the 68000 itself as being akin to a beta release. The 68010 was the "proper" MVP.

The 68000 being "akin to a beta release" is an exaggeration. I would not even classify the 68000 issues as bugs.

unrecoverable bus faults (minor issue without a MMU) - oversight
user mode MOVE from SR (read only and minor issue without a MMU!) - oversight
CLR load+store mem access instead of only store - oversight
relocatable VBR - new feature

A "beta release" CPU has been in production for how long?

https://en.wikipedia.org/wiki/Motorola_68000 Quote:

After 46 years in production, the 68000 architecture is still in use.

Apple, Commodore, Atari, Sharp and Sega all decided to use the 1979 68000 and not upgrade to the 1982 68010. The 68010 was only available 3-4 years after the 68000 and had a fraction of the production life. Motorola was not interested in replacing the 68000 because there was no major problem. They were able to upgrade the disastrous PPC 603 to PPC 603e with double the caches, more cache ways and a die shrink in about a year when motivated. The PPC 603 to 603e is a ~63% transistor increase vs 68000 to 68010 transistor increase of ~1% and the PPC 603 was effectively replaced on the desktop by the PPC 603e where the 68010 never replaced the 68000 on the desktop.

Karlos Quote:

Something that would have been nice to have is byteswapping. The swap instruction could have been better defined. Swapping two 16 bit halves of a register is useful sometimes, especially when doing things like division, to get the remainder, but I think that the ability to perform a full byteswap efficiently was an embuggerance. My preferred implementation of that wouldn't actually be to extend the swap instruction per se (though that would be an MVP) but to have a move variant since that's actually a lot more useful for real world use cases like data conversion.

It is too bad the ColdFire MVS, MVZ, BYTEREV and BITREV instructions did not make it to the Motorola/Freescale 68k. SIMD units usually have a PERM instruction that can also swizzle. The AC68080 likely has all these now that Gunnar finally decided the ColdFire instructions were worthwhile after years of absence.

Karlos Quote:

Having spent a long time with both, I can summarise the difference between 68K and PPC from a development perspective. 68K is a generally a joy to program directly but occasionally frustrating. PPC is frustrating to program directly but with some occasional charm. On the whole, PPC is better for development in higher level languages. Of course that's also it's biggest problem. As soon as you start writing software entirely in higher level languages, there are many better hardware targets to choose from, especially since it's demise in desktop computing.

I remember the x86 vs PPC desktop days. PPC fans bragged about their 32 GP registers and compiler orthogonality advantage while x86 developers optimized games in assembly using their 8 GP registers. The rest is history especially PPC.

Karlos Quote:

On the very edge is the 68060. It can be frustrating to program directly compared to earlier models in order to extract the best performance from it and code tuned for it can be significantly worse on earlier CPUs. On the flip side it begins to perform a lot better than earlier models with compiled code.

The 68060 is easy to program for a semi-modern in-order superscalar CPU design. Legacy 680x0 code has a 45%-55% pair/triplet instruction issue rate which only improves to 50%-65% for optimized 68060 code. This means instruction scheduling is not nearly as important as for most RISC CPUs. There is plenty of room for improvement too. Using 32-bit datatypes to avoid partial register writes and allow result forwarding is important but this is usually good for the 68020-68040. Compiling for the 68020-68030 and instruction scheduling for the 68060 gives excellent results, not that popular compiler backends have 68060 instruction schedulers. The biggest problem here is the missing integer 64-bit MUL and DIV instructions which is maybe the worst mistake of the 68060. With the exception of bitfield instructions and large instructions, the 68060 has minimal timings/latencies for most instructions and addressing modes. The 68060 feels like a superscalar 68020/68030 successor where the 68040 is the 32-bit 68k CPU that feels different.

@matthey

They're bugs in the implementation. I didn't say they rendered it useless. The proof of that is in the uptake, particularly among home computers and consoles. However, the simple fact is, for "professional" OS development, those "minor oversights" are highly undesirable. Of all the the things they could have added or changed for the next iteration, they chose those. That alone is enough to tell you these weren't minor issues.

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: Apple, Commodore, Atari, Sharp and Sega all decided to use the 1979 68000 and not upgrade to the 1982 68010. The 68010 was only available 3-4 years after the 68000 and had a fraction of the production life.

Well, it seems to be the other way around

The 68EC000 / 68SEC000 (that might still be available from NXP) has all the fixes that the 68010 (and later version) brought with it, NXP has stopped producing the 68000 but might still offer the 68SEC000 as replacement. (AFAIK)

https://en.wikipedia.org/wiki/Motorola_68000#68EC000

Last edited by OneTimer1 on 12-Jan-2025 at 04:09 PM.

@Hammer

Quote:

Hammer wrote: 1990's Windows 3.0's 10 million sales (along with Excel and WinWord) were the big nuclear bomb against 68K desktops and DOS "killer apps" establishment. MS Office 1.0 was also released in 1990.

For business computing perhaps, but that market was already sewn up in 1981.

The Amiga had word processors and spreadsheet programs that did the job fine - if that's what you wanted to do. So why pay more to do what an Amiga could do for less? Because you were running a business. So of course you used a PC because everybody else did, and because cost didn't matter, and you wouldn't be playing games etc.

But the home/hobbyist market was different. Price did matter, and you were using the computer for fun - not boring work stuff - so it needed to be fun. Why would that have changed in the 90's? Because the culture was changing. The emphasis was on making money, not enjoying life. Jack was now all work and no play, a dull boy.

If that's what you wanted then fine, but many of us didn't. In the 90's I was running a business full time, but I still wanted to have fun. And PC's weren't fun. How could they be when everything about them screamed work? The last thing I want to see on my fun machine is Microsoft Office.

Quote:

Wing Commander's 1990 release completes the double banger. Wing Commander was PC's Defender of the Crown moment.

Wing Commander was a big hit on the PC because PC gamers were shallow and had low expectations. I tried playing it again a few days ago and was not impressed.

BTW guess which platforms didn't get it until 1992 or later? The SNES, Amiga, FM Towns and SEGA CD (in 1994). Such an amazing game it was that nobody could be bothered porting it to these popular platforms until years later. Here's what one magazine said about the SNES version (giving it a score of 60%):-
Quote:

I wonder if that wasn't over-rated in the first place. All that said, of course, there are die-hard fans out there who really like it. If you loved the space battle bits out of Elite, if you're eagerly awaiting Accolade's nearly identical Warp Speed, if you adored the PC original, then you'll love this - it's almost the same game. For others, though, play before you pay - I suspect you'll be rather disappointed.

Defender of the Crown was a work of art, Wing Commander was a POS in comparison. PC gamers wouldn't know that though, because DotC was ported to the PC in 1987 in puke EGA and disgusting CGA, so they never got to see the gorgeous graphics of the original. Gameplay was stink too - it didn't even use a mouse!

Poor ports like this are one of the reasons PC gamers went gaga when they finally got games with more than 16 puke colors - imagining that Amiga games can't have been that good in 32 colors if DotC looked so awful on a PC. But that's the way it went with PCs. The die was cast in 1981 so you had no choice. It was PC or nothing because you needed it for the business, so you put up with you got and pretended to like it. Tragically that's still true today. Windows 11 is awful but everybody uses it because they have no choice.

Last edited by bhabbott on 12-Jan-2025 at 08:02 PM.

@Karlos

Quote:

Karlos wrote: the simple fact is, for "professional" OS development, those "minor oversights" are highly undesirable. Of all the the things they could have added or changed for the next iteration, they chose those. That alone is enough to tell you these weren't minor issues.

That goes far more for x86, whose limitations were immediately obvious. Yet 8088 CPUs were the most popular throughout the 80's, simply because IBM chose it for the PC. Intel's next CPU, the 80186, was even more flawed - so much so that it couldn't be used in the PC. The 80286 had severe limitations too that made it a pain to use in the PC. IBM's choice of the 8088 CPU crippled the PC for over a decade, and its effects are still with us today.

In comparison the minor issues the 68000 had were nothing, especially in a home computer which wasn't going to have virtual memory etc. There was no pressure to use the 68010 because it didn't offer any advantages worth paying for.

As for a 'professional' OS, that was a tiny market which rapidly outgrew the 68000 anyway. Amiga OS not being a part of that was good. It was designed to be a very lightweight but powerful OS optimized for the low-end home/hobby computer that the Amiga was, and it did that job admirably. Even today Amiga OS 3.2 works fine on a 68000, unlike Microsoft Windows which abandoned the 8086 in the early 90's and 80286 soon after - for good reason.

@OneTimer1

Quote:

OneTimer1 wrote: The 68EC000 / 68SEC000 (that might still be available from NXP) has all the fixes that the 68010 (and later version) brought with it, NXP has stopped producing the 68000 but might still offer the 68SEC000 as replacement. (AFAIK) https://en.wikipedia.org/wiki/Motorola_68000#68EC000

You can still buy the 68SEC000 today, from Flip Electronics (11760 of the 20MHz version in Stock). I have one that I hope to use some day.

@Karlos & OneTimer1
There are several 68000 variants with different levels of compatibility to the original.

https://en.wikipedia.org/wiki/Motorola_68000#CMOS_versions Quote:

CMOS versions The 68HC000, the first CMOS version of the 68000, was designed by Hitachi and jointly introduced in 1985. Motorola's version is called the MC68HC000, while Hitachi's is the HD68HC000. The 68HC000 offers speeds of 8–20 MHz. Except for using CMOS circuitry, it behaved identically to the HMOS MC68000, but the change to CMOS greatly reduced its power consumption. The original HMOS MC68000 consumed around 1.35 watts at an ambient temperature of 25 °C, regardless of clock speed, while the MC68HC000 consumed only 0.13 watts at 8 MHz and 0.38 watts at 20 MHz. (Unlike CMOS circuits, HMOS still draws power when idle, so power consumption varies little with clock rate.) Apple selected the 68HC000 for use in the Macintosh Portable. In 2024, Rochester Electronics was licensed by NXP to continue to produce the MC68HC000. Both the physical design and test program were transferred to Rochester from NXP to continue to supply an authorized source to the market. The Rochester Electronics version of the 68HC000 is a product clone of the J82M mask set which was the last mask set used by Motorola. Motorola replaced the MC68008 with the MC68HC001 in 1990. This chip resembles the 68HC000 in most respects, but its data bus can operate in either 16-bit or 8-bit mode, depending on the value of an input pin at reset. Thus, like the 68008, it can be used in systems with cheaper 8-bit memories. The later evolution of the 68000 focused on more modern embedded control applications and on-chip peripherals. The 68EC000 chip and SCM68000 core remove the M6800 peripheral bus, and exclude the MOVE from SR instruction from user mode programs, making the 68EC000 and 68SEC000 the only 68000 CPUs not 100% object code compatible with previous 68000 CPUs when run in User Mode. When run in Supervisor Mode, there is no difference. In 1996, Motorola updated the standalone core with fully static circuitry, drawing only 2 μW in low-power mode, calling it the MC68SEC000. Motorola ceased production of the HMOS MC68000, as well as the MC68008, MC68010, MC68330, and MC68340 in on June 1, 1996, but its spin-off company Freescale Semiconductor was still producing the MC68HC000, MC68HC001, MC68EC000, and MC68SEC000, as well as the MC68302 and MC68306 microcontrollers and later versions of the DragonBall family. The 68000's architectural descendants, the 680x0, CPU32, and Coldfire families, were also still in production. More recently, with the Sendai fab closure, all 68HC000, 68020, 68030, and 68882 parts have been discontinued, leaving only the 68SEC000 in production.

Original NMOS 68000 CPUs were converted to the CMOS 68HC000 with minimal changes to preserve compatibility and were produced by Motorola/Freescale/NXP for a long time and are still available from Rochester Electronics. After the 68000 was no longer used for workstations, the desktop or consoles, compatibility was less important for embedded use so the 68EC000 and 68SEC000 CPUs made some of the 68010 changes but not all.

MOVE from SR Supervisor only
MOVE from CCR added
BKPT added
Statically Selectable 8- or 16-Bit Data Bus (like the MC68HC001)

The 68EC000 and 68SEC000 do not have VBR, SFC or DFC registers or MOVEC or MOVES instructions like the 68010. Additional stack frame data is not pushed on the stack to recover from a bus error like the 68010. The 68010 was only ~1.5% more transistors than a 68000 yet some of the features some people refer to as "bugs" were deliberately retained.

Reference which describes 68010 and 68EC000 differences follows.

https://bitsavers.trailing-edge.com/components/motorola/68000/M68000UM_AD_M68000_Microprocessor_Users_Manual_Rev8_1993.pdf

I believe this Motorola 9th edition manual has some errors remaining but it has some info not easily found elsewhere.

Last edited by matthey on 12-Jan-2025 at 09:50 PM.
Last edited by matthey on 12-Jan-2025 at 09:43 PM.

@matthey

Quote:

The 68000 being "akin to a beta release" is an exaggeration.

68010's corrective instruction set changes were carried over into the full 32-bit 68020.

Before 68851's release, C= wasted R&D resources on C= MMU for 68000 and another C= MMU for full 32-bit 68020.

C= MMU for 68000 was *nix working with slow context switching, i.e., it needed a TLB cache.

68010 allows for WHDLoad to exit and restore the AmigaOS session.

68K's MMU issue allowed system integrator platform lock-in.

Quote:

Apple, Commodore, Atari, Sharp and Sega all decided to use the 1979 68000 and not upgrade to the 1982 68010. The 68010 was only available 3-4 years after the 68000 and had a fraction of the production life. Motorola was not interested in replacing the 68000 because there was no major problem.

Motorola didn't price out 68000 with the instruction set corrected 68010.

For Motorola, any Unix-related CPU feature is a price premium while 286/386 PMMU is a bundled standard.

68010's tiny loop cache is good for repeated moving pixels.

Quote:

They were able to upgrade the disastrous PPC 603 to PPC 603e with double the caches, more cache ways and a die shrink in about a year when motivated. The PPC 603 to 603e is a ~63% transistor increase vs 68000 to 68010 transistor increase of ~1% and the PPC 603 was effectively replaced on the desktop by the PPC 603e where the 68010 never replaced the 68000 on the desktop.

PPC 603's small cache issue impacted 68K emulation. Gary Davidian's original Mac 68K emulator would not fit into 8KB of cache memory, severely hampering performance when running older applications written for the Motorola 68000 series.

Unlike 68010, PPC 603e was bundled with Apple's SKUs.

Quote:

I remember the x86 vs PPC desktop days. PPC fans bragged about their 32 GP registers and compiler orthogonality advantage while x86 developers optimized games in assembly using their 8 GP registers. The rest is history especially PPC.

During X86 vs PPC desktop, the Pentium era has minimum penalty transfers between GPR and FPR and Pentium FPU can process integer formats. PPC has a higher penalty with data transfers between GPR and FPR.

With minimal GPR and FPR (floating point registers) data transfer penalties on the X86 side, the Pentium era effectively has 16 registers and Pentium guarantees FPU availability for all SKUs.

DirectX6's geometry stage has an abstraction layer for Intel SSE and AMD 3DNow differences. Microsoft quickly supported X86's FP SIMD extensions for 3D games.

Quake 2 has direct 3DNow support. Quake III exploited Pentium II's minimal GPR and FPR data transfer penalties which is a significant problem for PPC. X86's stack nature is optimized for C++ function call stack. I can repost Quake III MacPPC porter's remarks on X86 vs PPC.

For the X86-64 version 1, minimal GPR and scalar SSE data transfer penalties effectively resulted in 32 registers effective. X86-64 guarantees SSE2 availability for all SKUs.

PowerPC camp can't even guarantee PowerPC FPR for SKUs since Freescale still hacks PPC ISA e.g. e500 PPC core.

68060 can't guarantee FPR availability for all SKUs i.e. the same ISA hacks mentality for Freescale PPC and 68K.

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

I do have 68010 chips for my Wicher 508i accelerator. My Wicher 508i has 68HC000 20Mhz rated that is overclocked to 50Mhz. Amiga applications that expect a faster 68K CPU also assume at least 68020 CPU. Before PiStorm, my candidates' CPU accelerators for A500 are Vampire V2 or TF536. I had A3000/030 @ 25Mhz, hence very fast 68HC000 wasn't ideal due to 68020+ compatibility reasons.

Last edited by Hammer on 13-Jan-2025 at 02:10 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

@bhabbott

Quote:

That goes far more for x86, whose limitations were immediately obvious. Yet 8088 CPUs were the most popular throughout the 80's, simply because IBM chose it for the PC. Intel's next CPU, the 80186, was even more flawed - so much so that it couldn't be used in the PC. The 80286 had severe limitations too that made it a pain to use in the PC. IBM's choice of the 8088 CPU crippled the PC for over a decade, and its effects are still with us today.

The integrated hardware included in the 80186 was incompatible with the support chips chosen by IBM for the 8088-based IBM PC.

Telex 1260 is a desktop PC-XT compatible clone with 80186. 80286 was released in Feb 1982 which makes 186 largely useless.

For Concurrent DOS, 286 had multiple stepping due to 286 errata e.g. B-1, C-1, E-1, and E-2. B-1 prototype has working 8086 emulation in 286 protected mode, while it's broken in production C-1.

286's problems led to Bill Gates referring to the 80286 as a "brain-damaged" chip which separated Microsoft's 386 direction against IBM's OS/2 1.x 286 direction.

286's protected mode was used by MS Xenix 286 (1984), Coherent (Unix clone), Minix, and IBM OS/2 1.x.

For the 386 project, Intel, MS, SCO, and Compaq cooperate together i.e. Compaq 386 (Sep 1986), Xenix 386 (1987), and Windows 2.x 386 (1987).

Amiga 1000 with 256KB RAM was released in July 1985. 1985 stock A1000 is below 1987's A500's 512KB RAM spec.

Compaq Deskpro 386 was released in Sep 1986. Gang of Nine PC clones follows Compaq 386's leadership. The cooperation between Intel and Compaq allowed 386's system integration to be quick and repeated for 486's 1989 release.

_________________
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

@ppcamiga1

Quote:

Amiga 68k has worse graphics.

... but Amiga PPC has worse networking, so boo hiss!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hammer

Quote:

Hammer wrote: Amiga 1000 with 256KB RAM was released in July 1985. 1985 stock A1000 is below 1987's A500's 512KB RAM spec.

What a difference 2 years can make!

However both the A1000 and A500 were limited to 512k ChipRAM. I added the internal 256k RAM expansion (which was supposed to come bundled with it) and then 2MB of external FastRAM to my A1000. With a 20MB hard drive this was a sweet setup.

Quote:

Compaq Deskpro 386 was released in Sep 1986. Gang of Nine PC clones follows Compaq 386's leadership. The cooperation between Intel and Compaq allowed 386's system integration to be quick and repeated for 486's 1989 release.

Compaq's 386 was very expensive. 486's were too when they were introduced. In 1989 ~3 million 286s, 2 million 8088/6's, and 1.25 million 386's were sold in the US. In 1991 only ~0.2 million 486's were sold, compared to just under 3 million 286's and a little over 3 million 386s (largely due to introduction of the 386SX which replaced the 286). In the same year ~1.25 million 68k Macs were sold in the US.

The 486 and 386DX were too expensive for the consumer market, which is why Intel introduced the 386SX. This CPU could use the same motherboard as a 286 with minor changes, making it the choice of budget-conscious customers. An article in the June 1994 issue of NZ Computerworld magazine (which I have an original copy of) gives the following examples of 'entry level' PCs (all prices ex. GST):-

1990 386SX-16, 1MB, VGA, 20MB HDD NZ$3495
1991 386SX-20, 1MB, SVGA, 52MB HDD $2395
1992 386SX-25, 1MB, SVGA, 52MB HDD $2395
1993 386SX-33, 2MB, SVGA, 42MB HDD $1895
1994 386DX-40, 4MB, SVGA, 170MB HDD $1899

From this you can see that low-spec 386SX machines were popular even as late as 1993. By 1994 the 386DX was replacing them, with 486s moving into the midrange as higher clocked 486s and Pentiums with PCI bus began to appear at the high end - just in time for Windows 95 to require performance that a 386 (even 386DX-40) couldn't provide.

@kolla

stop trolling
start working on graphics for 68k

@Hammer

Quote:

Hammer wrote: Amiga applications that expect a faster 68K CPU also assume at least 68020 CPU.

Note to Amiga developers:- please don't do this. It's OK to expect an 020 minimum for AGA specific titles, but otherwise you should give 68000 owners the opportunity to run your software, even if it might be a bit slow.

Rest assured that I will not do this in any of my code. Generic 68k only for me!

@bhabbott

Quote:

Note to Amiga developers:- please don't do this. It's OK to expect an 020 minimum for AGA specific titles, but otherwise you should give 68000 owners the opportunity to run your software, even if it might be a bit slow.

Hear hear!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@ppcamiga1

Quote:

start working on graphics for 68k

Graphics is one of the many things I use 68k systems for.

Any good animation software for Amiga PPC yet?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC