Wire Wrapping, or buffering PHI2 for the FFs?

Nah, I don't doubt the benefits of WW, and I can only say I'm amazed at some of the builds I've seen, but don't feel like mastering (well, at least trying) another technique right now. Besides, I've managed to get my hands on a nice stash of SMD parts, and the PCBs are dirt cheap.

And there it was... staring at me... all this time.... Dang!

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

Take a look at gate U14C, in the upper left corner... The timer should tick on the rising edge of PHI2 only if DECREMENT is high.

DECREMENT comes from the clock pipeline and is always 1 when counting PHI2 pulses, and it will be a single clock wide positive pulse when counting CNT, or TA underflows.

And sure, if DECREMENT is high, a rising edge on PHI2 makes the timers tick once... but it will do the same whenever DECREMENT goes high during high phase of PHI2.

So there it is, my extra count on CNT pulses, my extra count on one-shot mode, My (unnoticed) counting one cycle earler when setting START to 1. There is it probably the cause for 80% of the issues in the timers!

I'm going to try to generate a single pulse, on PHI2 rising edge, with 3 inverters+ an and gate, pretty standard stuff. PHI2 will be delayed by an aditional inverter that will clock the FFs in the clock pipeline, adding further delay to the DECREMENT signal. At least in theory, and using the Typical propagation delays in the datasheets, everything adds up. I get a ~18 ns pulse on PHI2 rising edge, that ends before DECREMENT goes high. Everything is pretty tight though... will need to run some tests before doing anything else.

Edit: A quick breadboard test I just did is extremely promising. Passing PHI2 through 3 inverters, and AND'ing it with itself gives me a ~20ns pulse (measured with a 20mhz not-very-precise oscilloscope). Pretty much in line with my estimation. That pulse is properly driving the '193 counters, and there seems to be a 40-50ns delay between PHI2 rising edge and the counter ticking. Half of this delay comes from the counter itself. I need to make sure DECREMENT won't rise within 30-35ns after PHI2 rising edge. For that, the DFF in the clock pipeline will be run with PHI2 delayed by 4 inverters. This, along the delay of the DFF itself feels like more than enough.

Also, with such a short pulse, I'm probably diving into some high-frequency zones. A clock with 40 ns cycle (20 high 20 low) is 25 MHz. The side effects I'm seeing because of this, is that the breadboard circuits works with decoupling caps only. Without them, I'm getting random unwanted ticks on the counter. Even with the caps, I'm getting quite a bit of ringing. I'm hoping for this to be exaggerated by the breadboard and for it to be less severe on a proper PCB.



As a personal note, this is probably the first time in this whole project I've had to look this deep into the propagation delay of a whole path... and I can feel something finally clicking into my brain about it! Still a long way to go of course, but it feels very good

Hi all.

I need to hijack my own thread and go a little bit offtopic...

The project is still going on but, as probably all of you are aware, the coronavirus crisis has put pretty much everything on hold...

For those of you who don't know, I live in Madrid which, right after Italy, is currently the worst spread focus in Europe. Af of today, it's my 7th day quarantined at home. Luckily for me, I can work from home pretty much without issue, and life, more or less, keeps going on.

As my wife and I are working from home now, I've had to dismantle my "lab". Also, I have no less than 4 parcels with PCBs, components, and other stuff wandering around the world and who knows when,or if, they will arrive.

For all of you in affected areas, take care, extreme any hygiene measures, wash your hands often. For all of you in unaffected areas... apply the same measures, please.

Spanish public health services, although not perfect, are said to be amongst the best of the world, and here in Madrid, they're close to collapsing.

Take care everybody.

Had some time at hands for drawing a "cheat sheet" for Dani's timer control logic.

Omitted the reset circuitry to make it more easy to read.
During reset, timer and timer latches are set to -1.



Sometimes it doesn't come out clear whether sontrol signals are HIGH or LOW active,
but considering it's a beginner project it doesn't look bad.

;---

A short overview about the clock dependencies.

Changed PHI2'''''' to PHI26 (PHI2 with six apostrophes).



Looking forward to see, how the adventure continues.

It's funny how I'm able to understand your schematics better than my own! That probably means I'm somehow putting together different pieces of a puzzle, while you're able to imprint some meaning in them. I like that.

Tomorrow will be my 60th day in quarantine. Oh my! And life still goes on. I now have a working SBC that can push the 74HCT6526 to, until now, unknown speeds.

So far I've only tested B0, and it is stable at 14Mhz. I can push the SBC a bit higher but the clock itself begins to fail just a bit after that, so that'll be my target for now.

I'm now building the second version of B1 (Timer B) that should fix all the issues detected on the first one. Next step after that, TOD, it's schematics are like 30% done so far. Only the actual clock is implemented, I'm still missing Alarm, and all the control logic. It feels nice to get back to "work"

Cheers!

Quick update today.

Over the weekend, I've built the second version of B2/TimerA. (In some previous posts I said it was B1/TimerB, the one I had, but no... it's actually B2/TimerA!) and, even though full testing needs to be done, first tests look extremely promising.

None of the issues found on the previous version seem to be present. I still need to get the scope and logic analyzer to check for the tiny details, such as underflows, timer output and so on, but I'm very confident.

If I don't managed to find anything wrong.... this would be another great milestone, after such a long time. Fingers crossed!

Hi all.

As I am expecting to complete timer tests within a couple of weeks, and, as I also have high hopes from what I am seeing this time, I decided to retrace my steps, back to the ports, before moving on with the next component, which would be ISR I think, as TOD and SDR are barely used on normal C64 operation.

As I have been pointed out several times, in several places, I have a big design flaw in my ports. They're not open collector, as I'm activelly pulling up the outputs. So far so good, this has worked for me (Being able to use a floppy drive with my ports whas a big milestone, quite a long time ago!) but, as I've been gaining more knowledge (ok, not a lot, but some ) I came to understand, this was a big flaw.

First alarms went of when I found some people talking about my work, in other forum, and mentioning "A killer poke" for my design. Pretty easy to see know... of course..

In a C64, ports are used to read the keyboard matrix, as you may know. Set both ports as outputs, pull one high, one low. Press a key, a Boom!. A short to ground. Yikes!

So yeah, I've been thinking of a couple of ways to amend this. @ttlworks suggested using some buffers ('125 or '126) with it's input tied to ground, that would be put in High-Z when the port had to output a 1, relying only on the external pullup to output a high value. So I went ahead, and layout a new board with this setup.

However, after further investigating... I made one (at least for me) big discovery. PortA and PortB are not the same. First clue was deeply hidden, in a readme.txt for a C64 emulator test suite. It's intented to be run on emulator to compare with the expected outputs and, when it comes to the ports. this is what I found:



Second clue was found on an old scanned MOS6522 datasheet.


On the 6522, PortB schematic suggests it has a transistor to pull up stronger, together with a "normal" transistor acting as a pullup. This have to be the "Active and passive pull-ups" that are mentioned on the 6526 datasheet.

Third and last clue. Back in september, 2019, user fhw72 posted a die shot of a 6526. Even though I'm not able to read silicon in any way, there was something there, completely obvious.


I've taken a section where we can see PA7 and PB0 together. I've colored in light red the VCC metal, light yellow GND. In the VCC metal, nexts to all PB pins, there're plenty of vias, forming what I can only guess is the active pullup. They're not there in any of the PA pins.

To have additional information, today I've put one of my original CIAs under some stress with some very simple test.



I've tried with different R5 values, from infinite (No resistor) to 0, (direct connection) and the results seem to prove all the above:



I need to dig up my most basic electronics knowledge(Shame on me, yesterday I had to google Ohm's Law ), but I should be able to find some accurate values for the pull'ups of a rial CIA, and how to best mimick them on my design.

'125 or '126 will work fine but they only offer 4 bits per package (14-pin). If you're interested in saving space (and if you're not already committed to your new layout) then you may wish to consider this bunch of options, which offer 6 bits in a 14-pin (Example: 74xx07), or even eight or nine bits in a 20-pin.

Nine wide Schmitt trigger buffer; open drain outputs

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The credit belongs to Digikey's product search function. THAT is what I suggest folks bookmark.

In this case I started with Product Index > Integrated Circuits (ICs).

From there I saw two possible paths for an open-drain device:

Product Index > Integrated Circuits (ICs) > Interface - Drivers, Receivers, Transceivers
and
Product Index > Integrated Circuits (ICs) > Logic - Buffers, Drivers, Receivers, Transceivers

It was in the latter category that I discovered the nine-wide Open-Drain Schmitt... which I had never heard of until today.

First I had to click a lot of filters to rule out unsuitable parts, such as those that won't run on 5 volts. I admit the process is a bit finicky, and I sometimes have to backtrack. But it's amazing the stuff you find sometimes.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes it requires patience. But it gets easier with practice.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Nice findings!

Board is not ordered yet, so it's open to changes. However, having 4 bits per IC, so 2 ICs per port, has the nice benefit of resulting in a very clear an nice layout. 6 gates per IC would mean sharing one of them amongst both ports. I'll save 1 IC, but the routing won't be so clean.

I may try with those 9 bits buffers. That could work. And yet, I have quite a stock of '126 laying around, so maybe it's not worth it in the end. I also have plenty of PCB real state available.

Last update on the timers, probably for quite a long time I'd say.

Another weekend spend on testing, and they now feel as good as I feel I can manage. All counting modes are OK (For TIMERA, reviewed version of TIMERB is not built yet). But it work.... except those moments when it doesn't.

I doesn't happen too often. Around once every 10.000 PHI2 cycles from what I can see. But sometime, the lower nibble of the timer goes haywire and does not count right. What I'm seeing are bits failing to flip. My best guess, the clock pulse to the counter is too short and it's messing with the internal flipflops.

I don't have equipment precise enough to look furter into this. I do have a 20Mhz oscilloscope that only registers the clock as a blip, and a 24mhz logic analizer that detects the pulse around 60% of the time. Until I can get hold of something more powerful... both timers will stay as they are right now.

So, after such a long time... work begins on the ISR. It will share board with the SDR too, (if they fit together, which I think they will). We'll see how this goes.

Cheers!

Hi everybody! It's been quite a long time... as I expected.

Pretty much nothing has changed since my last post.... I still haven't "recovered" my lab, so any work with real hardware is still on hold.

However, for the last couple of weeks I've been getting up to speed again. It's amazing how much stuff just slips out of your head when you don't use it for some time. I've been re-learning some stuff, making sense of my old schematics... and looking for a way to progress with this project.

So far, I've been using Intel Quartus for my logic simulations. This is, of course, not its original purpose, so... well... overcomplicated for my needs, and, as I stepped further into the 6526, it became difficult to implement good tests, and this reflected on my work.

But, again, inspired by @Drass excellent work with the 100MHz TTL 6502, I decided to give Logisim a try. If you can properly create the 6502 there... a 6526 must be easy right?



Absolutely right. It took me only a weekend to get a handle on the Software, getting Drass CPU working, and implementing a very crude 6526 (Just DDRA and DDRB). But, amazingly, it is able to run some code, write values into the 6526, and read them back!

So I'm going to redo a big chunk of my work. Get some proper test suite running in Logisim. The circuit above replicates the most basic components of my SBC6526, which can now run with an original MOS6526, so I should be able to run the same code, both in logisim, both in real hardware. That for sure feels like a good starting point for a decent test suite!