On 2014-02-23 21:00:02 +0000, Paul Förster said:
> ok, some delay in the thread on my part. :(
NP.
>>> what do you mean by "older" version? Is there a "new" version? ;-)
>> Yes, even two ;-)
>
> is there a way to make you post an update here? ;-)
Provided that I finish that - sure.
>> Actually I set it always to 50Hz. Just to save on bytes - I have always
>> the same setting, no matter what the video norm is and don't have to
>> account for it later on.
>
> ok, I see. You only correct it later in the routine if needed. After
> all, it need some initial setting, even if it was the wrong one.
Exactly. If it's the right one - leave it. If it was wrong - change it.
It doesn't matter which one you choose for the start. I chose 50
because statistically in my location this one should be more often
correct AND because it supposedly requires less time/code to get
accurate readout.
>> Yes, actually count full rasters to be precise.
>
> what do you mean by full rasters?
Hm - full raster is a full raster ;-) How should I explain this? That's
one full set of all rasterlines that the machine is capable of
generating. All visible and all invisible rasterlines. Or, in other
words, a number of rasterlines, after generating which the machine
returns again to line #%000000000 (note the nine bits - ninth, #8 is
visible in SCROLY. #0-#7 are visible in RASTER register).
> Is there a way to see if a raster line is drawn only to a specific
> position so I could, in theory, manipulate one single arbitrary
> position on screen in a different graphics mode for example even if the
> graphics mode before and after that position is different? Just
> curious...
I am not sure what you mean. If I understand correctly, you just
invented "raster effects" ;-) All raster effects are based on
manipulating what the machine displays at specific position of the
screen (aka raster). But that seems somewhat too obvious so I am not
sure if I understood the question correctly.
>>> What I don't understand is that this still sets the CIA frequency in
>>> relation to the number of raster lines counted,
>>
>> No, it doesn't. Initially it sets it to 50Hz, regardless of the video
>> norm. Later on it doesn't relate the set frequency to the video norm
>> either.
>
> this is the point I just don't get. You count rasters which are video
> norm dependent but yet you don't relate to the video norm.
Contrary to the popular belief, computer's video norm is completely
unrelated to TODTICKS frequency. That's the whole point of the code I
posted, and this discussion from the very beginning (of my
involvement)! Those are two unrelated variables. And I don't relate
them in any way either. I use the video norm NOT to set the CIA's TOD
parameter but to get a reliable external timer resource. I need to
measure a predefined amount of time and I need a trusted resource. VIC
can give me the CIA independent timing information and it does.
Initially I don't know whether it generates 50 or 60 full rasters per
second though. This is very similar to the fact that I don't know
whether CIA's TOD is being fed with 50 or 60 Hz TODTICKS frequency. But
unlike with CIA, with VIC I can verify if it (VIC) runs 50 or 60 Hz
(even if it is different than what CIA runs on). That's where the video
norm verification comes in handy: no matter what else, PAL VIC will
generate 50 rasters per second and NTSC VIC will do 60 so I can always
get the accurate one second I need to check TOD's accuracy.
> I'd love to see CPU cycle counting code which would take the VIC
> stealing cycles into account without disabling the screen. :)
You can possibly do this for a specific application but for a generic
one - no... I wouldn't even try ;-)
> and how did Commodore make sure that the TOD did not run too fast in
> PAL country on an SX-64 then?
Actually (I haven't checked the SX's KERNAL for that but) I believe
that SX TODs runs always accurate after power-up. The most problems are
with regular 64s being run in PAL countries. Regular 64s derive
TODTICKS frequency from the mains frequency (which happens to be 50Hz
in PAL countries) and CIAs are initially set to 60Hz. So - to answer
your question - they ensured the accuracy of SX-64 TODs by both
initialising CIAs to 60Hz AND supplying always 60Hz, regardless of the
mains frequency. They didn't do the same in regular C64/128s though.
>> RESTORE is not the only source of NMIs. Yes, you should. To be on the
>> safe side. Especially that the number of microseconds you have a chance
>> to get NMI is slightly above 1000 ;-) But in any case you don't want to
>> enter /any/ race condition. AFAIR that's one of the enhancements I did
>> in the "newer" version.
>
> please post. :) Setting the NMI vector to point to an rti is trivial.
> Did you do anything else?
AFAIR no. And I can't now recall any other method that would handle
/all/ NMIs better. True, it still leaves a chance to skew the results
if the NMIs happen fast enough but at some point one has to learn the
difference between possibility and probability and only account for
what is probable unless there is a feasible method to cover all cases
;-)
>> You did well :-) Hope I cleared the remaining parts. Did I? Please let me know.
>
> I'm not 100% sure yet. At least I hope I finally got the concept that
> you measure the time taken to pass a predefined number of rasters
> rather than the other way around as I initially thought would be the
> case.
Yes, that's the case here. The other method I wrote of is supposed to
do the opposite: get one TODTEN (the lowest TOD granularity) and see
where your rasterbeam is after that.
>> P. S. Maybe this thread will eventually motivate me to finish the other
>> version of the routine... ;-)
>
> yes, I hope so too. :) After all, this is quite interesting. You
> probably noticed on the TC64 mailing list
TC64 mailing list? I don't think I attend it. Need to check what and
where it is.
> that I did the RTC read/write code there. That's also why I asked for a
> way to set TI/TI$ in another thread here. The idea and code you
> provided are included in that code to also set the TOD properly on any
> system, not only the TC64, to keep the code more flexible.
As I wrote some time ago - I myself got badly bitten by this buggy
approach of checking video norm in order to initialise TOD. And I never
noticed the problem until people started using the program on real
hardware in various parts of the globe rather than on VICE where the
same thought path has been used: the emulated TODTICKS frequency is
chosen according to what the video norm is selected (arrghhh...)! Since
then I check it always properly rather than ass-u-me ;-)
--
SD!