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:

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

[mohammednihad]

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

[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.... :)

[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

[viktorhugo]

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.

[sustainable_home]

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

[mastercko]

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

[HObsession]

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!

[nev]

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.

[mmhvd]

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 Youtube 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.

[Gaalua]

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

[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.

[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).

[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. :-)

[karlfochtmann]

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

[gshingles]

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

[robertmenteer]

Your emulator still needs the reset process corrected.