Hello,
I wanted to write something for GlassOS, and figured that AHelper could use some more demo programs, so I made a Conway's Game of Life simulator. Here's the screenie:


It's slow as hell, cause it's written in C, but it works.

^_^

It really is quite horrendously slow. I'm not sure who's to blame - the program itself or the C get/setpixel routines AHelper wrote when the assembly ones I wrote didn't work. It probably wasn't helped by the fact that I don't actually know C, either (writing this program was a combination of guesswork and help from AHelper)

If the program was written so the pixels are stored per byte, then the update code would move faster as it would not have to do any bit code.

So GlassOS is something programs can already be written for? I am so outdated, nice job SirCmpwn.

The OS is ready to be programmed for. The only issue is that it may not be safe to put on a calc. So why program for it? It's the only way I can find bugs in the OS code. Programs written for GlassOS must be included in the .8xu file and has to be included in the Launcher code, but as you can see, there are already 5 programs that run in GlassOS.

Islands is the program doing heavy testing/development on a gfx library and has already improved the key buffer code.

I might rewrite this today to work faster with full byte-ness. I'll probably just write my own buffer->screen routine that uses full sized bytes.

That would take 6,144 bytes of RAM, which seems prohibitive, but I guess that GlassOS is designed to give programs a full page of RAM regardless of what they need anyway. So what did we decide is making this so, so slow? Is it SDCC's fault?

Another faster gol on ticalc.org uses 14K of extra RAM . (Extra RAM page, not just extra RAM)

I blame SDCC not being able to optimize the bit grabbing. Doing it by bytes will work better

Who wrote that particular Game of Life clone? AHelper, that's the value of doing hand ASM programming. Out of curiosity, could the code that does the generation N+1 calculation from generation N in the 768-byte buffer be inline ASM?

Sure, the buffer address pointer can be accessed like
Code:

The blame is partially SDCC, partially my lack of care with coding this. It uses two screen buffers and does pixel testing to perform the logic, and could be signifigantly optimized. Remember that this isn't AHelper's fault, because I wrote (1) this game of life program and (2) the assembly versions of the (get/set)Pixel functions that didn't work (thus forcing them to be C until such a time I can fix the asm versions).

Yeah. If you do a 2D array in C for the pixels, then you will be in a good place as SDCC does that much better (as the tilemapping engine is written in C and isn't slow)

Heh, i notice that on a real calc, the screen loads a bunch of random pixel data in the form of a border... I guess that an array is the best choice right now still (as memory GlassOS has)

You should try fixing those asm functions... I am without ones until i stop being lazy and write ones

Yeah, I'll write some soon. I'm a bit busy.

If you need help writing pure ASM versions, you are more than welcome to ask us for help. I might be misunderstanding you, though.