Hi guys

I've been playing around with an ATMEGA 328P Microcontroller for communication with RS232C.
All works quite well.
I was wondering: Has anyone tried to use an AVR or PIC as a ACIA/UART in a 65C02 design? I was thinking of either interfacing a '328P with a VIA or, even better, talk directly with the 65C02 bus.
I can't see this being a major problem. I could even simulate an 65C51 flags, memory mapped locations, etc...
Can anyone see any potential issues?

It would work well hooked up to a VIA with handshaking etc. Less sure about directly hooking it to the CPU bus. Maybe with some very tight AVR ASM... Whats the max clock rate on that AVR?

Not my cup of tea in any case.

_________________
8 bit fun and games: https://www.aslak.net/

Max clock is 20MHz

Hi banedon.

Could you use something like a flip-flop with the ACIA chip select signal as an input and the output connected to the 65C02 'RDY' line to have the 65C02 "wait" for the time required by the AVR to (A) recognize it's chip select, (B) select internal UART register based on the A0..A3 address lines, (C) setup port data direction register according to the R/W line, and, (D) push or pull data to/from the data bus? Of course the AVR would have to clear the flip-flop to allow the 65C02 to complete the current 65C02 cycle.

The AVR microcrontroller have several interrupt lines that can trigger by a high-low or low-high transition. So 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. You have enough time to read the databus and the address lines and react on that. You could simulate several hardware by one 328P by trggering different code on different chip select signals. You ATMEGA could work as ACIA and as VIA at the same time.

_________________
How should I know what I think, until I hear what I've said.

What's wrong with using a real UART?

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

The biggest issue would be dealing with reading the UART, since the AVR would have to very quickly assert the data, then tri state the bus on the very next clock.

I second BBDs question.

_________________
8 bit fun and games: https://www.aslak.net/

Hi banedon,

to interface the 6502 with a microcontroller you need to implement some registers that can be read or written by the 6502. You need to create a protocol so the 6502 and the AVR can exchange "data". So the effort is quite high. You basically have two options, a asynchronous design and a synchronous design. The Asynchronous design would use "ready" and "ack" status signals that tell the other side when a datum has been sent or when a datum has been read by the either side. Daryls' text video V2 is an example when the 6502 writes to the AVR. The reverse can be used to allow the AVR to send data to the 6502. Or you use the RDY to stop the 6502 and use an interrupt to let the AVR do the rest.

The synchronous design would require that everything happens synchronously to PHI2. The easiest is to have the AVR create PHI2 and poll a "chip-select" and read some address bits to know when to read or write to the 6502 like in Michaels http://forum.6502.org/viewtopic.php?f=1&t=2854&p=31658&hilit=test#p31658 3-chip design. But this is limited to rather low PHI2 clock rates, even if the AVR just copies from the 6502 to the internal registers this uses at least 10-20 cycles. Using Interrupts of the AVR in a synchronous design is out of the question this is too slow. You require at least 7 cycles before the first instruction of the ISR
is executed.

In any case, you should build a solution that is as universal as possible, because to only use the USART of the AVR it is not worth the effort as BDD mentions correctly, however if you once have a general solution then you could use the plethora of IO features of a AVR, including I2C, SPI, Timers etc.

Using a VIA to interface with the AVR is possible but very slow and it uses a lot of pins. Also it is not trivial to build a bidirectional bus between the AVR and the VIA, as each side decides on the direction of the IO pins. Instead of a VIA I would use something like the 74HCT652.

Cheers

Peter

A hybrid solution would be to let the AVR control the clock only when selected. Normally the 65C02 would run at its maximum clock, but when the IO address for the AVR is selected, a simple gate could disconnect the main clock and allow the AVR to clock when it is ready.

And yes, only replacing the UART is not worth the effort. But as Peter said, there is much more in a microcontroller, not just serial interfaces and timers, but an analog comparator, analog converters, PWM outputs, a timer capture input, clock output, lots of flash-ROM... So the possibilities are plenty.

In the next release of my emulator, you will be able to connect other AVRs to utilize their IO capacity. Unfortunately it is a 4 bit bus structure requiring the cooperation of the master AVR and therefore nothing for a native parallel bus CPU.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

That is how I do it in my 3-chip design with the extra advantage that the PIC microprocessor performs the address decoding and doesn't have to poll for its chip select signal.


That's correct. My PIC, with 62.5-nS instruction cycles (like a 16-MHz AVR), uses exactly 16 instruction cycles per 65C02 clock cycle to perform its functions, which limits the 65C02 clock to 1-MHz. If I upgrade to a PIC24 device I could have a 4-MHz 65C02 clock.


I agree. I can only justify using the PIC in my 3-chip design because it provides "direct" full-speed (1-MHz) access to the PICs Serial and high-performance SPI peripheral registers as well as providing the CPU clock and reset signals, a blind loader function, and 'soft' address decoder function. For ROMless designs with 'classic I/O' like an ACIA and/or VIA that don't require PIC peripheral access, I use a 28-pin PIC strictly for Reset, Clock, Loader, and Decoder functions.

I would not change the clock. I would prefer a solution using RDY. A changing clock inhibits parallel use of 65xx peripherals. I already thought about such a solution. But I have still some issues with my setup using RDY. To start a AVR cycle is rather easy, you only need to sample the chip-select that selects the AVR with PHI2 using a 74C74 flip flop. The same chip-select also informs the AVR. Now the AVR has all the time he needs to transfer the datum from the 65xx bus to the internal register or reading a register and put it onto the 65xx bus. However now starts the tricky part. Now the AVR needs to release RDY and at the same time the sampling of the chip-select signal must work immediately in case the next cycle is again for the AVR, e.g. if you use the flash. With high 65xx system clock rates this could be a challenge. I have not encountered a good solution for this. However using the flash will be slow, so I would not consider it, but still RDY must be released considering that the next cycle might still use the AVR, e.g. when you use 16-bit transfers together with a W65C816.

Cheers

Peter

P.S. I'm looking forward to your solution to use AVR as IO for your emulator

It occurs to me that in my earlier post I was describing Jeff's (Dr Jefyll's) "wait state generators" from this post and this post in another thread. My apologies to Jeff for the missing attribution.


Forgive me if I'm going off-topic, but, I'm curious... Could that wait-state logic be duplicated in a GAL/PAL?

Look here -> http://sbc.rictor.org/wsgen.html

You can use this as a starting point.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Daryl pointed you to his GAL implementation of a wait-state generator, which is a good way to go about it. The same logic will work in a CPLD or an FPGA—Daryl's CUPL code with minor alteration is how I implement ROM and I/O wait-stating in POC V2's CPLD.

As a reminder, the NMOS 6502 does not respond to RDY during a write cycle. That deficiency was one of the reasons Commodore used "clock stretching" in the C-128 when I/O devices were being accessed.

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

All these wait state generators generate a fixed predicted number of wait states. Has anyone a more bus related wait-state generator? I mean something like used in typical bus protocols where the CPU is always halted until a ACK signal is generated by the selected device (IO, Memory, ROM etc). Preferably the ACK should be a edge sensitive signal. E.g. in a PDP-11 system the CPU always stalled when performing a read or write until a CONT signal was asserted on the bus. Even Memory had to create the CONT signal.