FRT input capture

[mic]

I was poking around again at some dual SH2 experiments on the Saturn and actually got it to work this time (on HW too).

Then I added syncing using the same method of polling the FRT control status register as used in the SBL. This also appeared to work, until I tested it on my Saturn and noticed that my slave code never seemed to be executed anymore.

The problem seems to have something to do with when 0xFFFF is written to 0x21000000. Does anyone know what this actually does? Will it just set the flag in FRTCSR, or does it also cause an interrupt?

 

[antime]

The FRT's input capture will cause an interrupt if enabled by the ICIE bit in TIER. The Dual CPU manual suggests that it isn't enabled by default, by that is simple enough to check.


Technically, the input capture is controlled by the CPU's FTI pin. Looking at the schematics found here (massively improved from the ones from that GeoCities page, but apparently done by the same person(s)) we see that both the master and slave CPU's FTI pins are connected to an ASIC which going by the pin names seems to sit on the memory bus. This in turn suggests that when this ASIC recognizes a write to memory address 0x21000000 it will pulse the slave CPU's FTI pin which will cause the ICF bit of FTCSR be set in the slave CPU which in turn causes an interrupt if enabled.


Clear as mud.

 

[mic]

Yeah. As it turns out the problem was simply that I was writing to 0x21000000 too soon after turning the slave on. So the slave probably hadn't had time to disable the FRT interrupt at that point, and it ended up who-knows-where.

I inserted a wait for vblank between turning on the slave and writing to 0x21000000 for the first time, and now it works as intended on my Saturn

 

[mic]

Oh, and here's the test program that I wrote (with source): http://jiggawatt.org/badc0de/dualgegg.zip

Works both in yabause and on a real Saturn.

It's a modification of a program I posted here last year(?). Just a simple graphical effect. The difference in this version is that I divide the screen horizontally into two equal parts and let the two SH2s draw one part each.

The mechanism is very simple; At the start of each frame the main SH2 signals to the slave SH2 that it should start drawing the bottom half of the screen. The main SH2 then draws the top half in parallel. Once it is finished it assumes that the slave also has finished, and it goes on to wait for the next vblank before copying the virtual screen to VDP2 RAM.

This was just a way to try some dual SH2 execution though. It's not very well optimized. You might want to make sure that as much as possible of the most frequently used code/data is always in cache for example - but this program doesn't do that.