5 ms·

Part of the magic is how bonkers frugal the Epson SoC (PN S1C88349) is: when running at a low-power mode at 32kHz, it consumes an astoundingly low 9 microamps.

Part of the magic is how bonkers frugal the Epson SoC (PN S1C88349) is: when running at a low-power mode at 32kHz, it consumes an astoundingly low 9 microamps. [1] How much do you think you could get done with a cycle budget of 32k per second? 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/id002478.pdf https://global.epson.com/products_and_drivers/semicon/pdf/id...

adhesive_wombat 3y ago
There's an ultra-low power mode in newer TMS430s, and you can use an external ultra-low-power RTC. From memory, it's under 100nA on paper, including things like the power switch leakage. Crazy stuff.
- MrBuddyCasino 3y ago
  Do you mean the TI MSP430?
  - WithinReason 3y ago
    https://en.wikipedia.org/wiki/TI_MSP430 https://en.wikipedia.org/wiki/TI_MSP430
  - adhesive_wombat 3y ago
    Ugh yes! Don't know why I always get that wrong!
FirmwareBurner 3y ago
>Part of the magic is how bonkers frugal the Epson SoC (PN S1C88349) 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.
- hnwizard 3y ago
  You should be reaching the charge decay of that cell more or less now. :) But yes, incredible. These are products made with a lot of care, unlike modern counterparts that are just so very lax on these things.
  - eru 3y ago
    > [...] unlike modern counterparts [...] 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.
    - hnwizard 3y ago
      I didnt mean to compare it with calculators that are entirely powered by light. More to modern watches, smartwatches and whatever modern devices we have.
      - eru 3y ago
        You are right about them. But battery hungry monsters ain't new. Have a look at the Sega Game Gear. 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.
hnwizard 3y ago
There's a staggering, mind blowing, astronomical levels of bloat and complexity in modern systems, be it SoCs, Operating systems or apps. 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.
- hdjjhhvvhga 3y ago
  Only if there is an economic incentive to it. Currently, there is none. (A cynic in me would say the reverse is true at least in Apple ecosystem, as more resource-hungry apps push users to upgrade their devices more often.) 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.
  - ralphc 3y ago
    In modern times the argument is the economic incentive is to optimize for the developer, not the hardware. Python, Node etc. over C.
    - eru 3y ago
      And most of the time that's the right trade-off. 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.
  - eru 3y ago
    If we really needed to, we could compress assets a lot, eg with procedural generation. (Including the neural network kind.) But that would be a lot of hassle, and would probably trade run time for space. 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.
Zeetah 3y ago
In the Arthur and DW ActiMates (https://news.ycombinator.com/item?id=36656190 https://news.ycombinator.com/item?id=36656190), my teammate, Craig Ranta, implemented the Real Time Clock using a Microchip 12C508 or 12C509. It ran at 32.768 kHz. 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.
ilaksh 3y ago
I found "ROM" to be confusing because I always thought that meant you couldn't change it, but they mention swapping modifiable data in and out of there. It's actually EEPROM and I guess that is a little similar to Flash memory.
- namibj 3y ago
  Usually NOR flash. SSDs are usually NAND flash.
zenolove 3y ago
The [E0C6S46](https://download.epson-europe.com/pub/electronics-de/asmic/4bit/62family/technicalmanual/tm_6s46.pdf https://download.epson-europe.com/pub/electronics-de/asmic/4...) still powers the 1st and 2nd gen Tamagotchi! 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.
- triyambakam 3y ago
  Wow, I'd love to see the emulator

adhesive_wombat 3y ago

There's an ultra-low power mode in newer TMS430s, and you can use an external ultra-low-power RTC. From memory, it's under 100nA on paper, including things like the power switch leakage. Crazy stuff.

MrBuddyCasino 3y ago
Do you mean the TI MSP430?
- WithinReason 3y ago
  https://en.wikipedia.org/wiki/TI_MSP430 https://en.wikipedia.org/wiki/TI_MSP430
- adhesive_wombat 3y ago
  Ugh yes! Don't know why I always get that wrong!

FirmwareBurner 3y ago

>Part of the magic is how bonkers frugal the Epson SoC (PN S1C88349) 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.

hnwizard 3y ago
You should be reaching the charge decay of that cell more or less now. :) But yes, incredible. These are products made with a lot of care, unlike modern counterparts that are just so very lax on these things.
- eru 3y ago
  > [...] unlike modern counterparts [...] 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.
  - hnwizard 3y ago
    I didnt mean to compare it with calculators that are entirely powered by light. More to modern watches, smartwatches and whatever modern devices we have.
    - eru 3y ago
      You are right about them. But battery hungry monsters ain't new. Have a look at the Sega Game Gear. 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.

hnwizard 3y ago

There's a staggering, mind blowing, astronomical levels of bloat and complexity in modern systems, be it SoCs, Operating systems or apps. 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.

hdjjhhvvhga 3y ago
Only if there is an economic incentive to it. Currently, there is none. (A cynic in me would say the reverse is true at least in Apple ecosystem, as more resource-hungry apps push users to upgrade their devices more often.) 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.
- ralphc 3y ago
  In modern times the argument is the economic incentive is to optimize for the developer, not the hardware. Python, Node etc. over C.
  - eru 3y ago
    And most of the time that's the right trade-off. 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.
- eru 3y ago
  If we really needed to, we could compress assets a lot, eg with procedural generation. (Including the neural network kind.) But that would be a lot of hassle, and would probably trade run time for space. 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.

Zeetah 3y ago

In the Arthur and DW ActiMates (https://news.ycombinator.com/item?id=36656190 https://news.ycombinator.com/item?id=36656190), my teammate, Craig Ranta, implemented the Real Time Clock using a Microchip 12C508 or 12C509. It ran at 32.768 kHz. 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.

ilaksh 3y ago

I found "ROM" to be confusing because I always thought that meant you couldn't change it, but they mention swapping modifiable data in and out of there. It's actually EEPROM and I guess that is a little similar to Flash memory.

namibj 3y ago
Usually NOR flash. SSDs are usually NAND flash.

zenolove 3y ago

The [E0C6S46](https://download.epson-europe.com/pub/electronics-de/asmic/4bit/62family/technicalmanual/tm_6s46.pdf https://download.epson-europe.com/pub/electronics-de/asmic/4...) still powers the 1st and 2nd gen Tamagotchi! 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.

triyambakam 3y ago
Wow, I'd love to see the emulator