Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|05138||Core||Minor||Always||Feb 8, 2013, 15:24||May 20, 2021, 15:25|
|Version||0.147||Fixed in Version||0.232||Build||64-bit|
|Fixed in Git Commit||a068ff3||Github Pull Request #|
|Summary||05138: coco, coco3: strange behavior when initializing PIA interface chip|
This bug can be observed by typing the following after starting up the emulator in BASIC:
POKE &HFF23,&H38:POKE &HFF22,&HF0:POKE &HFF23,&H3C:SOUND 1,100
This code initializes the Port B control and data direction registers of the 2nd 6821 PIA chip (labeled IC4 / 68B21 on the Coco3 schematic). It shouldn't do anything at all; it just initializes them to their defaults. The sound statement is just there to insert a delay before the coco BASIC resets the screen.
So the bug is that during the sound delay, the screen goes into some coco 2-style graphics mode while running this in MESS. It does not do this on my real coco 3; it stays in the 32-column text mode during the delay. Removing the second POKE statement ($FF22) will result in the expected behavior, so this appears to be the source of the problem. Could it be that this memory address which is reserved for the PIA is also being routed to the VDG? I have not tested the coco1/2 system under MESS to see if the problem also appears there.
|Steps To Reproduce|
|Affected Sets / Systems||coco, coco3|
|There are no relationship linked to this issue.|
Feb 8, 2013, 20:31
In the future, please test against the most recently released binary available (0.148 in this case) before making a bug report.
Feb 8, 2013, 22:20
|If you could, run all the test cases you can think of (using MESS 0.148) and report all the results. The more good information we have the better.|
Feb 11, 2013, 05:04
Same thing in MESS 0.148.
I believe I know what is happening in terms of hardware emulation. $FF22 controls video in bits 3-7. If you change change $FF22 to the data direction mode, the bits 3-7 should not alter the video when changed but that happens with MESS.
The POKEs changed the value of bit 3 CSS in $FF22. Do that on a real Coco3 and the video will change if that bit is an OUTPUT. However, with $FF23 bit 3 set to 0 $FF22 bit 3 became an INPUT with the above POKEs and when "data direction" was turned off, CSS should not have changed as it was an INPUT (RGB monitor sensing).
Feb 12, 2013, 07:04
|From the schematic in my tandy 512k coco 3 service manual, it seems that the port B I/O pins for bits 4-7 are not connected to anything. PB3 is connected to pin 10 of the RGB connector, and from the schematic it looks to me like the only possible use for this pin would be to detect if an RGB monitor was connected or not. As such, it should be an input (low bit in DDR register), and it seems to me that this is an error in the BASIC ROM that it sets it to be an output. This is why I used a DDR register value of $F0 even though both MESS and a real Coco use a default value of $F8. This doesn't have any impact on this bug report, however. Even if you set the DDR register to $F8 instead of $F0, you can observe the incorrect MESS behavior.|
May 19, 2021, 02:30
|I think this is a valid bug, but not likely to be fixed. The VDG emulation inside the real GIME is gated by the CoCo 1/2 compatibility mode (bit 7 of FF90). I think on real hardware being in CoCo 3 mode invalidates these changes to the VDG. But in MAME, the GIME emulation uses the VDG emulation to do it thing. Having the VDG check for the presence of the GIME CoCo 3 mode to turn off features seems like a step too far.|
May 20, 2021, 01:16
It seems the pull request I made for bug #7512 also fixes this issue.
Fixed in GitHub pull request 8078. https://github.com/mamedev/mame/pull/8078