278 points • 1 day ago • Article Link

早在 1980 年代初期，当 8-bit PC 硬件受到极其严重的限制时，制作流畅、可玩的电子游戏是一项极其耗费精力的优化工作。作者的一位朋友当时正在开发一款图形密集的横向卷轴游戏，游戏几乎已经完成，但却深受帧率过低而无法运行的问题困扰。尽管程序员已经应用了诸如循环展开（loop unrolling）等标准优化手段，但游戏速度依然缓慢。当时的挑战在于硬件缺乏诸如 blitters 或 texture mappers 等现代特性，这要求程序员必须手动逐字节地移动数据以将图像绘制到屏幕上。

作者在研究代码后意识到，瓶颈在于负责将 background tiles 复制到 screen buffer 的那段程序。机器使用的 6809 处理器提供了一些特定且强大的寻址模式，但朴素的复制例程的周期计数依旧很高。通过进一步展开循环，并手动计算内存访问的偏移量，他们实现了 60% 的速度提升。然而，这仍不足以满足游戏的性能要求，于是作者开始寻求更非传统、近乎"疯狂"的解决方案。

在查阅 6809 微处理器手册后，作者发现处理器的 stack 指令可以被改造成用于快速数据传输。通过征用硬件 stack 寄存器，即 S 和 U，作者开发出一种方法：利用包括 DP 寄存器在内的所有可用寄存器，以单次突发（single burst）的方式把数据从 tile 中取出并推送到 screen buffer 。这种方案效率极高，但也带来了副作用——tiles 会被绘制得上下颠倒，且左右两半被交换。

为了解决这一问题，两人意识到这种"搅乱"过程其实是一个 involution 。于是他们在游戏运行前就对 tiles 做了预处理，提前把内部结构反转。这样一来，等到把被破坏的数据绘制到屏幕后，图像在到达屏幕时会被自动完美地还原。该方案带来了 70% 的速度提升，基本有效地解决了性能问题。但当他们为声音加入 hardware-clocked interrupts 时，最后一道难题出现了。由于该例程需要征用 stack pointer，如果在绘制 tile 的过程中触发中断，就会覆盖保存 reference tiles 的内存。

他们通过巧妙地交换 stack 指针来化解这次最终的技术危机，确保中断造成的任何破坏都会落到 screen buffer 上，而不是原始的 tile data 。为了避免这种短暂的屏幕异常被玩家看到，他们调整了绘制顺序：从高内存往低内存绘制。这样，任何意外的损坏都会在下一张 tile 被绘制时被覆盖，从而保证在 buffer 送往显示器之前问题不会显现出来。

回想当初，作者把这段经历视作早期计算时代所必需的创造力的证明。面对极其苛刻的硬件限制，程序员不得不反复尝试、失败并迭代，才能找到既巧妙又有时不那么正统的解决方案。这个故事也提醒人们：在这样的技术挑战中，同样能收获乐趣，并鼓励他人把自己的经验记录下来，免得这些具有专业性与历史意义的见解随着时间流逝而被遗忘。 Back in the early 1980s, when 8-bit PC hardware was incredibly limited, creating smooth, playable video games was a grueling exercise in optimization. A friend of the author was developing a graphically intensive side-scroller that was nearly complete but suffered from unplayable frame rates. Despite the programmer having already applied standard optimizations like loop unrolling, the game remained too slow. The challenge was that the hardware lacked modern features like blitters or texture mappers, requiring programmers to manually move data byte by byte to draw images onto the screen.

The author, after studying the code, realized that the bottleneck was the routine responsible for copying background tiles to the screen buffer. The 6809 processor used in the machine offered specific, powerful addressing modes, but the cycle counts for the naive copying routine remained high. By further unrolling the loops and manually calculating offsets for memory access, they achieved a 60 percent speed increase. However, this was still insufficient to meet the performance requirements of the game, leading the author to seek even more unconventional, "crazy" solutions.

After consulting a 6809 microprocessor manual, the author discovered that the processor's stack instructions could be repurposed for rapid data movement. By commandeering both the hardware stack registers, S and U, the author developed a method to pull data from a tile and push it to the screen buffer using every available register—including the DP register—to move blocks of data in a single burst. This approach was remarkably efficient, but it introduced a side effect: the process drew the tiles upside down and with their halves swapped.

To overcome this, the pair realized that the mangling process was actually an involution. By pre-processing the tiles to reverse their internal structure before the game ran, the act of drawing the corrupted data would perfectly restore the images once they reached the screen. This solution provided a 70 percent speed improvement, effectively solving the performance issues. However, a final hurdle emerged when they implemented hardware-clocked interrupts for sound. Because the routine relied on commandeering the stack pointer, an interrupt occurring during a tile draw would overwrite the memory where the reference tiles were stored.

They addressed this final technical crisis by cleverly swapping the stack pointers, ensuring that any corruption caused by an interrupt would target the screen buffer rather than the original tile data. To prevent this temporary screen glitch from being visible to the player, they altered the drawing order to proceed from high memory to low memory. This ensured that any accidental corruption would be overwritten by the next tile being drawn before the buffer was sent to the display.

Looking back, the author highlights this experience as a testament to the ingenuity required during the early era of computing. Faced with severe hardware limitations, programmers had to constantly experiment, fail, and iterate to find elegant, if sometimes unorthodox, solutions. The story serves as a reminder of the joy found in such technical struggles and an encouragement for others to document their own experiences before these specialized, historic insights are lost to time.