What could have saved the Jag?

[JagChris]

2 hours ago, 42bs said:

But actually I am more interested in this mysterious bug.

Here's a pdf of Leonard and Mike Fulton discussing it.

 

https://www.mediafire.com/file/bqa0dg210sawv9m/Atari_Corp._was_the_Moon_Moon_of_games_companies....zip/file

[42bs]

Ok, no mysterious bug in the GPU, only a lack of not being able to have the common compare operation because flags are ANDed.

But this is well described in the docs.

The other "bug" is simply a bug in the GCC code generator. (At least that's what JagMod remembers).

 

Anyway Mike did make a point, other here did before: It was the early 90's. 

For example an ASIC took at minimum 6 months from first mask to final housed chip. 

[JagChris]

2 hours ago, 42bs said:

Ok, no mysterious bug in the GPU, only a lack of not being able to have the common compare operation because flags are ANDed.

But this is well described in the docs.

The other "bug" is simply a bug in the GCC code generator. (At least that's what JagMod remembers).

 

Anyway Mike did make a point, other here did before: It was the early 90's. 

For example an ASIC took at minimum 6 months from first mask to final housed chip. 

There is no other bug. What those are one and the same bug from two different perspectives....Brainstorm saw it as a hardware bug that they couldn't get around (Maybe a traditional way of doing this sort of thing with a compiler that they felt inflexible about) and people like High Voltage Software and Jagmod saw it as a 'well why didn't you just do this way' software bug 

 

 

Mike may have gotten the ASIC thing right But a few other things are in error.

 

Quote

I would have loved to share the tricks they used, but HV didn't share the details with us at the time so that was never an option

 

Not true HV and many other talented developers tried to communicate with atari about this issue and many other different things and got ignored.
 

Quote

I disagree. The RISC compiler was not ready for distribution. It was not even minimally functional by any reasonable standard. If we had sent it out, today you'd be asking us why Atari was sending out broken development tools.

Seriously, can you imagine 'Hey developers, here's a new compiler for the RISC processors but you cannot use it for code lesson 2K and doesn't compare values against each other.'

Then goes on to talk about a time wasting distraction it would have been for developers. Looking back on this this is just damage spin control. I mean they released games that people have bought with their harder earned money in this condition.

 

All tools are released in an unfinished state I think. You can follow the dev history of madMac/aln for the jag with bug reports and fixes coming in from developers out in the wild. 

They screwed up. Plain and simple.

Edited September 1, 2022 by JagChris

[42bs]

6 hours ago, JagChris said:

Then goes on to talk about a time wasting distraction it would have been for developers.

I do not know your mileage, but I am writing software for nearly 40 yrs now. Doing it for leaving for over 20yrs. And I can assure you, a buggy compiler - means one that generates buggy code - is the worst thing ever. No one wants this. A buggy assembler is easy to handle as it is 1:1 from mnemonic to machine code.

 

And regarding developers sharing info: A big lough on this. Even today demo/intro coders do mostly hide their tricks. And in the 80's and 90's they never did.

Just check out demozoo or pouet how many demos come with source code.

[laymanpigeon]

http://personal.ee.surrey.ac.uk/Personal/R.Webb/l3a15/extras/sdramart.html

 

https://www.teldat.com/blog/dynamic-random-access-memory-dram-fast-page-mode-fpm/

 

If Atari could have had survived delay of Jaguar for a year, SDRAM would be viable.

It would have effectively provided equivalent performance of 128bit FPM DRAM.

As Carmack stated another 64bits would have tripled texturing performance.

 

Doom then could have ran at solid 320x240 resolution with better framerate.

Skyhammer in worst case scenario would not have went below 15FPS.

Fight For Life could have had fully textured characters at solid 30FPS.

 

Perhaps to achieve such it may require duplication of texture data in SDRAM.

Performance would be even greater if SDRAM matched RISC clock for clock.

Even more so if another 64bit of SDRAM was there thus each can have own.

 

Anyway this is for JagChris... Downix is alive and well. lmao

 

I chat in DMs with him on Twitter.

[42bs]

35 minutes ago, laymanpigeon said:

 

If Atari could have had survived delay of Jaguar for a year, SDRAM would be viable.

 

https://youtu.be/p3j2NYZ8FKs?t=89

 

 

[laymanpigeon]

32 minutes ago, 42bs said:

https://youtu.be/p3j2NYZ8FKs?t=89

 

 

https://www.youtube.com/watch?v=t1TcDHrkQYg

 

[JagChris]

2 hours ago, laymanpigeon said:

Anyway this is for JagChris... Downix is alive and well. lmao

 

I chat in DMs with him on Twitter.

It's been a minute. Wish him well for me. Tell him the community now has that Jag ram cart he's been looking for. A whole 16MB ☺️

Edited September 2, 2022 by JagChris

[agradeneu]

3 hours ago, laymanpigeon said:

http://personal.ee.surrey.ac.uk/Personal/R.Webb/l3a15/extras/sdramart.html

 

https://www.teldat.com/blog/dynamic-random-access-memory-dram-fast-page-mode-fpm/

 

If Atari could have had survived delay of Jaguar for a year, SDRAM would be viable.

It would have effectively provided equivalent performance of 128bit FPM DRAM.

As Carmack stated another 64bits would have tripled texturing performance.

 

Doom then could have ran at solid 320x240 resolution with better framerate.

Skyhammer in worst case scenario would not have went below 15FPS.

Fight For Life could have had fully textured characters at solid 30FPS.

 

Perhaps to achieve such it may require duplication of texture data in SDRAM.

Performance would be even greater if SDRAM matched RISC clock for clock.

Even more so if another 64bit of SDRAM was there thus each can have own.

 

Anyway this is for JagChris... Downix is alive and well. lmao

 

I chat in DMs with him on Twitter.

Dude what are you smoking? 🤪

[laymanpigeon]

2 hours ago, JagChris said:

It's been a minute. Wish him well for me. Tell him the community now has that Jag ram cart he's been looking for. A whole 16MB ☺️

Will do.

1 hour ago, agradeneu said:

Dude what are you smoking? 🤪

Lower latency and more bandwidth of RAM would have improved performance.

Texture misses are a stall, lower latency could alleviate such an issue.

Since Carmack complained about inability for Tom of caching textures.

[+cubanismo]

On 9/1/2022 at 1:16 PM, 42bs said:

Ok, no mysterious bug in the GPU, only a lack of not being able to have the common compare operation because flags are ANDed.

Where did you draw this from? My reading of it is that it's unclear if he's referring to some operations not setting the ALU flags, or unreliably setting the ALU flags, or as you say, not having powerful enough condition codes to represent comparisons like LTE in one jump operation, though in all cases other than the unreliably setting flags one, yes, you can somewhat trivially work around it by using more instructions.

[JagChris]

21 hours ago, 42bs said:

I do not know your mileage, but I am writing software for nearly 40 yrs now. Doing it for leaving for over 20yrs. And I can assure you, a buggy compiler - means one that generates buggy code - is the worst thing ever. No one wants this. A buggy assembler is easy to handle as it is 1:1 from mnemonic to machine code.

Subject of the last couple of pages has literally been a recounting of talented developers who wanted to share with Atari the tricks they learned on the Jaguar. Among those stories is THE ONE AND ONLY TEAM that did get ahold of a bad compiler, said hey we want this, then fixed it and used it successfully. A 100% success rate right there.. Then tried multiple times to share it with Atari. This was in the 90s.

 

Quote

And regarding developers sharing info: A big lough on this. Even today demo/intro coders do mostly hide their tricks. And in the 80's and 90's they never did.

 

Just check out demozoo or pouet how many demos come with source code.

 

Looking at the small 3do scene we've got one lone guy. He only works on DOOM. Shares everything.

 You can look at the larger 32X scene and see similar stuff. Even one of the 32X Doom devs @Chilly Willy beyond sharing his work on that project shared the Jag AvP code. Thank him for that gift to the community. He doesn't even work on the Jag yet still shares what he's got. 

As far as our own homebrew scene, we were lucky enough that big people back in the 90s did indeed share when it mattered.. We had some guy whose name escapes me created the BJL uploader. This was huge. He's literally the Godfather of the Jag homebrew scene and considered Royalty in the community. Without him we'd have had nothing.

Today we have guys like Cubanismo who share significantly and generously. So significantly that their work may completely reshape the homebrew community in time. And if that BJL guy was here today, bless his heart wherever he is he'd probably still be sharing his work and code up in the programming section.

 I'm sorry about your bad experiences with the Pouet developers. But there are people who do share. These guys aren't laughable at all. They are lights in the dark.

Atari didn't have the foresight to bet on people like this and it cost them dearly.

Relating to the original topic, the first thing Atari needed to do to help them succeed was to get rid of narrow outlooks and limiting beliefs.

Edited September 3, 2022 by JagChris

[Zerosquare]

26 minutes ago, JagChris said:

We had some guy whose name escapes me created the BJL uploader. This was huge. He's literally the Godfather of the Jag homebrew scene and considered Royalty in the community. Without him we'd have had nothing.

 

(...)

And if that BJL guy was here today, bless his heart wherever he is he'd probably still be sharing his work and code up in the programming section.

You should ask @42bs about that. I think he knows the guy.

Edited September 3, 2022 by Zerosquare

[+Stephen]

15 minutes ago, Zerosquare said:

You should ask @42bs about that. I think he knows the guy.

You can't make this shit up if you tried!

[JagChris]

53 minutes ago, Stephen said:

You can't make this shit up if you tried!

I only see Zero when somebody quotes him these days. Beyond that you guys might be a little slow on the uptake.

 

As it is it doesn't look like I'm through with my ignore list.

[Zerosquare]

15 minutes ago, JagChris said:

As it is it doesn't look like I'm through with my ignore list.

You should put the entire forum on ignore. That'd save you time.

[+cubanismo]

39 minutes ago, JagChris said:

Beyond that you guys might be a little slow on the uptake.

Give them a break. Sarcasm on the internet is hard, and I don't think Mike Fulton was spinning. Atari's reasoning makes sense, regardless of whether it ended up being the right choice. I do appreciate the shout-out though.

 

Now, let's kick the tires on that infamous compiler, shall we? Turns out I already had dosbox installed. If you sync my SDK and mount it as your C drive in dosbox, this command to set up your path will get you access to the Atari/Brainstorm 68k/GPU/DSP compiler suite in its rawest form (No include files, no libraries for basic built-in math routines, startup files, etc.):

 

c:\> set PATH=%PATH%;c:\jaguar\bin\dos;c:\jaguar\bin\dos\agpu\2.6;c:\jaguar\bin\dos\m68k\2.6

 

Then you can compile C code to MADMAC (or RMAC) assembly like this:

 

c:\> gcc -mGPU -S -o gcctest.s gcctest.c

 

More details in my SDK in the file jaguar/docs/docs/gcc.txt.

 

Now I tried compiling this file:

 

void func(void)
{
    volatile long x = 1;
    volatile long y = 2;
    volatile long z = 3;

    if (x <= y) x = y;

    if (y >= z) y = z;

    if (z > x) z = x;

    if (y < x) y = x;
}

 

I've attached the output as jagtest-O0.s (unoptimized) and jagtest-O2.s (optimized, with -fomit-frame-pointer as well). The 'volatile' keywords are necessary when you move to optimized output as Atari/Brainstorm recommend. Otherwise this function compiles down to a no-op.

 

My observations:

 

The unoptimized code is pretty atrocious, but then what do you expect? It's unoptimized.

 

The optimized code isn't bad at all, but then again, this logic is trivial.

 

The compiler seems to correctly flip around the comparisons to account for the Jaguar's limited condition code capabilities. I'm not clear where the bug is. Anyone know what I should throw at it to trigger these infamous bugs?

jagtest-O0.s jagtest-O2.s

[+CyranoJ]

17 minutes ago, cubanismo said:

Anyone know what I should throw at it to trigger these infamous bugs?

Jagchris. Throw Jagchris at it.

 

BTW, you just accomplished more in an hour than Jagchris has since he decided to start posting on Jaguar forums decades ago. So consider that when replying to him.

 

Also, Jagchris just calling someone slow on the uptake just blew out my ironymeter.

[JagChris]

Gorf used an older version of the compiler. It's actually possible that HV shared what they found about the bug with Brainstorm and the latest version may incorporate the work around. 

[+CyranoJ]

2 minutes ago, JagChris said:

Gorf used an older version of the compiler. It's actually possible that HV shared what they found about the bug with Brainstorm and the latest version may incorporate the work around. 

 

Did he find it under a bottle of his own poo kept in the basement?

[42bs]

2 hours ago, JagChris said:

We had some guy whose name escapes me created the BJL uploader. This was huge. He's literally the Godfather of the Jag homebrew scene and considered Royalty in the community. Without him we'd have had nothing.

Hmm, is this meant ironic or is it m not being native English?

Anyway, before BJL was JagServer: https://www.jagware.org/jag_uploads/dev/roine_steinberg_jaguar_server/jserver.html

But it was limited to Atari ST with ROM port.

[JagChris]

4 minutes ago, 42bs said:

Hmm, is this meant ironic or is it m not being native English?

Anyway, before BJL was JagServer: https://www.jagware.org/jag_uploads/dev/roine_steinberg_jaguar_server/jserver.html

But it was limited to Atari ST with ROM port.

Because you're not a native English speaker I will actually tell you that it is affectionate irony. 

[42bs]

7 hours ago, cubanismo said:

Where did you draw this from? My reading of it is that it's unclear if he's referring to some operations not setting the ALU flags, or unreliably setting the ALU flags, or as you say, not having powerful enough condition codes to represent comparisons like LTE in one jump operation, though in all cases other than the unreliably setting flags one, yes, you can somewhat trivially work around it by using more instructions.

Hmm, yes I might have "over interpreted" what he was saying.

 

[+CyranoJ]

4 minutes ago, JagChris said:

Because you're not a native English speaker I will actually tell you that it is affectionate irony. 

 

That is superbly ironic, given you aren't a native English speaker being American.

[42bs]

37 minutes ago, cubanismo said:

The optimized code isn't bad at all,

I'd say it is horrible. Let alone the handling of the local variables.