I'm new to CPUs, but I generally understand how they work. I'm trying to use the 6502 as an example to see how data moves around, and Visual6502 and some block diagrams have been helpful. I'm specifically interested in the DPControl aspect of it, but I'm little lost on the timing. Unfortunately, the "wiki" link for the JSSim seems to be broken(not sure if that is long term or just lately).
So I have a few questions:
1) Is there a resource somewhere that charts out the "microcode"(yes I know it's not really microcode) for each instruction, along with its timing(T0, T1, etc)?
2) When I see something like T0+T2 in the state, is that T0 for the new instruction while T2 "finishes up" on the last one?
3) What is the alignment of the timing on the DPControl column? For example, if I use the default program that's in Visual6502, it has an ADC # instruction being fetched on cycle 19. I would speculate this completes by enabling the SB bus for ADD(ADDSB06 and ADDSB7) and loading this into the accumulator via SBAC. However, I only see these two being enabled on cycle 22 after the RTS is fetched.
Another example is before that, in the same code: INX is fetching at cycle 8, but SBX isn't enabled(and subsequently X being incremented) until cycle 11, which appears to be in the middle of the following DEY execution. Is this because DPControl is showing the state BEFORE the "current line" is executing, rather than during/after?
I've searched around and couldn't find any direct answers on this. Can someone please set me on the straight and narrow?
Thanks in advance! This stuff is really exciting.
Visual6502 DPControl?
Re: Visual6502 DPControl?
Welcome!
I think most (or all) of the visual6502 wiki can be found in the Internet Archive, here for example. And perhaps in particular the simulator Help page.
You might already have discovered the Trace More button - you can get a similar effect with appropriate URL parameters, like this.
For more on the T1, T2, etc, perhaps see the pages 6502 State Machine and 6502 Timing States.
Yes, probably, if you see T0+T2 you could think of them as corresponding to the just-finishing and just-starting instruction. I'm not sure if that will always help: the signals do what they do, and the names of the signals are there to help us humans understand. Although, that's a bit flippant, because this machine was designed by humans.
Yes, indeed, you'll see some kind of internal pipelining, in that write-back can happen in the second cycle of the next instruction. That's because the final arithmetic operation can (sometimes) overlap with fetch, and so write-back is in the following cycle. I think that's right.
So glad you're finding visual6502 useful, and enjoying your CPU-internals journey of exploration!
I think most (or all) of the visual6502 wiki can be found in the Internet Archive, here for example. And perhaps in particular the simulator Help page.
You might already have discovered the Trace More button - you can get a similar effect with appropriate URL parameters, like this.
For more on the T1, T2, etc, perhaps see the pages 6502 State Machine and 6502 Timing States.
Yes, probably, if you see T0+T2 you could think of them as corresponding to the just-finishing and just-starting instruction. I'm not sure if that will always help: the signals do what they do, and the names of the signals are there to help us humans understand. Although, that's a bit flippant, because this machine was designed by humans.
Yes, indeed, you'll see some kind of internal pipelining, in that write-back can happen in the second cycle of the next instruction. That's because the final arithmetic operation can (sometimes) overlap with fetch, and so write-back is in the following cycle. I think that's right.
So glad you're finding visual6502 useful, and enjoying your CPU-internals journey of exploration!
Re: Visual6502 DPControl?
BigEd wrote:
Welcome!
I think most (or all) of the visual6502 wiki can be found in the Internet Archive
I think most (or all) of the visual6502 wiki can be found in the Internet Archive
I will go through these links, they look like exactly what I was searching for.
Thank you so much!
Re: Visual6502 DPControl?
BigEd wrote:
So glad you're finding visual6502 useful, and enjoying your CPU-internals journey of exploration!
Are you folks accepting pull requests these days? This is a great tool and I would love to contribute, even if in a small way.
One other question.. I see some datapath control lines that are prefixed with # and ~. I saw in another thread that this has to do with active low signals and one replaced the other, due to one being more URL friendly.
Now, I am trying to understand how to interpret these. I have been using Hanson's block diagram to follow along, but I see very few scattered active low(or inversion) signals on here. Take DAA for instance. It shows up as #DAA and ~DAA in DPControl, but there's no indication of active low in Hanson's drawing. Should DAA be marked as active low in Hanson's drawing, and it only is in Visual6502 from future discovery? If I see #DAA,~DAA in the DPControl column, should I assume both that the signal is low, but it is considered active, as in DECIMAL ENABLE is ON? If this is all true, then would it be appropriate, for purposes of following data transfer, to ignore active high or low, but that the signal is active, if it is present in DPControl? I hope that makes sense.
Re: Visual6502 DPControl?
Yes, we could take pull requests, but I'd want to be incredibly careful not to break the simulator or to break any URLs already published on the web. Testing is difficult... essentially, if we make the smallest possible changes in each PR, and if the intent of the code is crystal clear, I can merge it. And it would be good to fix up any small difficulties. It's just that the stakes are high! Also, after merging into the official github repo, there's a separate deploy step to the live site, which I find very scary and difficult, so I would do that rarely and only with strong motivation.
If you're well-versed in git, you could proceed on a fork, and then marshal a series of very user-friendly PRs from that, perhaps.
Sorry, but I seem to have got the role of gatekeeper, and I'm very nervous!
As for the active-low signals: I think Donald Hanson's diagram is constructed for maximum teaching value, so it's not too surprising if it doesn't pick up every implementation detail. Whereas the naming of signals in visual6502 is a bottom-up one, with many names coming from explorations which later needed to be reconciled with the famous block diagram. A few signals have several names as a consequence.
As for exactly how the DPControl display deals with active low signals, I no longer remember. I suspect the code just lists all the signals which are high. It would have been more code to list all the signals which are active. Can I suggest you run a couple of simulations, in decimal mode and in binary mode, and find out? Or read the code. I think that's what I'd have to do.
(In other words, the further you descend the depths of loglevel, the more there is to look at, and the more you need to become your own expert guide. It's not insurmountable - you're not the first explorer. I will helicopter in and help you out if needed!)
If you're well-versed in git, you could proceed on a fork, and then marshal a series of very user-friendly PRs from that, perhaps.
Sorry, but I seem to have got the role of gatekeeper, and I'm very nervous!
As for the active-low signals: I think Donald Hanson's diagram is constructed for maximum teaching value, so it's not too surprising if it doesn't pick up every implementation detail. Whereas the naming of signals in visual6502 is a bottom-up one, with many names coming from explorations which later needed to be reconciled with the famous block diagram. A few signals have several names as a consequence.
As for exactly how the DPControl display deals with active low signals, I no longer remember. I suspect the code just lists all the signals which are high. It would have been more code to list all the signals which are active. Can I suggest you run a couple of simulations, in decimal mode and in binary mode, and find out? Or read the code. I think that's what I'd have to do.
(In other words, the further you descend the depths of loglevel, the more there is to look at, and the more you need to become your own expert guide. It's not insurmountable - you're not the first explorer. I will helicopter in and help you out if needed!)
Re: Visual6502 DPControl?
BigEd wrote:
Yes, we could take pull requests, but I'd want to be incredibly careful not to break the simulator or to break any URLs already published on the web. Testing is difficult... essentially, if we make the smallest possible changes in each PR, and if the intent of the code is crystal clear, I can merge it. And it would be good to fix up any small difficulties. It's just that the stakes are high! Also, after merging into the official github repo, there's a separate deploy step to the live site, which I find very scary and difficult, so I would do that rarely and only with strong motivation.
If you're well-versed in git, you could proceed on a fork, and then marshal a series of very user-friendly PRs from that, perhaps.
Sorry, but I seem to have got the role of gatekeeper, and I'm very nervous!
If you're well-versed in git, you could proceed on a fork, and then marshal a series of very user-friendly PRs from that, perhaps.
Sorry, but I seem to have got the role of gatekeeper, and I'm very nervous!
I have no interest in working on the simulation itself at all. This is clearly out of my league, as I am obviously still learning. I'm only asking how I can contribute to how the HTML/JS is presented in the browser and bringing a better experience in for newbs. I'll put in a pull request and you can take it or leave it. My question was if they are even up for consideration these days at all, so I might be wasting my time
On the topic, why is the wiki down? Can I offer to host the database?
Re: Visual6502 DPControl?
Yes, if you submit a PR let me know here and I'll see what I can do. Ideally it would be minimal!
For the rest, I'll PM you.
For the rest, I'll PM you.