[NTLK] RFC: project ideas for 2026

[David Arnold]

On Mon, Mar 30, 2026, at 3:26 AM, Matthias Melcher wrote:

> 2: Einstein: the emulator still works fine, but it could use a general 
> overhaul to modern C++ and maybe new minor features. All in all though, 
> it's a pretty complete app. It's a lot of work for relatively little 
> visible gain.

OTOH, C++ is a fairly rapidly moving target, and if Einstein is not kept up to date, it will relatively quickly become difficult to build with modern tools.  I'd be willing to invest some effort here.

> 4: NCX: NCX mostly works. We have access to the source code and I 
> managed to recompile it on modern macOS. Question is, is current NTX 
> good enough for everyone? Does it need (a:) small fixes? (b:) Major 
> fixes? Or (c:), a rewrite that runs on Linux and Windows as well?

I've recently returned to using a Linux laptop (after my Mac's SSD died), so I'd have some interest in a Linux solution.  Are you thinking an FLTK  application?

> 5: E-Paper display retrofit: I did find an e-Paper touch display that 
> could work with existing MP2x00 and eMates. It would replce the 
> existing display, have fantatsic contrast, but no backlight and just 
> touch (no pen interface). Not sure if there is anyone ready to modify 
> their machines, or if using a modern e-Paper device with Einstein ist 
> better.

I imagine that LED sidelighting would be a bit complex for a community-based solution?

> 6: Wifi Modem Card: Based on Jake Bordens awesome ESP32 board, we could 
> create an internalboard for the modem port that combines the USB dongle 
> functionality with modern Wifi and possibly even bluetooth. This is 
> again one of those projects that is 80% there, but the remaining 20% 
> need so much more time. 

I'd be interested in something like this.

If I was to dream, the ideal future for my Newton hardware would be to make it useful in the modern world.  I think that basically means a "side car": something that wraps the Newt in a 1997 bubble, and interprets for it to the modern Internet.

Such a board would perhaps run a small OS (Linux?) with a PPP connection over the Newton's modem serial port, DHCP, DNS, etc, proxies, and then a set of application proxies for POP, SMTP, HTTP, etc, that add SSL/TLS wrapping, convert POP to IMAPS, and so on.   It might be reasonable to include a sync feature for calendar and card objects into CalDAV and CardDAV, so they can sync with iCloud/Google/Microsoft/etc.

My concern is that this will require too much battery power.  It would be possible to implement all these as Internet services, but then the insecure protocols are exposed.  Perhaps some middle ground where the board just forwards the PPP traffic in a WireGuard tunnel?

> 7: Despite adding a compiler to Einstein, I have not seen new apps for 
> NewtonOS. Not complaining, since I have not written one myself either, 
> but the question is, does it make any sense to invest time into a: 
> improving the Einstein Toolkit, or b: documenting NTK with BasiliskII 
> and Einstein?

I play with Einstein periodically, much like I play with my Newton hardware periodically, but I don't have it installed on a suitable handheld device.  Without that, it's really just curiosity -- I  don't actually use it, and so I'm not often motivated to write an application for it.

That said, a development environment that didn't require spinning up a Mac emulator would certain reduce my barrier to entry.

> 8: In a similar quest, I managed to get Simon Bell's Newton Toolkit to 
> cimpile, and also to decompile Newton apps (i.e. take a .pkg file, 
> decompile it into NS source code, recompile it into a package, and get 
> the same app). Again, 80% there, still 20% to go, but only if anyone 
> needs that.

That sounds interesting.

> 9. On the quest to recreate the ROM source code, Simon Bell's code is 
> maybe 30% there. We could continue his work and end up with the entire 
> OS recreated. But this is an extraordinary amount of work, and would 
> require three or more dedicated devs who understand ARM assembler and 
> write C++ and it would still take many months.

If someone else were to coordinate this, I'd be willing to contribute a few hours a month, probably in short-lived bursts of enthusiasm when I can pretend my higher priorities don't exist for a long late evening or two.

> 10. Write an interface (similar to WINE that runs Windows apps on macOS 
> and Linux). This is basically like 9, but starting at the other end. We 
> take one Newton app pkg that we really love, and the write the 
> interface layer until the app runs native. We could probably get simple 
> stuff running in half a year, but probably never reach a perfect 
> NewtonOS that runs everything.

On the one hand, positively, an ability to write NewtonScript applications that run on my laptop or phone would be great.  I'd be much more likely to do that than write them for my actual Newton, since I use those devices every day.  And, of course, it would be pretty cool to pop up a Newton app on my phone or laptop!

On the other hand, less positively, I'm not sure it makes a lot of sense to write NewtonOS applications for my laptop or phone?   Typically, with WINE (or Darwin, the macOS equivalent), the integration with the host platform is mostly a matter of syntax: the system call or library function to do task X has a different name and reordered or slightly different parameter types to the host OS equivalent.  But there's largely a 1:1 semantic mapping between Windows, macOS, and Linux (and to a lesser extent, iOS and Android).  And so, you can run Word on Linux, or Visio on a Mac, and the clipboard works, and the filesystem works, and the mouse/keyboard/screen works more or less the same way.

But Newton applications are more integrated with both the system and with other applications.  The in/out box, for example, has no real equivalent.  Or Newton Intelligence.  And the data sharing of soups/stores is explicitly prevented on  modern mobile platforms,  So I fear that a lot of what was great about NewtonOS seems like it might be lost in a WINE-like translation environment?

I think you're right though: if this were to happen, picking a popular application and iterating until it works would be the best starting point.  Maybe something that doesn't need eg. NIE, so that effort is smaller.


Thanks Matthias,




d