Can I have 9kB if I enter nine times?

A project log for PIC Graphics Demo

Generate 640x480 64-color VGA graphics with an 8-bit PIC and an SRAM framebuffer

Ted YapoTed Yapo 01/05/2017 at 01:354 Comments

I got the ray-tracer to fit - into the PIC, anyway. At 8473 bytes, it's way over the 1kB limit, unfortunately. The good news is that this is without any serious attempts at size optimization - it's using the free XC8 compiler's native 24-bit floating point in pure C, and it was written more for simplicity than compactness. I figured once I got it working, I could start cutting corners to make a version fit.

The bad news is that since this thing is going to take so long to run, I need to start running the code I have if I want a chance at it finishing before the contest deadline - my rough estimates put it at 8 hours, but it could be twice as long or more. So, I kicked it off a few minutes ago.

So, it won't be in 1kB, but I might get a ray-tracer on an 8-bit PIC in true VGA resolution. In some universe, that's worth doing anyway :-)

I'll post an image when it appears. I uploaded the code already - you can see that it could use some serious optimization.

The one issue I had was that the XC8 compiler doesn't support recursive functions, which make ray tracing so much easier. I had to convert to an iterative approach. I've written four (or maybe five) ray tracers of varying complexity for different applications (graphics / optics / solar concentrator design) since the late 1980s, but I think this was the first time I couldn't use recursion. It was a neat little twist.


Yann Guidon / YGDES wrote 01/05/2017 at 14:47 point

The PIC16F don't have a nice stack, unlike most other architectures...

You can "cheat" but that takes a lot of code space.

  Are you sure? yes | no

Ted Yapo wrote 01/05/2017 at 16:18 point

Yeah, I've dealt with the PIC stacks for a long time, even down to the two-level, "closed" versions.  The PIC16F1718 has a 16-level hardware stack, which would be plenty for this code, and even then, you can read and write the top-of-stack, so the C-compiler doesn't even have to use the h/w stack if it doesn't want to - it could just push return addresses onto the data stack, then load them back onto the h/w stack when required.  Of course, it costs cycles and instructions, but the whole point of C is sacrificing code efficiency for programmer efficiency.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/05/2017 at 16:32 point

this reminds me that I had written a tiny RTOS for PIC16F and it was UGLY... Maybe I should publish it here ? ;-P

  Are you sure? yes | no

Ted Yapo wrote 01/05/2017 at 16:34 point

@Yann Guidon / YGDES sure.  I publish all my ugly projects :-)

  Are you sure? yes | no