08993: lhb, lhb2, lhb3, tygn, xymg: Text not drawn correctly in service mode

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
08993	Graphics	Major	Always	Dec 5, 2024, 18:20	13 hours ago

Tester	cuavas	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows 10/11 (64-bit)
Status [?]	Confirmed			Driver	igs/igs011.cpp
Version	0.272	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	08993: lhb, lhb2, lhb3, tygn, xymg: Text not drawn correctly in service mode
Description	Solid rectangles are drawn in place of some characters in service mode, and some characters may incorrectly have coloured backgrounds. The exact colour of the rectangles seems somewhat random, but the characters never seem to be drawn correctly. For example in the lhb2 DIP switch display, one character is not drawn in the description for SW1.4, two characters are not drawn in the description for SW1.8, none of the four characters are drawn in the description for SW2.7, three characters are not drawn in the description for SW2.8 (should be “示範音樂” but only “音” is drawn correctly), and three characters are not drawn in the description for SW3.1-SW3.2. Several settings are not displayed correctly, either.
Steps To Reproduce	1. Start lhb2 and let it pass the ROM check 2. Press the test button (F2) to show settings 3. Observe the incorrect display
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	lhb, lhb2, lhb3, tygn, xymg

Attached Files	0002.png (5,974 bytes) Dec 5, 2024, 18:20 Uploaded by cuavas
	0003.png (5,996 bytes) Dec 5, 2024, 19:25 Uploaded by cuavas
	0000.png (3,973 bytes) Dec 5, 2024, 20:22 Uploaded by cuavas xymg settings display with missing characters

No.22535 cuavas Administrator Dec 5, 2024, 20:27	lhb and xymg are also affected, but they seem to always display black squares in place of characters making it less obvious if you can’t read Chinese. The attached xymg screenshot shows missing characters in what should be “投幣比率”, “開分比率”, “進分上限”, “進分方式”, “比倍爆機” and “最小押注”.
No.23250 cuavas Administrator 8 days ago	I debugged this a bit with lhb2. It isn’t an issue with the screen update function or the blitter emulation – it goes wrong before that. While processing the text for the screens in question, the game code seems to get confused and calls a function at 0x001b1a that draws a solid rectangle by using direct CPU layer access rather than the function to blit a character. Another kind of odd thing – the rectangles aren’t drawn to the layer that the text would be: The rectangles replacing text in the setting names are drawn to layer 0 while the text is drawn to layer 3. The rectangles replacing text in the setting values are drawn to layer 2 while the text is drawn to layer 0. Is the layer memory being addressed correctly for direct CPU access? It’s obviously drawing to the correct location within the layer, but it’s a bit surprising that it isn’t drawing to the layer where the character the rectangle replaces is.
No.23255 Haze Senior Tester 8 days ago	is it interrupt timing? the IGS stuff is kinda sensitive to that and we've seen plenty of other cases are partial / bad spritelists when the IRQ timing is off.
No.23259 cuavas Administrator 7 days ago	It could well be interrupts happening when it doesn’t expect. I tried adjusting the screen timings to be closer to the measurements for nkishusp (260 lines total, 1282µs vertical blanking interval) but it didn’t help. I’m not really sure what to adjust, it only has two interrupt sources hooked up – vertical blanking and a 240 Hz timer that sets sound/animation tempo.
No.23268 cuavas Administrator 1 day ago edited on: 1 day ago	After more debugging, the draw list is coming from ROM. For example, here’s the display list for the right column of setting names in lhb2cpgs starting at 0x01eada in ROM – each byte is one character, four characters per line, 0xff is a space: 1D 09 0D 2C 02 11 0D 2C 33 11 34 36 33 11 3D 3E 08 11 3D 3E 81 82 83 84 85 86 21 87 Interestingly, all the values that it’s getting upset with have the high bit set. Now there’s a small possibility that the program ROM is being unscrambled incorrectly, but that’s kind of unlikely given the program isn’t crashing all over the place. Also note that the same characters fail to get drawn in multiple places, e.g. 自動 isn’t drawn in both “自動清除” in the left column and “自動摸打” in the right column. So I suspect something is going wrong with characters that need the high bit set. (A quick investigation suggests valid characters without the high bit set run from 0x00 to 0x4f, and the correct characters cannot be found in that range.) It handles characters with and without the high bit differently – the code for drawing a right column names starts at 0x05029a for lhb2cpgs. If the high bit is set, it does the following (character in D4, line in D2, column in D3): push long(D4 & 0x7f) push long(0) push long(0x6af6) push long(0) push long(3) push long((D2 * 20) + 30) push long((D3 * 16) + 265) call 0x1ae8 If the high bit is not set, it does the following: push long(D4) push long(0) push long(0x6aee) push long(0) push long(3) push long((D2 * 20) + 30) push long((D3 * 16) + 265) call 0x82a It’s obviously setting up blit parameters and calling a function. The third argument and the function it calls are different for characters with and without the high bit set.
No.23269 cuavas Administrator 1 day ago edited on: 1 day ago	BTW the consecutive values aren’t a warning sign. This is common for games that contain a relatively small set of Chinese characters. The characters are assigned code points in the order they’re used when the character set is compiled, so when you find the first string to use certain characters, you’ll see ascending values. For example “自動摸打” is the first string using these characters, so they’ve been assigned code points 0x81, 0x82, 0x83 and 0x84, then “示範音樂” is the first string to use 示, 範, and 樂, so they’re assigned code points 0x85, 0x86 and 0x87, but 音 was already used in an earlier string (probably in the sound test) and assigned code point 0x21 at that point.
No.23270 cuavas Administrator 1 day ago	The things at 0x6aee and 0x6af6 seem to be tile list descriptors of some kind. The first two words are the width and height (minus 1) – the first thing it does is read them, add one to each, and call a function to multiply them. The third and fourth words might be the address in blitter memory?
No.23271 cuavas Administrator 1 day ago	Just throwing ideas out there – by enabling the debug graphics decode device, I could find the “high bit clear” character set pretty easily in the decoded graphics (towards the end of the first tile set), but I couldn’t find the “high bit set” ones. Maybe those characters are drawn from program ROM, and it actually is an issue with video RAM addressing from the CPU?
No.23272 cuavas Administrator 13 hours ago	The video RAM addressing is wrong, but it gets nastier. The hardware supports a mixture of 8-bit and 4-bit layers, and they’re accessed differently. 4-bit layers are nybble-interleaved It keeps the number of 8-bit layers in RAM, and draws differently depending on whether the destination is a 4-bit or 8-bit layer.