http://jeremyreimer....ostman/node/329
This site had been brought up in a few discussions in the past on AA, some questioning its accuracy (or at least the many apparent omissions), but I don't recall ever seeing a definitive validation for its accuracy or inaccuracy.
So does anyone know how accurate these figures actually are? (and if the inaccuracies are mainly omissions, or actual errors -the Atari 8-bit sales seem to be missing all XL/XE sales, the CoCo is missing, TRS-80 isn't mentioned by model -and Model 1 and 2 are totally separate lines, VIC-20 and PET are missing, as are the Sinclair/Timex machines, Amstrad, MSX, or a breakdown of PC clones isn't provided -especially at least separating Tandy 1000 sales -and it's not mentioned if its strictly US sales, international, or some incomplete conglomeration of different regions -and obviously doesn't have a break-down by region in any case)
- AtariAge Forums
- → Viewing Profile: kool kitty89
kool kitty89
Member Since 14 Apr 2009OFFLINE Last Active Jan 17 2012 5:31 AM
Community Stats
- Group Members
- Active Posts 2,377 (2.3 per day)
- Profile Views 10,298
- Member Title River Patroller
- Age 22 years old
- Birthday August 8, 1989
-
Gender
Male
-
Location
San Jose, CA
Contact Information
107
Excellent
User Tools
Latest Visitors
Topics I've Started
Jerry Reimer's Total Share Computer site?
Fri Oct 28, 2011 5:23 PM
Why CRY?
Fri Sep 23, 2011 8:43 PM
I understand why the designers of the Jaguar chose to use a chroma/luma based color format (smoother shading and easier logic design for the shader logic, etc -working only on 4 and 8-bit boundaries), but why did they choose a proprietary color model?
Why not use a derivative of a standard color model that fit the requirements, like YCbCr? (ie 8-4-4 YCbCr)
And why use a luminance scheme that only shaded from normal intensity of colors down to black rather than having normal intensity in the middle with 128 shades towards black and 128 shades towards white?
For that matter, there were other compromises between plain RGB and CRY (or YUV/YCbCr) like using RGBI. 4-4-4-4 RGBI would mean choppier luminance shading than CRY, but a larger array of colors to choose from (as well as fitting perfectly for 24-bit RGB: 4-bits per RGB element and an additional 4-bits setting the intensity within the 8-bits per RGB of 24-bit colorspace . . . albeit not quite perfect if you arranged luminance relative to human perception rather than just RGB intensities). You couldn't even need a LUT (like CRY does) for 4-4-4-4 RGBI, just manipulating 24-bit RGB directly. (again, unless you corrected lumance calibration for human perception)
RGBI would also allow more flexible shading using colors rather than just light/dark. (like normal RGB shading, but with more of a compromise with luminance and working on convenient 4-bit logical boundaries)
So better luminance shading than 15-bit RGB (a la PSX/Saturn) but weaker than CRY or 8-4-4 YCbCr, and weaker colored shading than 15-bit RGB but better than CRY (or YCbCr).
Why not use a derivative of a standard color model that fit the requirements, like YCbCr? (ie 8-4-4 YCbCr)
And why use a luminance scheme that only shaded from normal intensity of colors down to black rather than having normal intensity in the middle with 128 shades towards black and 128 shades towards white?
For that matter, there were other compromises between plain RGB and CRY (or YUV/YCbCr) like using RGBI. 4-4-4-4 RGBI would mean choppier luminance shading than CRY, but a larger array of colors to choose from (as well as fitting perfectly for 24-bit RGB: 4-bits per RGB element and an additional 4-bits setting the intensity within the 8-bits per RGB of 24-bit colorspace . . . albeit not quite perfect if you arranged luminance relative to human perception rather than just RGB intensities). You couldn't even need a LUT (like CRY does) for 4-4-4-4 RGBI, just manipulating 24-bit RGB directly. (again, unless you corrected lumance calibration for human perception)
RGBI would also allow more flexible shading using colors rather than just light/dark. (like normal RGB shading, but with more of a compromise with luminance and working on convenient 4-bit logical boundaries)
So better luminance shading than 15-bit RGB (a la PSX/Saturn) but weaker than CRY or 8-4-4 YCbCr, and weaker colored shading than 15-bit RGB but better than CRY (or YCbCr).
What if the ST had had an open expansion architecture?
Thu Jun 2, 2011 6:26 PM
What do you think would have happened to the ST if Atari supported flexible, open-box expansion from day 1? Just flexible expansion support (apple II/PC style) without any other changes to the base hardware/chipset, just the configuration of the system and form factor. (limit the expansion to a single, universal expansion port on console models with external expansion modules also available -having fully featured desktop box models from the start would have been important for establishing the standard, let alone non-expansion related issues like the more professional "look and feel")
Easy RAM upgrades, added coprocessors (blitter, DSP, co-CPU, etc), added video cards, sound expansion, etc, etc. (not just limited by Atari's offerings either, but 3rd parties pushing things as well -especially significant if/when Atari was lagging in their own upgrades/enhancements/peripherals)
The bottom end models would have been basically identical other than a proper expansion interface in place of the cart slot . . . hell, having a standardized expansion interface could have more easily allowed even lower end models that omitted some less necessary features for low-end users (with add-ons including those features -things like the MIDI interface and corresponding ACIA, perhaps 256k of RAM, and maybe dropping the keyboard for a form factor closer to the 130XE . . . there's the ACSI, parallel, and RS232 ports too, but those would only save the cost of the connectors as the chips were all needed for other purposes).
What impact would have had on the ST's short and long-term success in the ST's various regional markets?
One other consideration could have been aiming at greater PC compatibility on the software end. Atari already had the DOS compatible file system of GEM, and PC compatible floppy formatting, so it would mainly have been a matter of software developers supporting cross-platform standardized formats for text, graphics, etc, etc. (plus, you'd need to get a 5.25" external FDD for real PC intercompatibility until the late 80s, and you'd need DS 3.5" drives for proper compatibility as well)
Easy RAM upgrades, added coprocessors (blitter, DSP, co-CPU, etc), added video cards, sound expansion, etc, etc. (not just limited by Atari's offerings either, but 3rd parties pushing things as well -especially significant if/when Atari was lagging in their own upgrades/enhancements/peripherals)
The bottom end models would have been basically identical other than a proper expansion interface in place of the cart slot . . . hell, having a standardized expansion interface could have more easily allowed even lower end models that omitted some less necessary features for low-end users (with add-ons including those features -things like the MIDI interface and corresponding ACIA, perhaps 256k of RAM, and maybe dropping the keyboard for a form factor closer to the 130XE . . . there's the ACSI, parallel, and RS232 ports too, but those would only save the cost of the connectors as the chips were all needed for other purposes).
What impact would have had on the ST's short and long-term success in the ST's various regional markets?
One other consideration could have been aiming at greater PC compatibility on the software end. Atari already had the DOS compatible file system of GEM, and PC compatible floppy formatting, so it would mainly have been a matter of software developers supporting cross-platform standardized formats for text, graphics, etc, etc. (plus, you'd need to get a 5.25" external FDD for real PC intercompatibility until the late 80s, and you'd need DS 3.5" drives for proper compatibility as well)
3rd party 68000 licensing and development
Thu May 19, 2011 12:53 AM
A while back, kskunk mentioned this:
http://www.atariage....ost__p__1862392
And my question is:
If various competitive 3rd party manufacturers of the 68000 (Signetics, ST, Hitachi, etc, etc) couldn't get licenses for later 68k architecture chips, (aside from taking Motorola to court) why didn't they invest in developing their own updated chips to compete with the '020/030/etc (be it full in-house design, reverse engineering, hybrid clone/in-house designs, etc -like the various x86 chips done by NEC, AMD, and Cyrix in mid 80s and early 90s -or at least more modest enhancements of the 68000), or, short of even modest updates to the 68k core, why didn't any of those competitors just push faster and faster clocked vanilla 68000s in the late 80s and early 90s? (another thing that some x86 vendors did -AMD and Harris with 20 and 25 MHz 286s, AMD with the extremely popular AM386DX-40, AMD again with the 5x86, etc, etc -something usually done when said manufacturer couldn't get a full new design online or at least not on the market soon enough)
http://www.atariage....ost__p__1862392
kskunk, on Sat Oct 17, 2009 6:20 AM, said:
(As an aside, there's some history around the 68020 and second-sources. Motorola knew that all the 68K suppliers were hurting their bottom line/ability to gouge customers. So they formed an alliance with Toshiba as the exclusive 68020 second-source. It was alleged that Toshiba got the deal by fixing prices. Motorola's traditional partners took them to court, in vain, trying to get the 020 masks. Some think Motorola's unwillingness to play fair killed off the 68K as a serious contender in the processor wars. Motorola's next big endeavor, PowerPC, was almost ridiculously open with the inclusion of many suppliers, partners, and licensing options. That may be why all three major consoles are using it today...)
And my question is:
If various competitive 3rd party manufacturers of the 68000 (Signetics, ST, Hitachi, etc, etc) couldn't get licenses for later 68k architecture chips, (aside from taking Motorola to court) why didn't they invest in developing their own updated chips to compete with the '020/030/etc (be it full in-house design, reverse engineering, hybrid clone/in-house designs, etc -like the various x86 chips done by NEC, AMD, and Cyrix in mid 80s and early 90s -or at least more modest enhancements of the 68000), or, short of even modest updates to the 68k core, why didn't any of those competitors just push faster and faster clocked vanilla 68000s in the late 80s and early 90s? (another thing that some x86 vendors did -AMD and Harris with 20 and 25 MHz 286s, AMD with the extremely popular AM386DX-40, AMD again with the 5x86, etc, etc -something usually done when said manufacturer couldn't get a full new design online or at least not on the market soon enough)
Atari's legal restrictions on using the Lynx Chipset?
Tue May 10, 2011 12:52 AM
Does anyone know if (or how, specifically) Atari Corp was restricted and/or obligated to use the Lynx chipset?
I'd imagine that their agreement with Epyx had some obligation to release a handheld system in general, but were there restrictions or provisions on using the hardware for other products?
Did Atari have free use of the IP of the design (and did they have exclusivity or could Epyx license it to another company if they chose to)?
And, if Atari did have free/flexible use of the chipset, why didn't they use it (or parts of it) for other projects? In particular, the lynx design seems to make a much better basis for a cost-effective/flexible/attractive (to developers and consumers) mass-market home game console than the Panther or an ST derived console. (an ST console would actually be more attractive than the panther too, at least in terms of being more "normal" and developer/port friendly, but the Lynx was far better all around from a cost, performance, and programmer/developer standpoint)
For that matter, it seems like parts of the lynx hardware (at least the blitter) would have been nice in an updated ST . . . albeit such an update would also mean a SHIFTER with packed pixel support (a feature they should have been aiming at anyway by the late 80s). I can see wanting backwards compatibility with the older ST BLiTTER, but given it had pretty much been used exclusively for high-level applications (MEGA-ST specific) prior to the STe, it wouldn't have been that big of a jump to drop the old blitter and actually switch to a new one without hardware backwards compatibility. (but perhaps with OS level backwards compatibility and facilities for patching some other software that had supported the old BLiTTER)
It seems like a waste for Atari to have a bunch of different projects and designs when they could have focused on consolidating resources that could be used (to different extents) among multiple products. (that's something you could argue back with Atari Inc in general, but Atari Corp could still have done it moving forward -albeit not so much with older chipsets that would be difficult to re-engineer for added features while maintaining compatibility -something Atari Inc had already partially compromised by losing some of the key engineers from the A8 design teams)
Atari Corp ended up with the ST line adding the MEGA BLiTTER, then the STe (same blitter moderate update to SHIFTER and DMA sound), Lynx chipset arriving somewhat before the STe entered production iirc, Panther continuing throughout 1989 to the point of completing the LSI design and preproduction dev systems with Panther chips being released late that year, then the TT with the TT SHIFTER (I think still without packed pixel support, but I'm not sure), then the Falcon with VIDEL in the works (plus the 8 channel 8/16-bit DMA audio, off the shelf 56k DSP, etc), the Jaguar starting in 1990 and being solidified in mid/late 1991 (TOM's first silicon revision taped out late that year), MEGA STE arriving in 1991 with 16 MHz derivative of the old BLiTTER (plus 16 MHz 68k, STe SHIFTER, DMA sound, etc), the the Falcon arriving at market in 1992 (early Jag dev systems released early that year as well), late 1992 saw the final revision of TOM arriving and JERRY being completed as well iirc, then the Jaguar's release/test market in fall of 1993.
It seems like there's a lot of waste there and also that some of the video game specific hardware would have been a good deal better for the computers that the computer-specific hardware actually used. (like a packed pixel supporting SHIFTER -especially with both 4 and 8bpp modes- coupled with the Lynx blitter -something that would have been pretty good even into the early 90s- and the the jaguar chipset being particularly impressive in general with tons of possible used in a computer -especially with more investment in tools and bug fixes . . . and perhaps aiming the Jag blitter's design to include backwards compatibility)
Hell, even the Panther (more so the Jaguar object processor) has some interesting potential as a 2D accelerator, especially for windowing. (probably more realistic to focus on blitter type hardware though -the original Panther was especially impractical due to requiring fast 32-bit SRAM to operate, but the revised version in the Jaguar was optimized for use with 64-bit DRAM efficiently -albeit a fully blitter-oriented design with the jaguar chipset could have had other advantages)
I'd imagine that their agreement with Epyx had some obligation to release a handheld system in general, but were there restrictions or provisions on using the hardware for other products?
Did Atari have free use of the IP of the design (and did they have exclusivity or could Epyx license it to another company if they chose to)?
And, if Atari did have free/flexible use of the chipset, why didn't they use it (or parts of it) for other projects? In particular, the lynx design seems to make a much better basis for a cost-effective/flexible/attractive (to developers and consumers) mass-market home game console than the Panther or an ST derived console. (an ST console would actually be more attractive than the panther too, at least in terms of being more "normal" and developer/port friendly, but the Lynx was far better all around from a cost, performance, and programmer/developer standpoint)
For that matter, it seems like parts of the lynx hardware (at least the blitter) would have been nice in an updated ST . . . albeit such an update would also mean a SHIFTER with packed pixel support (a feature they should have been aiming at anyway by the late 80s). I can see wanting backwards compatibility with the older ST BLiTTER, but given it had pretty much been used exclusively for high-level applications (MEGA-ST specific) prior to the STe, it wouldn't have been that big of a jump to drop the old blitter and actually switch to a new one without hardware backwards compatibility. (but perhaps with OS level backwards compatibility and facilities for patching some other software that had supported the old BLiTTER)
It seems like a waste for Atari to have a bunch of different projects and designs when they could have focused on consolidating resources that could be used (to different extents) among multiple products. (that's something you could argue back with Atari Inc in general, but Atari Corp could still have done it moving forward -albeit not so much with older chipsets that would be difficult to re-engineer for added features while maintaining compatibility -something Atari Inc had already partially compromised by losing some of the key engineers from the A8 design teams)
Atari Corp ended up with the ST line adding the MEGA BLiTTER, then the STe (same blitter moderate update to SHIFTER and DMA sound), Lynx chipset arriving somewhat before the STe entered production iirc, Panther continuing throughout 1989 to the point of completing the LSI design and preproduction dev systems with Panther chips being released late that year, then the TT with the TT SHIFTER (I think still without packed pixel support, but I'm not sure), then the Falcon with VIDEL in the works (plus the 8 channel 8/16-bit DMA audio, off the shelf 56k DSP, etc), the Jaguar starting in 1990 and being solidified in mid/late 1991 (TOM's first silicon revision taped out late that year), MEGA STE arriving in 1991 with 16 MHz derivative of the old BLiTTER (plus 16 MHz 68k, STe SHIFTER, DMA sound, etc), the the Falcon arriving at market in 1992 (early Jag dev systems released early that year as well), late 1992 saw the final revision of TOM arriving and JERRY being completed as well iirc, then the Jaguar's release/test market in fall of 1993.
It seems like there's a lot of waste there and also that some of the video game specific hardware would have been a good deal better for the computers that the computer-specific hardware actually used. (like a packed pixel supporting SHIFTER -especially with both 4 and 8bpp modes- coupled with the Lynx blitter -something that would have been pretty good even into the early 90s- and the the jaguar chipset being particularly impressive in general with tons of possible used in a computer -especially with more investment in tools and bug fixes . . . and perhaps aiming the Jag blitter's design to include backwards compatibility)
Hell, even the Panther (more so the Jaguar object processor) has some interesting potential as a 2D accelerator, especially for windowing. (probably more realistic to focus on blitter type hardware though -the original Panther was especially impractical due to requiring fast 32-bit SRAM to operate, but the revised version in the Jaguar was optimized for use with 64-bit DRAM efficiently -albeit a fully blitter-oriented design with the jaguar chipset could have had other advantages)
- AtariAge Forums
- → Viewing Profile: kool kitty89
- Guidelines




Send me a message
Find content
Display name history



