Glue questions

[plasmo]

While the topic is about glue logic, there are sufficient “glue logic” built into RAM, ROM, and peripherals that it is possible to build a 6502 computer without any extra glue logic. See this topic, viewtopic.php?f=4&t=6455

If you do use 22V10 for glue logic, there are sufficient sum-of-product terms in a 22V10 to build a small ROM and enough glue logic remain to build a 6502 SBC with just 22V10, RAM, and 6502. viewtopic.php?f=6&t=7868
Bill

[enso1]

Thanks, guys, what a timely (for me) refresher on interfacing the 6502!

Although the conversation reminds me of the days of butting heads with a teenage son... When I asked him to do simple things in a straightforward, experience-proven way -- be it wash dishes or vacuum the rug, I was not really interested in listening about how he thinks it should be done (resulting in dirty dishes or rugs, and pointless discussions).

Experience resulting in failure is a great teacher, but when asking those who've made mistakes before for advice, it's better to listen to what they say and not extol the virtues of trying random suboptimal crap because that is your 'process'.

[GARTHWILSON]

Someone once said, "The best kind of experience is someone else's."  (That assumes you'll learn from it without paying the price yourself.)

[fachat]

Just one additional notice.

It's valid to look at the total delay time of the chain of logic from address to select line.

But it helps qualifying the RAM select or WE line in the last gate of that logic just before the RAM. That reduces the critical time delay between Phi2 and select / WE, and gives you more slack for potentially more complex select logic.

André

[BigDumbDinosaur]

GARTHWILSON wrote:

Someone once said, "The best kind of experience is someone else's."  (That assumes you'll learn from it without paying the price yourself.)

That reminds me of something a friend of mine who is a retired airline captain once said: every design feature of a modern airliner was paid for with someone’s life.  Fortunately, the “cost” incurred in electronic design isn’t quite as severe.

[BigDumbDinosaur]

fachat wrote:

It's valid to look at the total delay time of the chain of logic from address to select line.

But it helps qualifying the RAM select or WE line in the last gate of that logic just before the RAM. That reduces the critical time delay between Phi2 and select / WE, and gives you more slack for potentially more complex select logic.

Yep!  That is something I have periodically mentioned when the subject of decoding best-practices comes up.  The below read/write logic adheres to what you recommend.

With the above circuit, if RAM is selected during Ø2 low, there will be only one gate delay after Ø2 goes high before /RD or /WD is asserted.  Using 74AC or 74AHC logic, that delay will be in the single-digit nanosecond range.

[L0uis.m]

Hello 0010 all,

BigDumbDinosaur wrote:

With the above circuit, if RAM is selected during Ø2 low, there will be only one gate delay after Ø2 goes high before /RD or /WD is asserted.  Using 74AC or 74AHC logic, that delay will be in the single-digit nanosecond range.

If you don't want to spend ¾ 74xx00 on it, but have ½ a 74xx139 left over, this Acorn Atom solution might be the thing for you

[BigDumbDinosaur]

L0uis.m wrote:

Hello 0010 all,

BigDumbDinosaur wrote:

With the above circuit, if RAM is selected during Ø2 low, there will be only one gate delay after Ø2 goes high before /RD or /WD is asserted.  Using 74AC or 74AHC logic, that delay will be in the single-digit nanosecond range.

If you don't want to spend ¾ 74xx00 on it, but have ½ a 74xx139 left over, this Acorn Atom solution might be the thing for you

That works as well, although you wouldn’t (shouldn’t) be using a 74LS device in a 65C02 or 65C816 circuit.  Just be aware that the 74xx139 is slower than most gates of the same logic type; e.g., a 74AC139 is about 25-30 percent slower than a 74AC00 in terms of TPD.

As it has worked out in my designs, the otherwise-unused gate in the 74AC00 doesn’t go to waste.  I use it as an inverter in the reset circuit for devices that require a high-going reset.

[teamtempest]

Quote:

Someone once said, "The best kind of experience is someone else's."

"Learn from the mistakes of others. You can't live long enough to make them all yourself." - Eleanor Roosevelt (disputed)

"Only a fool learns from his own mistakes. The wise man learns from the mistakes of others." – Otto von Bismarck

"From the errors of others, a wise man corrects his own." – Publilius Syrus, 1st century Latin writer

I will grudgingly admit that I'm finding those little AI summaries that Google is becoming fond of are often actually useful. Unlike many other applications, it's pretty good at summarizing and not noticeably sycophantic.

Somewhat surprisingly to me, these few lines took a far longer amount of time to come up with than it usually does. And there was only one (1!) link in the results. And not one to "Bartlett's Familiar Quotations" or something like that, which I had expected.

[BigEd]

You do always need to check the results, though. The provided citations often fail to support the claims given, in my experience. It may not be sycophantic, but it is unerringly confident, without being unerring.

[Niek6502]

I did some testing with a Microchip PIC18F26Q10 to see if I could use it for glue, providing a clock pulse, debouncing a reset button etc. (An advantage of using a PIC this way is that you can easily change chip select signals, clock freq etc without having to change the hardware on your board. It has 8 logic "cells" (CLCs) which can easily be programmed to provide chip assert signals from various sources. The CLCs work without any "CPU time" on the PIC - it works like a small PLD (so I could then also use the PIC to handle other tasks like driving a display or KB or whatever). I was pretty disappointed with the propagation delay of the logic, and the rise/fall times of the signals. This is a screen capture:

Scope input 1 (yellow line) shows a signal from a 1MHz oscillator (MCO-1510A), and scope input 2 (blue line) shows that clock signal after it went through one of the CLCs. The propagation delay is about 60ns, and the rise time is about 30-40ns. It shows the same rise/fall times when outputting a clock signal directly from the PIC (without any CLC etc).

I was hoping for a spiffier propagation delay and (more importantly) a quicker rise/fall time, but at least digging through some docs seems to indicate propagation delay is between 30 and 70 ns. I can't find any data on rise/fall times for output pins. Hm.

I checked the forum posts, and I could not find any recent discussions about using CLCs in PICs (a few posts from 10 years ago). Anyone has any recent experiences?

-Niek.

[BigEd]

Oh, that's slower than I would have guessed. And the CLCs always seemed like such a good idea.

[barnacle]

Does the PIC have an option to change the drive speed (rise/fall times) of the output like STM parts do?

Though I discovered some time ago that with the slower drive speeds, the output timing changed with temperature, which was confusing for a while (and then annoying).

Neil

[BigDumbDinosaur]

BigEd wrote:

Oh, that's slower than I would have guessed. And the CLCs always seemed like such a good idea.

The sluggish rise/fall times are particularly bad.  None of the 65C02 inputs, other than NMIB, have Schmitt action.  I suspect that with such slow rise/fall, stability would quickly become a problem with any attempt to speed up Ø2.

[Niek6502]

BigDumbDinosaur wrote:

The sluggish rise/fall times are particularly bad.  None of the 65C02 inputs, other than NMIB, have Schmitt action.  I suspect that with such slow rise/fall, stability would quickly become a problem with any attempt to speed up Ø2.

Seems likely. I had a few little projects in mind (like having the system boot off of the ROM and copy code from some storage into RAM, assert RESB, reprogram the glue, and let it boot up again so it starts the program loaded in RAM - just for fun). I might still give it a go, as I will be running this setup at 1MHz for now.

If anyone is interested in some PIC CLC code that is actually readable (instead of going through an annoying Windows GUI that spits out way-too-complex code) let me know.

-Niek.