Emulating a CPU in C++ #35 (6502) - Bug Fixing + Bonus Real 6502

In this video i address a bug in the cycle counting that was pointed out by superkplunk. As a bonus i also have a little footage of a real 6502 (in the from of a Commodore C64C).
I've also included what is a bascially an outtake video, where i was going to try and get an assembly language program working in the real C64 so i could test out some of the code I was trying to emulate. However the only assembler software i have isn't really up to the task.
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...
commons.wikimedia.org/wiki/Fi...
Timestamps
0:00 Cycle count problems
1:47 Fixing load registers tests
5:30 Fixing addressing cycles
11:40 Known issues
13:25 Verify test program works
14:05 (BONUS) A real 6502
16:43 (BONUS) Failed real 6502 assembler

[@cigmorfil4101]

You might want to try to contact the 8-bit guy - he has a lot of commodore kit - and he may be able to help you with testing things, particularly 6502 oddities.

[@Dakkidaze]

This series is such a treat to watch. I love it.

[@adrianohaha7659]

Loved the whole series, though I'm not a programmer. Would love to see you refining and using this further.

[@jorenheit]

Made it all the way :-D thanks for the journey, learned a lot!

[@DerykRobosson]

That was a fun series. Thank you for creating and sharing. I look forward to whatever may come next with the creation.

[@DavePoo]

It was my pleasure

[@neeyotube]

I realize I'm late to the party, but while researching the 6502 for my own project, I found some notes that explain some of the cycle count quirks. I'll paste them here, hoping they may save others from pulling their hair out wondering why LDA ABS_X takes a different number of cycles than STA ABS_X when they're essentially doing the same thing but in reversed order. All single-byte instructions waste a cycle reading and ignoring the byte that comes immediately after the instruction (this means no instruction can take less than two cycles). Zero page,X, zero page,Y, and (zero page,X) addressing modes spend an extra cycle reading the unindexed zero page address. Absolute,X, absolute,Y, and (zero page),Y addressing modes need an extra cycle if the indexing crosses a page boundary, ** or if the instruction writes to memory **. The conditional branch instructions require an extra cycle if the branch actually happens, and a second extra cycle if the branch happens and crosses a page boundary. Read-modify-write instructions (ASL, DEC, INC, LSR, ROL, ROR) need a cycle for the modify stage (except in accumulator mode, which doesn't access memory). Instructions that pull data off the stack (PLA, PLP, RTI, RTS) need an extra cycle to increment the stack pointer (because the stack pointer points to the first empty address on the stack, not the last used address). RTS needs an extra cycle (in addition to the single-byte penalty and the pull-from-stack penalty) to increment the return address. JSR spends an extra cycle juggling the return address internally. Hardware interrupts take the same number of cycles as a BRK instruction (even in the case of RESET, which goes through the motions of pushing the return address and status on the stack, but doesn't actually alter the stack). Source was nparker.llx.com/a2/opcodes.html under the "Instruction Timing" section roughly 1/2 down the page.

[@DavePoo]

Thanks, this is very useful, i wish i had read this before i started. It explains why things like NOP are 2 cycles and not 1, as it is always doing an extra cycle no matter what.

[@francoisdastardly4405]

@@DavePoo please pin on top the message from Alexander

[@cigmorfil4101]

The different behaviour of STn and LDn is due to the pipelining of the 6502 achieved by synchronous memory access. Every clock cycle the 6502 is doing an internal operation and an external memory access. STA abs,X and LDA abs,X use the same first 4 clock cycles: 1 - fetch OP Code; PC++ 2 - fetch absL; PC++ 3 - fetch absH; PC++, absL += X 4 - read abs; page cross ? absH++, force cycle 5 : This is where LDA and STA differ. For LDA if no page cross continue with next instruction; otherwise do cycle 5 after absH++ 5 - read abs For STA if no page cross do cycle 5 anyway, otherwise absH++, do cycle 5 5 - write abs Note that *both* read an address (abs with absL modified by X) in cycle 4. For a LDA if there is no page cross, the memory address was the correct address and so the data wanted is read as part of the pipelining meaning the next instruction can be fetched and run. However if a page boundary is crossed the address read is 256 bytes less than the real address as absH has not been updated. Hence the need to re-read the data from the correct address and the extra clock cycle. For a STA if cycle 4 was a write it would write the value before checking if a page boundary had been crossed. If no cross then no problem, but if there was a cross the address written would be 256 bytes prior to the correct address - not a good idea! To prevent this possibility the STA instruction forces the write to wait until after the cross check which means it has to wait until cycle 5 - the cross check and absH++ occur during cycle 4.

[@nev6502]

Thank you very much for this series Dave; I'm on video #3 and will be following through. Your information is immensely valuable

[@DavePoo]

You are totally welcome

[@lockybrand5728]

This series was awesome, you inspired me to program my own emulator, fantastic work mate

[@UTRG-UnderTheRain]

He's inspired me to do it also sadly for me I have neither the skills or the talent and so my ineptitude just saved myself months of work (I'm about 3 weeks into Java I started c++ but a programmer I know convinced me to swap to Java so that's where I am right now my first real attempt at learning to code)

[@jeelybeenz]

Brilliant, I really enjoyed this series :) thank you.

[@DavePoo]

No problem

[@abhaychirania9813]

Oh man it has been a great journey. Sad to see this series endiny.

[@sanderbos4243]

The outro with all the references to the picture you took of the box is so funny, where you DO have it, but are unable to use it, like owning a vault without its key. :P

[@monkey_see_monkey_do]

It's like Bluefever Software's series on programming a chess engine in C but about processor emulation - a super didactic top content that is gonna be on the cards forever. Thanks you for your hard work Dave!

[@DavePoo]

You are most welcome.

[@monkey_see_monkey_do]

@@DavePoo Dave, I'm now trying to do the same in x86 assembly to come up with a bootable version and there's a couple of question, please be kind to answer if you have some spare time... 1. Not clear what's going on with Program Counter - I mean FFFC seems to be a place where processor is LOOKING FOR A VALUE of where the program starts and doesn't start there, also FF00-FFFF memory range seems to be a ROM, not RAM, can you please clarify this if possible? 2. Another question is this addressiong starting from FF00 - I can't get how it can start with FF00 when in Apple 1 for instance there were only 256 byte, but those bytes still were addressed FF00-FFFF? 3. And the most significant question - in m6502.h file it seems like not all of instruction supported or did I miss something (I watched only first video in the series which is brilliant and was fairly enough to start my own project - THANK YOU SO MUCH FOR THAT!)? Thanks in advance! It's ok if you don't have time to answer ;) EDIT: Just figured out that actually ALL the instructions are supported - I was fooled by a mixture of addressing modes for LDA/LDX/LDY etc. and single byte op codes like TAX,TXA etc, so question #3 is no longer on the cards, sorry for bothering!

[@davidhayward1426]

Great series! I think you may have a bug in AddrZeroPageY. There is a variable of type Byte the you then increment by Y. I would expect this to wrap around is the result is greater than 255

[@stephenwhite506]

Love your work and explanations. If you want, take a look at the 6502 emulator I wrote for the Pi1541 project. It is a T cycle exact emulator written in about 700 lines of C++.

[@DavePoo]

Thanks, I had a quick look, it looks very good. You've implemented lots of undocumented behavior as well. The cycle counting is definitely a big deal if you want to implement these emulators properly. github.com/pi1541/Pi1541/

[@MrPDawes]

One of many things I liked about the BBC micro was the inclusive Assembler built into the BASIC interpreter. This allowed easy embedding of assembler code for stuff that needed to run fast like I/O drivers and BASIC for UI. It also meant I learned a lot about the bits and bytes of the machine and the memory map. Just need to do this Emulator in Python now.

[@DavePoo]

So i heard, the BBC micro implementation of BASIC was the best.

[@jonohiggs]

It would be absolutely fantastic if you wrote did another series writing a (maybe reduced) c compiler including backend for 6502 architecture

[@dw1664]

BBC BASIC, which is the resident interpreter of 6502-based BBC Micro, rather handily (and famously!) features an inline assembler which is far less quirky than the one you have been battling in this video. There are several excellent Beeb emulators around - for instance, BeebEm is practically perfect (after all it runs Exile and Elite !). I don't think there's anything to fear in using an emulator rather than real hardware - BeebEm's 6502 emulation must surely be balls-on to run all those sophisticated games and demos. It's an option to consider. :-) Thanks for producing these very interesting videos.

[@DavePoo]

Yeah, i just used it because i had it, turns out It's a barely usable assembler. I since bought a BackBit cart so I could load TurboAssembler or something else onto the machine but the cart doesn't work on my c64

[@padcom]

I wonder if someone already made the remark that when writing tests you shall see it fail first and pass second. That eliminates the "your tests are not robust enough" and "your test is a bit doggy".

[@__3093]

keep uploading

[@peterward2875]

Thanks for sharing. Some observations: 1. Nice to know I'm not the only one who's fingers get ahead of him while typing. :) 2. I think the processor has to take an extra step whenever it's messing with the PC or doing a "far pointer" to a full memory address, since the data bus is only 8 bits, whenever it's loading both bytes into the PC or as an address, it seems to take three steps; as if it's pointing to the first place, has to change the addressing lines in another tick, then transfers the next byte. Like every time you're doing the combined "memory[x] & (memory[x+1]

[@DavePoo]

1. The fingers are sometimes quicker than the brain 2. nparker.llx.com/a2/opcodes.html - I think this page has some good information (and was posted by a viewer after i finished this series), but it seems the timing of the instructions is not quite as simple as i first thought, and sometimes the CPU is wasting cycles by reading memory addresses and then discarding the information (see the section on "Instruction timing") 3. Yes, i think something like that could work.

[@martin-wallace]

Reading/interpreting the instruction page for the Assembler64 program I'm assuming you can run your compiled program by using RUN/STOP to exit the program, then run your SYS 49152 command to execute your program in memory, then you can return to the Assembler64 program by running GOTO 200. Also, the GO is referring to the short cut for your JMP etc operations. So JMP GO100 would jump to line 100, whereas omitting the GO (JMP 49152) would jump to the absolute address. You can also use the short-hand AS variable/label which is always set to the start of code - JMP AS+42 would jump to the address of start of code (ie 49152) plus 42 bytes (equiv. to JMP 49194). Does that help?

[@cigmorfil4101]

13:45(ish) PulLing the processor status off the stack (PLP) will result in the processor status having the flags set to whatever was on the stack - there are no privileged bits.

[@cigmorfil4101]

BRK cannot be stopped by SEI.

[@oeauoaeqjj1984]

you are a mazing

[@arkanjo7509]

thanks

[@CedLePingouin]

Thank you for this series, which I found incredibly interesting. I was wondering about your plan to simply subtract cycles once at the end (beginning?) of each instruction, instead of trying to guess how many cycles each "part" of an instruction consumes. You said the latter was not necessary since the 6502 always executes a full instruction anyway, even when an interrupt has been triggered. I guess that's true. But if you later implement I/O and ways for the emulated CPU to communicate with other chips, isn't it possible that some "events" happen "in the middle" of certain instructions ? I'm not an expert at this kind of stuff, so maybe I'm thinking too hard here :-) .

[@DavePoo]

Yes you could be right about that, maybe the approach i have done does have some advantages, but with just the CPU emulated it doesn't appear so. The only thing that is good i could see right now is when i was implementing some of the later instructions, i didn't have to insert any new cycle counting stuff as it was all handled already by the existing functions. I think to step the clock in synch with all the other emulated chips would be super accurate, but would probably require a re-write of the current CPU to do that (as it would have to stop in the middle of an instruction while another chip did something), it maybe that the emulation to that accuracy just isn't required to make a good emulator, and would require an in depth study of the computer architeture to answer that question (e.g. Maybe the CPU gets control of the bus until it's finished an instruction, so it doesn't matter anyway).

[@CedLePingouin]

@@DavePoo I just watched the (very interesting) video of Matt Godbolt, mentioned by tm barral in another comment. He's talking about how he progressively changed the way his emulator worked to account for sync with the rest of the hardware. So I guess I have my answer :) . That's what scares me the most if I ever decide to try and write an emulator. Even if the CPU I choose is relatively "simple", all that timing stuff and sync with other hardware is often giving me a headache. I'm not that good at electronics, and those "half cycles", "cycle stretching" and so on seem like a whole new world of pain :)

[@DavePoo]

Yeah, there is no doubt that creating an emulator for an entire system, even one as simple and old as the C64 or other 6502 computer is a lot of work. Actually i think that's what i wanted to show in this video series, that it can take a while to get this stuff working and correct, and a lot of time might need to be put into research of how the real system works. That said, it shows that creating your own emulator is totally doable if you are willing to put in the time (actually if you add up the time of this whole CPU series, it's actually probably only a few full days of work, but it took a long time as i was doing it in my spare time). Also, you'll never get it right first time, so you have to be willing to change as you go. Which is why i think it is important to have good tests written as you go, so you can refactor stuff and get some confidence that it is still working. Like i mentioned, if i did decide to refactor the cycle counting, i don't think i would change any tests, just the internal code to the CPU emulator.

[@CedLePingouin]

Yes, even though it seems like a lot of work to write emulators, it has always fascinated me, and this series makes me want to try. And I agree, the use of a test framework is a big plus in this series, and something that you don't often see in this kind of videos.

[@EdwinNoorlander]

Aks the 8Bitguy.

[@johnkelfy7256]

Older computers always seemed like magic to me

[@DavePoo]

I find all computers are like magic. Even when you take a really old chip like this one, the technology and centuries of scientific discovery that went in to getting to that point are asounding.

[@MichalMracka]

Maybe I missed something, but... For the "not ending" testing program - could you not compare the PC value for 2 consecutive steps, and break the loop, if it is the same? It either executes an instruction and increments PC by 1-3; or in case of a jump changes to a completely different value. The only case it stays the same would be when it jumps to the current PC (which is the actual SUCCESS/FAIL state).

[@KellyMurphy]

You could use an assembler on the PC and then poke it into the c64, or just manually look at the hexcodes and poke it in. Though anything longer then a dozen instructions might suck to do like that.

[@DavePoo]

I could do that, it would work, but i would also like to not go insane

[@AxeMurderer2222]

Try GOTO 49152 also might try entering instructions without a line number to see if it will execute them like an interpreter

[@theretrogamer5930]

Hey do you know how to add video or graphics, I am trying to make a NES emulator, it will help

[@lukasz-mf5ri]

I have tried to add condition on interrupt flag for BRK and actually it fails this test program... I dont know why...

[@christopherlawley1842]

Did the assembler highjack the BASIC interpreter?

[@arham9006]

this what rosetta on mac m1 do ? to make app competible with intel proc ?

[@twobob]

by 33:00 I am like "Why not just write the shortest possible test program and compile it. Then simply POKE the byte stream into the memory, Then SYS from that location?" Is the issue the actual viewing of the flags during the subsequent execution? Perhaps the test prog could just throw them out on the console Also. If this program is written in basic which you load - and then run - so we could either just LIST the files guts there? Before issuing Run? No? One might derive more about the available commands

[@newtonsheikh]

awesome stuff! are you on twitter?

[@DavePoo]

Thanks, i'm not on Twtter.

[@johnkelfy7256]

Dave Poo based, and redpilled

[@Stabby666]

I would have thought JMP/CALL/EXECUTE xxxxx might work?

[@MrRobbyvent]

28:50 lol "go" !!! I think the problem was that You jammed Commodore basic calling an LM routine which was terminated incorrectly. Now You have always "syntax error" then just reset the C64 to have it working correctly again. EDIT: long story. When You perform "sys 49152" You're actually performing a "jsr 49152" somewhere from basic which espect "rts" to return back correctly from machine language. If something went wrong Your stack gets corrupted and maybe critical memory locations too. Just remember that. You have a simple CPU, no memory protection , no advanced features: 6502 simply executes its instructions in sequence, mono tasking. Multiple tasks: You jump here and there quickly. Always full access privilegies. Your software must keep track of everything, respect OS reserved RAM locations and never get lost.

[@szabolcsmate5254]

What you need is a "kung fu flash cartridge". You can load any program, or cartridge image through this, and loading an action replay or final cartridge image will give you a monitor.

[@DavePoo]

Since this video, I've actually bought a BackBit cartridge, but sadly it doesn't work properly on my C64C

[@szabolcsmate5254]

@@DavePoo ahh what a shame, and how annoying. I got a Kung Fu with my old "brown" breadbin and works fine, and I had an original Action Replay (III?) back in the day with the beige C64 I had then. Both worked great for me. But the Fung Fu explicitly says that due to tight timing it may not work on every machine, so I guess I was just lucky with that. But you may be safer going with an original "hardware" cartridge.

[@duanewebber1514]

@@DavePoo i had a 64C as well my Snapshot v5/4 ? .... worked awesome , i believe its a canadian product from the eighties

[@georgrenelt1948]

It would be better to decode and execute the commands based on the "native" instruction matrix, because the position in the matrix tells something about the "physical" execution. Instead of implementing each operation i'd chose to create a matrix of command objects at runtime from the original matrix (-> www.oxyron.de/html/opcodes02.html). These objects manipulate the cpu infrastructure - in my understanding this saves you from fiddeling around with "specialties", because they are more a native or electric property. As a side effect it should be more independent from the actual 6502 design and is easier to match to other 65xx and maybe 68xx cpus. But: I like your approach from a standpoint of learning - c and 6502 assembler... ;)

[@DavePoo]

Yeah possibly. I didn't do that as the CPU is so simple with so few instructions. If i was emulating something like the Motorola 68000, even a CPU that old has so many variants of each instruction that the instruction set would be in the 1000's, so it would be a better approach i think for any CPU more complex than the 6502

[@CZghost]

So I finished the playlist of this series. Watch here: kzbin.info/aero/PLY8fEeQNSS-5ja0kSykwSILI5Nw4GQVO2

[@thezood]

This series made me want to code something but I don't know what.

[@DavePoo]

Pick something simple to start with. Try ascii tic tac toe or something like that.

[@64jcl]

Likely your tape drive head is misaligned so it gets read errors on the tape. And yes Interceptors assembler is an odd beast. Those variables are addresses though. It was quite usual to just code assembly directly into memory and just run it there. But ofc if your program had a critical error you would loose your source and all if you didnt save. :) - Btw if you hit RUN/STOP + RESTORE, it breaks back to default basic where you can type SYS 49152. If you then type RUN after it will run the assembler again but your program is lost (lol). Btw here is a small test program you can write: 10 LDA =1 20 STA 1024 30 RTS This will show an "A" in the top left corner of the screen (which is by default memory mapped to 1024-2023). The developer of this assembler Ian Gray programmed quite a lot of C64 games and chances are he actually made this assembler to make the first games. It was quite common back in the early days to code your own tools as you neither had the money to buy good stuff or they didnt exist at all. Some coders like the Darling brothers (who eventually started Codemasters) made their own game development kits where they churned out title after title and even releasing the game dev tool as well. Its quite clear that the many Codemasters Dizzy games (and other variants of this) were in fact made so they could be easily ported between all systems easily. This is very evident as the C64 versions of these games had just some fancy graphics put on left and right side as the ZX Spectrum for example only had a 32 columns screen (256 pixels) so all screens in those games are designed to fit that width, while the C64 ofc had 40 columns (320 pixels). :)

[@DavePoo]

Yeah, it is an odd little program. Quite cool that you can write something like that in BASIC. Really shows just how powerful BASIC was if you had the time to work with it.

[@twobob]

Yeah Excellent. Feels like organising you a SD loader for the c64 might move this forward? What say you? Done with this? Fun times anyway, thanks.

[@DavePoo]

I'm considering moving this into an Unreal engine plugin and continuing it from there to emulate a full system

[@twobob]

@@DavePoo Excellent, Unity also provide a wrapper for c++ blobs but the declaration used to be a bit agonising. Hopefully they updated it. I had a Vic20, this really brought back memories. Thanks

[@EdwinNoorlander]

Look at www.c64-wiki.com/wiki/Final_Cartridge_3 for the commands.

[@H2Obsession]

The 6502 doesn't have a B (Break) processor bit, nor an "Unknown" processor bit internally/electronically. These are just bit positions (4 and 5 respectively) that are written to the stack when a PHP / BRK instruction or an IRQ / NMI "command" are executed. Bit 5 is always written as 1. Bit 4 is written as 0 only when an IRQ or NMI (or RESet?) is processed; or as 1 when PHP / BRK is executed. Because there is no B (break) or Unknown bit inside the CPU, the value read from the stack (with PLP or RTI) is ignored by the CPU. I think a more accurate name for the Break bit is the Not_Interrupt bit. But that takes longer to say and write, and requires processing negative logic to understand it... so nobody uses that term. But that's how I think about it (call me crazy). You can "prove" the above logic with a simple program like this: LDA #0 PHA PLP ; the B and U bits (if they existed inside the CPU) would now be zero PHP ;write the flags on stack PLA ;get the flags to Accumulator At this point you should find on real hardware that A = $30 = 0b00110000 ... B and U bits are 1 because they are fake. This strange B flag behavior is because, although RESet and NMI have dedicated vectors, BRK and IRQ share the same vector. So the 6502 programmer is responsible to examine the data saved on the stack to determine which occurred. The programmer MUST examine the stack data, and not the registers with PHP/PLA for example. Crazy but true.

[@DavePoo]

Thanks, this is super helpful. I think you can see in the video i was pretty confused by those bits. I really did want to get that C64 working to test stuff like this but it was a bit of a disaster as you could see.

[@PaulOvery001]

Dave, Big thanks for the series. How about making a Tapuino on the cheap (supports emulator tap files). David Watts has a good video on this including maker links. (I was shocked when I made one and it just worked, first go, now I'm hooked on Arduino's) If you have the energy, use a C64 rom and see if you can fudge a display. This gfx lib by OLC is really nice for starters. (OLC has nice mix of c++ videos on his channel) github.com/OneLoneCoder/olcPixelGameEngine/wiki

[@DavePoo]

Thanks. You mean to get files into the C64. I think i will get one of the SD2IEC boxes to get stuff into the C64. I am considering taking the emulator further, and if so it would be a C64 emulator. As so many good C64 emulators exist, i think if i did do it, then i would embed in Unreal engine as a Plugin. I was thinking about how possible it would be to make a networked C64 that would allow 2 players to play the same game over the internet. It would require that both games were determinisic and the ability to roll back the entire emulation if there was a misprediction in the input. I'm not convinced my idea would work though, as i think it would cause horrible glitches in the sound when the input was mispredicted.

[@samba3403]

you need to exit from the assembler program to execute the memory location

[@toby9999]

That's what I though also. I did a lot of 6510 coding in hex way back in the 80's on the C64. I created my own hex monitor because nothing decent was available and there was no assembler.

[@wChris_]

i suggest using a much better assembler like "turbo macro pro" which is free and i think you can load programs with your phone and a cassette adapter. also a much faster solution is to use a sd2iec adapter

[@DavePoo]

Thanks, since this video i actually bought a BackBit cart to get stuff onto the C64 but it sadly doesn't work correctly on my machine.

[@somedude5414]

Anyone here see Ben Eater's YT channel where he BUILDS a real 6502 computer on a bunch of breadboards? Very Geeky cool!

[@DavePoo]

Yes and I can highly recommend watching it.

[@jeffmerlin2580]

Did you try "JMP 49152" (without line number) to start running?

[@DavePoo]

Apparently you need to do "SYS 49152" but you need to call END first to exit the machine code program otherwise it doesn't work.

[@theretrogamer5930]

Do you know a way to keep the emulator running even if there are no instructions. I mean like it just runs

[@DavePoo]

Not sure i understand that question. If the CPU is running, then it executes instructions.

[@theretrogamer5930]

@@DavePoo I mean that the CPU just keeps on running even if there are no instructions, I tried doing this by removing cycles from every function. I also added an instruction "ins.ext" which quits the loop and it work fine for now.

[@tmbarral664]

doh. I'm feeling useless here... dunno the C64. I was/am an Applemaniac. On a Apple //, a simple call -151 would have been a real treat to check how the real cpu is behaving.

[@DavePoo]

I have since been told that i needed to call "end" to stop that assembler program (which is written in BASIC!), then i would have been able to call "sys" command to run the comiled program. I think i want to get my hands on an SDCard interface for the C64 then i can load up turbo assembler and compile some stuff. Or could compile in the PC and then load it onto the real machine. That assember i tried looks like it would work, but there is stuff it can't really do (it's not a proper macro assembler, so writing code in it is going to be tricky, and i couldn't set the compiled location of the code, so couldn't create an interrupt handler very easily. Also those line numbers are a real pain when writing assembly).

[@tmbarral664]

@@DavePoo I watched an excellent video some years ago on 6502 emulation. A bit of a struggle to find it again but here it is: kzbin.info/www/bejne/bYjYg6RjjNKqa9E Not to mention one from Michael Steil exposing the guts of the beast : kzbin.info/www/bejne/nIjUc6CjhbaDapI. And the Ben Eater serie on building a 6502 computer: kzbin.info/www/bejne/gp_dpoCAgb-Fmrc Lot of fun ;) Viel Spass !

[@DavePoo]

Ah yes, Matt Godbolt. He is very good, and the author of the compiler explorer website. Which is very handy when you are trying to find out what your compiler is doing to your code.

[@cigmorfil4101]

The PET had a machine code monitor which may exist in the C64. If it executes a BRK instruction it entered the monitor. Doing SYS 1024 would enter the monitor as 1024 always contained a zero byte. On entry to the monitor the R command (below) is automatically issued. The PET monitor has the commands: .G [XXXX] goto the given address or current PC .L"fn",DD load a file .M SSSS FFFF dump memory .S"fn",DD,SSSS,FFFF save memory .X exit to BASIC .R dump registers .: XXXX XX XX XX XX XX XX XX XX set memory .; GGGG IIII PP AA XX YY SS Set registers: GGGG value of PC IIII value of IRQ vector PP value of process status AA value of A XX value of X YY value of Y SS calie of stack pointer The memory dump and register dump commands display the data on the format to change them, so you can cursor over the values, replace them and hit RETURN. When the Go command is used it loads the values of the registers as displayed by the R command.

[@TheMenaceProd]

maybe you got the syntax error because your program still said "110 sta var instead" of "110 sta va" and the error comes from the executing not doing sys 49152 (which should be the way to execute code on that location)?

[@TheMenaceProd]

nvmd ...just gave it a try in vice, doesn't work either

[@padcom]

27:49 You should be banned from YT for the longest clif-hanger in the history of clif hangers! :D

[@johnkelfy7256]

*Making a cpu that is older than you*

[@martiekr]

Just ditch the crappy C64 and use a Acorn Atom. The Acorn Atom has a build in Assembler that is part of the basic syntax. love it. if you are programming and you see some basic code is slow, just write it in assembler and call the assambled machine code where you had the slow basic code. Try one of the many Acorn Atom emulators there are out ther.

[@DavePoo]

Crappy! Blasphemy!

[@martiekr]

@@DavePoo You might need the Atomic Theory and Practice manual to operate the Acorn Atom. Roms can be found and downloaded, like from here: www.acornatom.nl/atom_handleidingen/aw123/acorn_roms.htm

[@degeneriert]

Hm. Isn't the C-64 using a 6510 (not:6502)?

[@DavePoo]

Yes

[@johnkelfy7256]

Please check the spam of this comment section youtube is filtering a link I sent

[@johnkelfy7256]

Hey! Please check that video KZbin video id: EhK5JNx0irA Minute: 15:01 The CPU you are trying to emulate had bugs.

[@DavePoo]

Yeah, i think i left a note about that addressing bug in the code somewhere. In in this emulator i didn't really address bugs like that and illiegal opcodes (which progams did use). It shows why writing an emulator can be harder than you think, as once you got it doing all the things it's supposed to do, you then have to get it to do all the things it wasn't suposed to do.

[@mikewollmann]

omg, that "assembler 64" ur using is horrible, if you can find a tape, 5.25 or listing of smon, then try smon, thats way easyer, and theres a nice documentation online but the series of ur 6502 cpu emulation was rly nice, now i rly know i dont want to spend that much time in trying it myself *hides*