02-19-2011, 10:21 AM
Hello LCD
Thanks for your answer. I have discover the compiler recently and I am impressed. When I talk (with twitter) with Boriel, my main suggestion was to separate the compiler, as FreeBasic does:
1. One compiler for compatibility with Sinclar Basic (line numbers)
2. Another compiler improved, with sintax similar to FreeBasic (without line numbers)
But Boriel sad me that option 1 was no sense, because there are other proyects that are almost 100% Sinclair Basic compatible.
So my main suggestion is make the 2 option, avoiding slow FP ROM routines. Use fixed point instead, there are some algorithms <!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/CORDIC">http://en.wikipedia.org/wiki/CORDIC</a><!-- m --> than are focused in hardware without arithmetic multiplier.
About the double buffer, my idea was make it transparent to the user. So for example you write Circle 100, 100, 10, and the compiler writes the circle in the back buffer, and flip the buffers when completes, avoiding flickering.
Thanks for your answer. I have discover the compiler recently and I am impressed. When I talk (with twitter) with Boriel, my main suggestion was to separate the compiler, as FreeBasic does:
1. One compiler for compatibility with Sinclar Basic (line numbers)
2. Another compiler improved, with sintax similar to FreeBasic (without line numbers)
But Boriel sad me that option 1 was no sense, because there are other proyects that are almost 100% Sinclair Basic compatible.
So my main suggestion is make the 2 option, avoiding slow FP ROM routines. Use fixed point instead, there are some algorithms <!-- m --><a class="postlink" href="http://en.wikipedia.org/wiki/CORDIC">http://en.wikipedia.org/wiki/CORDIC</a><!-- m --> than are focused in hardware without arithmetic multiplier.
About the double buffer, my idea was make it transparent to the user. So for example you write Circle 100, 100, 10, and the compiler writes the circle in the back buffer, and flip the buffers when completes, avoiding flickering.