Re: Why does POKE 56334,128 stop the cursor blinking in a PAL C64?

From: groepaz_at_gmx.net
Date: Wed, 29 Jun 2022 22:36:52 +0200
Message-ID: <2048029.BFZWjSADLM_at_rakete>
Am Mittwoch, 29. Juni 2022, 22:24:25 CEST schrieb tokafondo_at_tokafondo.name:
> I read the "Initializing TOD clock on all platforms" article in CIA section
> of codebase64, and tried the routines there to set the right value to the
> TOD clock in relation to the mains AC frequency.
>
> In the last part of the routine, there is this code
>
> [...]
>     cpy	#28		;Did 114688 cycles or less go by?
> 	bcc	:+		;- Then we already have correct 60Hz
$dc0e value
> 	lda	#$80		;Otherwise, we need to set it to 50Hz
> 	sta	$dc0e
> [...]
>
> So it could be said that with no more setup, the C64 can be booted and a
> POKE 56334,128 could be used to set the value to the 50Hz, couldn't it?
>
> The problem is that once that value is set, the cursor stops blinking and
> the keyboard stops being scanned. The computer doesn't crash or freezes
> because if an emulator is used, the $DC0E can be set back to $01 and
> everything continues working with no reset needed.
>
> WHy does it happen? Are the kernal routines hardcoded to a value that
> matches the 60Hz TOD clock, even in PAL machines with 50Hz clock?

This is no PAL/NTSC issue (and the kernal does not use TOD at all)

$dc0e also controls TimerA interrupt - and the system interrupt runs on that,
see http://unusedino.de/ec64/technical/aay/c64/cia114.htm

so in BASIC, you want to write %10000001 (129) instead

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

Physics is like sex: sure, it may give some practical results, but that's not
why we do it.
<Richard Feynman>
Received on 2022-06-29 23:01:09

Archive generated by hypermail 2.3.0.