> On 2017-09-02, at 19:31, smf <email@example.com> wrote: > > On 02/09/2017 17:09, firstname.lastname@example.org wrote: >> Depends how we define "the same" and "differently". The machine would not "notice" anything. But its relations with the outside world would change in many more, and unwanted areas than in the case when the master clock remains unchanged. And that one area, which would change is actually the goal here. > Anything not synchronised from the c64's clock is free to drift anyway. Sure. But it would be phase locked and unchanged for most of the time and only halved/doubled for less than 1% of it. >> Should they if you change pixel clock? > If you're buffering the line you are free to output at whatever pixel clock you want. I'd still need to remain in sync with what VIC generates. Meaning it's not really whatever I want, right? I can theoretically output it faster but can't output it slower than the VIC. And I wouldn't want to adjust that by cropping/extending border. The output has to show every pixel the VIC generates. >> What with software that needs accurate wallclock timers based on counting clock cycles? > Is that possible? I thought that was why the tod clock was run from the power supply frequency. It is. The same as with sound - when you need higher accuracy you count cycles rather than using TOD. And TOD is not always driven with power supply frequency. And mains frequency is also far from being reliable in the short run. >> The whole idea was about making the output "standard compliant" so that any composite/s-video equipment could accept such output without freaking out as it happens most of the times today. > What equipment is compelling to use with composite? > > If you just need interlaced you could probably buffer an entire field and squeeze an extra half line in at the end and keep the vsync time the same. How? VIC will be generating next field in the time I'll be outputting extra half-line. > It would add latency, which may or may not be a problem. I could buffer the whole frame but that adds latency, which is one of the major drawbacks of those converters that output something palatable when fed the signal from a 64. -- SD! - http://e4aws.silverdr.com/ Message was sent through the cbm-hackers mailing listReceived on 2017-09-02 19:03:57
Archive generated by hypermail 2.2.0.