前言

Game Boy这个词，相信一定能勾起不少80后和90后的童年回忆。从简单的打砖块到精灵宝可梦、塞尔达传说，这个平台上出现过太多经典的作品。而Game Boy本身也是从1989年开始一直生产到了2009年，总销量超过一亿台，成为了历史上第二畅销的掌上游戏机。值得指出的是，虽然Game Boy一直生产到了2009年，但是其主要的结构更接近于80年代流行的如FC（红白机）一类的8位游戏机。巨大的销量使它成为了最容易得到的8位复古游戏机之一。这一特点吸引了不少热爱8位游戏独特视听感受的玩家购买游玩Game Boy，也吸引了不少独立游戏开发者。时至今日，依然有爱好者在为Game Boy平台开发新的游戏。而Game Boy这一特点不仅仅吸引了游戏玩家。作为一台8位机， Game Boy内置的四声部PSG（可编程音频发生器）可以产生8位机独有的“芯片音乐”（Chiptune）。因此Game Boy受到了不少芯片音乐爱好者的追捧，包括也出现了如LSDJ一类的Game Boy专用的编曲软件，专门用于进行Chiptune音乐的编曲制作。8位机本身结构简单易于理解的特点也使Game Boy成为了一部分高校课堂中使用的例子。如佐治亚理工大学开设了Game Boy游戏设计课程帮助学生学习理解计算机体系架构，而卡内基梅隆大学也把设计一台Game Boy作为其高级数字系统设计课程的课程设计选题之一。这一切，发生在其停产近10年后的今天，也证明了这个经典平台强大的生命力。

要游玩Game Boy的游戏，当然是需要一台Game Boy和一张游戏卡带。如果想要玩的游戏是曾经的商业游戏，那只需要购买一张二手的卡带即可。但是如果是爱好者自制的游戏（或者程序），或者想要在Game Boy上运行自己编写的游戏，那就没有那么轻松了。通常而言，商业游戏的卡带是只可读取不可写入的，而为了写入自己的游戏，则需要一张可以写入的Game Boy烧录卡。

目前市场上可以购买到一些现成的烧录卡，然而价格都比较高昂，通常超过Game Boy本身的好几倍。然而好在，Game Boy的技术资料很容易在网上找到，只要能了解其原理，自己设计并制作一张烧录卡是可以做到的。

现在如果说起主打便携的笔记本电脑的话，可能很多人都会想到12-13寸屏幕+超低压的处理器这样一个搭配。确实，长久以来，笔记本电脑一直可以分为便携和性能两个流派，前者通常配备了11-13寸的屏幕和低电压的处理器，而后者则通常配备了14-17寸的屏幕和标压的处理器。然而这种划分，在上个世纪，可能并不成立。

ThinkPad的笔记本产品线，在发布之初（1993年）就有3个系列：300系列，500系列和700系列。300系列是廉价系列，500是超便携系列，而700则是高性能系列。首发型号的300、500和700分别配备了8英寸、7英寸和9英寸的屏幕，应该来说都是远小于目前的笔记本的屏幕的，屏幕的尺寸并不能成为笔记本定位的衡量依据。几年发展之后，IBM似乎“忘记”了500系列，使劲出了不少300系列和700系列型号，却不见了500系列的影子。虽然期间IBM推出过一些日本限定的500系列机型，如530CS、535、535E、535X、550BJ和555BJ，但是广大北美和欧洲用户，再一次听到500的声音，则是一直等到了1996年的560。而这次的560，配备了12英寸的屏幕和Intel Pentium 133的处理器。这个配置在当时的产品线中是怎么样一个定位呢？有趣的是，当时主打高端的760E笔记本，也只配备了12英寸的屏幕和Intel Pentium 133的处理器，性能上其实并没有明显的差距；而主打低端的365X笔记本，同样配备了Intel Pentium 133的屏幕，不过屏幕降级成了10英寸的CSTN或TFT屏幕。不难发现这三款笔记本在CPU配置上其实并没有太大的差异，而如果按照现在的标准按照屏幕尺寸去判断定位，那可是犯了大错误了，560是三款里面最轻最薄的，而屏幕最小的365X，用过的都知道，就是个大砖头。所以，大致来讲，这三款笔记本主要就是按照外观设计、功能取舍（如FDD和CD）和价格（而基本没有性能区别，当然性价比包括在了价格因素中），面向三种不同的人群的。

今天要展示的，很抱歉不是560，而是560的小改款560E。因为说白了就是一台IBM PC兼容机，没有更多的值得讲，所以这里也就放几张图给大家看下了。

↑ 虽然是便携机，但是接口还是相当齐全的

这次做了一些使用GD32单片机的制作。虽然说GD32是和STM32寄存器级兼容的，确实可以直接使用ST提供的工具和代码，但是这么做明显是违反了ST的协议的（当然使用CMSIS是不违反协议的）。一个方案是使用GD提供的工具和源码库，但是这样如果在未来想要迁移回ST的话则又是给自己找麻烦，所以干脆使用开源的解决方案libopencm3，就没有问题了。顺便调试方案也选择OpenOCD吧，不然用SEGGER的二进制总觉得不太清真。

本文就简单记录下过程，方便以后参考。环境：Arch Linux。

安装必要的依赖

从官方源安装以下包：

# pacman -S arm-none-eabi-gcc arm-none-eabi-newlib

从AUR安装以下包：

• openocd

创建一个项目

这里基本参考libopencm3提供的例子进行：

$ mkdir project
$ cd project
$ git init .
$ git submodule add https://github.com/libopencm3/libopencm3
$ make -C libopencm3 -j5
$ wget -O libopencm3.rules.mk https://raw.githubusercontent.com/libopencm3/libopencm3-examples/master/examples/rules.mk
$ wget -O libopencm3.target.mk https://raw.githubusercontent.com/libopencm3/libopencm3-examples/master/examples/stm32/l1/Makefile.include
$ cp libopencm3/lib/stm32/f1/stm32f103x8.ld .

修改libopencm3.target.mk的最后一行为：

include ../libopencm3.rules.mk

随后建立一个新的src文件夹，随便从libopencm3-examples里面复制个例子过来（.c和Makefile），如下修改Makefile文件：

OPENCM3_DIR = ../libopencm3
LDSCRIPT = ../stm32f103x8.ld

include ../libopencm3.target.mk

直接make hex或者make bin应该就能生成二进制了

使用OpenOCD下载

这里使用SWD方式下载，需要稍微编辑下配置文件

$ cd /usr/share/openocd/scripts/interface
$ cp jlink.cfg jlink-swd.cfg

在里面加入一行 transport select swd 即可。

随后启动OpenOCD并进行烧录：

openocd -f interface/jlink-swd.cfg -f target/stm32f1x.cfg
telnet localhost 4444
reset halt
flash write_image erase project.hex
reset

算是之前的后续吧……一些调试6UL时遇到的事情，记录一下

解压U-boot格式的initrd

$ mkimage -l uImage

显示镜像信息

$ tail -c+65 < uImage > out

去掉文件头

$ tail -c+65  < uImage | gunzip > out

如果文件是gzip压缩的，可以获得压缩前的数据

如果是initramfs，可以用cpio -t < out 或 pax < out来显示文件系统内容。

另外可以尝试挂载文件系统

$ mount -ro loop out /mnt

将initrd打包成U-boot格式

$ umount /mnt
$ mdconfig -d -u 0

将initrd压缩

$ gzip initrd

创建uboot格式镜像

$ mkimage -A arm -T ramdisk -C none -n ramdisk -d initrd.gz ramdisk.uImage