6502.org

(cross-thread from the "oscilloscope as a Logic Analyzer" topic:)
SYNC went dead after the SRAM was enabled? If there's no activity on SYNC then the cpu simply isn't running. It may have somehow executed a WAI or STP (Wait or Stop -- new WDC instructions). That wasn't your intention but if the system has crashed for some reason, it'll end up executing garbage (data, inappropriate code or the contents of uninitialized memory). Running amok that way it may have swallowed a WAI or STP op-code, and that would squelch the signal on SYNC.

Another possibility is that the cpu has lost its clock signal or some other basic requirement. Hence no SYNC. Is the Phase2 signal OK? Isn't your clock mux associated with the same reset logic that enables the SRAM? Smells like a clue to me... Trouble with the mux? I could be wrong...
Probably a good idea. There's no need to go beyond 1.25 MHz at present. And the EEPROM to SRAM copy is kinduva handful -- lots that could go wrong.

Is the schematic on page 11 of this thread still current with respect to the Reset logic and clock mux?

-- Jeff

Unfortunately, no -- the information contained in those documents are completely insufficient to write a synthesis tool of my own. The data provided covers only barely how to make a programmer for the chip (I still consider it insufficient; I would never trust myself to make a programmer with the datasheets alone).

The basic idea is still there using a 4-bit counter to manipulate the CPU/Reset, EEPROM/OE, and SRAM/OE. The counter is running 80MHz/65536/4096 @.29Hz. I've had to mod the original to be more inline with FPGA rules. This is from the latest schematic.



4 seconds plenty of time to copy 16K @1.25 MHz yes?

WAI will halt the MPU only until an interrupt is received. I don't recall from following this thread if he has something in the system that generates an IRQ.

STP, on the other hand, means stop, and only a reset can clear it.

Talking about Clock issues in my last post reminded me of something I noticed in the logic diagram. Your new version shows it too:
At issue is the fact your mux select (the signal I call INITIALIZE/RUN) may not be synchronous to the 5MHz and 1.25MHz signals being selected.
In other words, it's possible for the mux to change its selection partway through a cycle -- changing horses in midstream, so to speak.

If luck is with you, the 5MHz and 1.25MHz signals will be in the same state at the instant of changeover, and no glitch results. But otherwise the transition on the mux select will result in a spurious transition on the mux output -- your cpu clock! Although it's a one-time event, the effects of this irregularity on the cpu and on program execution are unpredictable -- and presumably unfavorable. (It might explain what you said: "SYNC went dead after the SRAM was enabled" ie: after INITIALIZE/RUN changed state.)

The alternative I've shown acts as a programmable divide-by-N to generate your 1.25 and 5MHz clocks. As you see, the counter can reload either of two hardwired values, thus determining the output frequency. (I haven't worked out the reload values; they'll depend on FastCkIn.) The key point here is that, no matter when INITIALIZE/RUN changes state, there will be no effect until the next reload of the counter -- ie, until completion of the current divide-by-N cycle.

The JK flip-flop provides a 50:50 duty cycle but, with some fussing, could perhaps be judiciously eliminated.

BTW, note that, even if INITIALIZE/RUN is synchronized to the 1.25 and 5MHz clocks, it'll be difficult to manage propagation delays and get the original circuit to execute a clean changeover.

Finally, dual clock frequencies aren't the only way to allow extra access time for the EEPROM. An alternative would be to make use of the cpu RDY input.

-- Jeff
Afterthought: I just noticed that INITIALIZE/RUN should maybe pass through a D flip-flop (clocked at FastCkIn) before it reaches SEL. A discrete 74xx version of the circuit definitely needs this; inside the PLD, however, the '157 mux probably disappears, optimized away...

Good call on that one!

I haven't been following this thread too closely, but after skimming it, check also the RDY signal too. If it's held low, that also will halt the CPU.

In fact, the WAI instruction works by pulling RDY low via an internal open-drain transistor through a resistor. IRQ, ABORT, and NMI simply releases the flip-flop driving that transistor. This is why the 65816 data sheet (at least the one I have) recommends connecting logic to RDY through an external resistor, to prevent the possibility of an accidental short.

So, even if RDY is unused, it's not alright simply to tie it high. OK, then! Good to know. RDY is bi-directional.
Edit: Re: the 'C02, WDC's W65C02S also should use a series resistor on RDY, whereas the Rockwell chip (and others?) don't require it -- but it'll do no harm. It's amusing (to me, at least) that, back when the 'C02 was introduced, much was made of the fact that they'd corrected the NMOS chip's vulnerability to certain opcodes that'd cause it to hang: to halt execution.

Now halt (ie STP) is back -- but it's a feature!

Haha, yeah. Well, there is value in the opcode in terms of controlling power dissipation.

Of course, for historical purposes, I think they should have called it JAM. ;D

My fault again. I had started a new thread about speeding up the 6502 ~1/3rd? way through this PWA thread, and this very topic came up...

I regretfully deviated from this PWA thread and created a separate one. If you're interested enough in what I was trying to do and want a quick sample, focus on the truth table below the schematic, (the counter wound up being a '163). ( viewtopic.php?t=1503&postdays=0&postorder=asc&start=24 )

This "speeding up" thread explains in more detail what I intended to accomplish. I have been successful with it because I never had the intention to switch the phase 2 during a copy execution cycle, only AFTER the $C000-$FFFF copy was completed and a JMP $xxxx was looping to itself. Then Phase 2 is sped up, cpu is reset, and SRAM /OE enabled.

It was my first iteration using discrete TTL, and I was anxious to keep this PWA thread on it's way to a quick, successful conclusion. This was before my introduction to CPLD's and FPGA's and much has changed...

EDIT: I apologize for all the edits, long day @work... I've been given some valuable troubleshooting techniques to evaluate/troubleshoot. I will update on my days off!

Not sure right now which is which, just make sure it's a synchronous counter (as opposed to an asynchronous one). May save quite some hassle later.

André

I did choose the '163 back then.
This is what I am thinking also as the most likely possibility, due to either EEPROM/SRAM copy issues or address/timing issues.

Thanks for giving me new tools to attack this problem from different angles!

I just need abit more time to implement...

The display does initialize! running from EEPROM (SRAM/OE disabled)

At least it wasn't HCF.

"Halt and Catch Fire" would actually be a fairly literal description... not of STP, but of WAI, executed in a system that has no series resistor on the RDY line (as explained above by kc5tja). The result of WAI would be a cessation of program activity (ie: Halt), and the internal pulldown transistor connecting to RDY would short circuit whatever drives it (ie: Catch Fire -- well, at least overheat ).
Excellent! The next step is to find out why it won't work from SRAM. Is the display a Read-Write device, or Write-only? Might it be that SRAM and the display sometimes try to drive the data bus simultaneously? (bus contention)
OK, that's a partial answer, but still somewhat of an untidy situation, if you don't mind my saying. The memory copy routine may run properly, but there's no guarantee that the loop jumping to itself will. (The loop could easily fail as a result of a Phase 2 glitch when the speed shifts gears.)

Loss of the loop is unimportant in itself, but if the cpu isn't running the loop, the question arises, what is it doing? Running amok and executing garbage is what! In that condition it could very well execute write opcodes that corrupt the SRAM contents established a moment before! Admittedly this isn't a strong probability, but the risk is real (and corrupted-memory problems can be fiendishly difficult to deal with). It seems to me to be a loose end worth tying up.

-- Jeff

Afterthough: instead of the loop, you could execute STP! It suits this situation to a tee.
Another: since running from EEPROM is OK, perhaps SRAM doesn't contain an accurate copy. Ie, corruption has occured, or (more likely) for some reason the copy operation was no good in the first place. Or for some reason you can't read back what's there.

I wasn't aware of that. But, I did take the advice of Nightmaretony, and use pullup/down resistors for any line I have to keep a logic "1" or "0". I have the /NMI, /IRQ, RDY, SOB, & BE all tied to 3.3V through a 5.1K resistor.
I understand what you're saying now about untimely terminating a piece of running software. The cpu may see a piece of data that was meant to be data but see it as an incorrect/unknown opcode?...

The Kowalski assembler doesn't recognize STP. Would BRK work too?...

1 more formerly unknown variable has been taken care of.
Looking over the data sheet for the 2Mx8 SRAM, I read it needs 1ms after power up before it can be properly accessed. So before the loop software, I overcompensated for now, and added ~26ms software loop "delay".