pubby / nesfab Goto Github PK

dont know why this is happening specifically but it seems like some of the examples (for example, hang_glider) does absolutely nothing when trying to run its cfg file through nesfab while others (hello_world in this case) work perfectly fine.

This program correctly prints an A-B pattern to the screen.

vars
    U[240] level_tiles

fn bar(U index) U
    for U x = 0; x < 16; x += 1
        U tile = level_tiles[index]
        index += 1
        {PPUDATA}(tile)
        {PPUDATA}(tile)
    return index

fn foo()
    {PPUADDR}($20)
    {PPUADDR}($00)
    U index = 0
    for U y = 0; y < 15; y += 1
        index = bar(index)
        index -= 16
        index = bar(index)
    {PPUSCROLL}(0)
    {PPUSCROLL}(0)

mode main()
    for U i = 0; i < 240; i += 1
        level_tiles[i] = i & 1
    foo()
    {PPUMASK}(%00001010)
    while true
        nmi

chrrom
    U[8]($00, $38, $44, $44, $7c, $44, $44, $00)
    U[8]($00)
    U[8]($00, $78, $44, $44, $78, $44, $78, $00)
    U[8]($00)

By moving the code out of bar() and into foo(), the pattern is no longer printed correctly. Something is going wrong regarding increments to the index variable.

vars
    U[240] level_tiles

fn foo()
    {PPUADDR}($20)
    {PPUADDR}($00)
    U index = 0
    for U y = 0; y < 15; y += 1
        for U x = 0; x < 16; x += 1
            U tile = level_tiles[index]
            index += 1
            {PPUDATA}(tile)
            {PPUDATA}(tile)
        index -= 16
        for U x = 0; x < 16; x += 1
            U tile = level_tiles[index]
            index += 1
            {PPUDATA}(tile)
            {PPUDATA}(tile)
    {PPUSCROLL}(0)
    {PPUSCROLL}(0)

mode main()
    for U i = 0; i < 240; i += 1
        level_tiles[i] = i & 1
    foo()
    {PPUMASK}(%00001010)
    while true
        nmi

chrrom
    U[8]($00, $38, $44, $44, $7c, $44, $44, $00)
    U[8]($00)
    U[8]($00, $78, $44, $44, $78, $44, $78, $00)
    U[8]($00)

In the example, we have a collection of pointers and casted pointers that are both initialized in their vars block and in the init_globals method. Using only the first initialization causes both the normal and casted pointers to agree in value when printed, but calling init_globals at the start of main gives different results. This is tested with both data and omni data blocks.

test.cfg.txt
test.fab.txt

I'm attempting to write my first NES app with this project. It should be said that I have no prior NES developing experience, so my code may not be great.

I found a situation where the compiler just seems to hang. I made a GitHub repo with repo code.

https://github.com/brckelly/nes-sample

Commit 484acc499fdcbd3600af71fc6a032ea42097bbd7 will show the issue.
Appling commit df697f8d192caf2adf668ebc4a65a74b8af0b7ac seems to be a work around.

Like I said, I could be doing something wrong, but it feels like there is something with the compiler. Thanks for taking a look.

It might be helpful to have built-in keywords for the APU registers as a parallel to the PPU registers.

I can compile the hello__world file by dragging the cfg to the nesfab.exe that i got from the binary release, but the other 2 examples (the text example and hand_glider), will not compile if I drag their cfg files.

Operating System: Windows 11 (21H2)
Lenovo 5000 series Laptop
Processor: AMD Ryzen 5
Ram: 16GB

`terminate called after throwing an instance of 'compiler_error_t'
what(): game.fab:14:19: error: Int value of 65302 cannot be represented in type U. (Implicit type conversion)
14 | ct U dead_color = $16
^^^
note: Add an explicit cast operator to override.

Aborted (core dumped)
`

I also got a bunch of warnings while compiling the compiler.

Hi,. I was wondering, is there a way to see the assembly code generated by NESFab compiler? I know I could use a decompiler, but maybe there's a way already to see what's generated

When attempting to read values from a UU[] which has been initialized in a vars block (say UU[] test = UU[]($1234, $5678, $9ABC)), the result is a jumbled collection of the bytes present (e.g. right now test[0] = $5634). I have observed similar issues with the UUU[] type, and potentially others.

Attached is a small program that reproduces the issue for UU[]s (along with a tileset that will be embedded lmao). Since I can't attach .fab or .cfg files, they are included with .txt appended.

test.cfg.txt
test.fab.txt

On the offchance that somebody needs a workaround in the meantime, re-initializing the values in a function/mode (e.g. at the start of main) appears to work properly. Continuing the example above, you could later set test[0] = $1234 and so on, and this works as intended.

In mmc3.fab, commit 344fd87 introduces a usage of the __mapper_detail pseudo-register.

This breaks the scanline_irq example, which uses mapper 189 together with mmc3.fab.

Given how similar mapper 189 is to MMC3, I would have expected 189 to support the __mapper_detail pseudo-register, too. However, mapper 189 seems to be missing in the switch statement for detail_size:

That causes the following error when building the scanline_irq example:

$ nesfab scanline_irq/scanline_irq.cfg
../../../../../../../usr/share/nesfab/lib/mapper/mmc3.fab:24:7: error: Mapper 189 lacks __mapper_detail.
 24 |     {&__mapper_detail}(bank_select) // Shadow register used by the runtime.
            ^^^^^^^^^^^^^^^

With the exception of bankswitch_addr, shouldn’t MAPPER_189 take the same switch branch as MAPPER_MMC3 throughout mapper.hpp?

This program:

struct Foo
    U bar
    U baz

ct Foo[1] quux = Foo[1](Foo(0, 0))

mode main()
    // force a read of the data in the struct
    {$8000}(quux[0].bar)
    while true
        nmi

Produces this assertion error:

nesfab: src/eval.cpp:6185: ssa_value_t eval_t::from_variant(const ct_variant_t&, type_t) [with do_t D = eval_t::COMPILE; ct_variant_t = std::variant<ssa_value_t, std::shared_ptr<ssa_value_t []> >]: Assertion `num_members(type) == 1' failed.

I figure that this should be a compiler error if this is in fact not allowed, unless the assertion is incorrect.

To reproduce, build the included mmc3 example, but replace the mapper with 189. The reset handler will be at $8161, but it should* be somewhere in $E000-$FFF9. This was tested with the most recent commit on b1.4.

*note: i actually don't know if this is true for 189. my current project currently builds the rom using mapper 189, then patches the header to make it mmc3 to keep the rom size small, so i desire mmc3 behavior here. having the reset vector pointing in a bad location seems to affect kryzsiocart users.

Should be able to reproduce the error with any non-standard unicode char, e.g. // should throw error ·.

Context: I use unicode chars in charmaps to make backgrounds look nice (which works perfectly), so commenting them out comes naturally from there

I'm certainly open to the idea that I'm doing something wrong, but I can't even get the hello world app to compile. I am running on ARM64 (Linux on Chromebook).

brckelly@penguin:~/src/nesfab$ ./nesfab ./examples/hello_world/hello_world.cfg 
examples/hello_world/main.fab:15:13: error: Int value of 2044 cannot be represented in type U. (Implicit type conversion)
 15 |     {$4015}(%100)
                  ^^^^
note: Add an explicit cast operator to override.

I cloned the repo today at hash: 45b8ca5

Any help you can give would be helpful. Thanks.

Will you make a Mac binary?

This code produces a stack overflow in build_incoming in asm_graph.cpp.

vars
    U[16] level_tiles

fn foo()
    {PPUADDR}($20)
    {PPUADDR}($00)
    U index = 0
    for U y = 0; y < 15; y += 1
        for U x = 0; x < 16; x += 1
            U tile = level_tiles[index]
            index += 1
            {PPUDATA}(tile)
            {PPUDATA}(tile)
        index -= 16
        for U x = 0; x < 16; x += 1
            U tile = level_tiles[index]
            index += 1
            {PPUDATA}(tile)
            {PPUDATA}(tile)
        index -= 16
    {PPUSCROLL}(0)
    {PPUSCROLL}(0)

mode main()
    while true
        foo()
        nmi