v1.0.5

One fix to the serial card, and a note about which card it is.

What changed

• Echo mode now echoes on both links. With receiver echo mode on (command
  register bit 4), the ACIA sent each received byte back out of the USB console
  only. On the real R6551 the echo goes out on TxD, and on this machine TxD is
  both the USB console and the side-header UART, like every other byte the
  machine sends. So a terminal on the side header never saw its own echo. It
  now does. Nothing in BIOS v1.6 turns echo mode on, so this only affects
  programs that set the command register themselves.
• The serial card is now named. The ACIA models the standard Serial Card
  with its CTS EN jumper at ground, which is how every board is built: CTS,
  DCD and DSR are all tied low, so CTS never stops the transmitter and DCD never
  stops the receiver. The firmware already worked this way. The source and the
  README now say so, and say why no other model makes sense here: neither the
  USB console nor the side header has RTS or CTS wires.
• The version in the binary info is 1.0.5, matching the tag.

Nothing else changed in the emulated machine, the embedded BIOS, the video,
the sound or anything on the SD card. The ROM image is still the v1.6 tag's
BIOS.bin, SHA-256 4b4154af…e210d8c56.

Install

Hold BOOTSEL, plug the Pico in, and copy the matching .uf2 onto the drive
that appears.

Board	File
Pico 1 (RP2040)	6502-picocalc-pico.uf2
Pico 2 (RP2350)	6502-picocalc-pico2.uf2

They are not interchangeable.

v1.0.4

If you have ever used Load ROM in the launcher, your machine has been
running that ROM ever since — not the built-in BIOS, and not the BIOS v1.6 that
v1.0.3 was released to ship. This release puts it back.

Read this first

A ROM loaded from the SD card is written to the top of flash. A .uf2 rewrites
the firmware at the bottom of flash and leaves the top alone. So a ROM loaded
once, months ago, quietly outlived every firmware update since — which is
correct for something standing in for a chip in a socket, right up until the
update is the one that changes the chip it is standing in front of.

That is exactly what v1.0.3 was: a release whose headline was the reissued BIOS
v1.6. A machine with a BIOS v1.5 in the ROM socket flashed it and came up
running v1.5. Nothing said so. The only place it was visible at all was the
ROM: line on the launcher's own screen, which nobody had a reason to open.

v1.0.4 clears the ROM socket once, on first boot. The machine comes up on
the built-in BIOS v1.6, which is what flashing a firmware release is meant to
mean. Nothing is destroyed: the image is still in flash, the file is still in
/ROMs on the SD card, and Load ROM puts it back in two keystrokes. A
loaded cartridge is not affected, and neither are your settings, the RTC's
NVRAM or CF.IMG.

If you have never loaded a ROM from the SD card, you were on the built-in BIOS
all along and nothing about your machine changes.

What changed

• The firmware now knows which BIOS it replaced. Loading a ROM records a
  checksum of the built-in BIOS as it stood at that moment. If a later firmware
  ships a different one, the machine says so on its own screen at boot: it names
  the ROM in the socket, says the built-in BIOS is newer, and points at F1 →
  Restore built-in BIOS. Any key dismisses it and it clears itself after ten
  seconds, so an unattended boot is never held up. It is shown once per
  power-on and keeps coming back while it is still true — the machine really is
  not running the BIOS the firmware ships — and restoring the built-in BIOS, or
  loading your ROM again over the current one, ends it. The same warning sits
  on the launcher's header in the meantime.
• The launcher names the BIOS version. Where the header used to read
  ROM: BUILT-IN BIOS, it now reads ROM: BUILT-IN BIOS v1.6, read out of
  the image's own banner rather than written down beside it. "Which BIOS is
  this machine actually running" is answerable at a glance, which it was not.
  The serial console says the same thing at boot: ROM: built-in BIOS v1.6.
• A cartridge survives the change. The stored media record changes shape,
  which is what clears the ROM socket, but a loaded cartridge is carried across
  rather than dropped. It is not a BIOS and it is not what went wrong.
• The version in the binary info is 1.0.4, matching the tag.

No change to the emulated machine, the embedded BIOS, the video, the sound or
anything on the SD card. The ROM image is still the v1.6 tag's BIOS.bin,
SHA-256 4b4154af…e210d8c56.

Install

Hold BOOTSEL, plug the Pico in, and copy the matching .uf2 onto the drive
that appears.

Board	File
Pico 1 (RP2040)	6502-picocalc-pico.uf2
Pico 2 (RP2350)	6502-picocalc-pico2.uf2

They are not interchangeable. See
The ROM socket in
the README for how a loaded ROM and a firmware update get on from here.

v1.0.3

Warning

If you have ever used Load ROM in the launcher, this release did not give
you BIOS v1.6. A ROM loaded from the SD card lives at the top of flash and a
.uf2 only rewrites the bottom, so a ROM loaded once — even months ago — kept
running after this update, and nothing said so. Machines flashed with v1.0.3
for its reissued BIOS v1.6 have been booting whatever ROM was in the socket
instead.

Flash v1.0.4,
which clears the ROM socket once on first boot and puts the machine back on
the built-in BIOS v1.6. Nothing is lost — the image stays in flash, the file
stays on the SD card, and a loaded cartridge, your settings, NVRAM and
CF.IMG all carry over. From v1.0.4 on, the firmware says so on screen when a
loaded ROM is standing in front of a newer built-in BIOS.

---

A patch release: serial flow control that works, on both links.

Two things land together. The embedded ROM is the reissued BIOS v1.6 — same
version, same banner, new bytes — and the emulated 6551 ACIA now models the
Rockwell R6551 exactly, including the part that made the old ROM hang.

What changed

• A long paste into BASIC arrives whole. Paste more than about 240 bytes
  into the serial console — over USB or the side header — on v1.0.2, and input
  stopped for good; sometimes the machine stopped answering altogether,
  mid-reply, and ignored Return and Ctrl-C. That is fixed. On the bench against
  a real R6551, pastes up to 14 KB now arrive byte-perfect. The cause was a
  four-part fault in 1.6's serial code: raising RTS also stops the
  transmitter, so BASIC's echo deadlocked the machine; the interrupt handler
  could store a character twice; the input ring could lap itself and lose 256
  bytes; and every echo reopened a gate the flooded buffer needed closed. The
  water marks are now $C0/$80, and XMODEM is exempt throughout. See the
  6502-BIOS v1.6 release
  for the whole story.
• The ACIA is the R6551, not an approximation of it. DSR and DCD are active
  low, so the permanently connected, permanently ready peer on the other end of
  the USB console and the side header reads 0 in both bits, where this card used
  to set DSR and mean the opposite. Clearing DTR turns the receiver, the
  transmitter and the interrupts off. A TIC of 00 raises RTS and stops the
  transmitter, which was settled on the bench against a real chip and against
  Rockwell's own 1981 datasheet, which has it wrong. The transmit interrupt
  follows TIC 01 alone, a status read clears the interrupt flag and nothing
  else, and the receive error flags clear on a data read, where the datasheet
  puts them.

What that second half means in practice: serial code you write here behaves the
way it behaves on a real AC6502 with a real Serial Card. Code that hangs a
board now hangs the PicoCalc too, instead of running and then surprising you at
the bench. Nothing in the BIOS, BASIC or any cartridge reads the DSR or DCD
bits, so nothing you already have changes behaviour.

No changes to the launcher, the video, the sound or anything on the SD card.
Settings, cartridge state and NVRAM carry over from v1.0.2. A BIOS image you
have put in /ROMs yourself still loads; if it is one of the serial builds from
before this fix, it will now hang on a long paste exactly as it does on a real
board, and the cure is the reissued BIOS.bin from the 6502-BIOS v1.6 release.

Install

Hold BOOTSEL, plug the Pico in, and copy the matching .uf2 onto the drive
that appears.

Board	File
Pico 1 (RP2040)	6502-picocalc-pico.uf2
Pico 2 (RP2350)	6502-picocalc-pico2.uf2

They are not interchangeable. See the
README for SD card layout
and first-boot notes.

v1.0.2

A patch release: the embedded ROM is now BIOS v1.6.

What changed

• BIOS v1.6 replaces v1.5. It is the last 1.x release, and the PicoCalc, as a TMS9918A machine, stays on it. See the 6502-BIOS v1.6 release for the full notes.
• NVRAM save slots. Six new Kernal calls, NvStat, NvRead, NvWrite, NvErase, NvFind and NvFormat, turn the clock card's 256 bytes into 16 slots of 14 bytes. Each slot has an owner ID and a checksum, so a program can tell no save from a damaged one. The NVRAM here is kept in flash and committed about two seconds after the last write, so give a save that long before switching off.
• The clock card is found even if a program left it in burst mode. Before 1.6, that state made the BIOS's probe miss the card entirely.

No changes to the rest of the firmware, the launcher, or anything on the SD card. Settings, cartridge state and NVRAM carry over from v1.0.1.

Install

Hold BOOTSEL, plug the Pico in, and copy the matching .uf2 onto the drive that appears.

Board	File
Pico 1 (RP2040)	6502-picocalc-pico.uf2
Pico 2 (RP2350)	6502-picocalc-pico2.uf2

They are not interchangeable. See the README for SD card layout and first-boot notes.

v1.0.1

A patch release: the on-device launcher is now black and white.

What changed

• The launcher's blue color scheme is replaced with grayscale — black background, mid-gray secondary text, a light-gray title and key bar with black text, and a white status line. Selected rows still invert to black-on-white.

No changes to the machine, the BIOS, or anything on the SD card. Settings and cartridge state carry over from v1.0.0.

Install

Hold BOOTSEL, plug the Pico in, and copy the matching .uf2 onto the drive that appears.

Board	File
Pico 1 (RP2040)	6502-picocalc-pico.uf2
Pico 2 (RP2350)	6502-picocalc-pico2.uf2

They are not interchangeable. See the README for SD card layout and first-boot notes.

v1.0.0

The A.C. Wright AC6502 running on a ClockworkPi PicoCalc, as a complete replacement for the device firmware. One .uf2, no host needed: it boots the real 32 KB BIOS ROM byte-for-byte, probes its I/O slots, shows the splash, and drops into BASIC.

Install

Hold BOOTSEL, plug the Pico in, and copy the matching .uf2 onto the drive that appears.

Board	File
Pico 1 (RP2040)	6502-picocalc-pico.uf2
Pico 2 (RP2350)	6502-picocalc-pico2.uf2

They are not interchangeable. See the README for SD card layout and first-boot notes.

The machine

Every card the family has, emulated against the BIOS's own probing:

• TMS9918 VDP on the 320x320 LCD — Graphics I/II, Text, Multicolor, sprites
• SID synthesised to the PWM speaker
• 65C22 VIA — the PicoCalc's keyboard through the BIOS's own IRQ path, and its keys standing in for a joystick
• 6551 ACIA — USB CDC and the side-header UART at once, XMODEM included
• DS1511Y RTC on the Pico's always-on timer, NVRAM in flash
• CompactFlash backed by a growable disk image on the SD card
• Banked expansion RAM — 16 KB on RP2040, 256 KB on RP2350

On-device

F1 opens the launcher from anywhere, even inside a cartridge that has hung the machine. Browse the SD card for programs, cartridges and ROMs; a cartridge stays in the slot across a power cycle, like the chip it stands in for. Settings (clock speed, expansion size, backlight, sleep timeout) persist in flash. Reset keeps RAM, power cycle clears it — the same two things the desktop emulator offers.

Known limits

• Speed. ~228 kHz effective 6502 clock, boot-to-BASIC around 29s on a Pico 1, against the 1-2 MHz originally hoped for. The BIOS is read from flash over XIP on every instruction fetch; copying its top 24 KB into RAM is the fix and it does not fit on either board — ~6 KB short on RP2040 even after giving up the expansion RAM card, ~9 KB short on RP2350. Closing the gap meant shrinking a core's stack untested, so it was left slow and stable. A Pico 2 has room to revisit this.
• Battery is shown raw. The keyboard controller's two bytes have no documentation to check them against, so the settings screen reports them as-is rather than inventing a percentage.
• The clock is not battery-backed on this board. Time survives a reset but not a power cycle, and comes up at the firmware's build timestamp until SETTIME/SETDATE.

Built on 6502-BIOS, 6502-EMULATOR, 6502-DEV, vrEmu6502, and clockworkpi/PicoCalc.