准备登录到服务器后，大概率是这样的一个界面： 1234567891011121314You can:(q) Quit and do nothing. The function will be run again next time.(0) Exit, creating the file ~/.zshrc containing just a comment. That will pre

JIT 编译所有的 NES 指令

问题调试 JIT 尤其是 difftest 的时候，在初期每次都要重新编译，烧录 sd 卡然后启动等待报错，再 debug。这个迭代周期非常多。如果每次都这样做，那么开发周期将会非常漫长，因此在 qemu 中直接跑 JIT 会大大加快开发进度。 显示设备qemu 一般都带显示设备，但是我们的游戏设计要在 hdmi 这种设备播放，因此最好能找一个支持帧缓冲的 qemu 设备就最好了。好消息是真有这个

问题通过 NES 模拟器，运行 mario 的效率太低了，主要的时间花费在了图像渲染上： 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051void am_gpu_fbdraw(int x, int y, uint32_t *pixels, int w, int

本文介绍如何将基于 AbstractMachine (AM) 抽象层的 LiteNES 模拟器移植到 xOS 上运行。重点讲解 AM 的设计理念，以及如何通过实现 AM 适配层让应用程序在不同平台间无缝迁移。 AbstractMachine 简介什么是 AbstractMachineAbstractMachine (AM) 是南京大学计算机系统基础课程设计的一套硬件抽象层。它的核心思想是： 将应

本文详细介绍 xOS Shell 中各个命令的实现方式。Shell 是操作系统与用户交互的核心组件，通过命令表驱动的方式实现了多种实用命令。 Shell 架构概述命令表设计xOS 使用静态命令表来管理所有可用命令： 12345678910111213141516171819202122typedef struct { const char *name; // 命

前言上节讨论了 HDMI 控制器的双 buffer 控制机制以及双 linebuffer 交换机制。本节基于 bufferframe 设计显示系统：将图像以及文字显示到 hdmi 显示的组件。 shell之前有 uart 显示屏的组件，它的原理就是对底层 putchar 进行重定向，这样只要 printf() 就能在 uart 显示屏上打印了： 12345678910111213141516171

HDMI 控制器在目前的 FPGA 板卡上设计的资源占用率如下。其中 mig_axi_32： 12345678910111213141516+----------------------------+------+-------+------------+-----------+-------+| Site Type | Used | Fixed | Prohib

前言之前的 xOS 运行很简单，就是简单的 shell，用户通过输入命令，回车后，离开 shell，去执行具备某个功能的函数，执行完再返回。 这样的设计有问题，因为一旦离开 shell，就意味着不能再接受输入了。而且一旦遇到意外，比如执行了某些代码，可能就再也回不到 shell 了。 因此我打算对 xOS 进行升级，基于时钟中断和原来的异常入口。 从中断到调度任务的单位是线程 Thread，要对某