At this point in development, MSVC is not generating optimized
code for ANESE, and struggles to hit 60 fups.
Clang makes beautifully performant builds though :D
golly gee whiz what a day.
This morning, I seem to have gotten sprite rendering working.
It's not super _accurate_, but hey, it renders basic stuff okay,
so i'm happy.
Background rendering is proving to be a annoying beast to tackle,
and has been causing me quite a bit of headache. Even now, it's not
working just right, and honestly, i'm running out of energy to try
to debug it today.
I have a feeling that my PPU <-> CPU bridge isn't working super
properly, since I feel as though I _should_ be able to run simple
games using my "draw debug nametable to main screen" hack, but
it still doesn't seem to be the case...
Maybe if I implement sprite-0 hit, it'll finally work...
Anyhoo, yeah. Work's chugging along.
I just want to play supah mario bros before new years hits, is that
so much to ask?
this isn't going well.
i've decided to forget accuracy for the moment, and to focus on
just getting the damn thing working with simple stuff, like the
Zelda title-screen demo, or Donkey Kong.
But fuck me man, this shit is complicated.
I'm going to bed now, and hopefully, next time I work on this,
i'll be able to get sprite rendering working properly.
hell, maybe i'll just scrap that, and instead focus on rendering
the background properly. I have a feeling that's going to be
a bit easier...
Right now, I really want to give up, and call it quits on this
project, because holy crap am I getting annoyed.
But then I remember that one day soon, everything is going to
work, and all this effort will have been worth it.
I hope that day comes soon.
holy moley donkey kong is actually rendering nametables golly gee
whiz that's amazing! I mean, nothing really works yet per-se, but
this is some really great progress!
I could try to make a OAM debug view, but I think i'll hold off on
that for now. Instead, i'll try to actually begin implementing the
core render loop.
I wasn't planning on reworking interrupts today, but one thing led
to another, and... yeah.
All I really wanted to do today was get a Palette Table debug view,
but for some reason, it isn't being populated! I had a suspicion
that maybe implementing interrupts would make something click, but
alas, interrupts are in, and no data is being written to the
palette tables :(
I'm just going to leave it be for now, and hope that as more of the
PPU comes together, it will just start working.
i'm still not entirely sure how the hell i'm supposed to write the
core render loop, but hey, at least I can see some tiles!
my plan right now is to slap together a couple more debug windows
for the various parts of the PPU's memory map, and get a feel for
how all the graphics are layed out in memory.
I kind of went down a deep rebbit hole.
As I started to implement the ppu_mmu, I realized that I needed to
finish my mapper, and when I did that, I realized that I didn't
fully understand how VRAM worked, and once I figured that out I
realized that to make my life simpler, I had to rework how some
interfaces works.
I could keep going, but you get the point.
But hey, I think the code is a lot more robust now, so that's good!
honestly, this is just procrastination before I start the PPU.
Golly, that's going to be difficuly, er, that is... fun! Yeah!
It's gonna be so fun! so much fun...
I'll tell ya, figuring addressing modes is hard.
I only really understood them today, after something clicked in my head.
The whole point of addressing modes isn't to provide instructions with
the specific data value for their operation, but to provide addresses
at which instructions can read desired data from!
Basically, I was trying to 'dereference' the address in my addressing
mode decoder function, when in reality, all I needed to do was pass
the address down to instructions, and let them dereference it
themselves (on a case-by-case basis)
I'll tell you one thing, this whole project sure has been a learning
experience :)
Yeah, the fancy way of handling instructions looked annoying to
deal with. Maybe i'll revisit the concept at a later date, but
for now, using a classic instruction lookup table aughta do fine.
In terms of CPU architecture, I think i'm pretty happy with how I
set things up. Sure, there are some parts of the code that i'm not
super happy about, but as a first draft, I think it's not bad. I'm
sure that after implementing more of the 6502, i'll get a better
idea of how to clean up the code.
What's left to do with the CPU?
- Implement the rest of the instructions (duh)
- Implement interruprs (aaaahhh)
And hopefully, once the CPU is passing nestest.nes, I can start
working on the rest of the NES 😄
Although i've tried to keep away from peeking at the implementations
of other NES emualtors, the few glances I have seen all seem to use
a big, dumb lookup table to decode opcodes (i.e: determine the
instruction and the addressing mode)
I thought that there must be a better way, since after all, the
actual hardware does it quite compactly :)
With the help of http://www.llx.com/~nparker/a2/opcodes.html, I
explored the 6502 ISA and tried to find bit patterns that would
give me a clean, compact way to decode instructions.
Alas, the few exceptions to the rule that I am finding are proving
to be quite annoying to work around...
As such, i'm going to go to bed today, and reconsider this approach
tomorrow.
i.e: my current way of encoding opcodes is unsustainable.
I'm just trying to get a feel for how the various addressing modes
work, and how instructions tend to operate.
