6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 21, 2024 8:29 pm

All times are UTC




Post new topic Reply to topic  [ 581 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 39  Next
Author Message
 Post subject:
PostPosted: Fri Oct 23, 2009 1:50 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
kc5tja wrote:
So far, I've found the 6522 quite pleasant to work with. That being said, I have spent many hours of my youth interfacing to the world with the 6526A and 8520A chips. I miss them dearly.

Still, I'd be interested in hearing your critique of the 6522 relative to the 6526.

I have several beefs with the W65C22S (the current incarnation), the first being that its IRQ output is not open drain and therefore can't be wire-OR connected to other open drain interrupt sources like you can with the 6526. A diode must be used to isolate the 'C22S interrupt line from the open drain circuit, which will cause some degree of interrupt latency. It completely escapes me why this was done. The NMOS 6522, while still a bogus design in my opinion, used an open drain IRQ.

Timer 2 can't be ganged to timer 1 to produce a 32 bit timer. You can configure timer B in the 6526 to count timer A underflows, producing a possible time interval of Ø2 * (2^32) -1.

In the 6526, a single register is used to define interrupt sources and to determine the cause of an interrupt. Reading the register automatically clears pending interrupts, requiring no special code to do so. The 6522 has two such registers, one to define interrupt sources (IER) and another (IFR) with the flags that indicate the interrupt source(s). When the 'C22S interrupts, the MPU must read the IFR to determined the source and then must write to the IFR a 1 bit corresponding to the interrupt source so as to clear it. Why was this two step process necessary? All it does is increase the code to be executed in the interrupt service routine.

It's a dumb piece of s**t silicon that is almost as bad as the 8563/8568 VDC used in the C128.

Quote:
An interesting idea here is to perhaps "bond" the multiple ACIAs into a single logical connection, thus providing greater throughput over your link.

In theory, such a link could achieve 921.6 Kb/s (92.16 KB/s using 8N1 format) throughput, but in practice what you are suggesting wouldn't work. The output of any ACIA is a bit stream slaved to a fixed clock (3.6864 MHz in the case of the 2692 and 2698). How would you funnel that down one wire and be able to tell which bit is which? You'd have to figure out how to take each bit stream from each ACIA and send it as a distinct FM signal to get it across one wire. Rigging up Ethernet would be less trouble.

Quote:
Actually, this rumor that Gore "invented" the Internet, or that he claimed as such, is demonstrably false. The transcript of his speech shows that he supported or authored the legislation which "enabled" the growth of the Internet industry, which history shows he did.

Yes he did support that legislation, but some years later he did intimate that the Internet was of his making, a claim I'm sure Jon Postel, Vint Cerf and others would have quickly quashed, had they been political sorts.

Quote:
The popular press, dominated as they are by right-wing interests, coined the phrase we all know and love to make fun of Gore for today.

There are plenty of other things to poke fun at Gore for legitimately -- this isn't one of them.

Actually, little of the press is in conservative hands. Most newspapers today are decidedly middle or left of center, and my take on most of the TV news broadcasts is that they have a liberal bent. The only really conservative TV news network right now is Fox, and they lean sufficiently far to the right to almost balance what has become a predominantly liberal media in this country. I really don't pay much attention to any of it, as it's mostly useless crap they report.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Oct 23, 2009 4:51 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
BigDumbDinosaur wrote:
It completely escapes me why this was done. The NMOS 6522, while still a bogus design in my opinion, used an open drain IRQ.


Of course, I cannot speak for WDC. However, I do know that open-drain or open-collector circuits have significant problems when you drive cycle times narrower. Since the 65C22 is rated to 14MHz, I suspect that an open-drain signal would be low for longer than desired after its IRQ is acknowledged, which depending on how the interrupt handler is written, may cause spurious interrupts.

Quote:
Timer 2 can't be ganged to timer 1 to produce a 32 bit timer. You can configure timer B in the 6526 to count timer A underflows, producing a possible time interval of Ø2 * (2^32) -1.


Yeah, I can see how this can be problematic, particularly if you are interested in maintaining precise timing for things like timer services in a multitasking operating system.

Quote:
The 6522 has two such registers, one to define interrupt sources (IER) and another (IFR) with the flags that indicate the interrupt source(s). When the 'C22S interrupts, the MPU must read the IFR to determined the source and then must write to the IFR a 1 bit corresponding to the interrupt source so as to clear it.


This design isn't unique to the 6522; the Amiga's chipset worked in a similar way, as does the Intel PIC chips (I do not know if APICs work this way, however, not having seen their datasheets). I predict that the 6522 was implemented this way because other contemporary chips did similarly, and thus, it minimized the "impedance mismatch" of engineers familiar with Intel's chips switching over to the 6522.

A lot of times, decisions like this have more to do with marketing than technical rationale.

However, one possible use of having split registers for these purposes may also stem from the contemporary computer systems not having a lot of RAM, and so even a single byte to cache the VIA's IFR was considered expensive. When the 6526 came out, it wasn't uncommon for computers to have 32K or more installed, and thus might have become a non-issue.

Quote:
It's a dumb piece of s**t silicon that is almost as bad as the 8563/8568 VDC used in the C128.


No. I must take exception to this extremism. The VIA is a solid chip; it has never failed, and I never found any aspect of this chip lacking. While I lament the lack of 32-bit timer capability, it's hardly a show stopper. The other things you consider a misfeature, I consider non-issues, and consequently, see no reason to object to the chip what-so-ever.

The VDC, on the other hand, is utter trash. The ONLY thing it got right was the auto-increment of memory address when reading or writing data to the data port. Allegedly a derivative of the 6845 used in the PETs, the register set shows only superficial resemblance; for everything else, it drew too much power, slowed everything down, and exhibited too many bugs. I would not even consider using this chip to wipe dog-doo off the floor.

Quote:
In theory, such a link could achieve 921.6 Kb/s (92.16 KB/s using 8N1 format) throughput, but in practice what you are suggesting wouldn't work. The output of any ACIA is a bit stream slaved to a fixed clock (3.6864 MHz in the case of the 2692 and 2698). How would you funnel that down one wire and be able to tell which bit is which?


You wouldn't. By definition, what you're describing is called PDH, plesio-synchronous data hierarchy, and uses time-division multiplexing to work (no need for FDMA, which your allusion to FM implies). It's how T1s and DS3s and such work -- a single copper cable with a MUX on the transmitting side, and a DEMUX on the receiving side, and a continuously increasing counter on both ends, synchronized on each end. This way, to give just one example, 24 slowish 64Kbps circuits can be multiplexed over a single cable to deliver T1's famous 1.544Mbps throughput.

What I was describing was using multiple serial links treated as a single logical connection. This is the definition of a "bonded" link (as distinct from a plesiosynchronous link). You most often hear the term these days in conjunction with T1s (ironically!) because a bonded T1 offering 3Mbps to 6Mbps proves much cheaper than a fractional DS3 of comparable throughput. Another application in contemporary electronics is the PCI-e standard (a 16x PCI-e bus interface is literally 16 PCI-e 1x channels working in unison).

Quote:
Actually, little of the press is in conservative hands.


I'm sorry, but this, and everything you say thereafter, is just plain poppy-cock with vanishingly little evidence to support these claims. While I will concede that CNN is more left than FOX, to call it a left-leaning station is wholesale inaccurate. Indeed, the single left-most station I've seen is (ironically!) MS-NBC, but even here, their content is optimized to earn Microsoft revenue from ratings.

So, don't hold your breath.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Oct 23, 2009 5:03 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
I have no complaints at all about WDC's VIA totem-pole IRQ\ output, as it frees us from having to think about how many clock cycles it takes for IRQ\ to float up after it's released, something that can otherwise be an issue at higher clock speeds as Samuel alluded. I got bit by that one in the late 1980's with an all-CMOS system with Rockwell parts even running at a couple hundred kHz and with an IRQ\ pull-up that I made too weak in order to save a miniscule amount of battery power. Interrupt latency on the '02 is 2 clocks average to complete the instruction in progress, plus 7 clocks for the interrupt sequence. Adding the teensy amount of gate delay for an AND gate adds insignificantly to the interrupt latency, and might even be less than the added slew time for an IRQ\ output to pull down a loaded line that goes all over the board (and sometimes off-board through connectors too) to various interrupt sources. I also have absolutely no complaints about the operation of the R/W\ line.

As for timers, it would be nice if you could make a timer register's contents appear continuously at the pins, like the 8536 (IIRC) did in an arbitrary waveform generator I used in 1990 did. That 8536 ran extremely hot though. In the rare need to link timers, you can connect T1's output on PB7 to T2's input on PB6. Otherwise, generating an interrupt every 64K clocks for the software to increment another counter in RAM is pretty low overhead. It's nice that the 6526 had the TOD clock, but with no resolution finer than 1/10th of a second and no calendar functions, I don't get terribly interested.

Quote:
When the 'C22S interrupts, the MPU must read the IFR to determined the source and then must write to the IFR a 1 bit corresponding to the interrupt source so as to clear it. Why was this two step process necessary?

Having several interrupt sources enabled simultaneously in a single VIA is rather uncommon; so if the VIA interrupted, you don't have to see which possible source within the VIA did it. Even if you do have multiple sources enabled, there's still no need to test for the non-enabled ones. In most cases, the interrupt is cleared automatically by the action that the interrupt requires. For example, if it's telling you it completed the shift-in or -out of a byte in the shift register, reading the byte that just came in or writing a new one to send out will clear the interrupt. If you're using T2 as a one-shot timer, re-writing it clears the interrupt. If you're using T1 to produce a stream of evenly spaced interrupts, just reading T1CL clears the interrupt. Etc.. If you weren't going to act on it immediately, you probably would not have the interrupt enabled, so then it becomes a non-issue. Most of my accesses to the IFR treat it as a status register, separate from actual generation and service of interrupts. For example, I read it to see if CA2 has been strobed, even though I don't have the IER set up to produce interrupts when CA2 is strobed. It wasn't urgent, so there was no need to enable the interrupt. I don't think I've ever written to the IFR in an ISR.

The 65c22 has been used in a lot of non-65xx systems too though, including PCs and 68000 computers.

If you were to criticize the 6551 ACIA, I would be more in agreement. I've used it a lot, and it definitely has some design shortcomings. The 6551 can do 115kbps, just not while generating the clock itself from 3.6864MHz. I like the MAX3100 14-pin-DIP UART which is interfaced via SPI. My workbench computer has 3 ACIAs, although one of them was for use with a tape modem that I built with about a dollar in parts to put data on any inexpensive cassette, and with excellent reliability, but the fact is that now with serial EEPROMs and flash memories, there's no point at all in using a tape modem anymore. Another ACIA was intended to be used primarily with MIDI, but I never did much with that. Daryl sent me one of his 65-SPI chips with the idea that I could make an adapter board to plug it into an ACIA socket, but I still haven't gotten around to it. These projects go very slowly. A more appropriate use for one of the ACIAs might be a mouse. I also got the tiny transmitter and receiver to make a wireless link to connect to one of the ACIAs, but that's another project that sits collecting dust, even though I have an application in mind, which is to take temperature data from a wheel turning at hundreds of rpm and transmit it to the workbench computer for real-time readout.

Although I have my memory divided along the coarser lines of 16 and 32K, I do have RAM gated by phase-2, and all my address-decode logic can be done with a single 74xx00.

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Oct 23, 2009 7:05 am 
Offline

Joined: Tue Nov 18, 2003 8:41 pm
Posts: 250
GARTHWILSON wrote:
Quote:
The problem, of course, with using the '573 to latch A16-A23 it that the BA7-BA7 value MUXed on the data bus vanishes too soon after the rise of Ø2. From what I've worked out, the '573 wouldn't have latched by the time the bank address on D0-D7 becomes invalid.

It doesn't matter, because the '573 does not require any hold time at all. Actually it may be negative by a nanosecond, so you could even change the data at the same time the latch enable goes low, and it will hold the right data.


The datasheets I looked at give hold times of 1-2.5 ns
depending on conditions and manufacturer (and similar
setup times)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Oct 23, 2009 7:14 am 
Offline

Joined: Tue Nov 18, 2003 8:41 pm
Posts: 250
kc5tja wrote:
Quote:
Actually, little of the press is in conservative hands.


I'm sorry, but this, and everything you say thereafter, is just plain poppy-cock with vanishingly little evidence to support these claims. While I will concede that CNN is more left than FOX, to call it a left-leaning station is wholesale inaccurate. Indeed, the single left-most station I've seen is (ironically!) MS-NBC, but even here, their content is optimized to earn Microsoft revenue from ratings.

So, don't hold your breath.


It is my fervent wish that we'll all agree this is offtopic
and inappropriate for these forums.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Oct 23, 2009 7:41 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
Quote:
The datasheets I looked at give hold times of 1-2.5 ns
depending on conditions and manufacturer (and similar
setup times)

Maybe I should have said I was looking at my National data book on the 'ACT573. After a closer look, lacking actual diagrams, it seems to be saying the hold time could be anwhere from -1ns to +1.5ns, typically 0ns.


About the politics:
Quote:
It is my fervent wish that we'll all agree this is offtopic
and inappropriate for these forums.

I was thinking the same thing, although I kind of started it by agreeing with BDD's anti-Windows signature line. Most of us have plenty to say about the political stage, but saying it on this forum will probably kind of ruin our 6502 talk and comraderie.

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Oct 23, 2009 11:55 am 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1043
Location: near Heidelberg, Germany
BigDumbDinosaur wrote:
I have several beefs with the W65C22S (the current incarnation), the first being that its IRQ output is not open drain and therefore can't be wire-OR connected to other open drain interrupt sources like you can with the 6526. A diode must be used to isolate the 'C22S interrupt line from the open drain circuit, which will cause some degree of interrupt latency. It completely escapes me why this was done. The NMOS 6522, while still a bogus design in my opinion, used an open drain IRQ.

I understand that this was done to support IRQ operation in higher clock frequency situation. As such, I can understand the change and it is easy to care for.
Quote:

In the 6526, a single register is used to define interrupt sources and to determine the cause of an interrupt. Reading the register automatically clears pending interrupts, requiring no special code to do so.

Which is one of the most annoying thing in the CIA to me! I'm writing a "real" operating system for 6502 computers, with device drivers that sometimes need to share a single piece of silicon like the CIA or VIA.

Now in the interrupt routine, it is very nasty if the first device driver polling the interrupt flag clears all interrupts - with no chance for a later driver to pick up its own interrupt source. VERY annoying!

Quote:
The 6522 has two such registers, one to define interrupt sources (IER) and another (IFR) with the flags that indicate the interrupt source(s). When the 'C22S interrupts, the MPU must read the IFR to determined the source and then must write to the IFR a 1 bit corresponding to the interrupt source so as to clear it. Why was this two step process necessary? All it does is increase the code to be executed in the interrupt service routine.

As has been quoted already, handling the timer or shift registers etc itself clears the interrupt already. And always being able to read the register without side effects is in general a very good thing.

Imagine even the usual ".byte $2c; label: LDA #$CC" in a C64. The code executing the "$2c" opcode is actually a "BIT $CCA9" - what register is that in the CIA's mirrored register file? Accidently reading the interrrupt register and clearing them is not good. (I've made the address values up, too lazy to look them up now but you get the idea)

Quote:
It's a dumb piece of s**t silicon that is almost as bad as the 8563/8568 VDC used in the C128.


The VIA and CIA still are amazingly versatile I/O chips, and, for most parts, well done!

The only grudge I have with the VIA is the shift register bug...

André


Top
 Profile  
Reply with quote  
 Post subject: POC Computer
PostPosted: Sat Oct 24, 2009 4:46 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
GARTHWILSON wrote:
I don't think you'll want the address and data bus drivers.

After diligent study of the W65816S DC characteristics, as well as some E-mail exchanges with WDC, I decided that Garth had a point about the MPU's drive capabilities. Accordingly, I reworked the design to eliminate the bus line drivers. Here are the modified schematics:
And, the resulting PCB, which is now 5-3/4" by 3-1/2", well under the 21 square inch limit for the ExpressPCB's ProtoPro product:
:)

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Oct 24, 2009 5:17 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
Quote:
And, the resulting PCB, which is now 5-3/4" by 3-1/2", well under the 21 square inch limit for the ExpressPCB's ProtoPro product:

Your density is already excellent; but if it makes it possible to get away with an even smaller board (or, in the future, easier to route if you do it by hand), remember that with the RAM, you can mix up the data lines and mix up the address lines. Same with ROM, although then you need to make an adapter to program it accordingly. I did that on a product we used to sell.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Oct 25, 2009 3:49 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
GARTHWILSON wrote:
Your density is already excellent...

Wouldn't be the first time I've been described as "dense." :D

Quote:
...but if it makes it possible to get away with an even smaller board (or, in the future, easier to route if you do it by hand), remember that with the RAM, you can mix up the data lines and mix up the address lines.

The above PCB layout is hand-routed, although I do use the netlist features in ExpressPCB's software to help avoid errors.

As for "mixing up" the RAM or ROM pins, the use of the PLC44 version of the '816 results in a somewhat natural layout, requiring few crossovers with the address and data bus traces. As a result, I can wire it with a one-to-one correspondence.

After considering several layouts, I concluded that the horizontal bus runs should progress from D0 to D7, with D0 closest to the underside of the MPU, followed by A0-A15. That seemed to work out with the shortest traces, which should help keep a lid on distribute capacitance.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Oct 25, 2009 4:48 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
fachat wrote:
BigDumbDinosaur wrote:
I have several beefs with the W65C22S (the current incarnation), the first being that its IRQ output is not open drain and therefore can't be wire-OR connected to other open drain interrupt sources like you can with the 6526. A diode must be used to isolate the 'C22S interrupt line from the open drain circuit, which will cause some degree of interrupt latency. It completely escapes me why this was done. The NMOS 6522, while still a bogus design in my opinion, used an open drain IRQ.

I understand that this was done to support IRQ operation in higher clock frequency situation. As such, I can understand the change and it is easy to care for.


Well, I see a lot of high speed stuff with open drain IRQ outputs, so it must not be as big a deal as suggested. In fact, I've been studying the data sheet for the AM53C94 SCSI ASIC and I see it has an open drain IRQ output, even though it can be clocked as high as 25 MHz, a 40ns cycle time. Obviously, AMD wasn't worried about inadequate IRQ circuit performance when they developed that part.

The rationale that has always been presented for having a totem pole IRQ output, as in the 65C22, is that it can result in a faster transition on the line, since actively driving it both ways negates some of the reactive effects of the circuit traces, especially the distributed capacitance that must be recharged when the line goes high. However, much of that can be avoided by proper PCB layout and by using the lowest value pullup resistor consistent with the sinking abilities of the "weakest" device that is sharing the IRQ line. Just because the data sheet says you should use, say, 3.3k, doesn't mean that is the optimal value. Anything that reduces the RC time constant will improve the transition time on the IRQ line.

Naturally, the type of resistor used is important. A typical carbon comp or carbon film resistor has loads of both inductance and capacitance. In my design, I have a number of circuits with pullups, so I used some Bourns SIP style resistors (which have low reactive effects) to reduce space consumption and make it possible for the resistors to be as close as possible to the MPU. It all helps in keep reactive effects under control.

Naturally, the front end of the interrupt handler should clear the interrupt source as soon as practical to assure that IRQ has adequate time to go high before IRQs are re-enabled. That is a basic of hardware level programming that has existed since back when I was using a Tele-Type to program post office computers.

Quote:
Quote:
In the 6526, a single register is used to define interrupt sources and to determine the cause of an interrupt. Reading the register automatically clears pending interrupts, requiring no special code to do so.

Which is one of the most annoying thing in the CIA to me! I'm writing a "real" operating system for 6502 computers, with device drivers that sometimes need to share a single piece of silicon like the CIA or VIA.

Now in the interrupt routine, it is very nasty if the first device driver polling the interrupt flag clears all interrupts - with no chance for a later driver to pick up its own interrupt source. VERY annoying!

In such a system, you should be using a prioritized interrupt circuit that identifies each interrupting source. Each source should have a specific front end whose first job is to read (and clear, if necessary) the interrupt flag register and store the contents. Once that front end has done its work, it can dispatch the MPU to the relevant event handlers (e.g., timer A underflow). The jump table (good place to use the 'C02 and '816 JMP (ADDR,X) feature) would also prioritize how events within a given device would be handled. After the event handler has finished its work, it would go back to the dispatch code to handle any other pending events (e.g., a timer B underflow). Upon completion of all event processing, you go to a common interrupt exit. If another (lower priority) device has interrupted, the whole process gets repeated as soon as the MPU RTIs, but with a different interrupt handler front end and a different dispatch table.

Quote:
Imagine even the usual ".byte $2c; label: LDA #$CC" in a C64. The code executing the "$2c" opcode is actually a "BIT $CCA9" - what register is that in the CIA's mirrored register file? Accidently reading the interrrupt register and clearing them is not good. (I've made the address values up, too lazy to look them up now but you get the idea)

The .byte $2C (and .byte $24) trick, although lamentably common with 6502 machine code, is usually bad practice, precisely for the reason you described. I recall years ago describing the sequence as a "harmless BIT instruction." Obviously, if it BITs a register, it's not harmless. I have to admit having used that technique now and then but generally have stayed away from it. If someone who worked for me did that I'd have to castigate him for writing booby-traps into his code. :)

BTW, all C-64 I/O hardware appears in the $D000 range.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Oct 25, 2009 6:48 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
Quote:
A typical carbon comp or carbon film resistor has loads of both inductance and capacitance.

I've never seen inductance or capacitance specifications on resistors, although the approximate inductance would not be difficult to calcultate from lead length, resistor body length, height above the ground plane, size of spiral in the film on the slug and number of turns in it if any, etc.. When I worked in VHF and UHF applications engineering in the mid-1980's, the carbon composition resistors worked fine, but we stayed away from the carbon film resistors especially in low resistance values because of the spiral cut in the film to adjust the value as accurately as they get them, as the spiral adds inductance. I didn't use leaded capacitors on the microstrip, but I did use 1/4W and 1/8W leaded CC resistors with the leads so short they were almost non-existent. The application was power amplifiers used for transmitters, up to a few hundred watts, mostly military. Resistors were sometimes used for biasing, but I also used them in the gate circuit to stabilize high-gain MOSFET power amps running at frequencies much lower than the transistors were able to operate (and oscillate!) at. My work there ranged from 30MHz to 2.4GHz, although most of my design work was at 175MHz. I didn't do any actual design work above 450MHz. I really don't think inductance and capacitance is an issue with most resistors, but if you can point to data to the contrary, I'd like to know. Obviously we're not talking about wire-wound.

An interesting related thing I found out recently is that mulilayer cermic chip capacitors (MLCCs) have a dramatic reduction in capacitance when you get them above about 20% of their WV. (That's X7R dielectric. Y5V and others are worse.) So if you want low distortion, you have to use a much higher WV than you might think. For our audio products with a 12V supply and peak audio signal voltages of slightly less, that means a minimum of 50WVDC to avoid capacitor-induced distortion at low frequencies! EDN had an article about it starting on page 77 of the April 12, 2007 issue. I will definitely be using bigger package sizes for some of the capacitors in our next product, in order to make sure I stay in the flat portion of the curve. On our newest product, I put in 0603 in a few places I should have put in 0805, and some 0805's probably should have been 1206's to get the higher voltages without going to the SMT 'lytics.

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Oct 25, 2009 4:06 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
GARTHWILSON wrote:
I really don't think inductance and capacitance is an issue with most resistors, but if you can point to data to the contrary, I'd like to know.

Periodically I've run across write-ups in which the author cautions about the reactive effects of carbon comp/carbon file resisters. I can't say, however, that I've ever seen any published data to that effect. In any case, I think at the frequencies at which 65xx hardware runs, lead inductance would be a negligible factor in circuit performance. As you say, lead length, position relative to the ground (or power) plane, etc., can be more important than the actual reactive characteristics of the resistor itself.

Quote:
Obviously we're not talking about wire-wound.

Obviously. :)

Your remark reminds me of a guy I knew who was trying to build an artificial load for use with audio amplifiers. This was back when tubes still dominated hi-fi audio and the Sylvania 8417 beam power tetrode was the king of the hill (I built several 8417 powered amps that cranked out 100 watts RMS at about one percent THD). He decided to use a large ceramic tubular style WW resistor. Well, as luck would have it, the inductance of the resistor combined with other circuit factors resulted in the world's most powerful one-frequency audio oscillator. :D

Quote:
An interesting related thing I found out recently is that mulilayer cermic chip capacitors (MLCCs) have a dramatic reduction in capacitance when you get them above about 20% of their WV.

Interesting you mentioned that, because I recall reading a whitepaper about that phenomenon some years ago when the MLCC caps started to become popular in digital design. The paper had recommended using a part with a WV at least twice that of the highest expected voltage in the circuit. It was also pointed out that the actual voltage seen by the cap was not simply the DC voltage difference of the circuits that it was coupling. This would seem obvious (to me, at any rate) but could be overlooked in an audio or RF design.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Sun Oct 25, 2009 9:28 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Oct 25, 2009 6:18 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
8BIT wrote:
... My SBC-3 runs at 8MHz and uses a 15ns CPLD and 12ns SRAM. I have the logic programmed as a transparent latch and it runs well.

Now, I have not tried to run it up faster. Purhaps I'll experiment with that when I get some time. I think I have a 14 MHz oscillator floating around somewhere. That gives me about 35ns of PHI2 low time.

Got a busy week planned... will try this weekend.

Daryl

Here are the inital results from my testing of the upper address line (A16-A23) latch.

I have stripped the video generator portion of my CPLD out and connected my Zicor UART to my SBC-3 Core. I verified the core worked at the original 7.159 MHz. (14.318MHz / 2) I had forgotten that I need to have a 2x PHI2 clock Oscillator to allow the RAM /WR logic to function properly.

I then changed Oscillators and have successfully run up to 12.59 Mhz. The fastest Osc I have on hand is a 25.175 MHz. For testing, I am copying RAM contents from one block to another and back.

I have some DS1075 programmable oscillators, but have not used them before. If I can get one programmed, I may try some faster clock speeds.

Daryl


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Oct 25, 2009 9:30 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
8BIT wrote:
Here are the inital results from my testing of the upper address line (A16-A23) latch...

Should be interesting to see what happens as you ramp the clock up toward 20 MHz.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 581 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 39  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 28 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: