[roondar]

Originally Posted by litwr

Sorry, I know little about 68k co-pros. Your words show that they were rather very expensive and rare. So the bug terrible in x86 world could be tolerated in 68k world.

The Motorola coprocessors were roughly the same price as their x86 counterparts.

The real reason they're rare is that, on average, most software didn't actually need an FPU back in those days. This goes for both x86 systems and 68k systems. I knew quite a few people with a PC and no-one had a 8087/80287. One or two did have a 80387 later on, but only because it came with the system - they didn't actually need one either.

You're simply vastly overstating the usefulness of an FPU in the 1980's and early 1990's to the average user. An 8087 coprocessor box from Intel from 1987 (or later) pointed to all of 160 programs that could benefit. Wow, what a large number out of the thousands and thousands of programs out there at the time. It sure sounds like a must have accessory

https://www.worthpoint.com/worthoped...sor-1856611681

It is because 65816 doesn't have a hardware division. With 16-bit arithmetic it is about 50% faster than 6502 with the same frequency. 65816 has also fast memory block movement instructions and several other very good features. So it is generally faster than 6502 and sometime much faster. You agreed that 6502 @4MHz can be faster than 68k at 8 MHz for byte processing. IMHO 65816 can be faster and with 16-bit processing.

I agreed that some 8-bit things would be faster, not all things. There is a lot of stuff at which a 4MHz 6502 will still be slower than an 8MHz 68000. The same will turn out to be true for 16 bit operations on a 65816@4MHz vs a 68000@8MHz.

Your arithmetic example even proves my point - if you check the cycle times of the 16 bit add/sub commands for both you will quickly find that the 65816 isn't always faster even clock for clock (i.e. the 65816 actually is slower clock for clock than the 68000 on some of these commands) and when it actually is faster clock for clock, it still is never over 2x as fast so it'll at best be the same speed when compared to a 68000@8MHz - even on instructions you yourself present here as being faster.

And that leaves out the main problem that the 6502/65816 faces, which is that the Motorola tends to simply need less instructions to do the same things as a 6502/65816 by virtue of not being an accumulator based design - even if we pretend that multiply and divide don't exist. This difference is somewhat smaller with 68000 vs 65816 as the 65816 adds a bunch of instructions, but still very clearly exists. Which means that looking at instruction cycle counts of simple stuff only tells a small part of the story. And a wrong one at that.

The blockmove is nice though, I'll grant you that.

Now, I've not been able to find other 65816 benchmarks, other than a few references to them on the 6502.org website (where apparently the 65816 lost to the 68000 on the sieve benchmark by a rather significant margin, though they did not provide a link). Interestingly, people on that forum concluded that the 65816 would indeed be faster than the 68000 - if they both ran at the same clock. And I'd agree with that.

Of course, it would still lose at half the clock speed - given the few data points we do have and the fact that the very fans of the CPU didn't claim it themselves (if I was a 6502 fan I would certainly claim such a thing if it were true!). Could there be benchmarks in which the 65816 wins? Well, show them and I'll admit defeat. But claiming something when the only evidence says you are wrong is clearly not going to work.

Indeed but it is better than nothing. I remember that I had to run this emulation in the early 90s because required software used co-pro.

This is seemingly a pure x86 problem. I've never had this problem on my Amiga back then - 99.9% of software simply included two binaries.

So there was a software for FPU only.

This reply of yours is highly disingenuous and you know it. Firstly, I show that FPU & non-FPU software is normally part of the same package. Then I go on saying that with a lot of searching I could find one example of this 68LC040 thing being a problem back in the day. That simply does not translate into the problem being a big deal or worthy of being discussed. My results in fact show there is no real problem. Unless you can actually show me why this problem you think is a big deal actually is actually such a big deal (you know, with fact based evidence - like a massive list of affected programs), I'll consider this matter closed.

I can repeat it sounds very odd. Why do not use faster sines or exponents? It sound like somebody says that he doesn't need multiplication because he always can get the same results with addition only.

You thinking it's odd doesn't make it so. I can keep repeating this it seems: actual, real world results don't agree with your opinion. In the real world almost no one used the FPU for these and as such, removing it from the FPU didn't change much.

The point here then, isn't that these functions couldn't be useful, but rather than they (for whatever reason) were used only rarely. That you personally don't understand why this was so is honestly completely irrelevant - it won't change the facts.

It sounds odd again. Moto had to cut a useful part of its chip. There is nothing good about that.

What is odd it how you refuse to understand why this might have been the right choice. Seriously, just because you don't understand it doesn't mean it was the wrong thing to do. Case in point, the 68040 was quicker than the 486 clock for clock on all the things that it did implement. Clearly then, their choice had merit - they sacrificed a part of the FPU that almost no one used and in return got a CPU that was 25% faster than the competition. This is how engineering is done - you try to pick the best possible compromise that fits the limits of technology, budget, etc.

Would it have been nicer to have these functions? Sure. But not by as much as you think and the cost to keep them was apparently too great.

There is always high-end and low-end system. 8088 based systems were quite good as a middle class of computer to the end of 80s. What is wrong with it? Amstrad PCW with z80 at effective 3.2 MHz could be quite successful to the start of 90s. Indeed for top systems there were 80286 and 80386. 80486 was available in PC since 1989, Moto had nothing comparable in 1989. 68040 with slow FPU can be generally better for top systems only until 1991 when 486dx/2 beat it forever.

You must be joking

The 8088 was not a 'middle class' computer by the end of the 1980's, it may have delivered mid-range performance in 1979, but was completely obsolete by 1985. The Apple's, Atari's, Amiga's, PC-AT's out by then absolutely trounced it performance wise.

As for 80286/80386/etc - that is completely irrelevant. This part of our discussion was purely about the 8086 as designed. You've repeatedly claimed the 8086 itself (not the follow-ups, the actual 8086 CPU) was fine until the late 1980's. Yet in 1982 the design was already so far out of date that Intel redesigned it really rather thoroughly in an effort to get it up to date.

But don't just take my word for it - there's this litwr guy who only a post ago said something rather similar in different words "Indeed 8086 needed a major upgrade in 1982 and it got it!". But now this other guy (I believe he's called litwr), disagrees with litwr

Seriously, one post back you agree with me that the changes to the 8086 were needed and now you're straight back to claiming there was nothing wrong with it

You claimed very odd thing. I can run old DOS software with my modern multi-core PC. I have even a bootable DOS partition on my HDD. Indeed some programs can be incompatible with virtual 8086 mode without proper OS support. However DOS software for work usually worked well with Windows or Desqview. Problems could be mostly with some games. Though even almost all games can run fine with modern virtual machines. You have pointed some real mode instructions that require emulation when using virtual 8086 mode. Agreed, but there are only a few of them, they are just emulated, and they are quite rare so the performance almost not affected. Only i/o became notably slower. If you need benchmarks just run a DOS benchmark program in the real mode and with virtual machine on modern Linux or Microsoft Windows. I worked with my emulator for Commodore plus/4 computer, it worked with almost identical speed in the both environments.

I have not claimed an odd thing, I have claimed a factual thing that you seemingly just don't want to hear or something.

So, just to (hopefully) break through this continued nonsense about real mode being compatible with protected mode one last time, here are the facts. Not opinions, not oddities, just facts.

1) Installing and running DOS on a modern PC proves nothing about real mode code running in protected mode, because.. DOS, even on the very latest x64 processors, does not run in protected mode.
2) Real mode code will not run in protected mode as-is. It will crash.
2) The workaround to this, namely Virtual 8086 mode, needs the OS to handle things or the real mode program will again crash.
3) The above shows that real mode code is not compatible with protected mode - if it were compatible, no workaround would ever be needed.

And again, I'm not saying you can't run the CPU in real mode - you can. I'm also not saying the compatibility hacks required for Virtual 8086 mode don't work - they do.

However, neither are relevant - An Intel CPU in protected mode cannot run 8086 code without requiring workaround in software. This fact proves the two modes are not compatible - no matter how often you make claims about running DOS or using an OS that has these workarounds built-in.

After all, if the OS using workarounds is an acceptable solution then your original point (remember were we started this) about some 68k code not being compatible with 68010+ is null and void - you can simply have the OS reset the VBR and run any offending program in supervisor mode. This is much less work than virtual 8086 mode requires and works just fine.

It doesn't change anything. 68k PDP-11 like ISA couldn't compete with more modern technologies. Indeed there is some charm in the retro style of old things but they are rather for museums now.

I never, ever claimed 68k is still relevant today. I've claimed that 68k was relevant for far longer than you claimed it to be. And despite what you posted above, that is a completely accurate statement. Case in point: you could buy a really rather popular device containing a 68k based CPU for years after the 486 had vanished from the PC market.

Oh and I found a lovely gem on the Wikipedia page on the PDP-11:

Originally Posted by Wikipedia PDP-11

The design of the PDP-11 inspired the design of late-1970s microprocessors including the Intel x86[1] and the Motorola 68000.