Guess what?

I do have a Timer B bug.

And a timer A bug.

And everything else

Everything else seems to be doing just fine, so I'm focusing on fixing this, before moving on to TOD.

I can now pretty much confirm that I've build a old version of the 6526. Also, my suspicions were right. Not only have I, unwillingly, reproduced the TIMERB bug, but I've managed to copy it to all other interrupt sources. So I'm sometimes skipping a TIMERA interrupt, and crashing whatever is running that relies on this.

I've been testing and testing today, both with a C64 and with the SBC6526, and I've narrowed down all issues to two.

The one we already knew about, TIMERB bug has spreaded to all other interrupt sources. Good this is, as I have to fix it for TIMERA, I will have the option to fix it for TIMERB if needed. I still need to figure out exactly how it is happening, but I'm planning anything to have a quick way of activating/deactivating it on the CB.

Second issue, has been a bit more elusive. One of the tests I am running is testing for TIMERB counting TIMERA and then measuring how and when reloads and interrupts happen.

The test starts CIA1 timer A at 0x00FF. CIA2 TIMERA at 0x0013 and CIA2 TIMERB at 0x0007.
When TIMERB underflows and triggers an interrupt, CIA1 TIMERA value is compared against known good values taken on a real CIA.
In between, and before the interrupt arrives, TIMERB is sampled too to verify reload. There are around 1200 values checked on this tests. The 74HCT6526 passes all of them, except one.

One!!

When TIMERA is set to 0x0010 and TIMERB is set to 0x0000, it fails.

With this setup, TIMERB underflow is triggered when TIMERA underflows (maybe next cycle, I need to check). The peculiarity of this test is that, the loading of TIMERB happens more or less at the same time has to fire. Right on the same cycle, maybe one cycle later or sooner.

The end result is, on a real CIA, the interrupt is missed. On the 74HCT6526, it fires, so it arrives 0x0010 cycles earlier. For a real CIA, we need to wait for another TIMERA underflow.

Test does not fail with TIMERA at 0x0011 or 0x000F, only at 0x0010.

Meanwhile, I've spent good part of my Saturday playing games on my C64, and I've found out that, the games that were crashing with the 74HCT6526, also crash with a real CIA... I need a better test suite!

(Edit: I got it the wrong way around. I thought I was missing the interrupt, but instead, I'm firing when the real CIA is not)

Wrong!

After a couple of days spent with the logic analyzer, I've positively identified the problem. When a ForceLoad is issued to a timer, when counting anything other than PHI2, if the ForceLoad is done one cycle before the timer underflow, the underflow is missed, and so is the interrupt.



On the left of the red bar, is a real 6526, on the right, the 74HCT6526. The cycle highlighted in red is the cycle next to the forceload command. You can see /CS going down the cycle before, with the register 15 selected (Control Register B). TimerB output is active on PB7, and even though a ForceLoad was done, the underflow takes precedence. A Timer pulse is sent, and this also triggers the interrupt.

However, on the 74HCT6526, no TimerB pulse is present on PB7, so no interrupt either. We need to wait to the next TIMERA underflow 0x10 cycles later to trigger a TimerB underflow, and then, the interrupt.



The issue comes from the "underflow&reload" segment of the timer pipeline.

Oddly enough, the underflow triggers on my Logisim model.



This test, morover, has undercover two more issues. Timer pulse is offseted by half a cycle. Also, not shown in the capture, when the ICR is read, /IRQ takes two additional cycles before clearing.

So close... yet... still so far!

Hi everyone. I'm back to "work" after a mandatory two months break, due to some family stuff going on (Nothing bad! Some good stuff actually, that needed my attention for some time).

And today, I bring a story of failure and success. I left here:



Right before this little break, I found a possible solution to this issue that worked, at least on logisim. In order to create the counting pattern found in the timers, (Remember, no 0 is ever read, but on reload, the starting value could be read twice : 4-3-2-1-4-4-3-2...) Whenever an underflow happens, a clock is removed from the pipeline the very moment the reload is triggered.

However, this same clock was being removed on any timer reload. If timer is stopped, a write to THI triggers a reload. This is not a problem as the timer is not running here.

Also, when a ForceLoad is issued, the pipeline was also cleared, and this, is what's preventing the interrupt to fire. So by not resetting the pipeline on a ForceLoad, the issue should be fixed.

The only downside is that this requires ForceLoad to be delayed one cycle, requiring a new FF.

Back from the break, I devised a way to upgrade my current B1 Board from its current form (v0.1.1) to the version with this fix included, (v0.2.1).


This is how the board looked before starting the conversion. There's already an extra FF hanging from the board, with the second FF on the IC used by another fix in the ICR... So ugly!


Much better now. This is in fact the same version as before, but with a dedicated 74HCT74 for B1. I also tidied up the wires on the board.


And the, the final version, with the second FF added to delay ForceLoad, and with a few cut traces and bodge wires to amend my problems.

Now, time to test comes.... and with it, a sounding failure.

I first tested the full stack on my SBC6526. All good, hopes are high. Time to test on a C64... and boom. Nothing works. The whole stack misbehaves. Failures are intermittent. It kinda works... for a few tests then everything falls apart.

All the work has been done on B1, so I removed all the bodges, reflow all the ICs, added and rechecked all connections... and I was getting the same misbehaviour!

After two days of headbanging against the walls and no progress... I decided to give the board a deep and nice cleanup. All the works I've been doing, there was flux all over the places.

Unexpectedly, everything worked. It seems all the flux on the board was adding enough resistance that the LS logic in the C64 was not able to handle it, but all the CMOS parts in my SBC could.

So... clean your flux! That was two days lost! Shame on me!

But after the clean up... the success. With all the changes to B1, everything still is as cycle accurate as it was before, which is amazing. I still have the issue with the missed interrupt, just because it's TIMERB the one skipping it. I chose to make the changes to TIMERA first, as the board was already heavily modified.

Now it's time to introduce the changes into TIMERB. Hopefully, it will allow me to pass this first test.

All this fixes are introduces in v0.2.1, which is not published yet. Once I test it on TIMERB, if it works, it will be commited to github.

Now... more bodging!

Cheers!

Congratulations on the success - I'll need to remember that possibility for possible future adventures.

Well... Don't light up the fireworks yet... After implementing the fix in TimerB, I'm actually getting the correct value on the test where it was failing before... but... I've caused around 20 failures in other places.

It feels I'm reloading too early from what I'm seeing... but this thing it's becoming selfconscious. I'm actually amazed I've managed to get this close!

Edit: After some deeper testing, it seems all the failures I'm getting correspond to a same case. When TA=0x0A and both TA and TB are ForceLoaded, TB seems to underflow one cycle earlier. If this is the case, delaying the TA underflow signal should be enough to get everything working.

Sometimes I just love to be wrong.



This, even though it may not look like much, is the first test of the CIA test suite succeding. Yesterday, with all the test I did, there was something that was bothering me, a lot.

One of my unit test for the timers involves ForceLoad. I start the timers, issue a forceload, and stop the timers. Then I read the value in each of the timers. This way, I measure if the ForceLoad happens right when it should (previous tests have already proven that start and stop are accurate).

Even though both timers are the same (At least, regarding this test) TB was stopping one cycle late.

Why? Well, during my board surgery this weekend, at some point I cut the wrong trace! Duh! After repairing this trace, and cutting the proper one... the test succeded. Remember, this is running both timers cascaded on very tight loops (TA = 0x13, TB=0x07) and after each test, values are decreased until TB=0x00. Tests checks for read values on small loops, and also the cycle when the IRQ fires for TB. I still have plenty of tests to run but, this means, that I'm probably cycle exact. With no "but"s or "if"s this time.

I will now consolidate this fix on my schematic, and v0.2.1 will be released with it.

So, what's next?

First, it's time to start building a second unit. I have the PCBs. I have lots of ICs left, I have pretty much everything. Sure, the may be some additional fixes needed... but I'm feeling optimistic.
Also, there's a lot of testing ahead. I do have a total of 142 tests compiled mainly from the VICE emulator test suite. Also, games!
Then... There is a handful of identified issues that still needs attention. Mostly related to SDR/ICR
And of course, we're still missing TOD. Work on the schematic is already ongoing, but still on its early stages.

The future is looking bright!

v0.2.1 has been released and published in my github.

It includes the fixes for the very first test of my test suite, which I have now made public here. The test suite comes from WinVice emulator testbench. I have only adapted it so I can fit all tests within a single floppy, and I'm adding comments and some minor changes to the code, in order to better understand it.

Right now, v0.2.1 passes tests 01. A small addition now allows me to switch between OLD and NEW Cia mode. I can pass the test in both modes

I'm still getting some errors on edge cases on several other tests, so I'm not 100% cycle accurate, but I am close, very close.

I am now dissecting tests 02, which fails for both NEW and OLD modes.

Cheers!

After some investigation into the latest test, I feel that it's the end of the road for my current design, at least if I want to achieve cycle-exactness.

My tests suggest that the timers are cycle-accurate, which is a great achievement. However, (and until I grab the logic analyzer, this is a conjecture) I am half a cycle late at the ICR. I miraculously fire the interrupt at the correct cycle, but I am setting the ICR bit one cycle late (or at least half a cycle late).

The bad news is that I am setting the ICR bit immediately when the Timer Underflow happens. There's no way for me to fire it earlier, unless the FlipFlopFromtheFuture is now available, but I'm afraid that's not the case.

Now, I am counting on PHI2. To move everything one cycle earlier, I need to count on /PHI2, but then I would be counting while a read is happening, so I need to add latches to the timer (which was probably a good idea from the very beginning anyway).

Also, as pointed out before, any small change to the timer pipeline has the potential to break everything around it.

Still, I am moving forward and have no plans to abandon my project now!

It has happened twice now. Every time I come to the conclusion that the FFFF is the only solution to my problem, it means I haven't understood the problem.

The latest failure I'm having on the ICR tests is not caused by the ICR being set too late. It's caused by it being cleared too late; two cycles late, to be precise. However, I can fix this issue very easily since I am feeding the ICRCLR signal through two regular DFFs before clearing the ICR. I read somewhere that the ICR is cleared two cycles after reading the register, but this information seems to be inaccurate.

I still need to run more tests to find out exactly how many cycles I'm off, but so far, no FFFF is needed.

Also, as the Starship launch didn't go entirely as planned, I wanted to have something to celebrate today. I've committed the full Board 4 schematic into my GitHub repository. This is the full TOD, so pending validation, this means I now have the full schematic for the 74HCT6526. Logisim tests are quite promising, and since there's no weird stuff here, and I have not chased full accuracy, I'm quite optimistic about the result.

Everything, as mentioned before, is published on my repo:
REPO: https://github.com/dmolinagarcia/74HCT6526
TOD schematic: https://github.com/dmolinagarcia/74HCT6 ... vx.x.x.pdf

Now, onto routing!

PD. So close... I am so close!

I had another productive weekend.

After getting close and personal with CIATEST 02, I've managed to get one step closer to full cycle-exactness.

The test starts Timer (both a and b, it test both) in a sort and tight loop 0x101 cycles. The test loop seems to be 0x102 cycles long, so each cycle, the timer underflows one cycle earlier.

The test is run twice per timer, with IRQ enabled, or with IRQ disabled. With IRQ DISABLED, ICR is read twice in rapid succesion, and the results print to screen. (@ for 00, A for 01, B for 02). Test on the right is TA, on the left, TB.





So it seems, my ICR0 and ICR1 bits are now cycle exact! This is OLD cia behaviour. For NEW Cias, TIMERB has same behaviour as TIMERA. The difference comes not for the bit set, but from the bit reset. In OLD CIA, TIMER A is resetted one cycle before TIMERB is after reading the register.

In my original design, both ICR0 and ICR1 resetted at the same time. So ICR1 was correct, but ICR0 was late. It was an easy fix, by bypassing one of the DFF in the ICRCLR chain.

These are the good news. The bad news, although not too bad, come from IRQ and ICR7. Right now, I'm tying both of them. Whenever ICR7 is set, IRQ is asserted, however, there may be one cycle difference. I'm still crawling through a full capture of the test with a logic analyzer. Hopefully, I have the feeling a DFF here and there will be enough to fix everything.

Oh, and by the way, TOD is complete Both PCB and SCH are commited to my repo, although so far, it's untested.

Excellent work here! I really enjoy reading about your progress.
(And I have wrangled with the CIA timers in the VICE emulator a looong time ago! )

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Excellent work here! I really enjoy reading about your progress.
(And I have wrangled with the CIA timers in the VICE emulator a looong time ago! )

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Well well well...







That, myfriends, is what a cycle exact MOS 6526 replica looks like.

B3 (ICR and SDR) has gone through a well deserved spa session this weekend. Gone is the dangling DFF to fix my original version of the SDR. Gone are the long and awfully soldered bodge wires. Now everything is better (Not perfect, but much better I should say)

Moreover, I've been fixing the small issues I still had. I can now replicate a NEW6526, but I still have some minor differences if I go to OLD6526 Mode.

And yes, that means I can switch between them. So far, I have 3 diferences between them

In NEW 6526, both ICR0 and ICR1 are cleared one cycle after reading the register. in OLD6526, ICR1 clear signal is delayed one more cycle.
In NEW 6526, ICR7 is set the very same cycle the interrupt source is set. In OLD6526 it takes an additional cycle.
IRQ signal follows ICR7, so NEW6526 fires the interrupt one cycle earlier. (It's actually half a cycle earlier, but for all purposes, it's one cycle earlier for the CPU)

So I have 3 switches on board to flip this 3 bits one cycle ahead or behind. In the final release, I will probabley have a quad 2-input mux (74HC157), so I can select all of them with a single switch.

Now, let's go back to earth.

Not everything is cycle exact. SDR fires a bit earlier on my design. And TOD, (Still not ordered) will definitely be different. But with the Timers, and the interrupt register being 99% exact, I think some little celebration is in order

This last changes are not committed to the repo, they will be shortly. The plan has not changed though. There are still quite a few tests to run, before I can confirm I'm done with this.

But I'm so close.... almost there...

Cheers!