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.


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.


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.


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!

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.



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.



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.



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.



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).



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.

_________________
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 datasheets I looked at give hold times of 1-2.5 ns
depending on conditions and manufacturer (and similar
setup times)

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

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

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.

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!


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)



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é

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:

Memory Map

Microprocessor Interface & Chip Decoding

RAM, ROM & I/O

External Interface

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:

Printed Circuit Board

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

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.

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


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!

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.


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.


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!

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

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.


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.


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!

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

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!