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)|
|Version||0.191||Fixed in Version||Build||64-bit|
|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.|
|Affected Sets / Systems||coco, coco2, dragon and clones|
Screenshot from 2017-11-24 08-38-41.png (216,292 bytes) Nov 24, 2017, 14:45 Uploaded by MrGW
sn74ls783.png (205,019 bytes) Nov 28, 2017, 22:26 Uploaded by MrGW
|There are no relationsihp linked to this issue.|
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.|
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)