It took between 8 and 17 years for the PCs and Macs to catch-up to what Amigas were doing in 1985. Even today modern Amigas have a lightwieght OS that runs circles around Mac or PC OSes. You don't need 1 gigabyte to get the job done. 0.1 gig and 1 GHz is enough.
I think your comparison is a bit off.
The original Amiga had a palette of 4096 colors, but could only display 32 of them simultaneously (5bpp CLUT). EHB6 was a kludge. The IBM PC mostly surpassed it in 1987 with the VGA chipset, both in depth and palette, and the Amiga never caught back up. Sure, the blitter was an advantage, but raw color depth won in the end.
The original Amiga had four 8-bit digital channels that could handle 20-26KHz audio. It had no frequency-modulation support. The IBM surpassed all this in in 1991 with the Soundblaster 2.0, and the Amiga never caught back up.
Sure, Autoconfig and the Zorro bus beat the crap out of what the PC had until VLB (some would say PCI). But the vast majority of Amiga users had a 500, 600, 1000 or 1200. You got one processor bus slot. Early Amiga 3000 users had a busted Z3 bus because of a bug in Buster. Meanwhile, the majority of PC and clone users had multiple slots, and could upgrade easier as new peripheral cards became available. They didn't need to replace broken bus controllers, either.
While AmigaOS 1.0 and later supported pre-emptive multitasking, the majority of entertainment software released for the Amiga disabled multitasking. The majority of Amiga owners were home users playing games. Therefore, the majority of the time, Amiga users were singletasking.
The lightweight nature of the kernel isn't really relevant in a world where your core processor is 100MHz or faster. And once you cross that bridge, you don't want that lightweight kernel - it's lightweight because it uses a flat, open memory model where a single stray pointer can crash your system. I want memory protection. And memory virtualization kills the beast known as memory fragmentation. It also delayed the need to jump to a 64-bit memory model for a number of years.
Don't get me wrong. I loved my Amiga 500. But I was highly disappointed with my Amiga 3000 - no real improvement in color depth, palette depth or sound resolution. Too many programs relied on a 7.15MHz 68000, which never would have happened if the Amiga 2000 came with a 10.73 or 14.32MHz 68000. Worse still, few non-productivity programs used the extra speed of the 3000's 68030 because the Amiga 600 still used a 7.15MHz 68000. And even after upgrading to 2.04 ROMs, it crashed all the time. The A3000 and 2.04 would have been the perfect time to introduce MEMF_PRIVATE and MEMF_CODE. No reason for userland programs to write freely to kernel space or over its own code segment.
I expect that the majority of these systems will be replaced in the next five years as everyone switches over to HD.
Even if you could find a used Cybervision or similar Amiga video card that could be tweaked to display HD resolutions, would existing presentation programs work with them correctly? Could they handle 16:9 aspect ratios? Would it even be worth the cost of hardware and labor when you could purchase turnkey PC solutions for less?
The Playstation would have devastated sales of the CD32 had Commodore still been in business in late 1994. One major reason was because Sony sold their hardware at a loss, subsidized by licensing fees collected against software sales. The MSRP of the PS1 was $299.
IIRC, Commodore made their profit from the CD32 up-front. They were eying a MSRP of $399 for its US launch. We can only speculate how much cheaper it would have been a year later.
I'm not sure if Commodore adopted it, but IMHO, it would have been suicidal for Commodore to try to use the subsidized hardware model with the CD32 since so many users would have bought it with the sole intention of turning it into an A1200 clone. Cheap users would then buy or pirate desktop versions of games, robbing Commodore of their ability to profit from the console.
Re:IBM PCs compared extremely poorly with Amigas
on
The Amiga Turns 25
·
· Score: 1
I think it was less about open architecture and more about forward momentum.
IMHO, I believe that the IBM PC won and the Apple Macintosh survived is because they were constantly improving. You can see a clear line of succession from the original PC to the AT. The line is a bit more murky with the Macintosh, but it is almost spastic with the Amiga.
Imagine if Commodore had released a new Amiga chipset every two years with incremental upgrades to every part of the system, all tied to a slightly faster processor. Do you think they would have remained more competitive? Would you have been excited if Commodore had released the Amiga 2200 in 1988 with a 14MHz 68000, an Enhanced Denise with support for 320×200×8bpp CLUT and HAM screen modes and an Enhanced Paula with 6-chan 8-bit 32KHz audio and native IDE support? I know I would have.
Based off of some of David Haynie's comments, it just sounds as if some of the chipset designs, including Hombre and AAA, were just too advanced and too aggressive for the fabs at the time. Meanwhile, management's obsession with the word "cheap" kept the platform from evolving properly.
And even if you had a graphics.library that abstracted the hardware properly, nothing would prevent an application from going around it. App developers did what they wanted. How many apps were floppy only, didn't allow task switching, and banged the hardware like a cheap date?
They should have made device independent graphics a priority from the start
While you could make the argument that the Amiga 2000, 3000 and 4000 should have had Denise and Lisa on a peripheral card, you can't really make that same argument for the Amiga 500 or 1200. It would have been cost prohibitive.
Also complicating things are Agnus and Alice. The older chips wouldn't have had enough address lines to support the size of the graphics buffers needed by each newer generation of chipset. I guess they could have added more address lines to Agnus from the start, that would increased manufacturing costs while decreasing the amount of memory left for fast RAM on the processor local bus (remember... 24 address lines... 16MB total between chip and fast)
No, I was talking about Mach, which was standing on its own feet by 1986. Although you could debate as to if it was more Mach or more BSD at that point...
Kernel != OS
True. But remember that the Amiga 1.x userland was fairly spartan. The magic was all up in the kernel.
VM was a good idea, sure... but not for the kind of small computers Commodore was doing in 1985... turning AmigaOS into UNIX would have ruined it
Yup, I just said that.:)
I was thinking along the lines of using a flat memory model where you kept your linear and physical addresses in sync, only using the MMU to generate protection faults.
And as far as 68020 + 68851, yeah, that became a solution. It wasn't a solution in 1985, the 68851 didn't work yet. Everyone doing UNIX workstations on 68K were building their own MMUs. Not to mention the fact that the 68020 was a $300 chip...
$300 for a 68020? Ouch. How much was the 68010 running in 1985? It would have worked just as well...
If the 68851 wasn't available yet, and since the 68451 was reported to have been a POS, how hard would it have been to have rolled your own MMU for generating protection faults? Could it have been something that could have been added to Agnus?
The WDC 65816 was technically an 8/16-bit version of the 6502, but it was a pretty ugly hack.
Agreed. The 65816 could be an ugly processor to deal with. And you’re right, only a handful of instructions could use long memory addresses, and only three addressing modes were available for long addresses. For everything else, you had to work within your 64KB bank unless you wanted to start messing with the data or program bank offset registers.
However, if the bulk of your program’s code and data could fit inside one bank, then it worked like an enhanced 65C02. In which case the 65816 was somewhat nice to deal with. Makes me wish that the 8502 had used a 65C02 derived core...
The C128's MMU actually made things much easier to deal with, in the specific case of 128KB of memory
But it was still bank switching, and bank switching is evil. If I could have a nickle for every time I fought with an expanded memory manager on a PC...
But yeah, while the MMU in the C128 was tolerable, it would have seriously kicked ass if I could have just flipped a bit and turned the processor into an enhanced mode that upgraded all of the 16-bit memory modes to 24-bit, upgraded the index registers to 16-bit, and would have added 16-bit counterparts to the 8-bit relative displacement Bcc branches.
It was pretty obvious the C128 was the end of the line for 8-bit at Commodore, so there wasn't a great deal of looking forward in the C128...... also not the budget we really wanted for it.
I never understood that. I always thought that the jump from the C64 to the Amiga was a fairly huge one, both in feature set and in price. The C128 would have made a nice filler machine for that market. Instead, it just seemed like an expensive C64 with a few bolt on features. Other than some BBS admins, I don’t remember anyone being excited over the C128.
And I never considered the 8-bit data bus or the 16-bit ALU of the 65xx series as a terminally limiting factor to the platform. I knew a few folks with IBM XT systems who had upgraded to VGA and Soundblaster cards. 256 colors and 8-bit digital audio all being processed with that crusty 8088, all under DOS.
If your budget was tight, then it seems like a lot of resources were wasted on adding the Z80/CPM support. And it must have killed your manufacturing cost per unit. It just seem as if better graphics, better audio and/or a better CPU would have made more sense. I mean, come on, even the C16 had a better color palette than the C128.
I disagree. I would actually suggest that Carnegie Mellon’s Mach was the best kernel of the time.
The majority of AmigaOS’s faults come from two issues: the use of TRIPOS rather than CAOS for AmigaDOS and the lack of better memory management. Although some might point out that those two are the same issue.
Programming in C for the Amiga back in the Kickstart 1.x days was a little rough with AmigaDOS. Once you learned how to program for Exec, you had to relearn how to program for AmigaDOS since it was BCPL based with its own unique set of structures.
Another problem is that the OS was prone to memory fragmentation. With BSD, you get a layer of abstraction because of virtual memory. With WinAPI, you get it from the use of handles. That allows the OS to perform housecleaning in the background. AmigaOS had none of that. No abstraction, no garbage collection. CAOS was supposed to include some limited management that reduced fragmentation without the speed hits that memory abstraction introduces.
The memory management issues also come from the use of a 68000 as opposed to a 68020 + 68851 as the baseline processor. Userland programs could trash the kernel and could trash or self-edit themselves because “.code” regions were read-write. There was also no way to mark memory as private, so you had to hash your passwords in memory to prevent eavesdropping. Fully virtualized protected mode like SYS.V, BSD, VMS and Win32 used would have been overkill for the time, but the all open wild-wild west of the 68000 was just as bad.
I’d actually argue that the Commodore 128, Commodore 65 and CBM-II series were all mediocre successors to the Commodore 8-bit line at best. I even suspect that had the Amiga not fallen into Commodore’s lap, they might have gone bankrupt because of it.
The main problem with all three systems was their CPU. The MOS 8502 found in the C128 and CBM-II as well as the CSG 4510 in the C65 could only access 64KB of memory directly, so they all relied on bank switching to get around the limitation. Bank switching SUCKS. It is even worse than the 20-bit segmentation model found in the i8086/8088.
Apple ended up using the WDC 65816, which included a limited set of op-codes that could handle 24-bit “long mode” addresses. But it was a bolt on feature at best, and was severely limited. A better option would have been if the MOS 8502 came with a new memory mode where all existing 16-bit ($xxxx) ops could have been extended to 24-bit ($xxxxxx) instead. A processor with a flat 24-bit memory mode would have been very easy to work with.
All of the C128’s other major faults (graphics and audio) are all secondary. Sure, had they either adopted the MOS 7360’s 121-color Y/C palette or a 64-color RGB6 palette, it would have been great. Had they adopted stereo SID and/or added frequency modulation, it would have been great. But in the end, the processor would have crippled it. Just try programming for the C65 emulator under M.E.S.S. and see for yourself.
There are several products currently on the market that allow you to perform geographic load distribution via DNS. These products look at your LDNS server's address and either attempt to triangulate using a reverse DNS lookup to the LDNS server, calculating number of hops and/or round-trip times to that LDNS from each of your sites, or they use static IP range tables broken down by region. The assumption is that a client in somewhat close proximity to their LDNS server.
The problem with these methods is that some very large ISPs may use only a couple of LDNS servers for an entire continent. In the case of third party DNS services, it grows to being a couple of LDNS servers for the entire planet. So there is no geographic unity between client and LDNS server.
This proposal helps a bit, but unless it includes a method where a LDNS server can be told that a DNS query's response is only good for that client's/24 subnet (or any varying mask bitlength), you'll still end up with clients clobbering each other with these geographic load distribution products unless you set the TTL to 1 second. That work around has the nasty side effect of increasing your DNS load by an exponential factor, which isn't good either.
More and more people consider their pets the same as family. That's one reason why you keep hearing the unflattering term "fur children" increasingly used to describe peoples' relation to their pets.
To these people, forcing their pets to spend their flight in the cargo hold is tantamount to cruelty. And how dare a company be cruel to anyone's child.
As more and more people get this unhealthy obsession with their pets, expect more laws being passed that allow them to bring their pets everywhere, including flights.
I can only imagine how people with allergies are going to respond. Maybe they can sue under the ADA here in the US. Who knows how the courts in Canada would rule.
The custom chips were originally Commodore's key to success, but they did absolutely become a boat anchor.
I guess while I have you on the subject, what DID actually happen between OCS and ECS?
I keep hearing rumors about Miner having "something good" over at Los Gatos (Ranger), but some of it doesn't make sense. If the rumors about the VRAM costs were true, why didn't the Paula replacement make it out? And why was the ECS Super Denise anything but super?
This was back in the days when PCs and Macs were struggling to deliver better than 1MB/s, and both were using PIO.
Now you've made me curious. EISA was on the market around the time of the A3000, even if it was a rare sight. I vaguely recall that the Adaptec EISA SCSI card in my old NT-based DEC Alphaserver could do bus mastering DMA. I believe that Intel boxes with EISA could also do busmaster DMA transfers, too... (checks Wikipedia)...which they supposedly could. I wonder how fast they were.
The NCR53C710 chip was so frickin fast
Yes it is. That's why I still have my DKB 4091 after all these years.
You'd do better with a 14Mhz '020 or even EC020 than 20MHz 68000 on most code
Right, the 68020 could do much more per cycle than the 68000. However, I'm being hypothetical here. If Commodore management was unwilling to fund the design of a new 68020-based entry level motherboard, how much effort (and cost) would it have taken to modify the existing A500/A2000B motherboards to handle a 68HC000 running at 14 or 21MHz?
I guess the biggest question would be bus timing. Was the custom chip bus running synchronous or asynchronous with the 68000 bus on the A500, A600 and A2000? How fast could you drive the ECS chips? If not very fast and if the custom chip bus was running in sync, how hard would it be to upgrade the buffers and DMAC used to interface between the two buses so that you could decouple the 68000 bus and run it faster?
So C= was not quite 1/5th the size of Apple in those days
Are you talking mid-80s or late-80s? I always thought that Commodore came close to running Apple into the financial ground with its price war with TI. That, and the money they hemeraged with the Apple III and Apple Lisa. I would have thought that Apple would have consolidated heavily as a way to stop bleeding money, including its R&D division.
The custom chips were originally Commodore's key to success, but they did absolutely become a boat anchor
Depends on how you look at it. They're only an anchor if the cost to develop them outweighed the advantage they'd give you in the market. Just look at the money that companies like Sony, 3dfx and Nintendo made with their custom graphics chips during the '90s.
To me, Commodore's later custom chips for the Amiga (ECS, AGA, AAA) always seemed to be an anchor because they were always behind the curve. OCS and Ranger seemed to be the only two that were ahead. So of course it was better to look outside the company - it sounds as if internal R&D couldn't keep up due to budget constraints and managerial interferrence. You guys were always months, if not years, behind the PC and workstation (SGI, Sun) markets. Too little, too late.
As for going to HP, that was probably a brilliant idea. It was one thing to roll your own chips by that point. It is another to try to run your own fabs. Mensch knew not to play that game when he founded WDC, as did Wilson and Furber over at Acorn/ARM.
Very early models of the Amiga 3000 came with an alpha version of Kickstart (V36/KS1.4) used for bootstrapping the system. The system would then attempt to load your main Kickstart image (DEVS:Kickstart) from floppy or hard disk.
In order to use a 68040, you had to have Kickstart 2.04 or 3.1 in ROM. As such, very early A3000 models were not offered with 68040 options because the ROMs weren't available yet. Also, it is my understanding that Commodore used full versions of the 68030 as opposed to cheaper 68EC030 parts because they needed the MMU to remap the softkicked Kickstart in memory.
If Commodore did offer a 68040 version of the Amiga 3000 desktop, it was simply an '030 model with a Commodore A3640 processor card installed.
On the other hand, none of the PCs or Macs had hard drive performance capable of real video... the Amiga 3000 did.
A stock Amiga 3000? I recall the onboard NCR chipset being a little sluggish. My drives really didn't start to zip until I tossed in my 4091, even with my original Quantum LP52S. I also recall moderately high CPU utilization with the onboard NCR, which my 4091 also corrected.
The original project for a next-generation chipset was started in 1988
Which was already too late. I know that technology didn't move as fast back then as it does now, but Commodore should have been starting work on a next-gen chipset as soon as the Amiga 2000 hit the streets back in 1986. "ECS" should have been released no later than 4Q88. Just look at the amount of time between the release of EGA (1984) and VGA (1987) by IBM.
but underfunded
Underfund your #1 moneymaker. Always a bright idea. Wouldn't expect anything less from Commodore.
The C65 was a stupid idea, and I believe it happened mainly because no one else wanted to work with the engineer involved, so they just left him alone.
Personally, I think every 8-bit machine released after the C64 was dumb. Both for how they were built, when they were built, and for whom they were built.
The C16/C116/Plus4/C264 were all stupid. The C116 was a toy with its membrane keyboard. The Plus/4 and C264 were too close to the price of a C64. The C16 should have been a compatible successor to the VIC-20, including its hardware periphials. Bugfix the CIA, keep the TED's 121-color 40×25 text mode, and match the VIC-I's sound capability. Market it for little kids and emerging markets.
The C128 was stupid. The Z80 coprocessor made it too expensive (and should have been made as an add-on cartridge instead). The bank switching on the 8502 made it too difficult to program. The VDC offered no real-world improvement in video over the VIC-II, other than its 80-column mode which required a special monitor. The SID should have been improved to support full FM synthesis, or at least [the inferior] phase distortion synthesis if Commodore didn't want to pay FM synth patent royalties to Yamaha. If the C128 could have done 160×200×8c, 320×200×4c and 640×200×2c with the C16's 121-color palette and the C64's eight sprites, using the Y/C connector as opposed to RGBI, all with a flat 24-bit memory bus, it would have done (IMHO) much better than it did.
The C65 came too late with the specs it had. The VIC-III was a cool chip, but the 4510 sucked for the same reason as the 8502. Again, mate the VIC-III to a WDC65816, 256KB of mem and an improved SID, and I still think it would have sold if priced very well (and in the right markets), even as late as '90. But by the time '92 rolled out, such a system would have been a dinosaur and a joke, even in Yugoslavia. I think Commodore had unrealistic pricing expectations around that point for their low-low end, being even more unrealisic thinking they could do it with an Amiga.
The A3000 has every area of the system we could improve improved, without the new custom chips. Some of that got expensive, which is why it didn't immediately trickle down to cheaper systems. That was Spring of 1990.
Which is why I don't understand why Commodore just didn't crank up the speed using legacy board designs for their entry level Amigas. Again, Motorola had a 20MHz 68HC000 out by 1990. Other than faster memory/core/logic chips, you could have essentially recycled the older 16D/24A bus from the A500/A2000 for very cheap.
I had an early A3000/030-16 model with KS1.4 in ROM, and I don't recall paying more than $2500 for it. Maybe that was for the 68040-25 model during the first weeks of sale?
What was with that "flicker fixer" thing it apparently used?
The flicker fixer was essentially a line doubler that took 15KHz 480i video and converted it to 31KHz 480p video. Commodore essentially took the A2320 flicker fixer for the Amiga 2000 and intergrated it onto the Amiga 3000 motherboard. They even used the same AMBER chip as the A2320 used. Nothing fancy about it.
[The A3000] may have had a faster processor, but they didn't do the same with the mainstream Amigas.
Correct. Both the Amiga 500+ and Amiga 600 used the same 7.16MHz 68000 as the original A500, which was really retarded. Models of the 68HC000 existed at the time that could have been clocked at 14.32MHz and 21.28MHz. Boosting the clock speed and switching from an NMOS to CMOS processor would have required relatively minor changes to existing logic board designs (as opposed to switching to a 68EC020).
But that replacement should have been the A1200, [not the A600,] which came out six months after
The A600 never should have been released when it was, or how it was. It should have been released in tandum with the A3000, preferrably with a full keyboard, faster processor and graphics comparable to XVGA.
No, the "Amiga 300" pricepoint should have been served by an Amiga, or they should have continued to sell the existing C64 at a bargain price.
The C64 was almost a decade old. It never would have sold as-is, except in maybe in emerging markets. The C128 was simply too complex and too expensive to manufacture. A new computer with the WDC 65816, 256KB of memory, the VIC-III and six-channel SID might have been manufactured for close to $100, well within the target price of the original Amiga 300 vision.
VGA did have a better indexed color depth at 320×200 (8-bit for VGA, 5-bit/6-bit EHB for OCS/ECS), as well as a larger palette (18-bit for VGA, 12-bit for OCS/ECS).
However, VGA was a very simplistic frame buffer. There were no masked block move functions, and it was limited to a single sprite. The Amiga chips supported 8 sprites and complex bit blitting through the Blitter.
As a result, after the release of VGA, games with a lot of static graphics tended to look better of VGA. Side scrollers and other sorts of arcade games looked better on the Amiga.
Let me rephrase and clarify. During the period of 1990-1996, I was not aware of a single person who went from the Amiga to Linux as their primary desktop OS.
However, during that time, I was aware of quite a few people who experimented with BSD. People who had a full 68030 or 68040 in their Amiga tried NetBSD, while those who switched to the PC generally tried FreeBSD.
I don't recall anyone from my old Amiga community talking about Linux until around 1998 or so. But by then, I had lost ties to many of those people.
I agree. Most Amiga users I knew ended up getting a PC with Windows because that's where all of the games ended up going. I knew a few who went to Macs. I'm not aware of a single one who went to Linux, and I was fairly big into the Amiga scene in my area at the time.
I think/.'s wishful thinking crowd is getting ahead of themselves.
Commodore put the gun to their head in 1990 with the introduction of the Amiga 3000. They pulled the trigger two years later with the release of the Amiga 600. It just took a few years before the body would finally die.
Neither the A600 nor the A3000 introduced any discernible enhancements to the product line over that of the A500 or A2000. It also failed to meet or beat the color performance of IBM's VGA chipset. In fact, it was actually advantageous from both a price and performance standpoint to buy an A500 or A2000 and then expand using third party devices.
Commodore might have been able to survive as a console manufacturer, but never as a desktop or workstation manufacturer. Apple and the PC clone market was hammering them on the low end while SGI, Sun and NEC was hammering them on the high end.
The sad thing is, all they needed to stay on top was something between the OCS and AGA. For 320×200, a 7bpp indexed color mode (128 colors) with a 15-bit palette. Toss in EHB8 and HAM8 as well. For 640×200, introduce a EHB5 mode. Lastly, bump the sound from 8-bit PCM to 12-bit ADPCM. Lastly, move everything to a real 32-bit bus, unlike this hybrid 16/32 crap the A3000 used.
Really, nothing revolutionary. And as for the so-called "Amiga 300" Commodore was looking for, they could have just released the never released Commodore 65 with a WDC 65816 at its heart instead. Cheap enough for emerging markets and Wal-Mart.
Amiga, for those who were into PCs, really, was a story about hardware that was way ahead of its time for the price.
For the Amiga 500 and 1000, I very much agree. Nothing could really touch them when it came to performance for their price. But for every other Amiga model, it is a debatable statement. Feature stagnation really robbed them of their advantage in the marketplace.
Had Commodre switched to a 14MHz 68000 for the Amiga 600 and 2000, as well as to an improved Denise with slightly higher color depths, I'd say that they would have remained unbeatable. Had the A3000 been released with something similar to AGA, it again would have remained untouchable.
But as it is, Commodore screwed the pooch with just about everything after the A1000. Which is why they are gone.
Slashdot Mirror
It took between 8 and 17 years for the PCs and Macs to catch-up to what Amigas were doing in 1985. Even today modern Amigas have a lightwieght OS that runs circles around Mac or PC OSes. You don't need 1 gigabyte to get the job done. 0.1 gig and 1 GHz is enough.
I think your comparison is a bit off.
The lightweight nature of the kernel isn't really relevant in a world where your core processor is 100MHz or faster. And once you cross that bridge, you don't want that lightweight kernel - it's lightweight because it uses a flat, open memory model where a single stray pointer can crash your system. I want memory protection. And memory virtualization kills the beast known as memory fragmentation. It also delayed the need to jump to a 64-bit memory model for a number of years.
Don't get me wrong. I loved my Amiga 500. But I was highly disappointed with my Amiga 3000 - no real improvement in color depth, palette depth or sound resolution. Too many programs relied on a 7.15MHz 68000, which never would have happened if the Amiga 2000 came with a 10.73 or 14.32MHz 68000. Worse still, few non-productivity programs used the extra speed of the 3000's 68030 because the Amiga 600 still used a 7.15MHz 68000. And even after upgrading to 2.04 ROMs, it crashed all the time. The A3000 and 2.04 would have been the perfect time to introduce MEMF_PRIVATE and MEMF_CODE. No reason for userland programs to write freely to kernel space or over its own code segment.
I expect that the majority of these systems will be replaced in the next five years as everyone switches over to HD.
Even if you could find a used Cybervision or similar Amiga video card that could be tweaked to display HD resolutions, would existing presentation programs work with them correctly? Could they handle 16:9 aspect ratios? Would it even be worth the cost of hardware and labor when you could purchase turnkey PC solutions for less?
"Database Error: Unable to connect to the database:Could not connect to MySQL"
The Playstation would have devastated sales of the CD32 had Commodore still been in business in late 1994. One major reason was because Sony sold their hardware at a loss, subsidized by licensing fees collected against software sales. The MSRP of the PS1 was $299.
IIRC, Commodore made their profit from the CD32 up-front. They were eying a MSRP of $399 for its US launch. We can only speculate how much cheaper it would have been a year later.
I'm not sure if Commodore adopted it, but IMHO, it would have been suicidal for Commodore to try to use the subsidized hardware model with the CD32 since so many users would have bought it with the sole intention of turning it into an A1200 clone. Cheap users would then buy or pirate desktop versions of games, robbing Commodore of their ability to profit from the console.
I think it was less about open architecture and more about forward momentum.
IMHO, I believe that the IBM PC won and the Apple Macintosh survived is because they were constantly improving. You can see a clear line of succession from the original PC to the AT. The line is a bit more murky with the Macintosh, but it is almost spastic with the Amiga.
Imagine if Commodore had released a new Amiga chipset every two years with incremental upgrades to every part of the system, all tied to a slightly faster processor. Do you think they would have remained more competitive? Would you have been excited if Commodore had released the Amiga 2200 in 1988 with a 14MHz 68000, an Enhanced Denise with support for 320×200×8bpp CLUT and HAM screen modes and an Enhanced Paula with 6-chan 8-bit 32KHz audio and native IDE support? I know I would have.
Based off of some of David Haynie's comments, it just sounds as if some of the chipset designs, including Hombre and AAA, were just too advanced and too aggressive for the fabs at the time. Meanwhile, management's obsession with the word "cheap" kept the platform from evolving properly.
Well, it is both.
And even if you had a graphics.library that abstracted the hardware properly, nothing would prevent an application from going around it. App developers did what they wanted. How many apps were floppy only, didn't allow task switching, and banged the hardware like a cheap date?
They should have made device independent graphics a priority from the start
While you could make the argument that the Amiga 2000, 3000 and 4000 should have had Denise and Lisa on a peripheral card, you can't really make that same argument for the Amiga 500 or 1200. It would have been cost prohibitive.
Also complicating things are Agnus and Alice. The older chips wouldn't have had enough address lines to support the size of the graphics buffers needed by each newer generation of chipset. I guess they could have added more address lines to Agnus from the start, that would increased manufacturing costs while decreasing the amount of memory left for fast RAM on the processor local bus (remember... 24 address lines... 16MB total between chip and fast)
Did you maybe mean the Accent kernel?
No, I was talking about Mach, which was standing on its own feet by 1986. Although you could debate as to if it was more Mach or more BSD at that point...
Kernel != OS
True. But remember that the Amiga 1.x userland was fairly spartan. The magic was all up in the kernel.
VM was a good idea, sure... but not for the kind of small computers Commodore was doing in 1985 ... turning AmigaOS into UNIX would have ruined it
Yup, I just said that. :)
I was thinking along the lines of using a flat memory model where you kept your linear and physical addresses in sync, only using the MMU to generate protection faults.
And as far as 68020 + 68851, yeah, that became a solution. It wasn't a solution in 1985, the 68851 didn't work yet. Everyone doing UNIX workstations on 68K were building their own MMUs. Not to mention the fact that the 68020 was a $300 chip...
$300 for a 68020? Ouch. How much was the 68010 running in 1985? It would have worked just as well...
If the 68851 wasn't available yet, and since the 68451 was reported to have been a POS, how hard would it have been to have rolled your own MMU for generating protection faults? Could it have been something that could have been added to Agnus?
The WDC 65816 was technically an 8/16-bit version of the 6502, but it was a pretty ugly hack.
Agreed. The 65816 could be an ugly processor to deal with. And you’re right, only a handful of instructions could use long memory addresses, and only three addressing modes were available for long addresses. For everything else, you had to work within your 64KB bank unless you wanted to start messing with the data or program bank offset registers.
However, if the bulk of your program’s code and data could fit inside one bank, then it worked like an enhanced 65C02. In which case the 65816 was somewhat nice to deal with. Makes me wish that the 8502 had used a 65C02 derived core...
The C128's MMU actually made things much easier to deal with, in the specific case of 128KB of memory
But it was still bank switching, and bank switching is evil. If I could have a nickle for every time I fought with an expanded memory manager on a PC...
But yeah, while the MMU in the C128 was tolerable, it would have seriously kicked ass if I could have just flipped a bit and turned the processor into an enhanced mode that upgraded all of the 16-bit memory modes to 24-bit, upgraded the index registers to 16-bit, and would have added 16-bit counterparts to the 8-bit relative displacement Bcc branches.
It was pretty obvious the C128 was the end of the line for 8-bit at Commodore, so there wasn't a great deal of looking forward in the C128... ... also not the budget we really wanted for it.
I never understood that. I always thought that the jump from the C64 to the Amiga was a fairly huge one, both in feature set and in price. The C128 would have made a nice filler machine for that market. Instead, it just seemed like an expensive C64 with a few bolt on features. Other than some BBS admins, I don’t remember anyone being excited over the C128.
And I never considered the 8-bit data bus or the 16-bit ALU of the 65xx series as a terminally limiting factor to the platform. I knew a few folks with IBM XT systems who had upgraded to VGA and Soundblaster cards. 256 colors and 8-bit digital audio all being processed with that crusty 8088, all under DOS.
If your budget was tight, then it seems like a lot of resources were wasted on adding the Z80/CPM support. And it must have killed your manufacturing cost per unit. It just seem as if better graphics, better audio and/or a better CPU would have made more sense. I mean, come on, even the C16 had a better color palette than the C128.
The AmigaOS was the best OS of its time
I disagree. I would actually suggest that Carnegie Mellon’s Mach was the best kernel of the time.
The majority of AmigaOS’s faults come from two issues: the use of TRIPOS rather than CAOS for AmigaDOS and the lack of better memory management. Although some might point out that those two are the same issue.
Programming in C for the Amiga back in the Kickstart 1.x days was a little rough with AmigaDOS. Once you learned how to program for Exec, you had to relearn how to program for AmigaDOS since it was BCPL based with its own unique set of structures.
Another problem is that the OS was prone to memory fragmentation. With BSD, you get a layer of abstraction because of virtual memory. With WinAPI, you get it from the use of handles. That allows the OS to perform housecleaning in the background. AmigaOS had none of that. No abstraction, no garbage collection. CAOS was supposed to include some limited management that reduced fragmentation without the speed hits that memory abstraction introduces.
The memory management issues also come from the use of a 68000 as opposed to a 68020 + 68851 as the baseline processor. Userland programs could trash the kernel and could trash or self-edit themselves because “.code” regions were read-write. There was also no way to mark memory as private, so you had to hash your passwords in memory to prevent eavesdropping. Fully virtualized protected mode like SYS.V, BSD, VMS and Win32 used would have been overkill for the time, but the all open wild-wild west of the 68000 was just as bad.
I’d actually argue that the Commodore 128, Commodore 65 and CBM-II series were all mediocre successors to the Commodore 8-bit line at best. I even suspect that had the Amiga not fallen into Commodore’s lap, they might have gone bankrupt because of it.
The main problem with all three systems was their CPU. The MOS 8502 found in the C128 and CBM-II as well as the CSG 4510 in the C65 could only access 64KB of memory directly, so they all relied on bank switching to get around the limitation. Bank switching SUCKS. It is even worse than the 20-bit segmentation model found in the i8086/8088.
Apple ended up using the WDC 65816, which included a limited set of op-codes that could handle 24-bit “long mode” addresses. But it was a bolt on feature at best, and was severely limited. A better option would have been if the MOS 8502 came with a new memory mode where all existing 16-bit ($xxxx) ops could have been extended to 24-bit ($xxxxxx) instead. A processor with a flat 24-bit memory mode would have been very easy to work with.
All of the C128’s other major faults (graphics and audio) are all secondary. Sure, had they either adopted the MOS 7360’s 121-color Y/C palette or a 64-color RGB6 palette, it would have been great. Had they adopted stereo SID and/or added frequency modulation, it would have been great. But in the end, the processor would have crippled it. Just try programming for the C65 emulator under M.E.S.S. and see for yourself.
There are several products currently on the market that allow you to perform geographic load distribution via DNS. These products look at your LDNS server's address and either attempt to triangulate using a reverse DNS lookup to the LDNS server, calculating number of hops and/or round-trip times to that LDNS from each of your sites, or they use static IP range tables broken down by region. The assumption is that a client in somewhat close proximity to their LDNS server.
/24 subnet (or any varying mask bitlength), you'll still end up with clients clobbering each other with these geographic load distribution products unless you set the TTL to 1 second. That work around has the nasty side effect of increasing your DNS load by an exponential factor, which isn't good either.
The problem with these methods is that some very large ISPs may use only a couple of LDNS servers for an entire continent. In the case of third party DNS services, it grows to being a couple of LDNS servers for the entire planet. So there is no geographic unity between client and LDNS server.
This proposal helps a bit, but unless it includes a method where a LDNS server can be told that a DNS query's response is only good for that client's
...embargo on!
More and more people consider their pets the same as family. That's one reason why you keep hearing the unflattering term "fur children" increasingly used to describe peoples' relation to their pets.
To these people, forcing their pets to spend their flight in the cargo hold is tantamount to cruelty. And how dare a company be cruel to anyone's child.
As more and more people get this unhealthy obsession with their pets, expect more laws being passed that allow them to bring their pets everywhere, including flights.
I can only imagine how people with allergies are going to respond. Maybe they can sue under the ADA here in the US. Who knows how the courts in Canada would rule.
The custom chips were originally Commodore's key to success, but they did absolutely become a boat anchor.
I guess while I have you on the subject, what DID actually happen between OCS and ECS?
I keep hearing rumors about Miner having "something good" over at Los Gatos (Ranger), but some of it doesn't make sense. If the rumors about the VRAM costs were true, why didn't the Paula replacement make it out? And why was the ECS Super Denise anything but super?
This was back in the days when PCs and Macs were struggling to deliver better than 1MB/s, and both were using PIO.
Now you've made me curious. EISA was on the market around the time of the A3000, even if it was a rare sight. I vaguely recall that the Adaptec EISA SCSI card in my old NT-based DEC Alphaserver could do bus mastering DMA. I believe that Intel boxes with EISA could also do busmaster DMA transfers, too... (checks Wikipedia) ...which they supposedly could. I wonder how fast they were.
The NCR53C710 chip was so frickin fast
Yes it is. That's why I still have my DKB 4091 after all these years.
You'd do better with a 14Mhz '020 or even EC020 than 20MHz 68000 on most code
Right, the 68020 could do much more per cycle than the 68000. However, I'm being hypothetical here. If Commodore management was unwilling to fund the design of a new 68020-based entry level motherboard, how much effort (and cost) would it have taken to modify the existing A500/A2000B motherboards to handle a 68HC000 running at 14 or 21MHz?
I guess the biggest question would be bus timing. Was the custom chip bus running synchronous or asynchronous with the 68000 bus on the A500, A600 and A2000? How fast could you drive the ECS chips? If not very fast and if the custom chip bus was running in sync, how hard would it be to upgrade the buffers and DMAC used to interface between the two buses so that you could decouple the 68000 bus and run it faster?
So C= was not quite 1/5th the size of Apple in those days
Are you talking mid-80s or late-80s? I always thought that Commodore came close to running Apple into the financial ground with its price war with TI. That, and the money they hemeraged with the Apple III and Apple Lisa. I would have thought that Apple would have consolidated heavily as a way to stop bleeding money, including its R&D division.
The custom chips were originally Commodore's key to success, but they did absolutely become a boat anchor
Depends on how you look at it. They're only an anchor if the cost to develop them outweighed the advantage they'd give you in the market. Just look at the money that companies like Sony, 3dfx and Nintendo made with their custom graphics chips during the '90s.
To me, Commodore's later custom chips for the Amiga (ECS, AGA, AAA) always seemed to be an anchor because they were always behind the curve. OCS and Ranger seemed to be the only two that were ahead. So of course it was better to look outside the company - it sounds as if internal R&D couldn't keep up due to budget constraints and managerial interferrence. You guys were always months, if not years, behind the PC and workstation (SGI, Sun) markets. Too little, too late.
As for going to HP, that was probably a brilliant idea. It was one thing to roll your own chips by that point. It is another to try to run your own fabs. Mensch knew not to play that game when he founded WDC, as did Wilson and Furber over at Acorn/ARM.
Very early models of the Amiga 3000 came with an alpha version of Kickstart (V36/KS1.4) used for bootstrapping the system. The system would then attempt to load your main Kickstart image (DEVS:Kickstart) from floppy or hard disk.
In order to use a 68040, you had to have Kickstart 2.04 or 3.1 in ROM. As such, very early A3000 models were not offered with 68040 options because the ROMs weren't available yet. Also, it is my understanding that Commodore used full versions of the 68030 as opposed to cheaper 68EC030 parts because they needed the MMU to remap the softkicked Kickstart in memory.
If Commodore did offer a 68040 version of the Amiga 3000 desktop, it was simply an '030 model with a Commodore A3640 processor card installed.
On the other hand, none of the PCs or Macs had hard drive performance capable of real video... the Amiga 3000 did.
A stock Amiga 3000? I recall the onboard NCR chipset being a little sluggish. My drives really didn't start to zip until I tossed in my 4091, even with my original Quantum LP52S. I also recall moderately high CPU utilization with the onboard NCR, which my 4091 also corrected.
The original project for a next-generation chipset was started in 1988
Which was already too late. I know that technology didn't move as fast back then as it does now, but Commodore should have been starting work on a next-gen chipset as soon as the Amiga 2000 hit the streets back in 1986. "ECS" should have been released no later than 4Q88. Just look at the amount of time between the release of EGA (1984) and VGA (1987) by IBM.
but underfunded
Underfund your #1 moneymaker. Always a bright idea. Wouldn't expect anything less from Commodore.
The C65 was a stupid idea, and I believe it happened mainly because no one else wanted to work with the engineer involved, so they just left him alone.
Personally, I think every 8-bit machine released after the C64 was dumb. Both for how they were built, when they were built, and for whom they were built.
The A3000 has every area of the system we could improve improved, without the new custom chips. Some of that got expensive, which is why it didn't immediately trickle down to cheaper systems. That was Spring of 1990.
Which is why I don't understand why Commodore just didn't crank up the speed using legacy board designs for their entry level Amigas. Again, Motorola had a 20MHz 68HC000 out by 1990. Other than faster memory/core/logic chips, you could have essentially recycled the older 16D/24A bus from the A500/A2000 for very cheap.
I had an early A3000/030-16 model with KS1.4 in ROM, and I don't recall paying more than $2500 for it. Maybe that was for the 68040-25 model during the first weeks of sale?
What was with that "flicker fixer" thing it apparently used?
The flicker fixer was essentially a line doubler that took 15KHz 480i video and converted it to 31KHz 480p video. Commodore essentially took the A2320 flicker fixer for the Amiga 2000 and intergrated it onto the Amiga 3000 motherboard. They even used the same AMBER chip as the A2320 used. Nothing fancy about it.
[The A3000] may have had a faster processor, but they didn't do the same with the mainstream Amigas.
Correct. Both the Amiga 500+ and Amiga 600 used the same 7.16MHz 68000 as the original A500, which was really retarded. Models of the 68HC000 existed at the time that could have been clocked at 14.32MHz and 21.28MHz. Boosting the clock speed and switching from an NMOS to CMOS processor would have required relatively minor changes to existing logic board designs (as opposed to switching to a 68EC020).
But that replacement should have been the A1200, [not the A600,] which came out six months after
The A600 never should have been released when it was, or how it was. It should have been released in tandum with the A3000, preferrably with a full keyboard, faster processor and graphics comparable to XVGA.
No, the "Amiga 300" pricepoint should have been served by an Amiga, or they should have continued to sell the existing C64 at a bargain price.
The C64 was almost a decade old. It never would have sold as-is, except in maybe in emerging markets. The C128 was simply too complex and too expensive to manufacture. A new computer with the WDC 65816, 256KB of memory, the VIC-III and six-channel SID might have been manufactured for close to $100, well within the target price of the original Amiga 300 vision.
Yes and no.
VGA did have a better indexed color depth at 320×200 (8-bit for VGA, 5-bit/6-bit EHB for OCS/ECS), as well as a larger palette (18-bit for VGA, 12-bit for OCS/ECS).
However, VGA was a very simplistic frame buffer. There were no masked block move functions, and it was limited to a single sprite. The Amiga chips supported 8 sprites and complex bit blitting through the Blitter.
As a result, after the release of VGA, games with a lot of static graphics tended to look better of VGA. Side scrollers and other sorts of arcade games looked better on the Amiga.
Let me rephrase and clarify. During the period of 1990-1996, I was not aware of a single person who went from the Amiga to Linux as their primary desktop OS. However, during that time, I was aware of quite a few people who experimented with BSD. People who had a full 68030 or 68040 in their Amiga tried NetBSD, while those who switched to the PC generally tried FreeBSD. I don't recall anyone from my old Amiga community talking about Linux until around 1998 or so. But by then, I had lost ties to many of those people.
I agree. Most Amiga users I knew ended up getting a PC with Windows because that's where all of the games ended up going. I knew a few who went to Macs. I'm not aware of a single one who went to Linux, and I was fairly big into the Amiga scene in my area at the time.
/.'s wishful thinking crowd is getting ahead of themselves.
I think
Commodore put the gun to their head in 1990 with the introduction of the Amiga 3000. They pulled the trigger two years later with the release of the Amiga 600. It just took a few years before the body would finally die.
Neither the A600 nor the A3000 introduced any discernible enhancements to the product line over that of the A500 or A2000. It also failed to meet or beat the color performance of IBM's VGA chipset. In fact, it was actually advantageous from both a price and performance standpoint to buy an A500 or A2000 and then expand using third party devices.
Commodore might have been able to survive as a console manufacturer, but never as a desktop or workstation manufacturer. Apple and the PC clone market was hammering them on the low end while SGI, Sun and NEC was hammering them on the high end.
The sad thing is, all they needed to stay on top was something between the OCS and AGA. For 320×200, a 7bpp indexed color mode (128 colors) with a 15-bit palette. Toss in EHB8 and HAM8 as well. For 640×200, introduce a EHB5 mode. Lastly, bump the sound from 8-bit PCM to 12-bit ADPCM. Lastly, move everything to a real 32-bit bus, unlike this hybrid 16/32 crap the A3000 used.
Really, nothing revolutionary. And as for the so-called "Amiga 300" Commodore was looking for, they could have just released the never released Commodore 65 with a WDC 65816 at its heart instead. Cheap enough for emerging markets and Wal-Mart.
Amiga, for those who were into PCs, really, was a story about hardware that was way ahead of its time for the price.
For the Amiga 500 and 1000, I very much agree. Nothing could really touch them when it came to performance for their price. But for every other Amiga model, it is a debatable statement. Feature stagnation really robbed them of their advantage in the marketplace.
Had Commodre switched to a 14MHz 68000 for the Amiga 600 and 2000, as well as to an improved Denise with slightly higher color depths, I'd say that they would have remained unbeatable. Had the A3000 been released with something similar to AGA, it again would have remained untouchable.
But as it is, Commodore screwed the pooch with just about everything after the A1000. Which is why they are gone.