Thanks Jac! I'm familiar with regulators. I think a 7805 with a heat sink will be adequate for the time being but I could replace it with a switching regulator if needed later.

I'm replacing the R65C02 with a W65C02S today to get rid of the 74HC541 buffers. While reading the datasheet I spotted this:

"During the low power Standby Mode, PHI2 can be held in either high or low state to preserve the contents of internal registers since the microprocessor is a fully static design."

What does "the low power Standby Mode" refer to? I could not find any other mention of it in the datasheet. I thought the clock could be stopped any time?

I'm asking because I'm planning to halt the 6502 like this:

1. Stop the clock (generated by ATmega)
2. Wait some microseconds so that the 6502 can finish whatever it was doing
3. Pull BE down
4. do whatever we like on the bus
5. BE high
6. Resume clock

This is very nice because I can do this in fixed number of cycles on the ATmega. This means I can halt the CPU on certain PAL scanlines, access the SRAM and restart the CPU, similar to how bad lines work on the C64.

The Standby mode is entered, when a WAI or STP instruction is executed. In case of the WAI instruction the µc can be reactivated by IRQ, NMI or reset. In case of the STP instruction the only way to reactivate is a reset. The standby mode does not require to stop the clock and reactivation requires the clock pulses to be present. The clock can indeed be stopped at any time during normal processing.

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

Ok, thank you! I guess the datasheet has an error then -- or at least it's misleading. I think the sentence "during low power standby mode" shouldn't be there in the PHI2 input description.

The data sheet's language could use some refinement. You need to define what you are attempting to do in order to select the manner in which you will do it.

Specifically, you have the following choices:

1. Halt the MPU by asserting (negating) RDY. The MPU will stop on the next Ø2 high and remain stopped until RDY is deasserted. At that time, the MPU will restart on the next Ø2 high. While halted in this fashion, the MPU will acknowledge interrupt input activity but will remain halted. Interrupt processing will occur as soon as RDY has been deasserted and the current instruction has been completed.
   
   
2. Halt the the MPU by executing a WAI (WAit for Interrupt) instruction. The MPU will stop on the next Ø2 high, go into a very low power consumption state (in the microampere range) and remain stopped until any hardware interrupt input is asserted. At that time, the MPU will resume execution on the next Ø2 high. There is a special use of SEI in conjunction with WAI to produce single cycle hardware interrupt latency.
   
   
3. Halt the MPU by executing an STP (SToP) instruction. STP is identical in effect to WAI, but can only be cleared with a reset.
   
   
4. Halt the MPU by stopping Ø2. As both the W65C02S and W65C816S have fully static cores, they can be indefinitely halted by stopping Ø2 in either phase without loss of data. Execution resumption will occur when Ø2 is restarted. Caution must be exercised in restarting the clock so that the phases do not get reversed.

I favor number 1 if stopping and starting the MPU is to be done in hardware, e.g., to generate wait-states for accessing slow devices. Stopping or stretching Ø2 could also be used as a wait-state method, but is more complicated to implement and can result in knotty timing problems.

Methods 2 and 3 are intended primarily for use in embedded hardware that must wait for long periods of time while imposing minimal drain on the power source (usually a battery), yet immediately spring into action when required. An example of such a device would be an implanted defibrillator, which usually spends most of the time awaiting input indicating that its services are required.

Method 4 is actually a byproduct of the implementation of methods 2 and 3. I personally don't recommend halting the MPU by halting Ø2, as timing issues may develop on restart. Accidentally restarting Ø2 in the wrong phase would surely confuse the MPU, since it performs actions on both phases of the clock cycle. Something else to consider is that 65xx peripheral devices are slaved to Ø2 and may malfunction if Ø2 is halted. In particular, the timers in the 65C22 are driven by Ø2 and will cease to keep time if the clock is halted.

Something to note is that halting the MPU by any of the above methods doesn't cause the MPU to relinquish the buses. You must assert BE if you want that to happen. As a fairly general rule, the sequence would be:

1. Halt the MPU.
   
   
2. Assert BE to disconnect the MPU from the buses. The data and address bus outputs, as well as RWB, will go to the high-Z state.
   
   
3. Enable your other device to do what it has to do.
   
   
4. Deassert BE to reconnect the MPU to the buses.
   
   
5. Finally, restart the MPU.

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

Ah, about deasserting RDY to pause the machine - did we conclude that the '816 continues to multiplex the high order address byte onto the databus during phi2 low? I can only remember that there was room for doubt.

I'm using method 4 because stopping the clock does not need any extra pins (RDY can be hardwired). The ATmega has "only" 32 I/O pins, and address and data busses already use 24 pins. The remaining pins are used for outputting video signal, 6502 clock, reset, bus enable, SRAM control pins CE and WE. All in all, it's a very tight fit. Using shift registers or I/O expanders to increase the number of pins isn't really possible because of critical timing requirements.

Interesting you should ask, as I have done some study on this, using POC V1.1 as a guinea pig. What I did was monkey-rig a Dallas DS1813 to the 65C816's RDY input, which allowed me to control RDY with a push button and not have to be concerned about debouncing. Here's what I found:

• The '816 only halts when Ø2 is high, regardless of when RDY is asserted (negated). This means that despite what the data sheet might imply, timing on RDY isn't critical. Practically speaking, one would not assert RDY unless the glue logic indicates that it is necessary. Since the most likely reason for doing so would be to access a slow device, the glue logic would assert RDY as soon as the address of such a device was presented by the MPU. In the case of the '816, that would occur about midway during Ø2 low, at which time VDA || VPA would be true, where || means logical OR.
  
  
• Execution resumes on the next Ø2 low following the release of RDY. This characteristic makes it relatively simple to implement wait-state logic with a flop or two and some gates.
  
  
• A16-A23, of course, only appears on D0-D7 while Ø2 is low and VDA||VPA is true. As the '816 doesn't halt in response to RDY until after the rise of Ø2, A16-A23 would not be present on D0-D7 at the actual start of a wait-state. This makes sense when one considers that the glue logic has to latch A16-A23 on the rise of Ø2. Hence A16-A23 will be maintained as long as the MPU is halted, subject to the caveat that the bank latches must also remain latched while RDY is asserted. This requirement is readily met with programmable logic, and is achievable with a little hoop jumping using discrete logic.
  
  In the CPLD code for POC V2, I define the A16-A18 bits (I'm only using 512KB of RAM in this unit) as latches, not flops. I condition the latches using the following CUPL statements:
  
  
  Code:
  [blatch0..2].LE = vbus & !PHI2 & !rdyout;
  [blatch0..2].L  = vbus & !PHI2 & [D0..2] & !rdyout;
  
  In CUPL, the .L suffix defines a node as a latch and the .LE suffix is "latch enable." The above code says to open the bank latches (blatch, which is defined as having three bits) when the expression vbus, functionally, VDA || VPA, is true, Ø2 is low and no wait-state is in progress (rdyout is false). The next line causes the latches to assume the state of D0-D2, again when conditions are the same as required to open the latches. As soon as Ø2 goes high, the latches are closed and if a wait-state is to occur, rdyout will also go high, preventing the latches from being opened during any Ø2 low that occurs during the wait-state. Hence A16-A18 is maintained for the duration of the wait-state.
  
  
• While the '816 is halted via RDY, all outputs are maintained in the state they would assume during Ø2 high. A0-A15 will reflect the effective address that existed when RDY was asserted, and D0-D7 will maintain whatever it is the '816 is writing if the wait-state occurs during a write cycle. E, MLB, RWB, VDA and VPA will be maintained in whatever state they were in when the wait-state commences. MX will be equal to the state of the x bit in the status register, since the m bit is present on MX only during Ø2 low.
  
  
• The MPU will note any interrupt input during a wait-state, but of course will not act on it until RDY is released and the current instruction has been completed.

It appears that when RDY is asserted the internal clock in the MPU is stopped as soon as Ø2 goes high. I based this conclusion on the fact that executing the WAI instruction causes RDY to go low until an interrupt occurs—RDY is bi-directional. WAI functions by actually halting the internal clock when it goes high, causing the '816 to go into a very low power state. The result is analogous to stopping the Ø2 clock generator source in the high phase.

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

By "hardwired," do you mean RDY is tied directly to Vcc or is it connected through a resistor?

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

4.7K resistor to Vcc to avoid the "RDY is bidirectional on WDC" gotcha.

Progress on ERIC-1 will be probably slow for a while until the Saleae logic analyzer I ordered today arrives. I'm experimenting with running the CPU clock lockstep with PAL video generation, so that the ATmega can access SRAM during phi2 low. Timing needs to be exactly right, and it's almost impossible to verify that it works without logic analyzer or oscilloscope. Hopefully the wait isn't too long...

Ok, I replaced the R65C02 with a W65C02S and removed the two 74HC541 buffers on the address lines. However, I've now got a new problem. I have a ICSP programmer connected to 3 pins of the ATmega microcontroller and those same pins are also connected to three bits on the 6502 address bus. Usually this is not a problem, as long nothing is driving these pins during programming.

However, for some reason this is now preventing reprogramming the ATmega… I would have expected this to work because when the microcontroller is programmed, 6502's BE is pulled down and thus the address bus should go to high-Z state. I believe this is a timing issue: I think when BE goes down, the delay before W65C02S releases the address bus is too long and the programmer sees this as bus contention and gives up.

Note that earlier when I had the 74HC541 buffers on the address lines, there was no such problem. So I'm assuming the buffers on the 6502
are simply too slow for the programmer… could this be it?

As a workaround I've added an extra buffer just for these three address lines. It works but it's a kludge I'd like to get rid of if possible.

Unfortunately I can't change pin assignments.

Any ideas?

The 65C02 timing diagram seems to indicate that the effect of asserting (negating) BE occurs within one clock cycle. You'd have to 'scope it to verify this. Are you allowing enough time after asserting BE before permitting the ATmega to become the bus master?

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

BDD, asserting does not mean negating. Please stop saying this! It adds possible confusion, rather than clarifying.

Unfortunately I don't have control over the timing. The programmer resets the ATmega, which makes the ATmega I/O pin connected to 6502's BE to go high-Z. The pull down resistor I have on the pin ensures that BE goes low but that's all I can do. The programmer will then start to upload code through the lines shared by address bus. I guess there's no way to get rid of the '541 buffer :-/

Long, long ago when I was initially exposed to digital electronics, I was taught that driving a signal to produce an effect opposite of the quiescent state is "asserting" it. In the case of BE, taking it low is what causes the 65C02 to relinquish the buses. So by following what I was taught, negating BE would be asserting it.

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