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
Tester Richard42 View Status Public Platform
Assigned To tlindner Resolution Fixed OS
Status [?] Resolved Driver
Version 0.147 Fixed in Version 0.232 Build 64-bit
Fixed in Git Commit a068ff3 Github Pull Request #
Summary MESS-specific 05138: coco, coco3: strange behavior when initializing PIA interface chip
Description 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
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems coco, coco3
Attached Files
 
Relationships
There are no relationship linked to this issue.
Notes
6
User avatar
No.09313
Tafoid
Administrator
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.
Thank you.
User avatar
No.09314
NekoEd
Senior Tester
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.
User avatar
No.09331
Robert Gault
Tester
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).
User avatar
No.09339
Richard42
Tester
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.
User avatar
No.18856
tlindner
Moderator
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.
User avatar
No.18864
tlindner
Moderator
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