that's it then, the final piece.
You can play games, record scenes, and boot games back up with the
recorded map.
It's not perfect, _far from it_, but it works!
There is still a lot of work to do, improving heuristics and such,
but I think wideNES is at a point where it can be merged into
master and shown off a bit :)
exciting!
gui.cc is now _almost_ module agnostic, which is awesome!
The last thing to do is to figure out what's the best way to route
input from the wideNES window to the main window, as the current
solution of _always_ passing input to the emulator is jank af.
I also finally got a ROM loading / unloading solution i'm happy
about. essentially, load/unload have become utility methods on the
shared-state struct.
no more SDL in ANESE core!
Also, with this commit, I can merge back into master, since wideNES
is hidden behind a flag :)
Before I do that though, a bit of cleanup is in order :)
If a human can figure out which parts of a screen to chop, why
can't wideNES do it automatically? Well, it can! sort of...
I implemented a couple of heuristics that use the state of the PPU
and the Mapper to "guess" what padding values make sense.
For now, I only have 2 implemented:
1) Check if the bgr-mask column is enbled on PPUMASK
- if so, add 8px of padding to the left of the screen
- many games that mask the left also have artifacting on the
right, so mask off 8px on the right too.
2) Check what scanline the Mapper IRQs happened on
- mask-off the rest of the screen
- many games use the Mapper IRQ for status-bars (smb3, kirby)
Now, these are not perfect heuristics by any means, with exceptions
rampant. eg: Lode Runner doesn't have any graphical artifacting on
the right of the screen. eg2: MegaMan IV uses the IRQ for different
reasons, unrelated to status-bars.
Nevertheless, they do a decent job with many games, smb3 and MC Kids
work flawlessly. Moreover, Metroid and Super Mario Bros work great
too, automatically having the entire screen captured (no padding)
While implemeting this feature, I decided to cleanup how I was
reading the NES's state, and implemented a basic Callback system,
enabling arbitrary methods to hook into important parts of the NES
lifecycle. eg: I added callbacks whenever a mapper fires an IRQ,
and a mapper whenever a PPU frame finished drawing (scanline 240)
This had the happy side-effect of fixing my smearing issues, as it
makes a lot more sense to sample the NES's state _before_ the NMI
handler happens, as that state the one that resulted in the current
frame! Just like that, every game I tested worked flawlessly, no
smearing to be found!
Also, this lays a much more solid groundwork for implementing a
proper debugger! It should be easy to take the nastyness that is
ppu_debug.cc and extract it into it's own GUI module! That way,
there will be _no_ state of SDL in ANESE core!
I still haven't figured out the smearing issue, but I _did_ figure
out how to greatly-improve compatibility with many titles!
I added the ability to "pad" the screen, cutting-off any artifacts
at the edge. This means that with a bit of tweaking, games like
SMB3 and MC Kids work near flawlessly!
It _should_ be possible to guess "good" padding values for games by
using some heuristic that relies on current mirroring mode, scroll
direction, and if the PPUMASK is on...
I also updated the README some more, putting a "teaser" for wideNES
on the main page, but splitting off the details into it's own page.
Yeah, it's about time I get wideNES out of the main NES module, it
was starting to make a mess. Instead, wideNES now has it's own
window, with it's own SDL rendering context.
I'd actually like to refactor the emu module some more, possibly
splitting it into sever different ones. eg: emu_core for the main
NES console + frameloop, emu_controls for handling input / movie
support, and take the file i/o and throw that into the menu module.
I'll get around to it eventually :)
Plus, if I can modularize things a bit more, I can merge this
branch into main, and put the entire wideNES module behind a flag!
-----
smearing.
I'm very confused.
I tried a bunch of stuff, and one thing I stumbled on was that if I
use the _last_ frame's scroll values, then I can fix smearing in
some games (smb2, metroid) at the expense of adding it to other
games (smb1)
I'm really not sure why that's happening, but i'll try investigate.
-----
Oh, and I added basic pan/zoom to WideNES, so you can scroll around
the viewport now :D
I'd like to think this commit marks the end of the first phase
of ANESE's development. It's been a long road, but ANESE is
finally at a point where I'm mostly happy with it.
ANESE sure as hell isn't perfect, but hey, it's pretty good!
The core code is pretty clean, the UI code is... acceptable, but
most importantly, ANESE actually plays my favorite NES games!
There is still some work to be done before I'd be comfortable
giving ANESE a v1.0.0 release, but what I have here is still
pretty great.
Let's call this ANESE v0.9.0 :)
-------
So, what next?
Well, contrary to what I said in some earlier commits, I think i'll
continue to work on ANESE a little bit more!
Specifically, i'd like to rewrite the 6502 emulation.
My current implementation is... okay.
It's instruction-level cycle accurate, but I don't think that's
good enough. It really should be sub-instruction level accurate.
Odds are the added accuracy will fix _a lot_ of bugs.
Aside from accuracy though, I have another reason to do a rewrite...
As a Waterloo student, I have to do a Work Term Report on some
technical project i've worked on recently. ANESE is one such project.
Since the report isn't designed to be very long, I'd limit my scope
to just a small aspect of ANESE: the 6502 emulator.
Yes, I could just write the report on how I arrived at my current
implementation, but I think it would be cool to attempt a cleaner
rewrite, and compare and contrast the two versions.
So yeah, stay tuned! I might also post the writeup (once I get
around to it)
no more janky DEBUG_VARS! Now, there is a defined NES_Params object
that is passed (by const ref) to the NES on construction, which is
passed along to all components that need it, with each component
holding a const ref to the individual fields it cares about.
Plus, I could finally get rid of debug.h/cc, which has outlived
it's usefulness.
cross-platform support man. it's tricky.
I didn't want to include more libraries, but I really didn't want to
deal with cross-platform pathfinding, or coming up with a custom
config format.
I still had to slap together a janky solution for getting a folder's
absolute path across platforms, but it seems to get the job done...
I fixed up the dmc some more, since I realized it sounded like
death (especially in Kirby's Adventure)
I also refactored and cleaned-up much of the APU. Lookin' good :)
Well, here we are. I implemented my own APU.
It's not great, far from it. Hell, I doubt interupts even remotely
work. I sure as hell won't be passing any APU tests...
But hey, it works in most games!
---
This was my last major task with ANESE.
While there are a _lot_ of things that I could still improve, I
think it might be time for me to ramp down, and start looking at
some other projects to work on. ANESE has taken up a huge chunk of
my time lately...
In the near future, I might push a few more commits to ANESE,
cleaning up some code here, adding some more comments there. Maybe
i'll actually improve the UI a bit.
I pushed a lot of common behavior up to the Mapper base class,
the most substantial of which is the bank-chunking logic.
Doing so did lead me to yak-shave a bit, since I needed to add
proper inheritence support to the Serialization library. It's not
_completely_ transparent, but it's pretty good. Essentially, since
C++ doesn't have a built-in "super" keyword to access the parent
class, you have to manually specify the parent class.
I didn't implement multiple-inheritence support though, since that
isn't relevant to me right now.
That said, the serialization library is really nifty, so (like I
mentioned earlier) i'd like to spin it off into it's own repo.
I also took this chance to add power_cycle() and reset() methods to
the mapper interface, since I realized that some games would die
on reset due to registers not being cleared properly.
So yeah, feels gud man.
tinyfiledialogs was a good band-aid, but it was always kind-of a
janky solution. Mind-you, this file-browser I threw together ain't
the nicest either, but at least it's within the main SDL window.
Now that the menu is in place, it's possible to switch between
games without restarting! Also, opening the file-picker pauses
ANESE, so that's good to finally have.
Thanks a bunch to cute_headers for a neat little cross-platform
directory traversal library, and also SDL_inprint for a quick-and-
dirty embedded font for use in the menu. Not having to bring-in
SDL_ttf is a huge load off my shoulders.
Oh, and i've noticed that `gui.cc` has started to get bloated, so
now I need to get around to cleaning it up weeeeee.
It wasn't that hard to do per-se, it's more about me finally
getting around to doing it. main.cc is hella clean, just making a
new SDL_GUI instance, and letting it RAII all of the SDL stuff.
Also, now that the new project directory structure is in place, it
shouldn't be that hard to add a LibRetro core! Fun!
It's not the prettiest code, and it sure as hell isn't how the
hardware does it, but by lord it does what I need it to do!
Yep, I pretty much copied the existing sprite fetching code from
one part of my PPU, and slapped it in spr_fetch(), with
cycle-accurate timings.
This is awesome, since I can remove the ugly "passing the PPU to
the mapper" shenanigans I wrote to get it working. I can actaully
use the correct MMC3 timing behavior, i.e: watching PPU A12 for
a rising edge.
Plus, if I switch to a subcycle-accurate CPU emulator, it _should_
automagically fix flickering in Kirby's Dreamland!
Oh, i'm almost forgetting the most important bit: Punch Out!!
It works now!!
That was the last game I really cared about getting up and running,
which means that I'm not going to be focussing on mappers for the
next little while, shifting gears instead towards accuracy stuff.
Basically, there are 2 things that I really want to get around to:
1) subinstruction cycle-accuracy - i.e: rewrite the CPU
2) write my own APU implementation
Of these two, I think i'll tackle 2) first, because if I don't do
it, i'll never be fully satisfied with myself. How can I say I
wrote a NES emulator if I haven't even written a major chunk of it!
So yeah, good stuff!
It's kinda jank, but hey, it works?
The serious issue is that it relies on the SDL2 dylib installed
from homebrew, and if that verion ever gets bumped, RIP.
hey, look at that. I have CI now :D
One of these days i'll look into how to package up macOS builds,
and update my cmake scripts to prevent a console from popping up
on windows.
This serialization framework sure was something!
It is by far the jankiest, ugliest, nastiest C++ i've written,
using a bunch of dirty pointer-hackery and casting to make it work
as "seamlessly" as it does, but god-damn if the end result isn't
marvelous.
Serializing arbitary C++ classes is hella simple now! Just extend
it as "Serializable" and slap-on the appropriate field definitions.
Now, there are a couple rough edges...
First of all, I don't handle Serialization inheritence that well.
Well... at all.
Only data serialized by the last-class in an inheritence chain gets
serialized, which works well-enough for Mapper extending
Serializable (since it doesn't actually have any data to save at
the base level), but things might break down the line.
Since this serialization library is pretty neat on its own, I
think I might spin-it-off into it's own project :)
Try and run Zelda, it should generate a .sav once ANESE closes, and
it should automatically read it once ANESE is reloaded with the same
file :)
So yeah, serialization.
It's an important part of any emulator.
It makes saving unsavable games possible.
It opens the door to a whole mess of neat stuff (rewind OwO)
The question becomes, what's a good way of doing it?
While there are probably much better solutions out there, I want my
solution to be fairly simple and lightweight.
The gist of the system is that anything that can be serialized will
extend the Serializable class. Though some clever use of
inheritance and macros, serializing the state of an object will be
as straigtforward as defining which fields should be serialized
(in the constructor, using some macros), and then calling
serialize() and deserialize(data) appropriately :D
I'm not planning on doing anything too fancy, basically just some
structured memcpy's, but it aughta work okay. Hell, i'm not even
labelling chunks, so if I ever change the order in which something
serializes it's members, old saves won't work anymore haha.
At least it's portable... ish? I've been using sizeof with fixed-
width types, so saves _should_ transfer across machines.
(assuming they have the same endianess)
Oh, and I still haven't figured out how i'm going to handle
serializing data-structures that have serializable members, (which
is kind-of important when serializing the NES / some of the fancier
mappers)
Off the top of my head, it might make sense to adopt some sort of
tree-like approach... but idk yet.
I shuffled A LOT of files and functions around.
Two big things in this change:
1) There is no more Cartridge class.
I wrote that class when I was just starting out with ANESE, and
before I had a good idea of how NES hardware operates. As it turned
out, the Cartridge class essentially just mirrored the Mapepr
interface! The only real functionality it brought to the table was
routing the raw ROM data through into thte ROM_File class, which
would parse the ROM data.
I restructured all that.
File parsing shouldn't be under the /nes directory, since the nes
couldn't care less if the ROM file is iNES, NES2.0, or whatever
other formats there are. All the NES cares bout is that there is a
ROM_File struct with good data in it.
So, I moved the specifics of file-format parsing out of /nes, and
put them under /ui/fs/parse_rom.h.
I've changed all the interfaces that used Cartridge to just use
Mapper, and pushed the construction and ownership of the ROM_File
struct to main() for now. Which leads to number 2...
2) Main doesn't have any filesystem code anymore.
Yep, i've moved all the code required to read roms (and general
files) into /ui/fs/load_rom.h, so all main() has to do is pass the
path to a ROM / file, and it gets back a fully validated ROM_File
struct, or filled data pointers!
The code could still use some work, reorganizing the freestanding
functions into classes / namespaces, but this is a big step-up
from just having it all cluttering up main()
----
So yeah. Not much on the emulation front today, mostly just
improving code-quality.
(i'm also just procrastinating having to implement MMC3 lol)
i've also had a chance to experiment a bit with ANESE, and I've
realized that I probably won't get supreme cycle-accuracy working.
My CPU emulator is instruction-level cycle accurate, but there are
some tests, games, and demos out there that rely on sub-instruction
level timings.
fixing these issues would involve a substantial rewrite of the CPU
core, which is something that I doubt i'll get around to. I'd
rather just push forward with implementing some more mappers,
cleaning up the code and UI, and taking a stab at a proper
home-grown APU implementation.
It's one of those little featues that is nice to have. I'll record
myself playing some games, and i'll be able to see how various
changes I make alter the timings.
also, maybe i'll get to the point where I can actually run propper
TAS movies on ANESE. that'd be pretty rad.
----
I also moved speedup out from the nes core, since movies would need
a lot more fancy logic if I had kept the functionality contained in
nes.cc. The only reason the nes is still notified of the speed
change is so Blaarg's APU can adjust itself.
so, MMC3 == Mapper 4. that kind of tripped me up a bit, but that's
a minor thing
So yeah, MMC3 is a tricky boi, and it's probably going to require
some restructuring / new wiring. I'll tackle that later.
In the meantime, I got mappers 2 and 3 working! They are really
simple mappers: 2 has a single swappable PRG ROM, and 3 has a
single swappable CHR ROM. ezpz implementations.
Mappers 2 and 3 got some quality games "working," such as Mega
Man 1, Contra, and Arkanoid! "working" is in quotes because i'm
still seeing glitchy graphics, namely in Contra.
By the looks of it, the glitchy graphics are similar to those in
some MMC1 games i've messed abou with, which indicates to me that
odds are the root of the problem lies somewhere with my PPU
implementation.
My gut is telling me it might be something to do with DMA timings,
but that may very well be completely wrong...
All in all, i'm pretty happy with this commit. I can stop stressing
over my MMC1 implementation, and instead get _really_ stressed over
my PPU implementaion!
weeeeeeeeee
It's been a while...
Once the semester started, I stopped working on my sideprojects,
as I had built a brand spanking new Gaming PC, and PUBG entered my
life.
Well, it's coop now, and I don't have a fancy gaming PC.
Might as well finish what I started here.
I always felt bad that ANESE was broken, and couldn't play all the
major titles. Yeah, SMB1 and Donkey Kong are great, but what about
Zelda? What about SMB2 and SMB3? Kirby?
So yeah. Hopefully I can get those working, and go on to bigger and
better things!
-----
Now, I don't know for sure, but I _think_ i've mostly fixed my MMC1
implementation. It passes the MMC1 mapper tests.
That means that things are broken for other reasons...
...
...
the PPU probably.
Ugh, this is going to suck.
So, lots of early assumptions proved to be wrong.
This meant that there was a bunch of code that had to be rewritten.
1) iNES format stores ROMs in 16k / 8k chunks, but that does _not_
mean that all mappers bank along those lines!
I rewrote the entire ROM File parsing logic, and instead of chunking
the raw ROM into banks at the iNES parsing stage, it is done on a
mapper-per-mapper basis
2) Cartridges are _not_ just dumb data storage devices, and can have
cycle-dependant logic!
To be fair, I knew I would have to cross this bridge someday. I had
to expand the Cartridge / Mapper interfaces to expose more of the
NES's. This is in both directions: Giving the Cartridge acess to the
NES's cycling logic, and also giving the NES a direct way to get
mirror modes from the cartridge (dynamically)
I was hoping that getting Mapper 1 working would also get Zelda
working, but alas, it's crasahing for some reason! As usual, I
suspect it's some shitty timings, and I can confirm, I am failing
a bunch of the NMI timing tests...
I _really_ don't want to go back into the hellhole that is the PPU,
but gosh darnit, I wanna play Zelda!
But hey, at least Megaman II works now :D
PS: I've been working on this commit for probably, oh, 8h total?
Not all at once mind you, it's been over the span of several days.
Now that i'm back in Toronto, i've been a bit busy, what with the
holidays, and old friends, and Wolfenstein II / DOOM taking up my
time.
I started looking into how to make the APU, and boy, let me tell
ya, it's going to be a massive undertaking.
Undoubtedly a fun undertaking, but still...
Since it's a personal goal to get Super Mario Bros 2 running
before new years (after all, that game has won
game-of-the-year i don't even know _how_ many years in a row),
i've decided to just use Blargg's venerable `nes_snd_emu` library
for now.
It took some wrestling, it it's in, and it works!
Almost.
I still don't know why enabling the Frame IRQ kills most games, but
i'll look into that!
Welp, on to bigger and better things!
Namely: MMC1, which will give me Zelda and... Super Mario Bros 2!
HOLY SHIT THE DAY THAT I'VE BEEN WORKING TOWARDS FINALLY CAME!
SUPAH.
MAHRIO.
BROS.
1.
WORKS!
Now, mind you, it's not flawless.
There are some issues I still need to work out, but nevertheless,
IT BLOODY RUNS!
I have a suspicion that it's relying on more accurate timings,
since right now, movement is pretty jank, and the time is ticking
far too quickly...
I'll look into the Frame IRQ now, hopefully that will be the last
piece of the puzzle :)
...
I'M SO HAPPY!
...
PS: I'm writing this from a plane as I fly home from vancouver.
It's pretty rad that I got this working on a plane :D
It happened! IT FINALLY HAPPENED!
I reimplemented how background pixels are rendered, and by golly,
IT SEEMS TO WORK! And you know what that means... DONKEY KONG
FUCKING WORKS. YES!
This is a _huge_ win for me, and i'm super stoked.
Up next, i'm going to look into redoing sprite rendering properly,
and getting the sprite-0 hit working. Hopefully, that will get SMB1
booting (unless it also needs the Frame IRQ implemented...)
WOOT!
added some 3rd party libs today! man, cmake is pretty complicated,
so it took a while to figure out, but hey, it seems to be working,
so that's good!
I added two libraries:
- `tinyfiledialogs` to handle opening a file-select window (that
varies per platform) in the case that no rom is specified on the
commandline.
- `args` handles parsing and validation of commandline arguments.
As I start to add more and more flags, it's probably a good idea
to set up a more extensible framework to configure ANESE
Oh, and FYI, this is all me procrastinating working on the PPU.
weeeeeeee!! isn't emulation fun?!
yeah, i'm a bit of a dummy. I was building ANESE in _Debug_ config
with MSVC, and wondering why it was so bloody slow. Well, no shit
it's slow, it's not even being optimized!
I've set all the flags properly now, and have killed the windows
clang portion of the cmake script. Clang is a massive pain in the
ass to set up on windows with visual studio, so finally getting
MSVC to run ANESE properly is awesome.
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
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.
