konnichiwa! i am bisqwit. in this video i create anes emulator from scratch. the process of creating an emulatoris highly technical, and i cannot possiblygo over every detail, but i will try to explain someof the more interesting parts. the cpu in nes has 2 kilobytes of ram, three general-purpose registers,a 8-bit stack pointer, and a 16-bit program counter that pointsto the current instruction to be executed. the purpose of an union is to providedifferent views to the same data.
nearly all registers in the nes containbit-fields that are smaller than a byte. this regbit object provides a portableway to access those bitfields. i learned it from byuu. my emulator architecture is synchronous. it means that every componentruns off the same clock.processes the screen rendering in real for instance, every time the cpu executesone clock cycle, the ppu executes three. each component only does the thingsthey should do on those clock cycles. this approach has a number of benefits. for instance, it makes it easyto provide tas functionality.
it also makes the overall emulatordesign a lot simpler than otherwise. emulation accuracy alsocomes as a side effect. the downside is that the emulatorrequires a beefier computer to run. now we come to the interesting part. the instruction execution core. this function, op, decodes andexecutes the next instruction. the process is delegated to 259 ins functions,made from a single template. this ins template, createdabout 5 seconds from now, contains a list of 56 micro-operations.
on the 6502, or the rp2a03 which nes has, every single instruction can be synthesizedfrom a combination of these 56 micro-ops. this list of strings is a compile-time table - that maps the opcode numbersinto lists of micro-operations. i have another video thatexplains the technique in detail. in any case, with this table and the list of micro-operations we can emulate the entire cpu. the actual cpu works by a similar principle. inside the cpu, there is atiny rom table, called pla. it means “programmable logic array".
the cpu uses this table to enableand disable parts of the processor - that should be active on each clock cycle depending on the instruction being executed. the micro-ops in the cpu are notthe same as listed in this program. there cannot be a direct 1—1 relationship. this list was created for thisemulator specifically. it was my way of making the sourcecode as short as possible, in order to fit the videowithin youtube length limits. just like the number 12 can be createdfrom 4 㗠3, or 2 㗠6, or 16 㗠3 㷠4, there are multiple ways to achievethe same outcome in emulators.
and in any computer programs, really. sorry about using so tiny font in this screen. i really wanted to fit the whole instructiondecoder & processor in one screen. this code requires a rathermodern c++ compiler, by the way. all of that “if†and decoding magichappens completely at compile-time. the compiler physically creates 259different functions from the same template. next up, reading the nes rom file.parsing the ines file header. i am using c functions here, againfor source code length reasons. the ines format is a de-facto standardfor nes rom distribution.
it was devised by marat fayzullin. the format has a number of problems,but it is compact and easy to parse. it does not accurately convey thedifferences between different gamepaks. a nes emulator not only needsto emulate the console hardware, but the cartridge (gamepak) hardware as well. gamepaks of different games havedifferent amounts of rom and ram on board. not only that, but they alsohave different circuitry. the circuitry is responsible forthings like memory “mappingâ€. the address space in 6502 is very small.
it can only see a small amount of memoryat a time, called a “page†or “bankâ€. the “mapper†changes which part of therom or ram is seen through that page. now, the ppu: picture processing unit. the ppu is the graphics chip in the nes. like the cpu, it also has a number of registers. the ppu has very little memory,just a couple of kilobytes. but what’s important is how it uses it. nes cannot render single pixels atarbitrary positions on the screen. (there are ways around that, but bear with me, i'm trying to explain things easy and understandable way.)
instead, the screen is dividedinto 8x8 pixel cells, or “tilesâ€. you can only change an entire tile. the tile can be chosen from 256 pre-determined tile patterns supplied in the game rom. the patterns are 2-bit: each pixelis one of four possible colors. each group of four tiles, i.e. 16x16 pixels,shares the list four possible colors. different 16x16 squares on the screencan have different sets of four possible colors, but there can only be a total of four different setsof four possible colors on the entire screen. and the background color (one of the four colors)must be the same in all four sets. this means there can only be 1 + 4x3 = 13 different colors in the entire screen of background graphics.
these sets of colors are called “palettesâ€. each color in the palettes comes froma single global palette of 54 colors. do an image search for “nes paletteâ€if you want to see the 54 colors. the list comes directly fromthe ntsc/pal encoding scheme. there are also a few status bits (color de-emphasis)that can globally tweak the palette. the background graphics is freelyscrollable in all four directions. on top of the background,there can be sprites. sprites are also 8x8 pixel tiles. or sometimes, 8x16.
the sprites are very similar to background tiles,but they can be positioned anywhere on the screen. game objects such as mario or powerupsare nearly always sprites. there can be a total of 64 spriteson a screen simultaneously. but only eight may be renderedon a single scanline simultaneously. if there are more, the general rule of thumbis that the extra sprites will not show. most games work around this limitationby rotating the sprite list. this way, if there are sprites thatbecome invisible due to the limits, at least it’s a different sprite each frame. this will appear as blinking while playing.
the ppu renders the screen in real time, in sync with the television set receivingthe ntsc video signal from the ppu. it runs on a very tight schedule. on each and every clock cyclethe ppu does some very specific things. usually more than one thing at once. the design is quite clever, really. this is because there are electrical limitations. to access the cartridge memory - the ppu must first assert the memoryaddress, and then wait for the data.
on every clock cycle it is either asserting a particular memory address, or reading the data and acting on it. but while it is waiting forthe cartridge to respond, it is also inspecting the sprite list - and sorting it out for the next scanline. and while doing that, it is also readingthe list that it created the last scanline - and rendering sprites based on that information. it all happens on a very specific schedule - where not a single clock cycle is wasted. some games actually depend on this schedule.
an accurate emulator must replicate this scheme. it was only reverse engineered quite recently. even after i made this video, newdiscoveries were still being made - by hobbyists reverse engineering the nes. this kind of information is not readily available. console manufacturers don’tjust publish these specifics. all emulators stand on countlessof manpower hours of research. so does mine, too. i have only donea very very tiny fraction of the research - that my emulator is based on.
for the nes, you can find nearlyall of this information - at https://wiki.nesdev.com/ . for more modern consoles,there may not even be such sites. if you want to create an emulatorfor the newest hot game console, you must be prepared to investmonths or maybe years of time - researching the hardware andsoftware in that console. it is a specialty that requires very deep expertise. maybe you can estimate how much that expertise,multiplied by years of work, is worth on the job market. it is not something thatpeople do “just like thatâ€.
think about that, if you plan to ask someone to create an emulator for your favorite console. the ppu is by far the most complexcomponent in the nes. even then, it is so much simpler than the ppu ofmore modern consoles like the snes or the gba. games for the nes of coursehave to communicate with this ppu. game developers must know which exact sequenceof writes to do to accomplish a particular outcome. this of course makes nes gamestricky to translate to other platforms. the games assume the presence ofvery specific hardware, and they are designed around the limitationsand features of the nes hardware. it is usually therefore impossible to just translatea nes game into a more modern platform.
any such pursuit would need to incorporateparts of an actual nes emulator. the nes was designed torender ntsc or pal video. most nes emulators containa hardcoded palette file - that translates betweenppu color indexes and rgb colors. but the real nes does not have that. neither does my emulator. in these few lines i created an ntsc modem. modulator + demodulator. it encodes the ppu colors into ntsc signal samples,
and straight away decodes that ntsc signal. this produces very authentic looking video. again, the design is not most efficient, but i was aiming for a designthat is fastest to type. i did add some caching to speed it up though. while the video, excluding borders,is 256x240 pixels in size, each “pixel†actually is eight ntsc video samples. so the resolution is 2048x240 really. however, you need 12 samplesto decode color accurately,
so the horizontal color resolution is 170â…”. within the 4:3 aspect ratio video,is the 256x240 screen, but also horizontal borders,for a total of 280x240. the pixel aspect ratio is therefore4ã·3ã—240ã—280 = 8:7. the joypads appear to the nesas simple 8-bit shift registers. indeed, inside the controller there isnothing but a single tc4021 chip. the music changed. this means that wehave the next component in the emulator. i am now writing the actual memory mappers. memory mapping is implemented using pointers.
the emulator does not access memory directly. instead, it uses a pointer to access memory. and this pointer is changed by the mapper, to point to whichever part of the memory - that the mapper circuit isprogrammed to point into. it surprised me actually that c++ allows the kindof template parameters i used in setpages(). in this emulator i only supportfive most common mappers. in reality there exist hundredsof different mappers for nes. every single nes/famicom gamecartcan count as a new mapper,
if it works the slightest bit differentlythan any other existing mapper. mapper 1 (mmc1) appears quite complex, but there are far more complex mappers. i didn’t write full ui. this emulator reads joypad input from a file rather than from a keyboard. here is the memory mapfrom the view point of the cpu. the soundchip is integrated into the cpu in the nes. ppu dma and joypad input arealso mapped into that memory region. begin section: apu (audio processing unit) the apu has registers too. in the japanese famicom, the gamecartmay also contain audio chips,
but my emulator only does the integrated audiothat is common to both nes and famicom. all of the music that you hear in this videois actually generated by this very emulator. the music in nes is produced using signal generators. the program / game can adjust thosesignal generators in real time, varying things like the pitch (frequency) and volume, to generate impressions of different instruments. the signal generators are: two square wave generators, one triangle wave generator,
and one static noise generator. there is also a wave generator thatcan read dpcm sample data from rom. in this part i am only creatingthe first four channels though. again, the design principles are: synchronous, i.e. it only runs cycles insync with the cpu instruction core, and minimal source code length,to fit things in a youtube video. and of course, accuracy.i want it to sound good. the best way to make it sound good - is to do exactly what a real nes does.
this would not have been possiblewithout the very detailed research - published for free by people likemartin korth, shay green, and others. the signal generators that produce sound - are run directly from the cpu clock. the game divides that clock toproduce sounds of different pitch. this means that if you change the cpuclock, sounds will also be affected. the cpu clocks in ntsc and palnes consoles are different. if you put an ntsc game into a pal console, and the game does not checkwhich console it’s running on -
i.e. it assumes it is running on ntsc,but it is really running on pal, you will get slower and lower-pitchedmusic than when running it on nes. this means e.g. that players of mega man iigot differently paced music - depending which hardware and regionthey were playing on. some games, such as super mario bros. 3,were changed for their pal port, so that the music sounded almostthe same as in the ntsc release. but if you put the cartridge into a differentconsole, it would still sound wrong. this phenomenon was very familiar to pal region players who bought pirate multigame carts, because these multigame carts nearly alwayswould contain ntsc versions of the games.
aside from the sound and speed differences, most games would still be totally playableeven if you put them in a different region console. however, if you tried pluggingan ntsc nes into a pal television set, the situation would be quite different. while the principles behindntsc and pal video are same, there are small details in timingsand in how colors are encoded. now, as an after-thought, i decided to incorporatedpcm support in my apu emulation. for the sake of completeness, you know. it will take about a minute.
of course in real life it tooka couple of days or maybe a week. after all, this video is a recreation, illustration. the purpose is to present the designin a natural, followable format. for details, check out that other videothat shows how i make these videos. the soundtracks in this video, as i said earlier,are rendered by this very emulator. the songs it is playing come froma japanese detective series: jake hunter. or, tantei jingå«ji saburå (枢åµç¥žå®®å¯ºä¸‰éƒž?). i chose some of my favorite songsfrom those famicom games. apparently, some of those games havebeen recently remade for the nds -
and even released in english. we are approaching the end of this video. check out part 2, in which i run the emulatorand showcase some other pieces of code!