How to use Gemini to bring up a V30 cradle
Gemini CLI wrote RP2040 firmware for a real V30; manual timing fixes and HIDOS enabled a DOS shell, while disk writes and compatibility stayed incomplete.
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Develop RP2040 cradle firmware for this V30 bus using the datasheet timing diagrams. Keep USB interrupts separate from bus service, verify read-direction turnaround and odd/even byte selection, and add emulator tests. Present timing traces for human review before we flash or power the physical board.
Reach people exploring AI agents
See placements →What happened
The physical V30 booted HIDOS MS-DOS with a working shell, file access and utilities; disk writes and broader DOS compatibility remained incomplete.
Reported by ikeji — Personal blogHow the agent did it
- Gemini CLI generated Pico SDK control code and diagnostic assembler tools for the RP2040 cradle.
- ikeji soldered and flashed the board, then manually corrected bus timing and odd-address behavior using a logic analyzer.
- The owner combined QEMU debugging, requested tests and a HIDOS port to boot DOS on the real V30.
Where a person stepped in
ikeji manually placed the board components, assembled the hardware and fixed dangerous electrical timing errors; they selected HIDOS after the direct loader failed.
ikeji built an RP2040 cradle around a real NEC V30 processor and used Gemini CLI in an empty directory to develop its control software. The agent wrote C++ with the Pico SDK, plus an assembler and disassembler. One RP2040 core served the CPU bus while the other handled USB debugging, avoiding interrupt interference with tight timing.
The manufactured board initially failed. Gemini suggested changing the circuit, but ikeji investigated with a logic analyzer. Generated firmware drove data immediately when the read signal changed, before the multiplexed bus had switched direction. The collision triggered USB power protection. A human-added delay corrected this; another manual repair fixed odd-address byte selection.
For existing DOS programs, the owner used QEMU and requested unit tests while correcting segment handling. A direct COMMAND.COM approach did not reach its prompt. Switching to HIDOS’s smaller device interface eventually booted MS-DOS on the physical V30 and supported the shell, file access and bundled utilities.
This was substantial agent-assisted firmware with human electrical debugging. Disk writes remained unavailable, memory was limited, and many machine-specific DOS programs still failed.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Personal blog · ikeji
Frequently asked questions
Did the first firmware work on hardware?
No. Bus contention and incorrect byte selection needed manual fixes.
Why use the second RP2040 core?
USB handling interfered with time-sensitive bus control.
Was this a complete PC replacement?
No. Disk writes were missing and many DOS programs remained incompatible.
More details
About this account
Gemini CLI generated Pico SDK control code and diagnostic assembler tools for the RP2040 cradle. ikeji soldered and flashed the board, then manually corrected bus timing and odd-address behavior using a logic analyzer.
Original dated account opened. Gemini chat informed circuit consultation; Gemini CLI explicitly performed the software work. Human fixes were required after bus contention. The author also notes operation outside the V30 datasheet voltage guarantee. Suggested prompt written by Agents In Use; no original task prompt was found in the verified text.
Credit: ikeji — Personal blog
Source published 11 Feb 2026
Source checked 14 Oct 2026
Tools and topics
Gemini CLI · RP2040 · NEC V30 · Pico SDK · Logic analyzer · QEMU
retro computing · firmware · bus timing
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.