The speed is impressive, honestly! Last march I wrote a 6502 emulator in Rust, and ran it on the pico / RP2040 along with a partner RP2040 wired up to act as a dummy EEPROM. The effective speed I saw in that setup running the same klaus test suite was about 1MHz.
Thank you. I just ran a simple counting program using ehbasic, and the emulator is over 6 times faster than the same program using the 1 MHz 6502 TIM. However, I think the best thing about an emulator is not the speed; but that we, as mere mortals, can actually "design" a CPU that works. Congratulations on your emulator!
Pretty neat ;) And yep, I was expecting more speed. That’s because I kept forgetting the RP is not running that fast. I’m also thinking that you made a compromise too for memory. As if you were repeating the code instead of having subroutines the thing would be a tad faster. But by how much I dunno. Don’t keep us hanging too long for the next episode ;) Kudos to you, David
Thanks. I mostly repeated code; there are only a few long routines that I branch to. There are a few cycles during each instruction where I restore register values to make debugging easier (register 4, op codes) that perhaps slow it down by like 5%. I might be able to save a couple more cycles here and there by optimizing code. Managing flags take a long time; you can make a fast; not so accurate, emulator; but I opted for as accurate a model as possible. For instance; I worried about how the "reserved" flag was modeled; and you never use the reserved flag! I have run the TIM monitor and Tiny Basic on emulator and they seem to run fine. I'll also see if I can find a benchmark that gives a more accurate speed number. Thanks for watching!
now I want to write my own 6502 emulator :D one idea would be to use Ben Eater's 6502 breadboard computer replacing the 6502 with the pico. and/or run Wozmon on it.
That would be an interesting project. When I finish porting the TIM; it will have all the functionality of Wozmon plus the ability to load and save programs using the MOS Technology hexadecimal file format; see my video on the TIM for more info (ua-cam.com/video/BcqRvHkn-EA/v-deo.html).
I would think the interpolator hardware with masks and shifts on the Pico might aid in the 8 bit simulation? I don't think I've seen you use it. It's an interesting bit of silicon
Interesting, I was expecting it to be much faster .I wasn't expecting it to be so awkward to do simple things like 8bit subtraction .I suppose that's because the rp2040 is optimised for 32bit operations where bits and bytes take a backseat. I have written quite a bit of 6502 assembler , but I don't think I can remember a single instruction now Stay young David, don't let time win. Merry Christmas.
Thanks; I think time will eventually win; but not without fight. I really like programming the 6502 (my first love); but I can see why the ARM machines are a lot more capable. Subtraction was difficult because of overflow and carry flags. In microprocessors; those flags are set in hardware (very fast); but not so in the emulator. This is because the 6502 treats these flags a little differently than other microprocessors. Plus, with a 32 bit machine; you need to play with bit 8 for the overflow; which requires a lot more code than you would think. Old school with ones and twos compliment worked much better.
@@LifewithDavid1 Yes, this is where an 8 Bit Platform for running the Emulator comes in handy, if it provides the neccessary Flags (mostly). I also had bad Times with the Substract with Carry, until i figured out that the C-Flag of the AVR, where my Emulation was running, behaves differently from the one in the 6502. That took quite a while to figure it out.
That would be interesting; but probably not economical. It looks like you can still get new Western Design Center W65C02 chips pretty easily from Mouser ($10). With the level shifting hardware (3,3V to 5V); you would have three times that in a replacement module. But that would be an alternative if the W65C02 ever goes out of production. Thanks for watching!
Why was addition and subtraction so difficult? uxtb r0, r0 uxtb r1, r1 add r0, r1 cmp r0, #255 ble nocarry //set carry flag nocarry: uxtb r0,r0 or am i missing something???
The overflow flag is what makes it difficult. The 6502 treats the overflow flag just a little differently than many other processors of the day. Binary addition isn't too bad. The binary subtraction is more difficult. There are eight different cases of signed operands that affect the result, carry, and overflow; Ken Shirriff's blog (see the link in the description) goes into much more detail. Using ones and twos compliment subtraction was much purer and more efficient then testing for each case. BCD arithmetic adds another layer of complexity. I reviewed several tutorials on nines and tens compliment subtraction. A lot of emulators just ignore BCD; but I wanted to get it right, including the carry and (hopefully) the overflow. Klaus's test does not exercise the overflow flag for BCD math. Thanks for the comment!
That's amazing. Thank you so much for sharing this.
Glad you enjoyed it! Check out the next video where the emulator does some actual old school work. Thanks for watching!
The speed is impressive, honestly! Last march I wrote a 6502 emulator in Rust, and ran it on the pico / RP2040 along with a partner RP2040 wired up to act as a dummy EEPROM. The effective speed I saw in that setup running the same klaus test suite was about 1MHz.
Thank you. I just ran a simple counting program using ehbasic, and the emulator is over 6 times faster than the same program using the 1 MHz 6502 TIM. However, I think the best thing about an emulator is not the speed; but that we, as mere mortals, can actually "design" a CPU that works. Congratulations on your emulator!
Respect. Thank You.
My pleasure. When I get the TIM working; you'll actually be able to do something. Thanks for watching!
Pretty neat ;) And yep, I was expecting more speed. That’s because I kept forgetting the RP is not running that fast.
I’m also thinking that you made a compromise too for memory. As if you were repeating the code instead of having subroutines the thing would be a tad faster. But by how much I dunno.
Don’t keep us hanging too long for the next episode ;)
Kudos to you, David
Thanks. I mostly repeated code; there are only a few long routines that I branch to. There are a few cycles during each instruction where I restore register values to make debugging easier (register 4, op codes) that perhaps slow it down by like 5%. I might be able to save a couple more cycles here and there by optimizing code. Managing flags take a long time; you can make a fast; not so accurate, emulator; but I opted for as accurate a model as possible. For instance; I worried about how the "reserved" flag was modeled; and you never use the reserved flag!
I have run the TIM monitor and Tiny Basic on emulator and they seem to run fine. I'll also see if I can find a benchmark that gives a more accurate speed number. Thanks for watching!
now I want to write my own 6502 emulator :D
one idea would be to use Ben Eater's 6502 breadboard computer replacing the 6502 with the pico. and/or run Wozmon on it.
That would be an interesting project. When I finish porting the TIM; it will have all the functionality of Wozmon plus the ability to load and save programs using the MOS Technology hexadecimal file format; see my video on the TIM for more info (ua-cam.com/video/BcqRvHkn-EA/v-deo.html).
I would think the interpolator hardware with masks and shifts on the Pico might aid in the 8 bit simulation? I don't think I've seen you use it. It's an interesting bit of silicon
Wow! I seem to remember seeing interpolators with the RP2040, but it didn't stick. I'll have to look at that, maybe it would help. Thanks for the tip!
Interesting, I was expecting it to be much faster .I wasn't expecting it to be so awkward to do simple things like 8bit subtraction .I suppose that's because the rp2040 is optimised for 32bit operations where bits and bytes take a backseat. I have written quite a bit of 6502 assembler , but I don't think I can remember a single instruction now Stay young David, don't let time win. Merry Christmas.
Thanks; I think time will eventually win; but not without fight. I really like programming the 6502 (my first love); but I can see why the ARM machines are a lot more capable. Subtraction was difficult because of overflow and carry flags. In microprocessors; those flags are set in hardware (very fast); but not so in the emulator. This is because the 6502 treats these flags a little differently than other microprocessors. Plus, with a 32 bit machine; you need to play with bit 8 for the overflow; which requires a lot more code than you would think. Old school with ones and twos compliment worked much better.
@@LifewithDavid1 Yes, this is where an 8 Bit Platform for running the Emulator comes in handy, if it provides the neccessary Flags (mostly). I also had bad Times with the Substract with Carry, until i figured out that the C-Flag of the AVR, where my Emulation was running, behaves differently from the one in the 6502. That took quite a while to figure it out.
@@NeverMind-pk4wz I can see that. I also think operation of the 6502 overflow flag is not consistent with some other platforms.
Now if you could build a breadboard that would let you emulate the hardware so you could build a replacement 6502 chip
That would be interesting; but probably not economical. It looks like you can still get new Western Design Center W65C02 chips pretty easily from Mouser ($10). With the level shifting hardware (3,3V to 5V); you would have three times that in a replacement module. But that would be an alternative if the W65C02 ever goes out of production. Thanks for watching!
Why was addition and subtraction so difficult?
uxtb r0, r0
uxtb r1, r1
add r0, r1
cmp r0, #255
ble nocarry
//set carry flag
nocarry:
uxtb r0,r0
or am i missing something???
The overflow flag is what makes it difficult. The 6502 treats the overflow flag just a little differently than many other processors of the day. Binary addition isn't too bad. The binary subtraction is more difficult. There are eight different cases of signed operands that affect the result, carry, and overflow; Ken Shirriff's blog (see the link in the description) goes into much more detail. Using ones and twos compliment subtraction was much purer and more efficient then testing for each case.
BCD arithmetic adds another layer of complexity. I reviewed several tutorials on nines and tens compliment subtraction. A lot of emulators just ignore BCD; but I wanted to get it right, including the carry and (hopefully) the overflow. Klaus's test does not exercise the overflow flag for BCD math. Thanks for the comment!