- --
Viewing Issue Advanced Details
ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
---|---|---|---|---|---|
02843 | Original Reference | Minor | Always | Jan 18, 2009, 17:08 | Jan 29, 2009, 09:22 |
Tester | chowell | View Status | Public | Platform | MAMEUI |
Assigned To | Resolution | Fixed | OS | ||
Status [?] | Resolved | Driver | |||
Version | 0.129 | Fixed in Version | 0.129u3 | Build | Normal |
Fixed in Git Commit | Github Pull Request # | ||||
Summary | 02843: schaser, schasercv, polaris: Only half the color RAM is emulated. | ||||
Description |
(I see that this game has the GAME_IMPERFECT_COLORS flag, which might refer to the problem described here, but there is no sign of any specific source comment or existing bug related to this.) The program address map for Space Chaser, schaser_map, shows that the color RAM area (0xC000-0xDFFF) only uses 10 of its address bits: it's an 8K region, but the use of AM_MIRROR(0x00E0) means that 3 address bits are mirrored. Likewise, the video update functions for both Space Chaser versions, schaser and schasrcv, address the color RAM with a mask of 0x1F1F, so the 3 mirrored address bits are masked out. Thus only 1K of color RAM locations are being used. Taito's service manual for Space Chaser can be found here: http://www.arcadedocs.com/vidmanuals/S/SpaceChaser.pdf This manual lists two different motherboards, RTN00003 and RTN00005. The schematics, layout diagrams, and parts lists for both motherboards all show that the color RAM is provided by two type-2114 1K x 4-bit RAMs. 11 address bits are sent to the two RAMs; the uppermost of these bits is the chip select signal. Of the 4 output bits from the color RAM, one is dropped; that aspect is consistent with the emulation. From examining both schematics (pages 11 and 12 of the PDF), the difference appears to be bit 5 of the color RAM's address, whose input comes from 4V'/AD7 in both cases. (You have to be careful when examining the RTN00003 schematic on page 12, because the signal naming and routing appears to be obfuscated, but the correspondence turns out to be the same.) Thus the schematics show that CPU address bit 7 is used for the color RAM; this bit is being ignored in MAME. Based on this, I would suggest changing the color RAM's AM_MIRROR to 0x0060 and the color RAM's address mask in the video update functions to 0x1F9F. Unfortunately, I don't have a working build system at the moment, so I can't test this change myself. (Since bit 5 of the color RAM's address comes from signal 4V' during raster scanout, one might expect color artifacts that show up on 4-scanline boundaries.) |
||||
Steps To Reproduce | |||||
Additional Information | schasrcv -> schasercv in 0.133u1 | ||||
Github Commit | |||||
Flags | Verified with Original | ||||
Regression Version | |||||
Affected Sets / Systems | schaser, schasercv, polaris | ||||
Attached Files
|
|||||
Relationships
There are no relationship linked to this issue. |
Notes
4
No.03605
Tafoid Administrator
Jan 18, 2009, 19:29
|
Good observations and findings. I'll acknowledge this in hopes someone from DEV will step up to use this information. Thanks for the informed contribution. |
---|---|
No.03607
chowell Developer
Jan 19, 2009, 06:20
edited on: May 17, 2009, 19:36 |
After finding a manual with schematics for Polaris: http://www.arcadedocs.com/vidmanuals/P/Polaris.pdf I found that it uses the same color RAMs as Space Chaser, with the same addressing scheme. Likewise, MAME addresses the Polaris color RAM just as it does for Space Chaser, so the same flaw is present. (The Polaris color RAM schematic is present on page 11 of the PDF. Note that the CPU board layout on page 8 of the PDF is even labeled "T.T. Space Chaser", implying that both units used the same CPU board; this board holds the color RAMs.) I am thus adding polaris to the ROMsets for this bug. I wonder if this bug also affects lupin3 and sflush, since all of these games appear to use the same color RAM hardware. However, I do not have a schematic to confirm this. (Page 15 of the PDF helps to give me the impression that Lupin III used the same motherboard as Polaris, since the two games seem to have used the same daughter board with only the ROMs and jumper wires changed. This doesn't support my supposition for Straight Flush, though, since it had a different CPU and obviously used a different motherboard.) I think the following bug already filed against Polaris may be related to this: http://mametesters.org/view.php?id=2695 |
No.03675
chowell Developer
Jan 28, 2009, 19:22
|
Forgot to mention one other game which might also be affected by this bug: rollingc, which seems to use the same color RAM as the Taito games. |
No.03689
aaron Developer
Jan 29, 2009, 09:22
|
(credit chowell) This is confirmed and fixed. Does not apply to rollingc, interestingly. The rollingc code does not initialize the extra bit of RAM, thus creating obvious incorrect artifacts. The other games appear to set things up properly. |