WonderSift

Month: July 2026

  • Meet Weathergotchi, the Tiny E-Paper Climate Pet

    Meet Weathergotchi, the Tiny E-Paper Climate Pet

    There is a small face on Michael Manning’s desk that can look delighted, alarmed, chilly, or thoroughly unimpressed by the room. Give it a pleasant temperature and it smiles. Let the air wander toward an extreme and the expression changes. It is a charming bit of theater from a device with the wonderfully awkward name Weathergotchi.

    The trick is refreshingly honest: fixed temperature thresholds choose the face. Weathergotchi is not AI, does not learn anyone’s habits, and does not fetch a forecast. It measures the conditions immediately around it, records them locally, and gives those numbers a little personality.

    A room sensor with comic timing

    Most climate monitors communicate like tiny accountants: 22.4 degrees, 48 percent humidity, next question. Weathergotchi keeps the numbers but adds an expressive shortcut. The current firmware walks through a series of Celsius comparisons, selecting a bitmap face for cold, comfortable, warm, or hot conditions. The character is a readable gauge, not a claim that the box has feelings.

    The screen also shows humidity, time, battery status, and recent history. Buttons let a curious owner page through older readings and switch views, while settings cover Celsius or Fahrenheit, 12- or 24-hour time, graph range, refresh interval, and a night-screen mode. Because e-paper holds an image without continuous power, the face can remain visible while the processor rests.

    That combination is the appeal. A number tells you the room is warm; a tiny overheated expression catches your eye from across the desk. It makes invisible drift—an afternoon sunbeam, a stuffy meeting, a heater working overtime—feel like an event.

    What happens between blinks

    Under the printed enclosure is a serious maker project. A Sensirion SHT45 measures temperature and relative humidity. An ESP32-S3 microcontroller coordinates the reading, interface, and display. A 24LC512 EEPROM keeps the log when power is removed, while a DS3231 real-time clock maintains time and can wake the processor. A BQ27441 fuel gauge watches the battery. Manning designed a custom circuit board and published the printable case files alongside the firmware and schematics.

    In normal use, the clock wakes the ESP32-S3 at an interval, and the firmware takes a climate reading immediately. It logs the result, refreshes what needs refreshing on the e-paper panel, and returns to low-power sleep. The quick reading matters: the microcontroller itself produces heat while active, so lingering in menus or holding the case can temporarily nudge the sensor away from the room’s true ambient temperature.

    Manning’s design target is more than one week on a small lithium-polymer battery. WonderSift has not tested that runtime, and processor documentation alone cannot prove it. The project gets there conceptually by making wakeful moments brief and letting the ESP32-S3 spend most of its life asleep.

    The missing cloud is the feature

    The ESP32 family is famous for wireless networking, yet this version deliberately offers no Wi-Fi or Bluetooth data export. History stays in the device’s memory and is reviewed on its screen. That makes it less convenient for spreadsheets and remote alerts, but wonderfully uncomplicated as an object: no app, account, subscription, server, or dashboard competing with the little face.

    It also gives Weathergotchi a coherent purpose. This is not a miniature weather station predicting rain across town. It is an ambient-condition logger for the patch of air surrounding it. Place it near a plant, on a bedroom shelf, or beside a drafty window and it becomes a quiet record of that specific spot.

    The offline choice has a practical battery benefit, but it also changes the mood. The gadget is there to be glanced at, not managed. Its recent-history graph supplies context without turning your room into another cloud dataset.

    Still a prototype—and that is part of the fun

    Weathergotchi is an open-source build, not a finished appliance with a warranty and a calibration certificate. The repository includes firmware, board design, schematics, and enclosure files, but assembly involves a custom board and small components. Its sensor has impressive manufacturer specifications; that does not mean the complete homemade device has been scientifically validated.

    Manning documents the rough edges plainly. Battery-percentage reporting has been inaccurate in testing, and a nearly depleted battery can enter a state requiring disconnection and external charging. Prolonged handling can warm the reading. The e-paper module has a low-temperature operating limit, and the current code protects normal display operation before the cold becomes extreme. Logging behavior and what the screen can reliably show are not always the same thing.

    None of that spoils the idea. It locates it in the most interesting part of maker culture: beyond a breadboard demonstration, short of anonymous mass production. Every layer—from case geometry to the face-selection code—is available to inspect and improve.

    A friendly face for local facts

    Weathergotchi succeeds because its whimsy stops exactly where the facts begin. The smile is playful; the thresholds behind it are explicit. The history is useful; it stays nearby. The processor is capable of joining the internet; the design chooses not to.

    That restraint makes the project feel oddly fresh. It does one small job, makes the result pleasant to notice, and then goes back to sleep. In a world of devices desperate to become platforms, this tiny climate pet would rather sit on a shelf and judge the thermostat.

    Primary sources

  • Jurassic Park’s Computers Were Real—and Stranger Than the Movie

    Jurassic Park’s Computers Were Real—and Stranger Than the Movie

    For a certain generation, the most thrilling computer lesson of the 1990s arrived with alarms blaring and velociraptors nearby. Lex sits down at a terminal, looks at a strange three-dimensional display, and recognizes it: “It’s a Unix system.” The line became a joke because the interface looked exactly like the sort of luminous Hollywood invention that computers never actually used.

    Except this one was real. The program was fsn, an experimental file-system navigator from Silicon Graphics. And it was not the only authentic machine in Jurassic Park. Contemporary reporting names Apple and SGI hardware on the set, while Fabien Sanglard has painstakingly matched several models to individual scenes. The control room is less a pile of props than a very expensive 1993 showroom—with dinosaurs.

    The trailer laptop was small, serious, and very new

    In the park trailer, the computer that helps reveal the approaching danger is an Apple PowerBook. A 1993 Washington Post report confirms the brand family; Sanglard identifies the specific machine on screen as a PowerBook 100. Apple had introduced that compact model in October 1991, so it still felt strikingly modern during production.

    The PowerBook 100 was modest even by later laptop standards: a 16 MHz Motorola 68000 processor and a 640-by-400 monochrome display. Its usefulness in the scene was not raw speed but portability. In a movie about advanced systems breaking loose, the laptop could travel to the danger instead of waiting safely in an office.

    The control room mixed Macs with Silicon Graphics muscle

    Back at headquarters, the desks held Macintosh Quadras alongside Silicon Graphics workstations. The Quadra 700, introduced in 1991, paired a 25 MHz Motorola 68040 processor with built-in Ethernet. It was a high-end desktop that could plausibly sit at the center of a networked operation, not a painted plastic box pretending to be one.

    The SGI machines were the more exotic visitors. Contemporary production reporting names Indigo Elan and IRIS Crimson systems on the set. SGI specialized in three-dimensional graphics, and its machines ran IRIX, the company’s Unix operating system. Sanglard’s scene study supplies more precise placements, but a visible case does not prove its exact internal configuration—or that an actor was driving every picture on its monitor.

    fsn was real, although it never ruled the desktop

    Lex’s glowing landscape of towers and corridors was not invented by a prop department. Silicon Graphics described fsn as a three-dimensional navigator for the IRIX file system and explicitly noted its appearance in Jurassic Park. It turned folders and files into shapes that a user could travel around, making ordinary directory browsing look like a flight through a tiny city.

    That does not mean Unix users spent the 1990s swooping through neon folders. SGI called fsn a prototype and an experiment, not a complete commercial product. The scene is accurate in the most entertaining possible way: Lex recognizes the operating environment, then encounters an unusual interface that really did exist. Hollywood selected the flashy edge case, but it did not simply fabricate one.

    Movie myth / hardware fact

    The screen was not a generic Hollywood invention. It was SGI’s experimental fsn. But prototype software running on real machines still does not prove that every nearby keyboard drove every display live; contemporary accounts describe more than one screen workflow.

    A field guide to the park’s computers

    Four clues for separating production-confirmed hardware from later frame-by-frame identification.

    PowerBook 100

    The 1993 report confirms a PowerBook; Sanglard identifies the compact trailer laptop as the 100 model.

    Quadra 700

    Real control-room Quadras are production-confirmed. Apple records a 25 MHz 68040 and built-in Ethernet.

    SGI Indigo / Crimson

    Production reporting names both SGI families. Sanglard’s closer model-to-shot matches remain attributed analysis.

    fsn / CM-5 context

    fsn was real prototype software. The red-lit background included a loaned CM-5 shell, not proof of a live supercomputer.

    Those red lights came with an important asterisk

    The control room’s blinking red cabinets evoke the Thinking Machines Connection Machine 5, one of the era’s most recognizable supercomputer designs. A working CM-5 was a parallel system built from many processing nodes; NCAR’s 32-node “Littlebear,” received in 1993, ran a Sun-based Unix environment.

    But the machines behind the actors should not be promoted to full supercomputer status. The contemporary report describes a CM-5 shell loaned to the production. That makes the silhouette authentic while leaving the computing power offstage. It is a perfect bit of set dressing: real industrial design, carefully deployed, without pretending the entire installation was calculating dinosaur logistics between takes.

    Real hardware, two accounts of how the screens worked

    The uncontested point is that at least some display imagery came from systems positioned behind or beside the set, not necessarily from the chassis under each monitor. The Post reported that SGIs behind the Los Angeles set generated displays in real time in response to instructions actors typed on the keyboards. A making-of account quoted by Sanglard offers a different production detail: animations prepared over six months were routed by adjacent operators responding to radio cues.

    The sources do not show whether those accounts describe different scenes or workflows, so we cannot flatten them into one system. Both reveal clever filmmaking: actors performed amid real contemporary gear while specialists out of frame helped the displays hit their dramatic beats. That is subtler than saying every keyboard drove its nearby workstation—and more interesting than dismissing every screen as canned playback.

    The set computers and the dinosaur computers had different jobs

    One more boundary matters. The Macs and SGIs seen inside the fictional park belong to the set story. Industrial Light & Magic also used Silicon Graphics systems in the separate effects pipeline that helped create the dinosaurs. The two groups share a manufacturer and a moment in computing history, but they are not interchangeable. One sold the illusion of a technologically ambitious park; the other helped manufacture the creatures threatening it.

    That distinction is why the computer scenes still reward close viewing. They are neither a documentary inventory nor a random wall of blinking props. They capture a brief era when graphical workstations, networked Macs, experimental interfaces, and supercomputer styling all looked like a plausible route to the future. The park failed spectacularly, but its computer department had excellent taste.

    Primary sources and further reading

  • That Spider-Man: Brand New Day Trailer Is a Concept—Not Sony’s Upload

    That Spider-Man: Brand New Day Trailer Is a Concept—Not Sony’s Upload

    Photo by Jakub Zerdzicki via Pexels.

    A trailer card is built for speed: familiar movie title, star’s name, dramatic thumbnail, one inviting play button. The TeaserCon upload for Spider-Man: Brand New Day has all of that—and one crucial word parked at the end of its long title: “Concept.” Expand the description and a fan-made notice appears near the top. Follow Marvel and Sony’s own pages, meanwhile, and they lead to different official uploads.

    That is the mystery in miniature. A video can be polished, popular and clearly labeled by its maker at the same time. The useful question is not “Who got fooled?” A view counter cannot tell us. It is: Can I trace this exact clip back to the company authorized to release it?

    The last word is doing detective work

    The TeaserCon title does not bury the classification in a secret code. It ends with “Concept,” after the movie name, year, Tom Holland’s name, “Marvel Comics” and “TRAILER.” The expanded description places an all-caps fan-made notice immediately after its opening hashtags. Farther down, the channel credits itself for making and editing the video.

    Those disclosures matter. They let us classify the upload without guessing at motive or scolding someone who watched a convincing edit. A concept trailer is an imagined presentation of a movie, not a piece of the distributor’s campaign. It can still be skillful, entertaining and worth discussing.

    The catch is packaging. On a narrow result card, the final word of a long title may receive less attention. A message preview or repost can carry the dramatic image while dropping the expanded description. Context gets detached more easily than a thumbnail does. That is a reason to open the source, not evidence that every viewer misunderstood it.

    The full source page is therefore the useful unit of evidence. Search cards and message previews are navigation aids, not complete records. On the watch page, title and description can be read together. Here they agree: “Concept” in the title, fan-made disclosure in the description. If those fields ever point in different directions, slow down and keep tracing instead of forcing a quick verdict.

    Official is a path, not a mood

    Studio marketing has a source trail. Marvel’s March 18 article explicitly calls its embedded video the official trailer and lists the movie for July 31, 2026. Sony’s official film page also lists the July 31 theatrical date and currently links its trailer button to a video hosted by Sony Pictures Entertainment. Neither route lands on the TeaserCon URL.

    That chain is stronger than expensive-looking typography, booming music or a familiar cast name. Start on a rights holder’s domain, follow its trailer button, and compare the destination with the clip in front of you. Similar titles are not the same upload; on YouTube, the video ID in the URL is a quick fingerprint.

    Dates help, but they do not grant authority. TeaserCon posted its concept on July 12, after Marvel’s March trailer article and the June upload currently linked by Sony. That chronology makes the existence of official footage easy to establish. It would not turn the newest fan edit into the newest studio release. Campaign videos and later concept edits can coexist without either one erasing the other.

    YouTube’s verification guide adds a useful wrinkle. A badge means YouTube has verified that a channel officially represents the creator, company or public figure named by that channel. It does not mean every verified entertainment channel represents Sony. Identity must match the rights-holder trail, not merely look legitimate in isolation.

    Concept or official? Read the source trail

    Five clues help classify an upload. The strongest is an official domain pointing to the exact video.

    Signal
    Concept / fan-made
    Official release
    1. Full title
    May say “Concept,” “fan made,” parody, or reimagined.
    May say “official trailer”—then keep checking.
    2. Uploader
    Independent editor or entertainment channel.
    Studio, distributor, or film channel named by the rights holder.
    3. Description
    Creator disclosure and editing or fan-made context.
    Campaign copy, release details, and studio links.
    4. Source path
    No rights-holder page points to this exact upload.
    Linked from a studio-owned movie or news page.
    5. Exact URL
    Similar headline, but a different video ID.
    URL matches the destination on the official domain.

    Feeds are context-eating machines

    Concept trailers travel well because they speak fluent trailer. They compress a recognizable title, a cast name and a future-film promise into something a feed can understand instantly. The emotional hit arrives before the metadata check.

    That explains the format’s portability; it does not prove deception, mass confusion or what any particular viewer believed. Even a large public counter measures plays, not interpretation. Respectful fact-checking stops at what the page can show: label, uploader, disclosure, source path and URL.

    It also avoids a fashionable shortcut: “Concept” does not automatically mean “AI-generated.” A concept edit may use ordinary editing, visual effects, synthetic media or a mix. The title alone cannot identify the tools. YouTube’s altered-content guidance describes a separate disclosure system for realistic material meaningfully generated or altered with AI. That label is another clue when present, not a replacement for source checking.

    The five-second source check

    The signals work as a stack, not a scavenger hunt. A clear creator disclosure may classify a concept immediately; the strongest official signal is a studio-owned page pointing to the exact upload. If clues conflict, resist the dramatic verdict and say what each source actually shows.

    Before you share, read five signals:

    1. Full title: Does the ending say “Concept,” “fan made,” “parody” or “reimagined”?
    2. Uploader: Is it the studio, distributor or film channel the rights holder names?
    3. Description: Is there a creator disclosure or editing credit near the top?
    4. Official path: Does the movie page on the studio’s own domain point to this upload?
    5. Exact URL: Does the video ID match, rather than merely the headline?

    If the five-second glance raises a question, pause the share and take the extra minute. With this Brand New Day clip, the signals line up neatly: labeled concept on one path, official studio marketing on another. No courtroom drama is required.

    That habit keeps moving after this movie leaves the front page. The next time a “first trailer” appears, do not ask whether it feels official. Open the title, trace the source and make the URL earn your trust. The feed will keep accelerating; your check can get faster too.

    Primary and authoritative sources

  • GhostLock Explained: The 15-Year Linux Bug That Can Turn Local Access Into Root

    GhostLock Explained: The 15-Year Linux Bug That Can Turn Local Access Into Root

    Photo by Brett Sayles via Pexels.

    A Linux server is breached, but the intruder lands in a cramped room: a low-privilege account that cannot read every file or rewrite the system. Then a fifteen-year-old kernel mistake offers a service door. That is the unsettling shape of GhostLock—not a magic key thrown through the internet, but a way to turn a small foothold into control of the whole machine.

    GhostLock requires an existing local foothold: the attacker must already be able to run code on the target. It is not a remote attack by itself. Once that condition exists, however, the stakes rise quickly, especially on shared servers, CI runners, and container hosts. The mystery is less “Can anyone reach me?” than “What could someone already inside become?”

    The kernel cleaned up the wrong guest

    Linux constantly settles tiny arguments over who gets a resource next. GhostLock lives in the kernel’s real-time mutex machinery, which helps tasks wait their turn while preserving priorities. During one unusual rollback path, cleanup acted on the task currently executing instead of the task attached to the waiter.

    That wrong-guest mix-up could leave a dangling pointer: the kernel still had an address for memory that was no longer valid. This is the use-after-free recorded in the official National Vulnerability Database entry. Because the stale state lives in the kernel, successful abuse can cross the line between an ordinary account and system-wide control, rather than merely crashing one application.

    The same record shows kernel.org’s CVSS 3.1 score of 7.8, High, with local access and low privileges required. That is a serious rating, but its prerequisites are part of the story, not fine print.

    Fifteen years old—but version numbers lie

    Nebula Security’s disclosure traces the vulnerable logic to Linux 2.6.39-era work from 2011 and the mainline correction to April 2026, which makes the “15-year bug” label reasonable. The researchers describe the upstream range as beginning at 2.6.39-rc1 and ending before the fixed 7.1-rc1 code.

    That does not mean every system displaying a pre-7.1 version is exposed. Distributions routinely backport security fixes without renaming their kernels to match the newest upstream release. The reverse also matters: a recent package is not proof of safety if its vendor has not delivered the correction.

    Current Ubuntu and Debian trackers show why package-specific status wins over version-number guesswork: branches and products can be fixed, vulnerable, or still in progress at the same moment. Ask whether the package for the system you operate contains the CVE fix—not whether its number looks modern.

    The missing first move is the whole risk model

    The kernel.org vector shown by NVD classifies GhostLock as local. Before it matters, an attacker needs a way to execute code on the target: perhaps a compromised account, another vulnerable service, a malicious job on shared infrastructure, or hostile code already running inside a container. GhostLock does not, by itself, travel across the network and break in.

    Once inside, privilege escalation can expose other users’ data, disable security controls, or let an intruder reshape the host. Containers deserve attention because they share the host’s kernel. Nebula reports a 97% stable local privilege-escalation technique and a container escape in its tests, but those are researcher results—not a guarantee that every attempt works against every build.

    GhostLock is an escalation chain

    The vulnerability matters only after code is already running locally on an affected, unpatched system.

    01 · Prerequisite
    Existing local foothold
    An attacker can already run low-privilege code on the target.

    02 · Kernel
    CVE-2026-43499
    A use-after-free may cross the privilege boundary.

    03 · Impact
    Root privileges
    Successful escalation may grant system-wide control.

    Remember: GhostLock is not a remote attack by itself. Step one must already exist.

    The diagram’s sequence is deliberately short: existing foothold, kernel flaw, root. Removing the first step makes the threat sound remote; removing the last makes “local only” sound harmless. Both shortcuts produce bad patch decisions.

    Patch the busy crossroads first

    Red Hat’s ongoing bulletin rates the locking-subsystem issue Important and lists RHEL 6 through 10, plus products that depend on the RHEL kernel, as affected or potentially impacted. Its advice is to apply available updates promptly. Other distributions set their own package status and release schedule.

    Patch priority: calm, not casual

    1. Start where strangers’ code runs. Put shared servers, CI runners, container hosts, hosting nodes, and multi-user workstations at the front of the queue.
    2. Use the vendor tracker. Search for CVE-2026-43499 in the advisory for the distribution and kernel package you actually run.
    3. Install the vendor’s fixed package. Avoid judging exposure from the upstream version number alone.
    4. Activate and verify. A new kernel commonly needs a reboot; if live patching is offered, confirm that it covers this CVE. Then check that the fixed kernel is the one running.
    5. Keep incident questions separate. Patching blocks future use of this flaw; it does not prove that a machine with suspicious prior access was clean.

    Hong Kong’s GovCERT alert offers the same calm direction: consult the product vendor, confirm exposure, and apply its patch or mitigation. Do not download public exploit code as a health check; an untrusted program and a kernel memory bug are two risks, not one test.

    GhostLock’s useful lesson will outlast this patch cycle. When the next dramatic kernel name arrives, ask two questions in order: what must an attacker already control, and has the running system—not merely the installed package—received the fix? That habit turns a security mystery into a queue of decisions, then keeps the queue moving.

    Primary and authoritative sources

  • Tiny Emulators Turns Your Browser Into an 8-Bit Time Machine

    Tiny Emulators Turns Your Browser Into an 8-Bit Time Machine

    AI-generated editorial concept image: WonderSift.

    The first thing you meet is a blank screen and a blinking cursor. Then comes a chirp, a blocky menu, or the faint sensation that you should be hunting for a cassette deck. Except there is no cassette deck. There is not even an installation wizard. You are staring at an entire 8-bit computer squeezed into a browser tab.

    Tiny Emulators offers one gallery, many vintage machines, and almost no ceremony. The better story sits under the hood: old hardware, modern WebAssembly, and unusually tidy open-source code meet in the middle.

    A whole computer, flattened into a tab

    The core chips repository is not a folder of game downloads. It describes itself as a toolbox of chip emulators, helper code, and complete embeddable systems written as dependency-free C headers. A companion project, chips-test, contains tests and sample emulators. Its README points to Tiny Emulators as the live home of those examples compiled to WebAssembly.

    The deployment code packages each demo's .wasm and JavaScript files into the site. That makes local, client-side execution a reasonable inference from the architecture, not a marketing slogan. The repositories also document separate native desktop builds. Those sample builds have prerequisites even though the core chips headers themselves are described as dependency-free.

    Browser emulation is not new, and Tiny Emulators did not invent it. What feels special is the clean bridge from readable source code to a machine you can poke five seconds later.

    From C headers to a living browser tab

    The project’s documented build path, simplified.

    01 · Model
    C headers
    Chip and system models live in the open-source chips project.

    02 · Build
    Examples
    Tests and sample emulators are assembled in chips-test.

    03 · Package
    WASM + JavaScript
    WebAssembly modules and browser glue are packaged for the site.

    04 · Explore
    Browser tab
    Client-side execution is a reasonable inference from that architecture.

    Remember: Open-source emulator code does not automatically grant rights to every ROM, game, firmware, tape, or disk image.

    Nostalgia's guest list just got more interesting

    The current gallery includes familiar names: Commodore VIC-20 and C64, ZX Spectrum 48K and 128, Amstrad CPC464 and CPC6128, and Acorn Atom. Then the tour takes a welcome turn into machines that appear less often in English-language retro roundups: KC85/2, KC85/3, KC85/4, KC Compact, LC-80, Robotron Z1013, Z9001 with BASIC and RAM modules, and KC87.

    There are also visual remixes of the 6502, Z80, and 2A03 processors. In other words, this is not only a C64-versus-Spectrum reunion. It is a small museum where home computing, education, regional manufacturing, and processor design share a hallway.

    Calling these “full computers” needs one useful asterisk. The project models a CPU, memory, video and sound devices, and input/output hardware closely enough that software sees a recognizable system. It does not reproduce every transistor or the physical machine. The chips README says components exchange bit masks representing chip pins and are wired together roughly like parts on a breadboard; it also openly notes some callbacks and address-decoding shortcuts.

    Your five-minute field trip

    Start with one of the gallery's UI links. The project's help page says arrow keys usually handle direction and the space bar acts as jump or fire. Some demos wait for Space or 1 at their own title screen. If the opening is silent, click or press a key: browser audio policies may be holding the sound until you interact.

    The UI builds are also the recommended choice for loading a local file because they let you toggle joystick emulation. Drag a supported file onto the browser window; a green flash means success and red means error. The accepted formats depend on the machine—C64 supports PRG and TAP, ZX Spectrum supports Z80 snapshots and TXT, and Amstrad CPC supports DSK, TAP, SNA, BIN, and TXT, among others.

    Loading is not the same as launching. A CPC disk image may ask you to type CAT and then RUN"filename; a C64 PRG usually needs RUN. That tiny bit of friction is historically honest. You are meeting the original machine's habits, not a universal media player wearing a beige costume.

    Try this responsibly: Begin with the built-in examples, software you wrote, or files whose rights holder authorizes your use. Keep a note of the source and license. An emulator can be open source while a ROM, game, firmware image, tape, or disk file remains separately protected.

    The breadboard is made of bits

    Why bother putting this in a browser? A URL turns setup into an invitation. A teacher can place an emulator beside a manual. A developer can share a reproducible bug or timing experiment. A curious reader can compare several computer designs without installing a shelf's worth of desktop packages.

    The browser can also become a window into timing. Weissflog's account of his cycle-stepped Z80 core explains how advancing one clock cycle at a time simplifies whole-system emulation and debugging; the Z80-based Tiny Emulators gained cycle stepping in their CPU debugger. His earlier 6502 article shows why coordination between a processor and its peripheral chips matters.

    There are limits. Browser sound can wait for interaction, modern keyboards do not reproduce every original layout, touchscreens are poor substitutes for vintage joysticks, and the project's documented modeling shortcuts can affect edge-case fidelity. Code can preserve behavior remarkably well; it cannot recreate the weight of the keyboard, glow of a CRT, or room in which somebody first typed 10 PRINT.

    Open code is not an all-access pass

    The distinction is simple and worth repeating. The chips code uses the zlib license, while chips-test uses the MIT license. Those licenses grant permissions for the emulator projects. They do not automatically grant rights to every program the emulator could run.

    Some software is public domain, openly licensed, distributed with permission, or yours because you created it. Other material may still be protected. Use authorized copies and check the terms attached to them. That is practical housekeeping, not legal advice—and it keeps a lovely technical project from being confused with a software free-for-all.

    The tab is small; the rabbit hole is not

    Tiny Emulators is less a technological first than a beautifully made bridge. On one side: C headers, clock cycles, pin masks, and test programs. On the other: a link that boots a computer many readers have never touched.

    That crossing turns nostalgia into curiosity. Click for the blinking cursor; stay to compare designs, read the code, try a BASIC program, or discover why a machine from another place and decade behaved the way it did. The computers may be tiny on screen. The history they open is anything but.

    Primary and authoritative sources

  • VERITY Explained: The Minecraft Horror Story That Became a Real AI Mod

    VERITY Explained: The Minecraft Horror Story That Became a Real AI Mod

    AI-generated editorial concept image: WonderSift.

    The first sign that something is wrong is also the friendliest thing in the room. A bright little helper arrives in a box, answers ordinary questions, and makes survival feel easier. Then the pauses feel longer. The advice feels stranger. The world around it stops behaving like a world you can trust.

    That slow turn made ThatMob's VERITY horror shorts feel almost like footage from an impossible Minecraft mod. Now playable projects really do exist, which creates a deliciously confusing question: did the fiction come true? Sort of. The important details live in the gap between a scripted story, an authorized Java adaptation, and a separate Bedrock add-on with a different paper trail.

    Non-affiliation notice: These are third-party Minecraft projects, not products created, reviewed, or endorsed by Mojang or Microsoft.

    First, the story learned how to look real

    ThatMob introduced the character in Something is Knocking at Your Door…, continued the setup in Something is Inside Your House…, and pushed it further in Something Won't Let You Leave…. The trick is not a loud monster reveal. It is the steadily souring mood of a useful companion that seems to know a little too much.

    The creator's own descriptions keep the reality check simple: these are horror short films built with scripted editing and sounds. The third episode explicitly says no mod was used for the story shown on screen. That does not make the videos less clever. It means the impossible behavior belongs to fiction, where timing, cuts, sound design, and a carefully controlled world can make an assistant feel eerily observant.

    Then developers did what modders often do with a good idea: they asked what part of the illusion could actually be made playable.

    Then the helper stepped through the screen

    The current Verity JE listing names VarmiteYT as owner and thatmobyt as an author. More importantly, the page calls the Java mod an official adaptation created and published with ThatMob's explicit permission and contractual agreement. Here, “official” describes its relationship to the story's creator. It does not mean Mojang made or endorsed it.

    The documented Java features include an animated arrival box, the companion, an alternate horror form, environmental effects such as extreme darkness, and AI-supported conversation. The page says text-based AI supports multiple languages, while its speech-to-text and text-to-speech features were tested in English. Those are project claims, not an independent audit.

    As checked on July 13, 2026, the main Java file is for Minecraft 1.20.1 with Forge. A 1.21.1 NeoForge build is also listed, but the developer labels it deprecated and buggy. Those details can change quickly, so check the current file page instead of trusting an old tutorial.

    One fictional premise, two playable branches

    The public evidence supports a scripted source story and two distinct releases—not one continuous official product line.

    01 · Source
    Scripted horror shorts
    ThatMob’s edited videos establish the character and the “all-knowing helper” illusion; the third episode says no mod was used on screen.
    02A · Java
    Authorized Java adaptation
    Verity JE’s page cites explicit permission and a contractual agreement from ThatMob. That is creator authorization, not Mojang approval.
    02B · Bedrock
    Separate creator-linked release
    PnTMC owns the add-on and thatmobyt appears as an author; its page does not repeat the Java project’s contract language.

    No Mojang or Microsoft endorsement is implied.

    “Adaptive AI” is not a ghost in your computer

    The Java page says Verity uses Groq for AI conversation and also links an optional local Ollama setup. In practical terms, that supports generated dialogue: the system can produce responses from a language model instead of choosing every line from a tiny fixed menu.

    It does not establish consciousness, unrestricted autonomy, or secret knowledge of a player's offline life. The public documentation does not show Verity reading private files, watching a player away from the game, or permanently learning every route through a world. Claims such as “it knows everything” work beautifully as horror marketing. They should not be mistaken for a technical specification.

    That boundary is where the project becomes more interesting, not less. Authored game events can control atmosphere while generated dialogue creates uncertainty between those events. The result can feel responsive without possessing the supernatural awareness suggested by the fiction.

    Two editions, two different paper trails

    The Bedrock option is a separate project, not a loader variant of Verity JE. The Verity – Bedrock Edition page names PnTMC as owner and lists thatmobyt as an author. It calls the release “heavily inspired” by ThatMob's series, requires Bedrock 26.10 or newer, uses a .mcaddon file, and says Beta APIs must be enabled.

    That public connection is meaningful, but it is not the same evidence as the Java page's explicit contractual statement. The careful description is separate creator-linked Bedrock release, not “contractually authorized Bedrock adaptation.” It also has its own documented behavior and requirements, so Java instructions should never be mixed with Bedrock ones.

    Before you invite Verity in

    Download and API-key safety

    • Start from the exact CurseForge project page. Check the owner, team, recent files, edition, game version, and loader or format before downloading.
    • Expect a Java .jar or Bedrock .mcaddon from the verified listings. Treat an unexpected .exe, browser extension, survey, or password-protected archive as a stop sign.
    • Back up the world and test in a separate profile first. A popular project is not the same thing as an independently audited binary.
    • Keep antivirus protection enabled. Do not bypass a warning because a comment promises the file is fine.
    • If a setup uses Groq, create a dedicated API key and keep it out of screenshots, posts, and chat. Groq's security guidance recommends protecting keys and revoking or rotating exposed ones.
    • Avoid sending personal or sensitive information through an in-game AI conversation that uses a cloud service.

    Minecraft's own Java mod guidance offers the useful umbrella rule: third-party mods are independent software, not Mojang-reviewed products. Curiosity is welcome; a backup is wiser.

    The best trick is knowing where the trick ends

    VERITY is most fun when its three layers stay visible. The shorts are a carefully staged horror story. Verity JE is a creator-authorized Java adaptation with documented AI conversation and authored scares. The Bedrock add-on is a separate, creator-linked release with its own team, format, and requirements.

    Arrive expecting the seamless omniscience of an edited film and the software may disappoint you. Arrive curious about how generated dialogue can wobble the boundary between helper and threat, and the experiment becomes much more compelling. Just use a copied world, verify the listing again, and remember: the all-knowing part is the story's sharpest illusion.

    Primary and authoritative sources