nesdev.org

bsnes used to have what was pretty much the best-in-class SNES debugger, but when byuu scrapped the old QT interface it went away.

So I think what calima means is, perhaps Revenant's fork of byuu's GB emulator will save us all

BGB is what I use, and I can confirm it works well in Wine. I don't think any open source emulators have debugging tools that are comparable.

The principle of charity would suggest that Kismet meant precisely "Expecting a sub-99$ FPGA unit [for hardware with the complexity found on an SNES]".

Not sure if this is what you're asking, but -3 to -1 inclusive are LDH [$46], A. They're not (usually) externally visible, but internal state changes happen during each constituent cycle of the instruction - the CPU isn't just sitting around waiting N cycles and then instantly executing the instruct...

In fact it's 39 * 16 + 36 = 660 cycles in HRAM, isn't it? Because the final JR isn't taken (- 4), but there's the LD A (+ 8) and a RET (+ 16). That still comes in under 160ms though. So what you're saying makes sense - the pandocs seem to miscount the cycles for the JR as justification, but the offi...

I feel like quitting nesdev outright, but I do not have a potential audience anywhere else. [...] definitely not from any other independent game development community. Why not? I've always found the indie game community very welcoming. Anyway, this is a really common problem that I'd guess almost e...

Another real neat trick you can do by carefully adjusting the scroll during hblank interrupts is vertical scaling.

Growing up in Ontario, Canada, all of our school computers were Unisys ICON systems up to a depressingly late date. The Wikipedia article says that it "disappeared" after the late 80s, but that's not true - I remember programming in Logo on it in Grade 5, and that was the late 90s! For wha...

The SNES has a screen brightness register; that's what most games would probably used to darken the screen.

Nevertheless, the idea is the same: the emulator precomputes the darkened palette and uses it to draw the screen rather than doing a floating point multiply on each pixel after-the-fact.

Yeah, as part of telling you why your code is slow it'd help if we could see your code

They're asking how emulators produce 60fps images with transparency, scaling, rotation, etc. so quickly on PC hardware without hardware acceleration, not how SNES games do it (with the SNES' hardware acceleration, of course).

I've never written an emulator myself, so I'm afraid I could only guess.

Lunar is strictly turn-based and has light positional elements.

I understand what you're saying in general but you maybe picked the worst possible example? Aside from the opening theme, most of Metroid 2's (incredible) soundtrack is atonal noise.

If assembler is fine I'd recommend RGBDS. It was apparently used in commercial GBC games back in the day since it's supposedly more versatile then Nintendo's official one. And it has a fork that is still maintained . It has a powerful macro language but also the syntax may be considered a bit weird...

Yes, SDCC is AFAIK the only real choice. A generic Z80 compiler wouldn't come close to working - the instruction sets are far too different. The GB "Z80" is much more like a souped-up 8080, although it's not source compatible (I can't tell - it might be binary compatible [1] [2] ). I know ...