I really appreciate you taking the time to upload this series, javid. I can tell you put a lot of effort into the quality of your presentation and I just wanted to let you know that I recognize and admire it.
Hey, Javidx9 What you do here is timeless. This video series will be relevant for decades and be a go-to resource for professional programmers and NES hobbyists. Thank you very much.
just WHY does this have so few views... can't wait to post this at the "TownSquare" slacks channel at work tomorrow. thanks for this gem, i really had a great time watching the series so far. please never stop, i am certain that one day people will appreciate this piece of art. greetings from germany!
The time you've taken to explain the inner workings of the NES is what I'm here for, and your One Note drawings and the code combined make this a very clear story. I've always wondered how the NES was able to do what it did so efficiently, thank you for explaining it!
@37:55 -- This truth is so fundamental I can't believe it never occurred to me! I really like learning "thinking outside the box" shortcuts like this that use the basic properties of a system! Your undertaking this project is impressive all on its own, but for me this is also extremely entertaining to get glimpses of how the old masters historically squeezed blood from a stone time and time again!
Amazing video, thank you. It is nice to follow this time travel back in memory lane and remember all the hardware trickery used, back in the day, to feed the serial outputs that generate the video signal expected by the TV set. On one hand it raised good memories of all the imagination needed, with lots of trial and error too; on the other hand its a showcase on how digital electronics evolution made life so much easy for programmers, specially for game programmers.
Hi. I've been following along, making my own version of your emulator. I tried emulating the PPU on my own, and made some progress, but quickly got very confused. Even after this video I haven't wrapped my brain around all the math and why it works (I'm gonna rewatch it), but I've implemented it and it works!! Even with the mappers I've added! Incredibly exciting! I've also added a simple controller class so I can press buttons on a controller, and invisible Mario is actually moving around and scrolling the background! Next goal: figure out how to render sprites before your next video :) I think it should be doable after watching this video >= 1 times. Thanks a lot for this series!
I am always amazed with your videos. I love them all. In this one, I have to admit, I got lost and confused with all the memory stuff at the begining. I will have to re-watch this video several times to fully understand it. I can truly say that I always learn from your videos. You are one of my favourite channels.
Thanks wowLinh, and you are one of my longest time supporters too! The PPU is a complex device because it does lots of things us programmers dont like. Its really a huge collection of edge and corner cases XD
@@javidx9 But is has to be understood to emulate. I'll get deeper into this video and your source code to try and understand all those "edge and corner cases" In any case. Great job. I cannot stress this enough. Keep it up!! I love everyone of your videos. And this series is simply the best!
I've rolled a die and it came up 4. Since that's truly random, you can just use 4 for random noise from here on out. That should hopefully fix the UA-cam compression algorithms.
Okay, yeah, you lost me on this one. The others I could follow, this one not so much... But still a big thank you for doing these. I've always been interested in how these emulators work. It is definitely a very insightful.
this series is inspiring me to write an nes book from making an emulator to a game for explaining everything... it seems like a bit of a dream though 😅
i like to read old game source code, just to see how creative the people back then had to get with incredibly limited hardware. and for inspiration. these people were like rocket scientist level of creative(or how creative i imagine rocket scientists must be). its very impressive. kind of javidX9, so extremely talented i look at myself and think what a joke. this guy is barely older than i am, where did he find the time to learn all of this.
Constraint has always yielded creativity. Youre forced to think innovatively. I believe this to be true and I was fortunate enough to start in an era where constraints were not optional XD
How can you know these a tons of knowledge ?You're be able to write your own game engine,you can write your own simulator,u write game in pure C++. How is it happens ? Only a basic c++ book is about 500 page.I can't imagine how much knowledge required to write NES simulator ? I guess I am idiot but you're normal person.Or you're genius like Einstein and I am normal person. Or,you're alien from Sirius galaxy, who want to teach us how to programming a real life galaxy simulation. You are the best skilled programmer I've ever seen !
This is absolutely amazing stuff. Just reading the NESDev Wiki I never understood what is going on. These videos are gold! For everybody following this tutorial: The trick with setting vertical blank to 1 manually to get the CPU running will not work with real NES games! It only works with the nes test rom instructions.nes.
Really enjoying this series, quite inspiring and filling in a lot of gaps in CompSci I'd forgotten! I know in the first video it was mentioned that the code would be in a style that was verbose for understanding and that works great. My one suggestion would be that it would be more readable and easier to grok and come back to (because I do watch parts of these N times ;) ) whilst watching if the key hex addresses used (offsets and the like) were named via some enum so that rather than repeatedly using e.g. 0x3F00 in the code and the reader needing to remember what that means, you would see (and I don't do C++) but e.g. Addresses.PALETTE_MEMORY - this would communicate what was being added in terms of architectural memory location a bit better I think. Anyway, not a biggy, big thumbs up from me.
Thanks Allistair, i see what you mean regarding naming the memory addresses that dont change much. I think for me it just became second nature staring at the information for so long XD but noted!
Best C++ beginner and intermediate book Is C++11 primer by Lippman hands down! From there you go to effective c++ and effective modern c++. Can't be wrong with those
I was going to give you a really big thumbs up, but then you called Kung Fu "a terrible game." It was great! Best sound effects ever! So no big thumbs up for you, Javid. Just a small thumbs up. ;)
hey Javid love the videos, I have a question ( fingers crossed you reply :) ) As I said love the videos you really are one of the first coders on youtube to make coding fun :) the question is about the one line coder console engine , you have done a couple of videos on it but my main question is which files on github are the actual implementation of the engine? I can find the header but can't find the implementation( cpp ) files, I would really love to know how the engine works at a lower level :) thanks!
Hi mark, both the olcConsoleGameEngine and olcPixelGameEngine are just header files. The implementation is contained within and they dont rely on libraries that dont come with your compiler. This makes them very easy to use.
@@javidx9 Thanks Javid for the prompt reply =) That's pretty cool I never knew you could actually implement functions and classes in a header file, that's neat =) final question, I noticed that the onelonecoderconsolegame engine and the olcpixelgameengine both use openGL and the Windows API, are these a major part of the game engine? if so , is there any good books on openGL etc that helped you implement the engine, thanks again!
Thanks, I'm pleased you've found it useful. Lol after doing one emulator I don't think I ever want to do anymore, but you never know I did love the SNES too!
Apparently some of those NES arcade cabinets used the lower bits of $2002 to store a validation constant, and I guess you could make your software lock out if it detected an invalid value.
Your explanation is better than nesdev lol. Do you intend on making videos on stuffs related to system programming like bootloder/kernel, compiler/interpreter, malware analysis or explain how printf/scanf and other standard library functions works, etc? It would be fun watching these stuffs.
That's just so impressive! Fully working CPU emulation in part 2, and some working graphics from real cartridges in part 4? One thing that makes me curious is how you regulate the speed at which the clock ticks, you can't possibly have several million function calls per second to emulate several MHz of clock speed? Or do you use interrupts for this? I should just look at the source code, but I bet an explanation ahead of time might help :-)
Effectively yes, im emulating about 2 million cpu clock cycles per second, and about 6 million ppu clock cycles. The emulation is actually faster than real time, so i slow it down to make it ~60 fps
@@javidx9 Wow! I assume if it's going that fast you can't possibly do the time adjustment on a per-cycle basis? Do you essentially tick enough times to render a frame, and then sleep until the next one or something along those lines, syncing at each frame to keep 60FPS going?
You’re an inspiration David. I code C++ at Bloomberg but have a major soft spot for hobby game dev. I really like how you present the maths side. I’m currently trying to improve my Calculus.
(@14:19) - I believe that “addr &= 0x000F” will accomplish your task of mirroring a lot simpler; also, what happens if you read 0x3F11 vs. 0x3F10? In your implementation, 0x3F11 in will produce 0x0011 out, but 0x3F10 will produce 0x0000 out - Oops. You would need 16 if-thens; one for each address from 0x0010-0x001F, to cover all the use-cases. HTH. 😊
I don't know if I got this comment wrong, but 0x3F10 would only drop 0x0000 if anded with 0x000F, as you suggested. 0x3F10 & 0x001F = 0x0010, not 0x0000. Remember each hexadecimal digit means a span of 4 bits, a nybble. 1F means 5 bits, effectively making this AND mask catch 5 bits, while 0x000F means 4 bits caught. 0b0011111100010000 (0x3F10) & 0b0000000000011111 (0x001F) = 0b0000000000010000 (0x0010).
Ok well , i am kind of doing the opposite in writing a NES game not the emulator part. Your videos are very helpful. But I have some issues. 1) How do you change the 256 tiles to another 256 tiles for the next level. Currently i am using an example and i can do vram_put(0x4b); to place a K on the current position of screen. So i get how to change palette memory as well as VRAM (name table memory ). But how the heck do you change pattern memory for a game cartridges. As i can modify any tiles to make a cool image or background. But i am limited to needing different patterns for different levels eventually.
On some carts CHR ROM is in fact CHR RAM so you can pull from program memory and populate the pattern memory. More likely and more used however is that you would instruct the mapper to "remap" the CHR ROM to a different bank. 256 is A LOT of tiles though XD
In the horizontal mapping section, min 44-ish you don't mention clearing the top 4 bits of addr. It looks impossible following the if statements to see if addr >= 0x2000 but then if addr >= 0x0000 which could never happen. I looked at the code and see addr &= 0x0FFF which fixes it
I hope sooner or later you abstract out the control(lers) into a separate class... I wouldn't consider any console emulator complete if one couldn't connect a game controller (or two) and use that. Whether is a modern controller or one of the many cheap USB NES-style controllers found on Amazon.
Wait... How does this work? uint8_t pixel = (tile_lsb & 0x01) + (tile_msb & 0x01); Will this not give the same value for 1+0 and 0+1? Shouldn't the msb one be shifted up? Or is this just how the NES works?
I had another "I don't understand why" moment at timecode 14:20 That "mirroring" on lines from 207 to 210, really doesn't make too much sense to me. Jumping back to around timecode 7:40, from what I could understand memory 0x0==0x4==0x8==0xc==0x10==0x14==0x18=0x1C, all being the "background" colour. So "in my weird logic" it doesn't make sense to only mirror 0x4==0x14, or 0x8==0x18, even less sense to me to do it individually. Why not just mirror all of them to 0x0? And if I did it right...it seems all those memory locations are the only memory locations to always have the lower 2 bits equal to zero. Thus, I am thinking that lines 207,208,209,210 could just be replaced with something simular to: if(!(0x3 & addr)) addr = 0; and would make more sense, since really all are equal to $3f00 the background?
Right now going back to my half-made NES emulation, and was lost. So dropped by this video. Now my code makes bit sense. And I think I'll proceed with where I left, the sprites
Somehow, got my hacks removed and implemented it accurate to hardware operations. Though could've been easier if my decisions were better, like choosing -1 instead of 261, my ifs look ugly now ;-l
You're video are really great. But I had a bit of a what the heck moment. To clarify, I know nothing about NES architecture, but I am a bit familar with emulators in general. The line 110 at timecode 11:56, makes no sense whatsoever to me. If you are "adding" a LSB and MSB, shouldn't the line read: pixel = (tile_lsb & 0x01) | ((tile_msb & 0x01)
If you don’t mind me asking, but what is you educational background? Are you a math, cs, engineering, etc major and studied at an self-taught, undergrad, graduate, etc level?
@@joshinils Be carefull however. This does not guarantee the size of your struct. The compiler may add "padding", like blank space between fields. It does not matter as long as you have a normal use of your structs. It does matter when you use struct to layout memory (for example when reading a binary file, or sending datas to gpu). It also happens when you have something like this: union { struct { bla bla bla }; int something; }; And write into "something" and then read into the struct fields. Because you'll be making an assumption that the compiler does not guarantee : the layout of the structure. This is especially true when you mix types ( like struct { float a; int b:1; } ) or bitfields and non-bitfields ( like struct { int a:1; int b; int c:1; } ) You may have no use of this advice right now, but maybe later it will help you "if you don't understand what is wrong with your struct, try to output the sizeof of it". (and use and abuse of valgrind/drmemory. I couldn't emphasis this enough.)
Why do you add tile_lsb and title_msb? Shouldn't title_msb be shifted left and or'ed in instead? Color index will never be higher than 2, which is not what you said should happen earlier in the video.
There's something I'm not quite clear on: there is a tblPattern[] variable on the PPU that's holding the pattern table data, but on the PPU::ppuRead() function, we're calling the cartridge's Cartridge::ppuRead() function, which reads directly from the vCHRMemory[] vector on the cartridge. Same thing for the write functions. We only ever use the PPU's variables when the cartridge's mapper fails to map the address that's being read/written to/from. Is this how it's supposed to work? If so, then the pattern table memory inside of the PPU will never get used in the case of a cartridge using Mapper000, which seems weird to me. Am I missing something? Edit: I believe I was in the right heh, everything worked for me making the above assumptions.
There is a bug at 11:49. You add the msb and lsb together, but you forget to shift the msb by 1. The code should be uint8_t = (tile_lsb & 0x01) + ((tile_msb & 0x01)
Update on my Java port, About halfway through the video, I encountered some "errors" and the CPU doesn't work. I'm now going to redo the entire project and confirm that everything works at several points during the videos. ill post back here when I've gotten back to this video and again when I've finished this video. Probably won't post again for a couple of days to a week.
Finally got back to part 4. This time it includes the debug screen and clock and frame functions. I got stuck on part 3 with some address errors and then I found out that I had a 15 instead of a 16 when defining how many bytes in the header(java doesn't allow direct reading to classes so I used a byte array instead). But, it works exactly like in part 3 and I can't wait to finish the ppu. Post back in about a day with no errors(hopefully).
I have hit a roadblock. I got to 28:22 when I got to the roadblock. I'm pretty sure that I messed up some vital bit of code in the ppu but it jumps to FFB0 for no apparent reason and doesn't load any characters into character rom. I probably won't post for a VERY long time because I will probably forget all about this project with school and other things but if I decide to review over my code with the code from GitHub, I will probably get it going. This might and probably will be my final post. Goodbye
This is it. I might do another attempt but I don't think I will for a long time. It gets to RTS and since the stack has some value in it that isn't right, it jumps outside of the program and breaks. if anyone wants to look at my code and try to find out what's wrong, be my guest. The code is located at github.com/GamingLiamStudios/glsJNES I would really be grateful if anyone could help me fix this bug. Thank you.
Phew I am writing nes emulator , cpu ok , cartridge ok , mapper 0 ok , Bus ok , but ppu gives me problems I don't know I can't see anything Although debug counters shows that cpu is working
Why is the nametable in the ppu class if it's stored on the cart and under the effect of the mapper? Also, why is the vblank nmi done using a variable that is checked every cycle? Why can't the ppu call a function to let the cpu know? You can even put a forwarder function in the Bus class if you don't feel like giving the ppu direct access to the cpu.
The 2k of vram is stored on the system. The mapper can be in control of the mirroring configuration of the cart. This is distinct from address mirroring. Some carts may also have nametable memory stored on them. Ive shown the simplest case in this video.
I'm a little bit confused about something. At 14:17 mirroring from byte 10 to byte 0, byte 14 to byte 4, etc, is hardcoded. However, shouldn't the bytes at 4, 8 and C map onto 0 as well? I can't see how a read at address 4/8/C results in a read of the background colour
Hi Tomer, not really but then i wouldnt see it as anywhere i use the union i only access the individual named bits, so in reality i dont actually care how the compiler represents it as long as its consistant.
Please have a read of pull request 15: github.com/OneLoneCoder/olcNES/pull/15 I believe it addresses some issues that I feel need to be corrected in the next video - or at least it reveals something that isn't intuitively obvious about the code that needs further explanation.
At 20:00 your description of the scan lines it awesome. It really ties in well with Ben Eater's VGA video card build. ua-cam.com/video/l7rce6IQDWs/v-deo.html
Took me at least 3 months to learn all the stuff you just explained in 1 hour.
Thats ok Brett, it took me 3 months too!
lol i have been trying to understand this stuff for years and still don't get it :|
@@davep7176 Same thing
I'm watching this video for the 3rd time now and every time I see tons of new stuff
Too bad it's english i'm studying c++ and trying to write an emu but i don't understand english speech very much
I really appreciate you taking the time to upload this series, javid. I can tell you put a lot of effort into the quality of your presentation and I just wanted to let you know that I recognize and admire it.
Much appreciated Aaron, its good to hear youre enjoying the stuff!
@@javidx9 me too i appreciate it too
Really Amazing lessons!
Hey, Javidx9 What you do here is timeless.
This video series will be relevant for decades and be a go-to resource for professional programmers and NES hobbyists.
Thank you very much.
just WHY does this have so few views... can't wait to post this at the "TownSquare" slacks channel at work tomorrow.
thanks for this gem, i really had a great time watching the series so far. please never stop, i am certain that one day people will appreciate this piece of art.
greetings from germany!
Hi Leon, Greetings! Sorry for the delay in response, but Im pleased youve enjoyed the series.
Oh boy, I think this series has convinced me to write a NES emulator in Rust, what on earth am I thinking, I must be insane... 😂
I am on the part 3 on type script 🤣🤣😅
Did you do it i am also interested we could collaborate
Im already far enough for displaying palettes, and it was quite fun
Finally got through this video, and... my head hurts. I need to watch this again.
The time you've taken to explain the inner workings of the NES is what I'm here for, and your One Note drawings and the code combined make this a very clear story. I've always wondered how the NES was able to do what it did so efficiently, thank you for explaining it!
This video series has been invaluable for my foray into creating retro game systems on an FPGA.
Ooof, no easy task, but good luck!
@37:55 -- This truth is so fundamental I can't believe it never occurred to me! I really like learning "thinking outside the box" shortcuts like this that use the basic properties of a system! Your undertaking this project is impressive all on its own, but for me this is also extremely entertaining to get glimpses of how the old masters historically squeezed blood from a stone time and time again!
People who know stuff are not afraid of entropy. Great joy watching your videos.
Amazing video, thank you.
It is nice to follow this time travel back in memory lane and remember all the hardware trickery used, back in the day, to feed the serial outputs that generate the video signal expected by the TV set. On one hand it raised good memories of all the imagination needed, with lots of trial and error too; on the other hand its a showcase on how digital electronics evolution made life so much easy for programmers, specially for game programmers.
Was looking forward to this all day! Now I have something to look forward to in 2 weeks.
With this much quality content, how does this channel not even have 100k subs? Keep up the good work man
Lol thanks Demolidor, I will!
Hi. I've been following along, making my own version of your emulator. I tried emulating the PPU on my own, and made some progress, but quickly got very confused. Even after this video I haven't wrapped my brain around all the math and why it works (I'm gonna rewatch it), but I've implemented it and it works!! Even with the mappers I've added! Incredibly exciting! I've also added a simple controller class so I can press buttons on a controller, and invisible Mario is actually moving around and scrolling the background! Next goal: figure out how to render sprites before your next video :) I think it should be doable after watching this video >= 1 times. Thanks a lot for this series!
Did you happen to beat Javid to it?
I am always amazed with your videos. I love them all. In this one, I have to admit, I got lost and confused with all the memory stuff at the begining. I will have to re-watch this video several times to fully understand it.
I can truly say that I always learn from your videos. You are one of my favourite channels.
Thanks wowLinh, and you are one of my longest time supporters too! The PPU is a complex device because it does lots of things us programmers dont like. Its really a huge collection of edge and corner cases XD
@@javidx9 But is has to be understood to emulate. I'll get deeper into this video and your source code to try and understand all those "edge and corner cases"
In any case. Great job. I cannot stress this enough. Keep it up!! I love everyone of your videos. And this series is simply the best!
What a wonderful job! I hope you are rewarded for all the work done because the information you give is invaluable.
Thanks Ginger. All I want is to get people intetested enough to maybe google something they had not thought about looking at before.
I clicked on this SO fast after seeing it man I love your content! You've inspired me to fuddle around with my own projects, thank you :)
Lol thanks Connor!
Congrats on 100k subscribers! I've been following you for so long now, it's well deserved.
Thanks buddy!
I love that hex debugger you created. When I was creating my jav autoreplace language I never thought of that idea.
I just about managed to follow the first 3 episodes, but this one fried my brain. Great stuff.
Unfortunately, youtube's compression renders 31:32 into a smudge.
could be a good idea to change the "random noise" to something less random
I've rolled a die and it came up 4. Since that's truly random, you can just use 4 for random noise from here on out. That should hopefully fix the UA-cam compression algorithms.
@@Phroggster no you didn't, randall did
He should have just added a black box on top in his video editor.
been waiting 2 weeks for this😁... havent even watched the video yet and i already gave it a thumbs up
Woohoo, been waiting all morning for this
Just wanted to say really enjoying this series during my staycation.
Okay, yeah, you lost me on this one. The others I could follow, this one not so much... But still a big thank you for doing these. I've always been interested in how these emulators work. It is definitely a very insightful.
Never underestimate creativity and resources for all types of reasons not just nes development and emulators
The very same bit plane technology is in a game boy model one from 1989 ad only without color graphics which came around ten years later
I do drawings in black and white by the way
But somehow I can feel the color generated by the drawings that I make that are semi detailed by the way
This is so out of my league but I watch it anyway. I hope I learn sonething subconsciously 😊
this series is inspiring me to write an nes book from making an emulator to a game for explaining everything... it seems like a bit of a dream though 😅
i like to read old game source code, just to see how creative the people back then had to get with incredibly limited hardware. and for inspiration. these people were like rocket scientist level of creative(or how creative i imagine rocket scientists must be). its very impressive. kind of javidX9, so extremely talented i look at myself and think what a joke. this guy is barely older than i am, where did he find the time to learn all of this.
Constraint has always yielded creativity. Youre forced to think innovatively. I believe this to be true and I was fortunate enough to start in an era where constraints were not optional XD
How can you know these a tons of knowledge ?You're be able to write your own game engine,you can write your own simulator,u write game in pure C++.
How is it happens ?
Only a basic c++ book is about 500 page.I can't imagine how much knowledge required to write NES simulator ?
I guess I am idiot but you're normal person.Or you're genius like Einstein and I am normal person.
Or,you're alien from Sirius galaxy, who want to teach us how to programming a real life galaxy simulation.
You are the best skilled programmer I've ever seen !
I noticed you were so close to 100k, and I finally decided to subscribe. Good job. I wish I had earlier.
Thanks Itz!
Thank you for doing this! I've been hoping to get into a gameboy color emulator project, and this is definetly gonna help towards that goal!
This is getting exciting!!! 🕹👍❤️🦍
Lol it was still exciting filming it for the video even though id implemented 3 times already XD
This is absolutely amazing stuff. Just reading the NESDev Wiki I never understood what is going on. These videos are gold!
For everybody following this tutorial: The trick with setting vertical blank to 1 manually to get the CPU running will not work with real NES games! It only works with the nes test rom instructions.nes.
Really enjoying this series, quite inspiring and filling in a lot of gaps in CompSci I'd forgotten! I know in the first video it was mentioned that the code would be in a style that was verbose for understanding and that works great. My one suggestion would be that it would be more readable and easier to grok and come back to (because I do watch parts of these N times ;) ) whilst watching if the key hex addresses used (offsets and the like) were named via some enum so that rather than repeatedly using e.g. 0x3F00 in the code and the reader needing to remember what that means, you would see (and I don't do C++) but e.g. Addresses.PALETTE_MEMORY - this would communicate what was being added in terms of architectural memory location a bit better I think. Anyway, not a biggy, big thumbs up from me.
Thanks Allistair, i see what you mean regarding naming the memory addresses that dont change much. I think for me it just became second nature staring at the information for so long XD but noted!
Hey @javidx9 what C++ books do you recommend?? and keep up with the good work... your channel is amazing, I really love it.
*Here you go*
stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list
@@JohnCena-zf2kl thank you...
Best C++ beginner and intermediate book Is C++11 primer by Lippman hands down! From there you go to effective c++ and effective modern c++. Can't be wrong with those
Lovely video. Thank you!!
I was going to give you a really big thumbs up, but then you called Kung Fu "a terrible game." It was great! Best sound effects ever! So no big thumbs up for you, Javid. Just a small thumbs up. ;)
There's only one word in my mind. brilliant!!
impressive. Almost 100k subscribers! Nice ;) You are the reason for me to undust my compiler and learn again to code. Keep going ;)
Congrats on 100K Subs!!!
Thanks Austin!
I'm 3 years late but this is proving to be one of the best series I've ever watched on UA-cam.
This series is excellent. Thank you.
I think this is the first time I have ever shared a UA-cam video to my Facebook. Keep up the good work.
My thumb up before watching!
Almost 100k subs!
scary stuff!
great video! can't wait til the next one
hey Javid love the videos, I have a question ( fingers crossed you reply :) )
As I said love the videos you really are one of the first coders on youtube to make coding fun :) the question is about the one line coder console engine , you have done a couple of videos on it but my main question is which files on github are the actual implementation of the engine? I can find the header but can't find the implementation( cpp ) files, I would really love to know how the engine works at a lower level :)
thanks!
Hi mark, both the olcConsoleGameEngine and olcPixelGameEngine are just header files. The implementation is contained within and they dont rely on libraries that dont come with your compiler. This makes them very easy to use.
@@javidx9 Thanks Javid for the prompt reply =)
That's pretty cool I never knew you could actually implement functions and classes in a header file, that's neat =)
final question, I noticed that the onelonecoderconsolegame engine and the olcpixelgameengine both use openGL and the Windows API, are these a major part of the game engine? if so , is there any good books on openGL etc that helped you implement the engine,
thanks again!
Why is the msb on line 110 at 12:20 not shifted left? lsb + 2*msb gives 0-3, but lsb+msb gives only 0-2
Иван Назаров Yup, he made a mistake here.
I just cracked my C nes emu thanks to this series! You rock! Can you do a snes one too?
Thanks, I'm pleased you've found it useful. Lol after doing one emulator I don't think I ever want to do anymore, but you never know I did love the SNES too!
Apparently some of those NES arcade cabinets used the lower bits of $2002 to store a validation constant, and I guess you could make your software lock out if it detected an invalid value.
I hate that this was posted at 9pm est but I’m still gonna watch it lmao
2am here in UK I happen to have woken up needing the toilet, and now I'm going to be staying awake for a while!
Nice stuff 👍
Nice. Keep going!
Your explanation is better than nesdev lol.
Do you intend on making videos on stuffs related to system programming like bootloder/kernel, compiler/interpreter, malware analysis or explain how printf/scanf and other standard library functions works, etc?
It would be fun watching these stuffs.
That's just so impressive! Fully working CPU emulation in part 2, and some working graphics from real cartridges in part 4? One thing that makes me curious is how you regulate the speed at which the clock ticks, you can't possibly have several million function calls per second to emulate several MHz of clock speed? Or do you use interrupts for this? I should just look at the source code, but I bet an explanation ahead of time might help :-)
Effectively yes, im emulating about 2 million cpu clock cycles per second, and about 6 million ppu clock cycles. The emulation is actually faster than real time, so i slow it down to make it ~60 fps
@@javidx9 Wow! I assume if it's going that fast you can't possibly do the time adjustment on a per-cycle basis? Do you essentially tick enough times to render a frame, and then sleep until the next one or something along those lines, syncing at each frame to keep 60FPS going?
Looking forward to the next vid. Suggestion, though: get a "pop filter" or move your mic away from directly in front. You're getting a lot of pops.
More gentle awesomeness. Another fantastic video. How do you find the time for this stuff :-)
Lol thanks again Tom, i almost dont. These long videos play havoc with my life in many ways! XD
You’re an inspiration David. I code C++ at Bloomberg but have a major soft spot for hobby game dev. I really like how you present the maths side. I’m currently trying to improve my Calculus.
(@14:19) - I believe that “addr &= 0x000F” will accomplish your task of mirroring a lot simpler; also, what happens if you read 0x3F11 vs. 0x3F10? In your implementation, 0x3F11 in will produce 0x0011 out, but 0x3F10 will produce 0x0000 out - Oops. You would need 16 if-thens; one for each address from 0x0010-0x001F, to cover all the use-cases. HTH. 😊
I don't know if I got this comment wrong, but 0x3F10 would only drop 0x0000 if anded with 0x000F, as you suggested. 0x3F10 & 0x001F = 0x0010, not 0x0000. Remember each hexadecimal digit means a span of 4 bits, a nybble. 1F means 5 bits, effectively making this AND mask catch 5 bits, while 0x000F means 4 bits caught. 0b0011111100010000 (0x3F10) & 0b0000000000011111 (0x001F) = 0b0000000000010000 (0x0010).
Ok well , i am kind of doing the opposite in writing a NES game not the emulator part. Your videos are very helpful. But I have some issues.
1) How do you change the 256 tiles to another 256 tiles for the next level. Currently i am using an example and i can do vram_put(0x4b); to place a K on the current position of screen.
So i get how to change palette memory as well as VRAM (name table memory ). But how the heck do you change pattern memory for a game cartridges. As i can modify any tiles to make a cool image or background. But i am limited to needing different patterns for different levels eventually.
On some carts CHR ROM is in fact CHR RAM so you can pull from program memory and populate the pattern memory. More likely and more used however is that you would instruct the mapper to "remap" the CHR ROM to a different bank. 256 is A LOT of tiles though XD
You should really do a SNES emulator tutorial that would be awesome
In the horizontal mapping section, min 44-ish you don't mention clearing the top 4 bits of addr. It looks impossible following the if statements to see if addr >= 0x2000 but then if addr >= 0x0000 which could never happen. I looked at the code and see addr &= 0x0FFF which fixes it
I hope sooner or later you abstract out the control(lers) into a separate class... I wouldn't consider any console emulator complete if one couldn't connect a game controller (or two) and use that. Whether is a modern controller or one of the many cheap USB NES-style controllers found on Amazon.
Yay
Oh mah dude, bitfields aren't always packed, I had some really bad experience from that assumption, really hard to trackdown bugs
Amazing video;
Thanks Nill!
Flag-Pole Fanfare. Awesome bud.
Wait...
How does this work?
uint8_t pixel = (tile_lsb & 0x01) + (tile_msb & 0x01);
Will this not give the same value for 1+0 and 0+1?
Shouldn't the msb one be shifted up?
Or is this just how the NES works?
Your right, this would never produce a sum of 3. Should be uint8_t pixel = (tile_lsb & 0x01) + ((tile_msb & 0x01)
Yeah he says it's the sum of the two bits, but I think he really meant concatenation of the two?
I had another "I don't understand why" moment at timecode 14:20
That "mirroring" on lines from 207 to 210, really doesn't make too much sense to me.
Jumping back to around timecode 7:40, from what I could understand memory 0x0==0x4==0x8==0xc==0x10==0x14==0x18=0x1C, all being the "background" colour.
So "in my weird logic" it doesn't make sense to only mirror 0x4==0x14, or 0x8==0x18, even less sense to me to do it individually.
Why not just mirror all of them to 0x0? And if I did it right...it seems all those memory locations are the only memory locations to always have the lower 2 bits equal to zero.
Thus, I am thinking that lines 207,208,209,210 could just be replaced with something simular to:
if(!(0x3 & addr)) addr = 0;
and would make more sense, since really all are equal to $3f00 the background?
Right now going back to my half-made NES emulation, and was lost. So dropped by this video. Now my code makes bit sense. And I think I'll proceed with where I left, the sprites
Oof, i would have to start again if i were to return to an emulator! 😂
@@javidx9 seriously, there were many times I felt "this is redundant" and removed it then be like "omg it wasn't"
Somehow, got my hacks removed and implemented it accurate to hardware operations. Though could've been easier if my decisions were better, like choosing -1 instead of 261, my ifs look ugly now ;-l
You're video are really great. But I had a bit of a what the heck moment.
To clarify, I know nothing about NES architecture, but I am a bit familar with emulators in general. The line 110 at timecode 11:56, makes no sense whatsoever to me. If you are "adding" a LSB and MSB, shouldn't the line read:
pixel = (tile_lsb & 0x01) | ((tile_msb & 0x01)
If you don’t mind me asking, but what is you educational background? Are you a math, cs, engineering, etc major and studied at an self-taught, undergrad, graduate, etc level?
I was self taught programming, did a degree in computer systems engineering, then a phd in neuromorphic engineering
around 19:15, what does that colon do there? i dont think i know the syntax of it
Am wondering the same thing :)
its called a bit field, i.e. how many bits i want to use to store that data
Thank you, that is actually very useful to know :)
Great video, javid, really appreciate it! :)
@@javidx9 ooh, helps to know the name of something. so that makes the compiler check that i only use as much of a type as i have permitted. neato
@@joshinils Be carefull however. This does not guarantee the size of your struct. The compiler may add "padding", like blank space between fields.
It does not matter as long as you have a normal use of your structs. It does matter when you use struct to layout memory (for example when reading a binary file, or sending datas to gpu). It also happens when you have something like this:
union
{
struct { bla bla bla };
int something;
};
And write into "something" and then read into the struct fields. Because you'll be making an assumption that the compiler does not guarantee : the layout of the structure.
This is especially true when you mix types ( like struct { float a; int b:1; } ) or bitfields and non-bitfields ( like struct { int a:1; int b; int c:1; } )
You may have no use of this advice right now, but maybe later it will help you "if you don't understand what is wrong with your struct, try to output the sizeof of it".
(and use and abuse of valgrind/drmemory. I couldn't emphasis this enough.)
bg_palette and bg_pixel are always 0. Does anyone know why is this happening?
omg yes.
Why do you add tile_lsb and title_msb? Shouldn't title_msb be shifted left and or'ed in instead?
Color index will never be higher than 2, which is not what you said should happen earlier in the video.
There's something I'm not quite clear on: there is a tblPattern[] variable on the PPU that's holding the pattern table data, but on the PPU::ppuRead() function, we're calling the cartridge's Cartridge::ppuRead() function, which reads directly from the vCHRMemory[] vector on the cartridge. Same thing for the write functions. We only ever use the PPU's variables when the cartridge's mapper fails to map the address that's being read/written to/from.
Is this how it's supposed to work? If so, then the pattern table memory inside of the PPU will never get used in the case of a cartridge using Mapper000, which seems weird to me. Am I missing something?
Edit: I believe I was in the right heh, everything worked for me making the above assumptions.
I got pretty far and then my code just... It gets stuck on a random place (smb) and doesn't set palette. It does load sprites tho.
There is a bug at 11:49. You add the msb and lsb together, but you forget to shift the msb by 1. The code should be uint8_t = (tile_lsb & 0x01) + ((tile_msb & 0x01)
Update on my Java port, About halfway through the video, I encountered some "errors" and the CPU doesn't work. I'm now going to redo the entire project and confirm that everything works at several points during the videos. ill post back here when I've gotten back to this video and again when I've finished this video. Probably won't post again for a couple of days to a week.
Finally got back to part 4. This time it includes the debug screen and clock and frame functions. I got stuck on part 3 with some address errors and then I found out that I had a 15 instead of a 16 when defining how many bytes in the header(java doesn't allow direct reading to classes so I used a byte array instead). But, it works exactly like in part 3 and I can't wait to finish the ppu. Post back in about a day with no errors(hopefully).
I have hit a roadblock. I got to 28:22 when I got to the roadblock. I'm pretty sure that I messed up some vital bit of code in the ppu but it jumps to FFB0 for no apparent reason and doesn't load any characters into character rom. I probably won't post for a VERY long time because I will probably forget all about this project with school and other things but if I decide to review over my code with the code from GitHub, I will probably get it going. This might and probably will be my final post. Goodbye
This is it. I might do another attempt but I don't think I will for a long time. It gets to RTS and since the stack has some value in it that isn't right, it jumps outside of the program and breaks. if anyone wants to look at my code and try to find out what's wrong, be my guest. The code is located at github.com/GamingLiamStudios/glsJNES
I would really be grateful if anyone could help me fix this bug. Thank you.
R.I.P. YT compression @28:20
Parabéns espetacular conteúdo
Phew I am writing nes emulator , cpu ok , cartridge ok , mapper 0 ok ,
Bus ok , but ppu gives me problems I don't know I can't see anything
Although debug counters shows that cpu is working
Press 5 for Lacrosse
Why is the nametable in the ppu class if it's stored on the cart and under the effect of the mapper?
Also, why is the vblank nmi done using a variable that is checked every cycle? Why can't the ppu call a function to let the cpu know? You can even put a forwarder function in the Bus class if you don't feel like giving the ppu direct access to the cpu.
The 2k of vram is stored on the system. The mapper can be in control of the mirroring configuration of the cart. This is distinct from address mirroring. Some carts may also have nametable memory stored on them. Ive shown the simplest case in this video.
insane 💀
I'm a little bit confused about something. At 14:17 mirroring from byte 10 to byte 0, byte 14 to byte 4, etc, is hardcoded. However, shouldn't the bytes at 4, 8 and C map onto 0 as well? I can't see how a read at address 4/8/C results in a read of the background colour
Kung fu a terrible game? Man i loved that game, played it for hours on end lol
I just sucked at it XD
When I run it at 16:00 i get an error after the it has compiled saying vector subscript out of range
it also has piont to this line when i click ignore data = vPRGMemory[mapped_addr];
cannot run project, error : "cannot open source file "olcPixelGameEngine.h" "
You need to get that from the github and add it to your project.
are you having endianess problems while using unions as bit fields ?
Hi Tomer, not really but then i wouldnt see it as anywhere i use the union i only access the individual named bits, so in reality i dont actually care how the compiler represents it as long as its consistant.
@@javidx9 that's what I thought, cool
Please have a read of pull request 15: github.com/OneLoneCoder/olcNES/pull/15
I believe it addresses some issues that I feel need to be corrected in the next video - or at least it reveals something that isn't intuitively obvious about the code that needs further explanation.
I guess this is how people reverse engineer softwarre.
Guy might have coded something once or twice before haha 😅
We do need a series on some heavy emultors like pcsx2 ...
What do ypu think ?
At 20:00 your description of the scan lines it awesome. It really ties in well with Ben Eater's VGA video card build. ua-cam.com/video/l7rce6IQDWs/v-deo.html
"So here is good old Kung Fu, I'm kinda glad it's not working, it's a terrible game"
Are you kind of copying everything bisqwit does ? If so, next is "how to create a compiler".
No, he learned this himself from NESDEV wiki's, it took him 3 months to learn it he said in discord server.
So is it a British thing, pronouncing NES as "nezz" instead of "enee-ess"?
Yoop. Alsou hoob, boos and other stoof.
In Brazil it is also the "nezz". I guess you genesis soccer playing crazy ones are wrong after all.
This is magic :)