@WolfToTheMoon

Nothing was written in stone back then, what if big endian had won.

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

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: MOS 6502 is less than 3500 transistors WDC 65816 is cca 20 000 transistors MC 68000 is cca 68000 transistors. Bang per buck, in the late 70s/early to mid 80s... MOS chip line was probably the better choice. Now if only Tramiel did something more with MOS instead of cost cutting.

If you take into account only the price, then we could end up today using computers with the Microchip's PIC architecture family or something like that.

The price, by itself, cannot be the only factor to consider when choosing a processor.

Yes, the 65xx family is cheap, but very very limited for general-purpose computing. So limited that the 32 bit incarnation never went in production and even its creator suggested to use ARM processors if 32 bits are needed.

Commodore, focusing on MOS, might have went to the bankrupt even before 1994.

@cdimauro

Quote:

If you take into account only the price, then we could end up today using computers with the Microchip's PIC architecture family or something like that.

Thta's true, but in the 80's, price was very important, especially in Europe.

Quote:

Yes, the 65xx family is cheap, but very very limited for general-purpose computing. So limited that the 32 bit incarnation never went in production and even its creator suggested to use ARM processors if 32 bits are needed. Commodore, focusing on MOS, might have went to the bankrupt even before 1994.

MOS could have had manufactured other CPUs for Commodore(I believe they did manufacture some early 8088 for Commodore's line of PC compatibles).

_________________

Hammer Quote:

68060 has four bytes per cycle from the L1 instruction cache limitation which SysInfo easily crossed over. For example, two ADD.L $xxxx would trip over the 4-byte (32-bit) fetch limitation. AC68080's 16-byte (128-bit) fetch per cycle from the L1 instruction cache fixes this 68060's design flaw. Pentium has a 32-byte (256-bit) fetch per cycle from the L1 cache. By design, Motorola crippled 68060 relative to PowerPC 601's 256-bit fetch from the L1 cache. 68060 wouldn't be able to compete with Motorola's sabotage. 68K doesn't have a competent "AMD" cloner licensee insurance to enhance the original 68060 design against the wishes of the original CPU vendor i.e. Apollo-Core didn't exist in the 1990s.

I see you are still having trouble with the concept of a decoupled instruction fetch pipeline (IFP) and the major advantage it brings to provide consistent instruction delivery with a VLE and superscalar. Is it so unbelievable that a 4 byte/cycle fetch can feed a powerful superscalar 68060 that you believe it is a flaw that you keep harping on? If the 68060 operand execution pipelines (OEPs) were being starved of instructions, wouldn't it result in reduced superscalar (multi-issue) opportunities?

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)

These multi-issue rates are high, especially for an instruction starved CPU. I predict that these multi-issue rates are significantly higher than the Pentium which is why the 68060 has much better integer performance with the 68060 aided by a more orthogonal ISA. I predict this multi-issue rate is higher than most RISC CPUs too because load-to-use stalls greatly reduce multi-issue opportunities. Multi-issue data like this is rarely published for in-order CPU cores which is understandable because it would be embarrassing for most of them. The multi-issue rate is given for the similar ColdFireV5 that is based on the 68060 though.

https://www.nxp.com/docs/en/supporting-information/RPT68KFORUM.pdf Quote:

4-stage, 64-bit Instruction Fetch Pipeline ... Metric | Unit | V4 | V5 EffectiveCPI cycles/inst 1.42 1.05 BaseCPI cycles/inst 1.32 1.03 SS_Dispatches (pairs+triplets)/inst 0.28 0.64

ColdFireV5 was upgraded to a 64-bit fetch and has a 64% (pairs+triplets)/inst rate. ColdFire was mostly used for embedded use where the code would be recompiled giving targeted code. The 68060 average for targeted code is 58% (pairs+triplets)/inst rate. This is the same ballpark even though the ColdFireV5 is about 8 years newer with other modern advantages that may affect this result. Also, the ~6% difference in (pairs+triplets)/inst rate does not give 6% better performance.

https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/061505.pdf Quote:

Motorola’s goal is to provide high performance on existing binaries without recompilation. Based on traces of over three billion instructions, Circello expects the 68060 to issue 50%-60% of instructions in pairs. Figure 3 shows that issuing half the instructions in pairs results in a 33% performance increase due to superscalar issue; at 60%, the performance boost is 43%. These figures will be reduced due to cache misses and other overhead cycles, which are not improved by superscalar issue.

There may be better ways to increase the (pairs+triplets)/inst rate than increasing the instruction fetch to 8 bytes/cycle. Increasing the instruction buffer entries and OEPs to support 8 byte instructions would allow OPI.L #d32,(d16,An) superscalar execution. Then there are instructions like SWAP that are not superscalar executed for no apparent reason. These are not uncommon instructions and the limitations are completely arbitrary to reduce the 68060 to be more RISC like. ColdFire went further with removing support altogether for instructions longer than 6 bytes thus weakening the ISA performance potential as well as reducing orthogonality. The x86 and PPC ISAs and CPUs were heading in the opposite direction of beefing up performance.

Please stop harping on the "design flaw" of the 68060 4 byte/cycle fetch that likely makes a few percent performance difference at most. The design choice was a design decision. Engineering is the art of compromise. With upgrades, an 8 byte/cycle fetch becomes more worthwhile as was the case with the ColdFireV5. Just a 4 bytes/cycle fetch fed the powerful 68060 where most other CPUs could not be superscalar and an 8 byte/cycle fetch is enough to feed a memory munching monster of a 68060 upgrade. This is what an IFP design, which is a natural fit for a superscalar 68k CPU, and industry leading code density can do.

Hammer Quote:

Reminder, A1200/CD32 are desktop platforms.

CD32 was a console and the SBC was an embedded platform. As popular as the wedge designs were for CBM, SBC designs with optional external keyboards are more flexible as also exhibited by modular RPi hardware today. CBM almost survived to become what RPi is today but they failed to integrate and upgrade the chipset even though the 68k SoC they needed was a plan in their post bankruptcy documents.

Hammer Quote:

In real life, stock RPi 4B @ 1.8 Ghz or CM4 are within TDP specs when coupled with PiStorm and A1200 or A500. Installing RPi active cooling is for +2 Ghz overclocking e.g. my A1200's PiStorm32-CM4 has successful 2.2 Ghz overclocking. I could install a heatpipe linked with A1200's metal shield for passive cooling. My PiStorm32's CM4 adapter is purpose-designed with a fan header and A1200's breakout end-user I/O panel. 68000-based DragonBall VZ was pushed out of the smartphone market since ARMv4T. I also installed extra cooling for TF1260's 68060 rev1 overclocking attempts.

A 68060 core on modern silicon would likely draw mW of power, even if clocked up. Emulation is giving a fraction of the performance of native execution while using several times the power. Fans increase power used and increase system costs along with heat sinks and larger power supplies. This lowers the value and is the reason why emulation is rarely used in the embedded market.

Hammer Quote:

Good luck with the 3 Ghz 68060's scalar processing. LOL

The 68060 has superscalar scalar processing. Not all markets are high end and it would be difficult and expensive to try to compete in them. It is quite unnecessary anyway. All that is needed is a large enough market and being competitive in that market. The original RPi and RPi Zero have an ARM CPU that is less powerful than the 68060 yet millions of units have been sold. There have been millions of RPi Picos and RP2040 SoCs sold with only 133MHz CPU cores that are lower performance than the 68060 and lacking most modern CPU features. The SiFive U74 core is a similar superscalar design to the 68060 and a roughly comparable core, even lacking a SIMD unit. It has a similar IFP with only 8 byte/cycle fetch. The FPU latencies are worse than the 68060 and the core is not good for floating point without a SIMD either. It is a good simple design that minimizes stalls but it is primitive in many ways. A SoC using these CPU cores provides better performance than any 68k Amiga hardware and made less than $100 USD RISC-V SBCs possible despite limited RISC-V hardware demand and software. The 68k has a much larger game library and retro appeal. The 68k also makes a great little easy to program embedded CPU where it has proven success as the 16/32 bit king of the embedded market for well over a decade and perhaps two decades.


Hammer Quote:

Voodoo 4 didn't exist until October 2000's release. Unless you have a time machine, your counter-argument is not realistic.

I have a Voodoo 3 which gives roughly the same performance but the display output is better on the Voodoo 4. Earlier 3dfx hardware likely would have been enough to run Quake at acceptable fps as well. A 68060 based 3D console would have been in the late 1990s. Had CBM survived, CBM licenses the 68060 and adds 3dfx 3D tech to create an early floating point 3D based console instead of lower quality fixed point 3D hardware.

Hammer Quote:

Your Voodoo 4 PCI is bottlenecked by the slow 68060-75.

The Zorro III to PCI bottleneck is less than 10MiB/s. I overclocked my CSMK3 memory with the CPU using 50ns SIMMs with no wait states added. The CSMK3 still has good memory performance even compared to modern 68060 accelerators, some of which finally outperform it by a small margin. A 68060@100MHz would be better performance but it overclocks one of the CSMK3 chips which it is likely to burn out and the memory bus speed would need to be lower than the CPU speed. The CSMK3 does have 3 oscillator sockets and jumpers for clocking the CPU, memory and chipset separately but it wasn't designed for a 68060@100MHz like newer 68060 accelerators. As I recall, some of these newer 68060 accelerators can reach 60-70 MiB/s. This may limit PCI bandwidth somewhat if there wasn't a huge Zorro III to PCI bottleneck. Semi-powerful 68k Amigas were like Frankenstein's monster but now it is worse because the original hardware is temperamental and failing too. I wish there was a source of cheap 68k Amiga hardware like RPi hardware where if it fails, you just grab another SBC.

Hammer Quote:

On price and 3D gaming, Motorola ColdFire v5e wouldn't be able to beat Intel Celeron "Mendocino" and Coppermine-128.

The Celeron is low power for x86 but ColdFireV5e CPUs use a fraction of the power and transistors. No doubt the desktop Celeron is more powerful than an embedded ColdFireV5e. A 68060@100MHz with 180 DMIPS can play a surprising number of 3D games, especially with 3D hardware, so a ColdFireV5e@540MHz with 989 DMIPS should be able to play more with about 5.5 times the performance. This was a fully sythesizable ColdFireV5e core using auto layout circa 2002 (~130nm process). The question was not whether the ColdFireV5e could play 3D games at 100fps using 3D hardware but whether the resolution was high enough to satisfy gaming customers. There are always newer games pushing the envelope and it is not possible to support them all which takes an exponential amount of hardware and expense. There is demand for cheaper hardware and enough old games today that even a sub $100 USD SBC can play perhaps 75% of games ever made.

cdimauro Quote:

There's one problem: the zero page indexed addressing mode can only be used with the X register. So, you've to resort to the absolute indexed addressing modes which can use X and Y. It means that each LDA/ADC/STA instruction takes 3 bytes and 4 cycles each (one more if the address crosses the page).

Doh! Lack of orthogonality is a pain. It is easy enough to change the code to absolute accesses which actually removes the 6 INC/DEC instructions but it is like switching from local to global variables where the code is locked to a fixed memory location. This is bad coding practice where usually the opposite is recommended. Absolute addressing is not so bad for a 16-bit address space where it is undesirable for a 32-bit address space and very inefficient for a 64-bit address space. The absolute addresses are still extra code to fetch compared to what I wanted to do with the index registers which is one of the issues that I believe Lou overlooks. Also, I can see why compilers have trouble generating optimized code for the 6502.

cdimauro Quote:

43 bytes for the 6502: 12 * 3 + 7 * 1 bytes. It's also interesting to notice how many memory accesses are needed in its case.

Ok, so the instruction difference improves but the code size difference grows.

CPU | instructions | code size
6502 13 43
68000 7 16

Worse for memory accesses is not supporting larger datatypes. A 32-bit add with both numbers in memory is only 2 data accesses for the 68k instead of the 6502 12 data accesses.

cdimauro Quote:

What's sure is that he doesn't know coding...

Not everyone can assembly code the 6502. It requires patience and a good manual to look up all the non-orthogonal behavior.

Karlos Quote:

Somewhere on my long dead Seagate (pretty sure it could be recovered by a data recovery company) there's an experimental quake I was working on. It was identical to the software rendered right up to the point it actually has to draw stuff and uses Warp3D directly to render triangles and write the depth buffer. It was very unfinished and buggy but it was pretty quick at just drawing the world. This was specifically for BVision and it's limited capabilities. The pain points were texture management (which the GL version also has), but I managed to streamline some of that by putting lightmap textures into a tall thin (32 px) strip where possible. It's easier and more efficient to update them when they are like this because at 32 width, the sub patching isn't used and uploading the damage region becomes a linear copy and not a complex bunch of address permutations. You got to strip out all the hacky quake to GL stuff, the varying inefficiencies of Minimal on W3D and kept the ruthlessly optimised software 3D transformation and clipping. And you replaced the lowest level rasterization with hardware.

I worked on a different approach which was replacing the poorly optimized Warp3D libraries with optimized code although it is a very slow process. This may have been the problem you were trying to work around too. I only gained a couple of fps in Quake but the percentage gain is not bad. A much larger difference was seen in the OpenGL demos that were slide shows before and normal speed animations after due to the indirect method of rendering they used. Indirect rendering was removed in the next version of Warp3D but it actually worked well when optimized and multitasks much better than direct rendering. I think the PPC Warp3D had bugs they couldn't find as well as being poorly optimized so they gave up on it and removed it. Warp3D is a good example of closed source failure. The concept was good and the high level coding looked fine but the end code was a disaster of poorly optimized code and bugs. Only Amiga makes it impossible.

P.S.
Alain Thellier and I added software functions for missing hardware capabilities to improve compatibility. This is another good example of half effort development work by the developers sabotaging Warp3D. There never was an update of even bug fixes for the 68k Warp3D for which Alain I fixed several or an update to the latest version which Alain supported in his Wazp3D.

Last edited by matthey on 24-Aug-2024 at 02:15 AM.
Last edited by matthey on 24-Aug-2024 at 02:05 AM.

@cdimauro

Quote:

cdimauro wrote: @Lou Quote: But you can easily change it with your time machine, right?

Just as easily as a time machine will resurrect the Amiga platform.
Oh wait, apparently the 65XXX like still lives in the Mega65 with legal licenses from Cloanto...I guess time did tell indeed.

Quote:

Well, I am pleased to see you can read some directions and figured out how to link gifs...I was really worried about you!

Quote:

Quote: In the real world a general purpose computer doesn't use LUTs instead of proper math because the memory usage is onerous. You are getting hung up on CPU clock speed. What matters is memory cycles. 68000 Bcc takes 3 memory cycles when the branch is taken (2 when not) and has a range of +- 32k Bytes. The 6502 takes 4 cycles if the destination isn't on the same page, and 4-7 cycles if the distance is greater than +-128 bytes (Bcc + Bcc or JMP). No actually, I think you and other members are the ones getting hung up on clockspeed actually.

Actually you were the only one talking about (hypothetical) clocks. And the IPC/MIPS crappy measure.

Whereas you never think about combining them. IPC * clock = ? I leave it to you as homework.
[/quote]
Hilarious you are trying to tell me what I told you weeks ago as to why the 68000 cpu sucks.

Quote:

Quote: There were ways around that. For instance, the C128 offered an MMU that let you relocate the zero-page and stack pointer which let's you use the faster addressing modes. Eventually these features made it into extra registers like in the 65CE02's Z register addition. Here's an example on the C128: https://www.youtube.com/watch?v=u-ae8ZFZwaI Then show me how a Fibonacci's recursive implementation using it. And then measure it. I'm preparing other popcorns, in the meanwhile...

You're totally super cool linking a slideshow acting like a slideshow while missing the point of the slideshow completely. These are ZXSpectrum screens that he VIC-II can't handle. So for ZX fans that are also 128 fans...I guess it's a thing.
I know you're not smart and all, so I know you wouldn't know that an REU doesn't directly move memory to the VDC, only the CPU can. Again, you continue to display utter stupidity...when will you stop embarrassing yourself?
Here's one on a VDC with 16k. that does different fade-in fade-out effects. It's the same pictures as above but in a lower resolution to only show 1 vs the 4(2x2) ZXSpectrum screens shown in the other. I guess your too dumb to understand the point of a slideshow demo though. Par for the course.
https://www.youtube.com/watch?v=HIzgrL3l6Tc

Quote:

Once again, CPU clock speed doesn't matter. The fastest 6502 you could get in 1983 (when the Amiga was designed) was 3MHz. 3 x 2.47 = 7.41, 70% slower than a 12.5 MHz 68000 (introduced in 1982) even by your simplistic measure. But the Amiga used an 8 MHz 68000 throttled back to 7.09 MHz to match the memory cycle time, which was set by the video system.

LOL! Who had a 12Mhz 68000 in 1985? I think people are still waiting for that mythical 16Mhz version... The 68000 was so bad they rushed out a 68010 to fix their mistakes ... but by then everybody already foolishly ordered their 68000 work orders and coded workarounds. The money had been spent...then those workarounds became golden code...LOL! That's why --some-- stuff crashes when you replace the crappy 68000 with the improved 68010!

The SegaCD and Neo Geo were the only 12Mhz products released in 1990. Unaffordable in 1985. As we saw the TurboGraphx-16's 7+Mhz cpu in 1985 had no problem producing games of the same caliper.

Quote:

Smarter engineers chose the 68000 because the 6502 wasn't up to the task. Amiga OS 2+ comes on a 512kB ROM. Let's be generous and assume the 6502 would only need half the space. That still means a massive amount of bank switching just to execute the OS code. Add 1MB of RAM and you see the problem. Your poor little 6502 with its pathetic 256 byte zero page and tiny 256 byte stack would be chasing its tail all day long just trying to boot up!

LOL! Show me the developer who doesn't know how to work around such things and I'll show you a bad developer.

Show me the Amiga that launched with a 12Mhz 68000? Only the Megadrive/Genesis CD Quote:

Not needed: even a 7Mhz 68000 completely crashes the 65xx CRAProcessors when running any Amiga software, OS included.

Who's talking about time machines now? The 68000 was decided before Commodore ownership. The A1000 was a weak and almost unusable machine in stock form.

Quote:

Quote: In 1984 the, 20% more efficient than a 6502, 65C02 and 65816 were doing 4Mhz. Please, tell me where I can buy a time machine like your: https://en.wikipedia.org/wiki/WDC_65C816 Launched: 1985

https://en.wikipedia.org/wiki/WDC_65C02
Launch 1983. 65816 was developed in 1984 as merely a 16bit enhanced 65C02...and for Apple at that.
As for where to buy? WDC sells 65XXX products to this day. But for a more compete system with a 45Mhz cpu, here you go: https://mega65.org/

Quote:

Plus: https://en.wikipedia.org/wiki/MOS_Technology_6502 Max. CPU clock rate 1 MHz to 3 MHz

I know your level of stupidity you have isn't improving but...
A 3Mhz 6502 outperforms an 8 Mhz 68000. Amiga only had a 7.14 Mhz one.
In 1985 the turbographix16 had a 7.16 65C02.. Its like we're going in circles but when you're stupid I guess you forget the point you are trying to make isn't one you're winning. Commodore launched 7.14Mhz Amigas into 1990 until the unaffordable A3000 launch.

Quote:

Quote: A cheap MMU like in the C128 is all it takes to address stack and memory limitations. Sure. Then it should be very easy to use it and implement the above exercise, right?

I already linked a video on how it's done. I'm not wasting time on any requests from you who's shown no intelligence just as you won't bother going back to the last page or where I originally linked it. At this point - stupid may be a compliment.

Quote:

Quote: The 65816 can address 1MB without an MMU, Actually it's 16MB.

Wow, finally you found an actual slip-up from me when I meant the 65CE02 can access 1MB
The C128 was actually supposed to have 256k. The pads are there for the memory. It's a simple mod to turn a C128 into a C256. It's even supported in the 'bios'...
https://www.youtube.com/watch?v=Areq8K_ia9Y

Quote:

Quote: the A1000 launched with 256k. A lot of these arguments for the time are a mute point. They made the decisions they made because that's what they wanted, pre-Commodore. And because they had no time machine available...

Yes, looking at the market today, they will be judged by their decisions. Meanwhile, the C6X line lives on in a real licensed product today.

Quote:

Quote: Again, are we discussing the cpu or the platform? It depends: usually you compare entire platforms when it was talking only about CPUs, to show some advantage for your favourite CRAPprocessors. Now you do the opposite. So, as per YOUR CONVENIENCE...

You're the one that brought up the VDC when I mentioned the C128. Stupid is as stupid does. I suspect you did this because you couldn't win the cpu argument.

Quote:

Quote: Your Arch A3000 may have stunk to you due to lack of software support but in what I saw, it had great performance on what it offered. The ARM2 cpu was doing 8Mhz in 1986 and had an IPC of .5 (4 MIPS @ 8Mhz) which outperforms all Amigas until the Amiga 3000 out of the box. (Again - I ignore accelerators.) As per above: only because of YOUR CONVENIENCE. Quote: ARM3 was doing 25Mhz in 1989. Intel's 80486 did the same.

Yes, now you see what a poop decision pairing Amiga with a crappy 68000 was.... How about that time machine - eh?

Quote:

Quote: So again, I re-iterate: an Amiga launch with a 4Mhz 65816 would have eventually led to a move to ARM instead of the delayed over-priced and under-performing and late to the game Motorola poop-show followed by an attempt to move to the failed PPC line. I implore you: where I can get your time machine?

You can get it in the same place you get your delusional fantasies about the 68000 being a good cpu.

Quote:

Quote: Lou wrote: Still butt-hurt I see...

I thought you were much older. I guess you found your time machine after all!

Quote:

Quote: I only cared enough about the C900 to prove you wrong. No more. Ah, do you mean with the other slideshow that you've shown about it? There's also a video which shows it in action. Have you felt ashamed to share it? Here is it: https://www.youtube.com/watch?v=iYFQZyK3xSo A nice and slow... slideshow.

Quote:

Quote: a demo of a slide show that is a slide show .... somehow I'm supposed to be offended? You are not smart. Well, a smart people would have not provided the source of other big laughs.

You keep providing a lot of people with laughs. Me especially. I noticed eveyone else jumped off the cpu debate but apparently you're not smart enough so here we go:

Quote:

Quote: That's the most that you can get, since from the code it's clearly visible why: // copy bitmap (256x200=6400 bytes) from C128 RAM to VDC RAM VDC_BlitBitmap: [...] loop: lda $0000,y !: bit VDC_REG bpl !- sta VDC_DATA_REG iny bne loop inc loop+2 inx cpx #$19 bne loop rts The super slow copy operation from the CPU's RAM to the VDC's RAM. That's for transferring ONE byte at the time, but at the beginning you need to check the VDC's status bit, otherwise you interfere with it. In fact, you can only transfer data when it's NOT displaying something (e.g.: only during the vertical or horizontal blank period). That's why you can do very little with the VDC and it's not suitable for games: its memory is too limited for storing both the screen and the graphics assets, so you need to use the CPU's memory for them, but with this so slow operation. In short: USELESS CRAP. Quote: [quote] Oh really where's your time study? I've already reported on a previous comment. Goldfish syndrome?

Posting code isn't a time study.
Again, as per your 16k comment before/below, you're not smart enough to know many C128's have 64k of VDC ram...despite the fact that I linked you a cheap expansion showing how the RAM was directly wired to the gpu when you didn't think the VDC has DMA with it's own memory? You easily forget how dumb you are...

Quote:

Quote: Also - again, you display your complete and utter incompetence in all aspects of development. Well, actually I'm the only one which has shown something about development. You claimed to have written software for the C128, but you have provided not a single example neither the implementation of the simple exercise which I gave you. Guess why: you've no clue at all of software development.

LOL! I love your assumptions. But it also continues to expose your stupidity. I have described technical details about what makes those benchmarks useless and why an actual useful benchmark would expose the pathetic 68000's memory access speed.
I have shown you how many cycles the 68000 instructions take to execute.
I've shown you average IPC/Mhz and nothing is sinking in.
You are not smart. You should quit while you're behind.

Quote:

Quote: Assets are copied to the gpu's memory so that they can be reused as necessary. This is how programming all gpus work...unless you are in a shared-memory environment like the VIC-II and Amiga. Once in memory, you're just manipulating registers to do block-copying, etc. to do animation. When you turn on a C128, it literally dumps the 8k characterset ROM into the VDC's memory once regardless of what display mode you're in. That's done ONCE. Not every time it wants to display a character. How long did that take? This is not rocket science. You're not smart. Sure. And how much memory has the VDC? 16kB in TOTAL.

Stupid is as stupid keeps showing...

Quote:

Let me do a basic math. 8kB are wasted by this character table. 16 - 8 = 8kB (great math operation!) are left. Now let's assume that we've a 320x200 screen, which takes 8000 bytes. So, we've 8kB = 8192 - 8000 = 192 bytes left. Basically the only thing that you can do is drawing characters from this table to the screen. And only that!

Stupid is as stupid keeps showing us. 2nd revision C128's (including all C128DCR versions) came with 64K of VDC ram. It was also a common upgrade for the early ones....which is why I linked you that ram expander adapter some days ago. You are not smart. You literally can't put 2 and 2 together.

Quote:

[quote] Now let's take a look at what I was able to achieve with USA Racing (my car racing game) on a 1MB Amiga. It used 640 32x32 tiles with 32 colours = 480kB of memory only for that. The virtual screen for the player was 8192x65536 pixels wide, and it was scrolled on all directions at maximum speed of 800 pixels/s (on each direction) at rock solid 50FPS. Ah, the "slow" 68000 was doing a big part there, by moving such tiles from the Slow/Fast mem to the Chip mem (since 480kB of graphics only for the tiles cannot stay all in Chip mem). I've transferred the same technique to Fightin' Spirit, and that's the reason why it was able to move so much graphics for the big characters on the screen at 25FPS. Do the same with your crappy VDC, even using a REU.

Here is where you are full of lies. You used the blitter. You'd be a fool not to. If you did that with a 68000 then the Atari ST would be just as good a games machine. Thanks for the final proof!

@matthey

Quote:

matthey wrote: Lou Quote: Again, I'm not attacking 'Amiga' per say. I'm attacking the choice of cpu. A short-run decision gimped the platform in the long run. Perhaps he was blinded by 'marketing' at the time. Your statements defy intellect and history. The 68000 was one of the best performance MPUs in the early 1980s and was likely the best performance commodity MPU when introduced in 1979. The performance was just one advantage though. Jay Miner likely wanted and chose the 68000 because of features with one of the most important being a large flat address space. This feature alone was evolutionary and futuristic for a MPU in 1979. It was as evolutionary as the introduction of the low priced 6502 yet you blatantly ignore it even in hindsight while Jay Miner recognized it quickly before there were hardware implementations and correctly predicted the price would soon drop enough to use it and that engineering of a chipset should be started soon to take advantage of the opportunity. Lou Quote: Again, are we discussing the cpu or the platform? Your Arch A3000 may have stunk to you due to lack of software support but in what I saw, it had great performance on what it offered. The ARM2 cpu was doing 8Mhz in 1986 and had an IPC of .5 (4 MIPS @ 8Mhz) which outperforms all Amigas until the Amiga 3000 out of the box. (Again - I ignore accelerators.) ARM3 was doing 25Mhz in 1989. So again, I re-iterate: an Amiga launch with a 4Mhz 65816 would have eventually led to a move to ARM instead of the delayed over-priced and under-performing and late to the game Motorola poop-show followed by an attempt to move to the failed PPC line. You can argue that the Amiga should have had a 65816 which would have been cheaper than the 68000 and MOS/CSG could have potentially produced it, not that Amiga Corporation knew CBM would buy them. The 68000 was the better choice then and now though. The 68k Amiga would not be nearly as popular today without the large flat address space. The AmigaOS would be much more limited and less dynamic than it is. The 68k Amiga completely avoided the world of various kludge memory bank switching techniques on the 65816, 808x/x86, Z architectures, etc. It was the 80386 with large flat address space which allowed x86 to quickly catch up, despite baggage, 5 years after the 68000 was introduced. RISC architectures introduced in the mid-1980s often had large flat address spaces too although some had ISA flaws like ARM. Early Acorn RISC OS software is incompatible with later ARM CPUs because early ARM CPUs were not 32 bit clean (only supported 26 bits of addressing internally). Most Amiga software developed for the 16-bit 1979 68000 will run on a 32-bit 1994 68060. Code written for the 68000 will have better performance on the 68060 than 808x/186/286 code on a Pentium where compatibility is more challenging too. Motorola/Freescale certainly deserves some criticism for mistakes made with the 68020 ISA but the 68000 ISA was so good that it made this possible. If the 65816 was so good, there wouldn't be a need to move to another architecture. I'm not so sure RISC is the natural replacement for the 6502 accumulator architecture. ARM introduced performance handicaps which the 6502 did not have because of RISC. opa mem ; operation of mem to accumulator (3-4 cycles for zero page access) RISC separates memory accesses giving 2 instructions. ldr r4,mem ; load mem to register (3 cycles) op r5,r5,r4 ; reg to reg operation (1 cycle) ARM needs 2 instructions, 2 registers and 8 bytes of code to do the same work as the 6502 with 1 instruction, 1 register and less code. The 6502 minimum instruction cycles can be less too. Is this the worthy successor to the 6502? That was the original 3-stage ARM RISC pipeline but a deeper pipeline usually does not improve RISC performance as much as CISC performance. Let's take a look at the 5-stage ARM pipeline (ARM9TDMI for example). ldr r4,mem ; load mem to register (1 cycle) load-to-use stall (2 cycles) op r5,r5,r4 ; reg to reg operation (1 cycle) Load is finally 1 cycle but there is a 2 cycle load-to-use stall if the next instruction touches the result. This is still an improvement as two independent instructions can be placed between if possible. A two way superscalar CPU would need 4 independent instructions between. The popular Cortex-A53 is two way superscalar and the 8-stage pipeline has a 3 cycle load-to-use penalty so it needs 6 independent instructions between the load and an operation using the load. Load-to-use stalls are the great RISC performance killer as I've posted about before. A simulation in one paper showed that 8 GP registers without load-to-use stalls had better performance than 32 GP registers with a 2 cycle load-to-use stall. CISC pipelines usually avoided load-to-use stalls while ARM only has 14-15 GP registers (the PC is not GP while the link register is debatable). ARM Appendix Instruction Cycle Timings https://gab.wallawalla.edu/~curt.nelson/cptr380/textbook/advanced%20material/Appendix_B3.pdf The 6502 architecture is a simplified 6800 architecture. The 68000 has influences from the 6800 so is similar to the 6502 too. Many of the instruction mnemonics are the same like AND, ASL, Bcc, CMP, EOR, JMP, JSR, LSR, ROL, ROR, RTS and operate in a similar way with often more powerful options. Instead of only one accumulator and 2 index registers, the 68k is like having 8 accumulators (Data registers) and 8 index registers (address registers). The code more closely resembles 6502 code although a size should be specified and a register has to be specified . op.b mem,reg ; operation of mem to register (byte size) There is a single instruction now able to access multiple sized datatypes in a large flat address space using only a single register and without load-to-use stalls. The 68k needs a 7-8 stage pipeline and more hardware resources to make this efficient but the 68060 can execute cached operations like this in a single cycle including most addressing modes with no penalty. At the same time, it can execute another integer instruction in parallel. In my opinion, the 68k is closer to an upgraded 6800 or 6502 than RISC ISAs. It was also heavily influenced by the PDP-11. In case you missed my post in the other thread... http://bitsavers.trailing-edge.com/components/zilog/z80000/Z80000_CPU_Preliminary_Technical_Manual_Sep84.pdf P.S. Lou and Hammer should read the Z80000 manual linked above pages E-19 and E-20. The proper way to calculate millions of instructions per second (VAX MIPS) is shown which includes not just the average instruction latency but average pipeline delay, average addressing delay and average memory delay. The Z80000 average instruction execution cycles is 1.8 cycles but the average instruction cycles can increase to 2.5 to 4.0 cycles depending on the memory used. This is with 16 GP registers and a fully associative 256B unified cache with a 62% to 88% hit ratio. A 6502 with 3 registers and no cache is likely to have a hard time with the memory delay no matter how optimized the memory accesses are.

You can critique ARM and that's fine but it still won in the end.
The 65816 was good enough to take us into the 90's with the SNES and the SA-1 chip at 10+Mhz giving us better 16bit games than the Amiga could produce.
The TG-16 had a heck of a run thanks to all out raw speed.
Many of the SNES games actually ran at 2.67Mhz ... still enough to surpass a 7.14 Mhz 68000.

Again, I'm not a fan of the 65816 per say as I believe the 65CE02 is superior only lacking the memory addressing of the 65816. (1 MB vs 16 MB)...
You can watch a documentary on the Apple IIgs and how yields from the main supplier held Apple back on going faster than 4Mhz. Sanyo was able to produce 12Mhz versions without bugs but they weren't Apple's supplier. A shame really as many Apple die-hards preferred it to the black&white Mac.
I can send you a link if you want.

Last edited by Lou on 24-Aug-2024 at 01:19 AM.

@WolfToTheMoon

It would but the chipset design is little endian. They would have needed to design it from the ground u pas little endian. Which would have matched the previous Commodores. Even though the endian on 6502 is mostly pointer byte order. The one exception would be the CIA chips which are little endian, but with the somewhat wide register mapping for some reason, needing to access registers as only bytes means it wasn't a big issue.

@matthey

Quote:

I see you are still having trouble with the concept of a decoupled instruction fetch pipeline (IFP) and the major advantage it brings to provide consistent instruction delivery with a VLE and superscalar. Is it so unbelievable that a 4 byte/cycle fetch can feed a powerful superscalar 68060 that you believe it is a flaw that you keep harping on?

I'm not the only one i.e. AC68080 and Gunar says Hi.

Quote:

If the 68060 operand execution pipelines (OEPs) were being starved of instructions, wouldn't it result in reduced superscalar (multi-issue) opportunities?

SysInfo says hi since it easily tripped over 68060's 4 bytes (32-bit) fetch per cycle from the L1 instruction cache.

As a flagship for X86, the classic Pentium was replaced by the Pentium Pro (P6) in November 1995. The X86 competition wasn't frozen with a single microarchitecture design. Later P6 designs like Pentium III/Celeron Coppermine-128 reached the game console price range with the original Xbox.

For B2B, both Coppermine-128 and K7 Duron were offered for Xbox game consoles in the late 1990s. The original Xbox project was started in 1998.

Quote:

These multi-issue rates are high, especially for an instruction starved CPU. I predict that these multi-issue rates are significantly higher than the Pentium which is why the 68060 has much better integer performance with the 68060 aided by a more orthogonal ISA. I predict this multi-issue rate is higher than most RISC CPUs too because load-to-use stalls greatly reduce multi-issue opportunities. Multi-issue data like this is rarely published for in-order CPU cores which is understandable because it would be embarrassing for most of them. The multi-issue rate is given for the similar ColdFireV5 that is based on the 68060 though.

1. For this topic, price is a major factor. Jeff Porter selected MIPS-X-based SoC for performance vs cost reasons.

You can't even fit Motorola's 68060 cost policy into Commodore's mass-production model.

2. PS1's GTE major features are Multiply Matrix and Multiply Vector. GTE is accessed via COP0's co-processor op-codes. COP0 is modified from the original R3000A's COP0 design.

For Amiga Hombre, Commodore's PA-RISC implementation includes customized extensions for 3D.

For K6-2's 1998 release, AMD's 3DNow 64bit SIMD extension is customized for 3D and DSP. 3DNow includes instructions for 3D e.g. PFRCP (Packed floating-point reciprocal approximation), PFMUL (Packed floating-point multiplication), PFRSQRT (Packed floating-point reciprocal square root approximation). SSE's integer instructions were added to the original K7 Athlon and K7 Duron. 3DNow is optimized for Quake-like games e.g. Quake II with 3DNow support and DirectX6 geometry pipeline stage.

Intel introduced Streaming SIMD Extensions (SSE) in 1999's Pentium III release. Microsoft started the original Xbox "Midway" project in 1998 and AMD's K7 CPU was initially selected before Bill Gates overridden it for Intel's Coppermine-128. DirectX6 geometry pipeline stage supports Intel's SSE.

For the original Xbox, +700 Mhz clock speed is part of the compute power solution since it exploited the AMD vs Intel Ghz race.

Released in 1996, N64's cut-down R4000-based Reality Signal Processor (geometry) has a 128-bit vector unit @ 62.5 Mhz designed for 3D. 128-bit vector unit is accessed via COP2 (co-processor op-codes).

For 3D workloads, MC68060 is like a knife in a gunfight.

2. A 32-bit external bus is less optimal for workstation IEEE FP64 or 64-bit SIMD when compared to a 64-bit external bus competition.

Pentium has superior superscalar opportunities since the integer workload can be processed on two integers and FPU pipelines backed by 32 bytes (256 bit) per cycle from instruction L1 cache and 64-bit memory bus. PC's Tomb Raider used FPU.

Since 1995, Pentium servers/workstations have had access to PCI 2.1's 66 Mhz variant.

Pentium's 64-bit memory bus is prepared for X86's 64-bit SIMD extensions such as Intel's Pentium MMX and AMD's K6-2's 3DNow.

Pentium Pro (P6) introduces back-side and front-side external buses. Pentium Pro's L2 cache backside bus was later integrated into P6 Celeron Mendocino's on-chip L2 cache.

Due to 68040 bus limitations, 68060 doesn't have a dedicated backside L2 cache bus.

Certain PowerPC 604 implements a dual external bus when the second bus is used for the dedicated backside L2 cache.

For 3D workloads, MC68060 is like a knife in a gunfight.

Quote:

CD32 was a console and the SBC was an embedded platform. As popular as the wedge designs were for CBM, SBC designs with optional external keyboards are more flexible as also exhibited by modular RPi hardware today. CBM almost survived to become what RPi is today but they failed to integrate and upgrade the chipset even though the 68k SoC they needed was a plan in their post bankruptcy documents.

Wrong. Amiga's core market is games. Lew's Commodore combines "workstation graphics for the masses" and "cheap RISC" ideologies.

CD32 is still an Amiga 1200 with desktop capability i.e. CD32 is a desktop game console. Modern game consoles have access to MS Office 365, keyboard and mouse support.

Unlike other game consoles, CD32 is capable of being extended into Commodore Canada/Amitech's A2200-1/A2200-2 clone which duplicates most of the A4000 (e.g. multiple Zorro slots, CPU local slot) and A1200 (CPU local edge connector) expansion capability.

CD32 is not a normal SBC due to desktop and workstation scaling in its design. Vampire SA4 doesn't duplicate A1200/CD32's Commodore-Amiga unique expansion characteristics. Vampire SA4 is a dead end as a mobile phone.

Game consoles differ themselves since they require high compute performance over embedded microcontrollers.

Game consoles differ from desktop PCs due to major cost constraints but there is a merger between modern gaming PCs and desktop game consoles.

For Amiga Hombre, Nathaniel (includes the CPU with 3D extensions, Blitter texture fill) has access to the 32-bit system and 64-bit video memory bus which is a 96-bit bus.

Nathaniel implements a dual-bus approach.

Amiga Hombre's Nathaniel would be closer to AMD's APU concept which includes multiple memory bus controllers.

The designer for C65's CPU was hired by AMD and moved to the K7 Athlon team. MOS's 65xx CPU has the double-rate processing skillset and K7 has a double-rate 64-bit front side bus. 65xx CPU's double-rate processing skillset was assimilated by AMD.

Due to high math compute performance requirements, game consoles and smartphones have separated from the general embedded market.

For 3D workloads, MC68060 is like a knife in a gunfight.

AMD's K7 had "double rate" front-side bus tech before Pentium III or PowerPC G3/G4.

DEC Alpha 21264 had the original double-rate EV6 bus design in October 1996.

RPi only has a "cheap RISC" approach which lacks the "workstation graphics for the masses" approach.

Lew's "workstation graphics for the masses" approach was continued by AMD and NVIDIA. Intel, Apple, and Qualcomm are the next lower tier.

As mentioned in Commodore - The Final Years, many Commodore engineers move to SGI and 3DO.

SGI's graphics business unit was later transferred to NVIDIA.

ArtX and 3DFX are SGI rebels who wanted "workstation graphics for the masses".

ArtX was assimulated by ATI which in turn was assimulated by AMD. ArtX's engineers were responsible for N64's and Game Cube's graphics design and major contribution to SIMD-based Radeon 9700. Xbox 360's Xenos remained in SIMD GpGPU design while PC's Radeon HD went VLIW designs until SIMD-based Graphics Core Next. AMD ditched VLIW-based GPU designs due to driver optimization difficulty.

Gaming PC's NVIDIA defeated other workstation graphics vendors, but AMD remained dominant in desktop game consoles and handheld gaming PCs.

AMD has Lew's "cheap/high compute power" and "workstation graphics for masses" approach, NOT RPi.

RPi wouldn't be able to beat Valve's SteamDeck's $294 price for a handheld gaming PC.

The only reason for RPi inside the Amiga is due to enhancing retro Amigas at a low cost without Commodore-Amiga Inc.

SteamDeck's $294 price will run WinUAE faster than Emu68 with RPi CM4 and run Genshin Impact at PC's max graphics details at 1080p/60 hz.

Quote:

Please stop harping on the "design flaw" of the 68060 4 byte/cycle fetch that likely makes a few percent performance difference at most.

Wrong. Refer to AC68080 vs MC68060.

AC68080 has two integer execution engines like MC68060.

Quote:

The design choice was a design decision. Engineering is the art of compromise. With upgrades, an 8 byte/cycle fetch becomes more worthwhile as was the case with the ColdFireV5.

68040 has 8 bytes per cycle fetch from L1 cache.

https://www.design-reuse.com/news/4126/motorola-generation-superscalar-32-bit-coldfire-microprocessor-core.html
Motorola 0.13 micron ColdFire V5 reaches 333 MHz.

The fastest ColdFire V5 was seen to be 540 MHz.

Using Motorola licensed 0.13 micron process node, AMD Athlon 64 FX-55 Clawhammer CG stepping reached 2.6 Ghz.

Motorola's 0.13 micron PowerPC 7447 (1600 Mhz) and 7457 (1267 Mhz) didn't reach the same speed as AMD's FX-55's 2.6 Ghz.

IBM's 0.13 micron PowerPC 970 reached 2.0 Ghz. PowerPC 970FX switches to 90 nm process node.

At 90 nm process node, MPC 7448 reached 1.7 Ghz while Athlon 64 X2 6400+ (F3)
Black Edition reached 3.2 Ghz and PowerPC 970FX reached 2.7 Ghz.

AMD Bulldozer and Intel Pentium IV are designed for very high clock speeds at the expense of IPC.

AMD licensed process tech from Motorola. https://www.cnet.com/tech/tech-industry/motorola-ready-to-make-amd-chips/


Quote:

Just a 4 bytes/cycle fetch fed the powerful 68060 where most other CPUs could not be superscalar and an 8 byte/cycle fetch is enough to feed a memory munching monster of a 68060 upgrade. This is what an IFP design, which is a natural fit for a superscalar 68k CPU, and industry leading code density can do.

That requires 68060 design changes.

Quote:

The 68060 has superscalar scalar processing. Not all markets are high end and it would be difficult and expensive to try to compete in them. It is quite unnecessary anyway. All that is needed is a large enough market and being competitive in that market. The original RPi and RPi Zero have an ARM CPU that is less powerful than the 68060 yet millions of units have been sold.

The key idea with RPi's business model is operational low-cost SBC, not just CPU or SOC.

For end users, Broadcom SOC is not useful without RPi's value-added factors e.g. RPi small form factor design, documentation, and support.

Broadcom provided bare-metal software libraries for Emu68's foundation.

RPi's main innovation is the low-cost mainboard platform instead of chasing PC's ATX/ITX standards. Amiga PowerPC camp chased after PC's ATX/ITX standards instead of solving the cost of entry issue.

These foundation factors enabled Emu68 with PiStorm.

I have a spare 68LC060 rev 4 and it's useless without a platform.

I can buy a cheap Power8 or Power9 CPU, but without a cheap platform, it's useless.

Amiga's value added is the platform beyond just the 680x0 CPU.

Quote:

There have been millions of RPi Picos and RP2040 SoCs sold with only 133MHz CPU cores that are lower performance than the 68060 and lacking most modern CPU features. The SiFive U74 core is a similar superscalar design to the 68060 and a roughly comparable core, even lacking a SIMD unit. It has a similar IFP with only 8 byte/cycle fetch. The FPU latencies are worse than the 68060 and the core is not good for floating point without a SIMD either. It is a good simple design that minimizes stalls but it is primitive in many ways. A SoC using these CPU cores provides better performance than any 68k Amiga hardware and made less than $100 USD RISC-V SBCs possible despite limited RISC-V hardware demand and software. The 68k has a much larger game library and retro appeal. The 68k also makes a great little easy to program embedded CPU where it has proven success as the 16/32 bit king of the embedded market for well over a decade and perhaps two decades.

There's more than just selling CPUs or SoCs and providing basic ISA documentation.

RPi started by selling Broadcom SOC with a cheap mainboard business model before they ventured into rolling their cut-and-paste engineered SoC. There are other factors beyond the silicon hardware.

Apollo-Core (located in Germany, EU) already has an AC68080 in FPGA design and the next step is problematic.

Specific business development and funding plans are beyond the scope of this topic.

https://www.thinkingaheadinstitute.org/content/uploads/2021/02/GPAS__2021.pdf
Pension funds vs GDP ratio for an investing strength indicator.

Five Eyes/Five Passport Group:
Australia, $2,333 billion, 174.8%
Canada, $3,080 billion, 192.5%
United Kingdom, $3,564 billion, 135.1%
United States, $32,567 billion, 156.5%


EU:
Finland, $279 billion, 104.3%
France, $166 billion, 6.5%
Germany, $548 billion, 14.5%
Italy, $231 billion, 12.5%
Netherlands, $1,900 billion, 214.4%,
Ireland, $197 billion, 49.4%
Spain, $44 billion, 3.6%


Non-EU:
Switzerland, $1,163 billion, 164.3%


USMCA:
Mexico, $259 billion, 24.9%
Canada, $3,080 billion, 192.5%
United States, $32,567 billion, 156.5%


East Asia, South East Asia:
China, $285 billion, 1.9% (not including state-owned investments)
Hong Kong, $199 billion, 58.3%
Japan, $3,613 billion, 73.6%
South Korea, $968 billion, 61.0%
Malaysia, $279 billion, 83.0%

Pension fund policies from Five Eye and Nordic groups enable strong venture capitalist capabilities.

Last edited by Hammer on 24-Aug-2024 at 05:20 AM.
Last edited by Hammer on 24-Aug-2024 at 05:13 AM.
Last edited by Hammer on 24-Aug-2024 at 03:40 AM.
Last edited by Hammer on 24-Aug-2024 at 03:28 AM.
Last edited by Hammer on 24-Aug-2024 at 03:21 AM.

_________________

@matthey


Quote:

@matthey I have a Voodoo 3 which gives roughly the same performance but the display output is better on the Voodoo 4. Earlier 3dfx hardware likely would have been enough to run Quake at acceptable fps as well. A 68060 based 3D console would have been in the late 1990s. Had CBM survived, CBM licenses the 68060 and adds 3dfx 3D tech to create an early floating point 3D based console instead of lower quality fixed point 3D hardware.

Wrong. Amiga Hombre's two chips have a 1 million transistors budget that includes a CPU with 3D extensions, texture mapper/raster-ops, Copper, 2D display, audio, DMA CD-ROM controller and 'etc'.

3DFX's Voodoo 1 price is not at the game console level. Voodoo's 1 million transistors don't include the CPU and are already a two-chip solution without factoring the video DAC. Voodoo's 1 million transistors is not a fully operational computer.

Lew's Commodore plans to license a 68020 CPU and there is a 68020 license cloner.

Dave Haynie's Acutiator is designed to accept three RISC CPUs (with big-endian PA-RISC being one of them) and 68EC040. Acutiator's custom chipset includes a requirement to operate 68EC040.

Amiga Hombre game console is based on PA-RISC.


Quote:

From Commodore - The Final Years, And because AAA was designed to work with different processor families, Haynie wanted his Acutiator motherboard to also handle different processors. Specifically, there were at least three major RISC processor families at that time and he wanted Acutiator to accept these RISC chips. Their architecture required three custom chips: EPIC, AMOS, and SAIL. In cost comparisons, Haynie calculated that the Acutiator architecture would add approximately $125 to a system (including the cost of a 68EC040 chip),

68EC040-25 has about $100 cost, hence Acutiator chipset has $25 cost. This is just the extra glue for the 68EC040 CPU to Amibus's Amiga chipset side which can be AAA or AA or AA+.

Amiga Hombre's two chips has $40 cost.

Acutiator prepares for Amiga Hombre and A1200 SoC glue.

Quote:

@matthey The Zorro III to PCI bottleneck is less than 10MiB/s. I overclocked my CSMK3 memory with the CPU using 50ns SIMMs with no wait states added.

50ns access is not a read/write cycle.

A1200's FP DRAM has 80 ns access with a 140 ns read/write cycle (7.1 Mhz effective).

Nathaniel (which contains a custom PA-RISC) has direct access to dual memory bus design i.e. system (e.g. larger memory storage DRAM) and video memory (e.g. smaller memory
storage and faster VRAM). This is similar to 3DO MADAM's hybrid dual memory bus design.
The lessons from "Super A500".

3DO's VRAM has 20 ns serial/sequential access.

Nathaniel (3D extended custom PA-RISC, Blitter texture mapper, Blitter raster-ops, memory copier, Copper) includes
32-bit PCI interface,
32-bit DRAM interface,
64-bit VRAM interface.

Amiga Homber Nathaniel is closer to the modern AMD APU designs e.g. four 32-bit DDR5 memory interfaces and 28 PCIe lanes.

68060's single 32-bit external bus is 68040 dated.

Quote:

@matthey The CSMK3 still has good memory performance even compared to modern 68060 accelerators, some of which finally outperform it by a small margin. A 68060@100MHz would be better performance but it overclocks one of the CSMK3 chips which it is likely to burn out and the memory bus speed would need to be lower than the CPU speed. The CSMK3 does have 3 oscillator sockets and jumpers for clocking the CPU, memory and chipset separately but it wasn't designed for a 68060@100MHz like newer 68060 accelerators. As I recall, some of these newer 68060 accelerators can reach 60-70 MiB/s. This may limit PCI bandwidth somewhat if there wasn't a huge Zorro III to PCI bottleneck. Semi-powerful 68k Amigas were like Frankenstein's monster but now it is worse because the original hardware is temperamental and failing too. I wish there was a source of cheap 68k Amiga hardware like RPi hardware where if it fails, you just grab another SBC.

CSMK3 is an expensive design.

Last edited by Hammer on 24-Aug-2024 at 06:53 AM.

_________________

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @cdimauro Quote: If you take into account only the price, then we could end up today using computers with the Microchip's PIC architecture family or something like that. Thta's true, but in the 80's, price was very important, especially in Europe.

And price was also important depending on the specific market segment.

Cheap home computers -> 65xx was fine.

More expensive personal computers -> 65xx was not the good choice.
Quote:

Quote: Yes, the 65xx family is cheap, but very very limited for general-purpose computing. So limited that the 32 bit incarnation never went in production and even its creator suggested to use ARM processors if 32 bits are needed. Commodore, focusing on MOS, might have went to the bankrupt even before 1994. MOS could have had manufactured other CPUs for Commodore(I believe they did manufacture some early 8088 for Commodore's line of PC compatibles).

With which fab process? Fabs need to be modernized and you need to invest money on them, which Jack hasn't done, so a lot of time was wasted here.

After that Jack left then fortunately there were some investments with newer processes, albeit not on par with the other silicon companies.

@matthey

Quote:

matthey wrote: cdimauro Quote: There's one problem: the zero page indexed addressing mode can only be used with the X register. So, you've to resort to the absolute indexed addressing modes which can use X and Y. It means that each LDA/ADC/STA instruction takes 3 bytes and 4 cycles each (one more if the address crosses the page). Doh! Lack of orthogonality is a pain. It is easy enough to change the code to absolute accesses which actually removes the 6 INC/DEC instructions but it is like switching from local to global variables where the code is locked to a fixed memory location. This is bad coding practice where usually the opposite is recommended.

Exactly. If you want to make the code reusable and not locked to a fixed location, then you need to use pointers. And here... well, goodbye 6502!
Quote:

Absolute addressing is not so bad for a 16-bit address space where it is undesirable for a 32-bit address space and very inefficient for a 64-bit address space.

Right, but the 65xx family only had a 16-bit address space, whatever the variant it was: 8, 16, or 32 bit. everything beyond 16-bit addresses was done using the infamous bank switching, which of course killed the performance with more general purpose code.
Quote:

The absolute addresses are still extra code to fetch compared to what I wanted to do with the index registers which is one of the issues that I believe Lou overlooks.

Well, he doesn't overlook: it simply ignores everything which puts his beloved 6502 in a bad shape (which means: almost always with general purpose code).
Quote:

Also, I can see why compilers have trouble generating optimized code for the 6502.

Compiler support for the 6502 wasn't really a problem, because the domain for this processor is the embedded & earlier consoles world, where you usually write assembly code which has to set registers on the hardware. So, you don't need great computation power neither high-level code.
Quote:

cdimauro Quote: 43 bytes for the 6502: 12 * 3 + 7 * 1 bytes. It's also interesting to notice how many memory accesses are needed in its case. Ok, so the instruction difference improves but the code size difference grows. CPU | instructions | code size 6502 13 43 68000 7 16 Worse for memory accesses is not supporting larger datatypes. A 32-bit add with both numbers in memory is only 2 data accesses for the 68k instead of the 6502 12 data accesses.

Right. Now think about the floating point implementation: adding two FP numbers, like it was done one Commodore's BASICs of the time.

Why those BASICs were so slow? It's enough to take a look at their disassembled code and see how pages and pages of instructions are needed for the 6510/8502.

@Lou

Quote:

Lou wrote: @cdimauro Quote: cdimauro wrote: @Lou [quote] But you can easily change it with your time machine, right?

Just as easily as a time machine will resurrect the Amiga platform.
Oh wait, apparently the 65XXX like still lives in the Mega65 with legal licenses from Cloanto...I guess time did tell indeed.[/quote]
I reveal you a secret: the Amiga platform is still alive, and Cloanto is heavily contributing to it as well...
Quote:

Quote: Well, I am pleased to see you can read some directions and figured out how to link gifs...I was really worried about you!

At least I can do something...
Quote:

Quote: Actually you were the only one talking about (hypothetical) clocks. And the IPC/MIPS crappy measure. Whereas you never think about combining them. IPC * clock = ? I leave it to you as homework. Hilarious you are trying to tell me what I told you weeks ago as to why the 68000 cpu sucks.

I reveal you another secret: it doesn't suck only because YOU, which are mr. nobody, said it.

Actually on pure calculations the 68000 simply destroys your beloved 65xx.
Quote:

Quote: Then show me how a Fibonacci's recursive implementation using it. And then measure it. I'm preparing other popcorns, in the meanwhile... You're totally super cool linking a slideshow acting like a slideshow while missing the point of the slideshow completely. These are ZXSpectrum screens that he VIC-II can't handle. So for ZX fans that are also 128 fans...I guess it's a thing. I know you're not smart and all, so I know you wouldn't know that an REU doesn't directly move memory to the VDC, only the CPU can. Again, you continue to display utter stupidity...when will you stop embarrassing yourself? Here's one on a VDC with 16k. that does different fade-in fade-out effects. It's the same pictures as above but in a lower resolution to only show 1 vs the 4(2x2) ZXSpectrum screens shown in the other. I guess your too dumb to understand the point of a slideshow demo though. Par for the course. https://www.youtube.com/watch?v=HIzgrL3l6Tc

ROFL. Here the discussion was about the STACK RELOCATION ON C128. I've asked you one the most simple example, Fibonacci, implemented using it, and what you do: talk of completely different things.

Genious!

Anyway, you provided another slow and low-resolution example that shows how CRAPPY is the VDC. Thanks again.
Quote:

Quote: Once again, CPU clock speed doesn't matter. The fastest 6502 you could get in 1983 (when the Amiga was designed) was 3MHz. 3 x 2.47 = 7.41, 70% slower than a 12.5 MHz 68000 (introduced in 1982) even by your simplistic measure. But the Amiga used an 8 MHz 68000 throttled back to 7.09 MHz to match the memory cycle time, which was set by the video system. LOL! Who had a 12Mhz 68000 in 1985? I think people are still waiting for that mythical 16Mhz version... The 68000 was so bad they rushed out a 68010 to fix their mistakes ... but by then everybody already foolishly ordered their 68000 work orders and coded workarounds. The money had been spent...then those workarounds became golden code...LOL! That's why --some-- stuff crashes when you replace the crappy 68000 with the improved 68010! The SegaCD and Neo Geo were the only 12Mhz products released in 1990. Unaffordable in 1985. As we saw the TurboGraphx-16's 7+Mhz cpu in 1985 had no problem producing games of the same caliper. Quote: Smarter engineers chose the 68000 because the 6502 wasn't up to the task. Amiga OS 2+ comes on a 512kB ROM. Let's be generous and assume the 6502 would only need half the space. That still means a massive amount of bank switching just to execute the OS code. Add 1MB of RAM and you see the problem. Your poor little 6502 with its pathetic 256 byte zero page and tiny 256 byte stack would be chasing its tail all day long just trying to boot up! LOL! Show me the developer who doesn't know how to work around such things and I'll show you a bad developer. Show me the Amiga that launched with a 12Mhz 68000? Only the Megadrive/Genesis CD

ROFL again: this text was coming from Bruce's post and you ALREAD had a discussion with him. Premature Alzaimer?
Quote:

Quote: Not needed: even a 7Mhz 68000 completely crashes the 65xx CRAProcessors when running any Amiga software, OS included. Who's talking about time machines now?

SOFTWARE. Do you understand the meaning of the word?

And the context? The assumption was to have an Amiga with your crappy 65xx processors.

So, to sum it up, the Amiga OS and its software were supposed to be developed for the 65xx.
Quote:

The 68000 was decided before Commodore ownership.

Fortunately.
Quote:

The A1000 was a weak and almost unusable machine in stock form.

LOL. I don't even comment here.
Quote:

Quote: Please, tell me where I can buy a time machine like your: https://en.wikipedia.org/wiki/WDC_65C816 Launched: 1985 https://en.wikipedia.org/wiki/WDC_65C02 Launch 1983.

Which I haven't talk about, right?
Quote:

65816 was developed in 1984 as merely a 16bit enhanced 65C02...and for Apple at that.

LAUNCHED: 1985. So, NOT available on 1984. Do you understand it?
Quote:

As for where to buy? WDC sells 65XXX products to this day. But for a more compete system with a 45Mhz cpu, here you go: https://mega65.org/

Irrelevant.
Quote:

Quote: Plus: https://en.wikipedia.org/wiki/MOS_Technology_6502 Max. CPU clock rate 1 MHz to 3 MHz I know your level of stupidity you have isn't improving but...

Only because YOU said? I believe you, I believe you.
Quote:

A 3Mhz 6502 outperforms an 8 Mhz 68000. Amiga only had a 7.14 Mhz one.

Ah, yes. I see how good it performed on the Byte Sieve benchmark.
Quote:

In 1985 the turbographix16 had a 7.16 65C02..

Guess what: an entire machine now...
Quote:

Its like we're going in circles but when you're stupid I guess you forget the point you are trying to make isn't one you're winning.

And I trust you, only because YOU said it. Sure.
Quote:

Commodore launched 7.14Mhz Amigas into 1990 until the unaffordable A3000 launch.

Your ignorance is embarrassing: https://en.wikipedia.org/w/index.php?title=Amiga_2000&safemode=1#amiga2500
Quote:

Quote: Sure. Then it should be very easy to use it and implement the above exercise, right? I already linked a video on how it's done.

The video was showing how to use the stack and zero page relocation.
Quote:

I'm not wasting time on any requests from you who's shown no intelligence just as you won't bother going back to the last page or where I originally linked it. At this point - stupid may be a compliment.

OK, let's keep it simple, and I don't repeat again the same things, because I had enough to make jokes against you. Just: see above.
Quote:

Quote: The 65816 can address 1MB without an MMU, Actually it's 16MB.

Wow, finally you found an actual slip-up from me when I meant the 65CE02 can access 1MB[/quote]
Well, it's not the first time and you show to don't know even fundamental things of what you talk about...
Quote:

The C128 was actually supposed to have 256k. The pads are there for the memory. It's a simple mod to turn a C128 into a C256. It's even supported in the 'bios'... https://www.youtube.com/watch?v=Areq8K_ia9Y

What's not clear to you that I had a C128 and I know it very well, included its expansions (VDC too, of course)?
Quote:

Quote: [quote]the A1000 launched with 256k. A lot of these arguments for the time are a mute point. They made the decisions they made because that's what they wanted, pre-Commodore. And because they had no time machine available...

Yes, looking at the market today, they will be judged by their decisions.[/quote]
9 years aren't enough for you?
Quote:

Meanwhile, the C6X line lives on in a real licensed product today.

Same as above: same for the Amiga.
Quote:

Quote: It depends: usually you compare entire platforms when it was talking only about CPUs, to show some advantage for your favourite CRAPprocessors. Now you do the opposite. So, as per YOUR CONVENIENCE... You're the one that brought up the VDC when I mentioned the C128.

At the RIGHT context.
Quote:

Stupid is as stupid does.

Stupid people don't understand discussions and how they evolve.
Quote:

I suspect you did this because you couldn't win the cpu argument.

Actually it was proven several times how 65xx sucked compared to a simple 68000. Whereas you never provided evidence of the opposite...
Quote:

Quote: As per above: only because of YOUR CONVENIENCE. [quote]ARM3 was doing 25Mhz in 1989. Intel's 80486 did the same.

Yes, now you see what a poop decision pairing Amiga with a crappy 68000 was.... How about that time machine - eh?[/quote]
Not needed: the 68040 followed the next year and crashed all ARMs.

It's only the 80486 which just did the same, one year before.
Quote:

Quote: So again, I re-iterate: an Amiga launch with a 4Mhz 65816 would have eventually led to a move to ARM instead of the delayed over-priced and under-performing and late to the game Motorola poop-show followed by an attempt to move to the failed PPC line. I implore you: where I can get your time machine?

You can get it in the same place you get your delusional fantasies about the 68000 being a good cpu.[/quote]
Same as above: I believe you, yes...
Quote:

Quote: Ah, do you mean with the other slideshow that you've shown about it? There's also a video which shows it in action. Have you felt ashamed to share it? Here is it: https://www.youtube.com/watch?v=iYFQZyK3xSo A nice and slow... slideshow. Quote: Well, a smart people would have not provided the source of other big laughs. You keep providing a lot of people with laughs. Me especially. I noticed eveyone else jumped off the cpu debate but apparently you're not smart enough so here we go:

Actually OTHER people jumped in, and you were not able to contrast the results.

Which is an impossible mission for you.
Quote:

Quote: I've already reported on a previous comment. Goldfish syndrome? Posting code isn't a time study.

I haven't posted the code, but reported such information from the forum that YOU have share. Goldfish...
Quote:

Again, as per your 16k comment before/below, you're not smart enough to know many C128's have 64k of VDC ram...

See above: already answered.
Quote:

despite the fact that I linked you a cheap expansion showing how the RAM was directly wired to the gpu

Sure, you have WIRE an external expansion to the VDC. Easy task, yes.
Quote:

when you didn't think the VDC has DMA with it's own memory? You easily forget how dumb you are...

Care to PROVE it? Since I NEVER talked about it, dear liar.
Quote:

Quote: Well, actually I'm the only one which has shown something about development. You claimed to have written software for the C128, but you have provided not a single example neither the implementation of the simple exercise which I gave you. Guess why: you've no clue at all of software development. LOL! I love your assumptions. But it also continues to expose your stupidity. I have described technical details about what makes those benchmarks useless and why an actual useful benchmark would expose the pathetic 68000's memory access speed. I have shown you how many cycles the 68000 instructions take to execute. I've shown you average IPC/Mhz and nothing is sinking in. You are not smart. You should quit while you're behind.

Repeating the same CRAP all the times doesn't make it true.

Actually the only numbers are coming from Byte Sieve, where we've seen how "good" was the 6502.
Quote:

Quote: Sure. And how much memory has the VDC? 16kB in TOTAL. Stupid is as stupid keeps showing...

Numbers MATTER, dear LIAR.
Quote:

Quote: Let me do a basic math. 8kB are wasted by this character table. 16 - 8 = 8kB (great math operation!) are left. Now let's assume that we've a 320x200 screen, which takes 8000 bytes. So, we've 8kB = 8192 - 8000 = 192 bytes left. Basically the only thing that you can do is drawing characters from this table to the screen. And only that! Stupid is as stupid keeps showing us. 2nd revision C128's (including all C128DCR versions) came with 64K of VDC ram. It was also a common upgrade for the early ones....which is why I linked you that ram expander adapter some days ago. You are not smart. You literally can't put 2 and 2 together.

Again, NOT for ALL C128.

The normal C128 which was widespread had only 16kB for the VDC. Dot.
Quote:

Quote: Now let's take a look at what I was able to achieve with USA Racing (my car racing game) on a 1MB Amiga. It used 640 32x32 tiles with 32 colours = 480kB of memory only for that. The virtual screen for the player was 8192x65536 pixels wide, and it was scrolled on all directions at maximum speed of 800 pixels/s (on each direction) at rock solid 50FPS. Ah, the "slow" 68000 was doing a big part there, by moving such tiles from the Slow/Fast mem to the Chip mem (since 480kB of graphics only for the tiles cannot stay all in Chip mem). I've transferred the same technique to Fightin' Spirit, and that's the reason why it was able to move so much graphics for the big characters on the screen at 25FPS. Do the same with your crappy VDC, even using a REU. Here is where you are full of lies. You used the blitter. You'd be a fool not to. If you did that with a 68000 then the Atari ST would be just as good a games machine. Thanks for the final proof

Hopeless, I've written this:

the "slow" 68000 was doing a big part there

You have not even basic understand of what people write.

P.S. Not time to fix the layout. I'll not waste other time on that.

@Lou

Like Z8000 and 80286, 65K's 16-bit memory segmentation model is brain-dead. I prefer 68K over 65K.

IPC is an implementation issue.

Operating systems with 32-bit 68K led to other 32-bit capable RISC CPUs with flat memory models.

Microsoft's Windows NT roadmap is a 32-bit CPU with a flat memory model.

GUI MS Excel and MS Word are programmed for Mac 68K, leading Bill Gates to label the 286 as brain-dead.

68030 has 0.5 IPC for ADD instructions, which is okay, but I prefer MUL and other 3D-related instructions i.e. combine the attributes from DSP56K with 68030 for lower cost 68030M variant i.e. optimized for MUL instructions. MIPS camp attacked 68020/68030's weakness with MUL-related instructions. ARM had ARMv3M i.e. MUL optimized ARM6 variant.

It's 3DO's fault for selecting a cheap ARM60 with ARMv3 ISA.

The "average IPC" argument hides specific instructions for 3D workloads.

Again, IPC is an implementation issue.

68040 and 68LC040 are mostly pricing issues.

68EC040 is a support chips issue.

If you look at AMD's 3DNow instruction set as an example, they are targeted for 3D.

My argument is a 3D-optimised full 32-bit 68K lower cost variant i.e. 68030M with "3DNow" like focus, hence this is a management issue. I'm paranoid about MIPS.

Last edited by Hammer on 25-Aug-2024 at 02:55 PM.

_________________

@Hammer

Quote:

ike Z8000 and 80286, 65K's 16-bit memory segmentation model is brain-dead. I prefer 68K over 65K.

For a computer's success on the market and adoption, that is irrelevant.

I've said this before, I'll say it again... Amiga 1000 was a failure, sales wise. The main reason was there was no software and it was expensive, relatively speaking, compared to the 8bit systems at the time. Nobody who was buying a home computer at the time cared for memory segmentation - nobody! They cared about price and software, in that order.

Had C= invested in a 16/32 bit 6502 CPU, they could have had a much better chance capturing a larger share of the 16/32 bit market in 1985 - because backwards compatibility with 6502 software base. The same thing that, among other things, made IBM PC successful.

_________________

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @Hammer Quote: ike Z8000 and 80286, 65K's 16-bit memory segmentation model is brain-dead. I prefer 68K over 65K. For a computer's success on the market and adoption, that is irrelevant. I've said this before, I'll say it again... Amiga 1000 was a failure, sales wise. The main reason was there was no software and it was expensive, relatively speaking, compared to the 8bit systems at the time. Nobody who was buying a home computer at the time cared for memory segmentation - nobody! They cared about price and software, in that order.

Yes, especially for home & personal computers.

However, workstations and servers have different needs.
Quote:

Had C= invested in a 16/32 bit 6502 CPU, they could have had a much better chance capturing a larger share of the 16/32 bit market in 1985 - because backwards compatibility with 6502 software base. The same thing that, among other things, made IBM PC successful.

Then please tell me more about my Plus/4 and its compatibility with the previous Commodore's machines, from Pets to the Vic20 and C64...

@cdimauro

Quote:

However, workstations and servers have different needs.

Commodore wasn't in a business selling workstations and servers. Their bread and butter were cheap home computers. And in that market, in 1985, 6502>68000. Strategically, it made a lot more sense to design a backwards compatible cheap 6502 16/32 bit home computer system than the Amiga, but not like the C128 was.

Quote:

Then please tell me more about my Plus/4 and its compatibility with the previous Commodore's machines, from Pets to the Vic20 and C64...

that was not CPU's fault.

_________________

This is all a massive load of bollocks. Commodore didn't design the Amiga, Hi-Toro did. Consequently Commodore had no say whatsoever in the CPU selection; it happened before they bought it.

It would have been suicide to release the A1000 then release a successor based on a different CPU that the machine wasn't designed around.

There was no "missed opportunity" here, thankfully. But it was OK, commodore had plenty of further opportunities to screw up and they didn't miss a single one.

Last edited by Karlos on 25-Aug-2024 at 09:36 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: This is all a massive load of bollocks. Commodore didn't design the Amiga, Hi-Toro did. Consequently Commodore had no say whatsoever in the CPU selection; it happened before they bought it. It would have been suicide to release the A1000 then release a successor based on a different CPU that the machine wasn't designed around. There was no "missed opportunity" here, thankfully. But it was OK, commodore had plenty of further opportunities to screw up and they didn't miss a single one.

The argument could be made (but not won) that Commodore could've asked the Hi-Toro team to re-engineer the Amiga computer around a different CPU. As I found out via a question on this very forum: any other contemporary CPU within the ballpark price would severely compromise the potency of the custom chipset.

The more I've ruminated on the whole sordid affair, the more I'm convinced that outside of the immediate return of screwing over Atari, the medium term returns were based on a bet that all the tech in the Amiga would get cheap enough in the near future for Commodore to have their C64 2.0 moment. They kept remaking and losing that bet.

A similar bet was made by NeXT several years later. Moore's Law is not linear. A linear equation between technological improvement and cost of production is extrapolated in more of a Monte Carlo average of highly variable data, driven more by market trends rather than what is possible in silicon. It is capitalism after all, and no one wants to halve the price of item if they can get away with it.

_________________
All the way, with 68k

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: For a computer's success on the market and adoption, that is irrelevant. I've said this before, I'll say it again... Amiga 1000 was a failure, sales wise. The main reason was there was no software and it was expensive, relatively speaking, compared to the 8bit systems at the time. Nobody who was buying a home computer at the time cared for memory segmentation - nobody! They cared about price and software, in that order.

TG-16's install base is similar to Amiga's, hence citing the TG-16 example wasn't a good virtue.

68K based Macintosh was a superior success when compared to other desktop platforms.

When compared to the Mac 512K, the 1985-era Amiga 1000 wasn't "ready for business".

Steve Jobs has courted major business software applications for "next generation" GUI business applications on stable high-resolution "business" resolution. The Macintosh platform reached around 14 million in 1994 and this install base's customers can spend 1.2 million PowerMacs to Jan 1995.

The original Machintosh can move large chunks of pixels at high-res business resolution e.g. https://youtu.be/2B-XwPjn9YY?t=102

Steve Jobs has focused on "ease of use" GUI since the original MacOS and through to NextSTEP, MacOS X, iPOD and IOS. MacOS's GUI craftsmanship is far superior when compared to Commodore 900's 1985-era Coherent.

From Google's Andriod/ChromeOS, Apple's MacOS X/iOS, Valve's SteamOS 3-Holo and Sony's GameOS, commercially successful *inx -based OS has heavily customized GUI and middleware.

At a certain clock speed, Motorola has superior mass production when compared to 65K vendors. Apple exclusive (for Apple IIGS) called out Bill Mensch's overpromise BS. Commodore's Dave Haynie complains about WDC's 65C816 supply issues.

Against TG-16's HuC6280 CPU solution, WDC 65C02 differs from CSG's 65CE02's 1 IPC design when 65C02 is just CMOS 6502's 0.5 IPC. There's a difference in implementation between WDC's 65C02 vs CGS's 65CE02.


Quote:

WolfToTheMoon wrote: Had C= invested in a 16/32 bit 6502 CPU, they could have had a much better chance capturing a larger share of the 16/32 bit market in 1985 - because backwards compatibility with 6502 software base. The same thing that, among other things, made IBM PC successful.

1. PC's text-based Lotus 123/WordPerfect/Word Star establishment was displaced by Microsoft's "next-gen" GUI MS Excel and WinWord for Windows 2.x that were ported from MacOS versions. There was a change of business software establishment with MS Windows.

IBM's Display Write wasn't able to dominate against Word Perfect i.e. #metoo is not enough.


2. Unlike the x86 PC platform, the 6502 platforms are fragmented like their 68K counterparts. CPU ISA alone doesn't complete the platform.

Commodore's Plus 4 has a common 65xx CPU family with C64 and it's not compatible and these are dead ends in relation to the platform's graphics upgrades which is the same issue for certain Amiga clones like Apollo-Core's Standalone V4+.

65xx home micros backward compatibility is a mess e.g. VIC-20 games don't run on C64 unless it is super simple. Jack Tramiel doesn't understand business desktop computer platforms except for something to sell at a lower cost with a dead-end graphics anchor.

A 286 PC AT standard with CGA or EGA can be upgraded to VGA. IBM has partitioned PC's graphics architecture. The PC doesn't need to sync its CPU upgrades with graphics architecture upgrades.

Last edited by Hammer on 26-Aug-2024 at 03:51 AM.

_________________