Hacking the Timex m851
lock.cmpxchg8b.com
lock.cmpxchg8b.com
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.
If you're interested in something with a bit more features, check out the Bangle.js[0]. The benefits are you have Bluetooth, GPS, accelerometer, vibrator, and a colour screen. The main downside is that the battery lasts considerably less than 3 years.
> With a sunlight readable always-on screen, 4 week battery life, complete flexibility, and complete control of your data, Bangle.js 2 is a refreshing break from expensive smart watches.
0. Where my next class is going to be
1. Store the bus schedule to the bus stops I used
2. The phase of the moon
Checking the bus schedule on your watch before smartphones looked like a James Bond move :)
I wish they still made watches like this, at this power consumption you could keep your watch charged from solar power indefinitely
To be fair, the first iPhone was launched 16 years ago, and smartphones that could store a bust schedule have been around even before the first iPhone. I would store the bus schedule as an SMS draft on my Siemens phone over 20 years ago.
https://github.com/sharandac/My-TTGO-Watch
I stumbled over this, while I was researching for building my own DIY iPod Nano 7G with the LILYGO T5 E-Paper dev board
Product: https://www.aliexpress.com/item/1005002474854718.html
Code-Repo: https://github.com/Xinyuan-LilyGO/LilyGo-T5-Epaper-Series
This would be an amazing iPod Nano 7G replacement, if I had more time and more skill in arduino stuff ;)
I would be surprised if the current code isn't MUCH better, but it's power budget is going to be much closer to an Apple or Samsung smart-watch and not an 80s era ultra-low-power m851.
If you're hip to experimentation (like I am) it's a fun little project and worth the money. If you're looking for something to compete with an iWatch, you're going to be disappointed.
Well Casio surely does. Search "Casio MIP display".
It was magical watching a Timex DataLink watch receive data (at a really slow data rate though) - short moment in time before USB and WiFi appeared.
The cool thing about both these watches is you don't have to recharge them every day (though you do have to wind up the wind-up watch.)
I'd love to have a decently integrated watch with low battery usage (and generally low stakes for wearing/replacing) which I can also agree with aesthetically. Bums me out that Sensorwatch [1] is the best we can do.
[1] https://www.sensorwatch.net
edit: Sensorwatch is amazing, but not an ecosystem (yet).
That said, 3 years on a single battery doesn't seem great of course I suppose it depends what apps you use and load..and that it's programmable that is cool.
[Edit: Oh. Okay. I see that you included a reference to the "RETIRED" product listing. I mean, it wouldn't be a TI product unless TI EoL'd it just as it was getting market traction.]
I don't know why he's complaining about the Windows 98/XP PIM software. It worked fine, and it's open source <https://sourceforge.net/p/datalinkusb/code/HEAD/tree/USBPIM/>. It does not work on Windows 10 and later, however. I looked into it years ago, and it seemed related to the GUI code (I think it used MFC?) and not anything involving watch access. Probably fairly easy for someone familiar with Windows dev to fix, especially with the source. Edit: Wait, I misread. He was complaining about the SDK wizard, not the PIM. Yeah, the wizard wasn't great. Also, it was slow since every file assembled had several megabytes of headers included.
Having C code running on the watch is nuts. The builtin ROM software was written in a high-level assembler (probably for size/CPU/power consumption reasons), and the user SDK was a regular assembler (I got the impression that back then Epson wasn't giving away the better development software, so the best that could be included for free with the SDK was the regular assembler.) The OS's overlay system and semi-adhoc calling convention isn't C friendly. Often, values were passed in whatever registers were convenient for the callee, with macros to help hide this when possible. EEPROM access functions took parameters from global RAM variables.
The SDK documentation was great. 10/10. You could not reasonably ask for more. It had many examples, every single header file used by Timex, which documented every single function and variable (even ones internal to the builtin software), and PDFs describing every bit of data going in and out of the watch, from the communication protocol to the file formats used by every builtin app. The OS used by the watch is impressively clean and easy to use for a one-off 8-bit system.
Most development for the watch was shared on a Yahoo Group, which is down now, but there are backups somewhere. I manually saved a bunch, and I know that people there backed up the messages and uploaded them to... I don't remember exactly where, I'd have to look it up. I remember running across a post there from the EEVBlog guy when looking through old posts. He was asking about making a fitness tracking app.
It took me a long time to get around to writing anything for it, but I wrote several programs for it around 2013-2015ish. A timer, calender, expense tracker, and a viewer for the user tracking data (stuff like how many times you've pressed a button, entered an app, or had an alarm go off). The SDK had a single DOS program as part of the build process (it was something to feed the linker some addresses), so I had to rewrite a 32-bit version to get the SDK to work on 64-bit Windows 7. I think I later found someone else already did that on the Yahoo Group.
I am thinking of the Cybiko, but that’s also contemporary to the Timex watch.
https://www.atredis.com/blog/2020/11/4/garmin-forerunner-235...
Maybe Palm and Psion devices count? I would exclude WinCE...
It doesn't really mean much, since all apps default to unprotected on boot, so you can never use it, but it's interesting.
Because the m878 has GPS and ANT+ support which makes it exponentially more powerful.
> They’re long out of production, and getting hard to come by.
> I bought a set of two on eBay, they just needed new batteries and were as good as new.
I'm not an English native speaker, however to me "hack" means something not standard. Not necessary cracking, of course, but just using SDK to write some software does not sound like something very "hacky". Those watches were explicitly designed to be extendable.
1. From the MIT Model Railroad Club. This is the "good" definition of hacking. A "hack" is a clever manipulation of an existing system to exceed it's design specs or make it do something radically different from what it was originally intended to do. Example: "Did you see that radical hack Bob pulled, using a the I/O port on a Commodore 64 to drive the model railroad track switcher? That was amazing!"
2. From the news media in the 80s and 90s. To break into a computer system. Example: "Wiley hackers broke into government computers and stole your Social Security, Drivers License and Credit Card numbers. But the good news is you get free credit monitoring services for the next year."
3. From ????. To jury-rig a system out of parts you wouldn't expect would work together, but it does. Example: "Did you see that radical hack Bob pulled, using a cardboard toilet paper roll to emulate a PDP-11? That was amazing!"
These words seem to have more to do with social status within a particular group than anything else.
Instead, he works under Linux with standard Makefiles, using wine and calling the compiler directly.
The original term comes, afaik, from journalists who would hack on typewriters, hence hacks.. it's another evolution, but I'm not great with etymology.