6502.org

Yup, that was it! After the patch, the game runs! And if you wait long enough ...The game crashes exactly in the same way as with the 6510 installed ... amazing. (Btw, how cool would it be to fix that bug after all these years. )

But either way, I’m super happy with the fix. Just for fun, below is a capture showing an NMI hijacking an IRQ already in progress. Interestingly, RDY happens to go low just before the three write cycles of the BRK routine, and the TTL CPU finishes the writes before pausing, just as the vector low-byte is being fetched (/FCP.AD goes low). The byte that gets fetched eventually is the NMI vector. Very cool!

Ok, now for the bad news: the 15ns “Lost NMI” window remains. The fix for that part didn’t work. Turns out I really do need an extra flip-flop to properly fix the thing, so that will have to wait for the next rev of the boards.

In the meantime, Impossible Mission still hangs, so the hunt continues!

Cheers for now,
Drass

A leap forward - and bug-compatible!

Drass,

Did you post the logisim file(s) somewhere in this huge thread ?

If not, could you do so ?

I'm curious how your circuit compares to Warren's Microcoded CPU https://minnie.tuhs.org//Programs/UcodeCPU/index.html

Sure did.

viewtopic.php?f=4&t=3493&start=150#p47678

I’m not sure if the zip file worked out, so please let me know if you have any question/issues. More than happy to help.

One note: it’s been quite some time since I’ve updated the model. I know I left it in a consistent state, but it may not have some of the more recent tweaks. I hope it helps.

Cheers,
Drass.

Lol, right after my previous post in this thread.

Senility / laziness is a terrible thing

Thanks.

Mike

Thanks BigEd!

Having looked at it more closely, I can now confirm that the “Lost NMI” 15ns window does not exist in the TTL CPU after all. Turns out the window only occurs during phase2 and is always over by the time the NMI pin is sampled on the fall of PHI2. The two events never overlap and NMI transitions are always properly detected regardless of when they arrive.

Ok, glad that’s worked out ... time to move on to the next bug!

Alrighty then ... the boards are getting harder and harder to patch, with jumpers chris-crossing each other and ICs repurposed here and there. And yet there is more: turns out Impossible Mission also suffered from a “Lost NMI”.

I didn’t know whether to feel dismayed or grateful at this point. Truth be told, these bugs would have been nearly impossible to find were it not for these two games (IK+ and Impossible Mission). In each, the code hangs within a few seconds of start, and the Analyzer shows the problematic interaction between IRQ, NMI and RDY just before the breakdown very clearly. Nice!

In the end, the solution here was to inhibit sampling of the NMI pin at the beginning of the vector low-byte fetch, and to resume only once the final SYNC cycle of the BRK sequence is finished. In this way, a “Late NMI” is safely deferred until after BRK completes. The NMI will then interrupt the sercond SYNC of the ISR in progress (just as happens with the NMOS 6502).

Here now is the patch:And with that, Impossible Mission came to life!

Differences in the TTL CPU to the NMOS 6502 handling of NMI are now as follows:

1. NMI is sampled on the fall of PHI2 (rather than the rise of PHI2 for the NMOS 6502),
2. A “Late NMI” arriving after the vector low-byte fetch must persist past the completion of the final SYNC cycle in the BRK sequence, or it will be lost. This means the minimum pulse width for a “Late NMI” is 4 cycles (rather than 2.5 cycles for the NMOS 6502).

I don’t think I can get a closer match to the NMOS 6502 behaviour without adding more ICs to the boards. Here’s hoping that won’t be necessary. By way of recap, the compatibility changes we have so far are as follows:

• Implemented NMOS 6502 RDY to pause only on Read cycles
• Verified the behaviour of all Dead Cycles for both NMOS and CMOS microcode
• Implemented the RWW sequence for NMOS RMW instructions
• Fixed the sampling of NMI to more closely reflect the NMOS 6502 behaviour.

And somehow I have a feeling this might not be the last of it. More testing ahead!

A great day at the World Of Commodore conference in Toronto!

Dr Jefyll and I had an opportunity to show the TTL CPU and Jeff’s TTL-enhanced CPU (a.k.a KimKlone). Both were very well received, with a steady stream of folks coming over to see the CPU guys in the corner of the room. Here are some pics from the day: Also in our plans for the day was to carry-out our very own Connect-A-thon! — a.k.a testing the TTL CPU with other machines. Forum and TPUG member Steve Gray generously volunteered his Commodore PET 8032 for the first test (thank you Steve). Although we'd taken precautions, it was hard to feel absolutely certain the CPU's fast AC logic wouldn't generate overshoots that could damage the PET’s circuitry. After some debate, we decided to go ahead with the test despite the risk that we might have overlooked something. Thankfully, all was well and the PET booted with its familiar jingle-beep and no magic smoke. Steve’s PET had suffered a failure in the video hardware earlier in the day, so unfortunately the display remained blank. Despite this shortcoming, everyone agreed it was a successful boot up, and we moved on to test with Jeff’s KimKlone, which, until today, featured a Rockwell 65C02: KimKlone booted on reset, but crashed a few milliseconds thereafter. Steve and Jeff suspected the power supply, and decided to “borrow” a hefty capacitor from the PET. Scope in hand, Jeff tried to enhance KK’s power supply with some "on the show floor" patching:Unfortunately, KK refused to run even with the new CAP installed. We tried various captures with the logic analyzer, but soon realized we had been at it for hours and the room was empty ... the serious debugging would have to wait.

As part of the day, I also had the opportunity to present the C74-6502 in a talk to the group. Here is a YouTube link to the talk: https://youtu.be/dB3P5tt4gnE All in all it was great fun and a wonderful day. To mark the TTL CPU's debut in public, I posted up a website and a Draft Datasheet:

https://c74project.wordpress.com
https://c74project.wordpress.com/datasheet/

The only regret was wishing that ttlworks could have been there to complete the Team C74 commemorative photo . Here’s to you Dieter! Cheers for now,
Drass

EDIT: Added YouTube link to the C74-6502 talk.

Very cool indeed. Glad you guys had fun.

Excellent! Thanks for writing up your show experience and sharing!

Very impressive! Great work!

Steve

Dang: somehow I had missed that WOC already was _this_ weekend. As time flies.

Drass and Jeff: thanks for sharing the cool pictures, looks like both of you had a lot of fun at WOC...
...after more than 3 years of working on this project.

I'm still sorry that I wasn't there, and that I'm not in the group photo of "Team C74",
but unfortunately I'm located at a different continent than the rest of the team.


Sorry to hear, that the KimKlone had refused to work with the TTL CPU.
Could be either a timing problem... or some of the "illegal" 65C02 opcodes are not cycle exact.

Go, Team C74, go.

Awesome !
I miss Toronto, as well...

After viewing the pics of you two at WoC, I feel better knowing I'm not the only one around here with white hair.

I salut C74 team from Finland!

A