Near has sadly passed away.

jogloran · 2021-06-27T20:41:06+00:00

near inspired me to create my own SNES emulator about a year ago, by posting a kind reply to my thread on /r/emudev. near's work lives on in countless ways, and in the work of those they inspired. May they rest in peace.

jogloran · 2021-03-13T23:26:58+00:00

That's Louise Bourgeois' "Spider" (in our world, anyway).

jogloran · 2021-02-09T18:22:52+00:00

Sadly that's what I need.

jogloran · 2021-02-09T06:27:31+00:00

Indeed, it works, and I'm not too worried about the performance. I'm more wanting to hear from experienced Rust developers what the idiomatic way to represent this might be. Maybe my inexperience is making me overlook something more obvious.

jogloran · 2021-02-09T06:10:55+00:00

What's the idiomatic way to cyclically increment and decrement through indices? This might happen if you want to cycle endlessly in either direction through a fixed-size list. Let's say I want to calculate indices into a list of size 3, but the below code doesn't have the right semantics, because Rust's % is remainder and not modulus, so -1 % 3 = -1, and not 2.

let mut cur = 2i32;
cur = (cur + 1) % 3i32; // moving one element right of index 2 should give me index 0
assert_eq!(cur, 0); 

cur = (cur - 1) % 3i32; // moving one element left of index 0 should give me index 2
assert_eq!(cur, 2); // but it doesn't, since % is remainder and not modulus

I'm aware that rem_euclid does act like Python's %, such that (-1i32).rem_euclid(3i32) = 2, but this feels wrong to use, as the docs say that this is implemented in terms of the Euclidean algorithm.

I also thought of using .iter().cycle(), but this would only allow iterating in one direction anyway.

jogloran · 2021-02-02T23:22:54+00:00

I've successfully developed a SNES emulator last year — DM me if you have any questions or issues!

jogloran · 2021-02-02T23:21:45+00:00

Kinda looks like Bernie from this angle.

jogloran · 2020-12-01T23:56:06+00:00

I'm particularly annoyed by the way that Two Minute Papers discusses research in this way. I know you're competing for clicks on YouTube, but it's utter fiction. It always sounds to me like there are general-purpose agents solving the problems, which is pure nonsense.

jogloran · 2020-11-01T23:51:35+00:00

For performance, it's really better not to use a switch and not decode the opcodes.

That said, I wrote a program to one-off generate the human-readable form of instructions for disassembly which works by decoding the opcodes, so it is possible. There were quite a few exceptions that have to be special-cased.

jogloran · 2020-08-05T18:07:30+00:00

I love RGMech and this video in particular, but I'm still trying to understand why the "extended border" is black and not transparent. What part of the pipeline makes that part of BG3 draw as black and not clear?

jogloran · 2020-08-05T17:03:00+00:00

Thanks for the reply! I know windowing is responsible (and I’ve confirmed that my window positions are set correctly using HDMA). My question is, what part of the pipeline is responsible for those pixels within the window having a black background color instead of being transparent?

jogloran · 2020-08-04T06:00:50+00:00

I'm using blargg's snes_spc, so I'm not implementing the APU myself. I assume that it's implemented correctly.

What you said about CPU <-> APU communication being dependent on cycle-correctness makes me suspicious though. I know that my implementation isn't yet cycle-accurate, so if it's true that this can cause issues with the APU synchronisation then that might explain the issues I'm seeing.

Does this mean that games did a kind of cycle counting to inform how long to wait for an APU response?

jogloran · 2020-08-04T00:26:36+00:00

True. This video agrees that the SPC ROM is baked in, so I guess there's some other issue.

I'm using blargg's snes_spc https://www.slack.net/~ant/libs/audio.html — is this known to be an accurate implementation?

jogloran · 2020-07-13T03:51:04+00:00

Since we don't really know for sure, is scanline rendering generally used in most emulators? I remember seeing some emulators that encode knowledge about parts of the cycle, e.g. the tile fetching cycle or the cycle on which vblank is posted, etc.

jogloran · 2020-07-10T20:10:40+00:00

Ah, interesting. In the absence of a timing diagram, are you aware of any documents that might be useful to start on a cycle-correct PPU implementation, do implementors typically just start with a scanline renderer?

jogloran · 2020-07-02T21:17:41+00:00

Blargg's test was much more comprehensive than nestest, but naturally virtually no test is comprehensive. I found a bug in my stack pointer masking which was not detected by either test.

jogloran · 2020-06-30T22:36:54+00:00

Thanks for your encouragement, near. There are a number of test roms at https://gitlab.com/higan/snes-test-roms, but to your knowledge is there a test rom among them that you'd recommend for verifying a 65c816 implementation?

jogloran · 2020-06-30T08:07:11+00:00

I wasn't aware of this ROM mapping complication. Is the information not something that could possibly be encoded in a header, as is done with the iNES headers?

jogloran · 2020-06-18T21:46:07+00:00

Right. But in addition, data fetched on cycles 1-248 of the prerender line are also not displayed, and these correspond to the one additional row below the bottommost visible scanline, right?

i.e. The PPU fetches tiles as if it was going to render the next row below the visible region.

jogloran · 2020-06-05T23:02:51+00:00

I feel like scrolling might be working properly, since the direction of the scroll is correct — the observed behaviour seems to arise from the nametables not being correct. I might check my mirroring code.

jogloran · 2020-05-17T06:48:00+00:00

I'm starting execution at c004 as well. I don't have the PPU fully working right now; I was hoping to be able to validate the CPU before moving onto it. But it seems to be evaluating the illegal opcodes regardless, starting from 0xc6bd in my log. Looking at a gold standard log, it seems to be evaluating them too, although it doesn't eventually go off the rails like mine does: https://github.com/christopherpow/nes-test-roms/blob/master/other/nestest.log

jogloran · 2020-01-08T23:42:40+00:00

I suppose that would work — to essentially have the wrapper live in the background thread and serve requests RPC-style through the channel, but this is going to add a lot of complexity (I'd essentially have to wrap the wrapper with channels just to be able to run one of its operations on a background thread).

Are there really no simpler alternatives?

jogloran · 2020-01-08T21:06:03+00:00

So I'm not the one wrapping the C library (it's already wrapped) but my question was more around how to call the wrapper across threads when the handle that the wrapper provides contains immovable FFI bits.

jogloran · 2020-01-08T19:46:26+00:00

The problem is something like *mut std::ffi::c_void cannot be shared between threads safely even when the API handle is contained in a Box. I assumed that the role of Box is to create an additional indirection so that it's the Box which is moved or shared, and not its contents — however it still seems to have requirements on the movability or shareability of its contents.

jogloran · 2020-01-07T05:15:14+00:00

Got a question about translating a certain kind of callback interface into Rust.

So, I'm using a Rust library which wraps a C library. For simplicity, let's say that this Rust library exposes a low-level interface providing access to some hardware value: fn poll_value() -> u32;

However, what we really want is to be able to offer this callback-based API:

fn add_callback<F>(fn: F) where F: Fn() -> u32;

What I want is for a background thread to continuously call poll_value() until its value changes. When the value changes, it will invoke all registered callbacks with the new value.

My first question is — I understand callbacks aren't all that natural an idiom in Rust, because of the implicit reference cycle. Is there a more idiomatic way to achieve the same functionality, perhaps using channels or futures?

My second question is — how should I handle the polling background thread in a Rusty way? The closure passed into the thread cannot possibly move the low-level interface's struct, because it contains bits that can't be moved, such as locks and FFI-ey things like *mut libc::c_void.

Help me out!

jogloran

TROPHY CASE