Stupid Noob Question Regarding the Jaguar Motorola 68000

[Lost Dragon]

Genesis Road Rash slightly faster than the later Amiga conversion.

 

Solid game engine.. Just 1 E.A milked a tad on Genesis..

[VladR]

 

Genesis version of this supposed to be 90% complete, i had always hoped

for a Jaguar version myself..

Given the following facts of Zeewolf:

- only about half of screen is covered with 3d polygons, hence fillrate needs are much lower than full-screen games

- axis-aligned world, with basically just strafing camera : means simple interpolation for vertices (e.g. super fast)

- limited colors (looks like 4-bit coloring on terrain to me - e.g. just 16 colors, objects can have different colors) - thus a single 32-bit write stores 8 pixels

- simple sounds that can easily be played off 68000, no need to abuse DSP for this

 

It should run at 60 fps, in default res, just off GPU, without Blitter (not much use to to fire blitter for just few pixels).

If we employed DSP, and wrote a multithreaded renderer, jag should be able to pull this off at 30-60 fps even at 640x240

 

Actually, in higher resolutions, it'd probably make sense to fire blitter for each scanline of each triangle (while GPU is computing left and right xp for the next scanline of the triangle), and paradoxically, we might get same framerate, as from lower resolutions (where only GPU would be doing the rendering), because it'd take same amount of time for GPU to write few 32-bit words in lower res, as it'd take in higher res firing Blitter (would be an interesting technology experiment to know where that threshold actually is!).

 

I would bet this can run on jag at 720x200 in a playable framerate (~20 fps), given multithreaded rendering+Blitter.

[Flojomojo]

Since they sold 30Mil of 'em, they should be pretty cheap to pick up today, no ?

 

 

Yes, the Genesis/MegaDrive is as common as can be. Since you've gone this long without one you might as well wait for the new AtGames version, which will have HDMI, nice wireless controllers, and a mess of games built-in, as well as a cartridge slot for old games, too. It should be out in a few months.

[sd32]

 

 

Yes, the Genesis/MegaDrive is as common as can be. Since you've gone this long without one you might as well wait for the new AtGames version, which will have HDMI, nice wireless controllers, and a mess of games built-in, as well as a cartridge slot for old games, too. It should be out in a few months.

Or do what real men do, and get an original model 1 version . Maybe get the latest Mega Everdrive flashcart for homebrewing.

[Flojomojo]

Or a Pi, that comes with everything. "Real men" don't play ancient video games.

[VladR]

Or do what real men do, and get an original model 1 version . Maybe get the latest Mega Everdrive flashcart for homebrewing.

If I played with homebrewing on Sega, I'd rather try to tackle the 8-processor beast - Saturn - now that's a mighty challenge

 

But, there's still couple years worth of experimenting with Jag - I'm only now getting to a place where I can texture fast enough, and I haven't maximized the flatshading throughput either - since what I learnt now with texturing the road, a lot could be done on my flatshader to improve its performance.

 

And I gotta do multithreaded rendering with DSP, and I still don't have full interlaced resolution working (1382x576). And it's still not in a playable / interactive state - (but that's because I don't want to lock myself to current performance/feature set, I'm waiting till I'm as far as possible).

 

But, once all these things are done, the software rasterizer should be relatively straightforward to port to any other RISC chips. After all, the algorithms are the same (triangles, scanlines, framebuffer, duh!), and since all I'm doing on jag, in terms of instructions, is load/store/jump/compare/math, the same instructions (just different syntax) are going to be on any other RISC platform, so porting my jag engine to saturn should be relatively straightforward. But that's, like, 5+ yrs down the road...

 

I am , however, very curious, what kind of 3D scenes could Sega Saturn accomplish, if I had a multithreaded engine running on both SH-2 PLUS FH1 (third DSP@22.6 MHz), and they would be helping VDP1 (which, by HW design, can handle textured polygons in itself, allegedly).

That's like, roughly 2.5x-3x the power I am extracting from jag right now (since I am using just one RISC chip : the GPU) PLUS Saturn's VDP1. Sonofagun...

 

That's some brutal horsepower, right there - but there's no way, any commercial team, had ever a time, to build a multithreaded hybrid renderer, that works across 4 RISC chips and merges both SW rasterizing, and whatever VDP1 does with 3d polygons.

 

You don't get a R&D fun like that on PC. There - it's just - blah - buy a new nVidia card with 500 more cores. Oh, wait, just wait 3 more months, and... Oh, wait...

[phoenixdownita]

If I played with homebrewing on Sega, I'd rather try to tackle the 8-processor beast - Saturn - now that's a mighty challenge

 

....

But, once all these things are done, the software rasterizer should be relatively straightforward to port to any other RISC chips. After all, the algorithms are the same (triangles, scanlines, framebuffer, duh!), and since all I'm doing on jag, in terms of instructions, is load/store/jump/compare/math, the same instructions (just different syntax) are going to be on any other RISC platform, so porting my jag engine to saturn should be relatively straightforward. But that's, like, 5+ yrs down the road...

 

....

Ahem, Saturn used quads https://segaretro.org/VDP1_(Saturn)and that made it all the more complex as decent tools for quads based geometry were lacking and/or very primitive compared to triangles. But I guess you meant brute force via the SH2s maybe?

[leech]

Sega Genesis (the Megadrive) in Japan launched in late 1988, so its almost 5 years older tech than the Jag. In late 1994 Sega launched the Sega 32X add on for the Genesis, in response to the Jaguar and 3DO systems.

 

I love Genesis Road Rash. Yeah, its a bit choppy, but its doing sprite scaling in software unlike most 2d racer from the 16 bit era, and the road has hills.

 

Aladdin on Genesis was the original. The Amiga run only on AGA i think.

Could have sworn it came out for the Amiga first, but then I also could have sworn it had an ECS release, but according to http://hol.abime.net/3225it did not. Though it also says there it was developed by Jaguar, too bad it was never released for it... could have been really pretty.

[VladR]

Ahem, Saturn used quads https://segaretro.org/VDP1_(Saturn)and that made it all the more complex as decent tools for quads based geometry were lacking and/or very primitive compared to triangles.

 

According to the official Saturn docs, section 7.7, page 127:

When two vertices are set at the same coordinates, a polygon is drawn as a triangle.

 

But, I never really understood what the fuss was about. In my gamedev studio, we have always created all meshes from quads, even though no PC gfx cards ever processed anything else than triangles. Why ? Because it's much more natural, easier and faster to work with quads. Converting to triangles was always done as a very last step.

I never even had to ask any 3d artist. It was just "duh, of course".

I still, to this day, whenever I fire up 3dsmax, work only with quads. When you create low-poly buildings, you actually don't want triangles, as a matter of fact, as they screw up normals very often (3dsmax was quite buggy back then). With quads, you had 100% of the time, uniform normals and did not have to worry that the export would screw things up.

 

I still, to this day, recall, when we read that "complaint" on quads, in some game magazine, looked at each other in office, and were like "WTF are they smoking :)". It was a running joke for about 3 months

 

 

But I guess you meant brute force via the SH2s maybe?

I may have been very brief. Here's what I mean:

Chip1 :VDP1: renders, say, 1,000 triangles (via HW)

Chip2 :SH-2:A : 28.6 MHz: renders, say, 250 triangles (via my software rasterizer)

Chip3 :SH-2:B : 28.6 MHz: renders, say, 250 triangles (via my software rasterizer)

Chip4 :FH1: 22.6 MHz: renders, say, 200 triangles (via my software rasterizer)

 

The numbers are just an example, I never tested the HW. But you have 3 RISC chips totalling 79.8 MHz that can additionally, process more polygons, on top of VDP1. Just look into my older "Wipeout" experiments. That was ONE chip (GPU), accessing framebuffer, pixel by pixel (no Blitter, just direct access to Framebuffer). Now triple it AND add whatever amount of polys can VDP1 process by default, in HW.

 

Granted, such a hybrid engine that would be properly sync'ed across 4 chips would be a bitch to code, but hey

 

If you did just a flatshader on Saturn across all those chips, the polycount would be absolutely insane for the time.

And that's for 60 fps.

At 30 fps, it's ~2x

At 20 fps, it's ~4x

At 15 fps, it's ~8x (e.g. 8x whatever amount of polys those 79.8 MHz of chips generated on top of VDP1)

 

 

Maybe, I should go back temporarily to my flatshader (the Wipeout codepath) and see what kind of scene complexity is possible to extract of one chip, when you go down to 15 fps and have 4 vblanks. So many things to experiment with, so little time...

[Lost Dragon]

Heya VladR:I meant to say A500 Zeewolf takes a massive frame rate hit when things got busy, your chopper had response times of a brick..far more playable on an A1200.

[Flojomojo]

Erm, all we have to do is add up MHz of many different chips now? In what universe does that make any sense? Must be from the days when we were told to "DO THE MATH."

[phoenixdownita]

Erm, all we have to do is add up MHz of many different chips now? In what universe does that make any sense? Must be from the days when we were told to "DO THE MATH."

Shhhhhhhh!!!!

 

He forgot to add 13Mhz of a 68K to the mix (but it is no RISC).

[Stage_1_Boss]

I don't know what's happening, can I go play Phantasy Star II?

[VladR]

Heya VladR:I meant to say A500 Zeewolf takes a massive frame rate hit when things got busy, your chopper had response times of a brick..far more playable on an A1200.

Yeah, I noticed that framedrop too [across multiple platforms]. That usually happens due to 2 reasons:

1. Engine is not optimized

2. Engine IS optimized and 80-100% of all available power goes to rendering, thus, when more stuff needs to happen on screen (enemies,explosions,AI), the rendering component isn't getting as much CPU time, which is obviously instantly visible.

 

Given the fact that this engine ran on 8 MHz Acorn Archimedes, I think we can all safely agree, that option 1 can be ruled out

 

Erm, all we have to do is add up MHz of many different chips now? In what universe does that make any sense? Must be from the days when we were told to "DO THE MATH."

Of course, because we're talking RISC chips here (e.g. DSp, GPU), not CISC (e.g. 68000). While on CISC (68000), each assembler instruction execution time wildly varies, on RISC, each instruction takes fixed amount of time, save for complex ones (like DIV, or indexed memory access). This is going to get slightly mathematical, but bear with me, I will break it down as simple as possible.

- On Jaguar, the GPU/DSP clock is 26.59 MHz

- in 1 second, you get 26.59 Million ticks

- in 1 frame (NTSC, 1/60 s), you get 26.59M / 60 = 443,166 ticks

- on Jaguar, outside DIV/indexed storage instructions, almost all other instructions take 3 ticks

- 443,166 / 3 = 147,722 instructions per NTSC frame

- with a little bit of rearranging the code, it's relatively easy to get this average to 2.5 (especially for inner loops), thus you can execute 443,166/2.5 = 177,266 instructions per NTSC frame

 

As long as you are NOT accessing main RAM, the GPU execution pipeline is not halted, hence you can get between 147,000 and 177,000 instructions per single frame. On PAL, that number is ~20% higher

Now you do loose a bit of performance as you have to load data from RAM, process them on GPU, and store back somewhere to RAM. But the important thing is you do not access RAM in tight inner loops, hence you can get very close to that 177k ops/frame.

 

Since on Jag, we have DSP, that is of same clock, you can now double the max instruction throughput per frame, as you get 177k from GPU and 177k from DSP. Of course, due to half bandwidth to RAM from DSP, a heavy usage of RAM on DSP would drastically reduce this number. So, you really don't want to load/store too much RAM data on DSP. Hence, you must design the engine components in a way that can use this to your advantage (harder than it looks)

 

If we had 4 RISC chips, you could indeed do 4x177k = 708k ops/frame. I can't speak for memory architecture of Saturn, I didn't spend that much time with their dev docs. But as far as maximum theoretical throughput goes, that's how it works.

 

 

This is the universe, where adding MHz DOES make sense.

 

 

Shhhhhhhh!!!!

 

He forgot to add 13Mhz of a 68K to the mix (but it is no RISC).

Exactly. No RISC, hence didn't forget. I'd delegate 68k to do something menial, like input, scripts and gameplay (depends on game genre, of course), so that RISC chips can do the work they were designed for.

[phoenixdownita]

Aside from "adding the Mhz because throughput is all that matters ..... in this Universe we can add Mhz" statement ..... I think we can all agree that the Sega Saturn can render more polygons (quads or otherwise) than the Jag .... that I think we can agree.

 

For the rest what the RISC were designed for or not is another matter (some were general purpose, some were specialized), there was a time when CISC/RISC mattered on some ground, I recall everyone moving to it like the Motorola 88K, Intel i860 (none of them made it very far) all trying to catch the wind of the SPARC, MIPS etc... of the time. Heck the ARM CPU is RISC and that's everywhere now (aside from datacenter servers, they are trying of course) even though to be fair their v8 ISA 64bit is meddling the waters a little (I kind of liked the predicated model of the ARM 32bit ISA but it did make reading the code a little "unnatural" at first).

So told a modern x86/x64 is hiding RISC cores behind a CISC ISA, and if they would just expose 2 or 3 times the number of registers I doubt we would be really caring about the distinction.

 

We also all agree that GFX, especially 3D, is an embarrassingly parallel workload, so the more "simple" cores you can throw at it the better like all modern GPUs do with thousands of relatively "simple" but dedicated cores (call them CUDA, Stream Processors or whatever you would like) ... great, still they do not advertise their gear via "add the Mhz" so I suspect that:

 

[Flojomojo]

Thank you.

 

Also, this

https://superuser.com/questions/167131/how-do-i-calculate-clock-speed-in-multi-core-processors

[VladR]

Thank you.

 

Also, this

https://superuser.com/questions/167131/how-do-i-calculate-clock-speed-in-multi-core-processors

Wow, that was, uhm, ..deep...

 

I'll remember next time not to waste my breath on trying to explaining anything to you.

 

A valuable experience.

[Zerosquare]

I'll remember next time not to waste my breath on trying to explaining anything to you.

Yeah, please don't waste your time. And ours.

[Flojomojo]

Wow, that was, uhm, ..deep...

 

I'll remember next time not to waste my breath on trying to explaining anything to you.

 

A valuable experience.

Clearly, I'm an idiot and you're a genius. I bow to the most amazing Jaguar programmer of this 21st century. Use your great powers for good.

[VladR]

Yeah, please don't waste your time. And ours.

Someone holding a gun to your head, forcing you to read my posts ? Just hit the ignore button and your problem is solved. Contrary to popular misconception, I won't loose my sleep over it

 

Clearly, I'm an idiot and you're a genius. I bow to the most amazing Jaguar programmer of this 21st century. Use your great powers for good.

That the best sarcasm you can produce ?

You know, in a civilized society, when someone goes out of their way, to explain something to someone, that someone is usually expected to do something with the information. Anything.

But this concept clearly escapes you, and as you're already reverting to name calling, it's clearly best for all involved parties, to halt the discussion right there.

 

No worries, no harm done. Business as usual. Carry On

[Flojomojo]

You know, in a civilized society, when someone goes out of their way, to explain something to someone, that someone is usually expected to do something with the information. Anything.

 

[+Sauron]

Please stop.