Mars Check Program results for Kega Fusion v3.61
Moderator: BigEvilCorporation
Mars Check Program results for Kega Fusion v3.61
While I was digging through this ROM, I decided to give the latest version of Fusion (v3.61) a thorough test and report. For those who don't know, Mars Check Program is a program from SEGA (included in the 32X SDK) consisting of 161 hardware tests of the 32X. The program mainly tests documented features of the 32X. It has been reported that all of these tests succeed on the actual hardware. Many of these are simple tests such as register and memory read/write tests.
Normally, running this ROM in Fusion v3.61 causes a crash on test #38 of 161. As it turns out, some of these tests must be bypassed in order to obtain full results. For all I know, Steve already knows about all of these specific issues but I provide these results as a courtesy and for educational purposes as well.
Fusion v3.61 fails 26 of 161 tests:
#5 DREQ CONTROL REGISTER FULL BIT -- fails normally
- DREQ FIFO FULL flag is tested when FIFO is filled to 7 of 8 words (NOT FULL) and 8 of 8 words (FULL).
= Fusion incorrectly sets the FULL flag of the DREQ Control register based on whether the FIFO (either block) is NOT EMPTY instead of FULL.
#38 SH2 SERIAL COMMUNICATION -- stalls the Master SH-2 (must be bypassed)
- Tests the transmission of data via the SCI of both SH-2s.
= Fusion does not appear to emulate the SCI or else it is bugged.
FYI, the serial comm test uses the SCI in asynchronous mode at about 180000 bits per second -- the maximum async rate. Data size transmitted is 8 bits plus 3 individual bits for start, stop, and parity.
#53 SH2 MASTER H INTERRUPT (MD 0) -- fails normally
#54 SH2 SLAVE H INTERRUPT (MD 0) -- fails normally
#55 SH2 MASTER H INTERRUPT (MD 1) -- fails normally
#56 SH2 SLAVE H INTERRUPT (MD 1) -- fails normally
#57 SH2 MASTER H INTERRUPT (MD 2) -- fails normally
#58 SH2 SLAVE H INTERRUPT (MD 2) -- fails normally
- These tests roughly measure the frequency of H-INTs on the SH-2s.
= Fusion fails to trigger an H-INT in every case. The reason for this is unknown.
FYI, each test measures the number of H-INTs occuring in 30 frames. The H-INT count can be off by a frame's worth.
MD 0 counts H-INTs occuring on every line outside of VBLANK.
MD 1 counts H-INTs occuring on every line including those within the VBLANK.
MD 2 counts H-INTs occuring on every sixth line including those within the VBLANK.
#64 H BLANK BIT -- fails normally
#77 SH2 MASTER H BLANK BIT -- fails normally
#78 SH2 SLAVE H BLANK BIT -- fails normally
- Tests the HBLANK flag of the 32X VDP from the 68000 side and SH-2 side.
= Fusion doesn't set the HBLANK flag. This could very well be related to the previous issue.
#89 MD FRAME BUFFER 0 OVERWRITE -- fails normally
#90 MD FRAME BUFFER 1 OVERWRITE -- fails normally
- Tests the 68000 overwrite area on both frame buffers.
= Fusion doesn't emulate overwrite from the 68000 side. It treats the overwrite area as a mirror of the normal DRAM area.
#118 SH2 MASTER PALETTE R/W (DISP) -- stalls the Master SH-2 (must be bypassed)
#119 SH2 SLAVE PALETTE R/W (DISP) -- stalls the Slave SH-2 (must be bypassed)
- Tests normal 32X palette read and write. This test requires an active HBLANK flag.
= As previously stated, Fusion doesn't set the HBLANK flag, hence the stall.
#127 SH2 MASTER ROM TO SDRAM -- crashes the SH-2s, caused by corruption in SDRAM (can be bypassed or fixed)
#128 SH2 SLAVE ROM TO SDRAM -- crashes the SH-2s, caused by corruption in SDRAM (can be bypassed or fixed)
#133 SH2 MASTER FRAME TO SDRAM DMA -- fails, deadlocks the 68000 and Slave SH-2 (can be bypassed or fixed)
- This test incorrectly sets the DMA transfer unit to 16-byte [4 longword]. As I understand it, this is an illegal setting because it requires longword access, which is impossible to/from the external memories of the 32X. As a result, the test reverts to a 2-byte [word] transfer unit. It is possible that TS1 (bit 11) of the DMA Channel Control register is ignored in this case.
= Because of the illegal setting, Fusion overtransfers from ROM to SDRAM. The FRAME TO SDRAM test has a different result caused by the same illegal setting. Incidentally, #134 SH2 SLAVE FRAME TO SDRAM DMA succeeds without issue. When the setting is corrected, all of these tests succeed without issue.
#138 MD 68000 L -> R PAN -- incorrect playback, stalls the 68000 (must be bypassed) (NOTE: test can't fail explicitly)
#139 MD 68000 R -> L PAN -- incorrect playback, stalls the 68000 (must be bypassed) (NOTE: test can't fail explicitly)
- This test demonstrates PWM playback using a single FIFO switched from one speaker to the other.
= Fusion incorrectly implements channel output control via the PWM Control register.
The following is assumed to be the correct implemention:
RMD controls output to the right speaker and LMD controls output to the left speaker. The setting of each indicates the PWM FIFO source -- either left (L), right (R), or neither (OFF), but never both.
Fusion seems to disable the LEFT FIFO when LMD is set to OFF, even though RMD is set to L. The same occurs of the RIGHT FIFO. The test stalls as the program expects the PWM FIFO to become empty.
#143 SH2 MASTER L -> R PAN -- incorrect playback (NOTE: test can't fail explicitly)
#144 SH2 MASTER R -> L PAN -- incorrect playback (NOTE: test can't fail explicitly)
#148 SH2 SLAVE L -> R PAN -- incorrect playback (NOTE: test can't fail explicitly)
#149 SH2 SLAVE R -> L PAN -- incorrect playback (NOTE: test can't fail explicitly)
= These tests do not play correctly in Fusion for the same reason as the previous tests. However, they don't check the EMPTY flag so they do not stall.
#152 SH2 MASTER PWM DMA WRITE -- no sound output during test (NOTE: test can't fail explicitly)
- This test demonstrates PWM playback using DMA from SDRAM to PWM FIFO. Test runs for a fixed amount of time.
= Fusion doesn't seem to deliver the DREQ1 signal to the Master SH-2. On the other hand, #153 SH2 SLAVE PWM DMA WRITE works correctly.
#160 -- no 32X display during test (NOTE: test can't fail explicitly)
- This test is a demonstration of all 32X VDP modes using midframe mode switching performed by the 68000.
= Fusion doesn't respond to midframe 32X VDP mode switching, so the display stays in blank mode.
Not included among the failures is #161, a display test which appears to attempt to match Mega Drive VDP displayed color bars to 32X VDP displayed color bars. Since I am unable to compare the results between emulator and hardware, it is unknown whether Fusion's output is 'close enough', but I'll give Fusion the benefit.
Normally, running this ROM in Fusion v3.61 causes a crash on test #38 of 161. As it turns out, some of these tests must be bypassed in order to obtain full results. For all I know, Steve already knows about all of these specific issues but I provide these results as a courtesy and for educational purposes as well.
Fusion v3.61 fails 26 of 161 tests:
#5 DREQ CONTROL REGISTER FULL BIT -- fails normally
- DREQ FIFO FULL flag is tested when FIFO is filled to 7 of 8 words (NOT FULL) and 8 of 8 words (FULL).
= Fusion incorrectly sets the FULL flag of the DREQ Control register based on whether the FIFO (either block) is NOT EMPTY instead of FULL.
#38 SH2 SERIAL COMMUNICATION -- stalls the Master SH-2 (must be bypassed)
- Tests the transmission of data via the SCI of both SH-2s.
= Fusion does not appear to emulate the SCI or else it is bugged.
FYI, the serial comm test uses the SCI in asynchronous mode at about 180000 bits per second -- the maximum async rate. Data size transmitted is 8 bits plus 3 individual bits for start, stop, and parity.
#53 SH2 MASTER H INTERRUPT (MD 0) -- fails normally
#54 SH2 SLAVE H INTERRUPT (MD 0) -- fails normally
#55 SH2 MASTER H INTERRUPT (MD 1) -- fails normally
#56 SH2 SLAVE H INTERRUPT (MD 1) -- fails normally
#57 SH2 MASTER H INTERRUPT (MD 2) -- fails normally
#58 SH2 SLAVE H INTERRUPT (MD 2) -- fails normally
- These tests roughly measure the frequency of H-INTs on the SH-2s.
= Fusion fails to trigger an H-INT in every case. The reason for this is unknown.
FYI, each test measures the number of H-INTs occuring in 30 frames. The H-INT count can be off by a frame's worth.
MD 0 counts H-INTs occuring on every line outside of VBLANK.
MD 1 counts H-INTs occuring on every line including those within the VBLANK.
MD 2 counts H-INTs occuring on every sixth line including those within the VBLANK.
#64 H BLANK BIT -- fails normally
#77 SH2 MASTER H BLANK BIT -- fails normally
#78 SH2 SLAVE H BLANK BIT -- fails normally
- Tests the HBLANK flag of the 32X VDP from the 68000 side and SH-2 side.
= Fusion doesn't set the HBLANK flag. This could very well be related to the previous issue.
#89 MD FRAME BUFFER 0 OVERWRITE -- fails normally
#90 MD FRAME BUFFER 1 OVERWRITE -- fails normally
- Tests the 68000 overwrite area on both frame buffers.
= Fusion doesn't emulate overwrite from the 68000 side. It treats the overwrite area as a mirror of the normal DRAM area.
#118 SH2 MASTER PALETTE R/W (DISP) -- stalls the Master SH-2 (must be bypassed)
#119 SH2 SLAVE PALETTE R/W (DISP) -- stalls the Slave SH-2 (must be bypassed)
- Tests normal 32X palette read and write. This test requires an active HBLANK flag.
= As previously stated, Fusion doesn't set the HBLANK flag, hence the stall.
#127 SH2 MASTER ROM TO SDRAM -- crashes the SH-2s, caused by corruption in SDRAM (can be bypassed or fixed)
#128 SH2 SLAVE ROM TO SDRAM -- crashes the SH-2s, caused by corruption in SDRAM (can be bypassed or fixed)
#133 SH2 MASTER FRAME TO SDRAM DMA -- fails, deadlocks the 68000 and Slave SH-2 (can be bypassed or fixed)
- This test incorrectly sets the DMA transfer unit to 16-byte [4 longword]. As I understand it, this is an illegal setting because it requires longword access, which is impossible to/from the external memories of the 32X. As a result, the test reverts to a 2-byte [word] transfer unit. It is possible that TS1 (bit 11) of the DMA Channel Control register is ignored in this case.
= Because of the illegal setting, Fusion overtransfers from ROM to SDRAM. The FRAME TO SDRAM test has a different result caused by the same illegal setting. Incidentally, #134 SH2 SLAVE FRAME TO SDRAM DMA succeeds without issue. When the setting is corrected, all of these tests succeed without issue.
#138 MD 68000 L -> R PAN -- incorrect playback, stalls the 68000 (must be bypassed) (NOTE: test can't fail explicitly)
#139 MD 68000 R -> L PAN -- incorrect playback, stalls the 68000 (must be bypassed) (NOTE: test can't fail explicitly)
- This test demonstrates PWM playback using a single FIFO switched from one speaker to the other.
= Fusion incorrectly implements channel output control via the PWM Control register.
The following is assumed to be the correct implemention:
RMD controls output to the right speaker and LMD controls output to the left speaker. The setting of each indicates the PWM FIFO source -- either left (L), right (R), or neither (OFF), but never both.
Fusion seems to disable the LEFT FIFO when LMD is set to OFF, even though RMD is set to L. The same occurs of the RIGHT FIFO. The test stalls as the program expects the PWM FIFO to become empty.
#143 SH2 MASTER L -> R PAN -- incorrect playback (NOTE: test can't fail explicitly)
#144 SH2 MASTER R -> L PAN -- incorrect playback (NOTE: test can't fail explicitly)
#148 SH2 SLAVE L -> R PAN -- incorrect playback (NOTE: test can't fail explicitly)
#149 SH2 SLAVE R -> L PAN -- incorrect playback (NOTE: test can't fail explicitly)
= These tests do not play correctly in Fusion for the same reason as the previous tests. However, they don't check the EMPTY flag so they do not stall.
#152 SH2 MASTER PWM DMA WRITE -- no sound output during test (NOTE: test can't fail explicitly)
- This test demonstrates PWM playback using DMA from SDRAM to PWM FIFO. Test runs for a fixed amount of time.
= Fusion doesn't seem to deliver the DREQ1 signal to the Master SH-2. On the other hand, #153 SH2 SLAVE PWM DMA WRITE works correctly.
#160 -- no 32X display during test (NOTE: test can't fail explicitly)
- This test is a demonstration of all 32X VDP modes using midframe mode switching performed by the 68000.
= Fusion doesn't respond to midframe 32X VDP mode switching, so the display stays in blank mode.
Not included among the failures is #161, a display test which appears to attempt to match Mega Drive VDP displayed color bars to 32X VDP displayed color bars. Since I am unable to compare the results between emulator and hardware, it is unknown whether Fusion's output is 'close enough', but I'll give Fusion the benefit.
Yes, he has said that in the past but I wouldn't expect Steve to break a sweat attempting to fix a few of these errors. However, he is certainly welcome to do what he wants with Fusion; I provide these results merely as an FYI.
That said, the recently released X-Men prototype fails to run in Fusion because of a lack of SCI support. The Master SH-2 uses SCI to trigger an interrupt on the Slave, although no viable data is transferred via SCI. Of course, that is merely another FYI.
That said, the recently released X-Men prototype fails to run in Fusion because of a lack of SCI support. The Master SH-2 uses SCI to trigger an interrupt on the Slave, although no viable data is transferred via SCI. Of course, that is merely another FYI.
Re: Mars Check Program results for Kega Fusion v3.61
Well, I've been offline for a few months and just been directed at this thread, after already fixing some of this - grr.
TascoDLX, you're way too good at this shit
Now that the games all work, and this test has been confirmed to work on real hardware, I might as well go back to it.
It's a shame that all the games assume the docs are correct when apparently they aren't, but what can you do.
This one, however...
TascoDLX, you're way too good at this shit
Yup. This test disagrees with some of the docs, and what various games do. I know the hardware was being modified quite a bit during development, and I didn't know if this test was meant for final hardware. I decided to trust the games instead.Huge wrote:I recall Steve saying that Kega focuses on getting the games running, and not the hardware test roms
Now that the games all work, and this test has been confirmed to work on real hardware, I might as well go back to it.
It's a shame that all the games assume the docs are correct when apparently they aren't, but what can you do.
Pretty much, I just wasn't sure if it was correct before. You did find a couple of bugs that I seem to have created while optimising. Apparently they don't affect any games though, so I didn't noticeTascoDLX wrote:For all I know, Steve already knows about all of these specific issues
This one, however...
Nope. None of the modes are illegal, and they all work as documented. There must be some other reason for this one...TascoDLX wrote:- This test incorrectly sets the DMA transfer unit to 16-byte [4 longword]. As I understand it, this is an illegal setting because it requires longword access, which is impossible to/from the external memories of the 32X. As a result, the test reverts to a 2-byte [word] transfer unit.
Re: Mars Check Program results for Kega Fusion v3.61
Hmmm. This may require some testing. It's nearly impossible that any one of these tests transfers more than 96KB (despite being set for 512KB). But nothing seems to indicate that it shouldn't work as prescribed. I'm thinking there's some sort of timing problem, bus-related? Unfortunately I don't see a lot of possibilities here.Snake wrote:Nope. None of the modes are illegal, and they all work as documented. There must be some other reason for this one...TascoDLX wrote:- This test incorrectly sets the DMA transfer unit to 16-byte [4 longword]. As I understand it, this is an illegal setting because it requires longword access, which is impossible to/from the external memories of the 32X. As a result, the test reverts to a 2-byte [word] transfer unit.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Confirmed. Does nothing but fire continuously on real hardware with 3 button pad. If you're lucky, it will sometimes recognize pressing one of the other buttons (like the one that makes him swing the gun), but it doesn't recognize the dpad at all that I can tell.Huge wrote:Fusion 3.63 now runs X-Men proto, though it only seems to work with a 6 button pad. Using a 3 button pad will make the player constantly shoot. Can someone confirm this on the hardware?
-
- Very interested
- Posts: 273
- Joined: Fri Feb 29, 2008 8:12 pm
- Location: United States