Emulating a CPU in C++ #34 (6502) - Missing Instructions & Success!

In this video i implement the remaining missing instructions and address some other fixes. At the end there is a recap and retrospect of the entire 6502 emulator.
Links:
Source for this project: github.com/davepoo/6502Emulator
Google Test: github.com/google/googletest
6502 Information: www.obelisk.me.uk/6502/
6502 test program: github.com/Klaus2m5/6502_65C0...
Timestamps
0:00 Problems from last time
1:12 SBC Zero Page
6:00 SBC Immediate
9:37 SBC Timelapse
10:44 Rerun test program
13:28 If you got here then...
14:41 Conditional branch fix
18:55 Recap and Readme
25:52 Retrospect and future work
33:50 Closing comments

[@mohammednihad6755]

Finding your channel feels like finding a hidden treasure!! Keep going please 💙

[@Gaalua]

Congratulation on this achievement, it's a very nice piece of work and I enjoyed this serie a lot!

[@DavePoo]

Thanks, was a bit of an adventure. I had no idea how it was going to turn out. Could have been better, but it did ok in the end

[@karlfochtmann8712]

Really great videos!!! It's great seeing the work flow as you go

[@DavePoo]

Thanks, I saw a lot of people had done emulators but nobody had done the whole thing on video. So this is my attempt at that.

[@karlfochtmann8712]

@@DavePoo I've actually been inspired and writing the emulator in QT, my c++ needs some work, I've always been dealing with C using pic micro. Brilliant videos!

[@mmhvd66]

Thank you for making this journey! Watching the series was a nice trip down memory lane to the 80s when I had access to an Apple ][e. I can still remember seeing some of those opcodes and wondering what it meant. I have recently watched Ben Eater on KZbin building his breadboard PC, which greatly improved my understanding of how a CPU works. Your series has provided me with even more insight into the intricacies. I liked the style of the videos, but struggled a bit with the small text... but hey, I've been around since the sixties of last century.

[@DavePoo]

Yeah, the Ben Eater stuff is great, well worth a watch if you want to learn more about how a CPU works. I really love fact that you can learn so much about a computer/CPU in 2021 and it's a CPU that somebody sat down and desiged in the early 70's, you've got to respect the people who made those achievements back in the day. As for the small text, if you look i've got visual studio on 273% zoom, unfortunately, it doesn't zoom the text for the debugger.

[@sustainable_home]

Thanks a lot Dave! Very inspiring. I’m writing the emulator in Python. Keep up the good work!

[@raevod6361]

He hasn't uploaded in a year

[@willofirony]

Well done. I learnt so much, in particular, the value of GTest and the niggardly parts of operands such as BRK and RTI that an assembly programmer would just ignore. BTW the NOP following BRK: a debugger would , on selecting an address, copy the bytes at [address] and [address+1] into a table of structs holding the address and contents of the breakpoint. Then replaces those two bytes with 0X00EA. On continue, these actions are reversed. Why two bytes? That was a safety belt for two byte operands. A smart debugger would replace the break point in case it was in a loop. I was struck by your apparent lack of frustration. In fact the only time you seemed completely stumped was the "If you have made it to here" section. I think this was you required a change of mode of operation. Up to this point you were working in a "let get this part working" mode, rather than a "let me get this project finished" mode. The sign of a good programmer.

[@mastercko]

Never fixed "Verfify". 😉 Seriously though, excellent work!

[@nev6502]

Dave, I made it! It was rewarding to learn through what you've done, follow along, do things a bit differently in areas, work ahead of the video (Eg. I was loading programs very early on) then watch to see how it turned out, etc. I've made it through to the end and we are 1:1 in functionality. THANK YOU; this has been on my bucket list for 15 years. In relation to your closing comments, I'm afraid I must beg you; before moving on, please could you do a video on decimal mode? (if that is not far too much to ask). This is one of the best series I've ever followed and it's time to make a huuuuge comeback! You're popping up in the feeds, and your fans are SALIVATING for more! You asked me to ask, and I'm asking, and damnit you were right I am only one commenter. But it's SO CLOSE If you need the real C64 to be able to get through this, I can send you an SD card reader for it.

[@DavePoo]

Thanks, i've actually got a working BackBit cart now but i've not had much chance to do anything. You are right about the decimal mode, i never get around to doing that and it would be required to get a fully working CPU (never did interrupts either, and possibly other things i have forgotten about).

[@JulianOnions]

Congratulations! Loved the journey. You could get it to load C64 programs, you'd have to implement some sort of virtual IO though. A screen, keyboard.... :)

[@DavePoo]

Yeah, one thing to take away from this is that a cpu alonoe can't really do anything. All the fun comes from the IO, like the video and sound and input support hardware.

[@DavePoo]

Oh and there is one more video to come!

[@coxsj]

Excellent! Thank you!

[@viktorhugo8252]

This is a very good project. sometimes it is easier taking the real CPU for old programs. if you have the sources you can translate it for another processor. for demonstrate the OP-codes it will help to understand the executions. for exact timing and small interrupt routines you can’t fix this without a lot of work around. take the old 6502 if this is fast enough, or take the 65816 to solve your software problem. dissembling the old code on any machine is much easier as simulate the original mnemonics to emulate and executing a real 40 years old program.

[@H2Obsession]

Great video series. I would often slap my forehead and ask why is he trying to emulate a 6502 without understanding how it works first: lots of basic mistakes that you took a long time to work out and did a fair amount of guessing... BUT you persevered and got a decent emulator in the end. Good job! Thanks for sharing the journey. Just some thoughts: You did not read the cycle timing about branch wrong; the website you referenced wrote a bad description. Your primary reference didn't give a good description of BRK... in fact even official MOS documentation fails to describe it adequately. In fact I don't know a single complete description. I learned some things: 1. BRK sets the I flag (makes sense now that I think about it). 2. Calling a lambda within a lambda. 3. Using Google unit tests! 4. Assigning an expression to a single-bit-field value (like Flags.V) can fail unless you force the expression to boolean, like (x & 0x80) > 0. Anyway, thanks again. And congratulations on surviving 2020!

[@DavePoo]

Thanks. One of the goals i had with this was to show that you don't always finish up where you thought you were going. And i deliberately tried to avoid looking up too much stuff before hand as i wanted to write all the lines of code on video. It's kind of a response to a lot of KZbin video stuff i've seen where people just snap their fingers and all the code magically appears and it's clearly the Nth attempt, so it's much better than you would get if you tried it yourself. This is my first pass at doing an emulator like this, and i just learned it as i went. if i wrote one again would i do it different? I think so, but what i did end up with is something that works pretty well, needs improvement and would benefit from a rewrite to make it simpler or faster or more concise. I also learned 1, 2 & 4. I've used GoogleTest before so that doesn't count. Although that BRK was more confusing than i would have expected at the start. I think some people in the comments have posted saying about how much stuff i got wrong in this video, but i think maybe they didn't realise that when i said "what better way to learn how a CPU works", it was me that was doing the learning. I'm not trying to show people how to write a perfect emulator or how to write perfect code, i'm trying to show that the road to success is paved with failures (also there are quite a few mistakes that got corrected as i went along, it's a shame the video wasn't as popular when i was making them as it is now otherwise i could have corrected a lot more a lot sooner thanks to the comments being posted).

[@twobob]

Excellent series. "The sort of project you could do in 2 days" I believe was your original estimate? ;P Really enjoyed. Would obviously love more after the next more but hey ho ;) Thanks

[@DavePoo]

Not far off on that estimate i think. If you add the time of all the videos together + thinking time and stuff that was edited out. It isn't too much more than a few working days of code to get as far as i did.

[@DmitryKandiner]

29:50 Probably building the processor emulation starting with the emulated pipeline, command decoder and ALU would have been more easy (and would provide clock emulation intrinsically).

[@64jcl]

At this point I'd likely make my own "virtual 6502 machine" in that I'd make some sort of IO so that you could run a program that outputs to a screen and reads input. At that point you basically have a fully working virtual computer. As an experiment you could take something simple like a small Vic20 text adventure by Scott Adams and just take a look at the source as it likely just calls the Vic20 kernals print functions and keyboard read functions (each acts as a different channel where you just call CHROUT and CHRIN). You could make your own "kernal" that outputs this to your screen as well as read the keyboard input and respond to the kernal calls to read a char from the input device. Commodore made a very decent OS actually when they made the Kernal which made it very extendable and easy to emulate as well. A program that doesnt POKE directly into the graphics, sound or IO registers of the machine can be fully emulated through the kernal calls. If you take a look at sta.c64.org/cbm64krnfunc.html you can see all of them, and its a very managable set.

[@DavePoo]

Sounds like a great idea. If you fully did you own virtual machine, you are not limited to the instruction set of the 6502. you could extend it and add "multiply" or other things. However you would then start having to write your own assembler or extending an existing one and that goes deeper down the rabbit hole.

[@64jcl]

@@DavePoo , yes personally I'd stick to the 6502 family, perhaps 65c02 as it has some nice additional instructions. The fun thing is that you can actually run a lot of code already out there now and sort of emulate the IO chips of many of the consoles that have simpler display logic. Stuff like an Atari 2600 is a difficult beast as the display there is controlled realtime as the CPU runs, "chasing the raster beam" kind of coding. But most of the other ones used memory mapped character screens so its basically setting up where in memory the screen should be displayed from and depending on the system it also has separate registers to add sprites on top of the character display. The character sets themselves are also often memory mapped, which enabled games on those systems to have some decent custom graphics compared to the early terminals. :) - That said, a lot of C64 games for example often used tricks like repositioning and swapping out sprite positions mid-screen to enable having more than the 8 hardware sprites at the same time. Same was done with character maps and bitmaps. Coding for the C64 is rather fun as its down to the metal development.

[@glibbond168]

Damn...

[@AndersJackson]

Might want to write some IO devices to connect to the CPU. Yould be a GUI or connecting to real IO on a RPi. :-)

[@gshingles]

Can you not say "while (cpu.PC != 0x336d)" for your 6502 test program. I mean, if it gets there it means it succeeded? :)

[@DavePoo]

That could work, but if there is an error then the test will loop forever and stop all subsequent tests, so i don't want to leave that test in.

[@gshingles]

@@DavePoo yeah, I realised that several hours after commenting. :) Good job though, it's opened my eyes to test driven development.

[@robertmenteer3462]

Your emulator still needs the reset process corrected.

[@DavePoo]

Yeah, i wouldn't really attack the proper reset unless i was starting to emulate a full system.

[@lordsmeagol3390]

The RESET process basically loads PC from the RESET VECTOR. Using some more unions may be useful: // define the bit numbers (0 to 7) in the flags register static const enum FlagBit { B_Carry, B_Zero, B_InterruptDisable, B_Decimal, B_Break, B_Unused, B_Overflow, B_Negative }; // define the bit fields (0b00000001, 0b00000010 ... 0b01000000 0b10000000) in the flags register static const enum FlagField { F_Carry = 1

[@piwex69]

I am sure you have seen this :en.wikipedia.org/wiki/WDC_65C02#Logic_features (section Bug Fixes) -> it points out all this strange bugs/or/features of original 6502. I belive you have not implemented one of them (incorrect boundary handling i JMP indirect).

[@thomasfriedrich2001]

Yes, you could star it :)