开源掌机到底怎么开源的，也没见淘宝上卖的机器提供开发资料？

以我比较熟悉的OpenDingux和RetroMini为例

RetroMini实际上和后来比较流行的“开源掌机”的模式实际上有一些区别，这个机器原始提供的系统并不是Linux系统，而是某个现成的（可能是上游提供的）嵌入式系统。

OpenDingux的开发团队在JZ的CPU上，先是编译工具链（包含一些对JZ的专门代码优化），然后构建了ubiboot用于拉起Linux，接着构建内核和一些外围程序，相关的内核驱动也都是完全重新编写的。后来的一些“开源掌机”的第三方系统似乎是依赖开发商提供现成的内核代码（有的可能只有二进制内核编译的结果？），在其中做用户空间的搭建。

OpenDingux的高光时刻其实在很久之前的丁果时期，所以等到我接触RetroMini的时刻，社区基本上没有剩下什么人。只能参考一些现成的模拟器代码仓库。OpenDingux的用户空间程序包其实是一个squashfs，在运行时临时挂载并执行，其中运行的可以是脚本，也可以是编译好的程序，编译的程序需要使用特定的工具链进行编译。

对于图像和声音， 如果不想要自己直接控制硬件设备，那么就是用SDL。对应的工具链包含了SDL（1.2）的库的支持，因此可以用SDL编写声音、图像和按键代码，这基本上就完成了对系统的输入输出的对接，如果你有现成的模拟器内核，将模拟器内核运行和SDL对接，由SDL控制帧率，SDL输入事件对接到内核的手柄输入，然后将内核的图像输出转写成游戏机和对应SDL支持的特定格式并输出，模拟器内核生成的声音BUFFER也通过合适的方式被SDL的声音回调函数接收走，就可以完成一个简易的模拟器的移植。

进一步的优化其实必不可少，由于RetroMini的性能非常捉鸡，因此模拟器优化和不优化经常是两个样子。如果完全不优化，模拟器内核生成的图像需要转换，保底也得写一个memcpy来将其复制到SDL的帧中。OpenDingux的SDL支持最多3帧的硬件帧，因此如果能做到一帧提供硬件显示，另一帧直接挂接到模拟器内核中让模拟器提供直接填充的方法，整体减少了复制的时间，性能上可能会好一些。另外就是声音，如果可以直接挂接内核生成的原始的声音，也可以减少转换不同声音格式的时间。

模拟器准确率其实在这个系统上很难做到，大部分模拟器的目标是让你运行起来觉得不会卡就可以。因此模拟器里会有类似声音BUFFER来不及准备时，拿先前的BUFFER重新放一遍糊弄你的情况，用这些偏移的方法降低不适感。

内存其实也不大，一个机器也就32M内存，OpenDingux通过ZRAM来将CPU兑换成更多一些的内存。而模拟器一般需要通过mmap技术，将游戏ROM直接映射到内存空间，让Linux内核帮你完成文件数据和内存的交换。

总而言之，如果就一个RetroMini当成开发板玩，还是挺有意思的。后来的开源掌机，即便用JZ CPU的，大部分应该是没有像OpenDingux一样提供完整的工具链到boot到内核的，定制程度可能会稍微低一些。