yep i pick that up in the busy routine , commenting out that part is ok at 32mhz , but i did defined variables on data pins for bit , 0 and 1 to try it , setting a check counter on the when the busy is retried , it rarely used is at 32mhz , but at 64mhz its always retrying the busy check , clearly its unable to access this Lcd at 64mhz and the busy routine is always retryed , but increasing then send routines pause's does not help, thats got me stumped


i have found setting the pause to 2us in the send/ busy routines , helped with the artifacts , with the cpu running at 32mhz, any less seem to introduce artifact to the large fonts at some point

this lib is a not bad a s base , but i finding more to rewrite in it as i go further forward, so far i have rewriten section on the FS use , initiation , puting a byte in the graphics area, adding area info to graph home , and then using it , which has helped , but , getting a speed increase so that the 1/100 sec timer number are blur is not happening with the large fonts , it intern it slow the smaller normal fonts down on refreash . i think if i can get the thing to run at 64mhz and not introduce more delays in doing so may be the anwer , in the end need the system to run at 64mhz for other processes



I am using a for , next loops for x, y data that brings in a lookup table of the 90 odd bytes per char , each byte then is placed on the screen x first ,

the fonts" file is then included as a seperate file at a compile time , could not think of any better way to go about this , this file also included 240x 64 banners etc

am sure that its slowing things down as it has to go lookup the 90 bytes then put them on the screen then change it all for each chr , but i dont know any better way to do it , i am wish i could put in faster !!!


cheers

sheldon



yes as i loom further at the lib there is unused code in there , but for the most part it works