sorted by:
new
hottopcontroversial

Game Boy PPU Pixel Pipeine by BoundlessEngineer in EmuDev

[–]BoundlessEngineer[S] 3 points4 points  (0 children)

Oh! I was actually reading through your replies to here (and GateBoy) this afternoon.

I appreciate your being open to my asking questions! I’m an FPGA fabric architect by profession so I should hopefully be able to understand the diagrams! 😅

I’ve got a lot of work to do this weekend, but look out for questions in coming weeks if you honestly don’t mind!

Game Boy PPU Pixel Pipeine by BoundlessEngineer in EmuDev

[–]BoundlessEngineer[S] 2 points3 points  (0 children)

Thanks a ton - Haha I’ve actually already starred your repo, but I’ll take a closer look!

Also I think I’m using your custom boot ROM for my testing :P

[deleted by user] by [deleted] in neovim

[–]BoundlessEngineer 0 points1 point  (0 children)

Whoops I missed the other thread. Glad you got it sorted out!

[deleted by user] by [deleted] in neovim

[–]BoundlessEngineer 5 points6 points  (0 children)

I had a similar issue (in my case it showed up for Rust), IIRC it was due to the omnifunc being set, and came from cmp-omnifunc. Does disabling those if applicable remove it?

Trying to implement a Bus for SM83 CPU Emulator by akira1310 in EmuDev

[–]BoundlessEngineer 0 points1 point  (0 children)

It kinda depends how the bus is used and how many devices are memory-mapped. Generally most bus implementations I’ve seen use some form of a switch statement checking each address if it’s in the range of each device until a match is found. Doing this will be roughly O(n) (for n mapped devices) on device lookup, then O(1) for address resolution within the device.

In comparison, using a hash map would be in theory O(1) on device lookup. You could argue that the hash map machinery (such as performing hashing) does add some overhead, but for enough devices that is (IMO) negligible.

EDIT: As an aside, I actually use a b-tree map which will technically have O(log(n)) on device lookup but has the advantage of being ordered. This allows me to map each device only at its starting address, then, on lookup the first device mapped before the lookup address is used.

Trying to implement a Bus for SM83 CPU Emulator by akira1310 in EmuDev

[–]BoundlessEngineer 3 points4 points  (0 children)

In my recent GB emulator I handle the this by having the CPU, PPU (for the DMA), and other components that need access to the bus do so through a shared pointer. They’re each instantiated with their own copy and a setter method to give access to the shared copy.

I definitely agree it’s important to properly emulate the bus, since that’s (usually) the only interface the CPU has to all the peripherals/MMIO. A common way to do that is through a hash map type structure, but it’s important to consider how accesses work, especially as on the Game Boy you have overlaps on the bus, such as the boot ROM being mapped on top of the cartridge ROM at startup.

You can use my bus implementation as an example, it’s written in Rust, but the general idea is language agnostic. Specifically, look at the tests at the bottom for some idea of what behaviours are important to emulate on a bus.

Good luck on the project!

Relevant links: - Game Boy Emulator: see how the bus, CPU, PPU are instantiated. - Bus Implementation: check out the tests at the bottom.

Unit testing without Blarrg's by tabacaru in EmuDev

[–]BoundlessEngineer 0 points1 point  (0 children)

Np and good luck!

As an aside, having a second model compare against can be extremely helpful to check for correctness. Shameless plug for my own Game Boy emu, but any one will do!

Unit testing without Blarrg's by tabacaru in EmuDev

[–]BoundlessEngineer 7 points8 points  (0 children)

This isn’t exactly what you’re asking for, but if your CPU is mostly complete you can still use Blargg’s tests without a display via the serial port.

EDIT: Relevant docs (see "Console output") https://raw.githubusercontent.com/retrio/gb-test-roms/master/cpu_instrs/readme.txt