6502.org

Just another possible idea for using an AVR without using RDY or a VIA interface.

The main problem it seems is the delay of the AVR Data Direction Register since it has to be controlled in software.
If 2 AVR ports were used, 1 port set for input and 1 port set for output then the S/W delay of port I/O switching is removed.
The AVR output port would need a tri-state buffer between the 6502.

Any thoughts?

jmp(FFFA), to reply without quoting everything:

There's a performance comparison at http://westerndesigncenter.com/wdc/AN-0 ... risons.cfm . The Sieve of Eratosthenes benchmark is blank for the 68K, but I remember seeing elsewhere that the '816 compared favorably to the 68K.

I know 68K enthusiasts definitely like the programmer's model. It is more suitable for certain compiled languages like C. The 6502's extended set of registers is of course zero page, and the 816's is the direct page which is like zero page but renamed because it can be relocated, and every task can have its own DP. (The '816 is much better suited to things like multitasking and relocatable code than the 6502 is.) BigEd observed, "With 6502, I suspect more than one beginner has wondered why they can't do arithmetic or logic operations on X or Y, or struggled to remember which addressing modes use which of the two. And then the intermediate 6502 programmer will be loading and saving X and Y while the expert always seems to have the right values already in place."

On the segmented memory, the 65Org32 (so-far-vaporware-only) all-32-bit 65816, the bank registers are 32-bit also, serving as offsets for various tasks' beginning addresses but eliminating the 64K boundaries. The 65816's bank boundaries are transparent in long addressing; but without using long addressing all the time, the key is to make the boundaries work for you instead of against you, just as one does with zero page (and on the '816, "direct page," since it can be relocated). The shorter addresses in operands and tables were a benefit especially when memory was far more expensive than it is today.

In the Apple IIgs, the '816 was definitely capable of more than 2.8MHz, but Steve Jobs wanted it held down because he didn't want the IIgs to make the Macs looks bad.

I believe the 68K took 46 clocks for the interrupt acknowledge and interrupt sequence. The 816's is 8 clocks, one more than the 6502's, because it pushes the program bank. Programming manuals usually show ISR examples that are much longer than normally needed, just to cover all their bases, since they don't know your particular situation and they want to make sure they push and initialize everything including things you won't need in many situations.

It is unfortunate that so many ICs are not available in DIP form; but fortunately we can get adapters that are easy to use, like this one from Jameco: There are also thru-hole PLCC sockets, even wire-wrap ones (although the WW ones are expensive and hard to find): The 6522's shift register can only go one direction at a time, so you'd need two for full duplex SPI. I think all the SPI ICs I've used used only one direction at a time though, with dummy data going in the other direction. If you do use the SR, sending a byte is as simple as STA VIA_SR. 16 clocks later, you can do it again, if it's running at half the phase-2 rate. If you can get the next byte to send any sooner, you could check the status but it would be more efficient to just put in a NOP or something like that. If you were transferring a block of data like for an SPI serial memory, you might have for example: and keep the SPI busy pretty much full time. If you were transferring data to and from an SPI-interfaced UART, you would of course have to add code to keep watching to make sure you don't overrun the transmit buffer or re-read already-read bytes from the receive buffer.

I do like the I²C protocol a lot. I think very few devices can handle 5MHz clock rate, and other devices on the bus will need the slower clock rate just so they don't foul things up by responding incorrectly to start and stop conditions and addresses.

I have only bit-banged both SPI and I²C myself. The circuit potpourri page of my 6502 primer has circuits I've used, and links to accompanying source code, and also Jeff Laughton's tricks for fast (single-cycle) I/O with the 65c02. If you bit-bang with his tricks, producing a clock pulse, ie, a rising edge and a falling edge, takes a grand total of 2 cycles. Otherwise it takes usually 12, for INC, DEC, putting the clock line on a 6522's port's bit 0 so you can change just the one bit with these instructions. Put incoming data on bit 6 or 7 so you can test it with BIT without having to use AND.

Even with 16 bit addressing, bank boundaries are effaced during data fetches and stores, as using a 16 bit index on an absolute address facilitates crossing into the next bank. The bank boundaries are really only a concern in executable code, as PB doesn't increment when PC wraps. Given that very few 6502 programs even approach 64 KB in size, that's not a limitation. in my opinion.
In fact, by the mid-1980s, the WDC versions of the 65C02 and the 65C816 were capable of 8 MHz operation. Had Apple chosen to run the IIgs at that speed it would have made the Mac look kind of lame.

My assembly language teeth were cut on the 6502 over 35 years ago. I know the 6502 inside and out and in fact still to this day remember the hex values for several dozen of the opcodes (not to mention ROM addresses, hardware register addresses, etc. of the machines I used back then). Years later, when I transitioned to the 68000, I remember initially being overwhelmed with the sixteen registers, but it didn't take long for me to adapt and begin using them advantageously. In my opinion, both processors can be rewarding for an experienced programmer to work with despite dramatic differences in architectural philosophy. I feel fortunate to have been able to spend time with both of them.

While it is a popular view that the zero page (or direct page on the 6809 or 65816) are like an extended set of registers, there are some fundamental differences in architecture between zero/direct page memory and registers having to do with the presence or absence of the memory bus between the register and the processor. I'd say zero/direct page memory are closer to cache memory than to extended registers myself.
It was part of the snobbery of the day for 68000 programmers to look down on x86 programmers due to the segmented architecture. After all, why should the programmer concern himself with such details when his time was better spent focusing on efficient algorithms rather than worrying about whether or not he needed a far or near pointer when he added more lines to his code. Part of the elegance of programming the 6502 was the complex juggling act required of the programmer in keeping in mind and optimally using the very scarce CPU resources that were available to him. In fact this was a matter of pride that I'm sure extends to many of the old-timers on this group today. Yet it is precisely such limitations that generations of new architectures have sought to eschew (and rightfully so in my opinion). For is it not more valuable to enable the programmer to focus on algorithm design rather than resource management as he works?
I believe The Woz was still at Apple at that time and I'm surprised that he would acquiesce to such demands, much less artificially limit the architecture in such a manner as to make it almost impossible to work around the limitations in all the time that has come since. All of the accelerators that I'm aware of have been relatively limited in that they have been unable to increase the bus speed itself and have instead only focused on adding speed and cache to the processor.
I don't remember the interrupt latency on the 68K, but if its anywhere near 46 clocks then clearly it doesn't make a very good real-time processor. I understand the 6502 was designed to be an I/O processor from the beginning, so it stands to reason that it (and its descendants) would have good interrupt latency. OTOH, the 68000 was designed for computing and was used in many of the early workstations of the day.
I have a mixed background as both a hardware and software engineer, so I'm no stranger to the many SMT to through-hole adapters out there. I frequently design multi-layer PC boards with high-density SMT parts on them but I have a technician do all the soldering. In my home workshop, I've done a few TQFP-100s in the recent past, but it's not my idea of fun:
Having said that, nothing beats solderless breadboard for trying out new ideas or ideas. I am very impressed with the work that Oneironaut is doing with his Vulcan 74 project (to single out one of many impressive projects shared by members here). If I had no other choice, I'll use a surfboard (SMT to through-hole kludge) to enable me to use parts I can't find in any other format, or I'll just design an entire daughterboard I can easily interface to breadboard as I have done with CPLDs in the past (the source of my TQFP-100 soldering "fun"). But in this case there is a readily available off-the-shelf DIP part which I believe can be made to function as a high-performance UART that will afford no performance degradation to any 6502 system into which it is plugged, and which will have a software interface which will be virtually indistinguishable from the real thing. Well, those are my goals anyway, let's see how close I can get to them. And if I'm successful, I'll leverage the work to add SPI, I2C, and any of the other dozen or so hardware peripherals that make the PIC an attractive platform for embedded work.
I appreciate the heads up on some of the things the 6522 can do. I added one to the parts order that went out earlier today and will play with it as soon as is practicable. I'm unconvinced that it will be even equal to a PIC for SPI communications, but I'm certainly open to sticking both of them on a 6502 bus and try them both out.
I only mentioned the 5 MHz clock rate because the standard now goes up to that rate. I haven't used anything faster than 1.2 MHz myself, and most of the hardware I work with is only rated to 400 kHz, with a few being limited to 100 kHz. I imagine a 14 MHz 6502 could bit-bang out the lowest rates itself if it didn't have anything else to do at the same time.
Thank you for sharing your work with the community. Part of the reason I came here is because I could see there were a number of knowledgeable and enthusiastic people who all seem interested in sharing their knowledge and experience. I know few of my engineering peers would see the point of playing around with technology that was designed about four decades ago, but while there are still some differences of opinion here, that is not one of them.

I know there were GS accelerators out by the late 1980s. I've occasionally seen them come up on eBay for ridiculous amounts of money. I seem to recall they ran anywhere in the 4-14 MHz range, though there was nothing they could do about the system bus which peaked at 2.8 MHz unfortunately.

Of course, IMHO, the Amiga made both the Mac and IIGS look pretty lame anyway, and its 68000 was only clocked a bit over 7 MHz. I'll admit it had a lot to do with the other chips supporting the CPU, however.

I had to look up when the SuperCPU came out, which was a 20MHz '816 accelerator for the C64. It was 1996. I thought it was earlier. Bill Mensch said in an interview that in the early years of 6502, production testing was by hand, apparently functional only (ie, no testing of things like timing margins, drive currents, leakages, input voltage thresholds, etc.), and they marked the part for half of the fastest speed it ran fine at, rounded down to the nearest lower number of MHz. So a 6502 that ran at at 5MHz was marked for 2MHz. He said they had some that ran at 10MHz, even in the NMOS days, before the 65c02.

A friend got an Amiga 500 not long after they came out, and showed me some very impressive graphics demos.

It definitely would be nice to have some new 65xx I/O hardware; but it's not really necessary, as BDD pointed out. It would just make bus interfacing a bit easier. The '22 VIA is great for general-purpose I/O, but the new '51 has been a bit problematic, and there's nothing in production that directly addresses SPI, I²C, video, PWM, A/D, etc..

I have become more and more stack-oriented (including virtual stacks, not just the page-1 hardware stack), and using them to keep and pass parameters, have local variables, etc. makes for a reduced need for processor registers. The data stack works well in ZP. It really reduces the need for variables and the chances for contention between different pending routines wanting the same registers or data memory locations at the same time. Sometimes I have thought it would be cool if ZP and page 1 were onboard and each of these two pages had its own bus, making simultaneous access possible. The 6502-based microcontrollers seemed to mostly put their I/O in ZP, making I/O more efficient. This is where the SMB, RMB, BBS, and BBR instructions come in most useful. As long as I/O is onboard (as in a microcontroller), it would be nice to have that in its own page too.

Soldering SOICs and PQFPs with a chisel-tipped iron is pretty easy. After tacking two opposite corners down, you flood an entire side at once, possibly even with one big bridge, then another side, then get the excess solder off the iron and come back and hold the board vertically and go slowly from top to bottom of the row of pins. The extra solder comes off on the iron, leaving just the right amount on each pin, with no bridges, even though the iron's tip is fat enough to touch several pins at once. It works pretty well with a little practice. Extra flux helps but is not necessary, I've found.

I try to not get too much bridged at one time. Cleanup with desoldering braid is all it usually takes.

I've no doubt if there were a big need for it, someone would have already done it. I just figured it would make interfacing a little easier, and lay the groundwork for SPI, I2C, and the other on-board peripherals present on most PICs.
With the prevalence of cheap FPGAs, anyone with the inclination can now experiment with CPU architectures -- either variations on existing themes, or completely new concepts.
I have a concave soldering tip for my iron that works well. You just flood the tip with a bit of high-lead solder, and then run it down a row of TQFP (or other high density) pins. Then put it under a microscope and use some wick on any solder bridges you find and you can finish fairly quickly. For me, the trick is lots of flux and perfectly aligning the chip in place ahead of application of solder. Sounds like your technique is similar. Still, this kind of extremely fine work is not my idea of fun so I prefer to leave it to the guys who do it for a living as many of them are eager to make a few extra bucks soldering up boards for people like me. This is even more true when it comes to board rework involving fine-pitch SMT components where it becomes easy for unsteady hands to ruin traces while trying to lift parts. And all of this bother is exactly why I'd rather work with breadboard and DIP parts whenever possible.

As per my experience with AVR, it has several interrupt lines that can trigger by a high-low or low-high transition.
And you could immediately react on a chip select signal. If clocked fast enough there should be enough time to set the RDY line for the CPU.
Also you have enough time to read the databus and the address lines and react on that.
Actually you can simulate several hardware by one 328P by trggering different code on different chip select signals.

turnkey pcb assembly

Yep. I think you get one level triggered interrupt per 8 bit port (so three for the '328P) and two edge triggered ones. However, the '328 would probably have to be clocked at a much high speed than the system clock - Maybe twice or three times. This would give the AVR time to execute code and still allow the 6502 to keep a constant speed. As most AVR can tolerate 20MHz without overclocking that should be ok unless the 6502 is clocked much higher than 10MHz.

On an AVR an interrupt takes 4 cycles plus the remaining cycles of the currently running instruction (up to 3). The first instruction must deassert RDY and uses another cycle. Don't know, what the timing requirement to deassert RDY is, but it is probably shorter then 1 cycle. So an AVR being 8 times faster than a 65xx is still not fast enough.

Just a quick thought, how about a flip-flop latching the RDY line at CS, the AVR can take as long as it likes to clear the FF and release RDY.

One useful trick is to use the idle sleep mode of the AVR. That way it reacts immediately to the interrupt and there is no executing instruction to wait for. It makes wake-up times consistent (very useful for video stuff) and as short as they can possibly be.

I bet that AVR would run fine at 30MHz. The XMEGA range is rated for 32MHz anyway, but people have found they run reliably up to at least 64MHz without major ill effects. EEPROM seems to be the only weak point, but you can just switch to a lower clock for a while if you need it.

I'm still thinking about starting such a project as well, i.e. using a microcontroller as universal IO. In this thread a lot was discussed related to speed and number of cycles available to the microcontroller etc. But I think what we need is a solution that does neither depend or rely on the speed of the 6502 nor the microcontroller (AVR). Therefore I thought about a RDY generator that allows the 2 CPUs to run at individual speeds without constraints. Here is my proposal
After a Reset all flip-flops are cleared. /SEL is assumed to be the chip-select for IO and is asserted (low) for the IO range. When asserted, this must happen when PHI2 is low, FF IC1A will toggle from '0' to '1' on the next leading edge of PHI2 and pull RDY low. The address bus of the 6502 will be kept in the current state and /SEL will be left asserted. Now the microcontroller can do it's job and when done needs to assert ACK, the leading edge of ACK will trigger FF IC1B (note thate CLR is high so it will follow the D-input on a clock). As now both inputs of the NOR IC3B are low (note that IC2A was cleared after a RESET) the next leading edge of PHI2 will toggle FF IC2A from '0' to '1'. Now one input of IC3A is high and therefore the D-input of FF IC1A will be again high and FF IC1A will toggle from '1' to '0' then next leading edge of PHI2. RDY will now be released and the 6502 will resume it's cycle.
Once the microcontroller has asserted ACK it must de-asssert ack before honouring another IO request.
Using this circuit it does not matter at which clock rate the two CPUs (6502 und microcontroller) will run. Also it does not matter how long the microcontroller takes, the 6502 will wait.
By the way when using this circuit with a 65C816 and using the bank addresses you must take care that the databus of the 6502 will only show the bank address in the first PHI2=Low phase. So you must only latch the Bank address when RDY = high.

Also I would not use /SEL as an interrupt to the microcontroller but rather I would poll the /SEL signal in order to save the interrupt level for other internal tasks of the microcontroller. This also gives you the fastest response.

Peter, your circuit looks good except for an apparent typo. The diagram shows the 74_74 /CLR inputs being driven by PHI2, but I think the signal names have gotten reversed on the left side of the drawing -- the labels PHI2 and /RES have gotten exchanged. (I PM'd you shortly after you posted this on Tuesday, but maybe the PM notification didn't reach you.)

cheers,
Jeff