You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: numerous tools additions + firm make support + fixes!
* tools: init pica disasm dvl/raw, now dvl (shbin's) and raw instruction
streams can be disassembled.
* tools: init firm dump and firm make, firm make has been tested and has
built sucessfully a Luma3DS firm (even booted!)
* tools/Ncch: more misc changes, still not finished.
* hardware/pica: finish shader assembler, only missing literally *1*
diagnostic.
* horizon/fmt: finish dvl format description.
* docs/zpsh: document the zpsh format, still not final.
* ci: update to 0.15.2
Copy file name to clipboardExpand all lines: README.md
+8-3Lines changed: 8 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -80,6 +80,10 @@ Currently there are multiple examples in the `demo/` directory. To build them, y
80
80
-[flappy](demo/flappy) is a simple fully functional flappy bird clone written entirely with software blitting.
81
81
-[gpu](demo/gpu/) is a playground for [mango](src/mango.zig), bleeding edge features are tested there. Not really an example per-se.
82
82
83
+
---
84
+
85
+
You can (and are encouraged) to look at the `tools` directory as it is a good example of how to use the API's `zitrus` provides outside (and inside!) of a 3DS environment. Almost all tools are self-contained and span 50-300 LOC.
86
+
83
87
# Coverage
84
88
85
89
### Legend
@@ -109,8 +113,9 @@ Currently there are multiple examples in the `demo/` directory. To build them, y
109
113
- 🟢 3dsx (tools/3dsx): Make / Dump
110
114
- 🟢 Pica (tools/Pica): Assemble / Disassemble
111
115
- 🟢 Assemble: Only **Z**itrus**P**ica**Sh**aders are implemented as an output format.
112
-
- 🟢 Disassemble: Outputs **Z**itrus**P**ica**A**sse**m**bly, only ZPSH's can be disassembled currently.
113
-
- 🟡 Firm (tools/Firm): Info
116
+
- 🟢 Disassemble: Outputs **Z**itrus**P**ica**A**sse**m**bly. Either RAW instructions, ZPSH's or DVL's (.shbin) can be disassembled.
117
+
- 🟢 Firm (tools/Firm): Make / Info / Dump
118
+
- 🟢 Make: Confirmed to build (and boot!) Luma3DS from source, however needs more testing as the firm is not 1:1.
I wanted to learn arm and always wanted to develop 3DS homebrew, also I searched and I haven't found any kind of zig package that doesn't use libctru, so I just started reading a lot and doing things. Furthermore, using only zig has a lot of advantages:
200
-
- Really simplified and easy development. You don't need complex toolchains, you just need the `zig` executable, that's it! (However, obviously it is recommended that you use devkitPRO's tools as I'm sure you'll need them. You want to use gdb, don't you?)
205
+
- Really simplified and easy development. You don't need complex toolchains, you just need the `zig` executable, that's it. The tools `zitrus` provides also have no dependencies, they'll work on any platform that zig supports! You can still use devkitPRO's binutils if you need.
201
206
- Safety in `Debug` and `ReleaseSafe` modes. Zitrus currently uses the `ErrDisp` port to report panics and returned errors. The only missing thing is reporting return traces with debugging symbols (Currently only addresses are logged)
202
207
- Really useful and simple build-system (as you've seen the example `build.zig` is really small and makefiles are really arcane)
|`shader`|`bitpacked struct(u32)`| Starting from the LSb, the first `u12` is the number of entrypoints, the next `u12` is the number of instructions **minus one**, a valid PICA200 shader must have at least one instruction, `end`. The last `u8` is the number of instruction operand descriptors, **the value must be no larger than 128**|
19
+
|`entry_string_table_size`|`u16`| Size **in `u32`s** of the entrypoint string table |
20
+
|`flags`|`bitpacked struct(u8)`| Reserved |
21
+
|`header_size`|`u8`| Real size **in `u32`s** of the **Header**, allows for *forward compatibility*|
|`name_string_offset`|`u32`| Offset of the name in the entrypoint string table |
46
+
|`instruction_offset`|`u16`| Entry instruction offset, must be less than 4096 |
47
+
|`info`|`bitpacked struct(u16)`| Shader type and parameters, see below for the layout |
48
+
|`boolean_constant_mask`|`bitpacked struct(u16)`| Each bit represents the state of the constant boolean register `bX`|
49
+
|`integer_constant_mask`|`bitpacked struct(u16)`| Each bit represents whether a constant for the integer register `iX` follows, the remaining 12-bits are reserved and must be zeroed. |
50
+
|`floating_constant_mask`|`extern struct`| Each bit represents represents whether a constant for the floating register `fX` follows, the remaining bits are reserved and must be zeroed. |
51
+
|`output_mask`|`bitpacked struct(u16)`| Each bit represents represents whether an output map for the output register `oX` follows. |
52
+
53
+
#### `boolean_constant_mask` bit layout
54
+
55
+
Each bit represents the constant value for the register at that bit index.
56
+
57
+
| 16 | ... | 0 |
58
+
|:---:|:---:|:--:|
59
+
| b15 | bN | b0 |
60
+
61
+
#### `integer_constant_mask` bit layout
62
+
63
+
Each bit represents whether a constant value for the register at that bit index follows after the header.
64
+
65
+
Constants are sorted for each bit, that is, if bits `0` and `3` are set, the first constant will be for register `i0`
66
+
and the second for `i3`.
67
+
68
+
| 16...4 | 3 | 2 | 1 | 0 |
69
+
|:--------:|:--:|:--:|:--:|:--:|
70
+
| reserved | i3 | i2 | i1 | i0 |
71
+
72
+
#### `floating_constant_mask` layout
73
+
74
+
Each bit represents whether a constant value for the register at that bit index follows after the header.
|`low`|`bitpacked struct(u32)`| Whether a constant value follows for registers `f0`-`f31`|
81
+
|`mid`|`bitpacked struct(u32)`| Whether a constant value follows for registers `f32`-`f63`|
82
+
|`high`|`bitpacked struct(u32)`| Whether a constant value follows for registers `f64`-`f95`|
83
+
84
+
Bit layout for each field follows the same structure as `boolean_constant_mask` and `integer_constant_mask`.
85
+
86
+
#### `output_mask` bit layout
87
+
88
+
Each bit represents whether an output map for the register at that bit index follows after the header.
89
+
90
+
| 16 | ... | 0 |
91
+
|:---:|:---:|:--:|
92
+
| o15 | oN | o0 |
93
+
94
+
### Entrypoint constants and output maps
95
+
96
+
Each entrypoint can be considered as a different `shader module` that shares instructions with others. As such, they have different sets
97
+
of constants and output maps.
98
+
99
+
The layout is the following:
100
+
- Entrypoint Header
101
+
- Integer constants, one for each bit set in `integer_constant_mask`
102
+
- Floating constants, one for each bit set in `floating_constant_mask`
103
+
- Output maps, one for each bit set in `output_mask`
104
+
105
+
#### Integer constant
106
+
107
+
A `[4]u8` representing a 4-component vector with layout `xyzw`.
108
+
109
+
#### Floating constant
110
+
111
+
A packed 4-component `F7_16` vector in the format required by the PICA200. It can be seen as storing all `F7_16` components packed in an `[3]u32` and doing a `swap` of the first and last `u32`.
112
+
113
+
#### Output map
6
114
7
-
You can see the format types in `fmt/zpsh.zig` and how it is written in `tools/pica/main.zig`.
8
-
If you've never read zig, [here's the official reference](https://ziglang.org/documentation/master/)
115
+
An map describing output semantics for each component of the specified output. They're in the format required by the PICA200.
Copy file name to clipboardExpand all lines: docs/pica/zpsm.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,15 +23,15 @@ A `Limited source register` or `src_limited` refers to an `Input` or `Temporary`
23
23
24
24
A `Destination register` or `dst` refers to an `Output` or `Temporary` register.
25
25
26
+
A `Floating constant` register may be addressed at runtime starting at a base register fX, in that case you may use `a.x`, `a.y` or `a.l` to do so. E.g: `fX[a.x]`
27
+
26
28
## Basic Syntax
27
29
28
30
Each basic unit is a line, operands must be in the same line as the mnemonic/directive,
29
31
one exception to this rule is an instruction preceded by a label, as it is perfectly valid.
30
32
31
33
Comments start with ';', only single line comments are supported.
32
34
33
-
There's one TODO left, relative `Floating constant` source addressing with the address register.
0 commit comments