1. 项目缘起：当《图灵完备》遇上视频播放
如果你也玩过《图灵完备》（Turing Complete）这款游戏，肯定被它从零开始搭建计算机的硬核玩法深深吸引过。从最简单的与非门开始，一步步造出寄存器、ALU，最终构建出一台能运行程序的完整计算机，这个过程充满了挑战与成就感。但不知道你有没有想过，在这款以逻辑门为砖瓦的“数字世界”里，我们能不能玩点更“出格”的？比如，播放一段视频。
我当初冒出这个想法时，自己也觉得有点疯狂。毕竟，《图灵完备》里最复杂的输出设备，可能就是那个小小的、分辨率极低的点阵显示器了。用它来播放视频，听起来就像是用算盘播放高清电影。但正是这种“不可能”，激起了我的技术挑战欲。我的目标很明确：构建一个分辨率为144*256像素，并且帧率可以由我们自己通过“时钟刻”来精确控制的视频播放器。这意味着，我需要用游戏里最基础的逻辑门、计数器、寄存器，去模拟现实世界中显卡和视频解码器的核心工作流程。
为什么是144256这个分辨率？一方面，它是原始显示器模块（68像素）的整数倍（24行 * 32列），便于我们进行模块化设计和坐标映射。另一方面，这个分辨率在保证一定清晰度的同时，又能将电路复杂度控制在一个可实现的范围内。全高清？那得用上百万个逻辑门，估计游戏和你的电脑都得卡死。而“帧率可控”则是这个项目的精髓所在，它意味着我们不是简单地让画面动起来，而是要理解“帧”的本质——即每显示完整一幅画面所需要的系统时钟周期数。你可以把它调快，获得流畅的动画；也可以调慢，像逐帧分析大师一样观察每一个像素的变化。接下来，我就把自己从原理摸索到最终实现的完整过程，以及中间踩过的无数个“坑”，毫无保留地分享给你。
2. 核心原理拆解：像素、时序与数据流
要实现视频播放，无论硬件多简单，都绕不开三个最核心的问题：每个像素的颜色从哪里来？（数据）、这个颜色该送到屏幕的哪个位置？（坐标）、什么时候该切换下一帧画面？（时序）。在《图灵完备》里，我们需要用纯数字逻辑电路来回答这三个问题。
2.1 显示器模块的工作原理：它不是“屏幕”，而是“地图”
首先，我们必须彻底吃透游戏内置的显示器元件。它不是一个接受模拟信号的“屏幕”，而是一个严格的数字坐标映射器。我把它理解成一张固定大小的“像素地图”。
这个显示器默认是6行8列，总共48个像素点。它的输入是一个8字节（64位）的数据。这64位数据如何对应到48个像素呢？这里有个关键模式：列优先。很多朋友一开始会按“行优先”去理解，结果颜色全乱了。正确的方式是，把这64位数据看作8个字节，从高位到低位（或根据游戏设置）排列。通常，第2个到第7个这6个字节，分别对应显示器的第1行到第6行。而每个字节中的8个位（bit），则对应这一行中的8列，通常最高位（第8位）代表第1列，最低位（第1位）代表第8列。
举个例子就明白了。假设我们输入的数据中，只有第2个字节的第8位是“1”，其他位都是“0”。那么，在显示器上，只有第1行第1列这个像素点会被点亮。如果第7个字节的第1位是“1”，那么就是第6行第8列的像素被点亮。所以，控制显示器显示什么图案，本质上就是根据我们想要的像素坐标，去精确地设置那64位输入数据中特定比特的值。这是我们所有坐标计算电路的最终目标。
2.2 视频播放的三大支柱模块
基于对显示器的理解，我设计了整个播放器的三大核心模块，它们像流水线一样协同工作：
- RGB数据流读取模块：负责从存储视频颜色数据的“文件”中，按顺序读出每一个像素的RGB颜色值。这相当于显卡的显存读取部分。
- 像素坐标映射模块：负责计算当前时钟刻下，应该点亮哪个显示器上的哪个像素。它需要生成精确的控制信号，告诉显示器模块“现在该显示哪个点”。
- 帧缓冲与时序控制模块：这是整个系统的心跳。它以一个全局时钟为基准，控制着数据读取和坐标映射的步调。最关键的是，它定义了“一帧”的时间长度（比如1536个时钟刻），并负责在每帧结束时，通知数据读取模块切换到下一帧的画面数据。
这三个模块环环相扣。时序模块发出“滴答”声，坐标模块就计算出一个新位置，数据模块则把这个位置对应的颜色送出去。如此循环，静态的图片就变成了流动的视频。
3. 实战构建：从颜色数据到电路连线
原理清楚了，接下来就是动手搭建。我会按照数据流的顺序，从后端的数据准备讲到前端的电路实现。
3.1 准备视频源：从MP4到游戏能读的.bin文件
这是第一步，也是最容易让新手卡住的一步。游戏里的“文件加载器”元件可以读取外部文件，但它需要特定格式。我们的视频（比如一个MP4文件）必须被转换成纯二进制（.bin）的颜色数据文件。
这个过程可以分解为三步，我全部用Python脚本配合FFmpeg工具来完成，你可以轻松复用：
第一步：视频分辨率转换。我们的目标分辨率是256x144。如果原视频不是这个比例，需要先转换，以避免后期像素错位。我写了一个简单的Python脚本来调用FFmpeg：
import subprocess input_file = 'your_video.mp4' output_file = 'resized_video.mp4' target_resolution = '256x144' # 宽x高 ffmpeg_cmd = [ 'ffmpeg', '-i', input_file, '-vf', f'scale={target_resolution}', '-c:a', 'copy', # 保留原音频（虽然游戏用不到） output_file ] subprocess.run(ffmpeg_cmd, check=True) print("视频分辨率转换完成！")第二步：逐帧导出RGB数据。视频是由一帧帧图片组成的。我们需要把转换后的视频，每一帧都导出为原始的RGB24格式文件（每个像素用3个字节表示红、绿、蓝）。这里的关键是使用FFmpeg的rawvideo编码器和rgb24像素格式。
import subprocess import os def extract_rgb_frames(video_path, output_dir): if not os.path.exists(output_dir): os.makedirs(output_dir) # 命令：将视频解码为原始RGB流，并通过管道输出 cmd = [ 'ffmpeg', '-i', video_path, '-f', 'image2pipe', '-pix_fmt', 'rgb24', '-vcodec', 'rawvideo', '-' ] process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, bufsize=10**8) frame_width = 256 frame_height = 144 frame_size = frame_width * frame_height * 3 # 每帧的字节数 frame_count = 0 while True: raw_frame = process.stdout.read(frame_size) if not raw_frame: break # 将每一帧数据保存为一个.rgb文件 with open(os.path.join(output_dir, f'frame_{frame_count:04d}.rgb'), 'wb') as f: f.write(raw_frame) frame_count += 1 print(f"共提取 {frame_count} 帧RGB数据。")运行后，你会得到成千上万个frame_0000.rgb、frame_0001.rgb……这样的文件。你可以用010 Editor这类二进制编辑器打开看看，里面全是连续的RGB数值，没有任何文件头，这就是游戏需要的“纯数据”。
第三步：合并所有帧为单个.bin文件。游戏的文件加载器通常喜欢读取一个连续的大文件。我们需要把所有的.rgb文件按帧顺序首尾拼接起来。
import glob output_bin_file = 'video_data.bin' frame_files = sorted(glob.glob('output_rgb_frames/frame_*.rgb')) # 确保按文件名排序 with open(output_bin_file, 'wb') as bin_f: for frame_file in frame_files: with open(frame_file, 'rb') as f: bin_f.write(f.read()) print(f"所有帧已合并至 {output_bin_file}")现在，这个video_data.bin文件就是我们的“视频源”了。它的数据结构非常简单：从头到尾，依次是第一帧所有像素的RGB数据、第二帧的所有数据……每一帧的大小固定为 256 * 144 * 3 = 110,592 字节。
3.2 构建数据读取模块：xdriver与文件加载器
有了数据源，接下来就要在游戏里把它读出来。这里我自定义了一个核心元件，我把它叫做xdriver。
xdriver的核心任务是生成“文件偏移量”。你可以把.bin文件想象成一个很长的磁带，文件加载器是读头，xdriver告诉读头：“现在请从第N个字节开始读8个字节出来”。
我的实现思路是这样的：
- 基础步进：一个32位计数器，每个时钟刻加1。它记录的是在当前帧内的“相对位置”。因为我一帧要显示144行*256列=36864个像素，但我的设计是并行处理24行（后面会讲为什么），所以每帧需要扫描的次数是 36864 / 24 = 1536 次。因此，这个计数器的计数范围是0到1535。
- 帧间跳跃：一个64位寄存器，用来记录“当前帧的起始字节位置”。初始为0（指向文件开头）。每当上面的32位计数器计满1535归零时（意味着一帧的1536次读取完成），就触发这个64位寄存器进行一次更新：
新值 = 旧值 + 36864 * 3。为什么是36864*3？因为一个像素有3个字节（RGB），一帧有36864个像素，所以一帧数据的总字节数是110,592。加上这个值，文件加载器的读头就跳到了下一帧数据的开头。 - 最终偏移量计算：
xdriver最终的输出偏移量公式是：偏移量 = 3 * (1536 * line_group_id + counter_value) + frame_base。这里line_group_id是行组编号（0-23），counter_value是32位计数器的当前值（0-1535），frame_base是64位寄存器的值（帧基址）。乘以3是因为每个像素占3字节。
这个xdriver元件需要实例化24份，分别对应24个行组。每个xdriver的line_group_id输入不同，它们就能在同一时钟刻，并行计算出24个不同行像素数据在文件中的位置。文件加载器拿到偏移量，输出8字节数据，我们再用一个简单的xd2元件（其实就是几个导线）取出其中的前3个字节，这就是当前像素的RGB颜色了。这一步，我们解决了“颜色从哪里来”的问题。
3.3 构建坐标映射模块：除法器与译码器的舞蹈
颜色数据有了，现在要解决“送到哪里去”的问题。我们需要根据当前的全局时钟，计算出此刻应该点亮哪个6*8显示器模块上的哪个具体像素。
这个计算本质上是将一维的线性地址转换为二维的屏幕坐标。我使用了一个全局的64位计数器，它从0计数到36863（一帧的总像素数减1），然后归零，循环往复。这个计数器的值current_pixel_index，就代表了当前正在处理的第几个像素（按行优先顺序）。
坐标转换通过两级除法器实现：
- 计算行坐标和列组：用
current_pixel_index除以256（一行像素数）。商（row_quotient）的范围是0-143，这就是像素所在的行号。余数（col_group_remainder）的范围是0-255，它表示像素在该行的第几列。 - 计算具体列坐标：由于每个显示器只有8列，我们需要进一步定位。将上一步的余数
col_group_remainder再除以8。商（display_h_index）的范围是0-31，这决定了是当前行32个显示器中的第几个。余数（pixel_col_in_display）的范围是0-7，这决定了是该显示器内的第几列。 - 行坐标的细化：对于行坐标，我们还需要确定是6行显示器中的哪一行。将
row_quotient除以6。余数（pixel_row_in_display）的范围是0-5，这决定了是该显示器内的第几行。
至此，我们得到了一个五元坐标：(第几行, 第几个显示器, 显示器内第几行, 显示器内第几列)。最后两步是关键：
- 列选择：根据
pixel_col_in_display（0-7），通过一个解码电路，生成一个8位的独热码（One-Hot Code）。例如，如果是第1列（索引0），则输出10000000（二进制）；第2列则输出01000000，以此类推。这个8位数据会直接送到显示器元件的对应字节位。 - 行选择与显示器寻址：根据
pixel_row_in_display（0-5）和display_h_index（0-31），共同决定最终由哪个显示器元件在哪个行上显示。display_h_index通过一个5-32译码器，产生32个使能信号，每个信号控制一行中对应的那个显示器是否“激活”接收颜色数据。而被激活的显示器，则根据pixel_row_in_display，将收到的RGB颜色数据填充到其64位输入数据的对应字节中去。
这个过程听起来复杂，但用电路实现后，就像一套精密的齿轮，随着时钟滴答作响，自动而准确地将颜色数据“搬运”到屏幕的每一个角落。
3.4 时序控制与帧率设定：让心跳可控
这是让视频“动”起来，并且速度可控的关键。在我的设计中，帧率完全由“时钟刻/帧”这个参数决定。
回顾一下：我的全局64位像素索引计数器，每帧会计数36864次（从0到36863）。但是，我的数据读取模块（xdriver）是24路并行的，所以每读取一次颜色，可以更新24个像素。因此，完成一帧实际上只需要 36864 / 24 = 1536 个时钟刻。
“1536个时钟刻为一帧”就是这个播放器的原生帧率。如果你觉得这个速度太慢，比如画面卡顿，你可以从两个方向优化：
- 提高并行度：设计48路甚至144路并行的
xdriver。这样，完成一帧所需的时钟刻数就会按比例减少（例如48路并行只需768个时钟刻一帧），帧率就提升了。但这会显著增加电路规模和复杂度。 - 提高主时钟频率：在《图灵完备》游戏里，你可以调整全局时钟的发生器速度。直接加快时钟，所有操作都会变快，帧率自然就上去了。这是最简单的提速方法，但受限于游戏模拟性能和电路延迟。
所谓的“帧率可控”，在底层就是通过调整上述两个因素来实现的。你可以为不同的视频内容设计不同的并行架构，或者通过一个可配置的分频器来动态调整有效时钟速度，从而实现“快放”、“慢放”的效果。这给了这个项目极大的可玩性和扩展空间。
4. 调试心得与性能优化建议
第一次把整个电路连完，通上电，看到屏幕上出现扭曲、错位的色块而不是预想的画面时，那种心情真是难以言表。调试数字逻辑电路，尤其是这种大规模、深时序的电路，需要极大的耐心和系统的方法。
我常用的调试“三板斧”：
- 分段隔离：不要一次性测试整个系统。先单独测试
xdriver元件，用固定的输入看它输出的文件偏移量对不对。再单独测试坐标生成模块，输入一个像素索引，看它输出的显示器选择信号和行列独热码是否正确。最后再把它们连起来。 - 善用探针和常量：游戏内的逻辑探针是你的眼睛。在关键节点（如计数器输出、除法器商和余数、译码器输出）都接上探针，观察它们的值是否按预期变化。在调试初期，可以用常量发生器代替文件加载器，模拟输出固定的颜色数据，排除数据源的问题。
- 对比二进制文件：当画面出现错误时，记录下当前时钟刻和出错的像素位置。然后回到我们生成的
.rgb帧文件，用二进制编辑器找到对应位置的颜色值。再回到游戏，用探针查看此时文件加载器读出的8字节数据，以及xd2元件提取出的3字节RGB值。进行比对，就能定位是数据生成、数据读取还是坐标映射的问题。
关于性能优化，如果你的电路门数量爆炸（像我最初版本达到了120万门），导致游戏模拟极其缓慢，可以尝试：
- 降低分辨率：这是最直接有效的方法。将144256改为72128，像素数变为原来的1/4，电路规模和计算量会大幅下降。
- 简化颜色深度：不一定非要24位真彩色（1600万色）。尝试使用8位索引色（256色），这样每个像素只需1字节，数据读取和传输的压力会小很多。你只需要额外做一个小的颜色查找表（CLUT）电路即可。
- 优化计数器与除法器：游戏内置的除法器非常耗资源。检查你的设计是否真的需要全字长的除法。例如，在坐标计算中，除数是固定的（256， 8， 6），可以考虑用“乘以倒数近似”或特定的循环移位电路来替代通用除法器，能节省大量门电路。
- 流水线设计：将数据读取、坐标计算、显示器驱动等操作拆分成多个流水线阶段。虽然不能减少总门数，但可以提高最大时钟频率，在更快的时钟下达到更高的帧率。
构建这个视频播放器的过程，远比单纯通关《图灵完备》更有收获。它强迫你从最底层去思考图像、时序、数据流这些概念，把抽象的理论变成了眼前跳动的像素。当你最终调试成功，看到自己喜欢的画面在由你亲手搭建的“计算机”上流畅播放时，那种成就感是无与伦比的。希望我的这份经验分享，能为你打开一扇新的大门，在《图灵完备》的世界里，创造更多不可思议的数字奇迹。
