What if Commodore had lasted one year longer?

[haps]

Bruce, while I admire your dedication to the Amiga, I don't understand why people cannot just love the Amiga for the great computer it was in its time, and let it lay as such. Another year for Commodore may as well been a drunken man pissing in the wind.

[Promilus]

Yes, the Amiga did have a large number of video cards and other devices made for it

Not that large. And most RTG video cards are made with PC chips on ISA interface. As any such interface it was fairly mutable to Zorro II (both being just CPU interface + additional control signals). AFAIK Cirrus Logic chips were most frequently used and in newer designs S3 (trio, virge) + 3DLabs. There were few graphic cards which were built on non-pc components.

many of which were innovative and unique (not just copies of standard devices like most PC cards were)

Oh, I guess then all those piccolo, picasso, cybervision etc. shouldn't count then. And neither should e.g. Toccata. That basically cuts expansion list in half.

The Amiga's joystick ports are compatible with most digital and analog joysticks (unlike PCs which could only do analog), so there was no need to make 'Amiga' racing wheels etc.

Racing wheel has nothing to do with joystick. It is about better experience in racing games and simulators. You can hook up usb gamepad from xbox to PC and play either digital or analog ... so what, it makes great difference when you can play such games with steering wheel and amiga had few as well. Those weren't popular not because mause or joystick can do better. Those weren't popular on amiga because there weren't many games making a decent use of analog wheel and pedals. And digital wheel isn't quite that fun.

This is total nonsense. The reason Amiga video cards using P96 is possible is that the hardware and OS interface is open

Windows XP support single workspace. With ATI drivers it supported multiple workspaces (so just like in linux for many, many years you can drag app windows and drop on different workspace so efficiently use single monitor setup while running multiple apps). WinXP is closed but moddable. It isn't designed to be used as "live" but you can make it "live" so running from mass storage without actual installation on target machine. It's not like only Amiga community has decent developers. It doesn't mean WinXP is "open". P96 or CGX is necessity. MUI is required a lot as well. You have little choice there.

A PC of the day was no different, except that it lacked even more features

PC did not. And DOS is DOS ... disk operating system. That's all there is to it. What is the problem with running audio setting tool of the game and chose roland if you had one or adlib, or sb ?

Back in the day they generally provided drivers as part of the package because users expected it.

Yeah and everything was always free. Poseidon, MUI, dopus...

Many video card manufacturers expected you to download driver updates from the chipset manufacturer, then when it didn't work due to some quirk of their card you were out of luck. Good luck trying to diagnose and fix a video card driver in Windows

That sounds really funny when you have to swap library version, modify S-S etc. should you ever change your graphic card and/or cgx worst case scenario you brick your OS. Claiming that on Amiga everything works right out of the box is silly. It takes literally hours to get proper OS configuration for expanded amiga going from 3.1 disks to anything usable with fonts, datatypes, required libs etc.

As the hardware got more sophisticated it was obvious that abstraction was the only way to go. Optimizations might be more challenging, but they can be applied at the driver level without application programmers having to deal with it. It's same reason almost all high performance coding is done in C or C++ now.

You're missing the point. So I will give you another example. Arduino is platform which works with many devices. There's 8bit AVR, there's 32bit ARM also (both microchip and ST), there's Xtensa on ESP products and probably more. Most of the coding can be done on either and it will work ok. You could switch to different target and many functions will still work ok (just need to adjust few things in setup() ) The same code for very different devices. Does it work? Sure it does. It is quite popular too. Is it fast? Nope. And it will never be. With API like DX it's just bunch of functions. Microsoft doesn't really care about what your device does and how. All it cares is that your driver will translate API calls to whatever your device does and produce expected results. That's apparently a good thing because it allows to develop games quickly and to variety of hardware configurations. But producing optimal drivers for many hardware models and making optimal use of API on many different configurations isn't easy (actually it's plainly impossible). Game designers have to know which parts of the screen to cut out, effects to shut off so it'll work on slower configs. Manufacturers have to check if it works correctly and rewrite their drivers if some bad things occur. With one configuration it is way easier to produce optimized product, both application-wise and driver-wise.

The Amiga had well defined hardware and excellent documentation on how to control it bare metal in 68k assembler

Sure and that's exactly what has blown into their faces. It backfired because everyone expected backward compatibility and when apps are written to use direct access through registers it means all registers have to stay the same and new functionality just needs new ones. All new graphic cards at some level has to emulate 3 decade old VGA regardless of what their internal registers are (and there are a lot!). New amiga chipsets were made register-incompatible with OCS and AGA which means games designed to bang registers wouldn't work (directly). Only games designed using system libraries and calls would be able to handle new chipset and - at that time - there weren't all that many because even using best techniques OS still occupied some of the precious chipram.

By the time OS3 and AGA appeared, the Amiga had so many configurations that supporting them all in bare metal code was becoming very difficult

Well if written to chipset it was the same deal as always. Writing to additional hw beyond chipset would be difficult that way but gaming consoles aren't really all that expandable in the first place for reasons I already mentioned.

The machines are virtually the same except for one having a high performance CD drive interface with DMA, vs the other having a slower PIO hard drive interface

It doesn't matter. Graphics and sound subsystem was the same and so was memory. DMA only worked with that mere 2MB which was precious. As I mentioned CD rom could hold bigger games (bigger areas, better graphics etc.) which rarely happened. It could hold soundtrack or videos for cutscenes (like Wing Commander) - but it rarely did that as well. It could be used with smart buffering to dynamically load certain areas in the background when player was moving so without the need to load up whole map to memory (as it was pretty limited). That's thing which PS1 made frequently. It was hardly used at all on CD32. CD on CD32 wasn't used properly. 1 year more would make no difference. It would still be obliterated by Playstation and only make more ppl regret their choice.

SX32 is rare expansion and hardly ever used by any CD32 specific game. And you couldn't get 040/060 without conflicting with Akiko C2P (iirc) but it doesn't matter as 040 can do that math faster anyway.

[Keops/Equinox]

1 year more would make no difference. It would still be obliterated by Playstation and only make more ppl regret their choice.

I was about to post something but then I read this, it summed up perfectly what I was about to write

[Bruce Abbott]

Originally Posted by Promilus

Not that large. And most RTG video cards are made with PC chips on ISA interface. As any such interface it was fairly mutable to Zorro II (both being just CPU interface + additional control signals).

You implied that few video cards were made for the Amiga because it didn't have an 'open' architecture, but now you are saying it was easy because the Amiga had an open architecture?

AFAIK Cirrus Logic chips were most frequently used and in newer designs S3 (trio, virge) + 3DLabs. There were few graphic cards which were built on non-pc components.

X-Pert Visiona (released in 1990) used two Altera FPGAs.

Commodore A2410 (1991) used a Texas Instruments TMS34010.

Digital Micronics Resolver (1991) also used a TMS34010.

Digital Micronics Vivid 24 (1992) used a TMS3020 and up to four TMS34082 coprocessors.

Ameristar 1600GX (1992) used a Weitek 91460.

Macrosystems Retina (1992) used an NCR 77C22E+.

Retina BLT Z3 (1994) used an NCR 77C32BLT.

Archos AVideo 12 (1992) used an Actel A1010 CPLD.

Archos AVideo 24 (1992) used two CPLDs.

Impulse FireCracker (1990), GfxBase GDA1 (1991), Harlequin series (1991), GVP EGS 110/24 (1992), and Rainbow III (1994) all used standard TTL and PAL logic ICs - no 'PC' graphics chips.

Oh, I guess then all those piccolo, picasso, cybervision etc. shouldn't count then.

'PC' graphics chips were used in later Amiga RTG cards, when they finally became powerful enough to be useful. But that had its downsides. Some chips were hard to obtain, and many had quirks that made it difficult to get the best out of them on the Amiga. But once that was taken care of they were cheap compared to an in-house design. The biggest problem was manufacturers kept changing their chips, and as time went on became more secretive about their designs. On the PC that wasn't (much) of a problem because the manufacturer supplied a driver, but on other platforms it became more difficult to support new chips.

But this is getting off topic. Nobody in 1994 was expecting Commodore to use PC graphics chips in the Amiga. We were thinking a few enhancements to AGA would do the trick, and that's probably what they would have done.

Racing wheel has nothing to do with joystick. It is about better experience in racing games and simulators. You can hook up usb gamepad from xbox to PC and play either digital or analog ... so what, it makes great difference when you can play such games with steering wheel and amiga had few as well. Those weren't popular not because mause or joystick can do better. Those weren't popular on amiga because there weren't many games making a decent use of analog wheel and pedals.

USB wheels and pedals weren't popular on anything in 1994. But all Amigas (except the CDTV and CD32) came with a mouse, whereas most PCs didn't. That's the real reason Amiga games used the mouse instead of an analog device, because it already had one. Why force users to buy expensive addons when they already have the hardware to do the job?

Most PCs of the time didn't come with a sound card or joystick interface either. Great for dealers - I sold heaps of them in my shop. I don't remember selling a lot of wheels and pedals back then, but I do remember having a demonstration unit that was always getting in the way.

The Amiga didn't have a lot of serious driving games, but it did have a good number of flight simulators and many of them supported analog joystick. Here's a (non-definitive) list of Amiga games with analog joystick support:-

A-10 tank killer v. 1.5
AV8B Harrier Assault
Birds of prey
F-19 Stealth Fighter
F-15 Strike Eagle II
Fighter Duel Pro-2
Fighter Duel: Corsair vs Zero!
Flight of the Intruder
Flight Simulator II
Formula One Grand prix / World Circuit
Gunship 2000
Jet Pilot
Knights of the Sky
Mig-29 Fulcrum
Mig-29 SuperFulcrum
Reach for the Skyoes
Red Baron
Tornado

One driving game you won't find on that list is Test Drive by Accolade, released in 1987 (was this the first Amiga driving simulator?). Here's what a reviewer on Moby Games said about the PC DOS version:-

The only real gripe I have with Test Drive (and all Distinctive Software, Inc. racing titles) is the controls. They all use an eight-way directional control, much like an arcade game... As a keyboard control mechanism, this is expected; for an analog joystick, it's completely unacceptable.

So much for a 'better experience'!

But there may have been a good reason for reducing the resolution. The Amiga reads analog joystick positions with hardware, while the PC has to do it in software. Here's some info on the PC analog joystick interface:-

This simple method for measuring the resistance value is quite cheap, but not very accurate. This simple joystick port hardware implementation (originally designed for 4.7 MHz IBM PC) causes many headaches to game programmers (problems of different computer speeds, joystick port differences, problems in multitasking operating systems etc.). Big tolerances in joysticks and joystick ports mean that the every game must have an option to calibrate the joystick

I remember lots of frustration trying to 'calibrate' joysticks on PCs. The game would show a list of supported joysticks and yours wouldn't be on it. So You try one at random and the controls are mixed up. Finally you find one that's 'compatible', then struggle to calibrate the stick. By the time you get it working reasonably well you have lost interest in playing the game - or perhaps that was the game!

[Thomas Richter]

Originally Posted by Bruce Abbott

You implied that few video cards were made for the Amiga because it didn't have an 'open' architecture, but now you are saying it was easy because the Amiga had an open architecture?

RTG on the Amiga did not work because of its operating system, but despite its operating system. The amiga graphics system, the graphics.library, is more or less bolted on the custom chips. Its entire design, bitplanes, copper lists, sprites, is designed to drive the Amiga custom chips.


It is hard to communicate how many patches and tricks it requires to get systems like P96 or CGfx running, it is more or less a complete replacement of the graphics.library, with some quirks and workarounds on other libraries. CBM did only very little (in Kick 3.1) to support RTG, and this approach was half-hearted and incomplete.

Originally Posted by Bruce Abbott

X-Pert Visiona (released in 1990) used two Altera FPGAs.

Commodore A2410 (1991) used a Texas Instruments TMS34010.

Digital Micronics Resolver (1991) also used a TMS34010.

Digital Micronics Vivid 24 (1992) used a TMS3020 and up to four TMS34082 coprocessors.

Ameristar 1600GX (1992) used a Weitek 91460.

Most of these early systems are not supported by any RTG system today. The P96 driver model is more or less a look-alike of the PC VESA Bios, and it reflects what most contemporary Super-VGA chipsets could do at its time.

Originally Posted by Bruce Abbott

'PC' graphics chips were used in later Amiga RTG cards, when they finally became powerful enough to be useful. But that had its downsides. Some chips were hard to obtain, and many had quirks that made it difficult to get the best out of them on the Amiga. But once that was taken care of they were cheap compared to an in-house design. The biggest problem was manufacturers kept changing their chips, and as time went on became more secretive about their designs. On the PC that wasn't (much) of a problem because the manufacturer supplied a driver, but on other platforms it became more difficult to support new chips.

Mostly because the vendors made their chips to fit to the driver model Microsoft implemented in Windows ("Designed for Microsoft Windows"), and then vendors kept their little secrets in their drivers, moving the interface from the hardware to the software side. Thus, at some point, it would have been necessary to implement something similar to the Windows driver model on the Amiga.

Originally Posted by Bruce Abbott

But there may have been a good reason for reducing the resolution. The Amiga reads analog joystick positions with hardware, while the PC has to do it in software.

No. The actual hardware does pretty much the same. Your average analog joystick was connected to your sound card (sound blaster, whatever), and it operates pretty much by the same design as the Amiga "Paddle" hardware. A simple ADC on the chip supplies the read-out, the only thing software has to do is to read a hardware register. There is no substantial difference between PC hardware and Amiga hardware in this regard.


The only difference is that on the Amiga, by tradition, digital joysticks were more popular, but one could also connect analog joysticks to the machine, then using a different set of registers.

[Locutus]

Originally Posted by Bruce Abbott

Macrosystems Retina (1992) used an NCR 77C22E+.

Retina BLT Z3 (1994) used an NCR 77C32BLT.

Commodore A2410 (1991) used a Texas Instruments TMS34010.

Digital Micronics Resolver (1991) also used a TMS34010.

Digital Micronics Vivid 24 (1992) used a TMS3020 and up to four TMS34082 coprocessors.

I dont get what your trying to say, all of those where also used in PC applications.

The NCR chips not extensively as they sucked massively, but here they are:

http://www.vgamuseum.info/index.php/...2-ncr-77c32blt
http://www.vgamuseum.info/index.php/...22-ncr-77c22-e

The Texas Instruments ones? funny you mention them as their biggest volume was likely accelerated PC graphics cards for things like MS AutoCAD and 3DsMax on MS-DOS -> http://www.vgamuseum.info/index.php/...hitecture-tiga

Some of the other cards you mention which didn't use a video chip use a bare frame buffer with a RAMDAC with sometimes a hardware cursor, in some cases one from Inmos (yes, the Transputer company), that's just trying to make a card as simply and cheaply as possible. Given those cards where still very expensive in their day i'm not sure i'd call that much of a special achievement.

[Bruce Abbott]

Originally Posted by Promilus

New amiga chipsets were made register-incompatible with OCS and AGA which means games designed to bang registers wouldn't work (directly). Only games designed using system libraries and calls would be able to handle new chipset and - at that time - there weren't all that many because even using best techniques OS still occupied some of the precious chipram.

There weren't any new Amiga chipsets beyond AGA. If there were then they might have done this, but that would have alienated even more users. So I think they would have kept OCS-AGA compatibility for many more years if they wished to survive. But this is why I say it may have been a good thing that Commodore collapsed when they did, before they had a chance to screw it up.

It could be used with smart buffering to dynamically load certain areas in the background when player was moving so without the need to load up whole map to memory (as it was pretty limited). That's thing which PS1 made frequently. It was hardly used at all on CD32. CD on CD32 wasn't used properly.

I used 'smart' buffering in my CDTV title - it was the obvious thing to do when you have DMA.

One advantage of CD is that files are contiguous. That means once you start reading a file you can continue reading sectors directly, knowing they will be in order with no gaps. This is similar to how some games store data on floppy. An early example of dynamic loading is The Faery Tale Adventure.

You say CD32 wasn't used properly. I say as time went on it would have been better utilized. Most developers were initially happy enough just having much faster loading times and virtually infinite storage space, but I'm sure it wouldn't have taken them long to use it 'properly' - had Commodore still been selling CD32s.

SX32 is rare expansion and hardly ever used by any CD32 specific game.

But Commodore had prototypes of the A1200 CD drive that showed their intention to include an 030. If they had gotten that out I'm sure developers would have made games for it. The SX32 would provide the same functionality for the CD32. I'm not sure how 'rare' it was, but that's not important. What does matter is that expansions turning the CD32 into a full computer were developed. That means someone thought people would go for it.

A few games that needed the extra horsepower were released for the A1200 in the mid 90's, but we are only now seeing what might have been if Commodore had lasted another year or so. Yesterday I downloaded a new Wolfenstein 3D port from aminet, and was surprised to find that it was too fast on my A1200 with 50MHz 030. And the sound was excellent too (much better than DoomAttack). A 14MHz 020 with some FastRAM might be the 'sweet spot' for this game. That shows what a moderately expanded CD32 or A1200 can do in the hands of a talented programmer.

[Thomas Richter]

Originally Posted by Locutus

I dont get what your trying to say, all of those where also used in PC applications.

The NCR chips are standard VGA chipsets, 2nd generation, nothing particularly fancy about them. The small 77C22E+ is underpowered, it does not have a hardware blitter and only segmented memory access (quite customary back them, but a PITA for the Amiga).

Originally Posted by Locutus

The Texas Instruments ones? funny you mention them as their biggest volume was likely accelerated PC graphics cards for things like MS AutoCAD and 3DsMax on MS-DOS -> http://www.vgamuseum.info/index.php/...hitecture-tiga

The TIGA chipset is a complete oddball and no wonders CBM dropped the A2410 based on the TIGA as a hot potato. You do not have direct framebuffer access, every rendering instruction has to go through the (embedded) CPU on the board. Thus, if you wanted to transfer a graphics from the host (PC) side to the graphics memory, a program on the graphics card had to pick up the data, and place it in the frame buffer for you. This beast is an absolute nightmare to work with.

Originally Posted by Locutus

Some of the other cards you mention which didn't use a video chip use a bare frame buffer with a RAMDAC with sometimes a hardware cursor, in some cases one from Inmos (yes, the Transputer company), that's just trying to make a card as simply and cheaply as possible.

Most of the 2nd generation VGA chipsets were like that: A VGA core chip, a separate chip as clock generator, and an external RAMDAC chip picking up the data of the core. So that design wasn't all that unusual. Also, that the RAMDAC generates the sprite (e.g. the brooktree RAMDAC on the Merlin) is not so unusual.


However, while most contemporary VGA chipsets at least implemented the EGA/CGA/VGA engine and register set, the Inmos is just a stupid framebuffer whose only advantage is that it has very high pixel clock of 110MHz, so you could reach resolutions beyond what contemporary chips could deliver.

Originally Posted by Locutus

Given those cards where still very expensive in their day i'm not sure i'd call that much of a special achievement.

Well, these were all "experiments in the field of graphics", and the winner - at least up to 3rd generation "SuperVGA" - was the VGA register set and the VESA Bios because that "kind of" worked as common basis.



Later on, some 3D chips with memory-mapped registers arrived, such as the Permedia3D chip, which did not use the VGA legacy registers for its advanced modes, but implemented its own specific register set (much saner than the VGA set, but also somewhat limited). By around this time, the interface moved away from the hardware (VGA register) interface to the software based windows "Direct Draw" interface, and vendors became more and more quiet about their hardware layer, delivering only drivers instead of datasheets.


For windows, this made perfect sense as software is easier to adapt than hardware.

[Promilus]

@Bruce

There weren't any new Amiga chipsets beyond AGA.

Sure there were. Designed. Not released and I never wrote they did release them. They started design in late 80s and continued up to 1993 then dropped entirely as it would be pretty pointless to release it at that time (since PC was already there). And AAA was AGA incompatible already. It's successor Hombre was even more incompatible because that's not only new chips but CPU as well. So yeah, I stand by my statement and you can believe whatever you want.

You implied that few video cards were made for the Amiga because it didn't have an 'open' architecture

No. I implied there were no worldwide amiga standard for early cards (and that's where you'll find most of exotic chip implementations) and when it surfaced most of the cards used PC chips. And you lie about pc chips "finally being powerful enough" - there hardly was anything about "power" there. Those chips didn't really do much back then. All they had to do is display image stored in framebuffer which was modified by CPU. And that's all the power there was - CPU itself was responsible for anything going on the screen when Amiga had several hardware sprites (PC 1 for cursor usually), bit blitter (well PC got that as well in later VGAs) and copper (which PC didn't have). On the other hand Tseng ET3000 from ~1989 had 8bit color depth from 18bit palette at 800x600, newer chips were able to go high color at that res when A1200 was released. Sure, almost nobody had such cards as they were extremely expensive but the same thing applies to Amiga video cards (and I'm not talking about adapter from video slot to VGA connector which is also considered video cards at bboah). Plus - should you at least try to remember we're still talking about popular amiga models which are A500, 600, 1200 - and nearly all of those graphic cards mentioned before are for A2000/3000/4000 (and same goes to those I/O cards etc. but I doubt many users needed 8 com ports and so on).

We were thinking a few enhancements to AGA would do the trick, and that's probably what they would have done.

What they were working on we already know and it never was anything AGA related. Or even tweaked AGA. So spare me those hypothesis about enhancements of AGA which - even if they did - would take yet another few years to complete (and obviously by that time it'd still be way too late to introduce new and improved aga).

USB wheels and pedals weren't popular on anything in 1994

There were gameport solutions at that time and even way before. Gameport used the same port as MIDI but it wasn't the same thing. Just the same physical port. And by the time it was implemented on soundcards I think there were no such speed constraints as in original solution from early 80s.

They all use an eight-way directional control, much like an arcade game... As a keyboard control mechanism, this is expected; for an analog joystick, it's completely unacceptable

Unacceptable is about 8way directional control when analog joystick is used. Not about analog joystick itself. And about your rant of PC joystick - that's from times where it was on dedicated card and software-driven by processor (taking a lot of it's time just to measure how fast capacitor charges). That's something which was old history by the time CD32 was released so I see no reason to bring that up in this thread when the time we're talking about is middle of 90s!

I used 'smart' buffering in my CDTV title - it was the obvious thing to do when you have DMA

So you did and glory to you. Too bad there weren't many developers seeing potential in the idea at that time. Don't feel bad, there weren't many for CD addons to Atari and Sega as well.

I say as time went on it would have been better utilized

As the time went on there would still be Sony Playstation and no SX32 would combat that threat. With 2D games it can emulate more sprites than several amigas together. And it can actually do decent 3D even without dedicated hardware 3D (yes, that's all software 3D). That's how powerful RISC with vector math coprocessor is. And there was nothing Motorola 68k could throw at that particular beast. Also any coprocessor doing intensive graphics math would need fast access to chip ram and chip ram was already slow (plus there was no direct interface for chipram on the expansion port). That's exactly the reason why - given time - CD32 still wouldn't be able to compete. And nothing planned by Commodore would. Just accept that simple fact already.

[dreadnought]

PSX hardware was great, no doubt, but it wasn't the only winning factor - after all Saturn wasn't far off, in fact some say it was more powerful, even if undeniably more difficult to code for. And N64 even more so, though they made a huge mistake of sticking with carts as the storage medium. Still, they were a heavyweight, established competition, but what Sony did was to aim for the the zeitgeist - and capturing it was a masterstroke. With PSX, gaming was no longer associated with nerds and kiddies, it has become a "cool" thing to do in clubs and after parties, and eventually broke into the real mainstream. Games like Wipeout employed the hippest design houses and put the underground chart toppers on soundtracks, others yet were "serious" PC imports such as Tomb Raider or Driver, and it all made Mario & Sonic look a little bit childish and dated.

All of this was not accidental, but carefully orchestrated and advertised, with support of Sony's mammoth budget. How on earth Commodore, a crumbling & uncool old-timer with empty pockets, was supposed to compete with such relentless (and expensive) tactical blitz is anybody's guess.

[Promilus]

after all Saturn wasn't far off

Saturn wasn't far off in numbers only. It had stupidly complex architecture which required a lot of effort from developers to use it efficiently and still lacking in 3D area. New libraries and devtools appeared eventually but it was still one giant PITA. N64 missed opportunity with CD and what's most funny Playstation is just a revenge on Nintendo because how it stood Sony up during initial design for CD add-on for SNES which ultimately was never accomplished and since Sega CD was relatively fruitless Nintendo ended any CD development for their consoles for quite some time (and with that foolish move they both created their worst enemy and severely constricted their new consoles with low capacity medium). Now the only thing which actually would've helped CD32 to thrive (slightly) was ... if Sony actually did that SNES Playstation. But since it didn't happen... I just can't see a scenario where it actually becomes popular. Not CD32, nor Amiga 1200 CD.

[dreadnought]

Originally Posted by Promilus

Saturn wasn't far off in numbers only. It had stupidly complex architecture which required a lot of effort from developers to use it efficiently and still lacking in 3D area. New libraries and devtools appeared eventually but it was still one giant PITA. N64 missed opportunity with CD

So, as I was saying...

[Bruce Abbott]

Originally Posted by Thomas Richter

The NCR chips are standard VGA chipsets, 2nd generation, nothing particularly fancy about them. The small 77C22E+ is underpowered... The TIGA chipset is a complete oddball

How 'fancy' or 'oddball' these chips might been is not important, what mattered was that they weren't solely designed to work in a PC and nothing else. Many Amiga graphics cards didn't use an 'industry standard' graphics controller chip of any kind. You could argue that this lead to them having worse performance than later PC specific chips, but this is not the point. When Amiga hardware designers wanted high resolutions, high color and video compatibility they didn't just wait for a PC chipset to come out that did the job, they designed their own circuits. And they were able to do it because the Amiga had an open architecture.

By around this time, the interface moved away from the hardware (VGA register) interface to the software based windows "Direct Draw" interface, and vendors became more and more quiet about their hardware layer, delivering only drivers instead of datasheets.

For windows, this made perfect sense as software is easier to adapt than hardware.

Not just for Windows. It's the obvious thing to do when you want to support different hardware configurations with the same software. MSDOS did it. Most 8 bit home computers did it too. But those earlier systems had simple enough hardware and sufficiently limited hardware variations that it was practical to bypass the OS and hit the hardware directly - which was often necessary to get acceptable performance.

For example if you stick to funneling everything through the BIOS your programs can work even on MSDOS machines that aren't IBM compatible. But BIOS functions like printing characters were so slow on the 8088 that application developers avoided them in favor of writing directly to screen memory. Once they did that graphics chip manufacturers were forced to make their chips compatible with IBM's video adapters.

In the early days of the Amiga it was considered acceptable to kick out the OS and take over control of the hardware completely, but this started to become problematic when new chipsets were introduced. Commodore withheld some information on the AGA chipset and told developers to go through the OS to initialize the hardware. Part of the reason for this change in policy was that as the chipset was being developed they encountered bugs and incompatibilities that they intended to 'fix' in software. By going through the OS, application programmers didn't have worry about supporting different chipset peculiarities in their own code.

Had Commodore continued to develop their chipsets this problem would have gotten worse. However at the same time CPUs were getting more powerful so the need to to bypass the OS was getting less. The move towards 3D and graphic adventure games also helped because they only needed a basic frame buffer. There's a lot you can do on the Amiga without kicking out the OS and taking over the entire system. The performance degradation is often minimum, and the advantages numerous. However unlike modern PCs it is possible to combine system functions with hardware banging code - at least on machines that were produced up to 1994.

[Bruce Abbott]

Originally Posted by Thomas Richter

RTG on the Amiga did not work because of its operating system, but despite its operating system. The amiga graphics system, the graphics.library, is more or less bolted on the custom chips. Its entire design, bitplanes, copper lists, sprites, is designed to drive the Amiga custom chips.

Obviously. But for the most part the functions supplied by graphics library are not tied to any specific chipset, and since every Amiga has the custom chips in it there is always a way for applications that need it to work.

It is hard to communicate how many patches and tricks it requires to get systems like P96 or CGfx running, it is more or less a complete replacement of the graphics.library, with some quirks and workarounds on other libraries. CBM did only very little (in Kick 3.1) to support RTG, and this approach was half-hearted and incomplete.

I fully appreciate the issues involved. But the problems are mostly due to this insistence on being 'RTG' in a way that that is totally transparent to the OS and applications. This was not the case on PCs, where users accepted that they would need new programs to use new screen modes.

Most of these early systems are not supported by any RTG system today. The P96 driver model is more or less a look-alike of the PC VESA Bios, and it reflects what most contemporary Super-VGA chipsets could do at its time.

So?

I am a user of P96 for the simple reason that the Vampire uses it. Now as you know, the Vampire does not have any PC graphics chipset in it, and yet it somehow still manages to work. P96 does not require that the hardware be a clone of Super-VGA.

...and then vendors kept their little secrets in their drivers, moving the interface from the hardware to the software side. Thus, at some point, it would have been necessary to implement something similar to the Windows driver model on the Amiga.

If the Amiga was to compete with PCs then yes, this would have been necessary. Luckily we don't have to worry about that. However in practice we do have something similar with P96 and CyberGraphX.

No. The actual hardware does pretty much the same. Your average analog joystick was connected to your sound card (sound blaster, whatever), and it operates pretty much by the same design as the Amiga "Paddle" hardware. A simple ADC on the chip supplies the read-out, the only thing software has to do is to read a hardware register. There is no substantial difference between PC hardware and Amiga hardware in this regard.

There is a substantial difference. On the Amiga all timing is done in hardware, and the CPU only has to read the resulting count from a hardware register. The timing is accurate because the hardware counts horizontal lines, and the CPU is free to do other stuff.

Interpreting Proportional Controller Position

On the PC the CPU has to wait on a bit in the I/O port while counting time. As well as wasting CPU cycles this can seriously impact multitasking and interrupts because for accurate timing all interrupts must be disabled for several ms (the entire time that the capacitor is charging), and it can reduce accuracy and calibration because the timing is dependent on CPU speed etc.

[Turrican_3]

https://mobile.twitter.com/commodore...74605457616908

There you go, straight from the horse's mouth.

[Korban]

Not to be negative, but I think that'd have just made the Amiga look even worse in the eyes of history.
It was already verging on obsolete technology wise in '94 while the rest of the tech world was getting more advanced at an astronomical rate.

[PortuguesePilot]

Originally Posted by Korban

Not to be negative, but I think that'd have just made the Amiga look even worse in the eyes of history.
It was already verging on obsolete technology wise in '94 while the rest of the tech world was getting more advanced at an astronomical rate.

Being level-headed, rational, realistic and factual should never be seen as being "negative". I - and many more - share your view on the subject. It's not what we wanted to have been or to have happened, but we are capable of understanding that our will or our needs beard no consequence on how things unfolded or where they ended up. Things are what they are, regardless of what we wanted them to be. Not acknowledging this is being in denial.

[Thomas Richter]

Originally Posted by Bruce Abbott

How 'fancy' or 'oddball' these chips might been is not important, what mattered was that they weren't solely designed to work in a PC and nothing else.

Huh? Is there a "not" too much? The NCR chipsets were surely designed to work in a PC, simply because they use the standard IBM register set for that. It's just a tiny little bit extended (as customary back then) to allow larger resolutions. The INMOS and TIGA chipsets are indeed quite different and not PC-like, the TIGA not at all.

Originally Posted by Bruce Abbott

Many Amiga graphics cards didn't use an 'industry standard' graphics controller chip of any kind.

Actually, most, if not all use an 'industry standard' graphics controller chip. The only exceptions I'm aware of are the A2410, with its TIGA chipset, and the GVP Spectrum 110 which uses the INMOS chip, and of those, only the TIGA is really exceptional (..ly insane).

Originally Posted by Bruce Abbott

You could argue that this lead to them having worse performance than later PC specific chips, but this is not the point. When Amiga hardware designers wanted high resolutions, high color and video compatibility they didn't just wait for a PC chipset to come out that did the job, they designed their own circuits. And they were able to do it because the Amiga had an open architecture.

Huh? Of course the IBM PC had an open architecture as well, that was the whole key to its success. The VGA chipsets as well. You find all the registers and features documented in their datasheets. That's as open as it gets.


It only became worse after that point due to the "designed for windows" policy, which allowed chip vendors to move the interface from a hardware to a software interface. However, the same would have been necessary in the long run on the Amiga as well simply because the hardware interface is just not flexible enough and hard to upgrade.

Originally Posted by Bruce Abbott

But those earlier systems had simple enough hardware and sufficiently limited hardware variations that it was practical to bypass the OS and hit the hardware directly - which was often necessary to get acceptable performance.

And became unnecessary and a hindrance later on.

Originally Posted by Bruce Abbott

For example if you stick to funneling everything through the BIOS your programs can work even on MSDOS machines that aren't IBM compatible. But BIOS functions like printing characters were so slow on the 8088 that application developers avoided them in favor of writing directly to screen memory. Once they did that graphics chip manufacturers were forced to make their chips compatible with IBM's video adapters.

The problem with the Bios functions was that they weren't designed for graphics output, or rather, their abstraction were unsuitable. You don't design a Bios interface for "set pixel at x,y" because creating an entire graphics through such a function will necessarily be slow.

Originally Posted by Bruce Abbott

Part of the reason for this change in policy was that as the chipset was being developed they encountered bugs and incompatibilities that they intended to 'fix' in software.

No, part of the reason was that CBM wanted a migration path to newer hardware without having to worry about software too much. MS did the same, and it is of course the right move. It was just too late, and the graphics.system of the Amiga is not exactly the right foundation for this move, with its "bitmaps", "bitplanes" and "masks", all oriented at a planar graphics layout.

[A500]

Originally Posted by Turrican_3

https://mobile.twitter.com/commodore...74605457616908

There you go, straight from the horse's mouth.

Just out of curiosity, how would the PA-RISC follow-up to CD32 have compared to PS1? I'm guessing the answer is "poorly", but I also know nothing about the hardware described in the document.

[Bruce Abbott]

Originally Posted by A500

Just out of curiosity, how would the PA-RISC follow-up to CD32 have compared to PS1? I'm guessing the answer is "poorly", but I also know nothing about the hardware described in the document.

That's OK, you don't need to know anything to conclude that any Amiga product compares 'poorly' - it's a given. Or if it isn't, we will minimalize/ignore it and/or tell lies to make it appear to compare poorly. It's the Amiga way!


Here's an interesting document dated 11th May 1993. Some highlights:-

Future Product Options
A Software Perspective
Software Engineering Department, Commodore International Services Corporation

Architectures

Currently available, or under development, processor architectures are:
· MotorolaMC680x0
· Hewlett-Packard PA-RISC

and graphics architectures are:

· Advanced Graphics Architecture see AGA
· AAA (chipset)
· 3D Graphics Engine

All of these architectures are flexible and can be adapted to the needs of various market segments by system hardware and software configuration.

In addition, a number of graphics boards are available from or under development by third parties. Availability of and support for such products can contribute to Commodore's position in a number of specialized market segments, such as high-end graphic arts.

Short-Term Recommendations

Recommendations for short-term development strategy are:
· Develop CD32-compatible CD-ROM peripherals, tentatively designated CD1200 and CD4000, for the A1200 and A4000, respectively, to improve the competitiveness of these systems with Multimedia PC (MPC)
systems and expand the market for CD-ROM applications by adopting CD-ROM technology throughout the product line. Both of these products are already under development.

· Develop an A1200-compatible computer module for the CD32 system to provide an upgrade path to full computer functionality. This differentiates the CD32 from competing home entertainment consoles, such as the Super Nintendo Entertainment System (SNES)and Sega Genesis and MegaCDX systems.

· Develop an evolutionary improvement of the CD32, tentatively designated CD32 Plus, with built-in MPEG capabilities, expanded nonvolatile storage, and other improvements, with a critical emphasis on maximizing compatibility with CD32 applications, for release in late-1994 if a safe evolution of the existing platform is necessary to maintain competitiveness with other home entertainment consoles...

These short-term recommendations have a strong emphasis on the CD32 system. This recognizes the significant development, manufacturing, marketing, sales, and distribution resources that Commodore has committed to this product and the resulting importance of this product to the short-term success of the Company.

Long-Term Recommendations

Recommendations for long-term development strategy are:

· Develop a new release of the Amiga Operating System, tentatively designated Amiga Operating System Release 4.0, that implements retargetable graphics (RTG) and other features necessary to remain competitive in existing market segments and improve Commodore's position in new market segments.

Implementation of RTG will provide Commodore and third-party developers a stable, supported mechanism for improving the graphics capabilities of existing open Amiga systems (such as the A4000) via high-resolution/high-color graphics boards, maintain compatibility with existing applications because the AGA chipset can continue to be accessed as before, and maintain or improve the competitiveness of these systems with other open platforms.

· Develop a new architecture based on the Hewlett-Packard PA-RISC and the 3D Graphics Engine and systems based on this architecture on a fast-track schedule.

Options for systems based on this architecture include:
· CD3D (low-end CD-ROM- or cartridge-based entertainment and home education console)

· RISC1000/3D (mid-end personal computer)
Initial development of this architecture is currently underway.

· Develop a new operating system for the PA-RISC/3D Graphics Engine architecture on a fast-track schedule. The basic configuration should be a scalable, multitasking operating system designed for entertainment and edutainment applications. Optional components should provide additional features necessary for productivity, multimedia, and other higher-end applications.

Other Long-Term Considerations

· It is not apparent that the demand for systems based on the MC680x0/AAA architecture is sufficent to justify the development time and cost of this architecture. However, if a sufficently large market need is identified, systems based on this architecture, tentatively designated A1400 and A5000, should be developed. Retargettable graphics drivers and other operating system support should be implemented as necessary to support this new architecture.

· It is particularly important that a AAA-based home entertainment console, similar to the CD32, not be developed or publicly discussed. Such a system would be incompatible with existing CD32 applications and thus lack the software base that is a major factor in the sales of any home entertainment console...

Early design work is currently underway for an architecture based on the Hewlett-Packard PA-RISC CPU and a custom 3D graphics engine. In view of Commodore's position, two desirable system options based on this architecture are:

· A low-end cartridge- or CD-ROM-based home entertainment and edutainment console, tentatively designated CD3D.

· A low-end personal computer, targeted toward home entertainment, edutainment, and productivity applications, tentatively designated RISC/3D 1000...


In addition, a high-end personal computer, tentatively designated RISC/3D 2000, could be developed from this architecture to address the productivity and multimedia market segments. However, in view of Commodore's historically limited success in these market segments, this should be considered only if a significant and recognizable advantage over competing systems is identified...

The 3DO and Atari Jaguar systems, which are currently available or near release, provide these capabilities, as will systems currently being developed by Nintendo and Sega. In view of this situation, the PA-RISC/3D Graphics Engine architecture is essential to the long-term competitiveness of Commodore.

In 1993 Commodore was already working on a PA-RISC architecture CPU with custom 3D graphics engine and an RTG operating system to go with it, as well as expanding the CD32 and A1200.

However you think PA-RISC may have compared to the PS1 in 3D gaming performance, there is no doubt that it would eat it for lunch in other areas. The PS1 had no OS to speak of and was useless for anything but 3D games. Neither did it provide an upgrade path or commonality with any computing platform past present or future.