Wiznet makers

An Apple //e Card That Answers an MCP Client

Henri Asseily has been writing Apple II software in public for years. His GitHub account holds 44 repositories, most of them Apple II work: SuperDuperDisplay, a display engine for an Apple II bus card, a Linux fork of AppleWin, and the earlier AppleTini card. Appletini ONE is the current card, and the board itself was designed by Karl "KKR75" Asseily, whose name is on the silkscreen and on every schematic sheet.

Board render published in the repository and on appletini.org. It is a render, not a photograph of a finished card.

Appletini ONE is one expansion card for an Apple //e that stands in for a shelf of them. The README describes firmware and FPGA logic where "the PL handles cycle-sensitive Apple bus behavior; the two ARM cores provide storage, video rendering, USB services, configuration, and higher-level peripheral emulation." A WIZnet W5100S sits on that card as the Ethernet controller, and the FPGA fabric presents it to the Apple II as a Uthernet II. The repository was created on 6 July 2026 and last pushed on 21 August 2026, the date every fact below was checked.

The repository also ships something separate from the card. In tools/mcp/ it publishes a Model Context Protocol server, so an AI agent can read a live Apple II, dump its memory and watch its bus. Model Context Protocol, usually shortened to MCP, is the interface an agent uses to call tools that live outside the model.

One Card in Place of a Shelf, and Where Ethernet Sits

Appletini ONE replaces a stack of period expansion cards at once, which appletini.org sums up as "Seven machines in one slot". The README lists SmartPort storage and Disk II images, a slot-5 Z80 or 8088 coprocessor, Phasor and Mockingboard audio, a mouse card, RamWorks memory, VidHD and SuperSprite video, HDMI output, USB services, and one line that matters here: "Uthernet II compatible W5100 interface."

The Ethernet corner of the board render published by the project, not a photograph. The RJ45 jack sits at the card's rear edge, next to the mini-HDMI output.

The Ethernet is one function among many, not the reason the card exists. The repository's own AGENTS.md summarises the bill of materials and names the part plainly: "Ethernet: WIZnet W5100S (10/100 Base-T, parallel MCU interface)". The schematic PDF in schematics/ carries the same part as U129, a W5100S-L, wired to an HR911105A magjack and clocked from a 25 MHz crystal.

The product site does not name WIZnet or the W5100S anywhere. appletini.org describes the feature in user terms only: "A virtual Uthernet II connects your Apple //e to a real network through the onboard RJ45 jack, speaking standard TCP/IP." The chip name appears solely in the repository, in the BOM summary, the constraints file, the RTL and the firmware. That same site takes free reservations at approximately EUR 300 in the European Union and USD 450 in the United States plus local shipping, notes that "Pricing is indicative and may change", and states that shipping starts in September 2026.

What the MCP Server Actually Exposes

The MCP server is a single Python file, tools/mcp/appletini_mcp.py, about 10 KB long, built on FastMCP and pyserial. It publishes eight tools, six of which report machine state. Only two can act on the card: one sends a navigation key to its configuration menu, and one runs any firmware console command verbatim.

Generated technical diagram of the tool surface, taken from the docstrings in tools/mcp/appletini_mcp.py.

The most useful trick is the screen reader. apple2_screen_text returns the live 40 or 80 column text screen as plain text, and it picks the width from the live 80COL soft switch. The file explains why that costs nothing: "the apple_cycle_egress keeps write-mirror shadows of the Apple's main and aux memory banks in DDR (0x3F100000 / 0x3F110000), so this server can read the live text screen ... without touching the Apple bus at all."

The shadow also decides what the tools cannot see. The README in tools/mcp/ states the limit directly: "The memory shadows mirror writes since power-on: ROM regions and never-written RAM read as zero in apple2_peek." The same file notes that reboot and reset restart the Appletini firmware rather than the Apple II.

From a Tool Call to the Slot Pins

Every Appletini MCP tool resolves to a command on the firmware's own UART console. The tools/mcp/README.md draws the chain as "MCP client -> appletini_mcp.py -> serial UART -> ARM firmware -> FPGA fabric -> Apple II bus", and the server opens the port at 115200 baud by default, synchronising on a cmd> prompt before each command.

Generated technical diagram of the five hops, with the file that implements each one.

Registering the server takes one line, given in the repository's MCP README:

claude mcp add appletini -e APPLETINI_PORT=COM5 -- python tools/mcp/appletini_mcp.py

The console on the other end is not a toy. ps_sources/frontend/uart_control.c runs to 4,316 lines, covering video, audio, storage, USB, both coprocessors, bus diagnostics and ftp [status|on|off], and because it is a single shared channel the MCP README warns that any terminal program holding the port must be closed first.

Four Slot Addresses Mapped onto a W5100S

The Apple side of the W5100S lives in hdl/apple/uthernet2_card.sv, 838 lines of SystemVerilog that sit between the Apple II bus and the chip. Its header states the intent: "The hardware bus is intentionally close to passthrough: Apple data-port accesses normally become W5100S indirect data-port accesses."

Generated technical diagram of the address decode in hdl/apple/uthernet2_card.sv.

The card is assigned to slot 1 in apple_top.sv, and it decodes only four addresses out of the sixteen in its DEVSEL page. The comment next to the instantiation explains the split: "the SSC owns the slot ROM, the $C800 window, and DEVSEL $C0n1/$C0n2/$C0n8-$C0nF, while the Uthernet II answers only $C0n4-$C0n7." That is why appletini.org can say printing and Ethernet work at the same time from one slot.

Three details make old software work unchanged. Data-port addresses fold into the lower 15 bit W5100 space, so the high mirror lands on the same buffers, with TX at $4000 and RX at $6000. Auto-increment follows W5100 rules rather than W5100S rules, wrapping $5FFF to $4000, $7FFF to $6000 and $FFFF to $E000. Everything the W5100S adds in the $0030 to $03FF gap stays hidden except five registers that are punched through on purpose: $003C PHYSR, $0046 PHYCR0, $0047 PHYCR1, $0072 PHYLCKR and $0080 VERR, so PHY bring-up and chip identity remain reachable from Apple II software.

On the chip side the wiring is ordinary and the constraints file names every pin. hdl/constraints/appletini_yarz.xdc places eth_d[7:0], eth_a[1:0], eth_rd_n, eth_wr_n, eth_cs_n, eth_rst_n and eth_int_n in bank 35 as LVCMOS33. The fabric runs at 133 MHz, holds a read or write strobe for 16 cycles, roughly 120 ns, after a 2 cycle setup, and after a reset it holds RST# for 10 ms then waits a further 61 ms before it trusts the chip.

The ARM firmware reaches the same W5100S through a second port on the same module, and the state machine arbitrates those requests against Apple cycles, latching a host request that collides with an Apple access rather than dropping it.

MACRAW for DHCP, Hardware Sockets for FTP

The firmware uses the W5100S in two different ways, and the difference is worth stating precisely. Its DHCP client runs in MACRAW mode. ps_sources/frontend/uthernet2_control.c splits socket memory 4+2+1+1 KB through RMSR and TMSR, writes 0x44 to socket 0's mode register, opens it, and refuses to continue unless the status register reads 0x42.

static int w5100_raw_open(const uint8_t mac[UTHERNET2_MAC_LEN])
{
    uint8_t state;

    if (w5100_close_sockets() != 0 ||
        uthernet2_write_reg(W5100_REG_RMSR, W5100_SOCKET_MEM_4_2_1_1) != 0 ||
        uthernet2_write_reg(W5100_REG_TMSR, W5100_SOCKET_MEM_4_2_1_1) != 0 ||
        w5100_write(W5100_REG_SHAR, mac, UTHERNET2_MAC_LEN) != 0 ||
        uthernet2_write_reg(
            uthernet2_w5100_socket_reg(0U, W5100_SN_MR),
            W5100_SN_MR_MACRAW_MF) != 0 ||
        uthernet2_w5100_socket_command(0U, W5100_CR_OPEN) != 0 ||
        uthernet2_w5100_socket_status(0U, &state) != 0 ||
        state != W5100_S0_SR_MACRAW) {
        return -1;
    }
    return 0;
}

Everything above the frame is written by hand: the same file builds the Ethernet, IPv4 and UDP headers for each DISCOVER and REQUEST, then parses the offer back out of a raw frame. The factory default MAC is 02:41:50:50:4C:01, whose middle four bytes, 0x41 0x50 0x50 0x4C, spell APPL in ASCII, and the configuration help warns that "It may take up to 20s for DHCP to complete".

Generated technical diagram. Two of the three paths use MACRAW; only the FTP server lets the chip run TCP.

The Apple II programs in software/appletini_webserver/ take the same MACRAW route. Their README says "the W5100 runs one MACRAW socket and the 6502 handles ARP, IPv4, and TCP in software", using a trimmed IP65 library pinned to cc65/ip65 commit 25a9c5aa, and ip65/SOURCE.txt records that its Apple II driver "wraps the Contiki W5100 MACRAW driver".

The FTP server is the exception, and it is recent. ps_sources/frontend/ftp_sd_service.c arrived on 18 August 2026 in a commit titled "Add exclusive SD card FTP sharing (#5)", and it opens the chip's own TCP sockets: mode register 0x01, the LISTEN command, then status polling against 0x14, 0x17 and 0x1C, with control on port 21 and a passive data port at 50000. The shared header explains why both drivers use one socket-memory definition: "Keep all users on this one definition so raw DHCP and TCP services cannot drift apart." The menu help is blunt about the service: "Starts anonymous read/write FTP access to the SD card on TCP port 21", limited to the configured local subnet, and "Use this only on a trusted LAN: FTP sends file data without encryption."

A Repository Written to Be Driven by Agents

Two files show that the MCP server is not a bolt-on. The repository's AGENTS.md carves out a section called "Agent-Runnable Hardware Workflows" that lists exactly which hardware commands an agent may run, including "Codex may run vivado -mode batch -source scripts/build_and_export_xsa.tcl to build the PL project" and, with a physical precondition attached, "Codex may run xsdb .\scripts\launch_amp.tcl to run the frontend through JTAG; the Apple computer must be powered on."

The second file is docs/CODE_REVIEW_2026-08-20_MAIN_LAST3.md, a 61 KB review of the three most recent commits, dated 20 August 2026. It records its own method: "Ten finder agents produced 56 candidate findings ... Tally: 13 CONFIRMED, 3 PLAUSIBLE, 13 REFUTED." Several findings concern the W5100S paths, including a fixed passive port that accepts the first connection on the subnet and a CLOSE_WAIT case that truncated downloads.

Testing sits alongside that. The repository holds 67 test_*.py regression scripts, and scripts/test_uthernet2_card.py is unusually specific: it asserts that IP65's driver reaches slot 1 at $C094 to $C097, that Contiki's MACRAW setup still lands on socket 0 registers at $0400 with buffers at $4000 and $6000, and that RetroMate's default RMATE3 pathname correctly fails when the only Ethernet card is in slot 1. Those are source-text checks, not simulation or hardware runs.

What Is Published and What Is Not

The firmware and FPGA sources are public under GPL-3.0, with third_party/ and the bundled IP65 library keeping their own terms, and the repository ships the Rev.A3 schematic as a 37 sheet PDF. Ten firmware releases exist, from F0.9.0 on 14 July 2026 to F0.9.97 on 18 August 2026, seven of them in August alone, and FIRMWARE.BIN grew from 3,495,052 to 4,248,140 bytes across that span.

What does not exist yet is field evidence. The card has not shipped, no photograph of an assembled board is published anywhere, no throughput figure is given for the Ethernet path, and the repository showed 2 stars, 0 forks and no open issues on 21 August 2026. The honest reading is a well documented pre-production project rather than a proven one.

Related WIZnet Maker Projects

Uthernet II Ethernet card for the Apple II series is the physical card Appletini ONE imitates, built by a2retrosystems around the same W5100 register model, and both answer at $C0n4 to $C0n7 in an Apple II slot. The difference is that Appletini ONE rebuilds that interface in FPGA logic in front of a W5100S and shares the slot with a virtual Super Serial Card, which is why one card can print and network at the same time.

Apple II Web Server Written In BASIC shows the software half of the same idea, a 6502 machine serving HTTP through a W5100. Appletini ONE ships its own version, A2WEBSRV.SYSTEM, built with cc65 and IP65, and both confirm the same constraint: on a 1 MHz machine the chip becomes a raw frame pipe and the stack runs on the CPU.

Uthernet II Snooper CDA is a desk accessory that watches W5100 register traffic from inside the Apple II. It answers the same visibility question as apple2_bus_trace, from the opposite side: the snooper runs on the machine being observed, while the Appletini tool reads a trace ring in the FPGA and hands it to an agent over serial.

How Does BREMA Make a KNX Stick Its Own MCP Server, and Where Does PoE W5500 Fit? covers the other shape of the same trend, a WIZnet-equipped device that answers MCP itself over HTTP. Appletini ONE keeps the server on the host and reaches the hardware over UART, the more conservative arrangement, and needs no network stack in the firmware for the agent path to work.

FAQ

Q. What does Appletini ONE use the W5100S for? The W5100S is the Ethernet controller behind the card's virtual Uthernet II, reached from the Apple II at slot addresses $C0n4 to $C0n7 and from the ARM firmware through a second port in the same FPGA module. It carries Apple II network software, the card's DHCP client and the SD card FTP server.

Q. Does the card use the W5100S hardware TCP/IP stack? Partly. The DHCP client and the bundled Apple II programs use MACRAW and run their own protocol stacks, while the FTP server added on 18 August 2026 opens real TCP sockets on the chip with mode register 0x01 and listens on port 21.

Q. Will existing Apple II Ethernet software work with it? The FPGA reproduces the W5100 software model, including the address folding and auto-increment wrapping that Uthernet II drivers assume, and scripts/test_uthernet2_card.py checks that IP65, Contiki and RetroMate probe sequences still land where they expect. The card must be enabled in slot 1 for those probes to succeed.

Q. Can an AI agent type on the Apple II keyboard through MCP? No. apple2_menu_key drives the Appletini configuration menu only, and the repository states that the MCP server does not inject Apple keyboard input, so reads and card settings are the extent of it.

Q. Can I buy one, and what is the source licence? appletini.org takes free reservations at approximately EUR 300 in the European Union and USD 450 in the United States plus shipping, with shipping stated to start in September 2026 and pricing described as indicative. The repository is GPL-3.0, while third_party/ components and the bundled IP65 library keep their own licences.