dustpg / blogfm Goto Github PK

STEP3: CPU 指令实现 - 基础指令

这节就详细谈谈基础指令, 所谓'基础指令'只是自己随便命名的, 避免一节过长, 请勿对号入座.

指令周期

不同指令需要消耗不同的周期, 这很好理解. 不过就算相同的指令环境不同也会消耗不同周期:

• 页面边界交叉(Page Boundary Crossed)
  • 页面边界交叉是指6502将内存划分为256个页面(8位机但是拥有16位地址空间).
  • 当访问不同页面时, 需要额外的指令周期去读取.
• 跳转到不同页面(Branch Occurs Different Page)
  • 意思和上面的差不多
• 这两个会在这一步的最后一节详细谈谈

LDA - Load "A"

* 在页面边界交叉时 +1s

由存储器取数送入累加器A, 影响FLAG: Z(ero),S(ign), 伪C代码:

A = READ(address);
CHECK_ZSFLAG(A);

LDX - Load 'X'

* 在页面边界交叉时 +1s

由存储器取数送入变址寄存器X, 影响FLAG: Z(ero),S(ign), 伪C代码:

X = READ(address);
CHECK_ZSFLAG(X);

LDY - Load 'Y'

* 在页面边界交叉时 +1s

由存储器取数送入变址寄存器Y, 影响FLAG: Z(ero),S(ign), 伪C代码:

Y = READ(address);
CHECK_ZSFLAG(Y);

STA - Store 'A'

将累加器A的数送入存储器, 影响FLAG:(无), 伪C代码:

WRTIE(address, A);

STX - Store 'X'

将变址寄存器X的数送入存储器, 影响FLAG:(无), 伪C代码:

WRTIE(address, X);

STY - Store 'Y'

将变址寄存器Y的数送入存储器, 影响FLAG:(无), 伪C代码:

WRTIE(address, Y);

ADC - Add with Carry

助记符号 A = A + M +C

* 在页面边界交叉时 +1s

累加器,存储器,进位标志C相加,结果送累加器A.
影响FLAG: S(ign), Z(ero), C(arry), (o)V(erflow), 伪C代码:

src = READ(address);
uint16_t result16 = A + src + (CF ? 1 : 0);
CHECK_CFLAG(result16>>8);
uint8_t result8 = result16;
CHECK_VFLAG(!((A ^ src) & 0x80) && ((A ^ result8) & 0x80));
A = result8;
CHECK_ZSFLAG(A);

SBC - Subtract with Carry

助记符号 A = A - M - (1-C)

从累加器减去存储器和进位标志C,结果送累加器A.
影响FLAG: S(ign), Z(ero), C(arry), (o)V(erflow), 伪C代码:

src = READ(address);
uint16_t result16 = A - src - (CF ? 0 : 1);
CHECK_CFLAG(!(result16>>8));
uint8_t result8 = result16;
CHECK_VFLAG(((A ^ result8) & 0x80) && ((A ^ src) & 0x80));
A = result8;
CHECK_ZSFLAG(A);

INC - Increment memory

存储器单元内容+1, 影响FLAG:Z(ero),S(ign), 伪C代码:

tmp = READ(address);
++tmp;
WRITE(address, tmp);
CHECK_ZSFLAG(tmp);

DEC - Decrement memory

存储器单元内容-1, 影响FLAG:Z(ero),S(ign), 伪C代码:

tmp = READ(address);
--tmp;
WRITE(address, tmp);
CHECK_ZSFLAG(tmp);

AND - 'And' memory with A

* 在页面边界交叉时 +1s

存储器单元与累加器做与运算, 影响FLAG:Z(ero),S(ign), 伪C代码:

A &= READ(address);
CHECK_ZSFLAG(A);

ORA - 'Or' memory with A

* 在页面边界交叉时 +1s

存储器单元与累加器做或运算, 影响FLAG:Z(ero),S(ign), 伪C代码:

A |= READ(address);
CHECK_ZSFLAG(A);

EOR - "Exclusive-Or" memory with A

* 在页面边界交叉时 +1s

存储器单元与累加器做异或运算, 影响FLAG:Z(ero),S(ign), 伪C代码:

A ^= READ(address);
CHECK_ZSFLAG(A);

INX - Increment X

变址寄存器X内容+1, 影响FLAG:Z(ero),S(ign), 伪C代码:

++X;
CHECK_ZSFLAG(X);

DEX - Decrement X

变址寄存器X内容-1, 影响FLAG:Z(ero),S(ign), 伪C代码:

--X;
CHECK_ZSFLAG(X);

INY - Increment Y

变址寄存器Y内容+1, 影响FLAG:Z(ero),S(ign), 伪C代码:

++Y;
CHECK_ZSFLAG(Y);

DEY - Decrement Y

变址寄存器Y内容-1, 影响FLAG:Z(ero),S(ign), 伪C代码:

--Y;
CHECK_ZSFLAG(Y);

TAX - Transfer A to X

将累加器A的内容送入变址寄存器X, 影响FLAG:Z(ero),S(ign), 伪C代码:

X = A;
CHECK_ZSFLAG(X);

TXA - Transfer X to A

将变址寄存器X的内容送入累加器A, 影响FLAG:Z(ero),S(ign), 伪C代码:

A = X;
CHECK_ZSFLAG(A);

TAY - Transfer A to Y

将累加器A的内容送入变址寄存器Y, 影响FLAG:Z(ero),S(ign), 伪C代码:

Y = A;
CHECK_ZSFLAG(Y);

TYA - Transfer Y to A

将变址寄存器Y的内容送入累加器A, 影响FLAG:Z(ero),S(ign), 伪C代码:

A = Y;
CHECK_ZSFLAG(A);

TSX - Transfer SP to X

将栈指针SP内容送入变址寄存器X, 影响FLAG:Z(ero),S(ign), 伪C代码:

X = SP;
CHECK_ZSFLAG(X);

TXS - Transfer X to SP

将变址寄存器X内容送入栈指针SP, 影响FLAG:无, 伪C代码:

SP = X;

CLC - Clear Carry

清除进位标志C, 影响FLAG: C(arry), 伪C代码:

CF = 0;

SEC - Set Carry

设置进位标志C, 影响FLAG: C(arry), 伪C代码:

CF = 1;

CLD - Clear Decimal

清除十进制模式标志D, 影响FLAG: D(Decimal), 伪C代码:

DF = 0;

SED - Clear Decimal

设置十进制模式标志D, 影响FLAG: D(Decimal), 伪C代码:

DF = 1

CLV - Clear Overflow

清除溢出标志V, 影响FLAG: (o)V(erflow), 伪C代码:

VF = 0;

CLI - Clear Interrupt-disable

清除中断禁止标志I, 影响FLAG: I(nterrupt-disable), 伪C代码:

IF = 0;

SEI - Set Interrupt-disable

设置中断禁止标志I, 影响FLAG: I(nterrupt-disable), 伪C代码:

IF = 1;

CMP - Compare memory with A

比较储存器值与累加器A.
影响FLAG: C(arry), S(ign), Z(ero). 伪C代码:

uint16_t result16 = (uint16_t)A - (uint16_t)READ(address);
CF = result16 < 0x100;
CHECK_ZSFLAG((uint8_t)result16);

CPX - Compare memory with X

比较储存器值与变址寄存器X.
影响FLAG: C(arry), S(ign), Z(ero). 伪C代码:

uint16_t result16 = (uint16_t)X - (uint16_t)READ(address);
CF = result16 < 0x100;
CHECK_ZSFLAG((uint8_t)result16);

CPY - Compare memory with Y

比较储存器值与变址寄存器Y.
影响FLAG: C(arry), S(ign), Z(ero). 伪C代码:

uint16_t result16 = (uint16_t)Y - (uint16_t)READ(address);
CF = result16 < 0x100;
CHECK_ZSFLAG((uint8_t)result16);

BIT - Bit test memory with A

位测试

• 若 A&M 结果 =0, 那么Z=1
• 若 A&M 结果!=0, 那么Z=0
• S = M的第7位
• V = M的第6位

影响FLAG: (o)V(erflow), S(ign), Z(ero). 伪C代码:

tmp = READ(address);
VF = (tmp >> 6) & 1;
SF = (tmp >> 7) & 1;
ZF = A & tmp ? 0 : 1;

ASL - Arithmetic Shift Left

助记符号: C <- |7|6|5|4|3|2|1|0| <- 0

累加器A, 或者存储器单元算术按位左移一位. 最高位移动到C, 最低位0. 影响FLAG: S(ign) Z(ero) C(arry), 伪C代码:

// ASL A:
CHECK_CFLAG(A>>7);
A <<= 1;
CHECK_ZSFLAG(A);

// 其他情况
tmp = READ(address);
CHECK_CFLAG(tmp>>7);
tmp <<= 1;
WRITE(address, tmp);
CHECK_ZSFLAG(tmp);

LSR - Logical Shift Right

助记符号: 0 -> |7|6|5|4|3|2|1|0| -> C

累加器A, 或者存储器单元逻辑按位右移一位. 最低位回移进C, 最高位变0, 影响FLAG: S(ign) Z(ero) C(arry), 伪C代码:

// LSR A:
CHECK_CFLAG(A & 1);
A >>= 1;
CHECK_ZSFLAG(A);

// 其他情况
tmp = READ(address);
CHECK_CFLAG(tmp & 1);
tmp >>= 1;
WRITE(address, tmp);
CHECK_ZSFLAG(tmp);

ROL - Rotate Left

助记符号: ...|0| <- C <- |7|6|5|4|3|2|1|0| <- C <- |7|...

累加器A, 或者储存器内容 连同C位 按位循环左移一位, 影响FLAG: S(ign) Z(ero) C(arry), 伪C代码:

// A_M 意思到了就行
uint16_t src = A_M;
src <<= 1;
if (CF) src |= 0x1;
CHECK_CFLAG(src > 0xff);
A_M = src;
CHECK_ZSFLAG(A_M);

ROR - Rotate Right

助记符号: ...|0| -> C -> |7|6|5|4|3|2|1|0| -> C -> |7|...

累加器A, 或者储存器内容 连同C位 按位循环左移一位, 影响FLAG: S(ign) Z(ero) C(arry), 伪C代码:

// A_M 意思到了就行
uint16_t src = A_M;
if (CF) src |= 0x100;
CF = src & 1;
src >> 1;
A_M = src;
CHECK_ZSFLAG(A_M);

PHA - Push A

累加器A压入栈顶(栈指针SP-1). 影响FLAG:(无), 伪C代码:

PUSH(A);

PLA - Pull(Pop) A

push的反操作, 在6502汇编称为pull, 不过自己还是习惯称为pop.
6502_cn这篇文档提到没有FLAG修改, 可能是笔误, 其他文档(比如这个)提到会影响S(ign) Z(ero) , 伪C代码:

A = POP();
CHECK_ZSFLAG(A);

PHP - Push Processor-status

将状态FLAG压入栈顶, 影响FLAG:(无), 伪C代码:

PUSH(P | FLAG_B | FLAG_R);

PLP - Pull Processor-status

PHP逆操作, 影响FLAG: (是的), 伪C代码:

p = POP();
// 无视BIT4 BIT5
RF = 1;
BF = 0;

REF

• nesdev-archive
• NES 文档2.00
• 6502 微处理器
• 6502_cpu

进行协同

如果要在D3D11 上进行2D绘制， 使用Direct2D将是一个不错的选择，因为D2D就是由D3D实现的，可以实现几乎无缝地交互协同工作.
微软在Direct2D and Direct3D Interoperability Overview中提到了这两种协同:

1. 直接在现有的交换链/RTV 上绘制, 就像一般正交投影绘制的UI一样
2. 绘制到纹理上让模型展示出来. 这样可以干的事情就多了. 特别地, 如果不是专门设计的3D展示UI, 用一般2D的UI然后放在一个矩形里面充当一个伪3D UI也是不错的选择. 这也是LongUI的实现目标之一.
   

直接协同

如同题目所述: 直接协同. 微软在文中是用一种"共享"的办法, 利用D3D 10作为中介让D3D11与D2D协同, 简直太麻烦了. 文中提到

With DirectX 11.1 or later, Direct2D supports interoperability with Direct3D 11 as well.

这里应该指的是版本号而非指特性等级.因为我在Win7的虚拟机(虚拟显卡只支持到10.1)也能够工作. 这里推荐的方法是(使用 Direct2D 1.1, 下面只包括D2D端必要数据)

                      +--------------+          +--------------+
                      |              |    QI    |              |
     +--------------> | ID3D11Device*+----------> IDXGIDevice1 |
     |                |              |          |              |
     |                +--------------+          +--+-----------+
     |                                             |
     |                                             |
     |                                             |      +-----------------+
+----+----+   +--------+     +----------------+    v      |                 |
|  D3D11  |   | D2D1.1 +-----> ID2D1Factory1  +----+----->+   ID2D1Device   |
+---+-----+   +--------+     +----------------+           |                 |
    |                                                     +-+---------------+
    |                                                       |
    |                                                       v
    |         +-------------------------+                  ++-------------------+
    +-------->+   ID3D11Texture2D**     |                  |                    |
              +--------------+----------+                  | ID2D1DeviceContext |
                             |                             |                    |
                             |                             +--------+-----------+
                             | QI  +---------------+                |
                             +---->+ IDXGISurface  +--------------->+
                                   +---------------+                |
                                                                    |
                                                                    v
                                                         +----------+-----------+
                                                         |     ID2D1Bitmap1***  |
                                                         +----------+-----------+
                                                                    |
                                                                    |
                                                                    v
                                              +---------------------+-----------+
                                              |                                 |
                                              | ID2D1DeviceContext::SetTarget   |
                                              |                                 |
                                              +---------------------------------+

*: 创建ID3D11Device: 记得D3D11_CREATE_DEVICE_BGRA_SUPPORT
**: 创建ID3D11Texture2D: 记得MipLevels=1
***: ID2D1DeviceContext::CreateBitmapFromDxgiSurface

这样全局可以共享一个ID2D1DeviceContext, 文本所使用的代码在NoteFL/D3D11/D3D11InteropWithD2D/main.cpp 这里，懒得渲染字体什么的了, 画个圈圈意思一下就行:

自己常用的小技巧

这里列出了自己常用的一些c/c++小技巧, 有些会有不足, 可以简单探讨一下.

模板与源文件

分类: 隐藏实现

大家可能都会有一个情况, 希望模板的实现在源文件中, 头文件中实现感觉有点"不舒服". 这里就探讨几种实现方式.

试想有以下三个文件, "test.h", "test.cpp", "main.cpp":

// test.h
#include <cstdint>
template<typename T> int32_t MyAtoI(const T str[], uint32_t);


// test.cpp
#include "test.h"

template<typename T>
int32_t MyAtoI(const T str[], uint32_t) {
    // 具体实现
    return 0;
}

// main.cpp
#include "test.h"

int main() {
    return MyAtoI("1.0", 3);
}

这样结果如果呢? 当然是链接时错误: 找不到`int MyAtoI(char const*, unsigned int)'的符号. 解决方法自然是让链接器找到这个符号就行.

比如可以在实现的源文件增加一个函数调用:

// test.cpp 实现2

#include "test.h"

template<typename T>
int32_t MyAtoI(const T str[], uint32_t) {
    return 0;
}
void fake_func() {
    MyAtoI("", 0);
    MyAtoI(u"", 0);
    MyAtoI(U"", 0);
}

缺点自然就是必须有啥就得加一个, 'char'还好说就那几个, vector<T>这个就不好弄了, 不过vector<T>这种, 头文件实现更为方便. 这种适合比较长的函数然后模板参数是可以简单预测的.

看到这个是不是想到了什么? 对了模板特化! 这个感觉和模板特化很类似. 同样, 模板特化也能作为一个实现方法:

// test.cpp 实现3
#include "test.h"

template<>
int32_t MyAtoI<char>(const char str[], uint32_t) {
    return 0;
}

template<>
int32_t MyAtoI<char16_t>(const char16_t str[], uint32_t) {
    return 0;
}

template<>
int32_t MyAtoI<char32_t>(const char32_t str[], uint32_t) {
    return 0;
}

这样或许失去了模板的优点, 所以还能这样:

// test.cpp 实现4

#include "test.h"


template<typename T> static inline
int32_t MyAtoI_static(const T str[], uint32_t) {
    return 0;
}

template<>
int32_t MyAtoI<char>(const char str[], uint32_t l) {
    return MyAtoI_static(str, l);
}

template<>
int32_t MyAtoI<char16_t>(const char16_t str[], uint32_t l) {
    return MyAtoI_static(str, l);
}

template<>
int32_t MyAtoI<char32_t>(const char32_t str[], uint32_t l) {
    return MyAtoI_static(str, l);
}

所以, 只要找到了对应的符号, 想怎么弄就怎么弄.

extern 重解释

分类: 小技巧

上面提到符号, 而且说了这么多C++的, 该说一点C的了. 说到C大家都知道没有类型安全一说, 甚至调用函数都不用进行声明. 利用这一点甚至可能手动写函数机器码的实现.

重解释也是非常重要的一个概念, c里面就可以用extern进行简单粗暴的重解释现有数据:

// 源文件1
#include <stdint.h>

void foo(void);

int main(void) {
    foo();
    return 0;
}

// 源文件2
#include <stdio.h>

extern const unsigned char main[];

void foo(void) {
    for (int i = 0; i != 16; ++i) {
        printf("0x%p: 0x%02X\n", main +i, main[i]);
    }
}

这样可以简单输出main函数的机器码实现, 不过似乎标准并没有规定数据区和代码区在同一个地址空间所以是UB.

不过这里是‘extern 重解释’, 重解释的是已有的数据:

// 源文件1
#include <stdio.h>

extern const unsigned char data_01[];

int main(void) {
    for (int i = 0; i != 16; ++i) {
        printf("0x%p: 0x%02X\n", data_01 +i, data_01[i]);
    }
    return 0;
}

// 源文件2
const double data_01[]= { 0.1, 0.2, 0.3, 0.4};

const 癌晚期

分类: 强迫症福音

自从看到'cosnt anywhere'后, 真的是到处放const:

const auto bar = foo.bar();

不过有些get函数是放在参数里面的:

int bar = 0;
foo.get(&bar);

不过c++11引入的匿名表达式真的是功能强大的特性:

const auto bar = [&foo](){
    int bar = 0;
    foo.get(&bar);
    return bar;
}();

Eagle

下面继续讨论一些关于像素风格缩放算法.

Eagle本身是一个比较初级的想法Eagle (idea), 称不上真正的算法, 但是有些后续的算法就是基于Eagle的. Eagle是放大至2倍, 这里称之为eagle2x.

Eagle想得很简单, 放大两倍后, 那个像素旁边原本3个像素颜色一样的话就设定为该颜色, 否则就是最邻的.

first:        |Then
. . . --\ CC  |S T U  --\ 1 2
. C . --/ CC  |V C W  --/ 3 4
. . .         |X Y Z
              | IF V==S==T => 1=S
              | IF T==U==W => 2=U
              | IF V==X==Y => 3=X
              | IF W==Z==Y => 4=Z

同样可以根据同样的**派生出eagle3x, 像素着色器可以简单实现为:

float4 eagle2x(uint2 pos) {
    const uint2 real_pos = pos / 2;
    float4 A, B, C;
    switch ((pos.x & 1) | ((pos.y & 1) << 1))
    {
    case 0:
        // AB
        // C
        A = InputTexture[real_pos - uint2(1, 1)];
        B = InputTexture[real_pos - uint2(0, 1)];
        C = InputTexture[real_pos - uint2(1, 0)];
        break;
    case 1:
        //  AB
        //   C
        A = InputTexture[real_pos - uint2(0, 1)];
        B = InputTexture[real_pos + int2(1, -1)];
        C = InputTexture[real_pos + uint2(1, 0)];
        break;
    case 2:
        // A
        // BC
        A = InputTexture[real_pos - uint2(1, 0)];
        B = InputTexture[real_pos + int2(-1, 1)];
        C = InputTexture[real_pos + uint2(0, 1)];
        break;
    case 3:
        //  A
        // BC
        A = InputTexture[real_pos + uint2(1, 0)];
        B = InputTexture[real_pos + uint2(0, 1)];
        C = InputTexture[real_pos + uint2(1, 1)];
        break;
    }
    return (eq(A, B) && eq(A, C)) ? A : InputTexture[real_pos];
}

来看看效果:

(eagle2x后4倍最邻插值)

(与8倍最邻插值比较)

可以看出处理后很多东西变得粗细不一, 不适合缩放曲线条, 甚至可以看到一些单独的点被去掉了, 这个算法(想法)只能测试用, 没法实际使用.

2×SaI

全称2× Scale and Interpolation engine, 作者Derek Liauw Kie Fa(Kreed)看到Eagle后想到的. 这里称为sai2x. 作者以GPL形式发布, (作者的)是一个完整的实现, 并不能算是算法, 维基提到可以以完全重写的方式避免被GPL病毒传染.

通过阅读源代码, emmm, 上古代码, 还是16bit的颜色, 对于显卡用的float4感觉差了一个世纪.

sai2x有一个重要步骤: 插值, 会生成新的颜色. 作者实现的插值感觉很不错, 值得学习, 不过这里由于是float4直接取平均值.

I|E F|J
G|A B|K   A -\  A0 A1
H|C D|L     -/  A2 A3
M|N O|P

    A0 = A

    IF  A == D AND B != C, THEN
        IF (A == E AND B == L) OR (A == C AND A == F AND B != E AND B == J), THEN
            A1 = A
        ELSE
            A1 = INTERPOLATE(A, B)
        ENDIF
        IF (A == G AND C == O) OR (A == B AND A == H AND G != C AND C == M), THEN
            A2 = A
        ELSE
            A2 = INTERPOLATE(A, C)
        ENDIF
        A3 = A
    ELSIF B == C AND A != D, THEN
        IF (B == F AND A == H) OR (B == E AND B == D AND A != F AND A == I), THEN
            A1 = B
        ELSE
            A1 = INTERPOLATE(A, B)
        ENDIF
        IF (C == H AND A == F) OR (C == G AND C == D AND A != H AND A == I), THEN
            A2 = C
        ELSE
            A2 = INTERPOLATE(A, C)
        ENDIF
        A3 = B
    ELSIF A == D AND B == C, THEN
        IF A == B, THEN
            A1 = A2 = A3 = A
        ELSE
            A1 = INTERPOLATE(A, B)
            A2 = INTERPOLATE(A, C)
            A3 = A3_SP_PROC(A, B, C, D, ...)
        ENDIF
    ELSE
        IF A == C AND A == F AND B != E AND B == J, THEN
            A1 = A
        ELSIF B == E AND B == D AND A != F AND A == I, THEN
            A1 = B
        ELSE
            A1 = INTERPOLATE(A, B)
        ENDIF
        IF A == B AND A == H AND G != C AND C == M, THEN
            A2 = A
        ELSIF C == G AND C == D AND A != H AND A == I, THEN
            A2 = C
        ELSE
            A2 = INTERPOLATE(A, C)
        ENDIF
        A3 = INTERPOLATE(A, B, C, D);
    ENDIF

可以看出作者将图像分为几个情况分别处理, 比如最外面的4个分支分别对应, 这个点可能是'', '/', 'X', 以及其他情况, 导致分支非常多. 中间还有一个作者自己发明的插值公式, 在这简写为A3_SP_PROC. 由于分支实在太多, 自己有可能重写错了.

(sai2x后4倍最邻插值)

(与8倍最邻插值, 以及2倍线性插值后4倍最邻插值比较)

可以看出因为A0点总是原来值, 所以放大后看起来像是往左上角偏了一个像素. 由于插值, 新加入了中间色, 实际上以100%比例看更合适, 所以像素风不再.

对于圆的处理效果很不错, 单独的点被处理成'星(+)'状, 要知道这是一个2倍的缩放, '+'是三个像素的. 效果最差的是'点状网', 主要是中间和边缘的效果不一致.

SuperEagle

作者同2xSaI的Kreed. 针对Eagle算法做出了改进.

原称呼:
   B1 B2
4  5  6  S2
1  2  3  S1
   A1 A2
改为:
   A B
 C D E F     D -\ D0 D1
 G H I J       -/ D2 D3
   K L

    IF H == E AND D != I, THEN
        D1 = D2 = H
        IF G == H OR E == B, THEN
            D0 = INTERPOLATE(H, H, D)
        ELSE
            D0 = INTERPOLATE(D, E)
        ENDIF

        IF E == F OR H == K, THEN
            D3 = INTERPOLATE(H, H, I)
        ELSE
            D3 = INTERPOLATE(H, I)
        ENDIF
    ELSIF D == I AND H != E, THEN
        D3 = D0 = D

        IF A == D OR F == J, THEN
            D1 = INTERPOLATE(D, D, E)
        ELSE
            D1 = INTERPOLATE(D, E)
        ENDIF

        IF I == L OR C == D, THEN
            D2 = INTERPOLATE(D, D, H)
        ELSE
            D2 = INTERPOLATE(H, I)
        ENDIF
    ELSIF D == I AND H == E, THEN
        D0D1D2D3_SP_POC(A, B, C, D, ...)
    ELSE 
        D3 = D0 = INTERPOLATE(H, E)
        D3 = INTERPOLATE(I, I, I, D3)
        D0 = INTERPOLATE(D, D, D, D0)

        D2 = D1 = INTERPOLATE(D, I)
        D2 = INTERPOLATE(H, H, H, D2)
        D1 = INTERPOLATE(E, E, E, D1)
    ENDIF

有两次插值的地方, float4的话可以直接A*0.75+B*0.25, 也有类似sai2x的地方, 作者自己发明的插值算法, 这里用D0D1D2D3_SP_POC代替.

(supereagle后4倍最邻插值)

既然是Eagle的'升级版', 就和Eagle比较吧.

可以看出作者很喜欢插值, 把Eagle不会引入新颜色的特点去掉了. 不过顺带解决了Eagle的BUG, 也就是消失的单独点, 代替的是颜色浅了, 变成25%, 不过也变成4倍. 当然, 也有像素偏移的现象.

Super2xSaI

Super2xSaI, 这里称为supersai2x, 作者同2xSaI的Kreed, 针对2xSaI算法做出了改进(了吗?).

原称呼:
  B0 B1 B2 B3
  4  5  6  S2
  1  2  3  S1
  A0 A1 A2 A2
改为:
    A B C D               
    E F G H     F -\ F0 F1
    I J K L       -/ F2 F3
    M N O P



    IF J == G AND F != K, THEN
        F1 = F3 = J
    ELSIF F == K AND J != G, THEN
        F1 = F3 = F
    ELSIF F == K AND J == G, THEN
        F3 = F1 = F1_SP_PROC(A, B, C, D, ...)
    ELSE
        IF G == K AND K == N AND J != O AND K != M, THEN
            F3 = INTERPOLATE(K, K, K, J)
        ELSIF F == J AND J == O AND N != K AND J != P, THEN
            F3 = INTERPOLATE(J, J, J, K)
        ELSE
            F3 = INTERPOLATE(J, K)
        ENDIF

        IF G == K AND G == B AND F != C AND G != A, THEN
            F1 = INTERPOLATE(G, G, G, F)
        ELSIF (F == J AND F == C AND B != G AND F != D)
            F1 = INTERPOLATE(G, F, F, F)
        ELSE
            F1 = INTERPOLATE(F, G)
        ENDIF
    ENDIF

    ; ELSIF 这里可以看作 OR
    IF J == G AND F != K AND I == J AND J != C, THEN
        F0 = INTERPOLATE(J, F)
    ELSIF E == J AND K == J AND I != F AND J != A, THEN
        F0 = INTERPOLATE(J, F)
    ELSE
        F0 = F
    ENDIF

    ; ELSIF 这里可以看作 OR
    IF F == K AND J != G AND E == F AND F != O, THEN
        F2 = INTERPOLATE(J, F)
    ELSIF F == I AND G == F AND E != J AND F != M, THEN
        F2 = INTERPOLATE(J, F)
    ELSE
        F2 = J
    ENDIF

可能是是性能上的提升吧?

(supersai2x后4倍最邻插值)

可以看出依旧在100%下是最好的. BUG? 这个算法有BUG吧? 感觉像素变成竖线了. 和2xSaI对比一下:

(与2xSaI对比, 均作了4倍最邻插值)

处理得比较好的是非坐标对齐的图像, 处理得不好的是坐标对齐的图像, 可能这是这个算法的偏向吧.

作者Kreed的这一系列大致是对点周围共计16点判断, 然后生成2x2的新数据, 会产生新的像素, 会产生像素偏移.

REF

• The advanced 2x Scale and Interpolation engine

HQx

进入HQx族了, HQx系列有一个特别的地方: 抗锯齿.

根据维基的介绍, HQx大致分为两个, 原版Maxim Stepin的HQx以及效果稍微差但是省空间的ScaleHQ.

前者, 作者形式发布的代码, 就算出现问题, 我们可以派生出一个LGPL实现分支, 然后直接使用预编译的二进制码即可. 后者, 则是由不同的作者实现, 然后被误以为是原版的HQ.

2xScaleHQ

那就先说说简单版的ScaleHQ吧, 似乎由guest(r)实现的. 根据libretro的文档, 有两个放大率的, 这里称为scalehq2x 和scalehq4x. 2x应该是在public domain, 而4x是GPL.

代码上根本看不出算法, 只有数学运算, 猜测是将像素转换成图形, 然后继续渲染. 不过懒得去研究, 直接简单改写scalehq2x用于支持本框架. 由于抗锯齿的原因, 这个效果在100%下效果最好, 这是效果:

4xScaleHQ

这是guest(r)在GPL下发布的, 同2xScaleHQ, 只有数学运算:

ScaleHQ

可以看出, ScaleHQ的优点是: ScaleHQ是专门为Shader编写的算法, 中间几乎没有分支, 全是运算.

缺点非常明显, 折线过渡不自然:

图中两个地方理论上应该有像素过渡的三角.

原版HQx

原版Maxim Stepin的HQx(HQ2x, HQ3x, HQ4x)总的来说是依靠查表, 对于一个点周围8点在YUV空间下形成256次可能性, 然后分别处理. 不过还是难不倒大佬们, 移植到了着色器上. 也是以LGPL形式发布的, 建议直接用了, LGPL用二进制文件即可.

实际移植的时候发现图像出现问题, 找了几天终于发现原来是图片载入出现问题了(32bppBGRA vs 32bppPBGRA), 导致LUT的权重读取错了.

(HQ2x-100%下效果)

(HQ3x-100%下效果)

(HQ4x-100%下效果)

(HQ4x后再用双三次插值到原比例的8倍)

HQx处理的效果非常讨人喜, 之前ScaleHQ提到的折线转交处也处理得很不错.

缺点, 除了实现比较困难外, 效果上可能就是把那个笑脸变成相低多边形的圆了. 而实际上, HQx在文字显示上, 非常不错. 不过在游戏中, 由很多颜色组成的实际画面就稍微差了一点(感觉一块一块的).

REF

• HQx
• ScaleHQ on libretro

拉格朗日点

之所以将游戏名称作为小标题, 自然是说到可乐妹的VRC7, 就不得不说'拉格朗日点'了, 因为这是一款唯一使用了VRC7的游戏. 被不少人冠上'FC最强音乐'的帽子.

当然实际上还有一款'兔宝宝历险记2(日版)'也使用了VRC7, 不过'兔宝宝历险记2'没有使用到VRC7的扩展音源(实体卡带比前者小了不少, 可以看作前者使用了VRC7a, 后者使用了VRC7b).

BANK

CPU $8000-$9FFF: 8 KB switchable PRG ROM bank
CPU $A000-$BFFF: 8 KB switchable PRG ROM bank
CPU $C000-$DFFF: 8 KB switchable PRG ROM bank
CPU $E000-$FFFF: 8 KB PRG ROM bank, fixed to the last bank
CHR $0000-$03FF: 1 KB switchable CHR ROM bank
CHR $0400-$07FF: 1 KB switchable CHR ROM bank
CHR $0800-$0BFF: 1 KB switchable CHR ROM bank
CHR $0C00-$0FFF: 1 KB switchable CHR ROM bank
CHR $1000-$13FF: 1 KB switchable CHR ROM bank
CHR $1400-$17FF: 1 KB switchable CHR ROM bank
CHR $1800-$1BFF: 1 KB switchable CHR ROM bank
CHR $1C00-$1FFF: 1 KB switchable CHR ROM bank

感觉都还科学. 变种区别为

• VRC7b 使用 A3 来选寄存器($x008)
• VRC7a 使用 A4 来选寄存器($x010)

PRG Select 0 ($8000)

7  bit  0
---------
..PP PPPP
  || ||||
  ++-++++- Select 8 KB PRG ROM at $8000

64*8=512

PRG Select 1 ($8010, $8008)

7  bit  0
---------
..PP PPPP
  || ||||
  ++-++++- Select 8 KB PRG ROM at $A000

PRG Select 2 ($9000)

7  bit  0
---------
..PP PPPP
  || ||||
  ++-++++- Select 8 KB PRG ROM at $C000

CHR Select 0…7 ($A000…$DFFF)

Mirroring Control ($E000)

7  bit  0
---------
RS.. ..MM
||     ||
||     ++- Mirroring (0: vertical; 1: horizontal;
||                        2: one-screen, lower bank; 3: one-screen, upper bank)
|+-------- Silence expansion sound if set
+--------- WRAM enable (1: enable WRAM, 0: protect)

IRQ Control ($E008 - $F010)

$E008, $E010:  IRQ Latch
       $F000:  IRQ Control
$F008, $F010:  IRQ Acknowledge

对比起VRC6起来, 简直不知道友好到哪里去! 根据地址线的规律, 可以使用:

    const uint16_t vrc7a = address >> 4;
    const uint16_t vrc7b = address >> 3;
    const uint16_t base = (((address >> 11) & 0xfffe) | ((vrc7a | vrc7b) & 1)) & 0xf;

将分散的数据聚集在一起方便switch编写.

兔宝宝历险记2 模拟出现的问题

一开始这个东西根本就不能运行, 到处出错. 一步一步反汇编后发现, 其实是IRQ的实现有问题. CLI后不久, 强行触发中断导致程序乱跑.

根本原因还是IRQ实现有问题(废话), APU禁用IRQ后依然触发了已经挂起的IRQ. 目前先将挂起的IRQ清除掉, 以后好好研究一下IRQ.

VRC7 扩展音源

VRC7拥有6个FM合成音源声道, 实现了Yamaha YM2413 OPLL的一个功能子集(阉割版). 似乎叫做'Yamaha DS1001', 下面为了方便描述, VRC7与'Yamaha DS1001'在描述上等价.

前面有一个寄存器Mirroring Control ($E000), 其中Silence位为1的话, 会让VRC7部分静音并清空相关数据状态.

Audio Register Select ($9010)

7......0
VVVVVVVV
++++++++- The 8-bit internal register to select for use with $9030

写入后, 程序不得在6个CPU周期(N制, 实际是12个内部周期)内写入$9030以及$9010, VRC7内部处理需要一点时间.

Audio Register Write ($9030)

7......0
VVVVVVVV
++++++++- The 8-bit value to write to the internal register selected with $9010

写入后, 程序不得在42个CPU周期(N制, 实际是84个内部周期)内写入$9030以及$9010, VRC7内部处理需要一点时间.

42周期可是比三分之一扫描行还多! 不过, 一般地, 作为模拟器不必担心.

内部寄存器

虽然$9010表明几乎有256个寄存器, 似乎内部只有26个:

• $00-$07自定义Patch
• $10-$15, $20-25, $30-35分别控制拥有的6个FM声道
• 至于合成器中Patch的概念, 简单可以理解为音色的一种描述

频率调制

FM是使高频振荡波的频率按调制信号规律变化的一种调制方式. 采用不同调制波频率和调制指数, 就可以方便地合成具有不同频谱分布的波形, 再现某些乐器的音色.

翻开(已经不存在的)大学教材, 回想起被傅里叶老人家支配的痛苦, 不由得感慨万分, 于是合上(已经不存在的)这本教材.

频率调制(Frequency modulation)FM, 现在似乎变成了电台的代名词了. 简单来说, 这里就是通过调制振荡器(Modulator)与载波振荡器(Carrier)进行合成, 即双算子-FM.

在音乐合成时, 双算子-FM可以采用:

F(t) = A sin(ωt + I sin ωt )
             c          m


     Modulator              Carrier
     调制振荡器             载波振荡器
  +-----------------+  +-----------------+
  |                 |  |                 |
  | +-+    +------+ |  | +-+    +------+ |
+-->+X+--->+ Sin  +------+X+--->+  Sin +---> 
  | +++    +--+---+ |  | +++    +---+--+ |
  |  ^        ^     |  |  ^         ^    |
  |  |        | I   |  |  |         | A  |
  |  |        |     |  |  |         |    |
  | -|-    +--+---+ |  | -|-    +---+--+ |
  | P|G    |  EG  | |  | P|G    |  EG  | |
  | -|-    +------+ |  | -|-    +------+ |
  |  |              |  |  |              |
  +--|--------------+  +--|--------------+
     |                    |
     +                    +
     ωm                   ωc

EG: 包络发生器 Envelope Generator
PG: 相位发生器 Phase    Generator

ADSR包络提供一个比较自然的A(t), I(t)函数:

   ON            OFF
    ---------------
---|              |-----------
                   
       /\          
      /  \________ 
     /            \
    /              \

    AAAADDSSSSSSSSRR 

VRC7内部拥有15个预置好的乐器PATCH和1个自定义PATCH, 也就是每8字节一个乐器:

• vibrato, 一般作抖音, 频率的改变(FM), 使能位
• tremolo, 一般作颤音, 音量的改变(AM), 使能位
• attack, 起音, 用于ADSR包络
• decay, 衰减, 用于ADSR包络
• sustain, 延音, 用于ADSR包络
• release, 释音, 用于ADSR包络
• $0$1: sustain, ASDR包络中, S阶段用
• key rate scaling, 调整ADSR包络速度
• multiplier, 倍乘因子(需要查表)
• output level, 调整调制器的基础'音量(衰减值)'
• waveform, 0: 正弦. 1: 半波整流正弦(小于0的被钳制到0)
• $4-$7, ADSR包络用数据. 0:暂停. 1:最慢. F:最快
• key level scaling, feedback 后面用的参数

声道

• $AB中, A就是上面三种情况, B就是声道编号: 0-5共计6声道.
• $3X:I, 就是乐器编号0-F
• $3X:V, 声道音量0-F, 当然实际没有音量的概念
• $2X:S, 为真的话, 会用$5替换掉PATCH中的'R'阶段原本的数据
• $2X:T, 0->1我们可以认为是键盘按下, 1->0则可以认为是键盘弹起. 键盘按下就能弹出一个音符, 按键弹起则进入音符ADSR的'R'阶段. 如果键盘敲不响, 肯定是卡住了: 0->0, 1->1.
• $1X的低8位, 与$2X的最低一位作为高位数据, 合成的9bit(freq). 以及$2X:O3bit的八度数据. 这两个合在一起定义了一个输出频率:

     49716 Hz * freq
F = -----------------
     2^(19 - octave)  

例如, A440, 记作A4, 八度(octave)为4. 这时freq为288.

49716Hz(49715.909Hz)是因为内部需要72周期处理全部声道, 所以可以反推VRC7的内部运行频率大致是3.579552MHz, 大约是N制CPU频率的两倍.

而且这个东西是硬件, 不会说插在P制红白机上就自动降频了(不过由于是VRC7内部驱动, 所以插在P制上也是发出的是同一个频率音符, 不像内部声部). 并且, 由于49716Hz>44100Hz, 所以我们可以认为, 最后输出是由各个声道通过混频得到的.

下面, 如果没有特殊说明, 说到VRC7的时钟周期, 是指49716Hz的周期.

VRC7的场合

'VRC7 Audio'里面并没有详细介绍细节, 不过下面论坛链接就有了.

相位计算:

每个算子拥有一个18bit的计数器用于确定当前相位, 每个时钟周期都会递增:

$00/$01 MMMM  $0  $1  $2  $3  $4  $5  $6  $7  $8  $9  $A  $B  $C  $D  $E  $F
Multiplier    1/2  1   2   3   4   5   6   7   8   9  10  10  12  12  15  15

phase += F * (1<<O) * M * V / 2

• F = $2X:D0 $1X 组成的9bit数据
• O = $2X:D1-D3 3bit的八度信息
• M = $0/$1 经过查表的倍乘因子. 由于第一个是乘以二分之一, 可以考虑LUT预乘2, 最后再除以2
• V = vibrato(FM)输出. 如果vibrato=0, V=1. 后面说明AM/FM的情况

实际使用中会使用'phase_secondary': phase_secondary = phase + adj

• 对于载波器: adj是调制器的输出. 超过18bit的将会舍弃
• 对于调制器, $03的3bit反馈值
• 当F为0: adj=0
• 其他情况, adj = previous_output_of_modulator >> (8 - F)
• 由于这个是代表相位, phase_secondary对于调制器就是利用相位差, 定位指定的相位:

$03         FFF    $0     $1     $2     $3     $4    $5    $6    $7
Modulation Index    0    π/16    π/8    π/4    π/2    π    2π    4π

18bit的'phase_secondary'构造为: [RI IIII III. .... ....]

R和I都是之后需要使用的:

• 其中'I'是(半)正弦表查表用的索引值. 具体使用多少位看具体实现, 最长可以用到17bit...太长了.
• 'R'为1的话, 表示在正弦波的下半部分. 前面提到了, $3的waveform会决定是否钳制负数到0

输出计算:

每个周期每个算子输出一个衰减值:

TOTAL = half_sine_table[I] + base + key_scale + envelope + AM

其中half_sine_table并不是真正的正弦函数表, 而是衰减值:

sin(pi/2) = 1   ~~~>  I='0100 0000'  ~~~>  half_sine_table[ I ] = 0 dB
sin(0) = 0      ~~~>  I='0000 0000'  ~~~>  half_sine_table[ I ] = +inf dB

其中base:

• 调制器: base = (0.75dB * L), L是$02的6bit基础衰减值
• 载波器: base = (3.00dB * V), V是$3X的4bit基础衰减值
• 后面会将浮点映射到整型(就是单位化而已)

其中key_scale是$02$03的2bit值K:

F: 9bit的频率数据
Oct: 八度

IF K==0, THEN
  key_scale = 0
ELSE
  A = table[ F >> 5 ] - 6 * (7-Oct)
  IF A < 0, THEN
    key_scale = 0
  ELSE
    key_scale = A >> (3-K)
  ENDIF
ENDIF

  
table:
   F:     $0     $1     $2     $3     $4     $5     $6     $7     $8     $9     $A     $B     $C     $D     $E     $F
   A:     0.00  18.00  24.00  27.75  30.00  32.25  33.75  35.25  36.00  37.50  38.25  39.00  39.75  40.50  41.25  42.00

后面的包络envelope, AM, 后面说明.

1. 到这里, 每个算子的输出就计算好了. 不过这是一个衰减值, 需要转换成一个初步的线性输出值, 20bit.
2. 根据'R'与'waveform'的值决定是否钳制为0.
3. 还要通过一个滤波器, 不过很简单, 只需要和前一个输出(不是最终值)做平均就行
4. 输出线性值
5. 衰减值与线性值转换公式为:

dB     = -20 * log10( Linear ) * scale      (if Linear = 0, dB = +inf)
Linear = 10 ^ (dB / -20 / scale)

包络发生器

每个算子的包络发生器拥有一个23bit的计数器(记为EGC), 为输出添加衰减值(控制音量). 拥有ADSR阶段, 结束后进入空状态(Idle).

除开Attack阶段, EGC为零时输出0dB, EGC为1<<23时, 输出48dB. 文中建议dB使用(1<<23)/48作为基础单位, 以做出最少的单位转换.

这里列出一些数据之后会用上:

• OF: $2X的低四位, 由八度和频率最高位组成的4bit数据
• K: $0$1的'key rate scaling'
• KO: K ? OF : OF >> 2
• R: 基础速率, 每个阶段不同, $04-$08的数据
• RKS: R*4 + KO
• RH: RKS >> 2, 超过15则被钳制到15
• RL: RKS & 3
• 注: 当R为0, EGC不会增加, 所以不用下面的计算了

Attack阶段:

• R是对应的Attack速率
• EGC += (12 * (RL+4)) << RH
• EGC超过23bit范围, 归零, 进入Decay阶段.
• Attack阶段输出是: AO(EGC) = 48 dB - (48 dB * ln(EGC) / ln(1<<23))

Decay阶段:

• R是对应的Decay速率
• EGC += (RL+4) << (RH-1)
• 当EGC达到对应的Sustain值时, 进入Sustain阶段.
• 具体是EGC >= (3 * Sustain * (1<<23) / 48)

Sustain阶段:

• 如果 $0$1: sustain为0, R是对应的Release速率
• 否则, R=0
• EGC += (RL+4) << (RH-1)
• 如果超过EGC本身范围, 进入Idle阶段

Release阶段:

• $2X:S为1的话, R=5
• 另外, $0$1: sustain为0的话, R是对应的Release速率
• 否则, R=7
• EGC += (RL+4) << (RH-1)
• 如果超过EGC本身范围, 进入Idle阶段

Idle阶段:

• 始终输出48dB

敲键盘

敲下和弹起后会处理一些事. 前面说了, 卡住的不算, 换一个键盘再来.

敲下:

• EGC=0
• 18bit的相位计数器归零
• 进入Attack阶段

弹起：

• 如果当前为Attack阶段, EGC置为Attack输出函数(EGC=AO(EGC))
• 进入Release阶段

AM/FM

前面提到的什么抖音颤音就在这了. 与前面不同的是, AM/FM的状态是全算子共用的(VRC7就一个AM/FM). AM/FM拥有一个20bit的计数器, 每个周期加上rate, 有一个共有的sinx = sin(2 * PI * counter / (1<<20)).

AM:

• rate = 78
• AM_output = (1.0 + sinx) * 0.6 dB (emu2413 使用的是 1.2 dB)

FM:

• rate = 105
• FM_output = 2 ^ (13.75 / 1200 * sinx)
• '^'是指指数运算

也就是说, FM/AM的计算不受用户(这里是指程序猿)的影响, 用户能控制的是决定用不用AM/FM.

可以看出很多地方的计算相当复杂, 具体可以用查表实现. 涉及到精度的查表, 自己会用常量控制, 然后试试什么精度可以接受.

实际编写

实际编写中自然是遇到了大量问题:

• AM冠FM戴. 经常有两个差不多的东西(这里就是AM/FM), 第二个就会直接复制, 但是没有完全修改.
• 建立查找表时, 浮点的inf需要特别处理.
• 最大问题还是:
• op->key_scale = (uint32_t)a >> (3 - key_scale_bits)
• 这句没有问题. 等等, 这句好像等价于:
• op->key_scale = ((uint32_t)a << key_scale_bits) >> 3
• 算了, 还是按照文档写的吧, 删掉:
• op->key_scale = (uint32_t)a << (3 - key_scale_bits)
• 于是右移变成左移了....花了半天才找到
• 建议大家这种情况: 不要修改, 用ctrl+z
• 几乎全是手贱

还一个架构上的问题:

之前提到了, 目前的处理模式是处理上一个状态. 所以外部有一个状态机, 保存了模拟器声部的上一次状态. 但是由于VRC7状态太复杂了, 不方便弄, 所以实现与其他不同:

• 其实只有一点, 就是在修改状态前触发audio_changed事件
• 这样内部本身就保存的上次状态, 就能用了
• 等等...为什么之前不这么弄? 忘了, 可能有bug?

合并输出

• 前面提到了, 由于频率太高, 所以认为是通过混频得到的. 这是一点.
• 是的, 由于59716Hz比目前使用的44100Hz大, 所以涉及到一个'重采样'的步骤.
• 问题: 为什么之前的不需要重采样? 知道的小伙伴可以回复评论!
• 方案1: 简单地可以舍弃掉中间错位的样本
• 方案2: 再稍微好一点的, 上步舍去的样本于下一次做平均
• 方案3: 第三个自然就是, 进行比较系统地重采样.
• 例如先通过一个22kHz的低通滤波, 然后针对每个样本进行权重分配
• 这里简单地平均一下就好了(方案2)
• 最后....
• 怎么和2A03合并呢...这文中没有提到权重
• 输出是一个20bit的数据, 不过可能带符号, 也就是21bit有符号.
• 阉割版只有6个声道, 但是明显地, 应该有8个.
• 也就是24bit有符号! 等等, 这不比CD音质还好?(内部全部使用双精度模拟的话肯定比CD音质好. 卡带上肯定不是, 不过, 还要什么自行车)
• 以1.0为上限, 应该除以(double)(1<<23) (单精度浮点捉襟见肘了), 理论最大值为0.75(6声道)
• 还是建议用户可调整

PATCH表

预置PATCH似乎到目前还没有明确值, 自己使用的自然是wiki提供的:

// 内部PATCH表
const uint8_t sfc_vrc7_internal_patch_set[128] = {
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Custom
    0x03, 0x21, 0x05, 0x06, 0xB8, 0x81, 0x42, 0x27, // Buzzy Bell
    0x13, 0x41, 0x13, 0x0D, 0xD8, 0xD6, 0x23, 0x12, // Guitar
    0x31, 0x11, 0x08, 0x08, 0xFA, 0x9A, 0x22, 0x02, // Wurly
    0x31, 0x61, 0x18, 0x07, 0x78, 0x64, 0x30, 0x27, // Flute
    0x22, 0x21, 0x1E, 0x06, 0xF0, 0x76, 0x08, 0x28, // Clarinet
    0x02, 0x01, 0x06, 0x00, 0xF0, 0xF2, 0x03, 0xF5, // Synth
    0x21, 0x61, 0x1D, 0x07, 0x82, 0x81, 0x16, 0x07, // Trumpet
    0x23, 0x21, 0x1A, 0x17, 0xCF, 0x72, 0x25, 0x17, // Organ
    0x15, 0x11, 0x25, 0x00, 0x4F, 0x71, 0x00, 0x11, // Bells
    0x85, 0x01, 0x12, 0x0F, 0x99, 0xA2, 0x40, 0x02, // Vibes
    0x07, 0xC1, 0x69, 0x07, 0xF3, 0xF5, 0xA7, 0x12, // Vibraphone
    0x71, 0x23, 0x0D, 0x06, 0x67, 0x75, 0x23, 0x16, // Tutti
    0x01, 0x02, 0xD3, 0x05, 0xA3, 0x92, 0xF7, 0x52, // Fretless
    0x61, 0x63, 0x0C, 0x00, 0x94, 0xAF, 0x34, 0x06, // Synth Bass
    0x21, 0x72, 0x0D, 0x00, 0xC1, 0xA0, 0x54, 0x16, // Sweep
};

这有128字节, 之前提到自定义BUS有256字节咩用到, 刚好可以用! 不过由于不在APU区, 储存状态时需要提供接口写入状态(这里是读取, 写入类似):

/// <summary>
/// VRC7: 从流读取至RAM
/// </summary>
/// <param name="famicom">The famicom.</param>
static void sfc_mapper_55_read_ram(sfc_famicom_t* famicom) {
    // 读取VRC7 PATCH表
    famicom->interfaces.sl_read_stream(
        famicom->argument,
        sfc_get_vrc7_patch(famicom),
        sizeof(sfc_vrc7_internal_patch_set)
    );
    // 流中读取至CHR-RAM[拉格朗日点使用了CHR-RAM]
    sfc_mapper_rrfs_defualt(famicom);
}

拉格朗日点 模拟出现的问题

音效: 开头start就出现问题了. 遂搜索论坛, 频率扫描的位移器, 如果为0则不进行扫描.

坑爹呢这是! wiki用0作为例子自己还以为是可以是0的! 这个问题已经在前面的博客修改并注明了(希望不要再出幺蛾子). 之前的代码自然是错的, 不过也不会去改了.

这游戏感觉完全在炫耀机能一般, 第一个BGM就在大量使用FM特性.

• 场景突然消失
• 猜测1: 目前处理'P'精灵有点问题, 会让后来的'P'精灵跑到之前的'P'精灵下面
• 猜测2: 同之前的, 精灵渲染采用了错误的BANK
• 没有去验证, 不过前者可能性较低

REF

• VRC7
• VRC7 Audio
• VRC7 Sound
• 多媒体技术基础及应用
• 调频(FM)音乐合成原理与实现
• 日本游戏音乐发展: Diggin'in the carts -- P2: The Outer reaches of 8-bit

附录: 各个表长的研究

FM

第一个说FM是因为有两个考虑的地方, 深度与宽度, 其中如果采用的是浮点的话, '深度'就无需考虑了. 但是代码就这一个地方使用了浮点也太奇怪了.

    for (int i = 0; i != SFC_VRC7_FM_LUTLEN; ++i) {
        const double sinx = sin(SFC_2PI * i / SFC_VRC7_FM_LUTLEN);
        const double out = pow(2.0, 13.75 / 1200.0 * sinx);
        sfc_vrc7_fmlut[i] = out;
    }

宽度同其他的, 这里谈谈深度. F * (1<<O) * M * V / 2, 转成(F * (1<<O) * M / 2) * V. 其中(F * (1<<O) * M / 2)播放一个音符中, 是一个固定值.

• 最大值: 490560, 19bit
• FM最大系数(约): 1.008
• 要怎么用就能将一个490560 * 1.008用整型模拟?
• 当然可以用: 490560 * 4128 / 4096之类的
• 这里的深度其实就是指分母的精度
• 对于32bit可以使用到8192
• 不过精度还仅仅是可以一用:

/// <summary>
/// StepFC: VRC7 FM计算
/// </summary>
/// <param name="left">The left.</param>
/// <param name="right">The right.</param>
/// <returns></returns>
static inline uint32_t sfc_vrc7_fm_do(uint32_t left, sfc_vrc7_fm_t right) {
#ifdef SFC_FM_FLOAT
    return (uint32_t)((double)left * (double)right);
#else
    return (left * right) >> SFC_VRC7_INT_BITWIDTH;
#endif
}

• 现在舍弃浮点的整数部分, 1.008中间可是很多位浪费了
• 即: a * 1.008 -> a + a*0.008
• 这样就有很多位可以用了(可以用到20), 但是小心负数方向

/// <summary>
/// StepFC: VRC7 FM计算
/// </summary>
/// <param name="left">The left.</param>
/// <param name="right">The right.</param>
/// <returns></returns>
static inline uint32_t sfc_vrc7_fm_do(uint32_t left, sfc_vrc7_fm_t right) {
#ifdef SFC_FM_FLOAT
    return (uint32_t)((double)left * (double)right);
#else
    const int32_t ileft = (int32_t)left;
    const int32_t extra = (ileft * right) / (1 << SFC_VRC7_INT_BITWIDTH);
    return (uint32_t)(ileft + extra);
#endif
}

实际实现中, 由于有除以4的操作, 这样会丢失精度. 所以上面函数uint32_t left, 实际是还没有除以4的uint32_t left_x4

宽度

• FM/AM表宽度不必太大, 控制抖音/颤音的, 256足矣.
• 半正弦表可以适当加大, 比如1024.
• Attack输出表不必太大, 128都行, 自己用的256
• 衰减转线性, 由于对数的原因, 这个表必须足够长不然精度不够
• 评选标准大致是最后几个出现重复值

精度10位时, 最后几个差距有点大.

精度14位时, 精度大致介于1与2之间.

精度16位时, 精度已经有0.5了.

所以选择: 15位, 这基本是最低要求, 可以使用16位

// 可修改
enum {
#if 1
    // VRC7 半正弦表位长
    SFC_VRC7_HALF_SINE_LUT_BIT = 10,
    // VRC7 AM 表位长
    SFC_VRC7_AM_LUT_BIT = 8,
    // VRC7 FM 表位长
    SFC_VRC7_FM_LUT_BIT = 8,
    // VRC7 Attack输出 表位长
    SFC_VRC7_ATKOUT_LUT_BIT = 8,
    // VRC7 衰减转线性查找表位长
    SFC_VRC7_A2L_LUT_BIT = 15,
#else
    // VRC7 半正弦表位长
    SFC_VRC7_HALF_SINE_LUT_BIT = 16,
    // VRC7 AM 表位长
    SFC_VRC7_AM_LUT_BIT = 16,
    // VRC7 FM 表位长
    SFC_VRC7_FM_LUT_BIT = 16,
    // VRC7 Attack输出 表位长
    SFC_VRC7_ATKOUT_LUT_BIT = 16,
    // VRC7 衰减转线性查找表位长
    SFC_VRC7_A2L_LUT_BIT = 16,
#endif
};

STEP8: 基本音频播放

本文github备份地址

上节简单介绍了基本概念, 下面, 介绍相关寄存器

分频器(Divider)

这里特指时钟分频器(或者叫做'分时器'?), 分频器会利用一个值(P)输出时钟, 内部持有一个计数器, 计数器到0就输出然后重置为P值, 比如P为5:

• 2 -> 1
• 1 -> 0
• 0 -> 5 =>输出
• 5 -> 4
• 4 -> 3
• 3 -> 2
• 2 -> 1
• 1 -> 0
• 0 -> 5 =>输出
• 5 -> 4
• 4 -> 3
• 3 -> 2

可以看出这个分频器的周期是P+1.

可以强制让分频器重载P值, 不过就不会输出时钟了. P值修改时不会影响分频器当前的计数.

帧计数器(Frame Counter) / 帧序列器(Frame Sequencer)

地址$4017, 问: 读取的话是用来干什么的?

写入的话就是用控制帧计数器(APU Frame Counter)的, 这个就是用来驱动方波、三角波以及噪声声道的包络、扫描和长度单元.

内部包含一个分频器和序列器.

帧计数器的分频器会以四倍于帧率的频率进行"计数"(NTSC下就是240Hz, 实际上会'稍微略'低于240). 4步模式4步就是刚好一帧, 5步模式5步就是一又四分之一帧了. 之后就根据序列器中的内容进行触发.

写入会使分频器与序列器复位

这个帧计数器的频率和垂直空白不是完全同步的, 是独立运行的, 只能说几乎是4倍. 接下来的内容, 如果没有特殊说明, 则假定在模式0(四步模式)下.

IRQ:

When $4017 sets the IRQ flag, it will keep telling the CPU to cause an IRQ, until the CPU reads from $4015 (or writes $40 or $C0 to $4017) to tell it to stop requesting an IRQ. $4017 doesn't have any other way of knowing that the CPU handled the IRQ; it doesn't know that the CPU has entered the IRQ handler.

文档说是由于电平敏感, 任何时间中断标志被设置并且并且CPU的I标志为0则立即触发IRQ. 这里每次写入$4017就会重置状态, 感觉时机很难把握, IRQ先放一放.

(中精度模拟下)简单实现为一帧内每隔大概65~66扫描行触发一次.

包络发生器(Envelope Generator)

包络(APU Envelope)发生器生成一个固定的音量或者一个锯齿包络(还可以选择是否循环)来控制音量, 内部包括一个时钟分频器和一个计数器.

上面提到了, 分频器的周期是P+1, 即每次获得P+1次时钟信号则输出一次时钟信号.

1. 当接收到帧计数器发出的时钟信号时
   • 之前写入了第四个寄存器?
   • 是: 计数器设为15, 重置分频器
   • 否: 为分频器提供一次时钟信号
2. 当分频器输出了时钟信号时
   • 计数器>0
   • 是: 计数器-1
   • 否且设置了循环: 计数器=15
3. 如果设置了固定音量
   • 是: 直接输出音量为P
   • 否: 输出音量为计数器的数据

例如:

• 如果P=0, 即分频器的周期为1, 能够将音量在4帧内将声音从15降至0, 2帧内将音量从7降至0.
• 如果P=15, 即分频器的周期为16, 能够在16*4, 即一又十五分之一秒内将声音从15降至0.
• 可以看出这个包络可以让声音'渐出'
• 实际上很多游戏的音乐使用的固定音量(如果是完整的ADSR包络, 估计就会用的很多了)

长度计数器(Length Counter)

长度可以理解为时长. 这东西用来自动控制持续的时间, 计数器可以被暂停. 暂停标志位是在D5位(方波、噪声), 或者D7位(三角波), 设置为0表示暂停. 暂停会让计数器...emmm...暂停.

内部计数器到0的话就会静音; 被提供时钟信号时, 计数器会-1, 除非:

• 已经0了
• 暂停中

长度计数器(APU Length Counter)是一个5bit的数据, 也就是说最高能到31, 前面提到120Hz的长度计数器触发频率, 换句话说最多15.5帧...太短了!

所以实际上5bit是一个索引值:

    iiii i---       length index
    
    bits  bit 3
    7-4   0   1
        -------
    0   $0A $FE
    1   $14 $02
    2   $28 $04
    3   $50 $06
    4   $A0 $08
    5   $3C $0A
    6   $0E $0C
    7   $1A $0E
    8   $0C $10
    9   $18 $12
    A   $30 $14
    B   $60 $16
    C   $C0 $18
    D   $48 $1A
    E   $10 $1C
    F   $20 $1E

长度计数器可以看出比较粗糙, 比如这种表都是偶数.

状态寄存器(Status Register)

$4015是APU相关寄存器唯一一个可读的寄存器.

读:

写:

写入0对应的声道就会静音, 同时长度计数器归零. 一定注意要归零, 自己之前忘记归零导致玩马里奥第二关才发现有音效问题, 找了很久才发现是这个原因

方波1/2 寄存器

为了方便, 下面节省$4004-$4007的说明

频率

• 方波声道的频率是CPU时钟的全境掉线, 不, 分频(division)
• 计算方法是 f = CPU / (16 * (t + 1))
• t是$4002-$4003的11位声道周期计时器
• t<8则静音, 即阈值是CPU频率的128分之一
• 1.789773MHz NTSC, 1.662607MHz PAL
• 大概是13kHz, 换句话说, 输出采样频率最好是至少26kHz, 这里就直接用万能的44.1kHz

占空比

• 占空比由$4000的高两位控制
• [0] 0 1 0 0 0 0 0 0 [12.5%]
• [1] 0 1 1 0 0 0 0 0 [25%]
• [2] 0 1 1 1 1 0 0 0 [50%]
• [3] 1 0 0 1 1 1 1 1 [25% 反相]

音量

• 可以是固定音量, 由$4000:D4(C)位确定
• 固定音量下, 具体音量就是$4000:D0-D3(V)
• 不是固定音量, 换句话说就是采用包络进行音量控制, 即$4000:D4(C)位为0
• $4000:D0-D3(V)这时候就是包络的周期
• 如果包络的循环模式$4000:D5(L)没有打开, 则启动长度计数器, 计数器到0则会静音

扫描单元(Sweep Unit)

扫描单元(APU Sweep)位提供了周期性调整方波周期的手段, 包含一个分频器和一个移位器.

EPPP NSSS  使能标志, 分频器周期(需要+1), 负向标志位, 位移数量

同样, 扫描单元的分频器也是P+1, 不同的是一个3bit的了. 还有就是扫描单元是以120Hz的频率触发, 所以扫描的频率是15Hz-120Hz(0.5帧-4帧)

移位器连续地对频率进行扫描:

• 将当前周期(11bit)右移s位, 作为结果值1
• 将当前周期加上(N为1则减去)结果值1, 作为结果值2
• 输出结果值2

方波1和2区别:

• 在N=1时, 方波#1是加上结果的反码, 也就是需要额外-1
• 在N=1时, 方波#2是加上结果的补码, 直接减就行
• 这是BUG还是特性?

例子:

• P = 0, N = 0, S = 0, 即每0.5帧将输出周期加倍, 即输出频率降低到一半, 低八度
• 钢琴**A音高对应频率为440Hz, 低八度A音则为220Hz
• P = 1, N = 1, S = 1, 即每帧将输出周期降至原来的一半, 即输出频率加倍, 高八度
• 高八度A音对应频率为880Hz
• 注意! 上面只是例子, 实际上为S=0的话不进行扫描

静音:

• 可以看出这个可以'加倍', 所以一旦超过11bit的范围($800), 应该被静音
• 同样会减少, 之前提到: 少于8静音.
• 因为是连续扫描的, 所以在不干涉的情况下, 最后总会高于$7FF或者低于8. 这个时候不会对频率更新(比如降到7然后就不会更低了)
• 假设一开始就是7, 然后准备增加, 因为已经低于8了, 实际不会增加.
• 这个测试ROM[sweep_cutoff]有测试, 不过自己并没有实现

方波的周期与频率

之前说到方波频率的计算公式f = CPU / (16 * (t + 1)), 为什么呢?

1. APU的频率是CPU频率的一半, 也就是说2个CPU周期等于1个APU周期
2. 之前说到了方波的占空比, 是一个8个数, 组成的数列
3. 比如[0 1 1 1 1 0 0 0]
   • 第一个APU周期方波输出0
   • 第二: 1
   • ...
   • 第八: 0
4. 这样上限频率是CPU/16
5. 之前说到了11bit的周期, 就像其他周期一样, N表示每N+1触发一次
6. 每N+1次APU周期 -> 推进这8个数列的索引
7. 每个APU周期 -> 输出这8个数列的当前索引表示的数据
8. 这样就输出了方波

具体实现

前面提到了, 目前使用状态机实现, 目前的实现是60Hz(同刷新率). 如果一帧内修改了超过1下, 只会以某一时刻为准, 不过60Hz对于音乐是够用了, 至于音效么, 只能说总比没有的好(比如马里奥跳跃的音效, 目前听起来就有点呆板了). 以后可能会用更好的办法(一旦修改数据就通知渲染层(广义)).

• 我是谁?
• 方波
• 频率?
• 由当前周期通过公式计算, 当前周期可能会通过扫描单元进行修改
• 周期太低(低于8)或者太高(超过11bit)都会导致静音
• 音量?
• 由包络单元输出, 当前音量可能是固定的也可能是通过包络衰减, 甚至还有循环
• 0就是静音 15是最大
• 占空比?
• 就是那4个
• 输出?
• 置空状态寄存器对应的使能位能让声道静音
• 长度计数器归零也会导致静音

三角波 寄存器

线性计数器

之前有一个长度计数器, 用于控制播放的时间, 由于120Hz和都是偶数, 所以精度是在一帧. 三角波增加了一个线性计数器能够更为精确地控制(那么代价是什么?).

$4008包括了一个控制标志位以及一个7位的重载值: crrr rrrr , 当然这个C位也被用于长度计数器.

之前可以看长度计数器是一回合2次(又由于是偶数, 所以...), 线性计数器则是4次:

• 如果之前写入了$400B, 则标记暂停
• 帧计数器提供了信号: 如果标记了暂停
  • 是: 将计数器设置为7bit重载值R
  • 否: 计数器非零则减1
• 帧计数器提供了信号: 如控制标志C为0, 则清除暂停标志

7bit, 240Hz可以看出还是挺细腻的.

频率

同之前的方波, 三角波也有一个数列(32):

F E D C B A 9 8 7 6 5 4 3 2 1 0 0 1 2 3 4 5 6 7 8 9 A B C D E F

所以理论上最高频率是CPU/64? 实际上与方波不同的是, 三角波采用的是CPU的频率, 也就是最高CPU/32. 计算公式: f = CPU/(32*(t + 1))

等等, CPU/32太高了吧? 硬件上的确没有限制, 实现上我们可以让t小于一个阈值让它实现上'静音'(反正听不到), 这个阈值当然就是人耳上限20kHz, 再换算到t...emm... 2?

模拟器可以这么实现, 但是如果是游戏开发就不能这么干, 单独的确是静音(听不到), (实机或者高精度模拟器)混起来就可能产生爆裂声 -- 除非就想这么干(搞事).

具体实现

没有包络控制音量, 没有扫描器控制频率, 对于模拟器实现来说——爽. 同样由于这些问题, 三角波要么循环要么就短时间放一下.

NES的三角波没有音量设定, 但是有一种特殊的调节其音量的方法(DAC法)

• 我是谁?
• 三角波
• 频率?
• 通过周期换算, 如果频率过高可以实现为静音
• 音量?
• 没有直接控制
• 输出?
• 置空状态寄存器对应的使能位能让声道静音
• 长度计数器归零也会导致静音
• 线性计数器归零也会导致静音

噪声 寄存器

$400C   --le nnnn   loop env/disable length, env disable, vol/env period
$400E   s--- pppp   short mode, period index
$400F   llll l---   length index

线性反馈移位寄存器

$400E S--- ---- S: 短模式

噪声声道有一个15bit的LFSR, 每次输出最低的bit位.算法如下:

1. 将D0位与D1做异或运算
2. 如果是短模式则是D0位和D6位做异或运算
3. LFSR右移一位, 并将之前运算结果作为最高位(D14)

如果是长模式(S=0), 这个LFSR的周期是32767(如果初始0则一直为0), 短模式的周期是93(还有可能是31?). 为了避免一直为0, 应该初始化为1.

周期索引

$400E ---- pppp 周期索引值

周期是一个4bit的值, 理所当然是一个索引值:

Rate  $0 $1  $2  $3  $4  $5   $6   $7   $8   $9   $A   $B   $C    $D    $E    $F
      --------------------------------------------------------------------------
NTSC   4, 8, 16, 32, 64, 96, 128, 160, 202, 254, 380, 508, 762, 1016, 2034, 4068
PAL    4, 8, 14, 30, 60, 88, 118, 148, 188, 236, 354, 472, 708,  944, 1890, 3778

制式的差异主要体现在CPU频率上:

• PAL-CPU/NTSC-CPU = 0.929

理论频率计算公式应该是CPU / P, 或者APU / P. 不用加1, 是因为直接给出了周期. 不过因为是噪音, 不是真正的频率, 这个频率只是LFSR的更新频率.

至于是CPU / P还是APU / P, 感觉上有歧义:

APU REF

All channels use a timer which is a divider driven by the ~1.79 MHz clock.

The noise channel and DMC use lookup tables to set the timer's period. For the square and triangle channels, the third and fourth registers form an 11-bit value and the divider's period is set to this value plus one.

• 这篇文档提到全部计时器是以CPU1.79MHz驱动

Timer with
divide-by-two on the output

• 但是方波计时器会除以2

NESDEV APU

• 这个当然是主要参考的

A timer is used in each of the five channels to control the sound frequency. It contains a divider which is clocked by the CPU clock. The triangle channel's timer is clocked on every CPU cycle, but the pulse, noise, and DMC timers are clocked only on every second CPU cycle and thus produce only even periods.

• 这个文档就说只有三角波是特例, 是以CPU周期为单位, 其他都是每两个CPU周期计算一次

然后自己用马里奥反复对比了其他的模拟器, 发现计算公式感觉上应该是CPU/P(没有比较源代码, 毕竟世界上最痛苦的事情, 莫过于看别人写的代码还没有文档), 有一个比较低的$0C音, 区别较大. 这个也需要求证. 不排除自己的实现有问题.

也就是说噪音生成的逻辑:

• 每P次APU(CPU?)周期更新一次LFSR
• 每次采样时: 检测LFSR最低位
  • 0: 输出音量
  • 1: 输出0

包络归来

噪声声道也用到了包络, 方波已经说到了就不再累述

具体实现

EZ模式实现就比较困难了, 因为实际上有一个LFSR状态机. 但是回归本质, 这是一种白噪声的实现手段, 实际上只有$400E中的5bit控制音色, 即实际上只有32种音色, 16种频率乘上2种模式. 反正是噪音(EZ模式嘛, 听个响, 要啥自行车).

再简化, 频率可以通过音频API调整, 也就是说只需要实现两个模式即可. 不过, 即使是白噪声, 短时间播放一段时间还是有差别的, 记录当前播放状态反而实现了一个伪状态机. 换句话说, 也就是每次播放不要从头播放, 从上次的地方继续.

实现:

1. 通过LFSR生成两段(两种模式)音频序列
2. 根据模式切换这个两段序列
3. 根据周期索引切换播放速度(调整频率)
   • 可以看出NTSC和PAL的LFSR修改频率, 理论上应该一致, 可以独立于CPU频率实现(方便但是会丢失精度, 理论一致但是实际上有误差)

...

• 我是谁?
• 噪音
• 频率?
• 没有, 滚
• 音量?
• 由包络单元输出, 当前音量可能是固定的也可能是通过包络衰减, 甚至还有循环
• 0就是静音 15是最大
• 输出?
• 置空状态寄存器对应的使能位能让声道静音
• 长度计数器归零也会导致静音

DMC 声道

DMC可以用来播放ΔPCM, 不过用的游戏很少, 原因当然是对于当时用kb作为单位的游戏来说太奢侈了. 2A03的DMC声道的采样深度是7bit的, 我们现在使用CD音质是16bit的, 差了不是一星半点. 甚至DEMO中自己是图方便, 直接用的32bit浮点.

不论是否被禁止(状态寄存器对应使能位), DMC都会向DAC输出数据, 一开始是0, 或者向$4011写入的7bit数据. 状态寄存器的使能位是用来控制样本播放的.

之前提到了三角波可以通过DAC方法调整音量, 想到了什么?

周期/频率

4bit想想还是索引:

Rate   $0   $1   $2   $3   $4   $5   $6   $7   $8   $9   $A   $B   $C   $D   $E   $F
      ------------------------------------------------------------------------------
NTSC  428, 380, 340, 320, 286, 254, 226, 214, 190, 160, 142, 128, 106,  84,  72,  54
PAL   398, 354, 316, 298, 276, 236, 210, 198, 176, 148, 132, 118,  98,  78,  66,  50

这个就没有歧义了, 两边都说明是以CPU周期为单位的, APU需要除以2. 同之前的制式区别, 当然也可以换算使用独立于CPU的频率(方便但是会丢失精度, 理论一致但是实际上有误差)

可以看出即使用最高频率播放, 也只有33kHz

样本

样本地址是一个8bit的数据, 实际地址是通过转换的:

• 地址: [$4012] * $40 + $C000
• 位操作: %11AAAAAA.AA000000

样本长度是一个8bit的数据, 实际长度是通过转换的:

• 长度: [$4013] * $10 + 1
• 位操作: LLLL.LLLL0001

ΔPCM输出

2A03的ΔPCM大致解码流程:

• 一个字节为一次循环, 从D0到D7
• 如果是1则Δ为+2, 否则Δ就是-2.
• 初始状态为0或者$4011的写入值.
• 是一个7bit的数据, 超过会被钳制.
• 甚至能中途能够修改$4011(搞事).
• 可以看出虽然输出7bit但是Δ是±2, 所以实际上最多能解码出6bit
• 由于声音是由'震动'产生的, 所以初始值理论上无所谓, 这里完全是为7bit范围服务的
• 1bit的ΔPCM相当粗糙, 导致DMC播放效果很差.

三个部分组成: DMA读取器->样本缓存->输出单元

• 样本缓存
  • 8bit样本以及一个'空'状态
  • 由DMA读取器填充
  • 仅能被输出单元清空
• DMA读取器
  • 样本缓存为'空'状态以及还有剩余样本可读则读取下一个样本, 地址+1, 剩余数量-1
  • 地址超过$FFFF则换至$8000
  • 读完了, 不过设置为循环, 则从头再来
  • 读完了, 不过设置为中断, 则标记中断

  Based on the following tests, DMC DMA adds 4 cycles normally, 3 if it lands on a CPU write, 2 if it lands on the $4014 write or during OAM DMA, 1 if on the next-to-next-to-last DMA cycle, 3 if on the last DMA cycle.

  • 访问CPU地址空间会让CPU暂停大约4周期
• 输出单元
  • 内部输出循环开始后:
  • 内部计数器载入8
  • 样本缓存为空, 则标记静音状态
  • 否则清除静音状态, 将样本缓存的数据移动到一个移位器, 并将样本缓存置空
  • 当收到时钟信号:
    1. 静音状态为0? 那么移位器的D0位:
    • 0: 7bit输出减去2
    • 1: 7bit输出加上
    • 7bit输出($4011可以设置, 可以理解为同一个东西)默认是0
    • 钳制在[0, 127]区间内
    • 即: 0-2 -> 0, 127+2 -> 127
    2. 移位器右移一位
    3. 内部计数器递减, 到0后结束本次输出循环

2A03的ΔPCM是1bit的Δ, 0就-2, 1就+2. 每8次(一个字节)一个循环, 8次是一个单位, 不能从中间打断.

解码练习: 有爱好者将ΔPCM数据RIP出来了, 可以用来测试解码器

• PS: 从这里可以看出恶魔城传说/恶魔城3中, 那段仅仅+1s恶魔笑声花了3kb

编码练习: 有兴趣的话可以将一段高品质的音频序列编码至2A03的ΔPCM序列

PCM输出

由于$4011的特点, 2A03可以以PCM方式工作, 这样会消耗大量的空间(ΔPCM x 8), 以及CPU时间. 音质甚至可以达到7bit/44kHz, 不过这个时候你就别想玩游戏了, CPU全部用来输出PCM了.

MMC5甚至带了一个类似的寄存器不过是8bit的了, 是鼓励用PCM吗?

具体实现

解码输出可以算是很简单, 但是对于EZ模式几乎是一个不可能的任务:

• 允许直接写$4011, 可以让ΔPCM以PCM方式工作(搞事啊)
• 读取CPU地址空间会消耗CPU周期, 失去同步

至于7bit的PCM, 很难实现也很容易实现:

• 利用当前设置几乎不可能实现
• 我们增加一个接口, 在PCM模式下(如何判断?), 这个接口就是用来记录当前CPU周期数与$4011的新值
• 让接口可以用来生产自己需要的音频序列, 实现上因为是7bit的, 我们可以简单地重解释(或乘以2)为8bitPCM直接输出, 不用转换成32bit浮点
• 如何判断当前是否是PCM模式?
• 嗯......?

至于ΔPCM, 难点是同步

• 存在多余的4周期(甚至还有其他情况!)
• 想想, 一行才100来个周期
• 在33kHz下, 也就是54周期输出一次
• 也就是一条扫描线输出两次
• 最高频率每4行会读取一次
• EZ模式下, 把这些周期塞在哪里?
• (一帧最多才浪费60+周期, 无视掉?)
• 有些搞事的会利用DMC中断来设置'分割滚动'效果
• 还有的会利用DMC中断实现锯齿波(仅仅需要17字节+中断函数, 很不错的锯齿波)
• 如何同步?
• 嗯......?

综上所述, 模拟DMC声道在状态机模式是比较困难的事情了(如果模拟精度精确到周期, 那就相当方便了, 真正的'仿真'). 我们先放置一下, 暂不实现.

混频器

托音频API的福, 自己没有实现混频器, 但是自带混频器算法如下:

    output = square_out + tnd_out
    
    
                          95.88
    square_out = -----------------------
                        8128
                 ----------------- + 100
                 square1 + square2


                          159.79
    tnd_out = ------------------------------
                          1
              ------------------------ + 100
              triangle   noise    dmc
              -------- + ----- + -----
                8227     12241   22638

当然除了2A03自带这些声道, 日版游戏还有卡带自带的额外声道, 原理上其实就是修改输出到DAC的值.

之前提到三角波可以利用DAC法修改音量, 想要模拟到这个程度必须自己混.

黑匣子

这次黑匣子作为状态机. 这次的文件有4个, 主要是MinGW-w64, 自己在N年前就给这个项目提出缺少XAudio2的头文件, 现在还是没有, 只好DIY以支持GCC(实际是g++)编译器(忘记说了, 项目中有CodeLite项目文件, 没有Visual Studio的可以用这个IDE, 配合GCC/MinGW-w64使用).

int xa2_init();
void xa2_clean();

void xa2_play_square1(float frequency, uint16_t duty, uint16_t volume);
void xa2_play_square2(float frequency, uint16_t duty, uint16_t volume);
void xa2_play_triangle(float frequency);
void xa2_play_noise(uint16_t data, uint16_t volume);

感觉都不用解释. 这次测试ROM同上次的拉罐, 是的这个拉罐ROM实际是带BGM的!

项目地址Github-StepFC-Step8

完整的马里奥

终于可以完整地游玩马里奥了, 就着这个劲儿准备把马里奥通关了!

然后自己加入了非常暴力膜幻的即时存档功能, 通关了.

作业

• 基础: 文中提到了ΔPCM解码练习, 试试吧
• 扩展: 文中提到了ΔPCM编码练习, 试试吧
• 从零开始: 从零开始实现自己的模拟器吧

REF

• APU REF
• APU registers
• FC音源普及篇

NSF 文件头

那么正式进入NSF文件的探索, 首先说的自然是文件头:

offset  # of bytes   Function
----------------------------
$000    5   STRING  'N','E','S','M',$1A (denotes an NES sound format file)
$005    1   BYTE    Version number (currently $01)
$006    1   BYTE    Total songs   (1=1 song, 2=2 songs, etc)
$007    1   BYTE    Starting song (1=1st song, 2=2nd song, etc)
$008    2   WORD    (lo, hi) load address of data ($8000-FFFF)
$00A    2   WORD    (lo, hi) init address of data ($8000-FFFF)
$00C    2   WORD    (lo, hi) play address of data ($8000-FFFF)
$00E    32  STRING  The name of the song, null terminated
$02E    32  STRING  The artist, if known, null terminated
$04E    32  STRING  The copyright holder, null terminated
$06E    2   WORD    (lo, hi) Play speed, in 1/1000000th sec ticks, NTSC (see text)
$070    8   BYTE    Bankswitch init values (see text, and FDS section)
$078    2   WORD    (lo, hi) Play speed, in 1/1000000th sec ticks, PAL (see text)
$07A    1   BYTE    PAL/NTSC bits
                bit 0: if clear, this is an NTSC tune
                bit 0: if set, this is a PAL tune
                bit 1: if set, this is a dual PAL/NTSC tune
                bits 2-7: not used. they *must* be 0
$07B    1   BYTE    Extra Sound Chip Support
                bit 0: if set, this song uses VRC6 audio
                bit 1: if set, this song uses VRC7 audio
                bit 2: if set, this song uses FDS audio
                bit 3: if set, this song uses MMC5 audio
                bit 4: if set, this song uses Namco 163 audio
                bit 5: if set, this song uses Sunsoft 5B audio
                bits 6,7: future expansion: they *must* be 0
$07C    4  ----    4 extra bytes for expansion (must be $00)
$080    nnn ----    The music program/data follows until end of file

转换为c的话就是:

/// <summary>
/// NSF 文件头
/// </summary>
typedef struct {
    // NESM
    char        nesm[4];
    // 1A
    uint8_t     u8_1a;
    // 版本号
    uint8_t     ver;
    // 歌曲数量
    uint8_t     count;
    // 起始数
    uint8_t     start;
    // 加载地址[小端]
    uint16_t    load_addr_le;
    // 初始化地址[小端]
    uint16_t    init_addr_le;
    // 播放地址[小端]
    uint16_t    play_addr_le;
    // 歌曲名称
    char        name[32];
    // 作者名称
    char        artist[32];
    // 版权
    char        copyright[32];
    // 播放速度 NTSC[小端]
    uint16_t    play_speed_ntsc_le;
    // Bankswitch 初始值
    uint8_t     bankswitch_init[8];
    // 播放速度 PAL[小端]
    uint16_t    play_speed__pal_le;
    // PAL/NTSC 位
    uint8_t     pal_ntsc_bits;
    // 扩展音源 位
    uint8_t     extra_sound;
    // 扩展位
    uint8_t     expansion[4];

} sfc_nsf_header_t;

其中有一些uint16_t数据, 文件中是以小端排列的. 大小端的问题就不再累述, 文件载入的话可以简单写为:

sfc_nsf_header_t header;
const size_t count = fread(&header, sizeof(header), 1, file);
// 交换大小端
if (this_is_be()) sfc_nsf_swap_endian(&header);

相关地址

查看文件头后, 有三个比较特殊的地址: 加载, 初始化, 以及播放.

加载地址, PRG-ROM自然是加载在高地址, 也就是$8000开始加载的, 某些ROM可能会从更低的地址加载(不过官方推荐范围是$8000-$FFFF).

一般地, 载入地址为$8000. 特殊地, 为$8000 + N * $1000. 这种情况应该是少于32kb的NSF. 更特殊地, 并不是以4kb对齐的地址.

例子: 如果一个NSF内容是32kb-1大小, 那么, 加载地址就可能是$8001. 为此, 核心部分数据精度再次提高, 之前是以16kb为单位储存的, 现在以字节为单位储存.

初始化地址, 自然是初始化每首曲子用的地址, 播放前需要初始化工作

播放地址, 初始完毕就可以正式播放曲子了.

相关字符串

拥有几个字符串的成员, 编码可以考虑为标准的ASCII或者使用了高位的'Windows-1252'编码.

播放速度

文件头拥有两个控制播放速度的, 分别对应N制式与P制式.

        1000000                  1000000
rate = ---------       period = ---------
        period                    speed

• 60.002 Hz(16666) 推荐NSF频率
• 60.099 Hz(16639) 实际N制式频率
• 50.007 Hz(19997) 猜测的P制式频率

个人认为, 这个项目是在模拟器基础上追加的NSF功能, 所以按照60Hz或者50Hz即可. 除非本体是NSF播放器, 就得严格按照这个频率.

BANK切换

文件头拥有8个字节的数据分别对应了Mapper-031的BANK切换. 不过前提是这8字节非0: 只要有一个非零则表示使用了BANK切换. 应该在每次初始化前切换至默认BANK. 如果没有使用BANK切换, 则从加载地址一路加载至EOF.

值得注意的是, NSF的BANK数量是以4kb为窗口, 而NES的BANK数量是16kb为窗口的. 比如可能NSF文件是24kb大小, 之前的处理, 是针对16kb窗口大小进行的膜运算:

// 0101 .... .... .AAA  --    PPPP PPPP
const uint16_t count = famicom->rom_info.count_prgrom16kb * 4;
const uint16_t src = data;
sfc_load_prgrom_4k(famicom, addr & 0x07, src % count);

所以我们需要针膜的单位是4kb了! 虽然NSF的窗口大小是4kb, 但大小却不是一定以4kb对齐, 前面提到的比如大小是32kb-1时, 这里就需要额外处理:

// 0101 .... .... .AAA  --    PPPP PPPP
const uint16_t count = (famicom->rom_info.size_prgrom + 0x0fff)>>12;
const uint16_t src = data;
sfc_load_prgrom_4k(famicom, addr & 0x07, src%count);

初始化曲子

根据nesdev的介绍, 应该这么初始化曲子:

• 清空$0000-$07FF, $6000-$7FFF. 这两大RAM区
• 初始化APU: $4000-$4013写入$00, $4015先后写入$00, $0F
• 帧计数器(帧序列器)设置为四步模式: $4017写入$40
• 如果使用了BANK切换, 初始化
• 累加器A设为需要播放的曲子的id(从零开始)
• 变址器X表示是否为PAL值(PAL=1, NTSC=0)
• 调用INIT程序

文件头有一个表示NP制式的:

$07A    1   BYTE    PAL/NTSC bits
                bit 0: if clear, this is an NTSC tune
                bit 0: if set, this is a PAL tune
                bit 1: if set, this is a dual PAL/NTSC tune

一般地, 如果是同时支持PAL/NTSC制式的曲子($07A:D1为1)才会使用变址器X传递过来的参数. 所以具体什么频率还是外部控制.

初始化程序必须以RTS结束, 但是不要误解:

INIT:

xxx
xxx
   JSR
   xxx
   xxx
   RTS          <-   合法的RTS
xxx
RTS             <-   真正的RTS结束

播放曲子

初始化完毕, 按照目标频率调用. 一般地, 以RTS结束, 但是不是所有的都是. 所以播放曲子的流程是:

void play_nsf(int id) {
    load();
    init(id);
    while (1) play();
}

这里和前面提到会以RTS结束, 这样就会导致程序很有可能跳转到$0000执行$00BRK. 这自然不是我们想要的, 所以我们有两种做法:

1. RTS指令做手脚, 检查到调用栈栈空了, 则停止全部CPU运转. 可能需要long_jmp()
2. 调用INIT, PLAY程序前先执行我们自己写的一段小程序, 填充调用栈. 这样INIT就返回到自己写的一段代码中了.

如果是写NSF转成WAV之类的程序, 推荐使用1. 这里使用2就行. 不过值得注意的是: PLAY程序不一定调用RTS, 这样调用栈会越来越小, 最后自然是喜闻乐见的'栈溢出'. 应该怎么处理呢?

实际上可以不用处理, 因为只是一个8bit的栈指针, 爆了, 从零开始就行!

自定义程序

之前说到用自定义的程序调用INIT/PLAY防止RTS到未知的地方.可以这么写:

JSR ADDR                ; 调用指定程序

LOOP_POINT:
JMP LOOP_POINT          ; 无限循环

这是一个总共为6字节的程序, 形成一个无限循环, 等待下次调用. 那么问题来了, 这段地址放在哪里?

$0000-$07FF	$0800	2KB internal RAM
$0800-$0FFF	$0800	Mirrors of $0000-$07FF
$1000-$17FF	$0800   Mirrors of $0000-$07FF
$1800-$1FFF	$0800   Mirrors of $0000-$07FF
$2000-$2007	$0008	NES PPU registers
$2008-$3FFF	$1FF8	Mirrors of $2000-2007 (repeats every 8 bytes)
$4000-$4017	$0018	NES APU and I/O registers
$4018-$401F	$0008	APU and I/O functionality that is normally disabled. See CPU Test Mode.
$4020-$FFFF	$BFE0	Cartridge space: PRG ROM, PRG RAM, and mapper registers (See Note)

wiki为我们列出了NSF的情况:

$0000-$01EF
$01F0-$01FF (may be used internally by NSF player)
$0200-$07FF
$4015
$4040-$407F (if FDS is enabled)
$4090 (if FDS is enabled)
$4092 (if FDS is enabled)
$4800 (if Namco 163 is enabled)
$5205-$5206 (if MMC5 is enabled)
$5C00-$5FF5 (if MMC5 is enabled)
$6000-$FFF9

可选的第一个可以是$01F0-$01FF, 但是我们JSR实际就是使用了这部分区域, 还是不用的好.

再一个连续的地址就是大致为$4100, 为了方便, 将$4000-$4200这512字节定义为'自定义总线内存', 计入BANK映射器. 其中$4100开始的256字节是合法写入, 前面256字节仅仅是为了避免意外写入, 实际上可以去掉. 就算不去掉, 程序还是可以将这256字节用作其他地方, 比如保存什么数据文件头什么的:

// 初步BANK
famicom->prg_banks[0] = famicom->main_memory;
famicom->prg_banks[1] = famicom->main_memory;
famicom->prg_banks[4] = famicom->bus_memory;
famicom->prg_banks[6] = famicom->save_memory;
famicom->prg_banks[7] = famicom->save_memory + 4*1024;

所以跳转程序可以这么写:

/// <summary>
/// StepFC: NSF用长跳转
/// </summary>
/// <param name="address">The address.</param>
/// <param name="famicom">The famicom.</param>
void sfc_cpu_long_jmp(uint16_t address, sfc_famicom_t* famicom) {
famicom->registers.program_counter = 0x4100;
const uint32_t loop_point = 0x4103;
// JSR
famicom->bus_memory[0x100] = 0x20;
famicom->bus_memory[0x101] = (uint8_t)(address & 0xff);
famicom->bus_memory[0x102] = (uint8_t)(address >> 8);
// JMP $4103
famicom->bus_memory[0x103] = 0x4c;
famicom->bus_memory[0x104] = (uint8_t)(loop_point & 0xff);
famicom->bus_memory[0x105] = (uint8_t)(loop_point >> 8);
}

帧内处理

之前实现的'ez'模式是处理视频+音频的, 这里只有音频所以可以适当简化, 一般来说, 同步点就是垂直空白触发的NMI. 一般地, 程序会利用垂直同步播放音频保证同步. 而NSF播放'感觉'不用太精确:

播放一帧:
        运行1/4帧
        触发帧计数器

        运行1/4帧
        触发帧计数器

        运行1/4帧
        触发帧计数器

        运行1/8帧
        调用PLAY程序

        运行1/8帧
        触发帧计数器

        处理音频事件

好戏才刚刚开始呢

这样, 基础的NSF就可以播放了, 就直接'嫁接'在Mapper-031即可:

/// <summary>
/// StepFC: MAPPER 031 重置
/// </summary>
/// <param name="famicom">The famicom.</param>
/// <returns></returns>
extern sfc_ecode sfc_mapper_1F_reset(sfc_famicom_t* famicom) {
    const uint32_t size_prgrom = famicom->rom_info.size_prgrom;
    assert(size_prgrom && "bad size");
    // NSF的场合
    if (famicom->rom_info.song_count) {
        uint8_t* const bs_init = famicom->rom_info.bankswitch_init;
        uint64_t bankswi; memcpy(&bankswi, bs_init, sizeof(bankswi));
        // 使用切换
        if (bankswi) {
            assert(famicom->rom_info.load_addr == 0x8000 && "NOT IMPL");
            for (uint16_t i = 0; i != 8; ++i)
                sfc_nsf_switch(famicom, i, bs_init[i]);
        }
        // 直接载入
        else {
            assert(famicom->rom_info.load_addr >= 0x8000 && "NOT IMPL");
            // 起点
            uint16_t i = famicom->rom_info.load_addr >> 12;
            i = i < 8 ? 0 : i - 8;
            // 终点
            uint16_t count = ((size_prgrom + 0xfff) >> 12) + i;
            if (count > 8) count = 8;
            // 处理
            for (uint8_t data = 0; i != count; ++i, ++data)
                sfc_nsf_switch(famicom, i, data);
        }
    }
    // Mapper-031
    else {
        // PRG-ROM
        const int last = famicom->rom_info.size_prgrom >> 12;
        sfc_load_prgrom_4k(famicom, 7, last - 1);
    }
    // CHR-ROM
    for (int i = 0; i != 8; ++i)
        sfc_load_chrrom_1k(famicom, i, i);
    return SFC_ERROR_OK;
}

由于没有图像输出自然就是啥也没有.

.

但是通过wiki, 我们知道NSF自然是可以使用扩展音源的, 这不奇怪. 但是NSF允许混用不同的扩展音源! 例如2A03+VRC6+FDS+MMC5+FME7, 所以, 好戏才刚刚开始呢!

REF

• NSF
• NES Music Format Spec

STEP1: CPU地址空间: 基础读写 + Mapper000

让我们再跨一步吧.

6502汇编使用数字前面美元符号($)作为16进制的表示(8086则是在后面加‘h’)

CPU地址空间布局

先谈谈内存布局, 6502理论支持64KB的寻址空间, 但是小霸王服务器只有2kb的内存. 自然得说说内存布局

M: 主内存2KB镜像, 比如读取$0800实际是读取$0000

R: PPU寄存器, 8字节步进镜像.

Registers: 一堆寄存器, 现在不用管.

Expansion ROM: 扩展ROM, 现在不用管

SRAM, PRG-ROM: 已经说过了

CPU中断

很遗憾, 自己在大学虽然是计算机系的, 但是不是计算机科学之类的学科, 而是靠近多媒体方向(比如计算机图形学, 音频之类的). 这就导致导致计算机硬件知识几乎没有, 只能靠脑补了.

6502有三种中断(按优先度排序, 越后面越优先):

• IRQ/BRK
• NMI
• RESET

每一种中断都有一个向量. 向量是当中断触发时“转到”的指定位置的16位地址:

• $FFFA-FFFB = NMI
• $FFFC-FFFD = RESET
• $FFFE-FFFF = IRQ/BRK

0. IRQ - Interrupt Request 中断请求
   硬件中断请求被执(大致分为Mapper和APU两类)
1. BRK - Break 中断指令
   当软件中断请求被执行(BRK指令)
2. NMI - Non-Maskable Interrupt 不可屏蔽中断
   发生在每次垂直空白(VBlank)时, NMI在NTSC制式下刷新次数为 60次/秒, PAL为50次/秒
3. RESET在(重新)启动时被触发. ROM被读入内存, 6502跳转至指定的RESET向量

也就是说程序一开始执行$FFFC-FFFD指向的地址

'低地址'在'低地址', '高地址'在'高地址'. 即低8位在$FFFC, 高8位在$FFFD.

Mapper000 - NROM

目前当然是实现Mapper000, 实际上也就是没有Mapper的意思:

• 适用于16KB(NROM-128)或者32KB(NROM-256)的PRG-ROM
• CPU $8000-$BFFF: ROM开始的16kb
• CPU $C000-$FFFF: ROM最后的16kb

Mapper接口

就目前而且, 只需要一个重置接口:

/// <summary>
/// StepFC: Mapper接口
/// </summary>
typedef struct {
    // Mapper 重置
    sfc_ecode(*reset)(sfc_famicom_t*);

} sfc_mapper_t;

BANK

BANK是每个Mapper载入的单位, 在某种意义上也可以称为window. 根据内存布局, 可以把根据地址划分为每8KB一个BANK, 一共8个区块:

• 0: [$0000, $2000) 系统主内存
• 1: [$2000, $4000) PPU 寄存器
• 2: [$4000, $6000) pAPU寄存器以及扩展区域
• 3: [$6000, $8000) 存档用SRAM区
• 剩下的全是 程序代码区 PRG-ROM

也就是:

uint8_t* prg_banks[0x10000 >> 13];

Mapper000 - Reset

根据所述内容, Mapper000可以实现为:

/// <summary>
/// 实用函数-StepFC: 载入8k PRG-ROM
/// </summary>
/// <param name="famicom">The famicom.</param>
/// <param name="des">The DES.</param>
/// <param name="src">The source.</param>
static inline void sfc_load_prgrom_8k(
    sfc_famicom_t* famicom, int des, int src) {
    famicom->prg_banks[4 + des] = famicom->rom_info.data_prgrom + 8 * 1024 * src;
}
/// <summary>
/// StepFC: MAPPER 000 - NROM 重置
/// </summary>
/// <param name="famicom">The famicom.</param>
/// <returns></returns>
static sfc_ecode sfc_mapper_00_reset(sfc_famicom_t* famicom) {
    assert(famicom->rom_info.count_prgrom16kb && "bad count");
    assert(famicom->rom_info.count_prgrom16kb <= 2 && "bad count");
    // 16KB -> 载入 $8000-$BFFF, $C000-$FFFF 为镜像
    const int id2 = famicom->rom_info.count_prgrom16kb & 2;
    // 32KB -> 载入 $8000-$FFFF
    sfc_load_prgrom_8k(famicom, 0, 0);
    sfc_load_prgrom_8k(famicom, 1, 1);
    sfc_load_prgrom_8k(famicom, 2, id2 + 0);
    sfc_load_prgrom_8k(famicom, 3, id2 + 1);
    return SFC_ERROR_OK;
}

这里使用到了C99的inline, 和C++的inline略有区别. 还有就是, 利用位操作减少分支判断也是编码技巧之一.

地址空间读写

根据BANK, 就可以非常简单地实现读:

    switch (address >> 13)
    {
    case 0:
        // 高三位为0: [$0000, $2000): 系统主内存, 4次镜像
        return famicom->main_memory[address & (uint16_t)0x07ff];
    case 1:
        // 高三位为1, [$2000, $4000): PPU寄存器, 8字节步进镜像
        assert(!"NOT IMPL");
        return 0;
    case 2:
        // 高三位为2, [$4000, $6000): pAPU寄存器 扩展ROM区
        assert(!"NOT IMPL");
        return 0;
    case 3:
        // 高三位为3, [$6000, $8000): 存档 SRAM区
        return famicom->save_memory[address & (uint16_t)0x1fff];
    case 4: case 5: case 6: case 7:
        // 高一位为1, [$8000, $10000) 程序PRG-ROM区
        return famicom->prg_banks[address >> 13][address & (uint16_t)0x1fff];
    }

和写:

    switch (address >> 13)
    {
    case 0:
        // 高三位为0: [$0000, $2000): 系统主内存, 4次镜像
        famicom->main_memory[address & (uint16_t)0x07ff] = data;
        return;
    case 1:
        // 高三位为1, [$2000, $4000): PPU寄存器, 8字节步进镜像
        assert(!"NOT IMPL");
        return;
    case 2:
        // 高三位为2, [$4000, $6000): pAPU寄存器 扩展ROM区
        assert(!"NOT IMPL");
        return;
    case 3:
        // 高三位为3, [$6000, $8000): 存档 SRAM区
        famicom->save_memory[address & (uint16_t)0x1fff] = data;
        return;
    case 4: case 5: case 6: case 7:
        // 高一位为1, [$8000, $10000) 程序PRG-ROM区
        assert(!"WARNING: PRG-ROM");
        famicom->prg_banks[address >> 13][address & (uint16_t)0x1fff] = data;
        return;
    }

还没实现的用断言即可. 写入也是同样的. 不过既然是PRG-ROM, 那么写入加个断言好了.

输出各个中断向量

可以看出RESET是跳转$C004.

项目地址Github-StepFC-Step1

作业

• 基础: RESET跳转地址的那一个字节是啥? 即执行的第一个指令的操作码是?
• 从零开始: 从零开始实现自己的模拟器吧

REF

• CPU memory map
• Mapper000 - NROM
• 任天堂红白机 ( NES ) 文档

滤镜与滤波器

这一步就来讲讲滤镜与滤波器, 都可以叫做filter, 总的来说可以提升用户体验.

滤镜

滤镜有很多种, 比如模拟CRT显示器, 但是这里不是说的这么一类. 由于原生分辨率只有256x240, 对于现在来说太小了, 我们可以把它放大一点, 使用的算法称为缩放算法(scaling algorithms), 处理后效果就简单地称为滤镜了.

这里采用被维基标注为public domain测试用卡片:

Filter

例如D3D11_FILTER有这么一个枚举D3D11_FILTER_MIN_MAG_POINT_MIP_LINEAR, 其中POINT和LINEAR就是代表了两种最基础的过滤方式: 点过滤和线性过滤.

一般缩放算法会采用插值, 这两个过滤方式对应的就是最邻插值和线性插值了.

最邻插值

也是之前采用的插值算法, 下面是放大3倍后效果

效果中规中矩, 也没有什么特别之处, 优点就是实现简单, 图像API本身就会提供

线性插值

这个方法实现也比较简单, 但是放大三倍后

就糊了.

当然, 还有很多插值方法. 比如D2D就还提供了什么各向异性过滤等高质量的插值算法, 我们所谓的"像素风格"图像是不适合用常规插值算法的, 因为这些算法是针对平滑像素.

像素风格缩放算法

维基列了相当多的算法, 这里就挑选几个看看.

通过粗略查看, 我们可以知道很多都是将原生数据放大至整数倍, 由于我们显示的话可能会显示成任意分辨率, 所以逻辑是:

原生->像素风格缩放算法->插值到任意分辨率

中间有两次缩放, 我们可以为用户提供选项, 最后一步可以考虑用线性插值或者最邻插值, 当然也是可以选的

后面还有4倍的一些算法, 4x4就是16倍, 用CPU处理自然略慢, 就用着色器处理吧, 这里就用比较熟悉的HLSL实现.

Scale2x

www.scale2x.it

看名字就知道这个算法是将分辨率提高至2倍

 A          提高至两倍      
CPB          P:12
 D             34
                
            1=P; 2=P; 3=P; 4=P;
            IF C==A AND C!=D AND A!=B => 1=A
            IF A==B AND A!=C AND B!=D => 2=B
            IF D==C AND D!=B AND C!=A => 3=C
            IF B==D AND B!=A AND D!=C => 4=D

可以看出这个算法并没有生成新的颜色, 例如P生成的左上角点, 可以认为是夹在AC**, 看情况变成AC.

效果:

(进行scale2x后再进行了4倍最邻插值)

(与8倍最邻插值比较, 可以看到4个角落并没有处理)

可以看出对于转角处有所处理, 稍微平滑了一点, 由于没有增加新的颜色, 所以处理后还是像素风满满, 不认真观察的话, 就会以为本身就是这样. 效果最差的应该是左下角的, 像坐标轴的那个, 也被强制平滑了.

像素着色器的实现

float4 scale2x(uint2 pos) {
    const uint2 real_pos = pos / 2;
    const float4 a = InputTexture[real_pos - uint2(0, 1)];
    const float4 b = InputTexture[real_pos + uint2(1, 0)];
    const float4 c = InputTexture[real_pos - uint2(1, 0)];
    const float4 d = InputTexture[real_pos + uint2(0, 1)];
    const float4 p = InputTexture[real_pos];

    float4 color;
    switch ((pos.x & 1) | ((pos.y & 1) << 1))
    {
    case 0:
        // IF C==A AND C!=D AND A!=B => 1=A
        color = (c == a && c != d && a != b) ? a : p;
        break;
    case 1:
        // IF A==B AND A!=C AND B!=D => 2=B
        color = (a == b && a != c && b != d) ? b : p;
        break;
    case 2:
        // IF D==C AND D!=B AND C!=A => 3=C
        color = (d == c && d != b && c != a) ? c : p;
        break;
    case 3:
        // IF B==D AND B!=A AND D!=C => 4=D
        color = (b == d && b != a && d != c) ? d : p ;
        break;
    }
    return color;
}

着色器, 特别是像素着色器应该尽可能地去掉分支, 这个实现包含了大量的分支. 可以考虑使用DX11带来的计算着色器(D2D也能用), 以减少部分分支. (然后传入索引减少75%CPU-GPU传输时间, 随便还能优化分支判断.) 后面的先不说, 计算着色器可以一次输出多次像素, 实现为:

void scale2x(uint2 pos) {
    const uint2 pos0 = pos.xy * 2;
    const uint2 pos1 = pos0 + uint2(1, 0);
    const uint2 pos2 = pos0 + uint2(0, 1);
    const uint2 pos3 = pos0 + uint2(1, 1);

    // ABC
    // DEF
    // GHI

    const float4 E = InputTexture[pos];
    const float4 B = InputTexture[pos - uint2(0, 1)];
    const float4 D = InputTexture[pos - uint2(1, 0)];
    const float4 F = InputTexture[pos + uint2(1, 0)];
    const float4 H = InputTexture[pos + uint2(0, 1)];

    const float4 CC = float4(1, 1, 1, 1) - (B - H) * (D - F);
    

    float4 E0, E1, E2, E3;
    if (CC.x + CC.y + CC.z != 3.0) {
        E0 = D == B ? D : E;
        E1 = B == F ? F : E;
        E2 = D == H ? D : E;
        E3 = H == F ? F : E;
    }
    else {
        E0 = E;
        E1 = E;
        E2 = E;
        E3 = E;
    }

    OutputTexture[pos0] = E0;
    OutputTexture[pos1] = E1;
    OutputTexture[pos2] = E2;
    OutputTexture[pos3] = E3;
}

线程量用的是SM5.0支持的[32, 32, 1], 这次总体效率提升大致在, emmmm, -50%左右. 是的, 效率降低了, 也不知道是不是D2D自带框架有问题. 当然测试发现, CS更适合重计算(128x64比较小), 不然大头花在其他地方了.

When is a compute shader more efficient than a pixel shader for image filtering?

Scale3x

这就是Scale2x的三倍版本, 也有Scale4x不过其实就是连续两次Scale2x.

ABC           E0 E1 E2
DEF       E:  E3 E4 E5
GHI           E6 E7 E8

E0 = D == B && B != F && D != H ? D : E;
E1 = (D == B && B != F && D != H && E != C) || (B == F && B != D && F != H && E != A) ? B : E;
E2 = B == F && B != D && F != H ? F : E;
E3 = (D == B && B != F && D != H && E != G) || (D == H && D != B && H != F && E != A) ? D : E;
E4 = E
E5 = (B == F && B != D && F != H && E != I) || (H == F && D != H && B != F && E != C) ? F : E;
E6 = D == H && D != B && H != F ? D : E;
E7 = (D == H && D != B && H != F && E != I) || (H == F && D != H && B != F && E != G) ? H : E;
E8 = H == F && D != H && B != F ? F : E;

同样, 直接"拿来"未做针对着色器的优化. 效果如下...同样还是像素着色器效率更好, 不过差距小了一点, 256x240的话, 效率就差不多了.

(scale3x后2倍最邻插值)

(与6倍最邻插值比较)

可也看出"圆"处理得比2x好, 其他的很一般了. 特别是中间的那个分割线, 还以为自己实现有问题, 找了很久, 然后用作者自己写的程序跑了一下还是一样的, 2X也有这种情况但是不明显, 估计放大倍数越大越明显.

ScaleNx

可以看出ScaleNx优点是: 容易实现, 不会引入新的颜色. 不会引入新的颜色这一点算是有得有失吧, 处理后还是像素风. 比如有一个很不错的算法只能放大到4倍, 现在要放大至8倍, 可以先用Scale2x处理再用那个算法.

还有有人(Sp00kyFox)根据ScaleNx改进(效果上)算法, 称为ScaleNxSFX, 增加了对于旁边点的判断范围, 以及基于Scale3x深度改进(It was originally intended as an improvement upon Scale3x but became a new filter in its own right)而形成的, 还有ScaleFX-rAA和ScaleFX-Hybrid两个额外处理. 这个算法比较新, 到最近(本文初稿于2018-09-24)作者似乎还在更新, 所以效果应该不错, 没准还有新的算法会在这个主题出现.

以及guest(r)基于Scale2x派生的Scale2xPlus, 这家伙在07年派生出这个算法, 但是居然也出现在了那个主题讨论中.

REF

• Pixel Scalers
• Pixel-art scaling algorithms

STEP8: 基本音频播放

目前为止, Mapper 0的游戏应该能够顺利玩了, 就差声音了. 所以接下来就是对于音频的模拟, 算是换一个口味轻松轻松(实际并不轻松)吧. 个人还是挺喜欢8Bit风格的音乐的!

本步骤中, 如果没有特殊说明则表示是NTSC制式

这里使用音频API是XAudio2.7, 需要DX的运行时. XAudio2.8是Win8自带的, 不过考虑到Win7还是使用2.7. 不过这样导致Win8以及后面的系统, 也需要下载DX的运行时库. 并且由于2.8接口上部分不兼容2.7, 但是还是用一个接口名, 这就很难受了, 只能说微软S那啥.

播放音频

同样因为可能读者拥有自己了解的音频API, 这里不对音频API做过多解释, 不过一般来说音频API就是读取样本缓存然后播放, 不考虑特效的话, 还是很简单的.

这一节简单介绍一下各个部分的特性.

APU

FC的CPU叫做2A03, 之前介绍了比起6502缺了点啥, 现在就是说多了点啥: pAPU - pseudo Audio Processing Unit

之所以有一个前缀p是因为没有专门处理音频的物理芯片 -- 这句话其实有歧义. 其实CPU和pAPU是一个芯片, 可以认为 pAPU + 6502 = 2A03

默认情况下, pAPU支持5个声道:

1. 两个方波声道
2. 一个三角波声道
3. 一个利用线性反馈移位寄存器的噪声声道
4. 一个用来播放DPCM的增量调制声道

还有就是Mapper额外搭载的, 这里不谈. 至于

• PCM(脉冲编码调制)
• APCM(自适应脉冲编码调制)
• DPCM(差分脉冲编码调制)
• ADPCM(自适应差分脉冲编码调制)

可以自行了解之间的区别, 不过这里为了方便, 样本格式采用IEEE单精度浮点表示.

方波

***   ***   ***   ***   ***   ***

---------------------------------

   ***   ***   ***   ***   ***

振幅浮点表示就是1.0和-1.0, 然后交错起来(也可以是0.0和1.0, 更为方便).

占空比

感觉和矩形/方形的有点联系, 50%才叫真正的"方波", 2A03中方波拥有4种占空比(Duty Cycle):

0. 0 1 0 0 0 0 0 0 [12.5%]
1. 0 1 1 0 0 0 0 0 [25%]
2. 0 1 1 1 1 0 0 0 [50%]
3. 1 0 0 1 1 1 1 1 [25% 反相]

反相的话, 单独听是听不出与不反相有啥区别的. 不过通过混音就可能会有点区别

音量

方波是有音量控制的, 最大15.

三角波澜T-Wave

*       *       *       *
 *     * *     * *     * *
--*---*---*---*---*---*---*---
   * *     * *     * *     * 
    *       *       *       *

振幅线性地在1.0和-1.0之间来回振荡(也可以是0.0和1.0, 更为方便)

三角波没有音量控制, 取而代之的是更为细腻的长度(时长)播放控制.

噪声

其实直接播放上面的就是噪声了(笑). 噪声声道通过一个伪随机的位发生器发出噪声. 由于是1bit随机以及最大音量15, 生成和方波类似, 只不过是从预设到随机了.

线性反馈移位寄存器(LFSR)

噪声声道有一个15bit的LFSR, 每次输出最低的bit位.算法如下:

1. 将D0位与D1做异或运算
2. 如果是短模式则是D0位和D6位做异或运算
3. LFSR右移一位, 并将之前运算结果作为最高位(D14)

DMC

用于DPCM生成, 2A03的ΔPCM大致解码流程:

• 一个字节为一次循环, 从D0到D7
• 如果是1则Δ为+2, 否则Δ就是-2.
• 是一个7bit的数据, 超过会被钳制.

PCM

由于DMC相关寄存器特性, DMC声道也能播放7bit的PCM数据. 不过, 如果说播放DPCM是硬件解码的话, 播放PCM就是软件解码了. 播放完全由CPU控制, 会消耗大量CPU资源.

状态机实现

模拟器对于音频的实现主流的方案是利用目前数据生成样本数据再传给音频API, 同时为了避免出现'饥饿'(starvation, 声部匮乏, 出现'卡音'现象)会缓存几帧的音频再播放. 不过这里嘛...

最初的音频实现, 我们实现简单点: 状态机. 将各个部分实现为状态的切换. 比如:

• 方波#1, 频率500Hz, 音量12, 占空比50%

这样会一直地播放这个方波, 直到方波#1的状态被改变. 音量为0的话记为停止播放:

• 方波#1, 频率500Hz, 音量0, 占空比50%

.

三角波有点特殊, 没有音量, 所以就频率0Hz定为静音(或者20Hz~20kHz有效). 还有一点由于三角波的特殊性, 我们需要完整地播完一个'三角波', 避免出现"爆音"(状态机特有)

细节部分就在下节介绍.

REF

• APU
• APU REF

StepB: 规范存储

自己在前面即时存档中, 非常暴力地几乎把所有东西都存进去了, 这一节自然得规范一下!

SRAM

有一些ROM使用SRAM进行存档, 这是非常基本的存档方式, 首先自然是实现这个, 不过你得找一个支持SRAM的游戏(好在MM就是)!

保存

这个也没什么可说了, 如果检测到ROM会使用SRAM, 那么在程序退出或者说切换游戏ROM时, 进行保存. 我们可以针对ROM计算出HASH值, 比如CRC32(自己使用的crc32b, 是搜索到第一个public domain代码). 然后保存文件名就是CRC32值即可.

当然, 只需要计算PRG-ROM的CRC32即可, 不然稍微修改文件头就不一样了.

读取

然后在游戏加载时读取即可. 查找之前对应的文件即可.

数据布局

很简单的文件头+具体数据即可

16字节文件头
                -StepFC-
                SRAMWRAM
8KB实际数据
                01010101
                ........

文件头基本就是用来检测是不是合法的文件而已, 甚至可以连文件头都不需要.

接口

当然, 核心不处理文件读写, 全靠接口:

// 保存SRAM
void(*save_sram)(void*, const sfc_rom_info_t*, const uint8_t*);
// 读取SRAM
void(*load_sram)(void*, const sfc_rom_info_t*, uint8_t*);

很简单就实现了!

即时存档/读档

这就是主要内容了, 之前是将所有内容一股脑地存进去了, 现在就得规范一下, 这个东西越后面完成越简单, 因为核心部分不会再修改了.

换句话说, 很有可能随着模拟器的编写, 这部分可能会发生翻天覆地的变化.

同样核心部分不处理文件读写, 但是又实在需要写入流, 自然就交给接口完成啦!

// 状态保存 写入流
void(*sl_write_stream)(void*, const uint8_t*, uint32_t len);
// 状态读取 读取流
void(*sl_read_stream)(void*, uint8_t*, uint32_t len);

当然是流数据即可, 可以用类似std::vector<uint8_t>保存(甚至可以通过网络数据流!), 不用非得是文件流. 这就是接口的好处.

逻辑是:

• 外部代码准备数据
• 调用sfc_famicom_save/load_state
• 外部代码对于数据的处理

// 保存状态
void sfc_famicom_save_state(sfc_famicom_t*);
// 读取状态
sfc_ecode sfc_famicom_load_state(sfc_famicom_t*);

需要存什么?

那么到底需要存什么东西? 简单地说就是"状态", 现在很多状态可以直接保存结构体数据就行, 但是, 但是很有可能修改数据布局, 导致这个版本的读取不了上一个版本的.

我们又不可能预知未来, 修改是必然的, 所以可以考虑使用版本号区分, 正式释出的时候可以兼容上一个(文件)版本的文件就非常完美了. 最完美的是兼容所有历史(文件)版本, 这个包袱有点重可以不实现.

大小端

又到异端审判的时间到了:

• (吃鸡蛋)是大端派还是小端派?
• 答曰: 混合序(middle-endian).
• 烧了

大小端问题在文件储存上问题比较突出, 以什么字节序保存也是一个令人头疼的问题, x86采用的小端模式自己感觉还算科学, 比如char16_t如果是保存的是ascii码的话, char16_t*强转char*就行, 步进变成2而已. 什么C++模板走开点, 重解释才是王道! 无奈网络传输一般用大端传输(大概是数字文字表示是左边更大)

这里就直接采用不考虑大小端的情况, 直接保存, 以后再考虑大小端.

RAM

RAM自然是保存的重点对象, 下面列出需要保存的RAM数据:

• CPU主RAM, 2KB的那个
• CPU的SRAM/WRAM, 8KB的那个
• PPU的VRAM, 2KB的
• PPU的EX-VRAM, 如果是4屏幕模式的话, 卡带上自带了2KB的VRAM
• PRG-RAM CHR-RAM

关于SRAM的说明, ROM会有SRAM的标志位(电池供电), 但是没有WRAM的标志位(FC供电). 比如超级马里奥3使用了WRAM, 但是ROM里面是没有SRAM标记的.

当然, WRAM可能不止8KB, 内部甚至允许切换, 所以SRAM/WRAM分开处理比较好.

再比如, 之前Mapper1是支持切换WRAM的, 不过因为是变种就没有实现, 这是以后的事情.

不过嘛, 无脑保存就行, 反正不缺8KB的磁盘空间, 甚至可以压缩.

PRG-RAM CHR-RAM

目前完成的4个Mapper寄存器都是基于对高位地址写入完成的, 也就是说这些Mapper在高地址是没有PRG-RAM的, 最多是WRAM视为PRG-RAM. 但是以后, 可能有(其实Mapper005-MMC5就支持)高地址的PRG-RAM. 准备好接口就行.

CHR-RAM这个就太常见了, 甚至Mapper0都有CHR-RAM的情况.

所以, PRG-RAM以及CHR-RAM应该是Mapper来处理的, 应该提供相应接口给Mapper:

// 写入RAM到流
void(*write_ram_to_stream)(sfc_famicom_t*);
// 从流读取RAM
void(*read_ream_from_stream)(sfc_famicom_t*);

例如大部分Mapper其实没有特殊的CHR-RAM处理, 可以公用一个接口, 例如写就可以这么干:

    // PRG-RAM 不考虑

    // 没有CHR-ROM则表明全是CHR-RAM
    if (!famicom->rom_info.count_chrrom_8kb) {
        famicom->interfaces.sl_write_stream(
            famicom->argument,
            famicom->rom_info.data_chrrom,
            8 * 1024
        );
    }

读也是类似的.

再例如Mapper 074, 国产膜改版的MMC3. CHR BANK的$08, $09号是CHR-RAM. Mapper读写只需要保存这部分即可.

文件头

大致布局, 当然最好是保证每块内容16字节对齐.:

判断用文件头
基础用文件头
RAM区
文件尾基础信息
文件尾详细信息

详细内容布局:

// 判断用文件头 16字节. 汉字是用UTF-16小端编码
                "-StepFC-SL大法好"


// 基础数据文件头 用于保存小几率修改的数据, 目前布局如下:

/// <summary>
/// 状态基本数据用文件头
/// </summary>
typedef struct {
    // 大小端检查用, 可以检测该位转换到其他平台
    uint32_t        endian_01020304;
    // 本结构体大小
    uint32_t        size_of_this;
    // 主 版本号
    uint8_t         major_version;
    // 副 版本号
    uint8_t         minor_version;
    // RAM 用掩码
    uint8_t         ram_mask;
    // 未使用
    uint8_t         unused;
    // 当前帧ID
    uint32_t        frame_counter;
    // CPU 周期数 低4字节
    uint32_t        cpu_cycle_lo;
    // CPU 周期数 高4字节
    uint32_t        cpu_cycle_hi;
    // APU 周期数 低4字节
    uint32_t        apu_cycle_lo;
    // APU 周期数 高4字节
    uint32_t        apu_cycle_hi;
    // PPU 周期数 低4字节
    uint32_t        ppu_cycle_lo;
    // PPU 周期数 高4字节
    uint32_t        ppu_cycle_hi;
    // 16字节对齐/ 保留用
    uint8_t         reserved1[8];
    // CPU BANK 高位偏移
    uint32_t        cpu_hi_banks_offset[4];
    // PPU BANK 低位偏移
    uint32_t        ppu_lo_banks_offset[8];
    // PPU BANK 高位偏移
    uint32_t        ppu_hi_banks_offset[8];

} sfc_state_header_basic_t;

// RAM MASK位如下
enum SFC_RAM_MASK {
    // 主RAM
    SL_CPU_MAIN_RAM_2KB = 1 << 0,
    // SRAM
    SL_CPU_SRAM_8KB = 1 << 1,
    // 主VRAM
    SL_PPU_VRAM_2KB = 1 << 2,
    // 额外VRAM
    SL_PPU_EXVRAM_2KB = 1 << 3,
};
// 从低到高表示随后的数据块
//                 D0为1时:    Main-RAM 2KB 
//                 D1为1时:    SRAM 8KB
//                 D2为1时:    VRAM 2KB
//                 D3为1时:    EX-VRAM 2KB

// 这4个RAM块结束后是Mapper的RAM块
//                 Mapper RAM块 大小布局由Mapper确定


// 最后是文件尾, 保存一些大概率修改的数据

// 文件尾段大小, 保存数据的大小, 版本不匹配时利用这个可以尝试强制读取.

/// <summary>
/// 文件尾 用于存放易变数据
/// </summary>
typedef struct {
    // CPU 数据段大小
    uint32_t        cpu_seg_len;
    // PPU 数据段大小
    uint32_t        ppu_seg_len;
    // APU 数据段大小
    uint32_t        apu_seg_len;
    // Mapper 数据段大小
    uint32_t        mapper_seg_len;
    // 输入设备 数据段大小
    uint32_t        input_seg_len;
    // 保留16字节对齐
    uint32_t        reserved1[3];

} sfc_state_tail_len_t;


// 文件尾 数据区, 这部分就是例如寄存器状态什么的, 布局容易修改的


/// <summary>
/// 文件尾 用于存放易变数据
/// </summary>
typedef struct {
    // CPU 寄存器
    sfc_cpu_register_t          cpu_data;
    // PPU 数据
    sfc_ppu_data_t              ppu_data;
    // APU 数据
    sfc_apu_register_t          apu_data;
    // Mapper 数据
    sfc_mapper_buffer_t         mapper_data;
    // 输入设备数据
    sfc_sl_input_data_t         input_data;

} sfc_state_tail_data_t;

存档就填写, 读档就读取, 将布局规划一下就简单了.

目前没有处理特殊WRAM的情况(交给Mapper后期完善), 不过测试了几个ROM都没问题, 说明这个情况比较罕见.

魂斗罗没有CHR-ROM, 需要保存8KB的CHR-RAM. 不过, 魂斗罗的鼓声实在是一大亮点!

项目地址Github-StepFC-StepB

作业

• 基础: 定义自己的文件格式和布局!
• 从零开始: 从零开始自己的模拟器吧!

REF

• MMC5
• MMC6
• Mapper 074

FC磁碟机

项目地址

Family Computer Disk System(FDS)是一种基于FC的磁碟机系统, 其中部分探讨会在下一步《全部成为F》简述.

这里仅仅是完成扩展音源部分, 自己并没有完全模拟FDS的计划. 毕竟从未见过, 甚至都是接触过模拟器后才发现才有这玩意. 没有感情, 对, 我是一台没有感情的程序猿.

可以看出FDS与其他不同的地方是: 别的扩展音源是卡带上的硬件, FDS音源是磁碟机上的. 所以FDS的游戏自然是: 不用白不用, 很多FDS的游戏都用上了.

FDS

iNES为FDS分配的Mapper编号是20, 不过仅仅作为保留用, 让模拟器知道自己在模拟FDS而已.

FDS扩展音源只有一个声道. 简单地说, 就是将一个长度64的自定义波形信息, 安装预定的方式进行调制. 所以别说模拟乐器了, 完全可以用来模拟人声. 就是精度差点(6bit).

Master I/O enable ($4023)

7  bit  0
---------
xxxx xxSD
       ||
       |+- Enable disk I/O registers
       +-- Enable sound I/O registers

D1位写入1才能让音频相关寄存器启动(懒得去实现).

Wavetable RAM ($4040-$407F)

7  bit  0  (read/write)
---- ----
OOSS SSSS
|||| ||||
||++-++++- Sample
++-------- Returns 01 on read, likely from open bus

这里保存了64步长的波形数据, 这部分可读, 不过声音播放中不可写. 读取时高两位是01, 所以实现上可以写入01SS SSSS.

Volume envelope ($4080)

7  bit  0  (write; read through $4090)
---- ----
MDVV VVVV
|||| ||||
||++-++++- (M=0) Volume envelope speed
||         (M=1) Volume gain and envelope speed.
|+-------- Volume change direction (0: decrease; 1: increase)
+--------- Volume envelope mode (0: on; 1: off)

• M=0: 音量包络速度
• M=1: 音量增益和包络速度

超过32是有效的, 但是输出前会被钳制到32(根据全文, 超过32的数据仅仅可能用于数据读取).

Frequency low ($4082)

7  bit  0  (write)
---- ----
FFFF FFFF
|||| ||||
++++-++++- Bits 0-7 of frequency

Frequency high ($4083)

7  bit  0  (write)
---- ----
MExx FFFF
||   ||||
||   ++++- Bits 8-11 of frequency
|+-------- Disable volume and sweep envelopes (but not modulation)
+--------- Halt waveform and reset phase to 0, disable envelopes

暂停波形的话, 会一直输出$4040的值, 也就是可以认为: 重置相位, 然后播发周期无穷大-频率为0Hz.

D6位仅仅会暂停包络而不是波形, 不过会重置这两个的计时器.

Mod envelope ($4084)

调制器(modulator), 或者调制(modulation)

7  bit  0  (write; read through $4092)
---- ----
MDSS SSSS
|||| ||||
||++-++++- (M=0) Mod envelope speed
||         (M=1) Mod gain and envelope speed.
|+-------- Mod envelope direction (0: decrease; 1: increase)
+--------- Mod envelope mode (0: on; 1: off)

• M=0: 调制包络速度
• M=1: 调制增益和包络速度

Mod counter ($4085)

7  bit  0  (write)
---- ----
xBBB BBBB
 ||| ||||
 +++-++++- Mod counter (7-bit signed; minimum $40; maximum $3F)

这是一个7bit有符号的数据,

Mod frequency low ($4086)

7  bit  0  (write)
---- ----
FFFF FFFF
|||| ||||
++++-++++- Bits 0-7 of modulation unit frequency

Mod frequency high ($4087)

7  bit  0  (write)
---- ----
Dxxx FFFF
|    ||||
|    ++++- Bits 8-11 of modulation frequency
+--------- Disable modulation

最高的禁用位能够禁用调制, 同样如果12bit的频率为0也能禁用调制.

通过禁用位暂停调制后才能够写入调制表($4088)

Mod table write ($4088)

7  bit  0  (write)
---- ----
xxxx xMMM
      |||
      +++- Modulation input

必须通过禁用$4087的相关禁用位才能正常写入, 否则无效.

调制表是一个64长的环形缓冲区, 每次会写入表中相邻的两位, 也就是说连续写入32次就能完整地写入一次(当然每次写入会推进位置).

Wave write / master volume ($4089)

7  bit  0  (write)
---- ----
Wxxx xxVV
|      ||
|      ++- Master volume (0: full; 1: 2/3; 2: 2/4; 3: 2/5)
|          Output volume = current volume (see $4080 above) * master volume
+--------- Wavetable write enable
           (0: write protect RAM; 1: write enable RAM and hold channel)

1, 3, 4, 5最小公倍数为 30.

D7为1时, 波形会保持当前的输出, 直到D7=0(自己的实现是在推进波索引时检查是否输出).

Envelope speed ($408A)

7  bit  0  (write)
---- ----
SSSS SSSS
|||| ||||
++++-++++- Sets speed of volume envelope and sweep envelope
           (0: disable them)

为音量/调制包络设置时钟倍频, 很少会使用(不过不要小看NSF). BIOS将其初始化到$E8.

Volume gain ($4090)

7  bit  0  (read; write through $4080)
---- ----
OOVV VVVV
|||| ||||
||++-++++- Current volume gain level
++-------- Returns 01 on read, likely from open bus

Mod gain ($4092)

7  bit  0  (read; write through $4084)
---- ----
OOVV VVVV
|||| ||||
||++-++++- Current mod gain level
++-------- Returns 01 on read, likely from open bus

频率计算

包络, 在n个CPU周期后, 包络单元会tick一次:

n = CPU clocks per tick
e = envelope speed ($4080/4084)
m = master envelope speed ($408A)

n =  8 * (e + 1) * m

由于FDS只在日本发售, 自然是N制式. 3+6+8=17, 看来必须用32bit整数保存.

一般地, 写入相关寄存器重置计时器, 要到下一次Tick才能正常重置(貌似没有实现).

波形表, 波输出和调制器内部拥有一个12bit的频率值. 还有一个16bit的累加器, 通过每次CPU时钟累加频率值, 超过16bit范围时推进一次位置.

f = frequency of tick
n = CPU clock rate (≈1789773 Hz)
p = current pitch value ($4082/$4083 or $4086/$4087) plus modulation if wave output

f = n * p / 65536

f*: 对于波形表的频率需要再除以64

TICK

包络单元. 启用时, 会被自身计时器tick, 根据$4080/$4084:D6位:

• 增: 如果增益小于32就+1
• 减: 如果增益大于零就-1
• 增益可以手动设置超过32

调制单元, 当调制单元被tick时, 会被根据调制计数器当前的调制表前进指定的次数:

0 = %000 -->  0
1 = %001 --> +1
2 = %010 --> +2
3 = %011 --> +4
4 = %100 --> reset to 0
5 = %101 --> -4
6 = %110 --> -2
7 = %111 --> -1

调制计数器($4085)是一个7bit有符号的数据, 于是就有-64 - 1 = 63之类的操作. 实际实现中我们可以利用8bit有符号int8_t实现: -128 - 2 = 126.

调制计数器实际使用中还是比较麻烦的, wiki都直接给出代码:

// pitch   = $4082/4083 (12-bit unsigned pitch value)
// counter = $4085 (7-bit signed mod counter)
// gain    = $4084 (6-bit unsigned mod gain)

// 1. multiply counter by gain, lose lowest 4 bits of result but "round" in a strange way
temp = counter * gain;
remainder = temp & 0xF;
temp >>= 4;
if ((remainder > 0) && ((temp & 0x80) == 0))
{
    if (counter < 0) temp -= 1;
    else temp += 2;
}

// 2. wrap if a certain range is exceeded
if (temp >= 192) temp -= 256;
else if (temp < -64) temp += 256;

// 3. multiply result by pitch, then round to nearest while dropping 6 bits
temp = pitch * temp;
remainder = temp & 0x3F;
temp >>= 6;
if (remainder >= 32) temp += 1;

// final mod result is in temp
wave_pitch = pitch + temp;

最终值上限可能超过12bit, 低于0的话会(presumably)被钳制到0.

大致过程

包络:

1. 每经过8 * (e + 1) * mCPU周期会Tick一次音量/调制包络
2. 目的是为了调制音量/调制增益
3. 注意相关禁用位$4080 $4084 :D7才能进行增益处理
4. 这里写出音量包络的处理, 调制包络也是非常相似的

/// <summary>
/// StepFC: FDS Tick一次音量包络
/// </summary>
/// <param name="famicom">The famicom.</param>
void sfc_fds_tick_volenv(sfc_famicom_t* famicom) {
    sfc_fds1_data_t* const fds = &famicom->apu.fds;
    assert(fds->flags_4083 == 0);
    assert((fds->modenv_4084 & SFC_FDS_4084_GainMode) == 0);
    // 增
    if (fds->modenv_4084 & SFC_FDS_4084_Increase) {
        if (fds->modenv_gain < 32) {
            fds->modenv_gain++;
            sfc_fds_update_modenv_gain(famicom);
        }
    }
    // 减
    else {
        if (fds->modenv_gain) {
            fds->modenv_gain--;
            sfc_fds_update_modenv_gain(famicom);
        }
    }
}

波输出与调制:

1. 每次个CPU周期增加一个12bit的频率值, 增加到16bit就Tick一次波输出与调制.
2. 波输出 每次个CPU周期还会额外增加一个增益数据
3. 波输出被tick时, 输出当前数据, 然后往前推进一次索引
4. 调制单元被tick时, 根据当前的调制表的信息增减调制计数器
5. 然后根据前面wiki贴出的代码计算出为波输出提供的增益值
6. 这里贴出调制单元Tick时的代码, 波输出还稍微简单点

/// <summary>
/// StepFC: FDS Tick一次调制单元
/// </summary>
/// <param name="famicom">The famicom.</param>
void sfc_fds_tick_modunit(sfc_famicom_t* famicom) {
    assert(famicom->apu.fds.mod_enabled);
    const uint8_t* const table = sfc_get_fds1modtbl(famicom);
    const int8_t value = table[famicom->apu.fds.modtbl_index++];
    sfc_fds1_data_t* const fds = &famicom->apu.fds;
    fds->modtbl_index &= 0x3f;
    fds->mod_counter_x2 += value;

    fds->freq_gained = sfc_fds_get_mod_pitch_gain(
        fds->freq,
        fds->mod_counter_x2 / 2,
        fds->modenv_gain
    );
}

合并输出

主要影响值: 波输出数据, 音量增益, 以及主音量.

• 波输出数据(6bit波数据)
• 音量增益(0-32)
• 主音量(2/2, 2/3, 2/4, 2/5)
• 最大音量大约是2A03方波的2.4倍
• 输出6bit才2.4倍, 可以算出权重大致是0.0045(并不确定, 交给用户控制)
• 最后通过一个滤波, 可近视为截止频率2kHz的低通滤波
• 输出被视为线性的
• 这里由于滤波器的存在, 可以暂时不用考虑重采样的问题

修改点

可以看出可以读取$4040-$4092(大致), 这部分刚好在前面定义的自定义BUS区. 上次刚好将VRC7数据转进来, 这里只好挪一下, 目前BUS布局:

• (自定义BUS)$4000-$403F: 储存调制表
• (自定义BUS)$4040-$407F: 储存波形数据(FDS可读)
• (自定义BUS)$4080-$4082: FDS读取用(FDS可读)
• (自定义BUS)$4100-$4105: NSF程序PALY用
• (自定义BUS)$4106-$410C: NSF程序INIT用(以后谈)
• (自定义BUS)$4180-$41FF: VRC7 PATCH表

static inline void sfc_fds_update_volenv_gain(sfc_famicom_t* famicom) {
    famicom->bus_memory[0x90] = famicom->apu.fds.volenv_gain | 0x40;
}
static inline void sfc_fds_update_modenv_gain(sfc_famicom_t* famicom) {
    famicom->bus_memory[0x92] = famicom->apu.fds.modenv_gain | 0x40;
}

编写FDS出现的问题

新的思路: 这一次尝试用新的思路处理audio_changed事件. 会在音频事件修改前处理(这个事件名称之后应该会继续修改), 然后用最小的临时'context'(上下文)数据而不是保存整个状态. 这个新思路可能会让全部的音频事件模仿.

禁止位: 有一点特别注意, 几乎所有相关bit位是禁止位, 而不是使能位. 实际编写中自己几乎全部弄反了.

调制增益: 调制的目的就是动态修改波输出频率, 不过可能会发生溢出的现象:

• freq + gain < 0
• 自己使用的是uint16_t这就让频率变得异常高
• 根据wiki的说法应该(可能会)钳制到0
• 也可以考虑使用int16_t

效果对比: 测试用ROM, 不对, 测试用NSF文件是一位叫做w7n的作者(四斋)cover的《初音ミクの消失》, 这是来自famitracker论坛. 标题提到是66Hz, 不过实际上60Hz还是可以听一下.

• 这个是NSF. 之所以用这个文件, 是因为音源是2A03+FDS的, 没有其他扩展音源支持. 直接将NSF嫁接到FDS接口就行.
• 仅仅将FDS声道打开就能听到FDS模拟的乐器, 以及最重要——模拟的ミク的声线
• 与自己手上的VirtualNES作比较, 会发现声音大致正确但是杂音有点重
• 其实说是杂音应该是之前提到的'跳跃点':

            **  
              *
               *       **
************    *     *  *
                 **  *
           ^       **
         跳跃点

这首曲子中, 几乎每次说完一个字就会出现. 这个东西通过低通滤波能够减弱, 但是还不能完全消除, 可能性:

• 实现有问题
• VirtuaNES的滤波器实现很不错
• 66Hz/64Hz(NSF文件里写着是这个频率)
• 频率的问题最好验证, 但是似乎没有什么效果
• wiki整篇除了$4083会暂停波外似乎没有有效的处理, 但是又不像三角波暂停后继续, 这里是暂停是为了写入新的数据.
• 这个问题先放着, 毕竟没有接触过FDS

REF

• FDS audio
• [FDS, 66Hz] Hatsune Miku no Shoushitsu (Project Famicaloid)

附录: 初音ミクの消失

《初音ミクの消失》是由cosMo@暴走P Official Channel创作的一首知名曲目.

https://www.youtube.com/watch?v=sMrY0KSPtuM

这首NSF曲子可以在https://www.bilibili.com/video/av3908758/?p=5在线听到.

作为对比, 曲子长度5分钟左右, 但是NSF文件不到300kb, 对比44.1kHz-8bit的wav文件大概需要13mb, 但是包含的信息感觉上却比wav还多.

更好的音频播放

我们之前实现的是在音频API基础上实现的状态机, 精确度大致在60Hz. 由于内部的帧计数器是240Hz的, 所以精度远远不够.

现在就由60Hz一口气提升到44.1kHz吧, 精度即在样本, 这是听觉上的上限, 但是距离最高的1.79MHz还差了几十倍!

而且当然要实现DMC声道, 很多游戏利用DMC发出鼓声来带节奏!

注意, 本节并未处理PAL的场合, 这个, 以后再说!

44.1kHz

采用这个频率不光是主流方案, 还有就是44100除以60和50都可以除尽, 即每帧的样本数量是固定的. 这次核心部分依然不会计算生成样本, 是由接口完成的样本生成, 好处是可以自由地选择采样率, 不用向核心提供参数.

48kHz也是不错的选择.

事件

这次由核心部分提供事件, 然后由接口生成数据:

// 音频事件
void(*audio_changed)(void*, uint32_t, int);

• 第一个参数自然是接口参数, 不过由于懒, 直接用全局数据
• 第二个参数是该帧事件发生时CPU周期数, 用于确定事件发生的时机
• 第三个就是事件类型了: 写入公共的寄存器事件0, 方波1,2以此类推, 6是帧计数器事件(240Hz的那个)

参数2范围: 44100 * 1789773 / 60 = 1315564005在32bit范围内, 也就是说即使是一帧最后一个CPU周期(大致为三万)也能通过32bit整数确定到是最后一个样本

所以, 实际上还是一个状态机, 不过精度高了.

核心 -> 接口事件 -> 生成样本到音频API

StepA: 基础混频

第A步, 基础混频. 之前了解到混频算法:

output = pulse_out + tnd_out

                            95.88
pulse_out = ------------------------------------
             (8128 / (pulse1 + pulse2)) + 100

                                       159.79
tnd_out = -------------------------------------------------------------
                                    1
           ----------------------------------------------------- + 100
            (triangle / 8227) + (noise / 12241) + (dmc / 22638)

文档还提到了可以使用查表或者线性逼近的方法混频.

这里因为使用的是桌面平台, 浮点计算能力不错, 加上为用户提供每个声道独立的音量调整还算比较重要, 这里就选择原生的算法.

如果目标平台的浮点计算能力弱的话, 可以考虑用查表的方式.

本篇中很多细节不再描述, 详细地可以参考前面的文章.

事件

超级马里奥跳跃的音效, 之前说到很呆板, 其实很大问题是因为状态机实现有问题, 导致切换状态很容易出现'爆音', 下面是马里奥跳跃时方波#1的状态切换.

注意的是, 好像事件记录有问题, 被延迟了一步, 比如第二次的状态实际在第一次, 不过用来测试足够了.

格式: <帧ID> 事件触发点 : 周期(已经+1) - 音量 - 占空比

< 508> 0.942 :  255 - 15 - 2
< 509> 0.252 :  255 - 14 - 2
< 509> 0.503 :  256 - 14 - 2
< 510> 0.251 :  256 - 13 - 2
< 510> 0.503 :  256 - 12 - 2
< 510> 0.942 :  257 - 12 - 2
< 510> 0.944 :  257 - 11 - 2
< 514> 0.252 :  257 - 15 - 1
< 515> 0.944 :  261 - 15 - 1
< 517> 0.942 :  261 -  9 - 1
< 519> 0.251 :  244 -  9 - 1
< 520> 0.949 :  228 -  8 - 1
< 521> 0.503 :  213 -  8 - 1
< 522> 0.503 :  213 -  7 - 1
< 523> 0.754 :  199 -  7 - 1
< 523> 0.942 :  199 -  6 - 1
< 525> 0.503 :  186 -  6 - 1
< 525> 0.754 :  174 -  6 - 1
< 526> 0.942 :  174 -  5 - 1
< 527> 0.942 :  163 -  5 - 1
< 528> 0.754 :  163 -  4 - 1
< 529> 0.995 :  152 -  4 - 1
< 531> 0.754 :  142 -  3 - 1
< 531> 0.995 :  133 -  3 - 1
< 532> 0.995 :  133 -  2 - 1
< 534> 0.251 :  124 -  2 - 1
< 534> 0.942 :  124 -  1 - 1
< 536> 0.252 :  116 -  1 - 1
< 536> 0.503 :  108 -  1 - 1
< 537> 0.942 :  108 -  0 - 1
< 539> 0.251 :  101 -  0 - 1
< 540> 0.942 :   94 -  0 - 1
< 542> 0.503 :   88 -  0 - 1
< 543> 0.942 :   82 -  0 - 1
< 545> 0.503 :   76 -  0 - 1
< 546> 0.942 :   71 -  0 - 1
< 546> 0.945 :   66 -  0 - 1

我们目前的逻辑: 有一串事件ABCD....当事件进行到F时, 处理E到F之间的样本, [E, F)区间采用E事件状态. 即: 永远处理上一个状态:

static void this_audio_event(void* arg, uint32_t cycle, int type) {

    const uint32_t old_index = g_states.last_cycle * SAMPLES_PER_SEC / NTSC_CPU_RATE;
    const uint32_t now_index = cycle * SAMPLES_PER_SEC / NTSC_CPU_RATE;
    // 将目前的状态覆盖 区间[old_index, now_index)
    make_samples(old_index, now_index);
    g_states.last_cycle = cycle;
    // 后略
}

然后用内建支持正则表达式的脚本语言(比如ruby)处理一下, 将数据转换生成C格式数组, 接下来大致就是方波#1的处理:

static const float sq_seq[] = {
    0, 1, 0, 0, 0, 0, 0, 0,
    0, 1, 1, 0, 0, 0, 0, 0,
    0, 1, 1, 1, 1, 0, 0, 0,
    1, 0, 0, 1, 1, 1, 1, 1,
};

const struct tmp_data {
    uint32_t    id;
    float       pos;
    uint16_t    p;
    uint8_t     v;
    uint8_t     d;
} DATA[] = {
    { 0, 0.000f,  255,  0, 2 },
    // 后略
};

void make_mario_jump() {
    float buffer[SAMPLES_PER_FRAME * 38];
    FILE* const file = fopen("record.flt", "wb");
    if (!file) return;
    memset(buffer, 0, sizeof(buffer));

    float apu_cycle = 0.f;
    const float cycle_per_sample = (float)NTSC_CPU_RATE / (float)SAMPLES_PER_SEC / 2.f;

    const struct tmp_data* data = DATA;
    uint8_t index = 0;
    for (int i = 0; i != sizeof(buffer) / sizeof(buffer[0]); ++i) {
        const float pos = (float)i / (float)SAMPLES_PER_FRAME;
        const float next = (float)(data[1].id) + data[1].pos;
        if (pos >= next) ++data;

        apu_cycle += cycle_per_sample;
        const float p = (float)data->p;
        if (apu_cycle >= p) {
            apu_cycle -= p;
            index++;
            index = index & 7;
        }
        
        float square1 = 0.f;
        if (data->v) {
            const float sq1 = sq_seq[index | (data->d << 3)];
            square1 = data->v * sq1;
        }
        const float sample = 95.88f / ((8128.f / (square1)) + 100.f);
        buffer[i] = sample;
    }

    fwrite(buffer, 1, sizeof(buffer), file);
    fclose(file);
}

因为目前使用的采样率是44.1kHz, 用CPU的1.789MHz除是除不尽的, 所以这里采用了浮点apu_cycle.

apu_cycle += cycle_per_sample;
const float p = (float)data->p;
if (apu_cycle >= p) {
    apu_cycle -= p;
    index++;
    index = index & 7;
}

这里是推进方波的8步索引, 注意的是, 如果周期足够小, 可能会在一次样本中推进多次. 稍微正确一点的是:

apu_cycle += cycle_per_sample;
const float p = (float)data->p;
const int count = (int)(apu_cycle / p);
apu_cycle -= (float)count * p;
index += (uint8_t)count;
index = index & 7;

接下来就是样本的生成了, 输出当前音量即可:

float square1 = 0.f;
if (data->v) {
    const float sq1 = sq_seq[index | (data->d << 3)];
    square1 = data->v * sq1;
}
const float sample = 95.88f / ((8128.f / (square1)) + 100.f);
buffer[i] = sample;

这样马里奥跳跃的音效就生成了, 我们可以利用类似audacity的软件导入裸数据:

就可以听到马里奥跳跃的声音了. 方波#2也是类似的. 在实现细节上值得注意的是:

• 写入$4003会重置方波#1的8步序列索引
• 写入$4007会重置方波#2的8步序列索引

三角波澜T-Wave

这个逻辑同样适合三角波, 值得注意的是, 我们之前实现最初状态机提到过因为三角波特性导致必须播放完一个三角波避免出现'爆音'. 这里解释本身为什么不会出现:

• 线性计数器或者长度计数器为0的话, 三角波的32步序列索引不会再变
• 之前提到会产生'爆音'是因为状态机播放的波形出现跳跃. 但是本身线性计数器或者长度计数器为0的话会暂停三角波的的索引, 以此达到静音的目的, 从而不会'爆'

BEFORE:

*     *                     *     *
 *   *  *     *           *  *   *
  * *    *  *                 * *
---*------*----***********-----*---
               ^         ^
               |         |
                 两次跳跃


                 没有跳跃
AFTER:        |           |
*     *       v           v *     *
 *   *  *     *************  *   *
  * *    *  *                 * *
---*------*--------------------*----

即:

• 线性计数器或者长度计数器为0的话, 依然会继续输出, 除非禁用状态寄存器的三角波, 输出0, 本身可能会产生'爆音', nesdev提到:

To silence the wave, write %10000000 to $4008 and then $4017. Writing a raw period of 0 also silences the wave, but produces a pop, so it's not the preferred method.

.

还有就是是以CPU频率驱动的, 这个问题不大, 毕竟音调会变得奇怪.

噪声

这一次可以通过频率比较准确的模拟LFSR状态了, 只有一点比较反常识:

When bit 0 of the shift register is set, the DAC receives 0

即, LFSR最低位是1, DAC会接收到0. 最低位是0, DAC会接收音量.

之前状态机实现得无所谓, 反正声道是独立的, 现在由于自己混音就得注意点.

DMC

重头戏来了, 这次实现的重点, DMC声道. 由于目前是事件驱动的状态机, DMC状态改变时, 这时候DMC样本非常有可能已经播放完毕了. 我们目前是延迟一个事件处理, 永远处理上一个事件. 也就是说DMC播放完毕处理IRQ是不可能的了.

DMC声道目前来说有三种用法:

• ΔPCM播放
• PCM播放
• 配合IRQ搞事

目前前两个都能处理, 最后一个就无能为力了, 好在最后一个很少见. 以后再说.

注意点: $4015的D4位实际上相当于DMC的播放/停止按钮

$4015 write	---D NT21	Enable DMC (D), noise (N), triangle (T), and pulse channels (2/1)
If the DMC bit is clear, the DMC bytes remaining will be set to 0 and the DMC will silence when it empties.
If the DMC bit is set, the DMC sample will be restarted only if its bytes remaining is 0. If there are bits remaining in the 1-byte sample buffer, these will finish playing before the next sample is fetched.

DMC声道最高频率是大致是33kHz, 就目前的采样率(44.1kHz)而言, 每次采样最多遇到一次DMC修改, 所以可以不用检测修改次数.

即时播放

现在就需要将音频即时播放, 那就处理一下实时播放的策略吧.

之前提到为了避免'饥饿'状态, 一般模拟器会缓存几帧数据再播放. 当然, 除了饥饿, 还有'吃撑'的情况.

个人觉得一个阈值太粗糙, 用两个阈值吧, 上下阈值, 针对不同情况进行处理.

饥饿状态

由于各种原因, 最大的原因可能是计时器的精度, 可能会导致音频播放剩余缓冲区过少(甚至到0), 我们可以这么处理:

1. 跳过视频帧(音频优先)
2. 插入空白音频帧(视频优先)
3. 结合上面两种情况, 比如一开始几秒是视频优先, 后面就是音频优先

列出来主要是可以让用户自行选择, 这里的实现:

• 图方便, 直接插入空白音频帧.
• "认为过少", 是到0了, 即没有剩余的缓冲区, 当前播放的是最后一个.

吃撑状态

由于各种原因, 最大的原因可能是计时器的精度, 可能会导致音频播放剩余缓冲过多. 过多的话, 一, 是可能当前环境不够支持过多的缓冲区, 二, 是会导致音频延迟, 到一定程度就会浑~ 身~ 难~ 受~.

1. 等待一两帧视频(音频优先)
2. 跳过音频帧(视频优先)
3. 结合上面两种情况

列出来主要是可以让用户自行选择, 这里的实现:

• 这里图方便直接睡过去Sleep(30). 毕竟吃饱了就睡是常识!
• 这样的话, 如果目前显示器明显超过60Hz, 会感觉比较难受. 还是那句话, 以后再说.
• "认为过多", 是到超过4, 即5.

.

自己播放时, 几分钟就会触发一次'吃撑':

自己仅仅是等待垂直同步, 也就说可能自己的显示器可能实际是60.01Hz的

(居然发现是PRG-RPM! 请叫我错别字大王)

新的音频/图像接口

之前的xa2_interface.h就升级(或者说降级?)了: xa2_interface1.h

int xa2_init(uint32_t sample_persec) ;
void xa2_clean() ;

void xa2_submit_buffer(const float*, uint32_t len) ;
void xa2_flush_buffer() ;
unsigned xa2_buffer_left() ;

很简单:

• xa2_buffer_left用来检测剩余缓存区数量.
• xa2_flush_buffer 理论上是开始或者结束需要调用
• xa2_submit_buffer 提交当前缓冲区, 由于XAudio2, 这部分缓存必须保证播放时, 引用有效
• 也处理了设备丢失的问题(自己用的是蓝牙耳机)

同样也升级了图像接口, d2d_interface1.h, 修改点很少:

• 交换了AB键, 玩双截龙2时, 突然意识到, A键在右边!
• d2d_submit_wave 就是把样本再发给图像接口一端, 可以显示当前帧的波形图像

当然, 这些都是小接口, 未作优化.

DMC 跳跃

之前4MB的PCM播放的ROM(搞事者转录的寒蝉鸣泣之时-解)也可以正确播放了.

.

不过播放ΔPCM还是可能会出现跳跃:

这是一段鼓声, 不知道是不是BUG. 但是几乎听不出来是'爆音', 或者说, 以为'爆音'就是这段鼓声的特点.

项目地址Github-StepFC-StepA

作业

• 基础: 自己考虑还有什么方法处理饥饿和吃撑的情况?
• 扩展: 自己实现生成WAVE数据的逻辑!
• 从零开始: 从零开始自己的模拟器吧!

REF

• APU Mixer

屏幕相关

这一节将介绍屏幕相关知识

CRT显示器

CRT叫做"阴极射线显像管"(Cathode Ray Tube), 也就是所谓的"大屁股电视机".

以前的老电视都是这种形式, 现在自己老家应该还有用了几十年的老电视. 记得是在初中物理还是是什么地方应该介绍过原理, 这个受限于电力系统的频率, 我国是50HZ, 使用的PAL-D,K制式:

这里有一个视频叫:

• 【中字】慢镜头下的电视工作原理科普（CRT/LED/OLED)
• 油管地址

可以通过高速摄像机直观地理解.

现在视频网站可能有720p, 1080p的视频. p就是表示逐行(progressive)扫描, 对应的就是i, 隔行(interlaced)扫描. 我记得PS3上有1080i的选项但是ps4没有看到(或者没注意到), 可能是时代不同了.

一般没有必要模拟隔行扫描(视频中的显示器貌似就是逐行扫描的CRT), 除非有强迫症. 但是扫描线的概念还是要有的:

1. HBlank
   • 扫描线扫描完一行要返回下一行(隔行的话就是下面第二行)开头, 直接返回会覆盖掉之前辛苦的扫描, 所以电子枪会暂时关掉, 然后掉头.
   • 这段工作会消耗大概整个扫描行1/6的时间.这段空白时间称为水平空白间隙(Horizontal blanking interval), 或者统称水平空白(HBlank). 这个"空白"是指消除电子枪的显示, 也被翻译作"消隐".
2. VBlank
   • 这个概念同样适用于垂直方向, 当整个画面(称为'场'Field, 逐行扫描则可以称为'帧'Frame)显示完了, 电子枪会回到屏幕的左上角. 就有了垂直空白间隙(Vertical Blank Interval), 常称VBlank这个东西.
   • 这段时间相当长, 可能有1毫秒. 拿NTSC举例, NTSC分辨率是720x480, 但是拥有525条扫描线, 有483条可见的扫描线. 剩下的不可见扫描线就是用来处理VBlank以及掉头. 为什么是1毫秒? 可以计算一下!
   • 现在虽然不怎么使用CRT显示器了, 但是这个概念还是一直保留.

计算题

NTSC 一秒显示60场, 每场平均262.5扫描线(隔行扫描). 也就是扫描线频率15.75KHz, 折合63.5微秒(μs), 262.5-241.5 = 21条扫描线. 也就是说VBlank花了1.33毫秒(ms), 标准制式是这样的.

FC的情况

根据NesDev提供的文档Nintendo Entertainment System documentation

+--------+ 0 ----+
|        |       |
|        |       |
| Screen |       +-- (0-239) 256x240 on-screen results
|        |       |
|        |       |
+--------+ 240 --+
|   ??   |       +-- (240-242) Unknown
+--------+ 243 --+
|        |       |
| VBlank |       +-- (243-262) VBlank
|        |       |
+--------+ 262 --+

FC是在243扫描线开始的时候触发VBlank, 240-242是在Unknown状态.

根据NesDev本身自己wiki的情况: PPU Rendering:

• Pre-render scanline (-1, 261)
• Visible scanlines (0-239)
• Post-render scanline (240)
• Vertical blanking lines (241-260)

细节上有些区别, 不过都是240行可见扫描线以及20行的VBlank线. 以wiki为主吧.

REF

• PPU Rendering
• Clock rate

星球大战

说到星球大战可能不得不说开场字幕:

这种开场字幕可谓经典, 连我这种没看过的都知道, 可见一斑. 现在我们就通过3D图形API渲染出类似的结果, 自己对D3D11较(其他API)熟悉, 文本API则使用配套的DWrite+D2D. 当然这种情况请关闭文本API的子像素渲染功能(Windows上叫ClearType技术, 大致原理一样, 细节或许不同)

3D文本

通过3D图形API可以很简单地渲染出来类似的效果, 一般来说有两种方式:

1. 离屏(offscreen)渲染
   先通过文本API在一张位图/纹理上渲染出文本
   
   然后贴在一个矩形
   
2. 转换为三角面
   通过文本API获取(tessellate)出三角面
   
   然后渲染三角面即可
   
3. 格式化为矩形串
   四大天王有5个可是常识!这种个人认为应该是最常用的, 其实就是上面两种的结合, 这里不实现仅仅讨论. 讨论最后面.

离屏渲染

上一节Direct2D 直接与Direct3D 11 进行协同中提到了D3D和D2D的协同工作, 这个协同最主要的当然还是文本渲染! D2D的文本是通过DWrite，简单说这里就是DWrite->D2D->D3D. 其中D2D->D3D已经知道了, 而第一步则非常简单:

1. 创建DWrite工厂DWriteCreateFactory, 最基础的
2. 创建文本格式(TextFormat)IDWriteFactory::CreateTextFormat, 文本格式可以认为是"字体", 相同格式的文本可以用同一个对象
3. 创建文本布局(TextLayout) IDWriteFactory::CreateTextLayout, 官方的说法是:

采用字符串、文本格式和关联约束，并生成一个对象，该对象表示完全分析和格式化结果。

然后D2D就可以直接绘制这个文本布局了ID2D1RenderTarget::DrawTextLayout, 当然D2D对此有优化, 在此不谈.

如果是类似使用OpenGL+FreeType之类的, 可能需要使用一些优化手段了。

转换为三角面

这个需要使用的文本API支持, 好在DWrite是支持的, 大致是

1. 创建一个自定义的文本渲染器, 利用IDWriteTextRenderer::DrawGlyphRun回调获取glyph run.
2. 然后利用IDWriteFontFace::GetGlyphRunOutline获取glyph run的轮廓(outline)
3. 然后实现ID2D1TessellationSink 接口获取(tessellate)三角形信息就好了

效果比较

测试文本节选自《三国演义》, 本想直接用星球大战的, 还是测试汉字效果才是王道:

默认情况的比较如下:

查看原图可以清楚地看出, 渲染小字体用三角面真是全是狗牙, 右侧的大字还能看得出, 左侧第三行三角面模式到第五个字"分(争)"才能辨识出来. 而离屏渲染中对应前面的"七国"也能分辨. 而右侧的大字用离屏渲染的又太模糊(不过这个是可以解决的! 后面会说). 感觉两边都不太行

4xMSAA
既然狗牙有点重, 打开抗锯齿怎么样, 这里用MSAA做测试:

- dustpg使用了4xMSAA
- 效果显著
可以看出几乎所有字都能辨识了, 可见渲染三角面字体必须抗锯齿. 至于怎么抗锯齿就看各位了, 比如也可以从shader下手, 毕竟MSAA是影响全局的.

效率比较

• 时间效率
  这里测试文本总共0x201c个也就是8000+个顶点, 虽然远多于矩形, 但是实际上重点是在像素着色器(PS)上. 1) 整个矩形都需要通过PS(有采样). 2) 只有三角面的部分通过PS(返回指定颜色)
  所以大致是: 顶点实在有点多->离屏渲染快; 渲染矩形小->离屏渲染快.
• 空间效率
  顶点占了大概64kb空间,离屏渲染512x512大概1mb空间, 这个需要斟酌, 因为512x512有时浪费有时不够用. 所以有一个通用结论: 当字体足够大时, 使用三角面更为划算(D2D应该就是这么实现的)
• 结论
  当字体足够大时, 使用三角面更为划算

本文使用的代码全在NoteFL/D3D11/D3D11Text3D/main.cpp里面, 有需要的可以查看

扩展阅读: 有向距离场(Signed Distance Fields)

对于这种文本(或者说灰度数据, 这里的灰度就是Alpha), V社(对, 就是不会数3的那个)发表了一篇Improved Alpha-Tested Magnification for Vector Textures and Special Effects的论文, 能够有效改善文本模糊的问题, 效果可谓是非常不错.

四大天王

OpenGL+FreeType的话可使用, 类似:

在渲染小字体时, D2D就是对于每个字符就是一个矩形, 对应的纹理坐标自然就是纹理缓存中的. (D2D渲染大字体则就是渲染三角面, 应该, 大概, 可能吧), 这就是第三种方法——四大天王! 不对, 格式化为矩形串.

这种情况需要自己实现一个字体纹理管理器, 毕竟汉字几万个. 然后实现一个简单的排版引擎. 再加上前面提到的SDF, 可谓是非常完美. (这个方法其实DWrite+D2D帮你实现了, 但是放在3D空间中就需要自己实现了)

这种情况下时间效率分析:
矩形位置需要通过PS, PS过程需要采样, 大致介于上面两种情况之间
这种情况下空间效率分析:
不用说, 不含缓存纹理的话(全局都可以用)是最划算的.
结论:
不嫌麻烦的话, 这个+SDF应该是最好的办法了

自己常用的小技巧

这里列出了自己常用的一些c/c++小技巧, 有些会有不足, 可以简单探讨一下.

大小端

分类: 简单讨论

"大小端"这一名称来自很有意思. 不过, 在这里, 大致就是怎么处理"字节序"的. 我们用char, char16_t以及char32_t描述'A'的话就是这样的:

(按地址增长方向排列)

              小端序        大端序        混合序
char           'A'           'A'          'A'
char16_t      'A',0        0,'A'     (?) 'A',0
char32_t     'A',0,0,0    0,0,0,'A'  (?)0,0,'A',0

一般来说只需要考虑大小端, 这两个即可, 混合序的程序估计得定制.

如何判断大小端呢? 终于在c++20中有了std::endian. 同时对于类gcc编译器可以使用:

// is little endian
struct is_little_endian { enum : bool { value = __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ }; };
// is big endian
struct is_big_endian { enum : bool { value = __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ }; };
// is pdp endian
struct is_pdp_endian { enum : bool { value = __BYTE_ORDER__ == __ORDER_PDP_ENDIAN__ }; };

限制模板膨胀

分类: 体积优化

c++模板极大地方便了代码编写, 但是有一个重要的问题就是如果滥用, 模板膨胀会极大地增加程序体积. 可能不少人会不在意, 毕竟内存白菜价. 不过也会有像我这种比起时间复杂度, 也会在意空间的.

上一部分我们用的是char自然是引出这部分: 字符串处理中部分限制. 比如c++标准模板库中<string>中有:

类型                     定义
std::string              std::basic_string<char>
std::wstring             std::basic_string<wchar_t>
std::u16string (C++11)   std::basic_string<char16_t>
std::u32string (C++11)   std::basic_string<char32_t>

虽然有非常多的文字编码, 但是或多或小地会在低字节与ASCII兼容. 我们在处理纯英文数字时(比如字符串转成数字)会仅仅处理ASCII部分, 利用字符之间的间隔就能轻松地在一条函数实现char等三种.

例如现在实现了一条函数, 字符串转换整型:

int32_t my_atoi(const char* ptr, size_t len) {
    // 具体实现
    ++ptr;
    // 具体实现
}

然后把ptr++之类的操作换成ptr+=n即可:

int32_t my_atoi_ex(const char* ptr, size_t len, size_t n) {
    // 具体实现
    ptr += n;
    // 具体实现
}

然后就是大小端了. 最低位在char16_t, char32_t中偏移不一样. 偏移量在上面列出了, 然后用模板特化就能编译期获取偏移量, 这个就不累述了. 最后就能实现为:

extern "C" int32_t my_atoi_ex(const char* ptr, size_t len, size_t n);

namespace detail {
    // ascii offset
    template<unsigned SIZE> struct ascii_offset;
    // ascii offset for 1 [char]
    template<> struct ascii_offset<1> { enum { value = /*impl*/ }; };
    // ascii offset for 2 [char16_t]
    template<> struct ascii_offset<2> { enum { value = /*impl*/ }; };
    // ascii offset for 4 [char32_t]
    template<> struct ascii_offset<4> { enum { value = /*impl*/ }; };
}

template<typename T> inline
int32_t MyAtoI(const T* str, size_t len) {
    const auto ptr = reinterpret_cast<const char*>(str) + detail::ascii_offset<sizeof(T)>::value;
    return ::my_atoi_ex(ptr, len, sizeof(T));
}

这是关于字符串处理相关限制模板, 理论上节约了2/3的代码空间. 接下来就是关于容器方面的限制.

c++用模板封装容器就能非常方便地使用, 这里就是以类std::vector的实现讨论这一问题. 向量, 或者还是用数组比较顺口储存了连续的数据.

在实际实现上 std::vector<int32_t>::push_back和std::vector<float>::push_back由于int32_t和float大小一致, 这两条函数可能会被优化合并为一条函数. 大致同理, 我们可以把这种没有构造/析构的对象单独拿出来实现一个专门储存这一类的容器, 经过内联后, 这一类调用的函数会完全指向同一个实现.

为了方便起见, 就称为"POD Vector", 我们可以通过std::is_pod 再配合static_assert防止程序猿作死. 自己在pod_vector.h, pod_vector.cpp 里实现了. 大致结构为:

class basic_vector {
    char*       data;
    uint32_t    length;
    uint32_t    capacity;
    uint32_t    size;
};

template<typename T>
class pod_vector : protected basic_vector {
    static_assert(std::is_pod<T>::value, "type T must be POD");
};

pod_vector在外层实现几乎兼容std::vector以方便使用. 这样随便用pod_vector也无需担心模板膨胀, 唯一低效率的情况就是例如pod_vector<char>::push_back效率较低. 说到char, 各位也会发现"字符串"也可以用这种方法实现!

特别地, 通过简单改造basic_vector, 字符串就能直接也能用pod_vector实现, LongUI中, 三种字符串char char16_t char32_t均是POD Vector的实现, 以实现轻量级目标.

可能大家会说, 只能用POD没啥用啊. 但是我们也可以实现不会模板膨胀的"非POD Vector". 自己在之前C++ 获取构造函数/析构函数的函数指针提到了, 我们可以使用类似于虚表的东西, 实现不会模板膨胀的"非POD Vector", 缺点就是用于 用于本身重点侧重于RAII的(例如智能指针之类构造析构比较短的), 用起来"不划算". 大型对象还是很划算的. 自己虽然实现了, 但是没用过所以应该有BUG(没用过的主要原因是因为标准库没有类似try_realloc的函数, 有的话效率在修改容量时大大提升速度).

常量折叠

分类: 空间优化

前面提到, std::vector<int32_t>::push_back和std::vector<float>::push_back可能会被"合并". 其根本原因其实是链接器的链接时优化, 把相同的常量折叠为一个, 从而减少程序体积. 这个就被称为"常量折叠".

我们当然可以进行扩展, 手动在运行时实现常量折叠. 这里先举一个特殊的例子. 之前说到工厂模式中链表使用头节点与尾节点方便处理:

struct Node {
    Node*   prev;
    Node*   next;
};
class Factory {
    Node    head;
    Node    tail;
};

其中, head的prev和tail的next会一直为nullptr. 所以, 我们可以把他们折叠在一起!

void* data[3]:

            tail     head     

[0] xxxx    prev
[1] null    next     prev
[2] yyyy             next

当然, 用于工厂模式没什么用, 就节约一个指针而已. 不过如果是树的一个实现, 那么每个节点都能节约一个指针就..."还行"...

虽然我们用"折叠"这个词汇, 核心**是"复用"数据. c++17中的string_view其**其实也是这个.

例如一个字符串PI=3.14159, 经过词法分析后可能被拆为"PI", "=", "3.14159"三部分. 如果每个部分都重新申请就会申请3个很短的字符串, 当然是非常不"划算". string_view就只需要在原来的字符串标记处起点与终点就能"复用"原来的字符串.

所以不要局限于"C风格(NUL结尾)"的字符串, 将自己所有字符串处理函数添加字符串的长度参数, 然后按照该长度处理也是极好的.(之前例子中的my_atoi拥有长度参数, 可以直接处理string_view!)

并且, "常量折叠"运行期可以升级为"同"量折叠. 这里修改了原字符串就能影响所有的string_view.

虚析构函数 虚释放函数

分类: 简单讨论

可能会在有些地方会建议"将所有析构函数声明为虚析构函数", 然后可能用着用着, 发现一个final关键字比较好. 不过这里讨论的不是该不该用, 而是怎么用: 虚析构函数, 还是虚释放函数:

struct Foo {
    virtual ~Foo(){}
};
struct Bar {
    virtual void Dispose() { delete this; }
};

释放一个继承于基础类的对象, 比较简单的就是这两种. 那么用那种呢? 这里先说说自己的建议:

• 对称原则
• 如果用new的, 就用delete
• 如果用类似Bar::Create的, 就用#Dispose

这个结论也很简单, 那么有什么好讨论的呢? 那就是new和delete被称为"操作符", 还允许被重载:

struct Foo {
    static void operator delete (void* p) { ::delete p; }
    virtual ~Foo() {  }
};

struct Bar : Foo {
    static void operator delete (void* p) { ::delete p; }
    virtual ~Bar() {  }
};

int main() {
    Foo* foo = new(std::nothrow) Bar;
    delete foo;
}

哪个operator delete会被调用呢?

我们会一般用重载(overload)操作符, 而不是说重写(override)操作符(cppreference的说法: Class-specific overloads), 加上static的迷惑性会让代码产生一些歧义. 当然, 这很大程度上仅仅是自己对c++了解不够, 所以产生的迷惑.

这里所讨论的就是, 如果可能基继承类会修改了内存分配的情况, 这种情况很少见, 但是如果出现了建议使用虚释放函数. 这里一点, Windows上的COM对象就是使用了Release.

STEP3: CPU 指令实现 - 扩展指令

这节是指令介绍的最后一节.

扩展指令, 或者说非法/未被记录的指令: 一般是组合指令. 由于非官方记录, 所以指令名称可能不一致.

本节很多指令并没有在STEP3中实现, 原因是因为使用的测试ROM并没有测试这些指令, 所以'忘记'实现了, 这些指令直到测试了'blOperg's CPU test rom v5'才实现.

NOP - No OP

除了基本的NOP, 还有高级的NOP. 一般来讲6502指令是根据寻址方式排序的(偏移), 所以在其他寻址方式对应NOP的地方还有

详细的请到引用链接了解

ALR[ASR] - 'And' then Logical Shift Right - AND+LSR

助记符号: A &= M; C = A & 1; A >>= 1;

只有两个指令周期(NOP你看看你), 应该是都消耗在了读取数据上

AND+LSR 的组合指令 - 逻辑与运算再右移一位:
影响FLAG: C(arry), S(ign), Z(ero), 伪C代码:

A &= READ(address);
CHEKC_CFLAG(A & 1);
A >>= 1;
CHECK_ZSFLAG(A);

例子: ALR #$FE 基本等价于 LSR A + CLC. 前者2字节2周期, 后者2字节4周期

ANC[AAC] - 'And' then copy N(S) to C

助记符号: A &= M; C = N(S);

N(egative)或者说S(ign)位的值复制到C(arry)位,
影响FLAG: C(arry), S(ign), Z(ero), 伪C代码:

A &= READ(address);
CHECK_ZSFLAG(A);
CF = SF; 

例子: ANC #$FF 有符号扩展; ANC #$00 基本等价于 LDA #$00 + CLC.

ARR - 'AND' then Rotate Right - AND+ROR [类似]

助记符号: A &= M; A = (A>>1)|(C<<7); C = (A>>6)&1; V = ((A>>5)^(A>>6)&1);

基本等价于 AND+ROR, 除了FALG设置.

C is bit 6 and, V is bit 6 xor bit 5.

影响FLAG: C(arry), S(ign), Z(ero), (o)V(erflow), 伪C代码:

A &= READ(address);
A = (A >> 1) | (CF << 7);
CHECK_ZSFLAG(A);
CHECK_CFLAG(A>>6);
CHECK_VFLAG(((A>>5)^(A>>6))&1);

AXS[SBX] - A 'And' X, then Subtract memory, to X

助记符号: X = (A&X) - M;

影响FLAG: C(arry), S(ign), Z(ero), 伪C代码:

uint16_t tmp = (SFC_A & SFC_X) - SFC_READ_PC(address);
X = (uint8_t)tmp;
CHECK_ZSFLAG(X);
SET_CF((tmp & 0x8000) == 0);

LAX - Load 'A' then Transfer X - LDA + TAX

助记符号: X = A = M;

* 在页面边界交叉时 +1s

将储存器数据载入A, 然后传给X.
影响FLAG: S(ign), Z(ero), 伪C代码:

X = A = READ(address);
CHECK_ZSFLAG(X);

SAX - Store A 'And' X

助记符号: M = A & X;

将累加器A和变址寄存器X '与' 的结果保留在储存器上. 影响FLAG: (无), 伪C代码:

WRITE(address, A & X);

DCP - Decrement memory then Compare with A - DEC + CMP

助记符号: M -= 1; A - M ? 0

读改写(RMW)指令, 存储器值-1再与累加器比较.
影响FLAG: C(arry), Z(ero), S(ign). 伪C代码:

tmp = READ(address);
--tmp;
WRITE(address, tmp);

uint16_t result16 = (uint16_t)A - (uint16_t)tmp;
CF = result16 < 0x100;
CHECK_ZSFLAG((uint8_t)result16);

ISC(ISB) - Increment memory then Subtract with Carry - INC + SBC

读改写(RMW)指令, 存储器值+1再用累加器减.
影响FLAG: C(arry), (o)V(erflow), Z(ero), S(ign). 伪C代码:

// INC
tmp = READ(address);
++tmp;
WRITE(address, tmp);

// SBC
uint16_t result16 = A - tmp - (CF ? 0 : 1);
CHECK_CFLAG(!(result16>>8));
uint8_t result8 = result16;
CHECK_VFLAG(((A ^ result8) & 0x80) && ((A ^ tmp) & 0x80));
A = result8;
CHECK_ZSFLAG(A);

RLA - Rotate Left then 'And' - ROL + AND

读改写(RMW)指令, 储存器数据循环左移再与累加器A做'与'运算.
影响FLAG: C(arry), Z(ero), S(ign). 伪C代码:

// ROL
uint16_t src = READ(address);
src <<= 1;
if (CF) src |= 0x1;
CHECK_CFLAG(src > 0xff);
uint8_t result8 = src;
WRITE(address, result8);
// AND
A &= result8;
CHECK_ZSFLAG(A);

RRA - Rotate Right then Add with Carry - ROR + ADC

读改写(RMW)指令, 储存器数据循环右移再加上累加器A和进位标记.
拿来用来计算 A+V/2, 其中V是9位(支持到512)数据.
影响FLAG: C(arry), S(ign), Z(ero), (o)V(erflow), 伪C代码:

// ROR
uint16_t src = READ(address);
if (CF) src |= 0x100;
CF = src & 1;
src >> 1;
WRITE((uint8_t)src);
// ADC
uint16_t result16 = A + src + (CF ? 1 : 0);
CHECK_CFLAG(result16>>8);
uint8_t result8 = result16;
CHECK_VFLAG(!((A ^ src) & 0x80) && ((A ^ result8) & 0x80));
A = result8;
CHECK_ZSFLAG(A);

值得注意的是ADC的第一行的 (CF? 1: 0) 就是继承于ROR的第三行CF = 操作.
所以可以实现为:

// ROR
// ...
tmp_CF = src & 1;
// ...
// ADC
uint16_t result16 = A + src + tmp_CF;
// ...

SLO - Shift Left then 'Or' - ASL + ORA

助记符号: A |= (M <<= 1)

读改写(RMW)指令, 储存器数据算术左移一位然后和累加器A做'或'运算,
由于要和累加器计算, 所以没有单字节指令SLO A, 即寻址方式为'累加器A'的.
影响FLAG: C(arry), Z(ero), S(ign). 伪C代码:

// ASL
tmp = READ(adress);
CHECK_CFLAG(tmp>>7);
tmp <<= 1;
WRITE(address, tmpdt);
// ORA
A |= tmp;
CHECK_ZSFLAG(A);

SRE - Shift Right then "Exclusive-Or" - LSR + EOR

读改写(RMW)指令, 储存器数据逻辑右移一位然后和累加器A做'异或'运算,
由于要和累加器计算, 所以没有单字节指令SRE A, 即寻址方式为'累加器A'的.
影响FLAG: C(arry), Z(ero), S(ign). 伪C代码:

// LSR
tmp = READ(address);
CHECK_CFLAG(tmp & 1);
tmp >>= 1;
WRITE(address, tmpdt);
// EOR
A ^= tmp;
CHECK_ZSFLAG(A);

SHX[SXA] - 行为可能不一致, 不做实现

SHX & SHY, 不过"blOperg's CPU test rom v5"中测试了该指令

SHY[SYA] - 行为可能不一致, 不做实现

SHX & SHY, 不过"blOperg's CPU test rom v5"中测试了该指令

blOperg's CPU test rom v5

测试ROM: "blOperg's CPU test rom v5"中, 仅仅不通过以上两个指令.

LAS - 行为可能不一致, 不做实现

XAA - 行为可能不一致, 不做实现

AHX[SHA] - 行为可能不一致, 不做实现

TAS - 行为可能不一致, 不做实现

KIL(STP) Kill Stop - 指令会导致CPU停下来, 不做实现

REF

• nesdev-archive
• NES 文档2.00
• Programming with unofficial opcodes
• 6502_cpu
• undocumented_opcodes