Nice set of articles: flagged as toread.

One quick note: with the visual6502 project (http://www.visual6502.org/), and the c-implementation (https://github.com/mist64/perfect6502), a fun way to test your emulator timing is to run it in parallel with the gate-level simulation, and compare them. For example, I do this with my golang 6502 emulator: https://github.com/zellyn/go6502/blob/master/tests/compare_t...

Nice project zellyn; I've got one with the same creative repo name: https://github.com/pda/go6502 ;) Mine currently makes no attempt at being cycle-accurate; it's basically the dev/test environment for a breadboard 6502 computer I'm working on.

Very nice. I used v6502 a lot as the article shows, but the real fun comes with the cycle-stretching, which AFAICT can't be simulated using v6502.

Hmmm. You should be able to pull the same lines up/down or pause the clock the way the real hardware does it.

My 6502 is a little rusty but wasn't it always faster to decrement the index? Don't compare to 10 each time, just decrement to zero. You save one instruction, which was probably a few clock cycles.

Yes, and never forget the BMI opcode.

Absolutely yes: I was just showing an example, not the most optimal code :)

Just reposting TempleOS's post (which, being hell-banned, many won't see). Plus, it's a little less ranty than usual :) Without further ado:

----------

To me abstraction above the hardware is like condoms. Some people say "Use three condoms, its better". I don't want a literal C64 -- just the complete open simple access... but 64-bit and 3Ghz and multicored. I don't want it to run on a 386, just x86_64.

I was trying to parse that earlier, but it doesn't make sense. Is he saying he wants something as open as a C64, but running on modern hardware?

he wants access to the bare metal on the same level as the C64, but with modern hardware.

POKE 53280, 0

Accidental down vote, sorry!

Makes perfect sense to me.

I think this is really awesome stuff. Now please someone turn this into a product. Take existing FPGAs and the synthesized hardware, and some place and route data, and generate cycle perfect simulations. If you do this, I can almost guarantee that you will be acquired by one of the big HDL companies, and you might even get to make a tool widely used and loved by EEs on the Internet everywhere. We've got spice online, we've got schematic capture online, now cycle accurate hardware simulation is the next target.

> Take existing FPGAs and the synthesized hardware, and some place and route data, and generate cycle perfect simulations.

> now cycle accurate hardware simulation is the next target.

Can you clarify this? Do you mean, take a 6502 HDL model, place and route it to an FPGA and back-annotate the PaR data into a simulation testbench that runs in an online simulator?

Yes. (could be an RTL model, something post HDL) You have that?

Cycle accurate models have been a product for a long time - I was writing them for a job over a decade ago.

Don't confuse them with timing accurate models, which also stimulate where in the clock cycle levels change. That's the class of model you would be interested in place and route data for.

I agree, I've got a copy of ModelSim which I use for that, I was wondering if someone could create a 'simulator as a service' using JS code in a browser. If you can take the RTL description of the synthesized hardware and create a model that runs in a browser, then you can have your browser do a quick check of your HDL while you are working. People compile so many things into JS these days, why not hardware?

Hey Chuck, you should do this :-)

To me abstraction above the hardware is like condoms. Some people say "Use three condoms, its better".

I don't want a literal C64 -- just the complete open simple access... but 64-bit and 3Ghz and multicored.

I don't want it to run on a 386, just x86_64.

Nothing quite so stark and sublime as hacking away with registers and memory alone, eh? Ring 0 is pretty cool place to be, I'll grant you that.

I think perhaps what I long for is the knowledge that I could gain a _total understanding_ of the hardware, ROM, timings - things were simple enough back in the day. The commodore 64 and other 8-bits are like that, and I've seen talks given on the c64 that seemed to lay bare every secret. I have so much respect for those hackers that know a device through and through with history and anecdotes related to the thing to add color to their own vast understanding.