wait states

[tomaitheous]

I'm curious if there's a way to halt the 68k to eliminate the additional wait states on the 32x side form accessing the bus. Somehow halt the 68k after the 32x initialize process? Be it hardware or not.

Or if there are any regions/areas in the address range that are remapped from the 32x unit when it is initialized - since it *is* the pass through for the cartridge. For the same idea above - to have access to ram/rom on the cart at same speed as internal SDRAM.

[8bitwizard]

I suppose if you really want to halt the 68K, just have it read an address space that doesn't provide DTACK.

But on an emulator or on hardware modified to provide BERR it probably won't work.

[Nemesis]

Execute an M68000 STOP opcode (0x4E72). While the M68000 is in a stopped state, it won't access the bus. Execution only resumes when an interrupt occurs.

[Stef]

...
For the same idea above - to have access to ram/rom on the cart at same speed as internal SDRAM.

You won't have access to rom on the cart at same speed as internal SDRAM whatever you do. The ROM is 16 bits and very slow when you compare it to the SH2 memory capabilities. You should never avoid as most as possible to access ROM when you're doing "in-game" processing. The normal way is to load ROM data into SDRAM before a level start then never access ROM at "in-game" time.
DOOM actually reads ROM data during 3D rendering, even worst it fetch its code from ROM, that partially explains the poor frame rate obtained...

[Chilly Willy]

That's understandable - DOOM has WAAAAAAAAY too much data to fit hardly any into SDRAM. I'm fairly certain the only thing in SDRAM is probably screen buffers (DOOM uses more than 2) and sound buffers. The DOOM executable wouldn't even fit in the SDRAM. A small level MIGHT fit in the SDRAM (just the level data, not the patches, flats, sprites, or sounds).

That's the biggest problem when making a DOOM conversion for the 32X - severe lack of RAM. Most console make up for that by leaving code and most data in the ROM. Just the variables and buffers go into RAM.

[tomaitheous]

Damn, that's right. The external bus is only 16bits wide.

Anyone have a nice opcode decoding chart for the sh2's?

[Snake]

You won't have access to rom on the cart at same speed as internal SDRAM whatever you do. The ROM is 16 bits and very slow when you compare it to the SH2 memory capabilities.

Yep. It's also much slower than the SDRAM anyway, so even if it were 32 bits, it'd still be slower.

Besides, I'm fairly certain that when the SH2s are reading ROM the 68K gets pushed aside, so there's no benefit in trying to stop the 68K.

The normal way is to load ROM data into SDRAM before a level start then never access ROM at "in-game" time.

Actually I think most games access ROM during the game. It's not too bad, unless...

fetch its code from ROM

Erk... that's nasty. I'm also pretty sure Sega tell you this is not allowed So DOOM is a bit naughty.

that partially explains the poor frame rate obtained...

Maybe, yeah. Still, I never understood why DOOM had such a small screen and such a low framerate. It should run way better than it did on a 486.

[tomaitheous]

It's also much slower than the SDRAM anyway, so even if it were 32 bits, it'd still be slower.

I take it then any access to the rom from the 32x is hard coded for slower memory interface than(fixed wait states)? That seems bazaar that they would not have a system/setting to change the wait states for faster ROMs.

Edit: Man.. I didn't see that the sVDP buffer has a latency of 3 cycles. Things are really looking bad on this design...

[TmEE co.(TM)]

SH2s were just too fast for the rest of 32X...