ikejiのblog

2026W36

Tue, 08 Sep 2026 11:31:16 +0900

20260901
- X260
- サスペンドしてた状態で、
- TanCon
  - ILI9488をつけた上で、消費電力を測りたい。
  - とりあえず付けたら5V250mAぐらいだった。
    - バックライトの輝度が100%だから、暗くしたら消費電力減るかも。
  - プロンプトが出るまで8分ぐらいになる。

20260902
- TanCon
  - 速くしてって頼んだら、30秒ぐらいでプロンプトが出るようになった。
    - 文字出力が遅い。

20260903
- テトリス
  - AIに豪華なテトリスを作ってもらった。
  - https://github.com/ikeji/aitest
- TanCon
  - 10fpsをめざしてって頼んだら、4fpsまではできたらしい。
  - 文字描画がハードウエアになった。

20260904
- テトリス
  - もっとAIに豪華なテトリスを作ってもらった。
  - indexページを作ってもらった。
  - https://ikeji.github.io/aitest/index.html
20260905
- テトリス
  - もっとAIに豪華なテトリスを作ってもらった。
    - めぼしいモデルはカバーしたか?
- Maker Faire Tokyo 2026
  - 新しい会場
    - 広くなって、列と列の間があいた
    - 企業ブースに企業サークルが入ってる
  - おもしろかったもの
    - ヒューマノイド販売中
    - スパチャ貯金箱
    - 鳩時計
    - 人力ホバークラフト
20260906
- 家のLAN
  - 部屋間の配線を光ケーブルにしたい。
  - PCIe <-> SFP+のカードがみあたらない。
  - いっかいやすみ。

2026W35

Tue, 01 Sep 2026 22:43:54 +0900

20260824
- fakedl
  - DisplayLinkデバイスのふりをするRaspberryPi Picoファームウエア
  - 作って動作確認せず放置してた。
  - - 動いた。
  - githubに置いた。
  - https://github.com/ikeji/fakedl
20260826
- PiCon2350
  - ちょっとはんだ付けを進めた。
20260827
- TanCon
  - TangNano 20kでRISCVを作ってもらいはじめた。
  - 寝ておきたら、OSが動いてた。
20260828
- TanCon
  - 1秒以下で起動するはずが、起動が20倍ぐらいおそかった
  - 聞いたらFlashもメモリもCPUも遅いせいだと言われた
  - 勧められるままDMAを付けてもらう

2026W34

Tue, 25 Aug 2026 22:41:27 +0900

20260818
- mytinydock
  - dzen使ってたけど、別の欲しくなった。
  - wmdockとか探してたけど、packageにない。
  - 作ればよくねってなって、作った。
  - https://github.com/ikeji/mytinydock
20260819
- EVO X2
  - Qwen3.8
  - 試した。
  - Q4でMTP入れても25tpsぐらい。
  - 実用には遅いか?
20260820
- Qwen3.8
  - lmake
    - 10年前ぐらいにgaucheで書いたスクリプト
    - これをguileに移植するタスク
    - gemma4では成功しなかった。
    - Qwen3.8では数時間かかったが成功した。
  - Opusにテストを書かせ、それが通るようにと指示したら、Qwen3.6でも成功した。
    - もっと難しいタスク考えないとな。
20260822
- fuchikoma
  - 新しいリモートログイン用PC
  - Core(TM) i5-13500H
  - メモリが64GB、NUMEが1Tあるぞ。
  - memtestは通った。
  - とりあえずDebianを入れる。
20260823
- fuchikoma
  - Octane benchmarkを走らせたい。
  - 一旦Desktop入れるのも嫌なので、USB-SSDにUbuntuを入れて計測
  - Octane score: 80590
  - デスクトップ版のCore i5-12400と同等か。
    - なかなか速い。
  - 前のPCは38000点ぐらいだったはず。
  - llamafile 182tps/33tps
    - 前のPC(Core i5-7267U)は 73tps/14tps
    - EvoX2は 632tps/98tps

wget https://huggingface.co/mozilla-ai/Llama-3.2-1B-Instruct-llamafile/resolve/main/Llama-3.2-1B-Instruct-Q6_K.llamafile
./Llama-3.2-1B-Instruct-Q6_K.llamafile -p 'Please describe what is LLM and how it works?'

2026W33

Tue, 25 Aug 2026 22:41:06 +0900

20260813
- X260
  - また再起動した。
  - ヒンジを調節したとき。
20260816
- EVO X2
  - 再セットアップした。
  - 今度はDockerベースでセットアップしてる。
  - GemmaとQwenを動かしたい。
    - 量子化とMTPの深さを追い込みたい。
    - Gemma4 26B-A4B: Q5KMでMTP=3が一番速かった。100tps
    - Qwen3.6-35B: Q4KXL MTP=3が75tps
    - MTPなしだとQ4のほうが速いけど、MTPありだとQ5の方が速いとか面白い。
20260817
- EVO X2
  - DeepSeekが動かなくなった。
  - 再セットアップ前は動いたんだが。
  - メモリの設定だろうか。

2026W32

Wed, 12 Aug 2026 12:03:54 +0900

20260805
- 新Linux Box
  - 今のはメモリもSSDも足りない。
  - ファンレスだから熱くなると計算力も心配
  - 今は時期がわるいのは承知の上で、新しいミニPC買いたい。
  - GMKTec M3 Proがよさそうかな?
    - 64GBモデルがあり、N100(32GB上限)よりメモリが積める。
    - DDR4なので、DDR5よりはメモリが安そう。
    - Core i5-13500HはN100よりだいぶ早いだろう。
20260805
- 新Linux Box
  - 買おうとしたら、カードが弾かれた。
  - 1000ドル越えるとダメなのかとおもったが、500ドル越えでもダメなのかも。
  - とりあえず、CPU/Memory/NVMEを分けて買った。
20260806
- steptest
  - GUIとコードベースの間を行き来する感じのCADを作りたい。
  - 真面目に設計するの面倒だけど、とりあえずPoCみたいなのをAIに作らせたらいいのでは?
  - https://ikeji.github.io/steptest/
  - できた。
20260807
- steptest
  - ぽちぽち、機能強化してる。

2026W31

Tue, 04 Aug 2026 12:01:10 +0900

20260727
- PiCon2350
  - ケースとして動くようになってきた。
20260729
- PiCon2350
  - 細かいところを修正
  - 画面はもっと薄いし、キーボードはもっと厚い。
20260730
- PiCon2350
  - 厚さを調節したら、開閉がきつくなった。
  - 原因わからん。
20260731
- PiCon2350
  - 調整したけど、解決できない。

2026W30

Mon, 27 Jul 2026 22:40:33 +0900

20260720
- HDD
  - 10Tぐらい入れてscrubした。
  - 問題なし
20260722
- PiCon2350
  - 腰が重過ぎたので、ケース作りをAIにやらせてみる。
20260723
- PiCon2350
  - 印刷してみた。
  - アイディアはよさそう。
20260724
- PiCon2350
20260725
- PiCon2350
- P1S
  - 印刷中にフィラメントが切れた。
  - 21.5kgつかった。

DOSCON: A Handheld MS-DOS Machine Running on Two AAA Batteries

Tue, 21 Jul 2026 22:09:28 +0900

日本語版もあります。

Last time, I put a real V30 CPU on an RP2040 “cradle” and booted MS-DOS (HIDOS) on it.

At the end of that article, I listed three things as “future work”:

Add disk write support, so I can develop software on the machine itself
Upgrade to the RP2350 to get more memory
Turn it into a portable terminal with its own screen and keyboard

This time, I did all of them. The result is called DOSCON.

It still carries a real V30 chip. It runs on two AAA batteries, and a few seconds after power-on you get the A> prompt. It has an LCD and a keyboard, it can read and write Japanese text on its own, and you can write a program in vi (self-made), assemble or compile it, and run it — all without leaving the machine.

The PCB (KiCad), the case (3D printed), the firmware (C++), and the DOS tools running inside: I built the whole stack myself.

Motivation

The previous machine’s only connection to the outside world was USB, so it needed a PC. But putting a PC that is hundreds of times faster than a V30 next to it, just to use it as a dumb terminal, felt completely backwards. The V30 is the star of the show, so the V30 should be self-sufficient. This time, the goal was a standalone machine.

And if it was going to be standalone, the shape was already decided. When I was in elementary school, I used to look at the Game Boy and daydream: “What if this had a keyboard instead of a controller, and I could write programs on it?” Take the V30 that was inside the PC-98 I used back then, and the C compiler I used back then, and put them into the box I wanted back then. In other words, this is answering a 30-year-old wish.

What Changed Since Last Time

The CPU-side architecture is the same “cradle” approach as before. The real V30 is the bus master, and the RP2350 plays the role of memory, I/O, and every peripheral. The RP2350 has two cores, so I split the work:

core1: Dedicated to V30 bus control. It watches ALE/RD/WR and moves data in and out of memory in step with the bus cycles
core0: Handles I/O requests, the screen, the keyboard, and USB

Since the V30 is the star, the case has a window so you can see the real chip.

The essential differences from the previous machine are three:

It runs standalone on batteries. No PC required — it works as a complete machine on two AAA batteries, with its own screen and keyboard
More RAM, enough to run a C compiler. Up from 128KB to 448KB. Not just MASM/LINK — even a C compiler runs on the machine now
It has a RAM disk. The biggest piece of unfinished business from last time — “no way to save the programs you write” — is solved

Last time, things like adjusting the clock speed were done from a monitor program on the connected PC. Now that the machine is standalone, it has a full configuration shell so you can do all of that on the device itself (the BootShell, described later).

The Big Picture

+---------------------+
|  ILI9488 LCD 320×480|   Portrait. 40×30 text (8×16 halfwidth / 16×16 fullwidth)
|  + 4×12 keyboard    |   ANSI.SYS-compatible escape sequences built in
+---------------------+
            |
+---------------------+          +----------------+
|  RP2350 firmware    |   bus    | V30 (real chip)|
|   - HIDOS host      |<========>|  μPD70116      |
|   - USB CDC × 3     | AD0-15+  +----------------+
+---------------------+   core1 handles the bus
            |  USB FS
+---------------------+
| /dev/ttyACM0  stdio |   DOS standard I/O (with SJIS↔UTF-8 conversion)
| /dev/ttyACM1  debug |   firmware logs / monitor entry
| /dev/ttyACM2  aux   |   COM1 / AUX (raw bytes, used for YMODEM transfer)
+---------------------+

Item	Previous (cradle86)	This time (DOSCON)
CPU	Real V30 (μPD70116)	Same real V30
Cradle	RP2040	RP2350 @ 250MHz
Memory	128KB	448KB + 8MB PSRAM
Display	Serial connection to a PC	Built-in LCD (40×30, Japanese support)
Keyboard	The PC’s	Built-in, 47 keys
Disk	ROM only (no writes)	ROM disk + 4MB RAM disk
File transfer	XMODEM (monitor feature)	YMODEM (DOS commands)
Power	USB	Two AAA batteries (USB-C also works)

Hardware

PCB

Designed in KiCad: RP2350 + ILI9488 + key switches + USB-C + battery holder, all on one board.

As before, component placement is generated by a Python script driving the KiCad API. For regular patterns like a key matrix, writing code beats placing parts by hand, and it makes redoing things painless.

Failure: I Miswired the SD Card

Last time the failure was “the board from the fab doesn’t work at all.” This time it was the SD card. The board has an SD card slot that was supposed to connect to the RP2350’s SPI module, but the clock and data lines ended up assigned to pins of two different SPI modules. On the RP2350, each GPIO pin can only serve specific SPI channels, so this cannot work as hardware SPI.

I had followed the AI’s recommended pin assignment, which makes this a sequel to last time’s “AI can’t read the timing charts in datasheets” incident. I did give the pin names a quick check, but I didn’t catch it. Wiring proposed by an AI should be carefully cross-checked against the pin multiplexing table.

The mistake surfaced only after I started writing the firmware. The board had long since been ordered. I should have written the firmware before ordering the board.

Fortunately the RP2350 has PIO, so it should be possible to rescue it with a software SPI. That’s future work; for now the machine’s storage is an SD-less setup (ROM disk in flash + RAM disk in PSRAM + YMODEM transfer). The goal — write code and compile it on the machine — was achieved without the SD card.

Keyboard

47 keys in 4 rows × 12 columns. The interesting part is how they’re read: a normal matrix scan would need 4+12 = 16 GPIOs, but this uses what I call a “double matrix”, which reads everything with 10 GPIOs.

Split 10 pins into 4 rows + 6 columns and a normal matrix gives you only 4×6 = 24 keys. So instead, each intersection gets two keys with their diodes facing opposite directions, and the scan runs both ways: “drive columns, read rows” and “drive rows, read columns.” That’s 2 keys per intersection, 48 positions total. The keyboard looks like 4×12 physically, but electrically its left half and right half share the same intersections in opposite directions.

After all, the V30 bus alone (AD0-19 plus control lines like ALE/RD/WR) eats close to 25 GPIOs, and then there’s the LCD’s SPI and the PSRAM’s CS. Not many pins were left for the keyboard.

Power

Two AAA batteries are boosted to 3.3V, and both the RP2350 and the V30 run at 3.3V. The boost converter is an off-the-shelf module. “A 5V-era V30 runs fine at 3.3V” was already confirmed last time, so this time the whole design is 3.3V from the start.

I later considered switching to a lithium-ion battery, but a fully charged li-ion cell exceeds 4.0V, which would probably fry this setup. Hence, dry cells.

Measured at the battery, the current draw is about 250mA. With AAA NiMH cells (around 750mAh), that’s roughly 3 hours by simple arithmetic. If you want more, AA cells (around 2000mAh) should give 8 hours, and doubling from 2 cells to 4 should double that again.

Case

3D printed. The modeling is not done in a CAD GUI but written as code — JavaScript for replicad. The keycaps are self-made too; the legends are SVGs generated by my own script and printed in via multi-color 3D printing. Looking back at the commit log, late April through May went almost entirely into tweaking the case and keycaps.

Why does the case take so long? Because you can’t run an AI agent loop on it. For firmware, the loop of “AI writes code → tests fail → AI fixes it” runs on its own. For a case, the feedback loop is: print it, fit it against the real thing, adjust dimensions, print again… and a human has to do that with their body. One iteration takes hours, and you can’t write tests for it. In the AI era, the enclosure is the biggest bottleneck in electronics projects.

Carrying HIDOS Around on Batteries

The OS is HIDOS, same as last time. HIDOS, created by my senior hdk, is an environment for self-hosting builds of the MS-DOS 2.11 source that Microsoft open-sourced, and it comes with a minimal VM configuration (hidosvm): one do-everything virtual device, plus a BIOS with exactly one call that invokes it.

I again use my fork as a submodule, but the quick-and-dirty fixes I made last time have since been properly fixed upstream, so the fork’s only remaining diff is build script customization. Not a single line of HIDOS code is modified. VM_IO.SYS is untouched too. The cradle went from RP2040 to RP2350, and the machine gained a screen, a keyboard, and Japanese text — yet the DOS side needed zero changes. I’d call that a victory for hidosvm’s design of “put all the complexity on the VM side.” The beauty of this approach is that you implement no BIOS, no 8253 timer, no 8259 PIC, no CRT controller — none of it. Every console, disk, and serial access from DOS arrives at the RP2350 as a simple protocol over I/O ports. When the V30 executes an I/O instruction, core1 — which is watching the bus — detects it and raises a shared flag, and core0’s host loop picks it up and dispatches to the console/disk/AUX handlers.

Memory Map

The V30 sees 448KB of memory, 3.5× the previous 128KB. The memory’s real body is an array in the RP2350’s internal SRAM, with core1 moving data in and out in step with the V30’s bus cycles. In other words, the RP2350 also plays the role of the memory chips.

The RP2350 has 520KB of internal SRAM in total; 448KB goes to the V30, and the rest is for the firmware itself — VRAM, bus control, and so on.

Virtual address	Purpose
0x00000〜	Interrupt vectors
0x00400〜	User program area
0x10000	VM_IO.SYS (virtual I/O driver) *initial placement
0x18000	MSDOS.SYS (DOS kernel) *initial placement
〜0x6FFFF	Free (DOS apps run here)
0x70000〜0xFFFEF	Nothing
0xFFFF0	Reset vector + BIOS (16 bytes)

The addresses of VM_IO.SYS and MSDOS.SYS are just where they’re loaded at boot; HIDOS relocates itself during startup.

The 448KB of RAM ends at 0x6FFFF, and there is nothing between there and the reset vector. Only the 16 bytes from the reset vector (0xFFFF0) — which the V30 fetches right after reset — get a special response from core1. The reset vector and the entire BIOS fit in those 16 bytes.

At initialization, all of memory is filled with 0xF4 (the HLT instruction) — same custom as the f command in last time’s monitor. If anything runs wild, it stops immediately.

Solving the Disk Write Problem

Last time I wrote “there’s no way to save the programs you make.” That’s now solved with a two-tier setup:

Drive A: A ROM disk baked into the firmware. COMMAND.COM and the full set of DOS tools live here
Drive B: A 4MB RAM disk (FAT) in PSRAM. Free to read and write

Last time I wrote “a RAM disk seems hard with so little memory,” but the RP2350 lets you hang 8MB of PSRAM off the secondary interface of XIP (a mechanism that maps external memory directly into the address space for reads and writes), so it turned out to be easy. Being a RAM disk, it vanishes on power-off — but the warm reboot described later, plus YMODEM transfers, soften that considerably.

The Terminal

Last time ended with “showing it on a connected PC isn’t very moving.” This time, the screen and keyboard that DOS sees are implemented entirely in the firmware.

ANSI.SYS-Compatible Escapes

In the DOS world, screen control conventionally goes through ANSI.SYS escape sequences, so I implemented the usual set: CUP (cursor movement), ED/EL (erase), SGR (colors), DECTCEM (cursor visibility). With this, DOS full-screen apps (like the vi described later) just work.

Japanese: Shift_JIS, Fonts, UTF-8 Conversion

The LCD carries an 8×16 halfwidth font for English text and a 16×16 fullwidth font for Japanese, used as a 40-column × 30-row text screen. The fonts are converted from bitmap images to C++ source by a Ruby script
The DOS side’s character encoding is, of course, Shift_JIS. The LCD interprets SJIS directly
Meanwhile, the standard I/O over USB (/dev/ttyACM0) is converted bidirectionally between SJIS and UTF-8, so a modern terminal emulator reads and writes Japanese as-is. The JIS X 0208 ↔ Unicode conversion tables are also script-generated

Existing Japanese-language software runs as-is.

PSRAM Scrollback Buffer

The text screen is only 40×30, so I gave it a 4096-line scrollback buffer in PSRAM. Tap the Fn key by itself to enter scroll mode, then move through past output with k/j or Ctrl-F/Ctrl-B. A DOS machine with less-style scrollback is surprisingly comfortable.

Tapping the Sym key toggles a double-size text mode. Kind to aging eyes.

Packing Everything Into 47 Keys

With only 47 keys, I went with the QMK-style layer approach familiar from the custom keyboard community. There are Ctrl / Shift / Sym (symbols) / Num (digits) / Fn modifiers, with priority Ctrl > Fn > Sym > Num > Shift > Base. A key with no definition on a layer falls through to the layer below (like QMK’s _______).

The Fn key additionally gets QMK Layer-Tap-style treatment:

Held with another key → Fn layer (F1–F12, cursor keys, PgUp/PgDn)
Tapped alone → toggles scroll mode
Both left and right Fn together → launches the MonitorShell (described later)

A neat side effect of the layer system: the chord detection needed no special logic — I just placed the shell-entry key at the Fn key positions on the Fn layer.

The Monitor Lives On: BootShell and MonitorShell

The spirit of last time’s monitor program (memory dump, disassembler, XMODEM…) carries over, and the firmware contains two “shells” besides DOS.

The BootShell is a settings menu you enter by holding ESC at power-on. Toggle the CPU clock, whether standard I/O goes to CDC or UART, drive configuration, UTF-8 conversion, and so on, then hit b to boot DOS.

The MonitorShell is entered while DOS is running by pressing both Fn keys (or typing anything into /dev/ttyACM1). It offers memory dump, disassembly, reset, and jumping to BOOTSEL (firmware update mode). Being able to peek into the running V30’s memory from outside is invaluable for debugging the DOS side.

My favorite feature is warm reboot: restart the machine while preserving the contents of the RAM disk (drive B).

It didn’t work on the first try, though. Once implemented, files on the RAM disk came out corrupted across reboots. To find where the corruption happened, I wrote SHA1SUM.EXE, a DOS program, took hashes of files before and after reboot, and narrowed down which data broke when.

The culprit was the XIP cache. The RP2350 accesses PSRAM through the XIP cache, so some of the data “written to the RAM disk” was actually still sitting in dirty cache lines, never having reached the PSRAM itself. Reset in that state and the cache evaporates — that was the punchline. The fix: explicitly flush the cache before jumping into the reboot.

SHA1SUM, born as a debugging tool, now ships on the disk and lives a second life as the file-transfer verification tool.

Talking to a PC: Three USB Serial Ports

Plug in USB-C and three CDC ACM devices appear. Thanks to the pico-sdk, this kind of composite serial device was easy to build.

Device	Role
/dev/ttyACM0	DOS standard I/O (parallel with the LCD, with SJIS↔UTF-8 conversion)
/dev/ttyACM1	Firmware debug log + monitor entry
/dev/ttyACM2	Direct line to DOS AUX (COM1), raw bytes

Last time I wrote “the serial port is already taken by the display, so I’ll need multiplexing or something.” A USB composite device solved it: one USB cable carries console, debug, and file transfer simultaneously.

File transfer is YMODEM over AUX. The disk ships with SX.EXE / RX.EXE, and on the Linux side plain lrzsz works.

To send a file from the PC to DOSCON, run RX on the DOSCON side, then sb on the Linux side:

A> RX /Y
$ sb HELLO.TXT < /dev/ttyACM2 > /dev/ttyACM2

And the other way around:

A> SX /Y HELLO.TXT
$ rb < /dev/ttyACM2 > /dev/ttyACM2

For verifying transfers, the checksum programs written for the warm reboot debugging (CRC32SUM.EXE / SHA1SUM.EXE) work as-is. Workflows like last time’s “LHA didn’t run, so unpack on Linux” got much smoother.

Developing on This Machine Alone, With vi and TUT-Code

For the leftover homework of “developing software on the machine itself,” the disk carries the HIDOS build artifacts (COMMAND.COM, EDLIN, DEBUG, MASM, LINK, …) plus my own VI.EXE — a vi-style editor doing full-screen control via ANSI escapes.

With RAM up to 448KB, a C compiler runs on the machine too. I installed the LSI C-86 trial version. The compiler I used in elementary school, running on the same V30 as back then — but this time on a machine I built myself. It just works.

Write FizzBuzz with copy con, compile it, run it. All inside this machine.

And perhaps the strangest part of DOSCON is kanji input: instead of an IME, vi has TUT-Code built in — a system where each kanji is typed directly with 2–3 keystrokes. I skipped the IME because there’s no memory for a dictionary. Among direct-input systems, T-Code needs more keys than this keyboard has, so I settled on TUT-Code. No candidate window, no dictionary lookup — a good match for a DOS machine with only 448KB. Japanese display works everywhere in DOS, but input currently works only inside vi.

So now the whole cycle — write source in vi → build with MASM or the C compiler → run → pull the result to a PC over YMODEM — completes on a battery-powered pocket machine, on a real V30.

Here’s Hello World assembled with MASM:

Development Log

Reconstructed from the commit log, it went roughly like this. The previous article was published on February 11 — and by then, I had actually already started designing the next board.

Early February: PCB design in KiCad, ordered
Mid February: Verified the LCD/keyboard standalone with MicroPython → firmware skeleton in C++
February 23: First implementation of the V30 bus interface and I/O handling
Late February: HIDOS as a submodule, disk image build, DOS boots
March: I/O work, SJIS/UTF-8, scrollback buffer, BootShell/MonitorShell, warm reboot
April: DOS-side tools (vi, YMODEM), README
Late April–May: Case and keycap tweaking, double-size mode, finishing touches

About four months, 74 commits.

The first time DOS came up on the LCD. From here on it was the fun phase: poking at and extending a working DOS machine.

Since I planned to hand the implementation to AI again, I built tests to excess. Every firmware class is template-parameterized and swappable, with FakeHAL/FakeScreen and friends injected into host-side gtest (no Pico SDK required), so all the logic that’s painful to debug on hardware — escape sequence interpretation, keyboard layer resolution — is verified in tests on a PC. If you build an environment where the AI can run the tests and fix its own code, software development hums along.

On the other hand, as mentioned, you can’t write tests for a case. Software where the AI loop runs, versus an enclosure where it can’t — the time spent on each flipped. That was this project’s lesson.

One more thing: I kept writing design memos in firmware/docs/ before implementing — memory map, logical key mapping, I/O specs, 13 in all. They’re good to look back on, and they became the first draft of this article.

Wrap-up and What’s Next

All three items of last time’s future work (disk writes, memory, screen and keyboard) are done. Japanese display and kanji input came along for the ride.

Having every layer from PCB to OS in your own hands means you get to decide where the boundaries between layers go (like throwing out the whole BIOS in favor of a single I/O port protocol). That’s the best part
The RP2350 has more than enough power to play “everything except the CPU.” V30 bus control, USB, and the display together still leave headroom
MS-DOS 2.11 lives comfortably in 448KB

And above all: the “Game Boy with a keyboard that I can program on” I daydreamed about in elementary school now runs on two batteries, in my hands.

Future work:

Rescue the miswired SD card with a PIO-based software SPI
And next, I’d like to move away from the V30 and build something different. I originally chose DOS on the theory that I could leverage existing DOS software — but if AI is this good at development, maybe a self-made OS, compiler, or even CPU should be on the table

Repositories:

DOSCON: https://github.com/ikeji/doscon
VI.EXE: https://github.com/ikeji/tiny-vi-clone
SX.EXE/RX.EXE: https://github.com/ikeji/xmodem
SHA1SUM.EXE/CR32SUM.EXE: https://github.com/ikeji/sha1sum
HIDOS (fork): https://github.com/ikeji/HIDOS/tree/doscon
HIDOS upstream: https://github.com/hdk1983/HIDOS

The End

Once again, I learned a lot.

Thanks to those who came before:

hdk, my senior, who created HIDOS
The people who devised TUT-Code
The custom keyboard culture exemplified by QMK
The people still maintaining lrzsz

乾電池で動く携帯MS-DOS機「DOSCON」を作った

Tue, 21 Jul 2026 22:06:28 +0900

Here is a English version.

前回、本物のV30 CPUをRP2040の「ゆりかご」に乗せてMS-DOS (HIDOS) を起動した。

その記事の最後に「今後の展望」として3つ書いた。

ディスク書き込みができるようにして、マシン上でソフトウエア開発をしたい
RP2350にアップグレードしてメモリを増やしたい
専用の画面とキーボードをそなえたポータブル端末にしたい

今回、これを全部やった。名前は DOSCON。

今回も本物のV30チップが乗っている。単4電池2本で動き、電源を入れると数秒で A> プロンプトが出る。LCDとキーボードが付いていて、単体で日本語の読み書きもできるし、vi (自作) でプログラムを書いてアセンブル・コンパイルして実行、までがこのマシンの中で完結する。

基板 (KiCad)、ケース (3Dプリント)、ファームウエア (C++)、中で動くDOSツールまで、フルスタックで必要なものを自作した。

動機

前作のマシンは、外部との接点がUSBのみだったので、別途PCが要った。でも、V30の何百倍も速いPCを隣に置いて、それをただの端末として使うのは、どうにも本末転倒だ。V30が主役なのだから、V30だけで完結してほしい。だから今回は、スタンドアローンで動作する事を目指した。

そして、スタンドアローンにするなら形は決まっていた。小学生の頃、ゲームボーイを見ながら「これのコントローラの代わりにキーボードが付いていて、プログラムが書けたらいいのに」と夢想していた。あの頃使っていたPC-98に入っていたV30と、あの頃使っていたCコンパイラを、あの頃欲しかった形の箱に入れる。つまりこれは、30年越しの答え合わせだ。

前作から何が変わったか

CPUまわりの構成は前作と同じ「ゆりかご」方式だ。本物のV30がバスマスタで、RP2350がメモリ・I/O・周辺回路のすべてを演じる。RP2350にはコアが2つあるので、分業させている。

core1: V30のバス制御専用。ALE/RD/WRを監視して、バスサイクルに合わせてメモリの中身を出し入れする
core0: I/Oハンドラ、画面、キーボード、USBの面倒を見る

主役なので、ケースの窓から本物のV30が見えるようにしてある。

前作からの本質的な違いは3つ。

スタンドアローンでバッテリ動作する。 PCに繋がなくても、単4電池2本で完結したマシンとして動く。画面もキーボードも付いた
RAMが増えて、Cコンパイラが動く。 前作の128KBから448KBになり、MASM/LINKどころかCコンパイラまでマシン上で動くようになった
RAMディスクがある。 前作最大の宿題だった「作ったプログラムを保存できない」問題が解決した

前作ではクロックの調節などはPCから繋いだモニタプログラムで行っていたが、スタンドアローンになった今作では、それも本体だけでできるように設定シェルを完備した (後述のBootShell)。

DOSCONの全体像

+---------------------+
|  ILI9488 LCD 320×480|   縦長。テキスト 40×30 (8×16 半角 / 16×16 全角)
|  + 4×12 キーボード   |   ANSI.SYS 互換エスケープを内蔵
+---------------------+
            |
+---------------------+          +----------------+
|  RP2350 firmware    |   bus    |  V30 (実チップ) |
|   - HIDOS host      |<========>|  μPD70116      |
|   - USB CDC × 3     | AD0-15他 +----------------+
+---------------------+   core1がバスを捌く
            |  USB FS
+---------------------+
| /dev/ttyACM0  stdio |   DOS の標準入出力 (SJIS↔UTF-8 変換つき)
| /dev/ttyACM1  debug |   firmware のログ / モニタ起動
| /dev/ttyACM2  aux   |   COM1 / AUX (生バイト。YMODEM転送に使う)
+---------------------+

項目	前作 (cradle86)	今作 (DOSCON)
CPU	本物のV30 (μPD70116)	同じく本物のV30
ゆりかご側	RP2040	RP2350 @ 250MHz
メモリ	128KB	448KB + PSRAM 8MB
画面	PCにシリアル接続	内蔵LCD (40×30、日本語対応)
キーボード	PCの物	内蔵47キー
ディスク	ROMのみ (書き込み不可)	ROMディスク + 4MB RAMディスク
ファイル転送	XMODEM (モニタ機能)	YMODEM (DOS上のコマンド)
電源	USB	単4電池2本 (USB-Cも可)

ハードウエア

基板

KiCadで設計して、RP2350 + ILI9488 + キースイッチ + USB-C + 電池ボックスを1枚に載せた。

前作同様、部品配置はPythonスクリプトでKiCad APIを叩いて生成している。キーマトリクスのような規則的な配置は、手で並べるよりコードで書いた方が楽だし、やり直しも効く。

失敗: SDカードの配線を間違えた

前作は「工場から届いた基板が全く動かない」だったが、今回の失敗はSDカードだった。基板にはSDカードスロットを載せていて、RP2350のSPIモジュールに繋ぐつもりだったのだが、クロックとデータが別々のSPIモジュールのピンに割り当たってしまっていた。RP2350のGPIOはピンごとに使えるSPIチャネルが決まっているので、これではハードウエアSPIとして使えない。

AIのおすすめのピン割り当てに合わせたら失敗した、という点で前作の「AIにデータシートのタイミングチャートは読めない」事件の続編でもある。一応ピン名を軽くチェックはしたのだが、見つけられなかった。AIの提案する配線は、ピンマルチプレクサの表ときちんと突き合わせるべきだった。

このミスが発覚したのは、ファームウエアを書き始めてからだった。基板はとっくに発注済み。基板を発注する前に、ファームウエアを先に作っておくべきだった。

幸いRP2350にはPIOがあるので、ソフトウエアでSPIを生やして救済できそうではある。これは今後の課題として、現状このマシンのストレージはSDカードなしの構成 (Flash上のROMディスク + PSRAMのRAMディスク + YMODEM転送) に落ち着いた。コードを書いてコンパイルするという目標は、SDカードなしで達成できた。

キーボード

4行×12列で47キー。面白いのは読み取り方で、普通のマトリクススキャンだと4+12 = 16本のGPIOが要るところを、「倍マトリクス」と呼んでいる配線で、10本のGPIOで読んでいる。

10本を行4本+列6本に分けると、普通のマトリクスでは4×6 = 24キーしか読めない。そこで各交点に、ダイオードの向きを逆にした2つのキーをぶら下げて、「列を駆動して行を読む」「行を駆動して列を読む」の両方向でスキャンする。これで交点1つから2キー、合計48ポジションが読める。物理的には4行×12列に見えるキーボードの左半分と右半分が、電気的には同じ交点を逆向きに共有している形だ。

なにしろV30のバス (AD0-19 + ALE/RD/WRなどの制御線) だけでGPIOを25本近く持っていかれる上に、LCDのSPIやPSRAMのCSもあるので、キーボードに回せるピンは限られていた。

電源

単4電池2本を3.3Vに昇圧して、RP2350もV30も3.3Vで動かしている。昇圧は市販の昇圧モジュールをそのまま載せた。「5V用のV30を3.3Vで動かしても動く」というのは前作で確認済みなので、今回は最初から3.3V一本の設計にした。

後から、リチウムイオン電池にしようかとも考えた。しかし、フル充電のリチウムイオン電池は4.0Vを超えるので、この構成では壊れそうだ。というわけで乾電池にしている。

電池側で消費電流を実測してみたら約250mAだった。単4のニッケル水素電池 (750mAhくらい) なら、単純計算で3時間くらいは動く事になる。もっと動かしたいなら、単3 (2000mAhくらい) にすれば8時間動くはずだし、2本を4本にしたら、更に倍の時間動くはずだ。

ケース

3Dプリント。モデリングはCADのGUIではなく、replicad用のJavaScriptでコードとして書いている。キーキャップも自作で、刻印は自作のスクリプトでSVGを生成して多色3Dプリントで入れた。コミットログを見返すと4月末〜5月はほぼケースとキーキャップの調整に費やしていた。

なぜケースにこんなに時間がかかるかというと、AIのエージェントループが回せないからだ。ファームウエアなら「AIが書く → テストが落ちる → AIが直す」のループを勝手に回してくれるが、ケースは印刷して、実物に合わせて、寸法を直して、また印刷して…のフィードバックを人間が身体でやるしかない。1周に数時間かかるし、テストも書けない。AI時代の電子工作は「ガワ」が一番のボトルネックだ。

HIDOSを電池で持ち歩く

動かしているOSは前作と同じ HIDOS だ。hdk先輩のHIDOSは、Microsoftが公開したMS-DOS 2.11のソースをセルフビルドできる環境で、「何でもできる仮想デバイスが1つ+それを呼ぶBIOSコールが1つだけ」というミニマルなVM構成 (hidosvm) が用意されている。

今回もforkをサブモジュールとして組み込んでいるが、前作で適当に動くようにした修正は、本家で正式に修正されたので、今のforkの差分はビルドスクリプトのカスタマイズだけ。HIDOSのコードには一切手を入れていない。VM_IO.SYSもそのままだ。ゆりかごがRP2040からRP2350になり、画面もキーボードも日本語も付いたのに、DOS側はノータッチで済んだ。「複雑さは全部VM側に置く」というhidosvmの設計の勝利だと思う。

この方式の何が良いって、BIOSも8253タイマも8259 PICもCRTコントローラも一切実装しなくていい事だ。DOSからのコンソール・ディスク・シリアルへのアクセスは、全部I/Oポート経由のシンプルなプロトコルになってRP2350に届く。V30がI/O命令を実行すると、バスを見ているcore1がそれを検出して共有フラグを立て、core0のホストループが拾ってコンソール/ディスク/AUXのハンドラに振り分ける。

メモリマップ

V30から見えるメモリは448KB。前作の128KBから3.5倍だ。メモリの実体はRP2350の内蔵SRAM上の配列で、core1がV30のバスサイクルに合わせて出し入れしている。つまりRP2350が「メモリチップ」の役も演じている。

RP2350の内蔵SRAMは全部で520KBあり、そのうち448KBをV30に渡して、残りをVRAMやバス制御などファームウエア自身のために使っている。

仮想アドレス	用途
0x00000〜	割り込みベクタ
0x00400〜	ユーザプログラム領域
0x10000	VM_IO.SYS (仮想I/Oドライバ) ※初期配置
0x18000	MSDOS.SYS (DOSカーネル) ※初期配置
〜0x6FFFF	空き (DOSアプリはここで動く)
0x70000〜0xFFFEF	何もない
0xFFFF0	リセットベクタ + BIOS (16バイト)

VM_IO.SYSとMSDOS.SYSのアドレスはブート時にロードされる初期値で、HIDOSが起動する過程で自分で移動する。

448KBのRAMの上限は0x6FFFFで、そこからリセットベクタまでの間には何もない。V30が起動直後に読みに来るリセットベクタ (0xFFFF0) 以降の16バイトだけは、core1が特別に応答するようにしてある。この16バイトにリセットベクタとBIOSがまるごと収まっている。

初期化時にメモリ全体を 0xF4 (HLT命令) で埋めておくのは前作のモニタの f コマンドと同じ流儀で、暴走したらすぐ止まる。

ディスク書き込み問題の解決

前作で「作ったプログラムを保存する方法がない」と書いた問題は、2段構えで解決した。

Aドライブ: ファームウエアに焼き込んだROMディスク。COMMAND.COMやDOSツール一式が入っている
Bドライブ: PSRAM上の4MB RAMディスク (FAT)。読み書き自由

前作は「メモリに余裕がないからRAMディスクは難しそう」と書いたが、RP2350はXIP (外部メモリをアドレス空間に直接マップして読み書きできる仕組み) のセカンダリインターフェースに8MBのPSRAMをぶら下げられるので、あっさり解決した。RAMディスクなので電源を切ると消えるが、それも後述のwarm rebootとYMODEM転送でだいぶ緩和されている。

ターミナル

前作は「PCに繋いで表示させていると感動も薄い」で終わったが、今回はDOSから見た画面とキーボードを全部ファームウエアで実装した。

ANSI.SYS互換エスケープ

DOSの世界では画面制御にANSI.SYSのエスケープシーケンスを使うのが定番だったので、CUP (カーソル移動) / ED・EL (消去) / SGR (色) / DECTCEM (カーソル表示) あたりを実装した。これでDOS側のフルスクリーンアプリ (後述のvi) がそのまま動く。

日本語: SJIS、フォント、UTF-8変換

LCDには8×16の半角と16×16の全角フォントを載せ、40列×30行のテキスト画面として使う。フォントはビットマップ画像からRubyスクリプトでC++ソースに変換
DOS側の文字コードは当然Shift_JIS。LCDはSJISを直接解釈する
一方、USBでPCに繋いだときの標準入出力 (/dev/ttyACM0) はSJIS↔UTF-8を双方向変換してから流す。現代の端末エミュレータでそのまま日本語が読み書きできる。JIS X 0208↔Unicodeの変換テーブルもスクリプトで生成した

既存の日本語表示ソフトウエアもそのまま動く。

PSRAMスクロールバッファ

テキスト画面は40列×30行しかないので、PSRAMに4096行分のスクロールバッファを持たせた。Fnキーを単独タップするとスクロールモードに入り、k/j やCtrl-F/Ctrl-Bで過去の出力を遡れる。DOS機なのにless的なスクロールバックがあるのはなかなか快適だ。

Symキーのタップで文字を倍角表示にするモードも付けた。老眼にやさしい。

47キーに全部を詰め込む

47キーしかないので、自作キーボード界隈でおなじみのQMK風レイヤ方式にした。Ctrl / Shift / Sym (記号) / Num (数字) / Fnの修飾キーがあり、優先順位は Ctrl > Fn > Sym > Num > Shift > Base。レイヤ上で定義がないキーは下のレイヤに「透過」する (QMKの _______ と同じ)。

Fnキーはさらに QMKのLayer-Tap相当の判定をしていて:

押しながら他のキー → Fnレイヤ (F1〜F12、カーソル、PgUp/PgDn)
単独タップ → スクロールモードのトグル
左右のFnを同時押し → MonitorShell (後述) 起動

同時押しの検出を専用ロジックにせず「FnレイヤのFnキー位置にシェル突入キーを仕込んでおく」だけで実現できたのは、レイヤ方式のきれいな副産物だった。

モニタは今回も居る: BootShellとMonitorShell

前作のモニタプログラム (メモリダンプ、逆アセンブル、XMODEM…) の精神は今作にも引き継がれていて、ファームウエアにはDOS以外に2つの「シェル」が入っている。

BootShellは起動時にESCを押していると入る設定メニュー。CPUクロック、標準入出力をCDC/UARTどちらに繋ぐか、ドライブ構成、UTF-8変換の有無などをトグルして b でDOSを起動する。

MonitorShellはDOS実行中にFn両押し (または /dev/ttyACM1 に何か入力) で入れるモニタで、メモリダンプ、逆アセンブル、リセット、BOOTSEL (ファームウエア書き込みモード) 突入などができる。実行中のV30のメモリを外から覗けるので、DOS側のデバッグに重宝する。

お気に入りが warm reboot だ。RAMディスク (Bドライブ) の内容を保持したまま再起動できる。

ただ、これはすんなり動いたわけではなかった。実装してみると、再起動をまたぐとRAMディスク上のファイルが化ける。どこで化けているのかを調べるために、DOS上で動くSHA1SUM.EXE を作った。reboot前後でファイルのハッシュを取って突き合わせ、どのデータがいつ壊れるのかを絞り込んでいった。

犯人はXIPキャッシュだった。RP2350のPSRAMはXIPキャッシュ越しにアクセスするので、RAMディスクに書いたつもりのデータの一部はまだキャッシュ上のダーティラインに居て、PSRAM本体には届いていない。その状態でリセットするとキャッシュごと消える、というオチだ。再起動前にキャッシュを明示的にflushしてから飛ぶようにして解決した。

デバッグのために作ったSHA1SUMは、そのままディスクに同梱してファイル転送の照合ツールとして第二の人生を送っている。

PCとの連携: 3本のUSBシリアル

USB-CでPCに繋ぐとCDC ACMが3本生える。pico-sdkのおかげで、この手のコンポジットシリアルデバイスは簡単に作れた。

デバイス	役割
/dev/ttyACM0	DOSの標準入出力 (LCDと並行、SJIS↔UTF-8変換つき)
/dev/ttyACM1	ファームウエアのデバッグログ + モニタ起動
/dev/ttyACM2	DOSのAUX (COM1) 直結、生バイト

前作で「シリアルポートは画面のために使ってしまっているので多重化するか別の方法を考えないといけない」と書いた問題は、USBのコンポジットデバイスにして解決した。1本のUSBケーブルでコンソール・デバッグ・ファイル転送が同時に使える。

ファイル転送はAUX経由のYMODEM。DOS側にSX.EXE / RX.EXE を同梱していて、Linux側は lrzsz がそのまま使える。

PCからDOSCONにファイルを送るには、DOSCON側で RX を実行してから、Linux側で sb を実行する:

A> RX /Y
$ sb HELLO.TXT < /dev/ttyACM2 > /dev/ttyACM2

逆にDOSCONからPCに送るには:

A> SX /Y HELLO.TXT
$ rb < /dev/ttyACM2 > /dev/ttyACM2

転送後の照合には、warm rebootのデバッグ用に作ったチェックサムプログラム (CRC32SUM.EXE / SHA1SUM.EXE) がそのまま使える。前作でLHAが動かなくてLinux側で解凍した、みたいな運用が今回はだいぶ楽になった。

viとTUT-Codeで、このマシンだけで開発する

前作からの宿題だった「このマシン上でのソフトウエア開発」のために、ディスクにはHIDOSのビルド成果物 (COMMAND.COM、EDLIN、DEBUG、MASM、LINKなど) に加えて、自作のVI.EXE を入れた。vi風のエディタで、ANSIエスケープで全画面制御する。

RAMが448KBに増えたので、Cコンパイラもこのマシンの上で動く。入れたのはLSI C-86 試食版。小学生の頃に使っていたコンパイラが、あの頃と同じV30の上で、今度は自分で作ったマシンで普通に動く。

copy con でFizzBuzzを書いて、コンパイルして、実行する。全部このマシンの中だ。

そしてDOSCONで一番変なところかもしれないのが漢字入力で、IMEを積む代わりに TUT-Code (2〜3打鍵で漢字を直接入力するコード体系) をviに内蔵した。IMEにしなかったのは、辞書を置くメモリがないから。同じ漢直でもT-Codeはこのキーボードではキーが足りないので、TUT-Codeに落ち着いた。変換候補ウィンドウも辞書引きも不要なので、448KBしかないDOSマシンと相性が良い。なお、日本語の表示はDOS全体でどこでもできるが、入力ができるのは今のところviの中だけだ。

これで、viでソースを書く → MASMやCコンパイラでビルド → 実行 →YMODEMでPCに吸い出す、までが電池駆動のポケットマシンで、しかも本物のV30の上で完結するようになった。

MASMでHello Worldをアセンブルして動かした様子:

開発の記録

コミットログから振り返ると、だいたいこんな流れだった。前作の記事を書いたのが2月11日。実はその頃には、もう次の基板の設計を始めていた。

2月上旬: KiCadで基板設計、発注
2月中旬: MicroPythonでLCD/キーボードの単体動作確認 →C++でファームウエアの骨組み
2月23日: V30バスインターフェースとI/O処理の初期実装
2月末: HIDOSをサブモジュール化してディスクイメージのビルド、DOS起動
3月: I/Oまわりの整備、SJIS/UTF-8、スクロールバッファ、BootShell/MonitorShell、warm reboot
4月: DOS側ツール (vi、YMODEM)、README整備
4月末〜5月: ケースとキーキャップの調整、倍角モードなど仕上げ

約4ヶ月、74コミット。

初めてLCDの上でDOSが起動した時の様子。ここから先は「動くDOSマシンをいじって拡張していく」楽しいフェーズだった。

今回もAIに実装を任せるつもりだったので、テストは過剰なぐらいに整備した。ファームウエアの全クラスをテンプレートで差し替え可能にして、FakeHAL/FakeScreenなどを注入したホスト側gtest (Pico SDK不要)を用意し、エスケープシーケンスの解釈やキーボードのレイヤ判定のような「実機だとデバッグが面倒なロジック」は全部PC上のテストで検証できるようにした。AIが自分でテストを回して自分で直せる環境を作れば、ソフトウエアの開発はよく回る。

一方で、前述の通りケースはテストが書けない。AIループが回るソフトと回らないガワで、かかる時間が逆転したのが今回の学びだった。

もうひとつ、実装前に設計メモを firmware/docs/ に書き溜めながら進めるスタイルを取った。メモリマップ、キーの論理化、I/Oの仕様など13本。あとから見返せるし、この記事の下書きにもなった。

まとめと今後

前作の展望3つ (ディスク書き込み・メモリ・画面とキーボード) は全部回収した。ついでに日本語表示と漢字入力まで付いた。

基板からOSまで全レイヤが自分の手元にあると、レイヤ間の「境界」を自分で決められるのが最高に楽しい (BIOSを丸ごと捨ててI/Oポートプロトコル1本にする、など)
RP2350は「CPU以外の全部」を演じる筐体として十分すぎる性能。V30のバス制御とUSBと画面を回してもまだ余裕がある
MS-DOS 2.11は448KBあれば快適に住める

そして何より、小学生の頃に夢想した「キーボード付きのゲームボーイでプログラムを書く」が、電池2本で手の中にある。

今後の展望:

配線を間違えたSDカードを、PIOでソフトSPIを生やして救済する
そして次は、V30からは離れて、もっと別の物を作ってみたい。そもそも今回DOSを選んだのは「既存のDOS資産が活かせるのでは」という目論見だったからだが、ここまでAIの開発力が高いなら、OSもコンパイラも、なんならCPUも、自作を視野に入れていいのかもしれない

リポジトリ:

DOSCON 本体: https://github.com/ikeji/doscon
VI.EXE: https://github.com/ikeji/tiny-vi-clone
SX.EXE/RX.EXE: https://github.com/ikeji/xmodem
SHA1SUM.EXE/CR32SUM.EXE: https://github.com/ikeji/sha1sum
HIDOS (fork): https://github.com/ikeji/HIDOS/tree/doscon
HIDOS 本家: https://github.com/hdk1983/HIDOS

おわり

今回もいろいろ勉強になりました。

先人の知恵に感謝します。

HIDOSを作ったhdk先輩
TUT-Codeを考えた人達
QMKに代表される自作キーボード文化
lrzszを今もメンテしている人達

2026W29

Tue, 21 Jul 2026 22:04:13 +0900

20260714
- DOSCON
  - 消費電力を計測した。
  - エネループ2本で給電して250mA消費だった。7-8時間ぐらい?
20260715
- X260
  - 持ち上げて、トンと置いたら再起動した。
20260719
- HDD
  - バックアップ用に14TBの外付けHDDを買った。
  - MicroUSB3.0だった。まじか。
  - luksとzfsで初期化
  - とりあえず、データで埋めてみる。