That, and alongside 48K ROM and 2K RAM, you get 3 timers, a UART, and an A/D converter. [1] https://global.epson.com/products_and_drivers/semicon/pdf/id...
Would it blow your mind that such ultra-frugal 8-bit parts have been available for about 30 years now?
Those Seiko-Epson chips, alongside with EM-Swatch, and OKI-Casio chips, were used in all kinds of timekeeping, calculator, thermometers, and all kinds of cheap low-power widgets with segment LCD displays that need to run years on a single button cell.
I have a calculator and a digital fever thermometer(the stick-type ones for the armpit or anus) that's over 15 years old, also using on one of those Seiko-Epson chips and it's still running on the same 1.5v button-cell that it came with, which is mind blowing when you factor in the charge decay of the lithium cell over time.
But yes, incredible. These are products made with a lot of care, unlike modern counterparts that are just so very lax on these things.
What makes you think so? You can still buy calculators that last a long time, and 'solar' powered calculators that work in pretty dim light inside of a class room.
The Game Gear had much higher specs than Nintendo's Game Boy. It had a proper colour display, instead of a pea soup screen.
> The internal reaction to the Game Boy at Nintendo was initially very poor, earning it the derogatory nickname "DameGame" from Nintendo employees, in which dame (だめ) means "hopeless" or "useless".[19][20]
(An idiomatic translation might be, 'Lame Boy'.)
As you might be aware, the supposed Lame Boy won the market. Partially because the Game Gear ate through batteries like crazy, while the Game Boy subsisted on a more measured diet.
Many mobile apps nowadays are larger in binary size than whole operating systems+applications doing extremely useful work.
It's staggering, scary and, where is this all going? Will someone or something put a damper on it? Probably not.
Oh yes.
Global warming will.
The fossil-fuels companies have been very effective at spreading propaganda, so some readers are probably laughing and thinking "ha! Idiot! It's not real!"
If so, I am sorry for you: you are flat-earthers. You have been eaten by the brain worms.
We are heading for 80-90% of the land on Earth being uninhabitable by humans inside 2-3 decades, and a small remnant population at the poles. All silicon chips, RAM, storage, etc. is made in tropical and subtropical regions, and they will all be gone.
If we are lucky we'll be back to handmade computers with individually soldered components scavenged from dead consumer electronics.
The CollapseOS person is probably right: http://collapseos.org/
Here is a quick guide to the science for those with the brain worms: https://medium.com/@samyoureyes/the-busy-workers-handbook-to...
It is the length of a short book, but that's because there is a lot to get in for those who've been trained to bury their heads in the sand because they listen to billionaire's BS.
Moreover, I'm not sure how much you can gain, actually. You can probably get some reduction in app size as far as code segment is concerned, but usually most of the space is taken up by assets, especially in games, and they're already well compressed. So basically we could optimize the last 20% which are the hardest to get right.
As for code: I think shaving of bytes isn't all that important, especially compared to assets; but simplifying logic can give various benefits. However, that also takes time and is probably not worth it for many applications.
A distinction I like to make is being careful to distinguish between bloat that worsens throughput and bloat that worsens latency.
Throughput still gets better almost for free over time by general hardware improvements. Latency still requires attention.
An example: an early word processing software (I think it was part of GEOS for the Commodore 64) paid a lot of attention to keeping the latency between you pressing a key and a letter appearing on the screen low. By today's standards, the Commodore 64 was slow as molasses, so when you typed quickly GEOS eg temporarily disabled breaking wrapping words at the end of the line and just jumped to the next line in the middle of a word.
After you had finished your burst of typing, GEOS would go back and calculate proper line breaks.
Compare that with textfields in modern websites, which sometimes have a noticeable delay before a letter shows up.
GEOS's code for such latency reduction was probably incredible convoluted and messy (I am just guessing here) and made it hard to a nightmare to add new features, but was worth it back then. The modern bloated website can probably sustain a higher throughput, even without no one taking any care to optimize that. But latency is horrible.
Not all the time, though. Eg consider a video game: the image frames have to be pumped out on a tight time budget every couple of milliseconds, but the logic to decide whether you have finished your quest can afford to run for a few seconds in the background.
Even though the latter is much simpler and could probably be coded up to run on even the Timex m851 in fractions of a second.
Sure, games are ever-demanding and will continue going that way probably for a while longer especially on the pure graphics side.
Many apps do contain truck loads of libraries and dependencies, which have dependencies and all of that alone, accounts to massive code size.
From memory, it's under 100nA on paper, including things like the power switch leakage. Crazy stuff.
4-bit (!) 32KHz MCU with 6,144 words of 12-bit (‼) ROM, 640 words of internal 4-bit RAM, and a 160-word 4-bit frame buffer for the integrated LCD driver (enough for double-buffering)!
The thing is a beauty! I wrote a Typescript emulator for it, a year ago or so, though for whatever reason I haven’t pushed it to GH yet (but I will if anyone’s interested! It can run unmodified Tamagotchi firmware.
Using the microcontroller was advantageous because we could implement a custom interface (data and wake up alarm signaling) to the main microcontroller, the functionality was exactly what we wanted, super low power and very inexpensive.
He had to deal with complications like maintaining the time, running the interface, maintaining the alarm, all at the same time.