kool kitty89

Crazyace, on Sat Jan 14, 2012 7:34 AM, said:

It seems like most/all of the Cojag games don't really do things that merit the faster CPUs. (most are just 2D and streaming video stuff -and the added VRAM makes more sense for added animation/texture detail)

Maybe it just made programming easier. (after all, for an arcade machine, that sort of modification would be pretty minor -and the Jag chipset was already very low cost, so even with the enhancements it was probably very cheap for an arcade board of the time)

Lynxpro, on Fri Jan 13, 2012 7:54 AM, said:

The big issue would be the price back in 1984/85 (when the ST was being readied for release and actually launched) . . . allowing only 720k drives from the start would have meant stocking those parts earlier on at higher cost (or risking shortages by waiting until closer to the release date).

If it was only a $50 (retail) difference, that would have been a good investment . . . $100 would have been more problematic, but perhaps still more worthwhile. (the issue is having competent sales people to explain things -and/or comprehensive advertising . . . neither of which Atari had consistently at the time -and usergroups would be veryhelpful with that sort of information too, but many average consumers wouldn't consult those sorts of things prior to making a purchase -more likely after the fact)

Albeit, by the time the 520ST really fell into the mainstream low-end market (especially in Europe) around 1987, the cost of the DS drives would probably be a non-issue anyway . . . and standardizing them from day 1 could have further deflated the price due to economies of scale.

wood_jl, on Thu Jan 12, 2012 2:07 AM, said:

This is always the case though. You either aim at lower cost/price and a broader market, or you push for a higher minimum standard at the expense of higher price/cost and more limited market. (in the US, 720k probably would have made sense -as would aiming at a higher-end market in general, but it could have ruined them in Europe as well as losing a fair chunk of the lower-end niche in the US -and whether they actually would have been more successful pushing mainly towards a higher/mid-range price even in the US is debatable -the bigger issue for the US market was marketing/distribution -albeit not having a desktop form factor hurt market perception too)

However, a better compromise would be making 360k the low-end standard, but prominently offering a 720k option from day 1 and making that the standard on higher-end models.

Also, lowest common denominators will change over time . . . look at PCs. 360k 40 track DSDD 5.25" disks was the bottom standard, but with 1.2 MB 5.25" and DD and HD 3.5" gradually becoming more and more popular, there was a shift in favor of higher densities, with both 1.2 and 1.44 MB disks becoming common by the beginning of the 90s (and most software transitioning to one or both of those formats by the early 90s -often with mail-in options for older formats), and eventually dropping 5.25" all together (around 1994, not long before most software switched to CD-ROM)

And with the ST, we'd be talking a much simpler situation than with PCs too, since you'd have 3.5" standard from the start, so only the matter of going to DSDD and then DSHD.formats later on. (with both users and publishers transitioning between those)

Plus, if you standardized a higher density for later models with other specific hardware features, than software specific to those newer features (graphics/sound/CPU/etc) would naturally cater to the newer disks too, without even having to offer lower-end options. (since it wouldn't be able to run on those models anyway)

The bigger issue would be maintaining the market such that users consistently transition to the newer hardware. (and, obviously, offering said hardware in a timely and affordable manner)

Quote

Again, there's still the cost issue.
And, as for the upgrades hardware (graphics/sound/CPU/etc), that was mainly in the context of expanding/evolving the line to keep it competitive (and expand the range of market segments it catered to). (albeit things like DMA sound and/or scrolling and/or chunky pixels and/or lower res modes -and certainly an expansion port/enhanced cart interface- may have been possible without compromising the price or release date -more an issue of design direction . . . though it probably would have been delayed if all those features were added -cost/price still probably wouldn't be a problem though)

Lack of consistent, timely, well-thought-out, efficient upgrades were one of the biggest problems with the ST (and Amiga for that matter).

Quote

But drivers weren't cheap either . . . so the question would be just how much more expensive a DSDD drive was compared to SSDD. (even Apple made that decision with the original Mac)


Another argument could be for using cheaper/common 5.25" disks/drives instead (common 40 track DSDD 360k disks -like PCs were using), and that would have had the advantage of greater potential (out of the box) PC compatibility on top of cost . . . but there's a whole other set of trade-offs. (from the practical -possibly media reliability issues- and aesthetic -3.5" made the ST look more high-tech)
Plus, 40 track disks also are a bit funky to move forward with since there's some level of incompatibility with 80 track (720k and 1.2 MB) disks (namely issues with old 40 track disks reading 40 track disks written/modified on 80 track drives) . . . PCs experienced this problem. (albeit, if Atari had used 720k DSDD 80 track disks from the start, they'd avoid that problem and have higher capacity than the SSDD disks used -plus cheaper drives and media- though PC compatibility would be more limited -the 80 vs 40 track issue as well as the limited support for 720k DSDD 80 track 5.25" disks on PCs -unlike 360k and 1.2 MB, which were both standardized by IBM)
Hell, they could have used a single-sided 80 track DD drive and still allowed 720k via flipping.

I already started a discussion on just this issue back here:
http://www.atariage....28#entry2168328
(from a practical sense, I still think 5.25" disks may have been better than what Atari used -be it 80 or 40 track, but from a marketing perspective it's a bit of a mess)

philipj, on Tue Jan 10, 2012 7:54 PM, said:

I've had some discussions with Kskunk on this before (and with some others too), and the Lynx chipset would not work well for a console, it's just too limited for that. (shared 8-bit bus, moderate use of FPM RAM bandwidth via FIFOs for the blitter, and only 4-bit color -and even at 4-bit color, it would have been much too slow to realistically manage a 256-320x200 ish screen)
Now, a lynx-like system design optimized more as a console could have been interesting, but there's still the trade-off of a framebuffer vs sprite/object/character based graphics. (like other consoles of the time, or the Panther)

I also considered the old Flare 1/slipstream chipset, but that's not particularly good either due to the requirement of SRAM/PSRAM in the "fastRAM" bank and generally primitive blitter, and the need for framebuffer space in all games. (no optimization for phrase/word wise pixel manipulation, just simple copy capabilities working 1 pixel at a time or block-copying data without masking transparent pixels, choppy scrolling using the VDC, no pixel look-up/expansion/offset support, etc)

The Panther itself wasn't right either, but the architectural concept is interesting in any case. (the use of SRAM limited cost effectiveness and the limit of 32k would have kept the system cost down but complicated programming and reduced cost effectiveness of games -not enough space to decompress into- and a pretty nice Ensoniq sound processor limited to 8k of sample RAM where basic/simple DMA sound embedded on the main system bus would have been adequate and much more cost effective -and actually more flexible since you wouldn't be limited to copying samples into the 8k block on the sound bus, but directly pulling samples from ROM/RAM and software mixing -the ensoniq chip had added additive/FM/AM synth capabilities too, but those are far less foolproof than plain samples, especially for western developers -given how a lot of DOS and MD/Genesis and YM2151 arcade games turned out compared to sample-based stuff . . . especially in the US -European developers tended to push synth capabilities more)

And there's the issue with the Panther's CRAM being limited to 32 entries (due to chip space) when there's support for 256 (1/2/4-bit pixels are expanded via a 8-bit offset, 8-bit pixels are used directly) . . . since it used 18-bit RGB, use of an off the shelf VGA RAMDAC would fit well too. (meaning no on-chip DACs or CRAM on early models, and more room to extend the line buffers to the full 8-bits)

A panther-derivative using DRAM instead of SRAM (and cheap/foolproof DMA sound) would have been interesting . . . or if it did stick with SRAM, they would have needed to make the investment in more RAM at least and preferably an interleaved bus mode allowing the 68k full bandwidth at the expense of 1/2 the OPL bandwidth (useful for 3D games or CPU/sound intensive games in general), something SRAM would favor in general (no page-mode/burst accesses to optimize for). They were at least using low-end (100/120 ns) SRAM, and compared to the multi-bus SRAM/PSRAM/VRAM based competition on the market, even 128k SRAM (4 32kx8-bit chips) with the Panther still may have been significantly cheaper than the likes of the MD or especially SNES. (at least if they had it in similar volumes)
Or perhaps even clocking the system back to 12.5 MHz (cheaper CPU and ASICs too) and working around 80 ns DRAM (which should allow 160 ns non-page-mode accesses and was fairly cheap/common by 1989/90) and use that in place of the SRAM (potentially with an interleaved mode too) without the added support for page-mode. (and thus a simpler DRAM controller too -much like the interface used in the ST, but a bit faster)
Hell, even plain 120 ns DRAM with the 16 MHz system (250 ns random reads/writes) would have meant decent bandwidth at least (especially with the OPL saturating the bus -16 MB/s), and that would have certainly stuck to very cheap/low-end RAM. (and the same RAM being used in the bottom-end ST models)

But this is, again way off the original topic. (anyone interesting in a new discussion topic on a Jaguar predecessor/7800 successor? -not sure what forum it should go in)

Quote

A healthier Atari would have obviously meant a healthier Jaguar (technically and -more importantly- management/marketing/PR wise) . . . and possibly a later start and later release of the hardware (meaning a better perspective of the market to design the system around and less foresight/guesswork to get right -like understanding the importance of C/library-level support/performance and texture mapping support and general blitter performance -for 2D and 3D games).

And, as it was, the 2 areas the Jaguar Chipset was flexible/modular with were RAM configuration (2 banks FPM DRAM, up to 4 MB each) and the CPU (support for any x86 or 68k based chip, and thus compatibility with most other processors as well -since they tended to comply with 1 or parts of each of those architectures).

But, as far as homebrew projects are concerned, it would probably be easier to find an old CoJag board with an '020 or R3k and the added VRAM in the 2nd bank for that matter.

Bryan, on Wed Jan 11, 2012 8:51 AM, said:

The problem was that Atari was just in no shape to support/manage such a console by 1993, even if it had been a cakewalk to program for, they wouldn't have had a much better chance than they did historically. (their position also compromised the low-cost potential of the system since, while a very aggressively low-cost design, they were limited in negotiation for components and manufacturing -as well as volumes- and were also forced to sell it at a profit due to their financial situation, and retailers generally sold at much higher margins for hardware/software than for more trusted brands -the game prices were heavily inflated over contemporary SNES/Genesis games of similar ROM sizes)

Albeit, had Atari been in a better managed/funded position in the first place, some of the bugs/problems with the Jaguar may have been worked out too. (and, assuming it had a successful direct predecessor on the market, it also could have been aimed at a later date -further addressing the bugs and potentially aiming at a larger/different feature set)


However, it's still amazing that, in spite of the Jaguar's extremely weak retail performance (only 135k units sold through 1995), there were a significant number of very skilled/ambitious programmers to work on the system. (Carmak was among them, though the Phase Zero team and Battlesphere teams too -among others)