Mars Check Program results for Kega Fusion v3.61

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Post Reply
TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Mars Check Program results for Kega Fusion v3.61

Post by TascoDLX » Wed Aug 05, 2009 10:49 am

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. ;)

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Wed Aug 05, 2009 11:13 pm

I recall Steve saying that Kega focuses on getting the games running, and not the hardware test roms (unlike other emulators), and as a consequence this test rom fails miserably on Kega (but compatibility with games is the best out of all 32x emus).

Something like that.

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Mon Aug 10, 2009 10:36 am

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. :wink:

Snake
Very interested
Posts: 203
Joined: Sat Sep 13, 2008 1:01 am

Re: Mars Check Program results for Kega Fusion v3.61

Post by Snake » Wed Sep 30, 2009 9:12 pm

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 :D
Huge wrote:I recall Steve saying that Kega focuses on getting the games running, and not the hardware test roms
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.

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.
TascoDLX wrote:For all I know, Steve already knows about all of these specific issues
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 notice :D

This one, however...
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.
Nope. None of the modes are illegal, and they all work as documented. There must be some other reason for this one...

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Re: Mars Check Program results for Kega Fusion v3.61

Post by TascoDLX » Sat Oct 03, 2009 12:15 pm

Snake wrote:
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.
Nope. None of the modes are illegal, and they all work as documented. There must be some other reason for this one...
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.

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Wed Oct 07, 2009 2:31 pm

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?

Chilly Willy
Very interested
Posts: 2767
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Oct 07, 2009 8:05 pm

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?
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.

notaz
Very interested
Posts: 191
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Thu Oct 08, 2009 11:15 am

It seems to have a minor bug in 3button controller code path, this patch fixes it:
000E76:4600

I used it for real hardware testing, as I only have a 3 button pad. Will have to patch checksum if you want to use it though.

King Of Chaos
Very interested
Posts: 273
Joined: Fri Feb 29, 2008 8:12 pm
Location: United States

Post by King Of Chaos » Thu Oct 08, 2009 9:44 pm

How's 3.63 working with the test now? Haven't had a chance to test it.

TascoDLX
Very interested
Posts: 256
Joined: Tue Feb 06, 2007 8:18 pm

Post by TascoDLX » Fri Oct 09, 2009 3:14 am

Fusion v3.63 fails 4 of 161 tests:

#127 SH2 MASTER ROM TO SDRAM (DMA)
#128 SH2 SLAVE ROM TO SDRAM (DMA)
#133 SH2 MASTER FRAME TO SDRAM DMA
#160 (32X MIDFRAME MODE SWITCH)

There are really only two issues remaining since the DMA problem is identical for those tests.

Post Reply