Was anyone else disappointed with the A1200?

[Thorham]

Originally Posted by Bruce Abbott

If you didn't have an Amiga in the late 80's the A1200 would have been just as exciting as the A500 was in 1987. But because you had "been there, done that" it was just more of the same.

My first Amiga was an A500. When I upgraded to an A1200 it made such a big difference, and I was very happy with it.

Originally Posted by Bruce Abbott

The PC was a bit different, and so was exciting if you weren't familiar with it.

[pandy71]

Originally Posted by Bruce Abbott

This is not correct. Sure it had better gaming/animation hardware, but it wasn't ahead of the PC in other areas.

Nope, i strongly disagree - Amiga was way ahead as offered in standard functionality not present in standard PC till at least 1994..96.
This functionality was obvious and normal for Amiga users and it is quite obvious that it was not appreciated .

Originally Posted by Bruce Abbott

IBM introduced the PC-AT in 1984 with a 6 MHz 80286 (equivalent to or slightly faster than an 8MHz 68000), EGA graphics with sharp 640x350 flicker-free graphics in 16 colors, 1.2 MB floppy drive, 20 MB hard drive and up to 512kB of RAM on-board. It was much more expensive the A1000, but also much more capable.

You could run 640x350 on Amiga with 82Hz refresh rate so flicker will be largely not present.

6MHz 286 is slower than 8MHz 68000 - i always recommends to run software like DJPEG (part of libjpeg) on Amiga and on PC to compare real speed.

[abu_the_monkey]

You could run 640x350 on Amiga with 82Hz refresh rate so flicker will be largely not present.

interesting. what screen mode is this that you are referring too? and what display/monitor would be required to use it?

[Bruce Abbott]

Originally Posted by Thomas Richter

TIGA was nothing like "OpenGL" or "DirectX" became to be. The "loadtiga" command of the A2410 card contains that library and loads it on the TMS, and the "a2410.device" is a user of this library.

But the application doesn't manipulate the hardware directly. High level graphics commands and parameters are sent to the board through the driver, to be executed by the TMS310x0 chip. A driver could be written that takes this information and uses it to control totally different hardware.

But why am I telling you this? You know it already.

The 8514 was quite disappointing compared to the Amiga - back then. However, the larger PC market changed that rather quickly while CBM management was asleep and issued stupid management directives not to advance the chipset.

640x480 in 256 colors was 'quite disappointing compared to the Amiga' in 1987?

"stupid management directives not to advance the chipset" - is not correct. AGA was in continuous development from 1989 to 1992. The first prototype AA chipset was produced in late November 1990. Of course it was buggy. By February 1991 it was good enough to boot Dave Haynie's A3000 Plus. Soon afterwards Irving Gould announced in an interview with Amiga Computing magazine that a new chipset was coming and should be ready "this fall". By late March 1991 they had fully working AA prototype chips, but the engineers had a list of 10 extra things they wanted to put in it.

You can see where this was going. On March 28 the engineers working on AA met to decide which features to add and which they could live without. Jeff Porter then estimated that the changes would push the release date back to April 1992 (which was about right).

Lew Eggebrecht (VP of Engineering) later explained why release dates kept slipping:- "We have some very free-thinking engineers... and if you don't give them specific goals they'll just continue to develop and develop. The process of converting a design to a product is something Commodore has always had trouble with. We're stopping all that."

But it was too late for the A1000 Plus. As a result of the AA enhancements and other delays they missed the 1991 deadline for Christmas sales, a critical failure. That's when Sydnes, under pressure from Medhi Ali to get the new machine out, came up with the idea of an A1000+ with the ECS chipset, which nobody wanted. However in February 1992 Ali ordered Sydnes to produce a AA replacement for the A500, to be released by September 1992 (only a year after they could have if they had stuck with the original AA design). Jeff Frank then took his A600 design and turned it into the A1200.

The truth is it wasn't stupid management directives that were the problem, but a lack of directives forcing the engineers to meet tight a schedule. Once Gould had announced an upcoming new chipset 'in the fall' they should have jumped to it. An A500 level machine with AA - even without any of those 10 extra features - would have hit the spot nicely. But instead of responding urgently they kept adding stuff to it, apparently not concerned about delays.

In the end we got a better product I guess, but that 1 year delay was fatal. 1991 was a great year for Commodore sales, but the next year sales dropped dramatically and they lost $100 million - because engineering couldn't see when it was time to stop chipset development and get the product out! If only someone in upper management had told them not to advance the chipset, Amiga fans might not be complaining about how disappointed they were at the A1200 arriving so late.

[Bruce Abbott]

Originally Posted by pandy71

6MHz 286 is slower than 8MHz 68000 - i always recommends to run software like DJPEG (part of libjpeg) on Amiga and on PC to compare real speed.

The PC-AT ran with 1 wait state due to the slow RAM available at that time. This dropped the effective clock speed from 6 MHz to 5 MHz. But the 80286 accesses memory every 2 clock cycles, twice as fast as the 68000.

In some applications the 68000 might be faster, but on most benchmarks the PC-AT has the edge. Here are some numbers I found with Google:-

IBM PC/AT 80286-6Mhz Lattice 2.15 1250 Dhrystones
Amiga 500 68000 7Mhz (sc 6.00)    1333 Dhrystones	

Amiga 1000 AmigaDOS 68000     7.16MHz 0.54 mips
IBM PC/AT PCDOS 3.0 80286     6.0MHz  0.69 mips

https://litwr2.github.io/pi-spigot-benchmark/pi-spigot-benchmark.html
100 digits of Pi 
Amiga 500/PAL+fastRAM, 68010, 7.09 MHz 0.34 seconds
IBM PC 5170 AT, 80286,        6 MHz    0.21 seconds

[sandruzzo]

It is interesting to notice that two of the worse architectures have been very successful: x86/x64 and vga-like gfx cards. After all, are they terrible?

[Promilus]

Originally Posted by pandy71

? How you can use Paula without emulating some Agnus functionality - or Denise without Agnus - you need all 3 IC's connected together or you need to put lot of glue logic to emulate Agnus - only CPU can be different than MC68K. It could be hilarious to see some ARM or x86 based "Amiga" (yes, i'm aware of Pistorm).

Look at the pinout and you will know. It needs clock and quadrature clock. Easy peasy. RGA? Same. Interrupts? No problem. DMAL? That's the only part slightly more challenging. Slightly. And as far as "ARM based Amiga" you should be well aware of the project which came before PiStorm and for which emu68 was written for. Yes, at PPA there's still somewhere a topic about STM32H7 based card with the last update 5 years ago when ARM was controlling screen memory. And that was only emulated 68k interface... no 68k instruction at that time has been emulated.

Z80 comes from 8080 but it is different than 8080. Amiga not use 8255 but some Amiga expansion boards use 8255. And yes, pointed that CIA's is pretty standard LSI. And for example Z80 family I/O IC's was NOT widely used on other HW than Z80 (i mean Z80 CTC, PIO, SIO etc)

Yes and all those "standard components" were designed for 8085 and worked well with similarly designed 8086. They were hardly used with Z80, 6502, MIPS, ARM or 68000...
Also it was possible to interface PIO and SIO with 68k as there was even an (I guess) eval board Z80 interface compatible but with 68000 CPU. And I did repair in the past old machine panel with 68000 and SIO + PIO done similar way...
https://bitsavers.org/pdf/colex/stdB...ds/std-68K.pdf

My point was that you limited standard to SSI and MSI logic, mostly 7400 family where my point was that some LSI are also standard i.e. largely ISA agnostic.

All amiga chipset is ISA agnostic. It doesn't need 68k instructions to work. It needs 68k signals to work, those chips are built around 68k bus cycles. Can you remove 68k and use native ARM instructions to drive them? Sure. No problem, as long as you retain 68k bus timings. In that case they are just as much "standard" as anything else of similar functionality. The only real issue is... both PC and Atari ST were made from parts widely available. Amiga was not. All those chips were amiga exclusive and CIA was still commodore exclusive. But there ain't much difference between what CIA does and what other I/O chips do and obviously it can be interfaced with all kinds of CPU systems as it runs both 6502 and 68k no problem.

IC's like Gayle, Gary are practically useless out of Amiga - you can use them but probably same functionality can be achieved easier, Akiko is very similar, perhaps C2P conversion has some added value but if this is worth something out of Amiga?

Worth outside amiga is not part of the discussion. Amiga was spread over several chips because of manufacturing limitations of MOS plant by Commodore (under investment and also the issue with leak of the tank), that's why more advanced chips were made by 3rd party. Ideally things like Agnus, Gary and most likely Denise could've been made in 1 chip forming what's in PCs of that era became known as "northbridge" with CIAs and maybe Paula forming "southbridge". That's exactly what they would've done if they had feasible process. So... going the same was as those nasty PC cloners. And basically that's what has been done by natami team some time later.

[TEG]

Originally Posted by Bruce Abbott

The truth is it wasn't stupid management directives that were the problem, but a lack of directives forcing the engineers to meet tight a schedule. Once Gould had announced an upcoming new chipset 'in the fall' they should have jumped to it. An A500 level machine with AA - even without any of those 10 extra features - would have hit the spot nicely. But instead of responding urgently they kept adding stuff to it, apparently not concerned about delays.

In the end we got a better product I guess, but that 1 year delay was fatal. 1991 was a great year for Commodore sales, but the next year sales dropped dramatically and they lost $100 million - because engineering couldn't see when it was time to stop chipset development and get the product out! If only someone in upper management had told them not to advance the chipset, Amiga fans might not be complaining about how disappointed they were at the A1200 arriving so late.

I see a pure contradiction in this sentence. Giving no directive is more or less the same as giving stupid directives. It look like there was a disconnection from the head and the body of CBM.

I really wonder how Commodore worked internally in the Amiga area. Did the R&D had meeting with the management to cogitate? From what you describe, it look like it was worst than the Tramiel area where the directives were at least kind of: "You and you, build an architecture to beat this competitor, we need it for Christmas. The one who fail will have its head cut." And so the C64 emerged in time.

[Promilus]

Originally Posted by sandruzzo

It is interesting to notice that two of the worse architectures have been very successful: x86/x64 and vga-like gfx cards. After all, are they terrible?

Current cards are hardly VGA... they do usually revert to VGA-like behavior with no driver loaded. So like boot screens etc. But they are much more advanced. Even ARM solutions like Mali could've imitate VGA screens but that's beside the point. What's important is compatibility with current standards like Vulkan and GLES (or in case of Windows apps - DirectX) but those are quite mutable. Like DXVK which translates DX calls to Vulkan and recompiles shaders during runtime. As for x86 - that was a PITA of architecture. Just handful of registers, segmented memory and instruction length varied from few bytes to few dozens of bytes. But that's kind of also a thing of the past. Because from quite a long time internally there are a lot more registers than covered by ISA and with 64bit addition they did increase a number of GPRs in ISA to fairly decent number of 16 (with a separate set of SIMD registers also 16). So while ISA itself is still a mess compilers do a fair job and the rest is handled by execution-time optimizations of the processor itself (like OOO, prefetch, scheduling etc.) Look where is PowerPC which was looking so nicely during Pentium and Pentium II era... And IBM's Power (previously POWER) came to increase number of threads inside single core instead of aiming at performance of single thread. The biggest progress came from late bloomer - ARM - which was widely used for power efficient devices but during last decade it did reach both HPC servers with A64FX and computers with M1, M2 and M3. Why ISA or architecture isn't all that important? Because all that actually matters is what you receive and at what cost. And availability is important as well. You can buy decent x86 CPU in a shop around the corner, replace the one of previous generation and still have fairly well behaving computer. Can you do that with ARM processor? No? Aaaa...

[Thomas Richter]

Originally Posted by Bruce Abbott

But the application doesn't manipulate the hardware directly. High level graphics commands and parameters are sent to the board through the driver, to be executed by the TMS310x0 chip. A driver could be written that takes this information and uses it to control totally different hardware.

In case you do not understand the difference: With OpenGL or DirectX, you get an API layer to create graphics, a piece of software running on the host machine. With TIGA, you don't. You get a graphics library that runs on the TMS, but how that library interfaces with the host, and how the software on the host interacts with the TIGA is *not* part of the library. That is part of the problem a vendor has to solve. It is something completely different. The "TIGA library" CBM used for the A2410 is there fore a superset of what they got from TI, and it had to be since that TMS code has to solve problems in addition to rendering graphics primitives. Thus, every vendor would still have to write a software layer to interface with the TMS, and there was no standard API to talk to the TMS - unlike OpenGL or DirectX where software can rely on such a layer present.

Originally Posted by Bruce Abbott

"stupid management directives not to advance the chipset" - is not correct.

"Read my lips no new chips" is a stupid management directive, and a clear directive *not* to develop new chips. As simple as that.

[TEG]

Originally Posted by Thomas Richter

"Read my lips no new chips" is a stupid management directive, and a clear directive *not* to develop new chips. As simple as that.

Especially when new chips are at the heart of your business.

But it look worst than that. AGA being delayed for 6 months could look like sabotage. It has been already said but here is in context:

Dave Haynie - By the time C= went under, development had really been stymied for some time (it's a related issue, refer to "The Deathbed Vigil and other tales of digital angst" for one view on some these factors). Things had been humming along on the A3000+ in the first half of 1991 (the A3000+ being the best of the A3000 and A4000 combined with a DSP3210 and kick-ass audio subsystem), then a new management came in and killed all the projects currently in the works. The A3000+ was reduced to a "development vehicle" for AA, AA was intentionally delayed for 6 months so Mehdi Ali would think the previous engineeing management has been screwing it up (they weren't), etc.

Source : https://www.cucug.org/amiga/aminews/...nie960306.html

[pandy71]

Originally Posted by Promilus

Look at the pinout and you will know. It needs clock and quadrature clock. Easy peasy. RGA? Same. Interrupts? No problem. DMAL? That's the only part slightly more challenging. Slightly. And as far as "ARM based Amiga" you should be well aware of the project which came before PiStorm and for which emu68 was written for. Yes, at PPA there's still somewhere a topic about STM32H7 based card with the last update 5 years ago when ARM was controlling screen memory. And that was only emulated 68k interface... no 68k instruction at that time has been emulated.

True and this was my point - you need to emulate Agnus functionality as Jay intentionally or not mimiced Atari architecture where ANTIC act like DMA controller (same as Agnus) and GTIA (act like data interpreter - same as Denise) - substantial difference is Agnus is not programmable as ANTIC was.

But hey, let's focus on functionality - so why do you need Paula in first place? to output PCM ? Use just DAC08 with 8253 as timer and something like 8257 to perform DMA... So you need to have 6 bit PWM audio level... so build some PWM or use 7497 to get better functionality.
you no need Paula to get same or better functionality.

You can use Pula but you need to recreate some Agnus functionality.

Similar for Denise - it can be probably used alone but way easier is to use Denise with Agnus.

Originally Posted by Promilus

Yes and all those "standard components" were designed for 8085 and worked well with similarly designed 8086. They were hardly used with Z80, 6502, MIPS, ARM or 68000...
Also it was possible to interface PIO and SIO with 68k as there was even an (I guess) eval board Z80 interface compatible but with 68000 CPU. And I did repair in the past old machine panel with 68000 and SIO + PIO done similar way...
https://bitsavers.org/pdf/colex/stdB...ds/std-68K.pdf

Most if not all LSI standard components are designed to be compatible in some way with leading uP buses.
You can use SIO, CTC, PIO with non Z80 buses but they offer something like autovectorized interrupts designed specifically for Z80 bus and this is impractical to be used by other than Z80 CPU's - Intel LSI's are more architectural agnostic.

Originally Posted by Promilus

All amiga chipset is ISA agnostic. It doesn't need 68k instructions to work. It needs 68k signals to work, those chips are built around 68k bus cycles. Can you remove 68k and use native ARM instructions to drive them? Sure. No problem, as long as you retain 68k bus timings. In that case they are just as much "standard" as anything else of similar functionality. The only real issue is... both PC and Atari ST were made from parts widely available. Amiga was not. All those chips were amiga exclusive and CIA was still commodore exclusive. But there ain't much difference between what CIA does and what other I/O chips do and obviously it can be interfaced with all kinds of CPU systems as it runs both 6502 and 68k no problem.

Agree, i've wrongly used term ISA to describe HW features (using ISA as sysnonym not only for instructions but also bus). For sure Amiga chipset is ISA agnostic.
CIA's (8520 and 6526) was easily available form MOS and later from CSG - they was offered on market same as popular VIA 6522.

Originally Posted by Promilus

Worth outside amiga is not part of the discussion. Amiga was spread over several chips because of manufacturing limitations of MOS plant by Commodore (under investment and also the issue with leak of the tank), that's why more advanced chips were made by 3rd party. Ideally things like Agnus, Gary and most likely Denise could've been made in 1 chip forming what's in PCs of that era became known as "northbridge" with CIAs and maybe Paula forming "southbridge". That's exactly what they would've done if they had feasible process. So... going the same was as those nasty PC cloners. And basically that's what has been done by natami team some time later.

TBH i have no information's about environmental conditions for MOS/CSG (when it was detected) - for sure manufacturing capabilities was limited thus need to use HP and VLSI later (AGA chipset).

I would avoid modern terms as northbridge and southbridge using exclusive and fast interface (usually serial - btw strange that Amiga didn't used high speed serial - AMD made some TAXI chipset - serializer and deserializer AM7968/7969 but perhaps this was too much) to be not cluttered by regular buses - in Amiga RGA is just internal address bus but regular data lines (and as such bus contention is present) was used to exchange data. Ideally all Amiga functionality shall be made as single IC (OCS or at worst ECS).

Btw i think i should use this as example of my point - are you consider AY-3-8910 as standard or non standard (i.e. custom) part.

[Promilus]

Let me remind you which part of Bruce opinion we're talking about in such length...

Nonsense. The CD32 integrated everything on the motherboard, with a single edge connector for future expansion. That's quite different to the average PC clone of the time.

PC cloners focused on making the standard PC architecture cheaper. This was mostly done by using far East manufacturing plants, and later on integrated chipsets incorporating the functions of standard ICs.

Now... do you agree or disagree with that statement? So trying to sell all C= limitations (chipset spread over several chips) as something good and omit the fact they also used far east facilities to manufacture their stuff? Gary is exactly the same thing - A1000 did NOT have gary. There were bunch of "standard IC" And same sh*t happened with A2000-B rev 4 mainboards with no Gary and also Buster in form of PAL chips. So that means... Amiga in '86 and '87 already did what PC cloners started in 90s - to integrate "standard ICs" in a form of own, more complex chips. Yay!

[pandy71]

Well... every Amiga integrated everything on mainboard (if you not count dirty workarounds) - but PC market is/was different than Amiga.

CBM started to use ASIC since first time to reduce cost and CBM keep all IP - PC is driven by spread IP and cost reduction.

Gary is simple address decoder and some floppy logic, most A1000 glue logic was placed in FAT Agnus. Yes, CBM made same things as Atari - lot of custom logic to reduce overall cost - PC at the beginning used discrete standard LSI to create system architecture - merging those standard LSI's into higher integration level was started relatively late. Not sure who started this first C&T or Opti anyway for long time XT and AT was made from standard logic.
But i see this process natural and quite obvious.

[pandy71]

Originally Posted by abu_the_monkey

interesting. what screen mode is this that you are referring too? and what display/monitor would be required to use it?

Same approach as in Atari ST emulators - by reducing number of the lines to be displayed you bumping vertical refresh rate - you can tell HW ( http://amigadev.elowar.com/read/ADCD.../node0044.html ) that end of screen was reached earlier. Simple calculation shows that (480*60)/350=82Hz , for ST this is (480*60)/400=72Hz
With this refresh rate line flickering is significantly reduced.
And large part of CRT's can properly display such video modes (usually they tolerate more on vertical than on horizontal).

[hammer]

Originally Posted by sandruzzo

It is interesting to notice that two of the worse architectures have been very successful: x86/x64 and vga-like gfx cards. After all, are they terrible?

IBM VGA was slow, but its performance and affordability were improved by VGA cloners. IBM PC business lost its market share to the PC cloners for a reason.

From experience, the IBM PS/2 Model 55SX (386SX-16, IBM VGA) is not a replacement for the A500 in action gaming and it's not a stock A1200-level competitor. Between Commodore's stock A1200 and IBM PS/2 Model 55SX, I'll select A1200.

IBM VGA is slow despite attaching K7 Athlon XP 2200+ (1800 Mhz) to it. Meanwhile, Emu68's 1800Mhz Cortex A72 has good frame buffer results for AGA.

My point, PC VGA cloners were matched with price/performance competitive X86 CPU pairing in 1991 and beyond.

---
X86 has respected backward software compatibility better than the other camp.

AMD used the same backward software compatibility superiority to beat Intel's Itanium i.e. it worked for Intel's IA-32 against major RISC alliances.

MOS/CSG 65xx CPU family R&D pace was very slow, hence its desktop microcomputer platform vendors seek alternatives e.g. ARM, 68K, Z8000.

[Bruce Abbott]

Originally Posted by pandy71

But hey, let's focus on functionality - so why do you need Paula in first place? to output PCM ? Use just DAC08 with 8253 as timer and something like 8257 to perform DMA... So you need to have 6 bit PWM audio level... so build some PWM or use 7497 to get better functionality.

The reason is you need 4 DAC08s* which aren't cheap, plus all the support circuitry. That's probably what the Lorraine prototype had in it.

However I think that sending I2S serial data out of Paula to an 'industry standard' external audio DAC would be a good idea. It would cost a bit more but be a lot more flexible and produce higher quality sound. This is similar to how AGA used a 'standard' external Video DAC with built-in color palette registers rather than try to integrate it into Lisa.

I also think it would be awesome to reproduce Paula with standard chips, like how the 6502 has been reproduced with standard logic gates. Obviously not cost-effective, but a great retro project!


* actually more than that because it has to pull both up and down. I'm not sure how Jay Miner would have done that - perhaps a current mirror selected with bit 7, then you only need a 7 bit DAC.

Btw i think i should use this as example of my point - are you consider AY-3-8910 as standard or non standard (i.e. custom) part.

The datasheet says "interfaces to most 8-bit and 16-bit microprocessors" and "is easily interfaced to any bus-oriented system" with suggested applications ranging from music synthesis to audible alarms and FSK modems. This indicates that they intended it to be an 'industry standard' part, which is what it became. However if you look more closely you see that the bus control signals are specific to General Instrument's own CP1610 CPU. To use other CPUs you need a few gates to convert the bus signals. There were also customized versions that were slightly different. Nevertheless it's clear that the chip was designed for general purpose use, not a specific product.

In comparison, Paula was designed to work only with Agnus/Alice in the Amiga. Commodore never even hinted that it might be possible to use it on another architecture, and doing so would be rather difficult when there was no application information. Thus it would meet the definition of 'custom chip' even if Commodore didn't call it that.

[Bruce Abbott]

Originally Posted by hammer

From experience, the IBM PS/2 Model 55SX (386SX-16, IBM VGA) is not a replacement for the A500 in action gaming and it's not a stock A1200-level competitor. Between Commodore's stock A1200 and IBM PS/2 Model 55SX, I'll select A1200.

I am hoping to do a comparison between those machines this week, if the 386SX-16 motherboard I got today works (the last one died before I got the chance). I paid $160 for it so it better work or that's it for retro PCs! The good news it has 16MB of RAM on it, so it should be able to run Doom (slowly).

[hammer]

Originally Posted by Bruce Abbott

But the application doesn't manipulate the hardware directly. High level graphics commands and parameters are sent to the board through the driver, to be executed by the TMS310x0 chip. A driver could be written that takes this information and uses it to control totally different hardware.

IBM 8514 includes an Adapter Interface standard. Some "Add-in Board" (AIB) cloners used TMS310x0 for 8514 Adapter Interface compatibility.
The idea is software drives the hardware sales.

The big elephant in the room against IBM's 8514 Adapter Interface is Windows 2D acceleration.

Originally Posted by Bruce Abbott

But why am I telling you this? You know it already.

640x480 in 256 colors was 'quite disappointing compared to the Amiga' in 1987?

8514/A can do 1024×768 resolution and up to 256 colors. The basic 8514/A with 512KB VRAM only supported 1024×768 16 colors and the 512KB memory expansion brought the total to 1MB VRAM and supported 1024×768 256 colors.

8514 blast past 640x480 in 256 colors.

Prominent 8514 clones are those from Paradise systems (acquired by Western Digital) PWGA-1 (also known as the WD9500), Chips & Technologies 82C480, and ATI’s Mach 8 and later chips.

Compatible 8514 boards were also based on TI’s TMS34010 chip.

Both 8514 and VGA standards set the stage for integrated SVGA AIB clones and IBM's XGA (1990).

Originally Posted by Bruce Abbott

"stupid management directives not to advance the chipset" - is not correct. AGA was in continuous development from 1989 to 1992.

Who are you to dispute Dave Haynie's argument?

ET4000AX was released in 1989, hence its R&D was before its release e.g. 1988. ET3000 was released in late 1987 a few months after IBM's 8514 and VGA releases.

ET4000W32 was released in early 1992.
From http://files.mpoli.fi/hardware/DISPLAY/TSENG/
ET4000W32's Windows 3.1 driver was date-stamped in March 1992.

Starting AGA's R&D in 1989 would be too late for the A3000 and A500 Rev6A R&D phases.

Originally Posted by Bruce Abbott

The first prototype AA chipset was produced in late November 1990. Of course it was buggy. By February 1991 it was good enough to boot Dave Haynie's A3000 Plus. Soon afterwards Irving Gould announced in an interview with Amiga Computing magazine that a new chipset was coming and should be ready "this fall". By late March 1991 they had fully working AA prototype chips, but the engineers had a list of 10 extra things they wanted to put in it.

You failed to factor in Dave Haynie's "more than 6 months lost" on unwanted ECS "A1000Jr" R&D.

[hammer]

Originally Posted by pandy71

Intel tried many times to create x86 alternative and every time failed (432, 860) - in fact Intel was victim and hostage of the x86 popularity, unable to start something different incompatible with x86 and biggest Intel curse. This is fact.

Intel didn't factor in software sells hardware and business software is a powerful use case factor.

AMD's RISC 29K CPUs are no different.

Originally Posted by pandy71

Yep, strong 256 colors with 64KiB page size - good luck with your 320x200.

1987 VGA encapsulated 1986 MCGA.

Originally Posted by pandy71

Trying but with you shuffling partially true, partially not - information's this is difficult.

Originally Posted by pandy71

So you confirm with above example that Apple was not good in HW at all (i mean in past they considered HW as less important than SW - perhaps this is not the bad approach) so fundamentally Apple approach was similar to PC. Apple philosophy was clear - not provide HW acceleration as standard in their products - for very long time this was same approach as in PC - lets do everything with CPU, substantial difference is that Apple provided neat API's to remove direct HW bit banging.

Apple's Quickdraw has a unified ecosystem while it's separated on Commodore's OCS/ECS/AGA and Video Toaster's 2MB 24-bit frame buffer and it's hardware-specific Toaster software.

Quickdraw's performance scales with graphics hardware's capabilities.

PC DOS has the superior Mortal Kombat 1 and 2 ports when compared to 16-bit Amiga ports.

Before 68K Amiga's Star Wars Dark Forces port, I ran the Mac 68K version on A500/A1200-PiStorm-Emu68. If I had CyberStorm 060 and CyberGraphics 64 for my A3000, I would have run Star Wars Dark Forces for the MacOS 68K. Might as well buy a Mac at this point.

Originally Posted by pandy71

Obviously You are immature or with some social deficit - unable to participate in reasonable discussion without expressing emotions and trying to insult someone not agreeing with you - sorry - this is sometimes hilarious, sometimes annoying - i have mixed feelings.

There you go again. You engaged in personal attacks and assumed I don't have corporate experience.

You started the personality-based flame war.

You departed from this topic's A1200 criticism subject.

Originally Posted by pandy71

First this is way off topic, secondly we trying to compare comparable i.e. 3 groups of market here - Amiga, Mac, PC in tie between 1984..1994 i.e. Amiga timeline.

Wrong. This topic is about the A1200, and by extension A1200 based CD32.

Originally Posted by pandy71

I don't care about Apple HW and SW - it never get my attention and i never participated in Apple hype.

This topic is about A1200 vs world. A1000 was released around mid-1985 in limited numbers.

Originally Posted by pandy71

This is example of your misinformation - TIGA is not 8514 compatible - this is different API however you may translate 8514 API to TIGA API and use non 8514 compliant graphics HW to emulate 8514 functionality.

The technical implementation details wouldn't matter to the end-user and general PC market when the AIB vendor marketed the TIGA-based card as 8514 compatible.

TIGA is not important for IBM's dominated PC standards.

There are more 8514 clones when compared to TIGA.

I don't care about TIGA and I never participated in Texas Instruments Graphics Architecture's hype.

Rendition's MIPS-based Verite V1000 emulated VGA and it was slow i.e. not fast VGA competitive. Verite V1000's slow VGA impacted Quake and Doom.

Originally Posted by pandy71

8514 clones are compatible at the register levels if not then they emulate 8514 trough different HW by using SW.

Registers can be emulated.

Originally Posted by pandy71

There was few 8514 clones so you could do bit bang and expect same from IBM design and clone design.

Registers can be emulated.

Originally Posted by pandy71

Are you sure? Any source of claim that 29K microcode was used to emulate x86

I didn't claim the K5 runs 29K instruction set. AMD marketed K5 as RISC with X86 decoders.

https://websrv.cecs.uci.edu/~papers/...LES/081401.pdf

To keep the K5 design pure, AMD says that no one associated with the Intel-derived designs was involved.


AMD borrowed heavily from the microarchitecture work that was done for the superscalar 29K, which was designed earlier, and much of the design team had 29K experience.


Two things that were used from AMD’s x86 experience are the compatibility test suites and validation methods that had been developed to test the clean-room 486 microcode.

To validate the design running real software, a Quickturn-based hardware emulator was used. Running on the hardware emulator, the K5 booted
DOS in July and Windows in August.

AMD believes that its investment in hardware emulation, which turned up
about two dozen subtle bugs, will pay off in chips that have few problems in
the initial silicon.

...
The overall style of the micro-architecture is most similar to that used by NexGen’s Nx586, in which x86 instructions are decoded only one at a time but are translated into RISC-like operations that are executed in parallel.



Quake's strong FPU requirement culled X86 CPU cloners.

K5 runs into the clock speed wall.

Originally Posted by pandy71

or perhaps 29K HW design with special, different than native 29K microcode was used to provide x86 ISA?

There's no point with 29K ISA since its R&D was terminated in late 1995.

Originally Posted by pandy71

This is two different things - it is quite obvious to reuse good HW design but perhaps technical subtleties may lead to some modification - it doesn't mean that 29K run x86 binary code as 29K rune OWN code and was used as fast RISC CPU.

AMD terminated 29K R&D in 1995 for the profitable X86 business.

Originally Posted by pandy71

IBM in past, in some products used MC68000 modified at microcode level to emulate S/370 ISA but this not made MC68000 S/370 compatible CPU.

AFAIR Transmeta was never x86-64 clone - only x86 ISA was emulated.

The customers are interested in S/370 software running on IBM-provided hardware and support contracts.

According to Linus Torvalds, Transmeta's Crusoe native code has no concept of memory protection, and there's no MMU.

Originally Posted by pandy71

Well... if you say so - it s also many ways to provide misinformation especially if by mistake or not author of misinformation seem don't understand technical subtleties...

There was no misinformation when AIB vendors marketed 8514 compatible addon cards with TIGA chips.

NVIDIA's RTX GPUs have RISC-V CPU, but it's hidden by NVIDIA. Customers are only interested in its marketed use case. NVIDIA's CUDA influence and dominance are beyond TIGA.

Originally Posted by pandy71

?!? I'm lost - will you be able to rephrase above to be more clear and please avoid marketing BS... This is opposite to general knowledge about PC - IBM released technicalities and allowed for duplication without clean-sheet - only BIOS was copyrighted so PC market closely followed IBM design. EGA was continuation of CGA and VGA was continuation of EGA and VGA...

For example, 8514's registers are published.

IBM's VGA design wasn't designed for low cost. ET3000 has ET3000AX 1108AF-0005 custom ASIC. ET3000 was released in late 1987.