What could have saved the Jag?

[Lostdragon]

1 hour ago, JagChris said:

No it's a raycast demo HVS whipped up and sent to Atari showing them what they accomplished with the aforementioned GPU compiler. If you read the read me right beneath it you'll see they're trying to show Atari it's straight C code without optimization etc.

 

Atari ignored them.

So no different than how they treated Eclipse then? 

 

Posted this in full some time ago but for newcomers, Marc from Eclipse in discussion with Zero 5 coder, Matthew Gosling :

 

 

"We worked on a new 3D engine designed around this routine to create a completely texture mapped racing game with a decent frame rate.

 

Unfortunately, as with some other proposed projects, Atari was just
too blind and unflexible to see what big step foward we could achieve
and so we had to cancel development after a few months as we couldn't
afford to proceed without Atari's support. At least some results from
our research were used in IS2.    "

 

 

If we are going to once again, go over the topic of how Atari treated it's 'best' development teams, we need a broader canvas than simply Atari ignored HVS. 

 

Tramiel Atari ignored pretty much all and sundary at one time or another and the Jaguar library suffered as a result. 

[agradeneu]

On 8/28/2022 at 8:55 AM, Sauron said:

You probably should have explained that better, then. Initially, it looks like you're referencing yourself on it, thus the cause for confusion. 

If 80% of posts to a topic are written by the same person it makes you a bit suspicious. 

 

 

[agradeneu]

14 minutes ago, Lostdragon said:

So no different than how they treated Eclipse then? 

 

Posted this in full some time ago but for newcomers, Marc from Eclipse in discussion with Zero 5 coder, Matthew Gosling :

 

 

"We worked on a new 3D engine designed around this routine to create a completely texture mapped racing game with a decent frame rate.

 

Unfortunately, as with some other proposed projects, Atari was just
too blind and unflexible to see what big step foward we could achieve
and so we had to cancel development after a few months as we couldn't
afford to proceed without Atari's support. At least some results from
our research were used in IS2.    "

 

 

If we are going to once again, go over the topic of how Atari treated it's 'best' development teams, we need a broader canvas than simply Atari ignored HVS. 

 

Tramiel Atari ignored pretty much all and sundary at one time or another and the Jaguar library suffered as a result. 

By the time those projects were started Atari already pulled the plug on the Jaguar. So probably that is the reason. 

But even Atari was clever enough to recognize the competence of Eclipse and respected them. 

[agradeneu]

1 hour ago, JagChris said:

No it's a raycast demo HVS whipped up and sent to Atari showing them what they accomplished with the aforementioned GPU compiler. If you read the read me right beneath it you'll see they're trying to show Atari it's straight C code without optimization etc.

 

Atari ignored them.

If I was Atari I would have been not much impressed with that demo.  

[JagChris]

9 hours ago, Lostdragon said:

If we are going to once again, go over the topic of how Atari treated it's 'best' development teams, we need a broader canvas than simply Atari ignored HVS. 

Aw come on LD it was nothing like that. It was about a risc compiler for the Jag.

 

You can expound upon that one sentence if you like. It would fit in a topic of what would have saved the Jag.

 

Though something interesting in the documents you and Stilphen released about Dactyl Joust.  Rehbock and someone else at Atari are corresponding back and forth using the latest milestone documents HVS sent Atari for that game as a backdrop. it lists their development setup as a deliverable for June 95. In the conversation it's totally ignored by the two Atari managers.

[42bs]

10 hours ago, agradeneu said:

By the time those projects were started Atari already pulled the plug on the Jaguar. So probably that is the reason. 

But even Atari was clever enough to recognize the competence of Eclipse and respected them. 

I think also this is a main reason. We (Phobyx, Lars and me) had a meeting with Norman Kowalewski in my student apartment and showed some of our stuff and he was impressed but no more reactions. Just silence. Soon we heard he left Atari.

 

Anyway, I will disect Ruiner to see if there is really GPU manager.

[+cubanismo]

I think everyone gets too upset over this part of this pointless debate (And it is pointless unless you're studying business or something. Atari and Jaguar failed. It's still fun and harmless IMHO to play "what if?" and armchair it 20+ years later, even with all the retreading, but then I'm relatively new here).

 

There's quite some evidence HVS had built up a bunch of good development tools and were pretty good at coding for the Jaguar. They probably weren't as awesome or generally applicable as some proud developers claimed, but they were probably pretty cool.

 

Would it have saved the Jaguar if HVS made that June 95 deliverable of some Jaguar SDK 2.0? No, it had already failed by the time they had this stuff put together. While it's still an interesting detail from a historical POV (thanks for pointing it out @JagChris), Atari would have had to have had tools like this available ~1yr before the Jaguar launched for it to have seriously affected the Jaguar's market performance at all. Even then...

 

Would any one thing have saved the Jaguar? Objectively, no. It would have had to be something insane like Sega completely failing to bring the Saturn to market for some reason and buying out the rights to the Jaguar as their 5th-gen offering at the last minute (Things nearly as crazy as this have happened in this industry behind the scenes, so it's not impossible, but... unlikely). If you try to boil it down to tools leading to a derth of good  games, recall Atari did manage to put out two games nearly everyone agrees were genuine killer apps: Tempest 2000 and AvP. Maybe they're not your personal favorites, but if you had the right machinery behind these titles, they should have been able to propel the console to success. Would more have been better? Sure, but how many people bought Nintendos just to play Mario Bros. and Duck hunt? Enough to make the console a success I'm sure. So many things, most all of which are covered ad nauseam in this thread and elsewhere in the forum, were stacked against the Jaguar that a killer game, killer tools, killer marketing, or a massive change of heart (Too soon?) on management's part wouldn't have righted the ship on their own. It was unfortunately doomed from the start. Atari took the meager remains of their winnings from that big jackpot hit in the 70's/80s and bet it all on lucky number 7, but there were 36 (37 in shitty US casinos) other slots for the roulette ball to land on.

[JagChris]

Just to clear my position up I brought up the HVS GCC compiler setup because someone wondered whether a compiler for the GPU was possible at all due to hardware bugs. 

 

I agree with Cubanismo it would have taken a combination of several different things much earlier, GPU compiler included to help Atari. 

Edited August 29, 2022 by JagChris

[JagChris]

An interesting sidenote on GPU compilers. Most people know that Carmack also retargetted one for the GPU about a year earlier. When I asked him if he ran into a comparison error problem he says he doesn't remember doing so. He remembered a read after write bug or somesuch. But nothing related to a comparison bug. 

 

It's interesting he didn't run into this problem.

Edited August 29, 2022 by JagChris

[alucardX]

On 8/24/2022 at 2:49 PM, zzip said:

Yeah increasing bit size doesn't give as many benefits as people think.   It usually gives access to more memory..   much more than Jag could ever hope to have in the 90s.   As for performance..  if you use 64-bit integers you will have a benefit,  but those are big numbers, 32-bit  is enough in most cases.   I've seen cases where going to 64-bit actually caused a slight performance hit.  

I think I read some place that the N64 was often programmed with 32-bit instructions because there was no benefit to using 64-bit instructions in many cases. I should find the reference where I read that.

[42bs]

2 minutes ago, JagChris said:

comparison error problem

If this error exists assembly programmer must have his this bug as well. I have read a lot of GPU code but nowhere found the faintest hint about such bug.

But maybe it is the same problem I run into with restoring the flags on interrupt return.

[JagChris]

Just now, 42bs said:

If this error exists assembly programmer must have his this bug as well. I have read a lot of GPU code but nowhere found the faintest hint about such bug.

But maybe it is the same problem I run into with restoring the flags on interrupt return.

I touched on this in the first post I linked to before for you.

 

Mike Fulton says it affects assembly programmers except in a different way. 

[42bs]

1 minute ago, alucardX said:

I think I read some place that the N64 was often programmed with 32-bit instructions because there was no benefit to using 64-bit instructions in many cases. I should find the reference where I read that.

64bit is by far not the holy grail. A reason why for example Linux did use 32 bit pointers even in x64. 

[+cubanismo]

2 minutes ago, JagChris said:

He remembered a read after write bug or somesuch. But nothing related to a comparison bug. 

I'm going to indulge myself and speculate a little:

 

It's likely this is just a simple bug in the Jaguar GCC implementation, not something inherent in the JRISC instruction set. I've written plenty of JRISC loops by hand that aren't off by one iteration. Off-by-one errors are pretty common. Some day I'll stop being lazy and run that JRISC GCC build in Dosbox to see how easily and in what way it manifests in practice to see if there's any trivial post-processing you could do to fix it.

 

IIRC, @CyranoJ made some claim the Doom JRISC code looks like someone naively converted m68k assembly to JRISC syntax. Still pure speculation, but I'm guessing John just wrote some tool that accomplished roughly this, so he could compile the Doom core routines to m68k using the regular compiler, then run a rather simplistic tool on it to convert that to JRISC, possibly with  some hand-editing and  tweaking before or after. For a targeted use case like this, this would be a vastly simpler project than implementing a full JRISC compiler backend. To someone at a game producer or marketing level, it all looks the same though: John did magic that compiled C code to JRISC.

[42bs]

1 minute ago, JagChris said:

Mike Fulton says it affects assembly programmers except in a different way

A hardware bug is a bug no matter if you write C or Assembly. But writing a C compiler back end which knows and respects all the traps in the RISC design esp. The scoreboard bugs might be what HVS meant.

[JagChris]

Yeah perhaps but I'm just going on the information given. 

 

Whether it was a hardware or software bug HVS made quick work of it. So it's not an insurmountable problem.

 

Perhaps some tests would clear up what kind of code it's spitting out. I think it's actually simple for-next loops that can trigger it. 

 

But perhaps any more discussion in this direction should go in the programmers section.

[JagChris]

@cubanismo Here's what he said about it last year on twitter

 

no need to speculate you can ask the man himself if you have Twitter.

 

 

Edited August 29, 2022 by JagChris

[42bs]

18 minutes ago, JagChris said:

@cubanismo Here's what he said about it last year on twitter

 

no need to speculate you can ask the man himself if you have Twitter.

 

 

🙂 thinking of a C compiler make people think of GNU C, but there are other esp. LCC which might be much easier to  modify for a new target architecture.

 

[JagChris]

2 hours ago, 42bs said:

Anyway, I will disect Ruiner to see if there is really GPU manager.

 

Might be easier to attempt that with the maze demo.

[JagChris]

5 hours ago, 42bs said:

Anyway, I will disect Ruiner to see if there is really GPU manager.

 

Maybe consider disassembling( I am assuming this is what you meant by dissection) the GPU gcc so it can be reassembled on something more modern.

[42bs]

6 hours ago, JagChris said:

 

Might be easier to attempt that with the maze demo.

So far, I could not get the maze demo run. If I get it running it is the easier part, yes.

[42bs]

4 hours ago, JagChris said:

 

Maybe consider disassembling( I am assuming this is what you meant by dissection) the GPU gcc so it can be reassembled on something more modern.

Even with ghidra is this a monument job. Also, did HVS speak about a tool to post-process the assembly generated by the GCC. And this tool is what is interesting.

But actually I am more interested in this mysterious bug.

[+cubanismo]

9 hours ago, JagChris said:

no need to speculate you can ask the man himself if you have Twitter.

This forum and a few low-traffic Discords are the closest things I have to social media.

 

Based on that comment though, it does sound like I was off base. That's what I get for speculating. In my defense, I was working with incomplete information since I avoid a substantial portion of the modern internet like the plague.

[+cubanismo]

51 minutes ago, 42bs said:

So far, I could not get the maze demo run. If I get it running it is the easier part, yes.

Have you tried 60Hz/NTSC? I didn't have any problem running that ROM. I think I've had it up on both GameDrive and Skunk, but I can't recall for sure which of the two or if both were used.

 

I'd love to take a look at that GPU manager code just for kicks, but keep in mind it isn't really usable without the corresponding tools to generate code that runs on it. That's what's kept me from putting any time into digging it out.

[JagChris]

2 hours ago, 42bs said:

Even with ghidra is this a monument job. Also, did HVS speak about a tool to post-process the assembly generated by the GCC. And this tool is what is interesting.

But actually I am more interested in this mysterious bug.

Yes. If you follow that link I mentioned the story of the GPU manager Corley talks about the stay resident program and the post processing tool in depth.

 

Here:

http://www.3do.cdinteractive.co.uk/viewtopic.php?f=35&t=3492//

Edited August 30, 2022 by JagChris