is the b-bus only 16bits?

[Coolgame]

the sh2 system bus runs at 32bits while the b bus runs at 16bits(multiplexed). wouldn't that be a problem in

transmitting 32bit data from sh2 to either vdp 1 or 2? what would happen if you try?

is there any way to over come this?

I hope i'm looking at it wrong.

 

[antime]

32-bit accesses are transparently split up into two 16-bit accesses. This is something you only really need to worry about if you have shared data (eg. a 32-bit variable accessed by both a SH2 and the M68000 needs some sort of guard lock).

 

[Coolgame]

oh no,that's not really what i wanted to ask, i know i ask it but,

it's like this, what if i wanted to do some sort of 3d transfomation

that require 32bit vertices animation using the b-bus at full 28mhz

speed (with 60 frames per second)?

in other words a better way to put it, what if a 32bit program is

running on the b-bus a full speed?

would that mean you can only use half that or you can only run a 16bit

program on the b-bus at 28mhz?

 

[antime]

The answer is the same. A 32-bit access will take two bus cycles (plus any wait states added by bus arbitration).

 

[Coolgame]

well i kind of figure that but if that's the case is there another way around the b-bus?

do any other buses go to the vdp 1 and 2?

like the the system bus?

 

[antime]

No, do you expect this to be an issue for you?

 

[Coolgame]

do you expect this to be an issue for you?

no, at least not much unless there's any slow down when acessing vdp 1 and 2 vram at the same time and

will it add more stress if i use the dsp to do vertice transformation math.

if i like to use 3 or 4 resources (sh2,vdp 1 and 2 the scu's dsp) will there be a issue?

 

[antime]

That depends on how much data you want to transfer, but probably not. VDP1 is much more likely to be fillrate limited (which also limits the amount of vertices processed), and for VDP2 you usually just update some registers once per frame and maybe some tilemap data.

 

[Coolgame]

yeah, in that case i have to find a way to cope with that fact.

im learning alot about the saturn (no more coding contests?).

sometime around this december im buying a new modchip, these emulators is not cutting

it.

maybe that's it about the b-bus for now.

being how it's structure a effective graphic

engine is needed.

but in that case can the dsp math chip do Gouraud shading or pre clipping?

when they say it can do lighting calculation in what way? has it been use before?

 

[antime]

You'll gain the best insight of the SCU DSP's capabilities by reading the SCU manual and the tutorial tech note (SOA-8). Its main strength is performing series of single-cycle multiplications, and if you can't keep the multiplier busy the work is probably better performed on one of the main CPUs (the SCU DSP instruction set is awkward for more general-purpose programming, and the clock frequency is only half of the SH2s).

 

[Coolgame]

You'll gain the best insight of the SCU DSP's capabilities by reading the SCU manual and the tutorial tech note (SOA-8). Its main strength is performing series of single-cycle multiplications, and if you can't keep the multiplier busy the work is probably better performed on one of the main CPUs (the SCU DSP instruction set is awkward for more general-purpose programming, and the clock frequency is only half of the SH2s).

i read those soa tutorial notes and the SCU manual on the dsp, even the (SBL) basic library manual.

but can you tell me about how to use the dsp in light calculation? does it do gourad shading?

I think i can make a supreb engine if i can program the dsp to do lighting (gourad shading) and

pre clipping while the other processors do their thang.

can it do pre clipping?

p.s i know im off topic to orginally talk about the b-bus, im sorry, do you think i should start a new message board subject?

 

[rorirub]

Gourad Shading is applied by the VDP1, but lightning should be handled by your software code.