Adventures in small code
-
I have 32KB of flash, and 2.5KB of RAM. I have one 128x32 monochrome screen. Over half that flash, and I don't know how much RAM is taken up by keyboard firmware. In what's left over some friends and I are making a Tamagotchi game. Talk about tricky. Now normally, to dynamically draw to a monochrome screen without readback capability, you have to hold a framebuffer, which takes 512 bytes in this case. We didn't want to use that RAM. The method we're using is to embed RLE compressed entire screens in the screen's native framebuffer format. That way we don't need any RAM at all to display a screen as it just spits the entire screen from flash. The RLE compression in my tests shrinks the final image size to about 1/3 of the size. Each screen, uncompressed is again, .5KB. Not sure if we'll be able to do it still, but it's fun.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I have 32KB of flash, and 2.5KB of RAM. I have one 128x32 monochrome screen. Over half that flash, and I don't know how much RAM is taken up by keyboard firmware. In what's left over some friends and I are making a Tamagotchi game. Talk about tricky. Now normally, to dynamically draw to a monochrome screen without readback capability, you have to hold a framebuffer, which takes 512 bytes in this case. We didn't want to use that RAM. The method we're using is to embed RLE compressed entire screens in the screen's native framebuffer format. That way we don't need any RAM at all to display a screen as it just spits the entire screen from flash. The RLE compression in my tests shrinks the final image size to about 1/3 of the size. Each screen, uncompressed is again, .5KB. Not sure if we'll be able to do it still, but it's fun.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I have 32KB of flash, and 2.5KB of RAM. I have one 128x32 monochrome screen. Over half that flash, and I don't know how much RAM is taken up by keyboard firmware. In what's left over some friends and I are making a Tamagotchi game. Talk about tricky. Now normally, to dynamically draw to a monochrome screen without readback capability, you have to hold a framebuffer, which takes 512 bytes in this case. We didn't want to use that RAM. The method we're using is to embed RLE compressed entire screens in the screen's native framebuffer format. That way we don't need any RAM at all to display a screen as it just spits the entire screen from flash. The RLE compression in my tests shrinks the final image size to about 1/3 of the size. Each screen, uncompressed is again, .5KB. Not sure if we'll be able to do it still, but it's fun.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
If you are fascinated by small code in general, take a look at the videos at https://www.pouet.net/[^]. One extreme example: Oscar's Chair[^], an executable of 4092 bytes, encoding a video/sound of about two minutes. Certainly, this code doesn't run on bare iron, but relies on Windows drawing and sound primitives. At runtime, it unpacks to a lot more than 4K of RAM - but the unpacking code fits in those 4092 bytes, along with everything that is specific to this movie of graphics and sound. It is really an impressing piece of work! You can find several other 4K videos (executable size, not line resolution!) at www.pouet.net. I also like Skyline[^]. Clicking at "4k" near the top right on the pouët page takes you to a long list, where you also can select other sizes, platforms and categories. They are not all for Windows.
Religious freedom is the freedom to say that two plus two make five.
-
I have 32KB of flash, and 2.5KB of RAM. I have one 128x32 monochrome screen. Over half that flash, and I don't know how much RAM is taken up by keyboard firmware. In what's left over some friends and I are making a Tamagotchi game. Talk about tricky. Now normally, to dynamically draw to a monochrome screen without readback capability, you have to hold a framebuffer, which takes 512 bytes in this case. We didn't want to use that RAM. The method we're using is to embed RLE compressed entire screens in the screen's native framebuffer format. That way we don't need any RAM at all to display a screen as it just spits the entire screen from flash. The RLE compression in my tests shrinks the final image size to about 1/3 of the size. Each screen, uncompressed is again, .5KB. Not sure if we'll be able to do it still, but it's fun.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Wow, you managed to outclass me, I have 128kB of flash and 6 kB of RAM!
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Did you abandon the monster CPU? Indeed it looks fun. :thumbsup: Enjoy!
"In testa che avete, Signor di Ceprano?" -- Rigoletto
Nah, this is just a separate thing.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Wow, you managed to outclass me, I have 128kB of flash and 6 kB of RAM!
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
How luxurious!
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Wow, you managed to outclass me, I have 128kB of flash and 6 kB of RAM!
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
I have 32KB of flash, and 2.5KB of RAM. I have one 128x32 monochrome screen. Over half that flash, and I don't know how much RAM is taken up by keyboard firmware. In what's left over some friends and I are making a Tamagotchi game. Talk about tricky. Now normally, to dynamically draw to a monochrome screen without readback capability, you have to hold a framebuffer, which takes 512 bytes in this case. We didn't want to use that RAM. The method we're using is to embed RLE compressed entire screens in the screen's native framebuffer format. That way we don't need any RAM at all to display a screen as it just spits the entire screen from flash. The RLE compression in my tests shrinks the final image size to about 1/3 of the size. Each screen, uncompressed is again, .5KB. Not sure if we'll be able to do it still, but it's fun.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix