06774: coco, coco2, dragon and clones: Clock speed running too fast in some instances

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	trs/coco12.cpp
Version	0.191	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	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	Screenshot from 2017-11-24 08-38-41.png (216,292 bytes) Nov 24, 2017, 14:45 Uploaded by MrGW
Attached Files	sn74ls783.png (205,019 bytes) Nov 28, 2017, 22:26 Uploaded by MrGW

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.
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)

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.

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)