> On 2017-09-02, at 15:54, smf <firstname.lastname@example.org> wrote: > > On 02/09/2017 13:42, email@example.com wrote: >> It might be the simplest/safest but it would affect everything. Things would run differently, look differently, sound differently, etc. That's not something I would be happy with. > If you adjust the c64 system clock then everything inside the c64 would run the same. 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. > They should look identical Should they if you change pixel clock? What with software that needs accurate wallclock timers based on counting clock cycles? What with software that actually requires accurate sound frequency? The goal is to have two machines next to each other, where they behave the same in all aspects except one: the modified gives a clear picture on modern equipment, which deals well only with standard compliant, interlaced signal. > , which is different to how a c64 should look. Interlaced, with frames running at a slightly different rate. I might again be missing something (like the previous time) but frames would have to run at the same rate. Only invisible portions of fields would need to be affected. Hm.. I guess that's again the same situation - can't really be done. > [...] It's better to keep the signal progressive and using the same timing as the c64, vga and hdmi should allow it. 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. Moving the output into VGA/HDMI is a different project. Also worth having a look at but possibly not so challenging ;-) > Although that can still depend on the TV. Deinterlacing will definitely make it look different. There are lots of ways to deinterlace, because none of them work well and they use heuristics to decide which one to use at various times. This was out of scope of this. It would be up to the receiving end to do its best, the same it does with all the regular video. Some do good, some bad, and some terrible job there. >> As long as it is kept stable and in sync with the original, VIC generated clock there shouldn't be any, should there be? > If vic doesn't freak out then it will change vblank timing in relation to the cpu, sid & cia. I can't see how that won't affect something. Academic now again as we haven't even tested if the VIC can be pushed that far plus it seems that I again entered a dead-end path with the actual framerate. So your approach would be in fact better in the sense that more likely possible to realise but OTOH not fulfilling the original objectives. -- SD! - http://e4aws.silverdr.com/ Message was sent through the cbm-hackers mailing listReceived on 2017-09-02 17:00:03
Archive generated by hypermail 2.2.0.