> X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.
I just opened up "clocktab.com" on Chrome, the first simple clock I could find by googling "clock," and Chrome's task manager shows it using a full 42 megabytes of memory.
Found a pocket calculator / timer in a drawer the other day. That thing is probably not even measured in kB. And also run with 4 thumbnail size solar tiles.
Yes, these are hard-wired logic and just a handful of bytes for two to four registers (at least input and accumulator registers, everything in BCD). Only more advanced calculators use floating point.
I've been interested in how 4-function calculators and cheap clocks work for a while.
Most of the implementational details would appear to be buried in files on engineering workstations at Chinese factories.
I found a calculator teardown at http://electronupdate.blogspot.com.au/2016/08/reverse-engine... a while ago. The author says it's very old but doesn't provide a ballpark (eg, 1990, 1995, 1998, 2003, etc). It does look quite hairy (and possibly not particularly compactly designed?).
I would guess there's a ridiculously simple ALU somewhere in there, but I wonder what else is involved in the specific context of a high-production-volume fixed-functionality design.
I hope to find something similar for a clock at some point.
The other day, for testing purposes, I managed to make a minimal docker container with the smallest 'exit 0' binary I could make without any serious trickery, just gcc -static -s -Os, and was kind of embarrassed that it took 840 kB.
(I realize there are ways to get this down to probably the sub-1kB level, but I wanted something I could generate reliably on the fly in a shell script, so...)
I fired up Windows 2.03 in DOSBox, with its clock app, available on archive.org[1], and it took up 60.1 MB. This is fun! I think the OS would run fine (at least, enough for the clock) with as little as 512K of ram[2].
If you have screen of size 640*480 and rendering without AA then you can render by CPU.
Otherwise, with modern hardware and 200 ppi monitors you will need GPU rendering with the whole infrastructure.
It would probably depend more on the OS and the underlying stack than anything.
E.g. on DOS, with direct memory access (plus maybe some INT 10h helpers to draw the digits; although Windows clock doesn't draw them) in video mode 13h, you could do this with a .COM program that would be under a kilobyte total in and of itself. If you counted DOS itself, you'd still be under 64k.
I just opened up "clocktab.com" on Chrome, the first simple clock I could find by googling "clock," and Chrome's task manager shows it using a full 42 megabytes of memory.