Jump to content
IGNORED

Its 1993, you're in charge of the Jag, what do you do?


A_Gorilla

Recommended Posts

And your point is? The fact remains the 020 would have allowed the Jerry to read it in half the time. Also

they would have not hard coded the DSP to accomodate a 68k but instead an 020...in fact if this is what

was the case the delay might have been shorter....providing they hard coded it for an 020.

 

My question is: why did the designers hard code the DSP memory pipeline to delay 6 cycles? Why wasn't the DSP made to access the bus at a similar speed to the GPU? Was it related to the 68000 or a separate issue?

Link to comment
Share on other sites

And your point is? The fact remains the 020 would have allowed the Jerry to read it in half the time. Also

they would have not hard coded the DSP to accomodate a 68k but instead an 020...in fact if this is what

was the case the delay might have been shorter....providing they hard coded it for an 020.

 

My question is: why did the designers hard code the DSP memory pipeline to delay 6 cycles? Why wasn't the DSP made to access the bus at a similar speed to the GPU? Was it related to the 68000 or a separate issue?

 

LOL..this is like asking God why He chose to create the universe in six days and rested on the seventh

instead of just zapping it all into exsistence in a nanosecond.

 

Well..... actually not really.....

 

But it is because of the 68k and quite frankly, the bosses(the Tramiels) poking their

noses into the engineer's business and not letting them control the design stage more.

 

Flare wanted the GPU/DSP combo to have more power but the lame 'warm and fuzzy' nonsense

seemed to prevail....the 020 would have been just as warm and fuzzy and more importantly

more practical and simpler for coders to get serious performance out of the Jaguar in a

much faster time frame.

 

You see....the Handy(Lynx) was already a finished design and at that point was ready for

production when Epyx settled out of court with them. If Flare had done their homework, they'd

have been better off not showing off the Jag chipset to the Tramiels until after it was set up

as they wanted it to be.

 

To think the money wasted on the Panther development and how it could have been better served

toward improving the Jaguar design, still makes my head spin.

 

Again.....the 020 would have...

 

Doubled the data width to the bus for both the host(020) and the DSP

 

Allowed true parallel operation between all three processors

without bus contention in all three locals

 

Double the speed of the host(020)

 

Allowed the 020 to be a practical AI and game logic processor where the

68k could not be(and instead it is a detriment).

 

The tool chain for the 020 is much more robust and therefore would have

allowed for much quicker porting of POPULAR games. No matter how well

the 68k tool chain is, it would not have solved the contention issues.

 

This system even with it's unified bus would have easily competed with a PSX

and would have been stronger than a Saturn.

 

The ONLY benefit of a CD drive is a larger data medium and would not help the

performance of the Jaguar what so ever.

Edited by Gorf
Link to comment
Share on other sites

OK, sorry for that rather transcendental question about Tom and Jerry...

 

I already pretty much understand the rest, at very least in a general aspect; CD is good for cheap media, more flexible in the sense of mass storgage facilitating large streaming audio and video files to be stored for playback, and cheapeer in general, even compared to small games on ROM cartridges (1-2 MB). SO definitely attractive to developers and distributors/retailers. The cost is obviously with the base hardware, adding substancially to cost and atari couldn't afford to take losses with extreme razor-blade marketing like Sony used. (at best, Atari might get away with selling at cost, at least initially, maybe for a small loss after the Sega settlement and/or if profits from game sales would sustain that) There's always the CD add-on, but that does complicate things, still, that could be handeled more fluidly, especially if some cart hames had provisions for expansion via CD. (music, added levels, multiplayer, etc) I do agree the hardware situation with the CPU is more significant.

 

 

Anyway, maybe this is getting into questions without straight answers again, but if Jerry's final design was limited by the 68k (other than just the bus width), does that extend to the CoJag as well, with 68EC020/MIPS R3000? (again, I mean the access delays compared to the GPU, not to mention the write bugs -the latter I assume is just a result of being rushed)

And if the implementation of the 68k had such a significant impact on the final design of Jerry (again, the access delays), how long had the 68k been the definite choice for the CPU? I'd gotten the impression that Flare went out of their way to design the system to accept multiple CPU types (x86, 680x0, MIPS R2000/3000 architecture).

Kskunk's staement really gave me the impression that the access delay (and write bugs) were not related to the 68000's implementation, with it's only direct detriment to Jerry being the 16-bit data path.

 

 

 

 

 

And, this may be completely crazy, but just kind of throwing it out there: Would it at all have been a possibility to use DRAM for local memory on TOM and JERRY instead of SRAM? (with the associated refresh circuitry onboard as well) Maybe this is a better question for kskunk though, vaiously you'd get a loss in performance from refresh, but you could fit a lot more RAM without increasing the die size. (depending on how much space the refresh circuitry took up, maybe 3-4x the size of the Jag's scratchpads; 12-16 kB on TOM and 24-32 kB on Jerry)

Link to comment
Share on other sites

I can't follow all the tech stuff you guys are talking about above.

And i didn't read the previous pages of replys. Hopefully I'm not repeating

anything said earlier.

 

I was reading some of my old ST Format mags. And i was surprised to

see a listing for a summer 94' release for Mortal Kombat and Batman Forever.

 

Atari should have made darn sure those two games made it out the door.

They both have mass appeal. Imagine those as pack-in games!

 

I still have more issue's of ST format to read, i wonder what other

surprise unreleased games I'll see listed in there.

 

BTW: one of the STF mags had a review of Frontier:Elite 2.

 

That game would have been SWEET on the Jag!!! I'd pay $100 today for an

updated version of it released on the JAG!

 

anyways.. i have more mags and tons of pages to read on this thread

 

-rick

Link to comment
Share on other sites

There is a complete list of unreleased games for the Jaguar on JS2 that I spent many many hours compiling. Most of the games have write-ups too and screenshots where possible too of either the Jag version or other released versions.

Edited by The_Laird
Link to comment
Share on other sites

My question is: why did the designers hard code the DSP memory pipeline to delay 6 cycles? Why wasn't the DSP made to access the bus at a similar speed to the GPU? Was it related to the 68000 or a separate issue?

 

Please ignore if you're not into technobabble... Without talking to the original designers, we can only speculate. So here goes. :)

 

If you want the low level technical reason: It looks like a separate issue. Inside Jerry's source code (JMEM.NET), there is a deliberate delay injected before each memory access. Surrounding comments shed some light on what's going on:

 

Imagine if code running on the DSP wanted to read the joystick register (which is implemented OUTSIDE Jerry -- on the external bus). It would need to create an external bus cycle, negotiate with Tom for access to the external bus, then wait around for Tom to grant permission. It's only half done at this point. Now a separate part of Jerry needs to process the incoming address, enable the correct chip select, then wait for the external joystick register bus to accept the request and settle, the finally latch the data and surrender the bus. This is a lot of stuff to do and it's easy to see why 6 cycles are needed.

 

Summing up the above paragraph is this comment in Jerry's code: "when DSP performs transfers to JERRY, master and slave state machines may conflict" And then we have the extra delay in the state machine.

 

If you want the high level "WTF is wrong with Jerry's bus design":

 

Tom has no problems with slow bus access because all bus mastering decisions can occur inside Tom within one cycle. This is part of the reason why Tom accesses the bus faster -- it owns the bus, so it can just grab it without waiting for permission. No other part of the Jaguar can do this.

 

Jerry inherited most of Tom's design, but it has huge hacks to Tom's bus controller, because Jerry isn't allowed to make bus decisions. Instead it has to communicate with Tom before doing anything.

 

We know that Jerry was created near the end of Tom's design cycle, so there probably wasn't time to design a proper bus controller for it. They could have done a lot better if they had created a unified incoming/outgoing state machine with some (well-tested) shortcuts.

 

So my speculation is: Jerry's bus performance sucks because they didn't have time to do a new bus controller design and probably thought 'this will have to be good enough for sound'. It's just a bunch of hacks, which may also explain all the other bugs in that part of Jerry.

 

- KS

Edited by kskunk
Link to comment
Share on other sites

So my speculation is: Jerry's bus performance sucks because they didn't have time to do a new bus controller design and probably thought 'this will have to be good enough for sound'. It's just a bunch of hacks, which may also explain all the other bugs in that part of Jerry.

 

I agree whole heartedly. It's the same friggin core and there was no reason other than

the external access issues you mentioned...which I also agree could have been dealt with

in a much more reasonable matter. So, no suprise here. Fact remains, that an 020 would

have been a much better 'warm and fuzzy' choice all around for Jaguar. If Atari had a

real set of balls they would have left the 'warm and fuzzy' crap out, used a small unified cache between the two and has another core with nothing on it outside of a

nice big 8 or 16k local. No video, no sound...just a hard core AI proccesor.....

one compiler and assembler.

 

Let's face it...they went with the 68k because they had a shitload of them left

over from the ST line, or at very least were in the middle of a buy deal with

Motorola.

 

 

 

So I revise what I would have done....

 

 

Same RISC Core with 8 or 16k local strictly for AI

 

Tom with double buffered blitter regs(and both channels with fractionals)

and TRUE dual write backs for the GP regs

 

Jerry with properly working communication unit(not the cheap POS they used)

A usuable workable compiler and MAC would have been fine for assembly.

 

The unified bus would have been fine since all three(four if you count the blitter)

would have been able to run in TRUE parallel and would have easily handled anything

the PS1 could have thrown at it.

Edited by Gorf
Link to comment
Share on other sites

So my speculation is: Jerry's bus performance sucks because they didn't have time to do a new bus controller design and probably thought 'this will have to be good enough for sound'. It's just a bunch of hacks, which may also explain all the other bugs in that part of Jerry.

 

I agree whole heartedly. It's the same friggin core and there was no reason other than

the external access issues you mentioned...which I also agree could have been dealt with

in a much more reasonable matter. So, no suprise here. Fact remains, that an 020 would

have been a much better 'warm and fuzzy' choice all around for Jaguar. If Atari had a

real set of balls they would have left the 'warm and fuzzy' crap out, used a small unified cache between the two and has another core with nothing on it outside of a

nice big 8 or 16k local. No video, no sound...just a hard core AI proccesor.....

one compiler and assembler.

 

Let's face it...they went with the 68k because they had a shitload of them left

over from the ST line, or at very least were in the middle of a buy deal with

Motorola.

 

 

 

So I revise what I would have done....

 

 

Same RISC Core with 8 or 16k local strictly for AI

 

Tom with double buffered blitter regs(and both channels with fractionals)

and TRUE dual write backs for the GP regs

 

Jerry with properly working communication unit(not the cheap POS they used)

A usuable workable compiler and MAC would have been fine for assembly.

 

The unified bus would have been fine since all three(four if you count the blitter)

would have been able to run in TRUE parallel and would have easily handled anything

the PS1 could have thrown at it.

 

 

But... would the cost of the Jaguar still been $250?? or $450???

 

 

By the way, you don't have any copies of Gorf left, do you? I'd love to buy one... but I think I missed the boat? I seem to recall there is some kind of problem or... some people were angry, or you were angry, I'm not sure... haha... so if by me bringing this up, then I totally apologize, but I'd love to have a copy of Gorf.

Link to comment
Share on other sites

Thanks for that great explanation Kskunk.

 

Would my suggestion to use local DRAM instead of SRAM scratchpads onboard Tom and Jerry at all feasible, or completely unrealistic?

 

Same RISC Core with 8 or 16k local strictly for AI

 

Tom with double buffered blitter regs(and both channels with fractionals)

and TRUE dual write backs for the GP regs

 

Jerry with properly working communication unit(not the cheap POS they used)

A usuable workable compiler and MAC would have been fine for assembly.

 

The unified bus would have been fine since all three(four if you count the blitter)

would have been able to run in TRUE parallel and would have easily handled anything

the PS1 could have thrown at it.

 

 

But... would the cost of the Jaguar still been $250?? or $450???

 

Any higher cost would be tied to designing the cache+additional RISC chip and fully working out any bugs. (though they could have promoted Tom to CPU and stuck with just the 2 RISCs with cache instead of adding a 3rd RISC processor)

In the long run it may likely have been cheaper than the current Jag, not having to buy a CPU from a 3rd party, only having to pay the chip vendor for manufacturing (Toshiba I beleive).

 

The bigger question is whether Flare could have designed and tested hardware like that given the limited budget/time available, regardless of external influences. (ie Atari Corp. management) I think Kskunk mentioned that cache would likely be the most intensive part to design, however, even if chache wasn't possible they could have designed the RISC to be more high-level freindly and intend the RISC on TOM to act as the CPU. (still limmited in parallel processing capabilities with the shared bus though)

 

Additionally, it might have been possible to make flare's RISC processor avalable as an embedded processor to the market or at least have the core open for licencing. (the former would require more invenstment on Atari's part, the latter I would think pretty straightforeward)

Link to comment
Share on other sites

But... would the cost of the Jaguar still been $250?? or $450???

 

I do not see why not. It's the same core. It might have cost a closer to $300 but well worth it.

 

By the way, you don't have any copies of Gorf left, do you? I'd love to buy one... but I think I missed the boat? I seem to recall there is some kind of problem or... some people were angry, or you were angry, I'm not sure... haha... so if by me bringing this up, then I totally apologize, but I'd love to have a copy of Gorf.

 

No more left and even if they were I could not sell them legally. The only reason for being

upset was the ludicrous and dubios accusation of code I wrote from scratch being compared to

someone downloading illegal ROM's. The worst that could be said is I did not have Midway's

permission to use the IP. I had Jamie Fenton's blessing. She just could not verify if the

rights fully reverted to her or not. With that I removed it from production and market. I did

what I believed to be the right and proper thing. Bet you any money those complaining still

never removed all the illegal ROM's from their drives.

 

It turns out that Midway did indeed renew the IP rights in 2000. So much for that since Midway

is no longer. Now it's Warner's IP due to the recent demise of Midway and sale of It's IP's

to Warner....and no, I have no desire or intention to persue Warner on the matter. In the words

of Jesus...."it is done....it is finished."

Link to comment
Share on other sites

Would my suggestion to use local DRAM instead of SRAM scratchpads onboard Tom and Jerry at all feasible, or completely unrealistic?

 

I assume you mean dedicated DRAM chips attached to each chip, since eDRAM (on-chip DRAM) was still a research project in the early 90s.

 

The real problem with FPM DRAM (the only affordable kind in 1993) is high latency. The SRAM scratchpads on Tom and Jerry have a latency under 25ns for random access. That means you can comfortably run the JagRISCs at 26.6MHz (each cycle being 37.6ns) without any wait states (lost cycles) on instruction fetch or data access.

 

A random access in FPM DRAM takes nearly 200ns -- or 5 cycles for a JagRISC. A sequential in-page access can take as little as 2 cycles, but that means even in the best case you've given up half your potential performance.

 

That's not the worst of it though. It's much more complicated to design a fast processor with memory being so slow, since you need to be able to try to mask the latency of external memory. Most RISCs use cache for this. The JagRISCs attempt to mask latency with a simple prefetch buffer, but as we know even that is buggy compared to using scratchpad.

 

The final problem is cost. You probably want a 32-bit bus (since this is the width of the scratchpads). 16-bits would halve performance again. A separate 32-bit bus is going to want around 60 pins. Chip packages with a lot of pins are expensive -- the number of pins is a major percentage of the cost in custom chips. Also, while transistors get cheaper every year (thanks to Moore's law), pins cost the same, so having a lot of extra pins for extra busses means you can't cost reduce very well in the future. And of course a 32-bit bus means you need at least 2 extra DRAM chips, which makes your PCB larger which trickles into other costs such as case size and packaging and so on...

 

Next thing you know you have a Saturn, which is NOT a cost effective console. (But man it has a cool looking motherboard. ;)

 

From a simplicity, performance, and cost perspective, scratchpad SRAMs are hard to beat!

 

- KS

Link to comment
Share on other sites

From a simplicity, performance, and cost perspective, scratchpad SRAMs are hard to beat!

 

Yeah it's one of the few good design choices they made. DRAM would suffer from all sorts of

performance issues and foot print issues. The RIC's would have been pretty lame using DRAMS.

Especially back in the day of the Jaguar. I think my revised senerio with Tom, Jerry and another

RISC core with a larger local would have been more cost effective and performance rich.`

 

The writebacks would be one thing I'd fix on the register file of the RISC's.

Edited by Gorf
Link to comment
Share on other sites

What about having a separate DRAM chip onboard the same package, but independent from the processor die? Was that still experimental as well?

 

That's called MCM (Multi-Chip-Module). Although the idea of MCM has been around forever, the first mass produced MCM was the Pentium Pro in 1995 and it was considered a very expensive approach at the time.

 

These days you see MCMs all over the place -- for example, on laptops, cell phones, and the XBox 360 GPU. This is only due to a confluence of cell phone miniaturization and flip-chip packaging, both of which happened around a decade after the Jaguar was being designed.

 

It's amazing how far things have come in 16 years!

 

- KS

Link to comment
Share on other sites

I assume you mean dedicated DRAM chips attached to each chip, since eDRAM (on-chip DRAM) was still a research project in the early 90s.

What about haiving a separate DRAM chip onboard the same package, but independent from the processor die? Was that still experimental as well?

 

DRAM was just not practical for this sort of application, especially since both cost

and performance hits would come into play. also keep in mund as KSkunk pointed out that

the number of pins would and the fact that most DRAM's of the time were 16 bits.

It would have greatly complicated the design im sure.

Edited by Gorf
Link to comment
Share on other sites

  • 2 weeks later...

Well, assuming I've time traveled back and the Tramiels have signed and notarised this...

 

1. Cancel the "Test Launch" in New York and San Francisco. All it does is rob you of momentum and make you look stupid to the magazines. Anyone taking a serious look at 3D0's business model knows it combines the stupidest marketing decisions of SNK, FM Towns, and Amway franchisees. Wait another year so that we can then...

 

2. Replace the 68000 with a Digital Alpha 21064 (if possible bribing Digital for a discount with free licenses of any and all unexpired and still relevent networking technology associated with the Transputer, giving them a leg up on Sun and Sillicon Graphics in the workstation market) decolcked to 75 megahertz. The 68000 was a boat anchor that made even less sense in the spec than the 6502s in the PC Engine/TurboGraphix 16 and Super A'Can and the Z80 on the Amstrad GX4000.

 

3. As mentioned previously, the price of RAM is about to fall through the floor. Load up at least 8 meg if you can, at least 6 of it as main system RAM.

 

4. Cartridge media are too small (in terms of capacity) and too complex for the cost to make them. CD-ROM drives are too expensive and way too slow at this point to use as a main drive. I will partner with Insite Peripherals to produce some variation of the Floptical format, or else go to Iomega and license the Zip. (or I can do both: one for software media the other for save data).

 

5. Spend the time to hammer out the stupid data interface, bitcode interpretation, and pipeline bugs that plagued the project at the time. The company's honor is on the line. I cannot afford to tarnish it further by conscpripting full price customers as guinea pigs and beta testers.

 

6. Seek out Ross Smith, Gary Tiroli, and Scott Sellers and tell them I want to build a true 3D hardware subsystem fed by either Jerry or the Alpha directly. 3Dfx's development cycle better fits consoles than computer cards anyway.

 

7. Ship development kits unsolicited and free of cost to anyone and everyone who's anyone in computer and videogames except Hudson (who's in bet with Nintendo and NEC) and Sammy (Who's in bed with Sega).

 

8. Release said development kit to the public (Plus a x4 CD-ROM Drive and a TOS 5.0 using a GUI ripped off of Google Chrome or Windows 7) for sale as the next mark of Atari Falcon at the same time the Jaguar is released to the general public.

 

9. Replace the standard controlers with something resembling a Dual Shock or a Sega Dreamcast controler, or better yet a Nintendo Super Advantage (with an anolog stick) or Beeshu Ultimate Superstick. The Standard Contoler combined the worst aspects an NES D-Pad and a Colecovision controller.

 

10. Spend the time to iron out the games to get them working properly. Trevor McFur needs convincing sound effects and an actual music track, for starters. I want to see at least 10 properly featured, finished, dubuged, and playtested titles before launch.

 

11. Stockpile them in werehouses atarting in June 1994 (or August at the latest) for mass shipment the week before Thanksgiving weekend, insisting that the rollout happen everywhere on Black Friday. Send systems and (first person) games to the magazines for review in September so that reviews and buyers' guides are on time for the December Issue the Wednesday before Thanksgiving.

 

12. Around May 1996, release The Jaguar 2: A die shrink to .5 micron process that cuts power consumption to 1/3 and the price by ca. $100, thus making the Playstation a very bad bargain on paper, and possibly short-circuit Final Fantasy VII as the Playstation's killer ap.

Link to comment
Share on other sites

Well, assuming I've time traveled back and the Tramiels have signed and notarised this...

 

Are you teasing? If so, your deadpan is too good. ;)

 

You're describing a pretty sweet console, but Atari didn't have the engineering resources of DEC plus SGI plus IBM. If they did, and consumers didn't mind shelling out $1495 for a console, that vision could be achievable in 1994... :D

 

- KS

Link to comment
Share on other sites

In addition to kskunk's ammusing points, I have a couple to make. ;)

 

1. Cancel the "Test Launch" in New York and San Francisco. All it does is rob you of momentum and make you look stupid to the magazines. Anyone taking a serious look at 3D0's business model knows it combines the stupidest marketing decisions of SNK, FM Towns, and Amway franchisees. Wait another year so that we can then...

OK, but a major reason for doing the half-assed pre-launch was to drum up investors, they were critically short on funding at the time, the other option being use of the Tramiel's private funds. (orm better, create a public spin-off company for the Jag and throw in hints toward internet capabilities that were huge in market speculation at the time, though that's probably something necessary a bit earlier than 1993, maybe there was still time though)

 

Extending the test launch to UK+Europe (as originally announced) probably would have helped too given Atari's stronger/more recent presence in the electronics world over there. (with the popularity of the ST line) Maybe go as far as emphesizing it most in those regions. (I wouldn't even bother with Japan, just not worth the troube to try to get into that market)

 

 

2. Replace the 68000 with a Digital Alpha 21064 (if possible bribing Digital for a discount with free licenses of any and all unexpired and still relevent networking technology associated with the Transputer, giving them a leg up on Sun and Sillicon Graphics in the workstation market) decolcked to 75 megahertz. The 68000 was a boat anchor that made even less sense in the spec than the 6502s in the PC Engine/TurboGraphix 16 and Super A'Can and the Z80 on the Amstrad GX4000.

Heh, yeah, that's a cost effective choice. ;) (even if they managed to get the chips at cost)

Using the 65C02 derivative int eh PC-Engine wasn't unfortunate, it worked quite well and was relatively powerful, roughly 2x as powerful as the SNES's CPU. (more with wait states taken into account) I have no idea why the SNES's CPU is clocked that slowly, they used DRAM to save cost, but faster DRAM should have been widely available at reasonable cost by 1990. (unlike the PC Engine's tiny 8kB of SRAM, that was certainly a limitation -granted the CD system greatly expanded that with various system cards)

 

Anyway, the 68EC020 was probably the most practical step up from the 68k, also what the initial CoJag used, though the home system would probably go for the cheaper/more available 16.7 MHz rated version than the 25 MHz one of the CoJag.

 

3. As mentioned previously, the price of RAM is about to fall through the floor. Load up at least 8 meg if you can, at least 6 of it as main system RAM.

kskunk addressed this already, see: http://phe.rockefeller.edu/LogletLab/DRAM/dram.htm DRAM prices were not falling at that point. However, I'm not sure about price changes between speeds of DRAM available, maybe some faster DRAM would have been affordable to use a few months later. (still sticking with FPRAM of course, not EDO let alone SDRAM -which Sega had alread started using in fall of 1994, but just some faster timed FPRAM, instead of 75 ns, maybe 70 ns, perhapd even 65-60 ns -although you'd also want to avoid running the system fast enough to require heat spreaders and add to cost) Again, I have no idea if faster DRAM was becoming more affordable though. (but it's obvious that prices for any IC size of RAM -useful for the Jag- was not dropping between 1992 and 1995)

 

4. Cartridge media are too small (in terms of capacity) and too complex for the cost to make them. CD-ROM drives are too expensive and way too slow at this point to use as a main drive. I will partner with Insite Peripherals to produce some variation of the Floptical format, or else go to Iomega and license the Zip. (or I can do both: one for software media the other for save data).

I tossed this idea around myself, thinking in the context of nentendo as well (they did eventually release that ZIP-like DD in japan -to little interest), but I'm not sure that would be a good idea. ZIP is known for reliability problems, particularly early on, and the disks (while cheaper than carts) would be a good deal more expensive than CDs and more limited storage wise (though load much faster), the drices would still be expensive as well, granted less-so than CD.

I think relying on compressed data loading from ROM carts may have been sufficient. (thus minimizing ROM sizes and avoiding expensive, complex hardware with moving parts)

 

5. Spend the time to hammer out the stupid data interface, bitcode interpretation, and pipeline bugs that plagued the project at the time. The company's honor is on the line. I cannot afford to tarnish it further by conscpripting full price customers as guinea pigs and beta testers.

Definitely, if possible. (there's kind of a hierarchy of what hardware problems are most important, I think the 68k is at the top usually, then a mix of other stuff, like mmu bugs, lack of double buffering for the blitter, and problems with jerry)

 

10. Spend the time to iron out the games to get them working properly. Trevor McFur needs convincing sound effects and an actual music track, for starters. I want to see at least 10 properly featured, finished, dubuged, and playtested titles before launch.

Yep, defintely somthing cleaner hardware would have facilitated.

 

 

12. Around May 1996, release The Jaguar 2: A die shrink to .5 micron process that cuts power consumption to 1/3 and the price by ca. $100, thus making the Playstation a very bad bargain on paper, and possibly short-circuit Final Fantasy VII as the Playstation's killer ap.

Something else kskunk mentioned: TOM and JERRY were produced using .5 micron process, rather signficant for 1993, no?

  • Like 1
Link to comment
Share on other sites

Well, assuming I've time traveled back and the Tramiels have signed and notarised this...

 

1. Cancel the "Test Launch" in New York and San Francisco. All it does is rob you of momentum and make you look stupid to the magazines. Anyone taking a serious look at 3D0's business model knows it combines the stupidest marketing decisions of SNK, FM Towns, and Amway franchisees. Wait another year so that we can then...

 

2. Replace the 68000 with a Digital Alpha 21064 (if possible bribing Digital for a discount with free licenses of any and all unexpired and still relevent networking technology associated with the Transputer, giving them a leg up on Sun and Sillicon Graphics in the workstation market) decolcked to 75 megahertz. The 68000 was a boat anchor that made even less sense in the spec than the 6502s in the PC Engine/TurboGraphix 16 and Super A'Can and the Z80 on the Amstrad GX4000.

 

3. As mentioned previously, the price of RAM is about to fall through the floor. Load up at least 8 meg if you can, at least 6 of it as main system RAM.

 

4. Cartridge media are too small (in terms of capacity) and too complex for the cost to make them. CD-ROM drives are too expensive and way too slow at this point to use as a main drive. I will partner with Insite Peripherals to produce some variation of the Floptical format, or else go to Iomega and license the Zip. (or I can do both: one for software media the other for save data).

 

5. Spend the time to hammer out the stupid data interface, bitcode interpretation, and pipeline bugs that plagued the project at the time. The company's honor is on the line. I cannot afford to tarnish it further by conscpripting full price customers as guinea pigs and beta testers.

 

6. Seek out Ross Smith, Gary Tiroli, and Scott Sellers and tell them I want to build a true 3D hardware subsystem fed by either Jerry or the Alpha directly. 3Dfx's development cycle better fits consoles than computer cards anyway.

 

7. Ship development kits unsolicited and free of cost to anyone and everyone who's anyone in computer and videogames except Hudson (who's in bet with Nintendo and NEC) and Sammy (Who's in bed with Sega).

 

8. Release said development kit to the public (Plus a x4 CD-ROM Drive and a TOS 5.0 using a GUI ripped off of Google Chrome or Windows 7) for sale as the next mark of Atari Falcon at the same time the Jaguar is released to the general public.

 

9. Replace the standard controlers with something resembling a Dual Shock or a Sega Dreamcast controler, or better yet a Nintendo Super Advantage (with an anolog stick) or Beeshu Ultimate Superstick. The Standard Contoler combined the worst aspects an NES D-Pad and a Colecovision controller.

 

10. Spend the time to iron out the games to get them working properly. Trevor McFur needs convincing sound effects and an actual music track, for starters. I want to see at least 10 properly featured, finished, dubuged, and playtested titles before launch.

 

11. Stockpile them in werehouses atarting in June 1994 (or August at the latest) for mass shipment the week before Thanksgiving weekend, insisting that the rollout happen everywhere on Black Friday. Send systems and (first person) games to the magazines for review in September so that reviews and buyers' guides are on time for the December Issue the Wednesday before Thanksgiving.

 

12. Around May 1996, release The Jaguar 2: A die shrink to .5 micron process that cuts power consumption to 1/3 and the price by ca. $100, thus making the Playstation a very bad bargain on paper, and possibly short-circuit Final Fantasy VII as the Playstation's killer ap.

 

 

The 020, the fixed write backs, REAL tools, along with a double buffered blitter reg file would

have been much simpler, more practical solution and would have easily competed with the PS1.

Even to the point where Sony might have had to rethink it's own design to really make others

think twice about selecting a current PS1 design over a properly done Jag. And to agree with

KSkunk, you could by a nice PC with a monster graphics card for the cost of the Jag you are

dreaming about. 4 megs ram might have been better too but 2 megs would have worked.

Edited by Gorf
Link to comment
Share on other sites

The 020, the fixed write backs, REAL tools, along with a double buffered blitter reg file would

have been much simpler, more practical solution and would have easily competed with the PS1.

Even to the point where Sony might have had to rethink it's own design to really make others

think twice about selecting a current PS1 design over a properly done Jag. And to agree with

KSkunk, you could by a nice PC with a monster graphics card for the cost of the Jag you are

dreaming about. 4 megs ram might have been better too but 2 megs would have worked.

 

The Playstation would still have wiped out a 'better' jaguar - as even the Jaguar 2 blitter wouldn't have competed ( at the speeds Atari were talking about in 1995 )

The only way for the jag to have survived would have been with more ( and better ) software at launch. Then they could have faced the launch of PS1 and Saturn backed with an install base in millions, instead of a palty 100k.

( I favoured CD as a hardware change at launch, but really the software is all that matters.. )

Link to comment
Share on other sites

 

The Playstation would still have wiped out a 'better' jaguar - as even the Jaguar 2 blitter wouldn't have competed ( at the speeds Atari were talking about in 1995 )

 

Yes it would have and it would have had better software as ports would be much more realistic on an 020, with

better blitter and no penalties on stalls. You just do not have a clue and I am not going to go through the

clear and simple reasons as to why it would be able to for the umpteenth time.

Link to comment
Share on other sites

 

The Playstation would still have wiped out a 'better' jaguar - as even the Jaguar 2 blitter wouldn't have competed ( at the speeds Atari were talking about in 1995 )

 

Yes it would have and it would have had better software as ports would be much more realistic on an 020, with

better blitter and no penalties on stalls. You just do not have a clue and I am not going to go through the

clear and simple reasons as to why it would be able to for the umpteenth time.

 

clear and simple and wrong reasons :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...