74HCT6526 - A MOS6526 implementation with 74xx ICs

[barnacle]

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

Neil

[ttlworks]

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.

[daniMolina]

barnacle wrote:

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

Neil

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!

[daniMolina]

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!

[BigEd]

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

[daniMolina]

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 :

past-daniMolina wrote:

past-past-daniMolina wrote:

- On powerup (or reset) TOD should not be counting, but it is. A write to the tenths register starts the count, a write to the hours register stops the count. On my design, TOD is and-gated with a signal I've called COUNT.

The idea was... when /RES goes high, that became a clock pulse for the flipflop that generates COUNT. With its Data pin tied to GND... on reset, COUNT should be 0. Right? Nope. Wrong. As I'm forcing a write to all registers on reset, /LOADT and /LOADH are active, so both /SET and /RESET inputs to the DFF are asserted simultaneously. When the /RES, /LOADT and /LOADH finally goes high, COUNT is always 1.
This will be fixed by taking /Q as COUNT, and swaping /LOADT and /LOADH on the flipflop.

The design was, after all, correct. The data input to the FF was floating so... Fix this, and COUNT is working now as expected.

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!

oneyearago-daniMolina wrote:

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

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!

[daniMolina]

daniMolina wrote:

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!

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!

[daniMolina]

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!

[fachat]

Congratulations! Great work!

[daniMolina]

daniMolina wrote:

c64.jpeg

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!

Hi everyone!

It's been three months since my last post, and pretty much the same time since I've last worked on the project. This last issue I found, it's more stubborn than others. I tried, back in February, a couple of ideas, but they ended in an even worse result. Moreover, after a year or so of hacks, I lost control of all the changes I have done so... I decided to take a break to try to get some fresh air.

In the mean time, thinks have changed a bit in my personal life. For the best, but one of the side effects is that I won't be able to have a "lab", probably until 2025. The good news is, by then, I will have a proper lab. No more hijacking the kitchen! The bad news is, the break will be much longer than expected.

As I know there are some people around following the project, I just wanted to let you know that it is not abandoned. I'll be back on it, eventually

Cheers!

[WCMiller]

Eh, life happens. I'll be interested in seeing things when this project wakes up!

[ttlworks]

Dani, I'm looking forward to see how your project continues.

Best wishes, and good luck!

[copperjump]

Hi Dani. This is a really cool project and I wish you luck in its further development.

[daniMolina]

Hello everybody!

There are no new updates for the project. My new home is almost completely built, and I still expect to have by lab up and running at somepoint during 2025.

After a one year-long break, it will take some effort to go back into the project, but I am really looking into it. Will keep you posted!

Meanwhile, I wish you all a very happy holydays, Christmas, New Years, and everyother thing to celebrate.

See you soon!

[BigEd]

Congratulations on the domestic progress - and a happy festive season to you too.