IO Registers: Serial Communication (1)

0x400_0120, 4, R/W, SIODATA32, SIO Data (Normal-32bit Mode; shared with below)
0x400_0120, 2, R/W, SIOMULTI0, SIO Data 0 (Parent) (Multi-Player Mode)
0x400_0122, 2, R/W, SIOMULTI1, SIO Data 1 (1st Child) (Multi-Player Mode)
0x400_0124, 2, R/W, SIOMULTI2, SIO Data 2 (2nd Child) (Multi-Player Mode)
0x400_0126, 2, R/W, SIOMULTI3, SIO Data 3 (3rd Child) (Multi-Player Mode)
0x400_0128, 2, R/W, SIOCNT, SIO Control Register
0x400_012A, 2, R/W, SIOMLT_SEND, SIO Data (Local of MultiPlayer; shared below)
0x400_012A, 2, R/W, SIODATA8, SIO Data (Normal-8bit and UART Mode)
0x400_012C, Not used

Development Setup

Status: Okay but could be better

Most parts of the Development Setup chapter are pure magic.

We should not attempt to fully document each tool involved. However, we should attempt to document a full list of the tools used and then point people to the appropriate manuals so that they can look into it if they want.

Similarly, we've got a few provided files, and we can explain why they say what they say, and point people to where they'd find out more.

Implement LLVM intrinsics for Div and Mod so that `/` and `%` work "normally" on the GBA

So, if we implement the correct special function, then we can make code like

let a = x / y;

Will suddenly magically work on the GBA.

#[no_mangle] extern "aapcs" fn __aeabi_uidiv(num: u32: denom: u32) -> u32
#[no_mangle] extern "aapcs" fn __aeabi_idiv(num: i32: denom: i32) -> u32

Question

Do we want division to magically work like that?

Personally, I think that division is so damn costly on the GBA that I want it to be called as a special function or even as a macro (which makes it look a little weird) just so that people remember that they're doing a weird and costly operation.

The Hardware Memory Map

Tutorial: Object memory 1d or 2d

TONC and GBATEK explain this concept rather poorly. We will need to ensure that we've got lots of pictures when we explain this feature in the book.

Improved setup instructions

More than one person has tried to build a "blank" project, which crashes because of missing eh_personality, or tried to use cargo build and had similar trouble.

Perhaps we can work on clarification

A text display system

We should walk the user through how they'd display a string using a bitmap font tilesheet and Mode0 graphics

Link people to the pixelfont editor so they can make their own font sheets easily.

bss end static

We want to add a way to get the address of the end of the BSS section that is filled by the linker. Something like this

extern {
  static __bss_end: ();
}

VolatilePtr

The current version of VolatilePtr<T> isn't the best. Obvious ways to improve include:

The derive attribute actually only derives if T has the trait in question, even though the pointer field itself will always support the requested traits regardless of what T actually is. We want to enforce that the traits in question are always present regardless of T.
We probably want to provide a way to iterate over volatile slots (such as for PALRAM).
We want to use NonNull so that the Option<VolatilePtr<_>> during the from the iteration don't need extra tag bits. Which also then means we have to store a PhantomData<Cell<T>> as well for invariance to hold, meaning that VolatilePtr<T> literals end up quite wordy, and we'd want some constructor methods.
We probably want more of the methods to be const if possible. That may require that we store NonZeroUsize and cast it into a *mut T at the last minute for reads and writes. This also requires some PhantomData<_>, to keep the type of the faked pointer tracked, though it could be T directly instead of needing to be Cell<T>.

Improve CI usage

So right now it only does cargo check and cargo check --release

We want to build all examples if possible. For this we need to setup devkitpro within the travis cache, which probably isn't too hard.
We want to be able to run tests so that we can write tests. Step 1 is to make the no_std tag on thr library be cfg_attr(not(test), no_std). Step 2 is to possibly cfg various lines so that things depending on the memory map only happen on the agb. I'm not sure we need tests for those things at all, but it'd be nice to not footgun.

Randomization

Some form of PRNG that's optimized to the GBA
Picking random values in a range and such too
Basically we should take randomize and make sure it works super well on the GBA and then use that.

Save to SRAM from IWRAM

GBATEK says that you should only save to SRAM with code executing from WRAM, not with code executing from ROM.

So, we need to describe how to do that.

Can we get a breakdown of the logic in the whole `crt0.s` file?

Right now there's a little commenting, but it's still kinda mysterious.

I think it'd be a good segment to add to the end of the "GBA Assembly" lesson if we put the entire crt0.s file with a comment on every line and a breakdown of why we're doing the different steps and stuff.

We copy .data to IWRAM but not .bss, is this just a legacy thing because .bss wasn't used at first?
Can we talk about what gbafix does exactly?
GBATEK says that IRQ and BIOS uses the top 256 bytes of IWRAM, and I see the part that sets the IRQ stack pointer, but it's kinda fuzzy how those three ARM instructions are setting the pointers, because it looks like the second block (user stack) would just overwrite what got set during the first block (IRQ stack)
How does that copy work? It looks like we're carefully setting things up and then calling CpuSet, correct? After that, the control flow just "falls through" into the next block and jumps to main, right?
Can we cover the control flow between "power on" and when we hit here? Particularly how swi 0 and swi 1 will interact with what crt0.s defines.

And any other notes and explanations you think a beginner would need!

Bitmap Video

BIOS Functions

CPU Control / Reset

Math

Memory Modification

Decompression Functions

0x10 BitUnPack
0x11 LZ77UnCompReadNormalWrite8bit ;"Wram"
0x12 LZ77UnCompReadNormalWrite16bit ;"Vram"
0x13 HuffUnCompReadNormal
0x14 RLUnCompReadNormalWrite8bit ;"Wram"
0x15 RLUnCompReadNormalWrite16bit ;"Vram"
0x16 Diff8bitUnFilterWrite8bit ;"Wram"
0x17 Diff8bitUnFilterWrite16bit ;"Vram"
0x18 Diff16bitUnFilter

Sound (and Multiboot/HardReset/CustomHalt)

Minimal Manual Interrupt Service Routine

Thanks to a bit of madness and a contribution from @aaaaaa123456789 of the gbdev Discord (ax6 on the Discord), it has been decided that, even if the ability to program an arbitrary ISR that's reusable within the crates ecosystem is not currently easy/possible, we can still hand code a basic ISR for just acknowledging a vblank, which allows us to at least use bios::vblank_interrupt_wait.

This is a stepping stone, not a destination.

But all we have to do is make a static array of u32 values, the raw opcodes of the ARM assembly we want, and then use the pointer to that as our interrupt handling pointer.

They kindly provided the handler code and the u32 values of said code for us:

  mov r0, 0x04000002 @e3a00381
  add r0, 0x200      @e2800f80
  mov r1, -1         @e3e01000
  strh r1, [r0]      @e1c010b0
  bx lr              @e12fff1e

IO Registers: Interrupt, Waitstate, and Power-Down Control

IO Registers: Keypad Input

0x400_0130, 2, R, KEYINPUT, Key Status
0x400_0132, 2, R/W, KEYCNT, Key Interrupt Control

Optimize non-DMA memory fills

For things like clearing the screen in bitmap modes we're currently using a thumb state u32 write but that's still not fast enough.

There is an assembly instruction for writing even more at once (stmia), which is what CpuFastSet uses, and we need to check if LLVM is generating this instruction or not.

If we get it going in user code instead of doing the bios call we save time on the mode switching from user to system and back.

GBA Book TOC Plan

Just a rough outline. The idea is that we'll cover topics by alternating(ish) between graphics and non-graphics topic until all the major stuff that isn't self-explanitory. Things like how particular bios functions work can often be better described in the crate docs, but the book (hopefully) should give a sense of what you might do with all the bits and bobs available to you.

Non-Bitmap Display Abstractions

Mode 0 (full tiled)
Mode 1 (one affine)
Mode 2 (two affine)

Minor fix of rt assembly.

From endrift, referring to the crt0.s

    ldr r1, =0x03FFFFFC
    str r0, [r1]

can be done in fewer bytes as

    mov r1, #0x04000000
    str r0, [r1, #-4]

this saves four bytes and one cycle

Move docs to gh-pages to avoid master merge conflicts

Can't link with `static mut`s

Trying to compile a program containing a (non-elided) static mut produces some delightful linker spew:

  = note: arm-none-eabi-ld: warning: cannot find entry symbol __start; defaulting to 0000000008000000
          `.bss._ZN16fox_flux_advance4test17h9ec3708eaa2e7c78E' referenced in section `.text._ZN16fox_flux_advance4step17hd2b45f0f3bd89611E' of /home/eevee/dev/fox-flux-advance.git/target/thumbv4-none-agb/debug/deps/fox_flux_advance-3341f37616403a6a.3y0pnfisrximx3xe.rcgu.o: defined
 in discarded section `.bss._ZN16fox_flux_advance4test17h9ec3708eaa2e7c78E' of /home/eevee/dev/fox-flux-advance.git/target/thumbv4-none-agb/debug/deps/fox_flux_advance-3341f37616403a6a.3y0pnfisrximx3xe.rcgu.o

Linkers aren't my area, but the problem seems to be that globals go in .bss sections, and those are dropped by the linker script. Adding this fixed it for me:

    .bss : {
        *(.bss .bss.*);
        . = ALIGN(4);
    } >iwram = 0xff

No idea if iwram is appropriate or not. Please let me know if not. ;)

Clear `examples-bak`

We have to clean out the examples-bak directory into either real code or throw it out entirely.

Does it spark joy?

IO Registers: LCD I/O Registers

0x400_0000, 2, R/W, DISPCNT , LCD Control
0x400_0002, 2, R/W, Undocumented - Green Swap
0x400_0004, 2, R/W, DISPSTAT, General LCD Status (STAT,LYC)
0x400_0006, 2, R, VCOUNT, Vertical Counter (LY)

0x400_0040, 2, W, WIN0H, Window 0 Horizontal Dimensions
0x400_0042, 2, W, WIN1H, Window 1 Horizontal Dimensions
0x400_0044, 2, W, WIN0V, Window 0 Vertical Dimensions
0x400_0046, 2, W, WIN1V, Window 1 Vertical Dimensions
0x400_0048, 2, R/W, WININ, Inside of Window 0 and 1
0x400_004A, 2, R/W, WINOUT, Inside of OBJ Window & Outside of Windows

0x400_004C, 2, W, MOSAIC, Mosaic Size
0x400_004E, Not used

0x400_0050, 2, R/W, BLDCNT, Color Special Effects Selection
0x400_0052, 2, R/W, BLDALPHA, Alpha Blending Coefficients
0x400_0054, 2, W, BLDY, Brightness (Fade-In/Out) Coefficient
0x400_0056, Not used

IO Registers: Sound Registers

Explain mGBA debug messages

https://gist.github.com/ketsuban/ec6b72b659221c1f0761a6e966083b41

Not sure where it goes in the TOC, I guess it fits as a non-video section

__clzsi2

#[no_mangle]
pub unsafe extern "C" fn __clzsi2(mut x: usize) -> usize {
    let mut y: usize;
    let mut n: usize = 32;
    y = x >> 16;
    if y != 0 {
        n = n - 16;
        x = y;
    }
    y = x >> 8;
    if y != 0 {
        n = n - 8;
        x = y;
    }
    y = x >> 4;
    if y != 0 {
        n = n - 4;
        x = y;
    }
    y = x >> 2;
    if y != 0 {
        n = n - 2;
        x = y;
    }
    y = x >> 1;
    if y != 0 {
        n - 2
    } else {
        n - x
    }
}

"I just stuck this in a shim.rs file. Eventually with any luck compiler-builtins will provide one which isn't written by me googling for a C implementation and quickly translating it to Rust." -- Ketsuban

remove the book from this repo

VolatilePtr::offset

We should add an offset method.

Ubsan says that for the purposes of IO Register stuff on the GBA it doesn't need to be wrapping_offset, so we'll just use normal offset.

See about moving to normal GCC binutils

Apparently we don't really need to specifically use devkitpro's ARM binutils, we can probably just use totally normal GCC binutils for ARMv4TDMI.

Currently we use devkitpro for the assembler and the linker.

We can't use LLVM's own linker because it has a v5 minimum because it uses the BLX instruction.

Still, it's worth it to give it a try using more a toolchain that's even more common than we're currently using.

alignX structs / macro to allow for aligned include_bytes!() usage

Thanks to oli for suggesting this style

#[repr(align(4))] struct Wrapper<T>(T);

pub const A: &[u8] = &Wrapper(*include_bytes!("file.img")).0;

transition to `cargo-make` when possible

Ketsuban suggested that we try out cargo-make

https://github.com/sagiegurari/cargo-make

It seems super cool, and if we can replace our build.bat file with something that'll work more properly on all platforms it'll be good.

Optimize Mode 3/4/5 line drawing?

We can probably make the line drawing faster by special casing some things.

IO Registers: Serial Communication (2)

0x400_0134, 2, R/W, RCNT, SIO Mode Select/General Purpose Data
0x400_0136, IR, Ancient - Infrared Register (Prototypes only)
0x400_0138, Not used
0x400_0140, 2, R/W, JOYCNT, SIO JOY Bus Control
0x400_0142, Not used
0x400_0150, 4, R/W, JOY_RECV, SIO JOY Bus Receive Data
0x400_0154, 4, R/W, JOY_TRANS, SIO JOY Bus Transmit Data
0x400_0158, 2, R/?, JOYSTAT, SIO JOY Bus Receive Status
0x400_015A, Not used

IO Registers: Timer Registers

0x400_0100, 2, R/W, TM0CNT_L, Timer 0 Counter/Reload
0x400_0102, 2, R/W, TM0CNT_H, Timer 0 Control
0x400_0104, 2, R/W, TM1CNT_L, Timer 1 Counter/Reload
0x400_0106, 2, R/W, TM1CNT_H, Timer 1 Control
0x400_0108, 2, R/W, TM2CNT_L, Timer 2 Counter/Reload
0x400_010A, 2, R/W, TM2CNT_H, Timer 2 Control
0x400_010C, 2, R/W, TM3CNT_L, Timer 3 Counter/Reload
0x400_010E, 2, R/W, TM3CNT_H, Timer 3 Control
0x400_0110, Not used

VRAM + Display Mode abstractions?

It's quite difficult to make any useful abstractions over VRAM for all possible video modes, but I think that we can at least do a good effort if we focus on just one mode at a time.

My first thought is that we can make a sub-module for each display mode and then fill it with display helpers and constants relevant to that mode.

Are there other good options? I also had the idea to try and make TiledGraphics and BitmapGraphics traits that we implement onto empty structs that represent each display mode, but I think even among Tiled and Bitmap modes there's not quite enough similarity to make that very useful.

Volatile

Clear `book/src-bak`

Anything in the book/src-bak needs to be sorted into a real part of the book or thrown out

Does it spark joy?

8x8 fonteditor

https://www.min.at/prinz/o/software/pixelfont/

Convert C test roms to Rust

There is a set of C test roms: https://github.com/mgba-emu/suite

We can use them as part of a usability and coverage test. Basically we want to write the C test rom in Rust as rustily as possible, and then make sure the crate supports thay code well, ideally with zero unsafe needed in the test rom code.

IO Registers: DMA Transfer Channels

IO Registers Intoduction

Have a way to flush MGBADebug / clear the buffer

REMOVE our local clz

now that rustc itself has a version, our version blocks all builds XD

Thumb / ARM switch notes

RandomThumb:
  bx pc
  nop

  .arm
RandomARM:
  @code here

also investigate umlal instruction

Heap Management?

I see no sign of dynamic allocation in source files and all examples are compiled with no_std flag, causing no built-in allocator. So how heap memory is managed in this crate?

Inline more

A lot of functions / methods aren't inlined with #[inline] when it might be beneficial to do so. For example I think it's good to inline the new method when using the newtype macro.

rust-console / gba Goto Github PK

gba's People

Contributors

Stargazers

Watchers

Forkers

gba's Issues

Question

Recommend Projects

Recommend Topics

Recommend Org