Hello! I have been playing around with the visual6502 simulation code. I ported it to lua in an attempt to understand it better (which worked), however in testing some things I discovered something that confused me. Shuffling the updates done in recalcNodeList(), or even just shuffling the allNodes() recalc done in initChip() causes the simulation to fail. What assumption(s) are these shuffles breaking that the simulation is relying on? It seems like the node numbering is significant.

Oh dear, that would not be good news. Because the simulation iterates (after each input change) until nothing's changing any more, it's always been hoped, and believed, that the order of evaluation doesn't matter. Certainly, the node order is more or less arbitrary - no special care has been taken as far as I know.

Can you give any details, or examples, so we could try to track this down in the JavaScript?

(If you know C, you can similarly experiment with Michael Steil's perfect6502, a port to C of the JS original. It's faster, of course.)

Oh, and welcome to the forum!

Thanks! I do know C, but I've been playing with the JS version, so i'll stick with that for now. (:

I may have spoken a bit too soon. It seems that although the states the simulator goes through are different (i checksum a list of all high nodes), the output is the same. At least up to the 10k cycles i was testing just now. I do occasionally see different values in some registers (X, Y, SP) but it doesn't seem to have affected the program's execution (the PC and memory match).

I'm using nodejs and a small shim script to run the simulator from the command line. The program being executed by the chip is just the small one included in testprogram.js.



shim.js:


Shuffle test locations:


With no shuffles, the last lines of the simulation are:


The 242 is the number the test program is incrementing.

And here are some examples with both shuffles enabled:


I'm assuming this isn't caused by the way I've pulled the simulator out of the rest of the code. But that is entirely possible. Perhaps i'll check against the C version.

I'm not convinced i know what's going on at all here. Intuitively it makes sense to me that different converged states could lead to the same behaviors (some state information just gets discarded), but it is kind of disconcerting to see different values showing up in the registers.

Update before i actually post: it happens in the C version too. Like with the JS version, it doesn't seem to actually cause the simulation to diverge (aside from X, Y, and occasionally SP containing garbage). I took it out to 100k and 1m cycles and it seemed like it was behaving?

The four tests i ran at 1m cycles actually all came out identical:

Hmm, well, I don't like the sound of register values coming out different! Can a modest-length simulation show the same? I'm hoping we can track down the point of divergence somehow. Looks like we'll also need to use a PRNG which gives us control of the seed.

As it happens, Dave (hoglet) has found a need to improve the resolution of node values, for a different MPU. I wonder if that will solve this one too. See this commit.

I suspect the garbage in the registers is due to settling during initialization. The test program doesn't store into X and Y; it only in/decrements them.

I also tested splitting recalcNodeList() into two pieces: the first which calculates the new states of node groups, and the second which updates the transistors controlled by individual nodes. This removes the dependence on evaluation order, and it still seems to simulate equivalently. It's basically treating the transistors as being "slower" than any path of propagation of state through nodes. I don't think it's necessarily better than the other way though. The visual6502 way is still completely deterministic unless you switch around node numbers (untested), or deliberately shuffle the recalc order (tested above).

Interesting, thanks. Sounds like it's worth (me or you or someone) doing some experimenting with code which does initialise the programmer visible state.

For example this program computes pi:
http://goo.gl/FXuoI
(not a great choice of test program, but I knew where to find it)

I can confirm that the order of evaluation DOES MATTER!

I have created a netlist for the MOS8501R4 and started debugging it with M. Steil's perfect6502 code. What I can say so far is:

The CPU crashes right after the reset sequence with a wrong PC due to a glitch on a few signals.
BUT: If I reverse the order of evaluation the CPU enters the user code correctly - no glitch.
I already tracked down the datapath control lines responsible for this misbehavior but I didn't nail down the exact line and timing.

ooh...

Here's a snippet of a problematic section:



Here's the output of one bit of the ALU with the two signals ADD_ADL and ADD_SB.

Unfortunately either ADL or SB get tied to ground before the input lines of the ALU are
disconnected leading to a destroyed PC on the rising edge of PHI2.
If I simply reverse the order of evaluation in the code the PC doesn't get destroyed.

In order to track down I added some dump functionality for specific signals and I can
see that a few signals change state TWO times in one iteration.

I now have tracked down one problematic section and can explain it:

Some background info:
In the simulation the signals propagate iteratively from (connected) nodes (let's call these Group #A) to the
nodes affected by changes of the gates connected to the Group #A. Let's call this Group #B (Or A+1 as
it's the next node group that will be evaluated).

The problem:
Now we have these non overlapping clock signals PHI1+PHI2 which means that one of them goes high after
the other one went low and also let's assume PHI1 lies in Group#X.
Due to the non overlapping nature of the signals PHI2 has to lie at least in Group#(X+1)
(X+1 means it changes at least one iteration after).

So far no problem.... BUT: The registers for the data path control lines also generate and use a signal
PHI1# which is directly derived from PHI1. Hence it also lies in Group#(X+1) too.

In my case the problem stems from the fact that signal PHI2 gets high BEFORE PHI1# is high in the simulation.
PHI1# is used to invalidate some signals controlling the ALU input and PHI2 is used to control ALU output.

In other words: The ALU output gets connected to an internal bus before the input to the ALU got disconnected.

IIRC, those datapath control drivers are circuits which show evidence of late changes in the 6502 layout, so possibly this possibility of a race was present also in early prototypes.
http://visual6502.org/wiki/index.php?ti ... timing_fix

I was able to work around that issue by disconnecting the on chip clock generator and generating both signals (PHI1+2)
manually.

After fixing a "flaw" (which made my pull up detection fail) in the layout of the 8501R4
(obviously present in ALL 850x derivatives) I got the simulation running.