curioustorvald/tsvm
1
0
Fork 0
mirror of https://github.com/curioustorvald/tsvm.git synced 2026-03-07 19:51:51 +09:00
Code Issues Packages Projects Releases Wiki Activity
Files
d1033736140c69d0562dc137fdf91cb394439ea8
tsvm/terranmon.txt
minjaesong d103373614 gpu: new font rom designation
2022-06-18 01:41:11 +09:00

484 lines
13 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
1 byte = 2 pixels
560x448@4bpp = 125 440 bytes
560x448@8bpp = 250 880 bytes
-> 262144 bytes (256 kB)
[USER AREA | HW AREA]
Number of pheripherals = 8, of which the computer itself is considered as
a peripheral.
HW AREA = [Peripherals | MMIO | INTVEC]
User area: 8 MB, hardware area: 8 MB
8192 kB
User Space
1024 kB
Peripheral #8
1024 kB
Peripheral #7
...
1024 kB (where Peripheral #0 would be)
MMIO and Interrupt Vectors
128 kB
MMIO for Peri #8
128 kB
MMIO for Peri #7
...
128 kB (where Peripheral #0 would be)
MMIO for the computer
130816 bytes
MMIO for Ports, etc.
256 bytes
Vectors for 64 interrupts
--------------------------------------------------------------------------------
IO Device
Endianness: little
Note: Always takes up the peripheral slot of zero
Latching: latching is used to "lock" the fluctuating values when you attempt to read them so you would get
reliable values when you try to read them, especially the multibyte values where another byte would
change after you read one byte, e.g. System uptime in nanoseconds
MMIO
0..31 RO: Raw Keyboard Buffer read. Won't shift the key buffer
32..33 RO: Mouse X pos
34..35 RO: Mouse Y pos
36 RO: Mouse down? (1 for TRUE, 0 for FALSE)
37 RW: Read/Write single key input. Key buffer will be shifted. Manual writing is
usually unnecessary as such action must be automatically managed via LibGDX
input processing.
Stores ASCII code representing the character, plus:
(1..26: Ctrl+[alph])
3 : Ctrl+C
4 : Ctrl+D
8 : Backspace
(13: Return)
19: Up arrow
20: Down arrow
21: Left arrow
22: Right arrow
38 RW: Request keyboard input be read (TTY Function). Write nonzero value to enable, write zero to
close it. Keyboard buffer will be cleared whenever request is received, so
MAKE SURE YOU REQUEST THE KEY INPUT ONLY ONCE!
39 WO: Latch Key/Mouse Input (Raw Input function). Write nonzero value to latch.
Stores LibGDX Key code
40..47 RO: Key Press buffer
stores keys that are held down. Can accomodate 8-key rollover (in keyboard geeks' terms)
0x0 is written for the empty area; numbers are always sorted
48..51 RO: System flags
48: 0b r000 000t
t: STOP button (should raise SIGTERM)
r: RESET button (should reset the system)
64..67 RO: User area memory size in bytes
68 WO: Counter latch
0b 0000 00ba
a: System uptime
b: RTC
72..79 RO: System uptime in nanoseconds
80..87 RO: RTC in microseconds
88 RW: Rom mapping
89 RO: BMS flags
0b b000 00ca
a: 1 if charging (accepting power from the AC adapter)
c: 1 if battery is detected
b: 1 if the device is battery-operated
if the device is battery-operated but currently running off of an AC adapter and there is no battery inserted,
the flag would be 1000 0001
90 RO: BMS calculated battery percentage where 255 is 100%
91 RO: BMS battery voltage multiplied by 10 (127 = "12.7 V")
1024..2047 RW: Reserved for integrated peripherals (e.g. built-in status display)
4076..4079 RW: 8-bit status code for the port
4080..4083 RO: 8-bit status code for connected device
4084..4091 RO: Block transfer status
0b nnnnnnnn a000 mmmm
n-read: size of the block from the other device, LSB (4096-full block size is zero)
m-read: size of the block from the other device, MSB (4096-full block size is zero)
a-read: if the other device hasNext (doYouHaveNext), false if device not present
n-write: size of the block I'm sending, LSB (4096-full block size is zero)
m-write: size of the block I'm sending, MSB (4096-full block size is zero)
a-write: if there's more to send (hasNext)
4092..4095 RW: Block transfer control for Port 1 through 4
0b 00ms abcd
m-readonly: device in master setup
s-readonly: device in slave setup
a: 1 for send, 0 for receive
b-write: 1 to start sending if a-bit is set; if a-bit is unset, make other device to start sending
b-read: if this bit is set, you're currently receiving something (aka busy)
c-write: I'm ready to receive
c-read: Are you ready to receive?
d-read: Are you there? (if the other device's recipient is myself)
NOTE: not ready AND not busy (bits b and d set when read) means the device is not connected to the port
4096..8191 RW: Buffer for block transfer lane #1
8192..12287 RW: Buffer for block transfer lane #2
12288..16383 RW: Buffer for block transfer lane #3
16384..20479 RW: Buffer for block transfer lane #4
65536..131071 RO: Mapped to ROM
--------------------------------------------------------------------------------
VRAM Bank 0 (256 kB)
Endianness: little
From the start of the memory space:
250880 bytes
Framebuffer
3 bytes
Initial background (and the border) colour RGB, of which only the lower 4 bits per each channel are used
1 byte
command (writing to this memory address changes the status)
1: reset palette to default
2: fill framebuffer with given colour (arg1)
3: do '1' then do '2' (with arg1) then do '4' (with arg2)
4: fill framebuffer2 with given colour (arg1)
16: copy Low Font ROM (char 0–127) to mapping area
17: copy High Font ROM (char 128–255) to mapping area
18: write contents of the font ROM mapping area to the Low Font ROM
19: write contents of the font ROM mapping area to the High Font ROM
20: reset Low Font ROM to default
21: reset High Font ROM to default
12 bytes
argument for "command" (arg1: Byte, arg2: Byte)
write to this address FIRST and then write to "command" to execute the command
1134 bytes
unused
(1920) !!PENDING FOR REMOVAL!!
mapped to font ROM
Font Mapping area holds 128 characters in consecutive order, each character is always 15 bytes.
(designer's note: it's still useful to divide the char rom to two halves, lower half being characters ROM and upper half being symbols ROM)
2 bytes
Cursor position in: (y*80 + x)
2560 bytes
Text foreground colours
2560 bytes
Text background colours
2560 bytes
Text buffer of 80x32 (7x14 character size, and yes: actual character data is on the bottom)
512 bytes
Palette stored in following pattern: 0b rrrr gggg, 0b bbbb aaaa, ....
Palette number 255 is always full transparent (bits being all zero)
(DRAFT) Optional Sprite Card (VRAM Bank 1 (256 kB))
250880 bytes
One of:
Secondary layer
Other 8-bit of the primary framebuffer (4K colour mode)
SPRITE FORMAT DRAFT 1
533 bytes: Sprite attribute table
(41 sprites total, of which 1 is GUI cursor)
12 bytes - signed fixed point
X-position
Y-position
Transform matrix A..D
1 bytes
0b 0000 00vp
(p: 0 for above-all, 1 for below-text, v: show/hide)
10496 bytes: Sprite table
256 bytes
16x16 texture for the sprite
235 bytes:
unused
SPRITE FORMAT DRAFT 2
DMA Sprite Area - 18 bytes each, total of ??? sprites
1 byte
Sprite width
1 byte
Sprite height
12 bytes - signed fixed point
Affine transformation A,B,C,D,X,Y
1 byte
Attributes
0b 0000 00vp
(p: 0 for above-all, 1 for below-text, v: show/hide)
3 bytes
Pointer to raw pixmap data in Scratchpad Memory
MMIO
0..1 RO
Framebuffer width in pixels
2..3 RO
Framebuffer height in pixels
4 RO
Text mode columns
5 RO
Text mode rows
6 RW
Text-mode attributes
0b 0000 00rc (r: TTY Raw mode, c: Cursor blink)
7 RW
Graphics-mode attributes
0b 0000 rrrr (r: Resolution/colour depth)
8 RO
Last used colour (set by poking at the framebuffer)
9 RW
current TTY foreground colour (useful for print() function)
10 RW
current TTY background colour (useful for print() function)
11 RO
Number of Banks, or VRAM size (1 = 256 kB, max 4)
12 RW
Graphics Mode
0: 560x448, 256 Colours, 1 layer
1: 280x224, 256 Colours, 4 layers
2: 280x224, 4096 Colours, 2 layers
3: 560x448, 256 Colours, 2 layers (if bank 2 is not installed, will fall back to mode 0)
4: 560x448, 4096 Colours, 1 layer (if bank 2 is not installed, will fall back to mode 0)
4096 is also known as "direct colour mode" (4096 colours * 16 transparency -> 65536 colours)
Two layers are grouped to make a frame, "low layer" contains RG colours and "high layer" has BA colours,
Red and Blue occupies MSBs
13 RW
Layer Arrangement
If 4 layers are used:
Num LO<->HI
0 1234
1 1243
2 1324
3 1342
4 1423
5 1432
6 2134
7 2143
8 2314
9 2341
10 2413
11 2431
12 3124
13 3142
14 3214
15 3241
16 3412
17 3421
18 4123
19 4132
20 4213
21 4231
22 4312
23 4321
If 2 layers are used:
Num LO<->HI
0 12
1 12
2 12
3 12
4 12
5 12
6 12
7 21
8 21
9 21
10 21
11 21
12 12
13 12
14 21
15 21
16 12
17 21
18 12
19 12
20 21
21 21
22 12
23 21
If 1 layer is used, this field will do nothing and always fall back to 0
14..15 RW
framebuffer scroll X
16..17 RW
framebuffer scroll Y
1024..2047 RW
horizontal scroll offset for scanlines
2048..4095 RW
!!NEW!! Font ROM Mapping Area
Format is always 8x16 pixels, 1bpp ROM format (so that it would be YY_CHR-Compatible)
(designer's note: it's still useful to divide the char rom to two halves, lower half being characters ROM and upper half being symbols ROM)
Text-mode-font-ROM is immutable and does not belong to VRAM
Even in the text mode framebuffer is still being drawn onto the screen, and the texts are drawn on top of it
Copper Commands (suggestion withdrawn)
WAITFOR 3,32
80·03 46 00 (0x004603: offset on the framebuffer)
SCROLLX 569
A0·39 02 00
SCROLLY 321
B0·41 01 00
SETPAL 5 (15 2 8 15)
C0·05·F2 8F (0x05: Palette number, 0xF28F: RGBA colour)
SETBG (15 2 8 15)
D0·00·F2 8F (0xF28F: RGBA colour)
END (pseudocommand of WAITFOR)
80·FF FF FF
--------------------------------------------------------------------------------
TSVM MOV file format
Endianness: Little
\x1F T S V M M O V
[METADATA]
[FRAME0]
[FRAME1]
[FRAME2]
...
where:
METADATA -
uint16 WIDTH
uint16 HEIGHT
uint16 FPS (0: play as fast as can)
uint32 NUMBER OF FRAMES
uint16 TYPE
byte[12] RESERVED
Type:
0: 256-Colour frame
1: 256-Colour frame with palette data
2: 4096-Colour frame (stored as two byte-planes)
4: iPF no-alpha indicator (see iPF Type Numbers for details)
5: iPF with alpha indicator (see iPF Type Numbers for details)
16: Series of JPEGs
18: Series of PNGs
20: Series of TGAs
21: Series of TGA/GZs
255: Every frame specifies the type
iPF Type Numbers (high bytes)
0..7: iPF Type 1..8
TYPE 0 FRAME -
uint32 SIZE OF FRAMEDATA
* FRAMEDATA COMPRESSED IN GZIP
TYPE 1 FRAME -
byte[512] Palette Data
uint32 SIZE OF FRAMEDATA
* FRAMEDATA COMPRESSED IN GZIP
TYPE 2 FRAME -
uint32 SIZE OF FRAMEDATA BYTE-PLANE 1
* FRAMEDATA COMPRESSED IN GZIP
uint32 SIZE OF FRAMEDATA BYTE-PLANE 2
* FRAMEDATA COMPRESSED IN GZIP
TYPE 16+ FRAME -
uint32 SIZE OF FRAMEDATA BYTE-PLANE 1
* FRAMEDATA (COMPRESSED IN GZIP for TGA/GZ)
TYPE 255 FRAME -
uint16 TYPE OF FRAMEDATA
uint32 SIZE OF FRAMEDATA
* FRAMEDATA
--------------------------------------------------------------------------------
TSVM Interchangeable Picture Format (aka iPF Type 1)
Image is divided into 4x4 blocks and each block is serialised, then the entire file is gzipped
# File Structure
\x1F T S V M i P F
[HEADER]
[Blocks.gz]
- Header
uint16 WIDTH
uint16 HEIGHT
uint16 HAS ALPHA
byte[10] RESERVED
- *.gz
uint32 UNCOMPRESSED SIZE
* PAYLOAD
- Blocks
4x4 pixels are sampled, then divided into YCoCg planes.
CoCg planes are "chroma subsampled" by 4:2:0, then quantised to 4 bits (8 bits for CoCg combined)
Y plane is quantised to 4 bits
By doing so, CoCg planes will reduce to 4 pixels
For the description of packing, pixels in Y plane will be numbered as:
0 1 2 3
4 5 6 7
8 9 A B
C D E F
Bits are packed like so:
uint32 SUBSAMPLING MASK (unimplemented; dont write this)
uint8 [Cg-Top Left | Co-Top Left]
uint16 [Y1 | Y0 | Y5 | Y4]
uint8 [Cg-Top Right | Co-Top Right]
uint16 [Y3 | Y2 | Y7 | Y6]
uint8 [Cg-Bottom Left | Co-Bottom Left]
uint16 [Y9 | Y8 | YD | YC]
uint8 [Cg-Bottom Right | Co-Bottom Right]
uint16 [YB | YA | YF | YE]
(total: 16 bytes)
If has alpha, append following bytes for alpha values
uint16 [a1 | a0 | a5 | a4]
uint16 [a3 | a2 | a7 | a6]
uint16 [a9 | a8 | aD | aC]
uint16 [aB | aA | aF | aE]
(total: 24 bytes)
Subsampling mask:
Least significant byte for top-left, most significant for bottom-right
For example, this default pattern
00 00 01 01
00 00 01 01
10 10 11 11
10 10 11 11
turns into:
01010000 -> 0x30
01010000 -> 0x30
11111010 -> 0xFA
11111010 -> 0xFA
which packs into: [ 30 | 30 | FA | FA ] (because little endian)
Reference in New Issue View Git Blame Copy Permalink