Some great ideas here folks! Many thanks for that.

RDY is something that has to be fixed, so for sure it’s a great place to start:There was an inverter/NAND combination on the board that I could use (previously used for STP), so the patch proved relatively painless. RDY’ above is the NMOS compatible signal — it stays high if R/W is low, which is what we want. In the final design, I’ll want to make the behaviour configurable, but a hard patch will do for now. A quick run with the Analyzer confirmed it works as expected.

But unfortunately, the problems are still there ...

So, onward! Time to see whether illegals or cycle counts are the issue. The TTL CPU conveniently exposes the pins for the current opcode, as well as the internal cycle counter. Using PHI2 as the capture clock, the Analyzer can easily generate a trace dump of all executed opcodes together with the cycles performed. A little validation program then goes through and flags any illegals or cycle-count anomalies. Here is some output of a trace to illustrate. It shows the sample number, the cycle-count (Q) and the opcode info:Unfortunately (or fortunately??), the games in question show no illegals, and no cycle mis-counts. It’s possible, though, that the CPU still has cycle-inaccuracies where a cycle should be saved but wasn’t. The little validation program would not detect these situations since it just compares against a table of allowable cycle counts for each opcode. Nevertheless, it’s progress, and it’s certainly good to know illegals are not in the mix.

A likely next step is to compare the opcode streams generated with the 6510 and the TTL CPU respectively and see if that reveals anything. Thanks again for the several suggestions above on how to do that!

More to come ...

_________________
C74-6502 Website: https://c74project.com

I am thinking about a way to get a post-mortem-dump to figure out what the last few hundred actions of the questionable program was. If say IK+ crashes - does it looks as if this happens always in the same way? If, then could you figure out how many cycles it runs before it crashes? Perhaps then you could trigger your analyzer somewhat before the actual crash to trace whats going on. Perhaps it is even possible to interrupt the program to get a mem dump before the crash happens, then resume it. Although taking much time, this interruption not necessarily forces the program to crash - at least this could be verified by doing the same action earlier.

Another - perhaps simpler - way to verify whether it is a timing issue: if you explicitly insert a dummy cycle into a medium frequent instruction (like LDY,ABS) - does that change a lot?


Good luck,
Arne

Just trying to sort the clues we have so far:

0) CPU bus timing is supposed to be correct (else, we would have _other_ problems).
1) "illegal" instructions are not used.
2) RDY is supposed to work like in the NMOS 6502.
3) Commodore Basic floating point works, so it probably isn't a bug in the Flag evaluation of the "legal" instructions. //Had this with M02.
4) test suite did work, so the "legal" instructions are "supposed" to work as intended.

IMHO this leaves three possibilities:

5) cycle inaccuracy somewhere in a "legal" instruction.
6) something "odd" that happens in the CPU during a page_crossing. (Branch or relative\indirect addressing ?)
7) something wrong with our "replication" of the stray reads, so a flag in a peripheral chip (6526 ?) isn't cleared as intended.

// I would vote for 7). On second thought: check 6) first.
Edit: probably not helpful, but check if /NMI is LOW when the game crashes...

Hmm... 31 years after the release of the game, Archer MacLean probably won't remember that code.

Good luck with debugging.

Nice cleanup ttlworks.

Deleted - superflous - overlooked a hint in ttlworks post -

Dieter, your instincts are spot on!

While following GaBuZoMeu's advice last night, I was looking to capture one of the games "in the act", and saw it in a tight interrupt loop. When I checked /IRQ, sure enough, it was stuck low. I had not put two-and-two together until you mentioned it, but #7 above is the likely reason. Nicely done!

Now, I know for certain that the CPU doesn't correctly reflect the NMOS behavior on stray reads -- in fact, I have a note on my "to be done" list to update the microcode to make sure that's the case. Seems like a good time to do that.

It's also worth desk-checking the other items on the list (page-crossings and legal cycle counts) while I'm at it.

Thanks!

_________________
C74-6502 Website: https://c74project.com

GaBuZoMeu, thanks for helping us with this project.

So it's 7) stray reads.

Hmm... many years ago, when I had built my M02 TTL CPU, I had tricked a macro assembler in 68k mode into generating the microcode.
For hardware related reasons, there was a limit to the amount of microcode steps a 6502 instruction could have, of course.
And because I was using macros it wasn't easy for me to spot if I had exceeded this limit somewhere in my microdode by accident.
My solution was to write a little "quick & dirty" C program that had scanned the microcode binaries,
giving me a list of the amount of microcode steps I had used for every 6502 instruction, just to be on the safe side.

Drass, IIRC you use Excel for writing the microcode.
Would suggest to export that Excel list to CSV text, then to write a little C program which checks that CSV text
for the stray reads and the cycle counts somehow.

Edit: fixed typo.

Thanks for the suggestion, Dieter. As it turns out, I already have a program to export the microcode to Logisim. It can be easily modified to validate cycles.

But the first step is to make sure we know what the "correct" behaviour of dead cycles is (i.e., cycles in which the CPU is busy with an internal operation and leaves the bus in some "temporary" state). Some of these dead cycles result in NMOS "stray" reads, but we know there are lots of subtleties and inconsistencies here. Given the various permutations of addressing modes and page-crossings on both NMOS and CMOS versions, just getting it all straight is a bit of a challenge.

To tackle it, Dr Jefyll and I put together a list of test cases, and I set about methodically to validate each on both my 65C02 SBC and the Visual 6502. The results were very interesting to say the least. One notable highlight is that, as Jeff pointed out, the "fix" that the 65C02 introduced to avoid stray reads during page-crossings was to simply leave the address already on the bus and reuse it during the dead cycle. That address is often PC, but is sometimes not (during indirect indexed addressing, for example). It can be confusing, but having a table which summarizes things sure helps.

So, here now, after many revisions and improvements suggested by Jeff, is a table documenting the dead cycles we are aware of for both 6502 and 65C02 variants (a pdf versions is also attached):The next step is to change the microcode to reflect this, as well as to figure out how to deal with instances when the TTL CPU dynamically generates micro-instructions during page-crossings. More on that later.

Cheers for now,
Drass

*** EDIT *** While working on updating the microcode for the TTL CPU, I ran across some dead cycles we missed the first time around. I've updated the document (now on revision 1.1) to reflect this, attached below.

_________________
C74-6502 Website: https://c74project.com

A remarkable work
I am eager to know whether this will cause some/most/all of the not yet running games to work seamlessly.

That's some really nice work, Drass and Jeff...
and I have to admit that I had under_estimated the time and the effort this would take.

Looking forward to see, if this fixes the little compatibility problem, or if we have to dig a bit deeper (page crossing etc.)

Go, Drass, go !

Thanks Dieter! Gotta keep moving forward.

I spent some time updating the microcode, and in the process found a few dead cycles we missed the first time around, as follows:

JMP (abs, X) -- Cycle 4
RTI, PLP, PLA, PLX, PLY -- Cycle 3
BBR, BBS -- Cycles 5 and 6*

I've added these on the document and updated the post above. At the same time, I noted that a couple of incompatibilities will likely have to remain in the TTL CPU. This is due to the specific way in which certain internal functions are implemented, as follows:

• 65C02 abs,X/Y write w/o pg. crossing -- this is the "annoying" bug whereby the CPU reads the target address before writing to it. The 65C02 fixes the problem if a page is crossed. On the TTL CPU, the microcode does not distinguish between a page-crossing and the lack of one (it simply adds the internal carry in both instances), and so we're stuck with only one possible behaviour. I've chosen to make the 65C02 "fix" apply whether or not a page is crossed. The same is true for the 65C02 INC/DEC instructions with an abs,X addressing mode.
  
• NMOS 6502 RMW Modify cycles -- the TTL CPU lacks the ability to write to memory while storing the ALU result in an internal register during the "Modify" cycle of RMW instructions. The function is simply not needed other than to support this particular aspect of the NMOS 6502, and I didn't design for it. So instead we are forced to execute "two reads and one write" for RMW instructions as the 65C02 does.

Arguably, these are both improvements, but that's not what we're after here. My guess is that the "65C02 abs,X/Y" incompatibility is unlikely to be a problem. I'm not as optimistic about the NMOS issue, however. We know programmers have used many NMOS side-effects to benefit at one time or another. That said, the C64 does not seem to have any FIFO type queues that might be sensitive to a different number of reads and writes in RMW instructions. A write to a CIA Interval Timers does have a different function from a read (specifically, a write sets the Timer Latch while a read returns the Timer Counter), but this only means the write of a RMW instructions is delayed by one cycle (R-R-W vs. R-W-W). This delay would have no impact when the Timer is stopped, and I suspect no impact of consequence when the Timer is running. I can't think of other potential problems this issue might present on the C64 (which of course does not mean there won't be any!).

While I was at it, I checked for dead cycles in Undocumented Opcodes, and made sure those were correct as well (as it happens, the microcode in the TTL CPU uses a common set of fundamental microinstructions for all opcodes -- a set of primitives as it were. As a consequence, fixing dead cycles for documented opcodes also dealt with undocumented ones in passing). All in all, therefore, I feel fairly confident that dead-cycles are replicated accurately for both NMOS and CMOS modes (with the above-noted exceptions). If this is in fact the problem, these changes to the microcode *should* address it.

Time to burn some ROMs!

_________________
C74-6502 Website: https://c74project.com

Nice to see this project is still ongoing.

Good luck!

A

Thanks Axel. Nice that you dropped by.

I’m still stuck on the problems described above. The four games I’m working on remain broken on the TTL CPU. This even after I updated the microcode to correct the behaviour of dead cycles. I have no idea what the problem is, but at least it’s nice to know RDY and dead-cycles are now implemented properly.

I get the feeling tracking down these last remaining incompatibilities is going to be tricky!

Cheers.

_________________
C74-6502 Website: https://c74project.com

Axel, thanks for dropping by.

Drass: sorry to hear, that the new microcode didn't fix the problem.
Forgive me if I'm wrong, but I interpret your text above in the thread as:
"I updated the microcode to make the dead-cycles of the TTL CPU as similar as possible to the dead-cycles in a NMOS 6502,
but I haven't checked if the TTL CPU does as intended."

To sum up the things we have so far:
TTL CPU goes into an infinite loop somewhere in the code with /IRQ stuck low.
This might be a sign for "an incompatibility somewhere".

;---

My suggestion is to check with an oscilloscope, if the TTL CPU does a read access to the 6526 at $DC00..$DCFF
(U1 pin 23 is /CS) while the loop is running with /IRQ stuck low.
There is supposed to be a read access to $DC0D for clearing the Bits in the 6526 interrupt\status register
for bringing /IRQ back to high again.

If there is no read access, then I think there still might be something wrong with ABS,X or ABS,Y addressing modes
of the TTL CPU, maybe during address calculation while there is a page crossing.

In this case, take a logic analyzer and focus on the IRQ vector pull for finding the start of the IRQ interrupt service routine.
Because then there _is_ supposed to be a difference between TTL CPU and NMOS 6502 when it comes to executing the machine code,
and maybe we would have to disassemble the interrupt service routine for spotting that difference.


Go Drass, go.
Feels like we are almost there (ok, so it feels like this for more than 9 months already...).
Good luck !

I mentioned this before but without any context or description:


Hoglet's code takes a databus-and-control-signals trace from a cheap 16 way logic snarfler, and decodes the 6502 or 65C02 activity, disassembling as it goes and highlighting interrupts and any discrepancies of the system vs the model. Should be ideal for tracking down cycle accuracy or bus activity accuracy differences in a new 6502 or 65C02 implementation. Dave recently found some bugs this way in Jens' "true cycle" core, which have now been fixed.

Are you able to log trace from logic analyzer enough to see what's the difference between real 6502 and TTL 6502? I started to custom build such a logic analyzer to find out the reason for one of the last errors in my design. I found the reason before I got very far in analyzer build.

A.