6502.org

Great use of Logisim to validate behaviour! Fantastic.

Hello! I am making a board where I want to use the /PC pin to notify another device when a read or write of PORT B occurs. The 6526 datasheets says, "PC will go low for one cycle following a read or write of PORT B." So, the question is - does /PC go low for one cycle, or two as you have done it?

Shame on me! Almost a year since my last post.... Yikes!

Long story short, I had to quit my job, as it was stealing all available time from me, since January probably... not even my "6502 time", but even family was getting impacted... not a good thing for sure. I begun at a new place a month ago, and it feels I back on track now!

I've used this month to get everything running again. My old workstation had a bad day and it had to be rebuilt. It took around 3 weeks to get everything back up and running again. Since then, I've begun working on a reboot of the whole project. I took down the old github repositories, for both the 74hct6526 and the sbc6526. Redone most of the work on KiCad (bye bye Eagle), and I'm about to repost the new versions for both. Once done, I'll place an order for the new PCBs: B0 (Ports, with proper open collector outputs, and DDR) and begin construction again. I've also managed to find a perfect spot to set up a new workshop!

Oh, and BTW... I'm like 95% decided to use a couple of GALs for TOD and SDR... i hope is not considered cheating

I've been keeping an eye on the forum all this time though... I hope everybody is ok around here!

@JimDrew. I'm incredibly sorry for the (extremely) late answer... /PC goes low for 1 full cycle whenever there's a read or write to the port. One thing I noticed back then, was that, when you do a write, there's a read to the same addres followed by the actual write on the next cycle, so the port is actually accesed in two consecutive clock cycles. In this case, /PC will be low for those two cycles. When doing a read, as expected, /PC is low for a single cycle.

All my repositories are now public.

GitHub repos:
SBC6526 https://github.com/dmolinagarcia/SBC6526
LOGISIM6526 https://github.com/dmolinagarcia/LOGISIM6526
74HCT6526 https://github.com/dmolinagarcia/74HCT6526

Of course... everything is untested, experimental, and may catch fire if anyone tries to build their own.

And finally, B0, which includes DDRs and PORTs is ready (again ) for production.

The full project is shared here:
https://github.com/dmolinagarcia/74HCT6526

Cheers!

Sometimes, a success, even if it's a little one, is very much needed.

After a very long time, most of it spent redesigning and rebuilding both my SBC6526 and the 74HCT6526 (moved to a 4 layer pcb, in Kicad), and implementing all little fixes I've found overtime... today, I've completed the build of the new B0 (DDR+PORTs).
The new design allows it to stack nicely with the SBC6526, with a much more compact design, free of messy ribbon cables and adapters. SBC now supports dual 6526s (Original, or replicas) so tests and comparisons are incredible easy now. Moreover, I've switched to solder paste + hot air soldering, and the results have been wonderful. The whole B0 was completed within 2-3 hours, with no rework needed at all.
And, more importantly, it works as intended. No bugs, no floating pins, no need to debug or diagnose anything. It just works. Ahhh... victory...

I know, this is more or less the same point I was like.... 3 years ago maybe? The difference, for me at least, is that now I stand on solid ground. Before, it was like quicksands everywhere!

All work is now focused on the TIMERs, which are, again, my biggest hurdle. LOGISIM testing is very promising. PCBs and components are here, and I have plenty of spare time this next weekend to build it.

My github repositories are up to date:

74HCT6526 : https://github.com/dmolinagarcia/74HCT6526
LOGISIM6526: https://github.com/dmolinagarcia/LOGISIM6526

Hi Dani,
nice to see that you are working on the TTL 6526 again.

From the looks of the pictures, you seem to be making nice progress.
Quality of your hardware has increased, what sure increases the chances for having success.
Keep up the good work.

Our 6526 dissection still has not started yet, and maybe we wil do a 8520 dissection first.
//8520 is similar to 6526, but has a 24 Bit binary timer instead of the 6526 BCD TOD.

To be honest, I've never fully stopped working on it, but for sure, the effort has been minimal. I've been wandering through some other projects, ranging from some ML stuff to learning FPGA programming. I guess I can't keep my mind idling for too long

The hardware quality has for sure take a huge leap. From the manufacturing standpoint, 4 layer with proper ground and power planes has to help somehow. Routing is much much more efficient now.

Soldering with solder paste and hot air is, once you get the grip of the temperatures, easy, fast, a very reliable. Actually...
After a couple hours, B1 (TIMERA + CREGA) is done. I just couldn't wait for the weekend.
And, oh my, ain't it beautiful?. Also, it works. I still need to put it through some heavy testing, but the most delicate part of this (Counting, properly detecting underflow, and reloading) works, it just does work!. It's been running for no less than 2 hours now, and it hasn't skipped a single beat.

I've run some limit testing with very low presets, stopping right at underflow, and that kind of stuff... and so far, it doesn't only work, it is cycle exact to the original!

So far, it starts to fail at around 9Mhz. Still plenty of work ahead, but it's looking very promising now.

Next stops, complete a full test suite for this board, and begin the design of B2. I do have a working logisim model, and as it is pretty much the same as B1, this should be fast!

Cheers!

Testing of B1 (TIMERA and CREGA) continues. So far so good, all test are OK and it seems to be cycle exact compared to original MOS6526.

Reliability is rock solid, all the issues I had with the timer skipping pulses are gone. After a couple of days running tests, nothing indicates a single clock cycle has been lost. Same applies to underflows. They fire everytime.

Only timer outputs (Toggle and Pulse), a few reload cases, and confirming the reload cycles are ok (4-3-2-1-4-4-3-2-1 when counting PHI2, 4-3-2-1-0-4-3-2-1-0 when counting CNT) remaing to be tested.

Until now, I've found only one difference with a MOS6526. When issuing a FORCELOAD, this arrives one cycle earlier. I do have an unused FlipFlop on board, that could be used to delay this signal.

Hoping to end all tests before next week!

Ah, yes... always a joy when one has both of those boxes checked off. Looks good? Yup. Works? Even better!!

Nice to hear that your perseverance on this project is paying off!

-- Jeff

Done for today... will push a bit more during the weekend, but most of the work is completed.

Just two issues, easily solvable, and probably not critical for the timers to work properly anyway.

As stated before, FORCELOAD is a cycle earlier than it should be.
Also, whenever timer starts, is starts counting one cycle before the original 6526.

Both signals can be easily delayed to match the original, with (I think) no other sideeffects.

Only counting CNT pulses remains to be tested. I'm having some trouble generating the pulses in the first place to be able to count them. The CIA1 in the SBC should provide them via its serial data register in output mode, but it's refusing to do so. (Maybe I'm not asking properly!)

When this is done, I'll replicate this tests on the logisim model. Hopefully I get the same behaviour, and I should be able to test the needed fixes for my two issues. They will be then implemented in B2 (TIMERB/CREGB).

Oh, regarding the interrupts from the Timers, just in case someone misses them. As they can't be tested until ICR is implemented, they will be tested as soon as ICR is done.

Cheers!

My guess is that the bug happens at the ICR itself, and not in the TIMER. So far, my ICR only exists as a logisim model, and it doesn't suffer from the bug. However, as the reset of each individual interrupt bit is asynchronous whenever the ICR is read, it may happen in the actual build, depending on the timing. Unfortunately, as all interrupt bits are the same, if it happens, it could happen to any interrupt source.

It's in my TO-DO list to further investigate this bug. I know it exists, I have a brief understanding of what and when it happens, but information seems scarce and incosistent.

We probably need to wait for @ttlworks and @fhw72 dissection of the 6526 to fully understand it.

Cheers!

In the real 6526, the problem occurs when the interrupt status is read one or two Ø2 cycles before a timer-B interrupt is scheduled to hit. I believe it was Elizabeth Deal who first described it when she was trying to use the timers to feed data to the SID at a controlled rate (Transactor volume 5, issue 2). George Hug further described the problem in his Transactor article “Towards 2400” (volume 9, issue 3), in which he detailed what he did to get the C-64 to do RS-232 processing at 2400. I became aware of it in trying to use the timer to interrupt a user input routine after so many seconds of no typing.

What was particularly aggravating about it was it didn't occur in all 6526s. One of the C-128Ds I had had the timer bug in one CIA, but not the other.


The 6526 also had a bug involving the TOD alarm function. In this case, the alarm wouldn't “go off” (cause an interrupt) if the tenths register was set to zero. The workaround was to not set the tenths to zero.

That's some very valuable information. Thanks! Believe it or not, I've been searching for info for some time now, but it is hard to find this among the army of "TIMER BUGs" occurrences in forums about emulation, FPGA, and this kind of stuff.

With MOS chips, if all the chips have the same bug, for me, it's not a bug but a feature, however inconvenient it may be. As the TimerB bug is not in all chips.. I won't try to hard to replicate it. However, after a quick lock at mi Logisim model..

download/file.php?id=11061&mode=view

I may have replicated, unintentionally, it for all interrupt sources, which is far far far from ideal. A read to the ICR triggers (With a 2 cycle delay) the clear input in all ICR Flipflops, crearing them. Any interrupt source triggers the set input of the FF so... I have a completely unexpected behaviour right now. Yup, definitely, I have to give this a proper review.

Regarding the ALARM bug, I have around 8 CIAs, ranging in date from 1986 to 1992, and I haven't been able to reproduce it. Of course, I don't mean it doesn't exists, but again... I see no need to replicate this