32X cartridge bigger than 32Mbits ?

[ob1]

The 32x Hardware Manual, in 3.1, ROM cartridge access when using the 32x states :

The MEGA Drive has a bank set register (A1 30F1h - A1 30FFh odd numbered addresses) for coping with a cartridge ROM that exceeeds 32Mbits. The RV bit should be set to "1" beforehand when accessing here.

So, does a 32x cartridge be bigger than 32MBits ? Up to how much ? How to access it ? What are these registers A130F1~A130FF ?

[oompa loompa]

yea, any cartridge can be bigger than 32mbits, but only through external bankswitching. a game rom can also allocate itself to $000000-$7FFFFF, but i never seen any carts that do this, nor do i think it'll work on genesis systems released after the model 2.

any read/write to $A13000 - $A130FF pulses the /TIME signal on the cartridge port -> handy for external bankswitching hardware

[GiGaBiTe]

You would think that the 32x could address more than 4M of space without bankswitching due to it being a pure 32-bit CPU.

[jlf65]

It can. They're talking about the Genesis side mapping for the 68K/Z80. If I remember correctly, the 32X can access up to 32MB directly on carts. I'd have to check my notes again to be certain on the exact size, but it's far larger than the Genesis side.

[GiGaBiTe]

jlf65 said:

It can. They're talking about the Genesis side mapping for the 68K/Z80. If I remember correctly, the 32X can access up to 32MB directly on carts. I'd have to check my notes again to be certain on the exact size, but it's far larger than the Genesis side.

I was thinking more along the lines of 4096 megabytes. Any CPU with a 32 bit address and data bus should be able to address that much in pure memory terms, but I'm not very familiar with the internals of the SH2.

[ob1]

If memory serves me weel, the SH2 has a 25 bit address bus : 32MB. Moreover, there are 4 chip select : CS0 to CS3, so 128MB.
The 32X memory mapping does state it. But the ROM cartridge only goes from 0200 0000h to 0240 0000h, even if the CS1 would allow a cartridge from 0200 0000h to 0400 0000h. I've never tried to go beyond 0240 0000h.

[jlf65]

ob1 said:

If memory serves me weel, the SH2 has a 25 bit address bus : 32MB. Moreover, there are 4 chip select : CS0 to CS3, so 128MB.
The 32X memory mapping does state it. But the ROM cartridge only goes from 0200 0000h to 0240 0000h, even if the CS1 would allow a cartridge from 0200 0000h to 0400 0000h. I've never tried to go beyond 0240 0000h.

Yes, i do think that's right. That's where I remember the 32M from. The ROM has one select line dedicated to it and can be a max of 32M, but I don't know what the largest anyone has actually tried is.

[GiGaBiTe]

It really wouldn't be feasible to have a 128M ROM unless you un-gimped the SH2's to their stock speed of 28.7 MHz and created a very good software renderer so that 3D mode doesn't look like garbage.

Unreal's software mode was and still is probably the best out there, because you don't get de-forming polygons and warping textures when you rotate your view which was very common on the 32x, Saturn and PS1.

it would be nice if someone could impliment it on the 32x, assuming the correctly clocked SH2's could handle it. I'm assuming they could if you made both SH2's do the rendering and sent the game data off to the 68000 in the main genesis or SCD.

[ob1]

You mean : both SH2 rendering tiles, and sending them to the 68000 VDP ?
Why not.
Isn't that the way Virtua Racing SVP works ?

[jlf65]

gigabite said:

It really wouldn't be feasible to have a 128M ROM unless you un-gimped the SH2's to their stock speed of 28.7 MHz and created a very good software renderer so that 3D mode doesn't look like garbage.

Unreal's software mode was and still is probably the best out there, because you don't get de-forming polygons and warping textures when you rotate your view which was very common on the 32x, Saturn and PS1.

it would be nice if someone could impliment it on the 32x, assuming the correctly clocked SH2's could handle it. I'm assuming they could if you made both SH2's do the rendering and sent the game data off to the 68000 in the main genesis or SCD.

All those consoles did affine texture mapping. Perspective correct mapping requires a division for every single pixel plotted, so on older systems, they would calculate the correct value at the start and end of a pixel span, then interpolate linearly between those points. If the two points are closer together, the linear region closely matches the non-linear curve generated by dividing at each point along the curve. If the points are farther apart, you get the classic fish-eye effect.

So it's a trade-off: move the endpoints farther apart and you go faster (fewer divides), but you get fish-eye; closer together prevents fish-eye, but slows rendering due to an increase in divides. So you can render on the 32X such that textures aren't warped (or not enough to really tell), but it will slow down the rendering.

[GiGaBiTe]

ob1 said:

You mean : both SH2 rendering tiles, and sending them to the 68000 VDP ?
Why not.
Isn't that the way Virtua Racing SVP works ?

No, I mean doing it 3dfx style and having each SH2 render different frames.

<68000 does game data>

SH2's do graphics in 32x

SH2 #1 renders frame 1 and sends to 32x VDP
SH2 #2 renders frame 2 and sends to 32x VDP
SH2 #1 renders frame 3 and sends to 32x VDP
SH2 #2 renders frame 4 and sends to 32x VDP

etc.

jlf65 said:

<very long post>

Yes, rendering will slow down in a traditional environment of one SH2 being game and the other being graphics, but if you use the method above, you could probably increase the performance 60-90%

I also don't get why sega retarded the clock speed to 23.5 MHz when the SH2 was designed to run at 28.7 MHz, I'm assuming that they didn't want the 32x to run into the Saturn market.

[pmjobin]

According to me, the major obstacle is bus bandwidth, not CPU power. The bus is shared between both SH-2s, the SD-RAM and the I/F ASIC (which also contains the PWM sound source). Furthermore, the slave SH can only lock access to the bus when the master frees it. So you have to consider that both SHs acts totally differently when you design your engine (ie: you can't run the same code on both of them and expect good performances). Finally, the SH-2 cache (4KB shared) is rather small for that kind of data intensive applications so you have to organize your datasets in a way that will prevent cache trashing as much as possible. What I suggest is to only use the slave SH to render into the framebuffer since the master can take over the bus anytime (in other words, make the slave SH perform bus intensive operations since it will not hinder the master SH, the opposite isn't true). The engine itself should use a tile array (CLX2 in Dreamcast) or span sorting approach (~Quake) with zero overdraw (in order to preserve bus cycles as much as possible) and render objects according to the texture they use (do everything with one texture before switching to another in order to prevent cache trashing). Also, make _very_ small textures or compress them in some way (eg: 4bpp palletized). This is the big picture:

FRAME n:
SH-master: generate span tree / tile array
SH-slave: draw span tree / tile array of frame n-1
{
while (numtex > 0) {
render every objects using a given texture
load next texture
}
Switch framebuffer & span tree / tile array
END

OK, this kind of processing may be CPU intensive but as I told earlier, the 32X is NOT bounded by CPU power as much as it is bounded by bus bandwidth (remember that the cache is shared so data access can only occur when the MOV instruction is executed in the leading IF stage).

[jlf65]

gigabite said:

I also don't get why sega retarded the clock speed to 23.5 MHz when the SH2 was designed to run at 28.7 MHz, I'm assuming that they didn't want the 32x to run into the Saturn market.

The SH2s use a PLL to generate a 3X Genesis clock. Four times would be >30MHz, which was too fast for them. Using a clock synchronized to the main Genesis clock made the logic easier than using an asynchronous clock (28MHz).

[bob]

I'm guessing that you can't use half multipliers. 7.83 MHz x 3.5 = 27.40 Mhz which is closest to 28.7 MHz without going over.

[jlf65]

bob said:

I'm guessing that you can't use half multipliers. 7.83 MHz x 3.5 = 27.40 Mhz which is closest to 28.7 MHz without going over.

Well, they do half multipliers NOW, but certainly not back in the mid-90's. ;D