Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06774 Timing Minor Always Nov 24, 2017, 14:45 Nov 28, 2017, 22:26
Tester MrGW View Status Public Platform MAME (Self-compiled)
Assigned To Resolution Open OS Linux (64-bit)
Status [?] Acknowledged Driver
Version 0.191 Fixed in Version Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary MESS-specific 06774: coco, coco2, dragon and clones: Clock speed running too fast in some instances
Description The emulated behavior of the SAM/VDG is incorrect in some circumstances. It affects NTSC/PAL machines for Coco 1, 2 and Dragons.
Steps To Reproduce The following code will issue a double-speed POKE for the whole system:

10 POKE &HFFD9,1
20 GOTO 20

This will cause video screen corruption on a real Coco as the SAM/VDG can't keep up with the refresh rate. XRoar seems to emulate this correctly and you should see the following screen I've attached (screen corruption). The screen in MAME will remain unchanged and you will see the screen intact.
Additional Information This issue was discovered while developing assembly code that utilizes the Spec & Sound cartridge.
Github Commit
Flags
Regression Version
Affected Sets / Systems coco, coco2, dragon and clones
Attached Files
png file icon Screenshot from 2017-11-24 08-38-41.png (216,292 bytes) Nov 24, 2017, 14:45 Uploaded by MrGW
MrGW
png file icon sn74ls783.png (205,019 bytes) Nov 28, 2017, 22:26 Uploaded by MrGW
MrGW
Relationships
There are no relationship linked to this issue.
Notes
2
User avatar
No.14469
MrGW
Tester
Nov 27, 2017, 01:26
I'm trying to get more information from the developer, so I apologize for not describing this issue with enough detail. It has to do with the way the system wide high speed POKE works vs an address specific high speed POKE. When the developer was writing code to use the Speech and Sound cartridge, he discovered the issue. I'll follow up again soon.
User avatar
No.14475
MrGW
Tester
Nov 28, 2017, 22:26
More info from the developer (Simon Jonassen):

read the third section of the first table (from the new image I attached).
$ffd6 (clear) / $ffd7 (set) control adress dependant fastmode
$ffd8 (clear) / $ffd9 (set) control FULL fast mode
the only place you can do FULL fast without video losses is in the horizontal and vertical borders !
we sometimes use this trick to give more clock cycles per scanline
NORMAL clock speed is .89Mhz (NTSC clock / 4)
that will give you 57 cycles per scanline
fastmode will give you 114 cycles per scanline
so you can enable fastmode in a vertical border and turn it off again before you reached the visible display
mame just maintains the visible display no matter what, and that is NOT the correct behaviour !
the coco3 does NOT suffer from this malady (by design)