PDA

View Full Version : A thought/question to homebrew developers.



Jadty
05-08-2011, 05:40 PM
Disclaimer: I know nothing of programming and the following is just some wishful thinking and brainstorming from yours truly.
inb4 OP is thinking of unicorns.

As complicated as it may sound, could a game (or even a tech demo) be developed that used the 32X and Sega CD (and the Genesis obviously) to the maximum potential? I think that after all these years the parts for this kind of ambitious project would be cheap to produce. Let's say we have a cartridge (in this setup it would be a 32X cart) with a ROM capacity of, I don't know, 256MB? (the Golden Sun - Dark Dawn rom on Nintendo DS is 256MB, and that is a HUGE game with excellent graphics and detail), a Sega CD and a disc holding data for music or SFX streaming (like Pier Solar). You'd have all of this producing very smooth texture mapped polygons/huge, very well animated sprites using the horsepower of Genesis, 32X and Sega CD graphic chips.

I originally included the SVP Chip in this list, but after some Wikipedia reading, I found out it's not possible to implement SVP and 32X at the same time due to some memory address limitations. I don't know, but maybe some genius programmer could find a workaround of this and implement it succesfully.

Now, would the Genesis be able to handle a cart with a rom so big? Is the Motorola 68000 prepared to address such a big amount of rom data? I think I read somewhere on the Pier Solar forums that they managed to implement 64mbit of rom only after struggling with the rom addressing method (or something like that, again, I don't know about programming).

Also, in case the Genesis is not prepared to handle this amount of data, maybe the Sega CD disc could be used for rom data instead of just music. That would do the trick to have a huge space for working rom-wise (this is assuming the minimal or no amount of this data will be used for FMV's and PCM music).

Some other thoughts: Is the Genesis prepared to have a music co-processor in the form of a chip-on-cartridge solution? (like the VRC6 used in some Konami games from the NES era, ex: Castlevania III). In this case, I'm thinking of a setup that involves a 32X cart that only includes such audio co-processor, some rom space for samples/voices (?) and if an SVP workaround is discovered, also one of those. Imagine having a much superior sound chip, having synthesized tunes at the level of a decent keyboard, it would be awesome and would completely change the musical capabilities of the Genesis. What I'm not sure about is if the Genesis has enough bus bandwidth to handle such amount of data coming back and forth between all of the devices working ideally close to 100%.

That's all I have in mind for now, sorry for the wall of text and formatting.
Please discuss.

Kamahl
05-08-2011, 05:46 PM
I don't understand your question.

Flygon
05-08-2011, 05:49 PM
The Mega Drive could handle an almost arbitrary amount of ROM on the cartridge, it just depends on how you wish to use bank switchers (To change between separate banks of ROM). There's a reason Game Boy Color games went up to 8 megabytes (Thanks to having a huge massive amount of 64 kilobyte banks), and probably would have shoveled up higher if the console lasted longer.

The techies know more about this than I do, of course.

Jadty
05-08-2011, 05:52 PM
I don't understand your question.

Basically I would like to know if my crazy ideas could be implemented on real world hardware.

Kamahl
05-08-2011, 05:59 PM
Huge ass Rom -> Bankswitching
There's no need for the SVP chip if you have the 32X hardware.
32X + Sega CD for rom data would be troublesome. Using just the Sega CD + a normal genesis cart is ok.
The genesis can have an audio chip on cart, the 32X includes an additional soundchip. The cable that has do be connected is for graphics not audio.

I still don't understand what you actually want to know.

Guntz
05-08-2011, 06:35 PM
I think he wants to know if you could use the Genesis, 32X and Sega CD all running one program that uses all of their combined power to make a really impressive game.

My answer: Sure, anything is possible. But right now there isn't a team working on such a game. As for cart storage, like what Kamahl said; bankswitching. Using that you can pretty much have any ROM size you want. But as for addressable space with no bankswitching, I don't think it's that high. Isn't 40 some Megabits the most the Genesis can read? Looking over a the NEO-GEO for a moment, I think addressable cart space is more dependent on things like the cart bus size (one of the Neo systems is around 260 pins for the cart slot, whereas the Genesis is only 60 pins wide), rather than CPU bit-ness and power.

Jadty
05-08-2011, 06:43 PM
Huge ass Rom -> Bankswitching
Big rom on cart: check



There's no need for the SVP chip if you have the 32X hardware.
Fair enough, but I was thinking of using combined horsepower, imagine SLI videocard technology. But ok, let's scratch that one out for simplicity's sake.


32X + Sega CD for rom data would be troublesome. Using just the Sega CD + a normal genesis cart is ok.

This I agree, I was thinking of putting everything related on the same place, as in having samples and PCM music on the cart together with the extra sound chip, and leaving CD for game data only. But I don't know how efficient that would be, if even doable.


The genesis can have an audio chip on cart, the 32X includes an additional soundchip. The cable that has do be connected is for graphics not audio.

I know the 32X adds more sound channels to the Genesis, I was thinking of having a completely different, modern sound chip, capable of producing higher quality sounds.


I still don't understand what you actually want to know.

Let me say it like this, I was thinking of pooling all of the resources of all the attachments of the Genesis + some new added features to make a very powerful console.

Chilly Willy
05-08-2011, 09:51 PM
What would be better is a cart similar to the Everdrive-MD, but with lots of ram instead of flash. It would load from an SD card, and have 64 MBytes of SDRAM (bank selected) to run from. You wouldn't need the CD that way, and you'd have plenty of memory to pull stuff (textures, sounds, etc) from.

You want as much as possible in memory to avoid loading, but not be TOO expensive. A 32Mx16 SDRAM from Digikey runs about $33, and 64 MBytes is a good amount for games the 32X MIGHT run if it had that much ram (like Quake).

old man
05-08-2011, 10:07 PM
I think the CD would actually slow things down. Your better off just doing the genesis/32x combo.

Jadty
05-08-2011, 10:34 PM
I think the CD would actually slow things down. Your better off just doing the genesis/32x combo.

Yeah, but the Sega CD has some sweet scaling hardware and sound chips. Also 700MB of working space is nothing to sneeze at when comparing price/capacity ratio.

Chilly Willy
05-08-2011, 10:48 PM
Yeah, but the Sega CD has some sweet scaling hardware and sound chips. Also 700MB of working space is nothing to sneeze at when comparing price/capacity ratio.

Except that with the 32X, neither are needed and just add to the expense. As long is it's for the 32X, make a ram cart + SD interface. It will be FAR faster than the CD and far larger. A CD may be 700 MB, but an SD card can be 32GB (SDHC). A reasonable size SD card these days is less than $10 and still much larger than a CD. The expense in the cart isn't the SD interface - that's almost nothing - it's the flash/ram and the CPLD. As long as you are doing a cart of any kind, the SD is a natural progression that eliminates the CD from the equation.

Jadty
05-08-2011, 11:10 PM
Except that with the 32X, neither are needed and just add to the expense. As long is it's for the 32X, make a ram cart + SD interface. It will be FAR faster than the CD and far larger. A CD may be 700 MB, but an SD card can be 32GB (SDHC). A reasonable size SD card these days is less than $10 and still much larger than a CD. The expense in the cart isn't the SD interface - that's almost nothing - it's the flash/ram and the CPLD. As long as you are doing a cart of any kind, the SD is a natural progression that eliminates the CD from the equation.

Good point, you seem to know a lot about how the console works so let me ask you this. Would it be possible to have that same cartridge you describe with 64MB ram and also a far superior sound chip? I keep thinking of a different sound chip because I can imagine a Genesis game pumping music as good as a decent Roland synth, or using very high quality PCM samples to use as strings, drums, guitars, synth leads, etc. I've always loved the sound of the Genesis sound chip and can only imagine what would happen if the sound could be upgraded externally and having old games using new sound banks. Am I making sense here?

Chilly Willy
05-09-2011, 12:19 AM
Good point, you seem to know a lot about how the console works so let me ask you this. Would it be possible to have that same cartridge you describe with 64MB ram and also a far superior sound chip? I keep thinking of a different sound chip because I can imagine a Genesis game pumping music as good as a decent Roland synth, or using very high quality PCM samples to use as strings, drums, guitars, synth leads, etc. I've always loved the sound of the Genesis sound chip and can only imagine what would happen if the sound could be upgraded externally and having old games using new sound banks. Am I making sense here?

Since the 32X uses the sound in lines for its own sound, it doesn't pass through/mix the sound in lines from its own cart port. So you would have to include your own mixing circuitry on the cart for more sound. Or maybe you could just say screw the MD/32X sound altogether and have a TOSLINK connector on the cart with optical 32-bit digital sound. :)

Of course, now you're really starting to add features that move you away from being a SEGA system. How about adding an X4 Athlon and an Nvidia chip to go with that sound chip? ;)

The point of programming on old consoles is to do something on the old console, not to turn the old console into a modern PC. I can see ram/flash and an SD cart port, but going beyond that you might as well just program on the PC instead. Your original idea called for giving the best the 32X can deliver, not the best some other custom chips can deliver.

Jadty
05-09-2011, 02:40 AM
Since the 32X uses the sound in lines for its own sound, it doesn't pass through/mix the sound in lines from its own cart port. So you would have to include your own mixing circuitry on the cart for more sound. Or maybe you could just say screw the MD/32X sound altogether and have a TOSLINK connector on the cart with optical 32-bit digital sound. :)

Of course, now you're really starting to add features that move you away from being a SEGA system. How about adding an X4 Athlon and an Nvidia chip to go with that sound chip? ;)

The point of programming on old consoles is to do something on the old console, not to turn the old console into a modern PC. I can see ram/flash and an SD cart port, but going beyond that you might as well just program on the PC instead. Your original idea called for giving the best the 32X can deliver, not the best some other custom chips can deliver.

It would be awesome if the community managed to develop a new hardware add on that could bring new life to the Genesis. Maybe not as outrageous as my ideas, but perhaps something more modest, even that cart with more ram inside. Some very interesting possibilities could arise from it.

TmEE
05-09-2011, 03:21 AM
32X DOES pass through the sound from cart port

You are not going to get any use out of some modern sound chip as there's none, except for some dumb DAC type things which are incapable of doing anything on their own.... Yamaha YMF278 would kick some serious ass there, OPL3 FM + 24 sample channels, 8/12/16bits, up to 44KHz, can use either sample ROM or RAM.

Making the hardware is easy, but the problem is that only new homebrew can ever use it and there's not enough of it

Chilly Willy
05-09-2011, 03:28 AM
32X DOES pass through the sound from cart port

It does? Cool. Learned something new. So you COULD put a sound chip in a 32X cart for better sound.



You are not going to get any use out of some modern sound chip as there's none, except for some dumb DAC type things which are incapable of doing anything on their own.... Yamaha YMF278 would kick some serious ass there, OPL3 FM + 24 sample channels, 8/12/16bits, up to 44KHz, can use either sample ROM or RAM.

A "standard Windows codec" would give you 16/24 bit 6/8 channel audio, and you could drive it with the 32X DMA. You'd still have to do all the mixing/effects with the CPU.



Making the hardware is easy, but the problem is that only new homebrew can ever use it and there's not enough of it

Yep, which is why I really don't think anything more than storage (ram/flash/SD) should be considered for such a project. Besides, I think my mod player + sfx demo proves the 32X PWM is adequate for games. 10 bit audio at 22kHz is more than adequate to the task.

TmEE
05-09-2011, 07:25 AM
A "standard Windows codec" would give you 16/24 bit 6/8 channel audio, and you could drive it with the 32X DMA. You'd still have to do all the mixing/effects with the CPU.
That is exactly the thing I would want to avoid. I would not settle for less than 16 channels in my stuff, and that is music alone, plus massive ROM use and bus bandwidth consumption when mixing is happening...

Chilly Willy
05-09-2011, 03:56 PM
That is exactly the thing I would want to avoid. I would not settle for less than 16 channels in my stuff, and that is music alone, plus massive ROM use and bus bandwidth consumption when mixing is happening...

Well, if you used an FPGA I suppose it would be possible to make a "simple" mixer for several DMA channels that output PWM. Typical SDRAM speeds today are 166Mhz and up, so you'd have plenty of time for DMA without slowing the CPU access to the memory. FPGAs have several multipliers in them, so you can even do things like volume, panning, and modulation effects without too much trouble. Do a simple fixed point sampler on the DMA channels for changing the pitch along with length and loop values and your mixer is all set for wavetable music and stereo/surround sound effects.

Such a sound mixer would be child's play to do in an FPGA like an Altera Cyclone. But again, we're now in territory of no longer being the same console... do we want to add that to the 32X? If we do, then at the same time, add a REAL GPU as well - it would be pretty easy to make a "blitter" for the 32X video that works on 8 and 16 bit pixels that can rotate/scale sprites, with one function to help render rasterized lines for 3D. It would run at the full speed of the SDRAM. Then all the SH2 would have to do is game logic, rasterizing polygons, and move the finished data to the 32X framebuffer. For sound, all the SH2 would have to do is process the music score and set the mixer values.

Such a cart would make ports of a bunch of different games much easier on the 32X... but it's more than just a 32X at that point. I guess one way to think about it is like the old 386 systems where you added a separate 3DFX card (the first that ONLY did 3D, not handle the display), and a sound card with hardware mixing like an AWE64.

Guntz
05-09-2011, 04:57 PM
Such a 32X hardware upgrade (that's really funny if you think about it :lol:) should be a lock-on cart. It would be insanely expensive to do a StarFox-style game on 32X.


To be honest though, I really don't like the idea of further additions to the hardware. By the time you're done adding new graphics and sound chips, it's not even a Genesis or 32X anymore. You might as well develop for a totally new piece of hardware instead (like a DS or 360) if you're gonna go to all that trouble to improve Sega's original hardware.

Chilly Willy
05-09-2011, 06:12 PM
Such a 32X hardware upgrade (that's really funny if you think about it :lol:) should be a lock-on cart. It would be insanely expensive to do a StarFox-style game on 32X.

No, it should have lots of ram and an SD card interface. Lock-on is well past its time - the SVP was the optimum period and item for lock-on. Using lock-on now in place of ram + SD is just silly.



To be honest though, I really don't like the idea of further additions to the hardware. By the time you're done adding new graphics and sound chips, it's not even a Genesis or 32X anymore. You might as well develop for a totally new piece of hardware instead (like a DS or 360) if you're gonna go to all that trouble to improve Sega's original hardware.

Which has been my point through the thread. I don't mind the idea of ram + SD, but the rest kind of defeats the purpose of programming on the 32X.

Guntz
05-09-2011, 08:34 PM
No, it should have lots of ram and an SD card interface. Lock-on is well past its time - the SVP was the optimum period and item for lock-on. Using lock-on now in place of ram + SD is just silly.

You misunderstand me. I mean the RAM + extra GFX and sound chips should be in a lock-on cart, so a regular cart can attach on top. If it has an SD interface, it might as well be a flash cart like the Everdrive. Who wants to have a new 32X game released on SD media?





Which has been my point through the thread. I don't mind the idea of ram + SD, but the rest kind of defeats the purpose of programming on the 32X.

Exactly. There's so much ridiculous extra hardware available for the Genesis already (most thanks to Sega), there's no point in making even MORE for the old 16-Bit monster. What we need are GAMES, not more hardware.

Of course, I think the reason why everyone talks about hardware rather than games is because hardware is easier to understand. Programming on the Genesis, even if it's easy, is actually pretty hard to get started with.

TmEE
05-10-2011, 04:58 AM
With FPGA you could take the 32X out from the mix, and have Video In/Out connector on the cart :P

kool kitty89
05-10-2011, 05:03 PM
32X DOES pass through the sound from cart port

You are not going to get any use out of some modern sound chip as there's none, except for some dumb DAC type things which are incapable of doing anything on their own.... Yamaha YMF278 would kick some serious ass there, OPL3 FM + 24 sample channels, 8/12/16bits, up to 44KHz, can use either sample ROM or RAM.
You'd need an added interface to allow the OPL4 to work in SDRAM rather than SRAM/ROM (which is all it supports natively), but that's probably not a big deal.

If sharing the main bus, that would also mean a somewhat hefty amount of bandwidth for higher sample rate stuff as it's all uncompressed. (you could do some software decompression, but that would end up using even more bandwidth in this case -unless you gave the OPL4 is own buffer of RAM to work in a decompressed/paged samples to it as needed -in that case, you could use SRAM or PSRAM and omit the DRAM interface)
If it shared the bus, 44 kHz 16-bit samples on all 24 channels would be about 2 MB/s (which would be under 5% of the SDRAM bandwidth), but since it would tend to be slow random accesses to SDRAM (without special buffering), that would probably end up taking closer to 15% of overall bus time. (depending on the speed of the OPL4's accesses and the actual access time for random access in the 32x SDRAM)

Of course, if you limited everything to 8-bit 22 kHz (or less) samples, that would be 1/4 of that. (unless it accesses 8 bit samples at one byte per read, so you'd use the same effective bandwidth for any sample size)



That is exactly the thing I would want to avoid. I would not settle for less than 16 channels in my stuff, and that is music alone, plus massive ROM use and bus bandwidth consumption when mixing is happening...
If you had all the samples compressed, that would be less of an issue. (especially if you split the SH2 cache and mixed to the scratchpad -to stay off the bus as much as possible- and thus only accessed the bus to read compressed sample data and write back the final mixed output from the buffer on-chip -outputting at 22 kHz should take less than .2% of SDRAM bandwdith for stereo, though there's the DMA overhead as well -not sure how fast that is- and under .3% of main bandwidth if you used 16 channels of 22 kHz T-ADPCM samples -about .2% with 2-bit CVSD- or closer to 1% if you ended up doing mostly random access reads)

The bigger issue would probably be slave SH2 resource used for the decompression and mixing, and how much would be left for other things.





If we do, then at the same time, add a REAL GPU as well - it would be pretty easy to make a "blitter" for the 32X video that works on 8 and 16 bit pixels that can rotate/scale sprites, with one function to help render rasterized lines for 3D. It would run at the full speed of the SDRAM. Then all the SH2 would have to do is game logic, rasterizing polygons, and move the finished data to the 32X framebuffer. For sound, all the SH2 would have to do is process the music score and set the mixer values.
Such a blitter would make it a lot closer to the GBA, but with more CPU resource. ;)


Except that with the 32X, neither are needed and just add to the expense. As long is it's for the 32X, make a ram cart + SD interface. It will be FAR faster than the CD and far larger. A CD may be 700 MB, but an SD card can be 32GB (SDHC). A reasonable size SD card these days is less than $10 and still much larger than a CD. The expense in the cart isn't the SD interface - that's almost nothing - it's the flash/ram and the CPLD. As long as you are doing a cart of any kind, the SD is a natural progression that eliminates the CD from the equation.
The CD's rendering capabilities would have been a lot more useful without the bottlenecks, though the sound chip could still be a useful option to free-up the 32x end, not to mention the potential of running a chunk of the game engine on the CD's 68k.

The bigger issue is, of course that many people already have Sega CDs (more than 32xs), so there's that to build on far more than any new/custom add-on. (plus there's the whole issue of wanting to see what could be done with the existing system Sega had back in 1994 ;))
. . . Albeit, on that latter note, one could argue that Sega might have released a RAM expansion for the 32x if the CD32x format really caught on. ;) (probably more like 1-2 MB though, and I think you mentioned that the Neo Myth's SRAM/PSRAM can already be configured to behave as RAM expansion in the 32x, or maybe I'm remember wrong)



You misunderstand me. I mean the RAM + extra GFX and sound chips should be in a lock-on cart, so a regular cart can attach on top. If it has an SD interface, it might as well be a flash cart like the Everdrive. Who wants to have a new 32X game released on SD media?
Umm, most homebrewers and hackers would probably much prefer the SD route. ;)
We're not talking full releases here, but free to download homebrew games (and possible hacks thereof).
Just like flash carts are being used as now.








Huge ass Rom -> Bankswitching
There's no need for the SVP chip if you have the 32X hardware.
32X + Sega CD for rom data would be troublesome. Using just the Sega CD + a normal genesis cart is ok.
I don't think having the CD function while a 32x cart is used is much different from getting it to work with a MD cart.
Getting the CD and 32x to work together in general is a separate topic. (and aside from needing to understand both the 32x and CD -as well as the genesis, there's a lot of bottlenecks that prevent useful cooperation for some things; namely the huge bottleneck of the Geneiss 68k acting as the middle man for any data -or code- moved from CD to 32x, namely an issue for trying to use the CD's ASIC for 32x graphics -the ASIC also had to stop rendering while the MD is transferring data since the word RAM is switched to the MD bus while that happens -actually a bigger bottleneck than the MD VDP's vblank DMA in that sense -DMA is at ~2.6 or ~3.25 MB/s vs ~1.52 MB/s for 68k block transfers)

That's one reason it would have made more sense for Sega to make a backwards compatible MD+CD derived successor rather than doing more add-ons. (that, and a slough of other added possibilities for enhancing the hardware at far greater cost efficacy than would be possible via add-ons -modest tweaks to the ASIC could have made it useful for rendering 8 and 16-bit graphics at similar speeds, let alone more aggressive enhancements like read/write phrase buffers -actually making it more efficient than the Saturn's VDP1- and many other possibilities for re-arranging and enhancing other parts of the system to make the most of the hardware at optimal cost -lots of options for building onto the MD VDPs incluidng some suggestions Chilly Willy made about doubled VDPs with flexible ability for layer combing for 4 or 8bpp modes and dual VRAM banks for each VDP to avoid contention . . . or other things like adding simple bitmap graphics modes -maybe 2 4bpp framebuffer layers supports per VDP with ability to combine to 8bpp, especially if that allowed the VRAM to be used fully in parallel without need for banking -ie like dual-port VRAM normally is in framebuffer based systems, then there's speeding up the 68k -at least making both 12.5 MHz, but 16.67 MHz rated versions would have been pretty cheap by that point too -and that's 1/3 the 50 MHz CD clock rate, various options for RAM and sound, etc, etc)

That's another topic entirely though. ;)



The genesis can have an audio chip on cart, the 32X includes an additional soundchip. The cable that has do be connected is for graphics not audio.
Not so much a sound chip as a pair of DACs with FIFO and DMA support. (except the DMA wasn't supported on any known dev kits back then -initial preproduction dev systems had broken DMA and Sega apparently never updated that in the manuals, so all games used FIFO or direct DAC writes with interrupt driven PCM drivers with excessive SH2 resource usage)

With DMA (more or less comparable to the STe's DMA, but with more flexibility over resolution and sample rate used via a semi-proprietary PWM format -I think the GBA may use the same format), you can to a lot more with the SH2s. (Chilly Willy's sample driver uses the slave SH2 to mix 32 channels at 22 kHz 10-bit stereo iirc, not sure if that's doing compression as well)
Of course, there's a trade-off of audio processing vs other performance depending on the game.

Jadty
05-10-2011, 05:52 PM
I'm really surprised and satisfied with the amount of technical discussion my thread has brought. I hope something good comes out of this, maybe the inspiration for some of you guys to start an expansion project :D

Chilly Willy
05-10-2011, 07:53 PM
(Chilly Willy's sample driver uses the slave SH2 to mix 32 channels at 22 kHz 10-bit stereo iirc, not sure if that's doing compression as well)

It's not. Everything is uncompressed signed 8-bit samples up to 256KBytes long. That's easy enough to change, but it's how it is right now.

I estimate you can mix up to 32 active channels; the current code just does 8. That's easy to change in the code as well, but if you add too many channels together, you may need to change the volume calculation to keep the sound from overflowing in the mixer. The current way the volume is calculated guarantees the sound cannot overflow with 8 active channels being mixed.

Also, mixing too many channels will consume more bus cycles on the 32X bus, slowing the game. Eight is good - enough for music and a few simultaneous sfx while consuming little bus time. I would recommend no more than 16 channels for a game, but a dedicated music program can do 32 or more.

TmEE
05-13-2011, 03:09 AM
You'd need an added interface to allow the OPL4 to work in SDRAM rather than SRAM/ROM (which is all it supports natively), but that's probably not a big deal.

If sharing the main bus, that would also mean a somewhat hefty amount of bandwidth for higher sample rate stuff as it's all uncompressed. (you could do some software decompression, but that would end up using even more bandwidth in this case -unless you gave the OPL4 is own buffer of RAM to work in a decompressed/paged samples to it as needed -in that case, you could use SRAM or PSRAM and omit the DRAM interface)
If it shared the bus, 44 kHz 16-bit samples on all 24 channels would be about 2 MB/s (which would be under 5% of the SDRAM bandwidth), but since it would tend to be slow random accesses to SDRAM (without special buffering), that would probably end up taking closer to 15% of overall bus time. (depending on the speed of the OPL4's accesses and the actual access time for random access in the 32x SDRAM)

You cannot share anything, and I was more thinking on dedicated sample ROM (i.e music and all SFX that are used everywhere and that fit in) and RAM for stuff that don't fit or constantly changes throughout the game. You will not be able to share the memory in any case, there's no arbitration setup there, and if there were you're better off using SH2s for doing the job as the performance would get wasted anyway.