非黑色字体均为我自己添加

原文放在文章末尾

移植WordUp图形工具包

        回到1990年代中(当我年轻的时候!),想要建立自己游戏的程序员并没有像Unity那样丰富的框架.可能我们能得到的最近的就是WordUp图形工具包,它是我遇到的Hot Sound & Vision CD光盘 -- 一个BBS文档.如果你有空,可以去谷歌看看什么是"公告板系统"...怀旧了!

        就像我非常简单的 fb.c,WGT提供了一组图形库的例程,它可以被重用.然而,这个库比我的成熟的多,并且使得它非常用以用来构建基于电子图形的游戏(比如 Breakout, Space Invaders, Pacman 等).

目录结构

        当我移植WGT到我自己的OS时(也就是说让他能在我的操作系统上工作),我使用如下的目录:

• bin/ :为了WGT的二进制文件(字体,电子图形,位图等)

• controller-ios/ :一个IOS平台的Swift示例 BLE控制器

• controller-node/ :一个Node.js示例BLE控制器

• include/ :现在同样包含了wgt.h 和 wgtspr.h (WGT代码必须的头文件)

• samples/ :我操作系统中执行特定WGT库函数的＂内核＂示例.为了执行它们,复制其中一个到与Makefile相同的文件加下(每次一个).

• wgt/ :库本身.在可能的情况下，我一直忠实于原始代码，但请记住它是为x86架构编写的，我们是在AArch64上!

        请注意:我不是一个Node.js开发者,也不是一个Swift开发者,并且所有的控制器只是单纯服务于我的目的的样例.它们并不打算成为样本!我也非常清楚他俩的很多问题...

编译

        所以...简单的在顶部目录敲下 cp samples/wgt01.c . ,然后敲下make来编译第一个WGT样例当你使用产生的 kernel8.img 启动的时候你会发现屏幕变为了 320*200(VGA!)模式,并且从一个角到另一个角花了条白线.如果你看到了,那么这个库在做它该做的事!

boot/boot.S的变化

        我们仍然启动进入多核环境(只是以防我们需要它).然而 boot/boot.S 仍然有一些非常重要的变化.它们是:

• 启动FPU(浮点运算单元),所以我们能使用非整数数学

• 从EL3(监管者异常水平)下降到EL1(内核异常水平),禁用MMU

• 为spin_cpu移动地址来容纳更大的boot.S

• 实现一个get_el函数来检查我们在哪个异常级别(主要为了debug)

使用IOS BLE 控制器

        为了使用IOS控制器而不是Node.js控制器,确保你有:

#define IOS_CONTROL

        在wgt/mouse.c 和 lib/bt.c 顶部都有.没有这个 #define , 代码将会寻找Node.js控制器(如果那是你想要的,就移除它!).

工作正在进行!

        总是有更多的事情可以做,但我认为对让别人的代码在你自己的OS上跑的探索是一个非常好的练习.这真是刺激.

        尝试编译一些样例(提示:wgt20和wgt60非常的有取!)...

        我将要从这里出发,这样我们就能在自己的OS上有所进展.

原文如下

Porting the WordUp Graphics Toolkit

Back in the mid-1990s (when I was young!), programmers who wanted to build their own games didn't have rich frameworks like Unity. Perhaps the closest we got was the WordUp Graphics Toolkit, which I came across on the Hot Sound & Vision CD-ROM - a BBS archive. If you have a moment, perhaps use Google to see what "bulletin board systems" were... nostaglia awaits!

Much like my very simple _fb.c_, the WGT provides a library of graphics routines which can be depended upon for reuse. This library, however, is much more fully-fledged than mine, and makes it easy to build sprite-based games (like Breakout, Space Invaders, Pacman etc.).

The directory structure

As I port the WGT to my OS (a.k.a. make it work on my OS), I am using the following directories:

 * _bin/_ : for WGT binary files (fonts, sprites, bitmaps etc.)

 * _controller-ios/_ : a sample Swift BLE controller for the iOS platform

 * _controller-node/_ : a sample Node.js BLE controller 

 * _include/_ : now contains _wgt.h_ and _wgtspr.h_ too (header files necessary for WGT code)

 * _samples/_ : sample "kernels" for my OS which exercise certain WGT library functions. To build them, copy one of these (and only one at a time) to the same directory as the _Makefile_.

 * _wgt/_ : the library itself. Where possible, I have stayed true to the original code, but do bear in mind it was written for the x86 architecture and we're on AArch64!

Please note: I am neither a Node.js developer, nor a Swift developer, and so the controllers are purely samples that serve my purpose. They are not intended to be exemplars! I am very aware of the multitudinous problems with both...

Building

So... to build the first WGT sample simply type `cp samples/wgt01.c .` from the top-level directory, and then type `make`. When you boot with the generated _kernel8.img_ you will see the screen go into 320x200 (VGA!) mode and draw a white line from corner to corner. If you do, the library is doing its stuff!

boot/boot.S changes

We're still booting into a multicore environment (just in case we need it). There are a few significant changes to _boot/boot.S_ though. They are:

 * Enable FPU (floating-point unit) access so we can do non-integer mathematics

 * Switch from EL3 (supervisor exception level) down to EL1 (kernel exception level), disabling the MMU all the same

 * Move the addresses for the `spin_cpu` variables to accommodate a larger _boot.S_

 * Implement a `get_el` function to check which exception level we're at (for debug mainly)

Using the iOS BLE controller

To use the iOS BLE controller instead of the Node.JS controller, ensure that you have:

```c

#define IOS_CONTROL

```

at the top of each of _wgt/mouse.c_ and _lib/bt.c_. Without this `#define`, the code will be looking for the Node.JS controller (so remove these lines if that's what you want!).

Work in progress!

There's always more that can be done, but I do think this was a good exercise in exploring the joy of getting other people's code to run on your own OS! It's quite a thrill.

_Do have a go at building some of the samples (hint: wgt20 and wgt60 are super fun!)..._

I'm going to move on from here now so we can continue to make progress on the OS itself.