There's a lot to be said for 24hr clocks!

Neil

Dani, congratulations, nice work.

Yes, AM/PM flag in the 6526 is tricky indeed.

Looking forward to watching your adventure.

;---
Edit:

Just in case it might be helpful:

8521 was the HMOS-II implementation of the 6526.
A dissection of the 8521 TOD is here.

You can't even imagine!

So far, (And it is quite far) I have been only testing with a couple of OLD Cias I bought for cheap on ebay (Authentic, but they're the old model). I have only analyze a NEW Cia for ICR comparison and that has been productive, for sure.

But, and there's always a but.

Something is wrong with NEW Tod, specifically, interrupt firing. Right now, I have the feeling it is firing an interrupt when hours, minutes, and seconds match, and ignoring tenths. Maybe it is by design, maybe it was a quick way to fix the TOD bug in old CIAs. (Which I haven't been able to reproduce by the way). It doesn-t change too much, and I could probably replicate this easily. It is just another rabbit hole opening in front of me!

It never ends!

Hi everyone!

With the new year almost here, it's time for my End-of-Year update.

Not much has changed since my last post. As usual, I've gotten lost in a few other completely unrelated projects. Now, with the holidays here and an awful flu season, no more work will be done here until next year.

So... where are we?



Both units are now completed. Unit 1 is passing all my tests except for the SDR send, which is driving me crazy. After tinning and retinning the stack connectors, it now feels solid with no connectivity issues. Unit 2 has some issues with its TOD, most likely caused by bad soldering. It will need some work, heat, and love, but it will work, same as TOD1. Interestingly, SDR also fails. I have proof it did work at some point; otherwise, I would doubt it myself! Again, nothing unsolvable, I hope. Getting all of this working is my next step.

Meanwhile... I've been preparing my C64 to receive the two 74HCT6526s:




As pretty much everything works, except for TOD2, I gave it a try and powered up the computer with both 74HCT6526s connected. I was hoping for it to work OK, but... nope. It fails to boot. I get the familiar light blue border + dark blue background screen, but that's it. This means the C64 partially works. The CPU is able to run code, initialize video, but then it seems to crash. Again, I didn't spend any time at all looking into the problem, as it was just a quick try.

The second step then, after getting both 74HCT6526s to work OK, is to get them working with the C64.

And then... testing, testing, and more testing.

Will 2024 be the year I end this? I hope so!

But until I get there, I hope everybody has a great end and start of the year.

Merry Christmas, everybody!

Wow what a demonstration of how highly integrated some of these “everyday” chips are, or were, even in those days. Congrats and greetings!

Hello everyone!

After the Christmas break, I have a few updates!

I will start with the very last fix I've implemented. Let's see what past-me said :



Well. No. All past-me's were wrong. I now have two full units, which go by the names of U1 and U2. U1 indeed works as expected, but U2 didn't. No matter what I tried, TOD was counting after reset. I was starting to think that asserting both /SET and /RESET was not a very good idea, as any slight delay in the signals could mess with the outcome. I tried replacing the 74HC74 and, not so surpringly, I got different behaviours with different brands. Bad design!

I inserted a new DFF (I had a spare on board) to delay the /LOADH signal to the flip flop by 1 cycle so, in the event of both /LOADT and /LOADH being active at the same time (Which, btw, only happens during reset) /LOADH would be one cycle late, keeping TOD stopped, as expected.

And yes, now, the design is correct, and works as expected. Always. Yay!

In the meantime, I had to resolder a handful of ICs on U2/B4. I might have been a bit over-excited as this was the last board, and I make a lot of mistakes there. But... in the end... brace yourselves for a nice photoshoot!



This is a real OLD 6526 passing all tests on my SBC.



Same for a NEW 6526. Of course, nothing can be seen here. If you want to revisit the differences between OLD and NEW CIAs, here are my findings.

Now, for the real fun.


U1 in OLD MODE


U1 in NEW MODE


U2 in OLD MODE


U2 in NEW MODE

The failed test on both U1 and U2 in NEW MODE, is the TOD interrupt test. There's a few cycles difference I can't yet explain. However, this is only evident when I am ticking TOD programmatically, so, instead of 60 times per second (or 50) I can do it at will. When I am counting real time, 4 cycles is not going to matter.

This does not prove my design to be cycle exact. I am only testing for regular situations, and I am not aiming at edge cases. The VICE Test suite will take care of that.

One of the things I fixed on U2, was a dead short to VCC on a few ICR signals. I am hoping this is what was preventing my C64 from booting up!

Today, February 9th, 2024, I do have two full 74HCT6526 working. And it only took me five and a half years!

What's next then? Of course, time to torture my C64 again. If it boots with both 74HCT6526s installed, it has plenty of testing to do.

Also, as my SBC6526 takes two 6526s, I will plug both there, and crank up the speed. Can't wait to see how high they can go!



And now, I'm already there

But the best is yet to come!

Oh, and by the way, a new release to github with this last few fixed will be uploaded shortly.

Cheers!

Well, although this is an interesting thing to see, for sure, testing didn't go exactly as planned.

1.5 Mhz.

That's it. At least, for the timers. They are for sure the most timing sensitive component here, so I was expecting them to give the first signs of problems, but... not that early!

Some tests start to fail around 1.6 mhz. Up until 1.5 everything still works. I can still read, and write to the timers, but I feel like they're failing to properly reset on underflow.

Everything else remains stable up until 7 MHz. At 8 Mhz around half of the tests fail and at 9Mhz, absolutely nothing.

I am not disappointed. What has really change my mood today is how close I am to problems already at 1Mhz. Both units show similar behaviour so... it's probably a design thing, more than a build quality issue.

Now, I'm going for the C64 testing!

Ain't that beautiful?

I found out why the C64 didn't boot properly the first time I tried with both 74HCT6526s. The socket for one of them was backwards. Backwards! Luckily, nothing was damaged.

I've been running tests for 3 days already. TOD and SDR are not cycle exact, but I already knew that.

Valid TOD counts work correctly. Invalid TOD counts don't. The comparator section needs to be redesigned to fix this. I have a rough idea for it, but it will need a new board.

SDR is pretty close, with interrupts firing about 5 cycles too early. So far, I haven't looked into this and I am totally clueless.

Everything else, is extremely accurate. So far I have only detected one issue to fix. Let me explain it.

We load the timer latch (A or B, both work the same) with 0x0000 and with the timer stopped.
We issue a force load (Write 0x10 into Control register). So timer now reads 0000
Write another value in the timer latch. The test uses 0x0004, but any value will do.
Write 0x19 into control register. This is, Force Load, set One-Shot mode, and start timer.

On real hardware, timer starts before the Force load takes place. As timer reads 0x0000 and it is now running, an underflow happens. Timer is stopped (because of one-shot) and the latched value is loaded (0x0004 in this example). An interrupt is also triggered.

On my design, Load happens first. 0x0004 is loaded into the timer, so when start is finally enabled, it starts counting until it reaches 0x0000. Now the underflow happens, resetting, stopping the timer, and firing the interrupt.

When testing different counts, issuing a Force Load when the timer is running, or not. Trying one-shot counts, everything... my timers are cycle exact. So this ForceLoad before/after start, is just an idea. I think I get them at the same exact time in my design, while on real hardware, start is half a cycle earlier, enough to trigger the underflow. I'm digging into my schematics, trying to figure it out if there's a way to squeeze this behaviour.

I don't like messing with the timer pipeline... I've said it before, and I will say it again. It is a miracle that it works the way it does!

Congratulations! Great work!

_________________
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/