frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Al Lowe on model trains, funny deaths and working with Disney

https://spillhistorie.no/2026/02/06/interview-with-sierra-veteran-al-lowe/
50•thelok•3h ago•6 comments

Hoot: Scheme on WebAssembly

https://www.spritely.institute/hoot/
114•AlexeyBrin•6h ago•20 comments

Stories from 25 Years of Software Development

https://susam.net/twenty-five-years-of-computing.html
49•vinhnx•4h ago•7 comments

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

https://openciv3.org/
809•klaussilveira•21h ago•246 comments

Reinforcement Learning from Human Feedback

https://rlhfbook.com/
72•onurkanbkrc•6h ago•5 comments

The AI boom is causing shortages everywhere else

https://www.washingtonpost.com/technology/2026/02/07/ai-spending-economy-shortages/
89•1vuio0pswjnm7•7h ago•101 comments

The Waymo World Model

https://waymo.com/blog/2026/02/the-waymo-world-model-a-new-frontier-for-autonomous-driving-simula...
1053•xnx•1d ago•599 comments

Start all of your commands with a comma (2009)

https://rhodesmill.org/brandon/2009/commands-with-comma/
470•theblazehen•2d ago•173 comments

Selection Rather Than Prediction

https://voratiq.com/blog/selection-rather-than-prediction/
8•languid-photic•3d ago•1 comments

Vocal Guide – belt sing without killing yourself

https://jesperordrup.github.io/vocal-guide/
196•jesperordrup•11h ago•67 comments

Speed up responses with fast mode

https://code.claude.com/docs/en/fast-mode
8•surprisetalk•59m ago•2 comments

France's homegrown open source online office suite

https://github.com/suitenumerique
535•nar001•5h ago•248 comments

U.S. Jobs Disappear at Fastest January Pace Since Great Recession

https://www.forbes.com/sites/mikestunson/2026/02/05/us-jobs-disappear-at-fastest-january-pace-sin...
42•alephnerd•1h ago•14 comments

Coding agents have replaced every framework I used

https://blog.alaindichiappari.dev/p/software-engineering-is-back
204•alainrk•6h ago•309 comments

A Fresh Look at IBM 3270 Information Display System

https://www.rs-online.com/designspark/a-fresh-look-at-ibm-3270-information-display-system
33•rbanffy•4d ago•5 comments

72M Points of Interest

https://tech.marksblogg.com/overture-places-pois.html
25•marklit•5d ago•1 comments

Software factories and the agentic moment

https://factory.strongdm.ai/
63•mellosouls•4h ago•67 comments

Unseen Footage of Atari Battlezone Arcade Cabinet Production

https://arcadeblogger.com/2026/02/02/unseen-footage-of-atari-battlezone-cabinet-production/
110•videotopia•4d ago•30 comments

Where did all the starships go?

https://www.datawrapper.de/blog/science-fiction-decline
67•speckx•4d ago•70 comments

Show HN: Kappal – CLI to Run Docker Compose YML on Kubernetes for Local Dev

https://github.com/sandys/kappal
21•sandGorgon•2d ago•11 comments

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

https://github.com/valdanylchuk/breezydemo
271•isitcontent•21h ago•36 comments

Learning from context is harder than we thought

https://hy.tencent.com/research/100025?langVersion=en
199•limoce•4d ago•110 comments

Monty: A minimal, secure Python interpreter written in Rust for use by AI

https://github.com/pydantic/monty
284•dmpetrov•21h ago•151 comments

Making geo joins faster with H3 indexes

https://floedb.ai/blog/how-we-made-geo-joins-400-faster-with-h3-indexes
155•matheusalmeida•2d ago•48 comments

Hackers (1995) Animated Experience

https://hackers-1995.vercel.app/
553•todsacerdoti•1d ago•267 comments

Sheldon Brown's Bicycle Technical Info

https://www.sheldonbrown.com/
424•ostacke•1d ago•110 comments

Ga68, a GNU Algol 68 Compiler

https://fosdem.org/2026/schedule/event/PEXRTN-ga68-intro/
41•matt_d•4d ago•16 comments

Show HN: If you lose your memory, how to regain access to your computer?

https://eljojo.github.io/rememory/
348•eljojo•1d ago•214 comments

An Update on Heroku

https://www.heroku.com/blog/an-update-on-heroku/
466•lstoll•1d ago•308 comments

Show HN: I spent 4 years building a UI design tool with only the features I use

https://vecti.com
367•vecti•23h ago•167 comments
Open in hackernews

Compiling OCaml to the TI-84 CE Calculator

https://farlow.dev/2025/05/17/ocaml-on-calculator
110•farlow•8mo ago

Comments

debugnik•8mo ago
This is cool! After the removal of all 32-bit targets from the native OCaml compiler, I had grown concerned about the portability of OCaml beyond the interpreter and Jsoo. But between this and the wasm efforts I see there are more escape hatches than I thought.

Consider sharing this in discuss.ocaml.org as well!

PaulHoule•8mo ago
The CPU is an eZ80 clocked at 48MHz

https://en.wikipedia.org/wiki/Zilog_eZ80#Use_in_commercial_p...

which uses 24 bit pointers for a 16M address space. I like it as it is clearly superior to the '8-bit' machines of the 1980s but a step below ARM.

kragen•8mo ago
Below ARM in what metric? It's not below ARM in cost, power consumption, or transistor count. It's below ARM in aesthetic appeal and convenience, certainly, but why would you want that?
adrian_b•8mo ago
Below especially in speed and in ease of programming.

A 48-MHz Z80 will be many times slower than a 48-MHz Cortex-M0+, which also costs only a fraction of a dollar.

If you want a decent speed on Z80, programming becomes difficult. The difference in execution time between naive Z80 programs for multiplying and dividing 32-bit numbers or 64-bit numbers and optimized programs can be of more than an order of magnitude.

Even the commercial programs that have existed during the 8080/Z80 era e.g. the Microsoft BASIC interpreters and FORTRAN compilers, or Turbo Pascal, were very far from obtaining optimal performance on Z80. Replacing their runtime libraries could gain a lot of performance. However that required a lot of work. On an ARM microcontroller nobody cares about implementing elementary arithmetic operations, because they are handled by hardware.

The difference in cost and transistor count could be relevant only for someone who uses millions of such chips. As an individual you do not care whether a CPU costs ten cents more or ten cents less.

The difference in power consumption is not at all guaranteed, because the energy required for the execution of a long software procedure that does e.g. a multiplication on a Z80 is likely to be greater than the energy consumed by a hardware multiplier. Similarly for any other complex operations.

A Z80 has less gates, but they must be reused many times for completing the same work that an ARM MCU does using more gates, but which are used much less times.

Moreover, a Z80 is likely to have been manufactured in an older CMOS process, which consumes more energy per gate switching.

So, except for very simple programs, it is more likely that a 48-MHz Z80 will consume more energy than a 48-MHz Cortex-M0+, for completing the same task, and not less.

Many decades ago, I was able to read the hex dump of a Z80 executable program as easy as someone would read today a C or Python source program. Despite that, I have no interest to program again a Z80, even if it provides pleasant memories.

Writing programs for instruction sets like AVX-512 or Armv9-A is much more interesting than reimplementing elementary operations on a Z80. With a good macroassembler, one could implement an instruction set for a virtual CPU and then use that to simplify the programming of a Z80, but then what is the point of using the Z80 instead of a CPU with more powerful hardware.

If you are insulated from the Z80 ISA by using a high-level language, e.g. BASIC, FORTRAN or C, then again you no longer have any reason to use a Z80 instead of another better CPU.

The only purpose of a Z80 today is to run unmodified legacy software, but even for that, a software cycle-accurate emulator is better.

kragen•8mo ago
I agree with almost everything you say. One minor quibble: I said the Z80 variants were not below ARM in cost, power consumption, or transistor count, while you seem to be implicitly accepting (and partially rebutting) a claim that they are below ARM in those metrics. That is, I think ARMs cost less, consume less power, and contain fewer transistors.

For example, you say, "A Z80 has less gates, but...", but I don't think that's true in this context, though this is the most dubious of my five claims. The original Z80 had 8500 transistors, which is less than the ARM 2's 27000 (according to https://en.wikipedia.org/wiki/Transistor_count) but couldn't run anywhere close to 48MHz; I think the eZ80 we're talking about is actually bigger than the ARM 2, because, although it supports the Z80 instruction set, its datasheet advertises, "Single-cycle instruction fetch, high-performance, pipelined eZ80® CPU core". And I think there may be more recent ARMs that are smaller than the ARM 2; I think the Cortex-M0 is about 48000 transistors¹, and the simplified Cortex-M0+ version is presumably a bit smaller.

The eZ80 definitely costs more than an ARM. It's not even close; an ARM costs about 5% of the cost of an eZ80. The cheapest eZ80 Digi-Key has in stock is https://www.digikey.com/en/products/detail/zilog/EZ80F93AZ02..., which costs US$5.27 in quantity 10, and LCSC lists https://lcsc.com/product-detail/Microcontrollers-MCU-MPU-SOC... for US$1.8562 in quantity 200+, though it's not in stock. By contrast, Puya's PY32F002, which is in stock, is 8.51¢ in quantity 500: https://lcsc.com/product-detail/Microcontrollers-MCU-MPU-SOC.... I've previously seen Cypress's CY8C4045 for even cheaper, 1.5¢ in quantity 1000 https://lcsc.com/product-detail/Microcontrollers-MCU-MPU-SOC... but they're out of stock at the moment and have been for a long time. That would be less than 1% of the cost of an eZ80.

You say, "The difference in cost and transistor count could be relevant only for someone who uses millions of such chips. As an individual you do not care whether a CPU costs ten cents more or ten cents less," but I don't think I agree about cost. When you have cheaper CPUs you can use more of them.

You say, "a Z80 is likely to have been manufactured in an older CMOS process, which consumes more energy per gate switching," and point out that needing less instructions for the same task on the ARM lowers the power consumption, which is true, but really understates the situation. ARMs utterly blow the eZ80 out of the water when it comes to low power consumption, even for simple instructions like increment, decrement, memory load, and memory store. Zilog's datasheet https://lcsc.com/datasheet/lcsc_datasheet_2411220235_Zilog-E... shows power consumption numbers on the order of 1 milliamp per megahertz; if we assume it's mostly one clock per instruction (as the datasheet claims, unlike the original Z80) at 3.3V that's still 3.3 nanojoules per instruction. That's 3300 picojoules. Low-power conventional-CMOS-logic ARMs like the STM32L0 family typically use on the order of 200 picojoules per instruction, 6% of the eZ80's consumption, while Ambiq's subthreshold-logic Apollo3 ARM (also mostly one clock per instruction) claims numbers in the neighborhood of 20μA/MHz at 3.3V, which works out to about 70 picojoules per instruction, a third of the STM32L0 and only 2% of the power consumption of the eZ80.

I think there are ARMs that use as much power as the eZ80, but they're high-performance chips, compromising on efficiency to go faster, rather than microcontrollers. Even back in the 01990s the StrongARM used only in the neighborhood of 1000 picojoules per instruction.

So, in summary, some ARMs consume 2% of the energy the eZ80 does (when running very simple instructions like increment and decrement), other ARMs cost 5% as much as the eZ80 does while using closer to 10% of the eZ80's energy, and while they are probably comparable in transistor count I think the ARM is probably smaller.

______

¹ This is based on the comment that it's 12000 gates in https://community.arm.com/support-forums/f/architectures-and..., where Joseph Yiu of ARM corrects dr.indira's higher estimate of 72000 to 100k transistors, saying, "Without going into details, some of the low cost Cortex-M0 microcontrollers on the market has less than 50K gates and that included bus system, peripehrals [sic], and possibly DMA support, etc (exclude memory area and analog components). The 12K gate number is based on minimum configuration at 180ULL process."