Skip to content

Instantly share code, notes, and snippets.

@GOROman
Last active August 30, 2026 15:41
Show Gist options
  • Select an option

  • Save GOROman/b62d5198a77e513279d897d09bbfe5c3 to your computer and use it in GitHub Desktop.

Select an option

Save GOROman/b62d5198a77e513279d897d09bbfe5c3 to your computer and use it in GitHub Desktop.
PS1 BIOS Audio Ripper SX Burst Edition — 简体中文

PS1 BIOS Audio Ripper SX — Burst Edition(简体中文)

语言:日本語 · English · 简体中文

logo

不走视频、不走串口,而是用“声音”读取初代PlayStation BIOS,并挑战180秒内完成。

这是什么?

通过模拟立体声音频,将用户拥有的初代PlayStation的512 KiB BIOS传输到浏览器,目标180秒内完成。PS1端不使用FPU,采用定点运算、SPU ADPCM和双缓冲DMA。实际数据只使用OFDM(不使用FSK):44.1 kHz立体声、512点FFT、64采样CP、96载波、QPSK。

一切始于はむさん的想法

项目源于はむさん(@Imaha486)的创意:不焊接主板、不依赖专用ROM编程器,而是让初代PlayStation读取自己的BIOS,再利用主机原本就有的输出把数据送出来。目标是为用户自己拥有的硬件制作备份。

这个想法后来扩展为完整的浏览器恢复系统:接收信号、检测错误、修复缺失数据、重建全部512 KiB,并在最终校验通过后才允许下载。

从ZX到SX,再到Burst Edition

PS1 BIOS Ripper ZX首先尝试把视频作为传输通道。PlayStation在画面中绘制编码图案,视频采集设备将其数字化,浏览器通过图像分析恢复数据。ZX建立了区块显示、CRC流程、浏览器内重建以及CD启动镜像分发的整体框架。

SX把通道从视频改为模拟立体声音频。问题也随之变成SPU ADPCM、音频线、采集接口滤波、采样时钟偏差和Web Audio。ZX与SX共享视觉和架构思想,但传输协议彼此独立。

普通SX首先追求真实主机上的稳定恢复。Burst Edition则专注速度:数据传输不再使用FSK,只使用立体声OFDM,并加入FEC、WASM解调和Worker并行处理,挑战180秒目标。

git历史记录下的困难

ZX的提交连续出现“时间方向解码改进”“真实UVC跟踪改进”“8色真实传输自校准”。合成画面容易读取,但真实视频采集会出现重复帧、丢帧、颜色漂移和时序差异。因此项目加入多线程解码、NTSC模拟器、调色板自校准、原生60 fps接收、移动端布局和LZSS进度显示。

SX的过程更加曲折。历史包含PS1 OFDM调制器修复、44.1 kHz AudioContext、windowed-sinc重采样、C解调器、WASM接入和RS(16+4),也留下多次回退:把缓冲从2048扩大到8192后立即撤销;把区块信息从FSK移到OFDM后因真实硬件不稳定而撤销;FSK从300提高到400 baud也被回滚。SPU播放边界、FSK到OFDM的切换、单声道传输以及单侧声道重放旧波形都经过真实硬件排查。最终提交才记录“真实主机BIOS恢复验证成功”。

Burst Edition第一次大型实现修改55个文件,增加约4700行,把发送端、接收端、FEC、WASM、合成WAV测试、PS1 UI和Web UI一起重构。后续又加入起步音、三语言界面、CD镜像和恢复改进。它不是一次就成功的设计,而是把ZX与SX的失败经验集中起来的结果。

为什么界面变成F1

“180秒以内”让传输时间自然变成圈速。接收一个区块像跑过一段距离;CRC错误像失速;FEC修复像进站维修;无法恢复则像赛车事故。相比普通矩形进度条,赛道更能表达这个项目正在做什么。

于是区块变成圈数,赛车经过的路面才会着色,CRC异常时赛车旋转,最后一个区块出现方格旗,完成时显示GOAL和纸屑。音频起步信号 2 → 1 → GO! 也采用赛车起步语言。

但所有这些演出都建立在はむさん最初的创意上:只利用PS1本身已有的输出取回BIOS。F1主题不是取代原案,而是以尊重的方式,把180秒挑战以及从模拟器反复回到真实硬件的艰难过程可视化。

两声短音,然后GO!

PS1端播放三角波ADPCM起步音:两个短音、休止、一个长音。浏览器依次显示 2 → 1 → GO!。这不只是演出,它也是输入增益的听觉基准,作用类似FSK载波校准;实际数据仍然只使用OFDM。

音频受损也要跑到终点

每组最多32个数据分片和4个校验分片。使用GF(256)(多项式0x11d)Cauchy矩阵,将CRC失败视为擦除,并通过高斯消元恢复缺失分片。恢复后依次检查数据包、区块和整幅镜像CRC32。OFDM FFT、同步和解调的高负载代码使用C/C++风格定点实现并编译为WebAssembly,在专用Worker中运行;WASM不可用时回退到JavaScript。

模拟音频不会每次都得到完全相同的数值。输入增益、左右平衡、采样时钟偏差、接口滤波和瞬间噪声都可能破坏个别数据包。因此接收端先尝试基于置信度的候选和CRC引导的单比特修复,再交给32+4 FEC恢复缺失分片。分片还会在时间方向交错,避免一次连续干扰集中破坏同一个FEC组。所有恢复都失败时,系统会停止,而不会保存损坏的BIOS。

SPU ADPCM为何需要特殊处理

PlayStation SPU使用带预测历史的4位ADPCM。PC上的理想OFDM波形经过量化、预测器、块边界、结束标志和DMA切换后会发生变化。一些问题只在真实主机出现,例如缓冲区切换后旧音频似乎又在某一声道播放。

因此起步音、OFDM数据和SPU RAM区域被分离,旧缓冲区不重复使用,波形边缘加入短淡入淡出,PS1端全部保持定点运算。起步音选择三角波,是因为它通过SPU ADPCM后仍较稳定,也便于浏览器判断电平和频率。

从模拟器走向真实主机

唯一的开发Mac是内存8GB的MacBook Neo,使用Codex开发;PS1构建在512GB Mac Studio完成。先在DuckStation确认,再把CUE/BIN刻录到CD-R并在真实主机测试。

信号路径:PS1模拟L/R → EP-136立体声输入 → 浏览器AudioWorklet。必须使用44.1 kHz立体声输入,并关闭AGC、降噪和回声消除。

验证被分成多个独立阶段:主机端编解码测试、合成PCM/WAV回环、DuckStation、CD-R、真实PlayStation音频,最后是浏览器中的整幅镜像CRC。模拟器成功不等于模拟音频链路成功。赛道、F1赛车、FEC旋转、圈速和终点庆祝等界面,让漫长的解调过程不再只是一个沉默的进度条。

为实验购买的设备

设备 来源
SCPH-3500 / SCPH-7500 Mercari
视频采集设备 / 音频线 Mercari
CD-R介质 Akibaoo
Apple USB SuperDrive Mercari

两台主机、视频采集设备和音频线总计约1万日元。

下载

致谢

项目 致谢
概念与灵感 はむ(@Imaha486)
Web应用 / PlayStation应用 使用Codex开发
Logo与视觉图片 由ChatGPT生成
开发与真实硬件测试 GOROman
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment