6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 8:42 pm

All times are UTC




Post new topic Reply to topic  [ 297 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15, 16, 17 ... 20  Next
Author Message
 Post subject:
PostPosted: Fri Aug 27, 2010 5:15 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
(cross-thread from the "oscilloscope as a Logic Analyzer" topic:)
ElEctric_EyE wrote:
I tried to jump ahead and do the EEPROM to SRAM copy @1.25MHz and run the system @5MHz. SYNC went dead after the SRAM was enabled and the CPU reset meaning either: 1) I am not giving the software enough time to copy $C000-$FFFF from EEPROM to SRAM, (unlikely) or 2) There is a problem with the bank switching hardware controlling addresses to the SRAM. Since I am using zero page for indirect indexed to copy 16K, the bank hardware is constantly flipping from upper 16K, where the copy program resides, to the lower 16K where zero page is...

Before I do tackle this problem however, I think I should focus back onto initializing the display, which is just LDA/STA, running from the EEPROM @1.25MHz.

Garth I used to use a '374 as a test port as well for an initial test to make sure everything was wired correctly etc. on my first iteration of the PWA. I actually did think of trying to put it inside the FPGA, but never got around to it... Testing SYNC seems to be an even more "bare bones" approach to initial startup, because you're testing right at the CPU itself.


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

Quote:
I think I should focus back onto initializing the display, which is just LDA/STA, running from the EEPROM @1.25MHz.
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Aug 27, 2010 4:17 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
ElEctric_EyE wrote:
These links may help. At the very least they'll give you clues how to program FPGA's without ISE software.


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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Aug 27, 2010 11:45 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Dr Jefyll wrote:
...Is the schematic on page 11 of this thread still current with respect to the Reset logic and clock mux?-- Jeff


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.

Image

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

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 12:39 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
Dr Jefyll wrote:
(cross-thread from the "oscilloscope as a Logic Analyzer" topic:)
ElEctric_EyE wrote:
I tried to jump ahead and do the EEPROM to SRAM copy @1.25MHz and run the system @5MHz. SYNC went dead after the SRAM was enabled and the CPU reset...
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).

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.

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 3:36 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Talking about Clock issues in my last post reminded me of something I noticed in the logic diagram. Your new version shows it too:

Code:
Broken external image link
http://www.laughtonelectronics.com/6502PWA.jpg

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 5:02 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
Dr Jefyll wrote:
Talking about Clock issues in my last post reminded me of something I noticed in the logic diagram...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.

Good call on that one!

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 5:21 am 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 5:54 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
kc5tja wrote:
the 65816 data sheet [...] recommends connecting logic to RDY through an external resistor

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.
BigDumbDinosaur wrote:
WAI will halt the MPU only until an interrupt is received. [...] STP, on the other hand, means stop, and only a reset can clear it.

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! :roll:


Last edited by Dr Jefyll on Sat Aug 28, 2010 4:51 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 1:55 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 10:06 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
Dr Jefyll wrote:
...it's possible for the mux to change its selection partway through a cycle -- changing horses in midstream, so to speak...


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!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Last edited by ElEctric_EyE on Sun Aug 29, 2010 12:33 am, edited 6 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sat Aug 28, 2010 10:35 pm 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1042
Location: near Heidelberg, Germany
ElEctric_EyE wrote:
I recommend focusing on the truth table below the schematic, and it wound up being a '163 counter, not a '161.


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é


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Aug 29, 2010 12:47 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
I did choose the '163 back then.

Dr Jefyll wrote:
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. -- Jeff


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)

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Aug 30, 2010 10:06 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8481
Location: Midwestern USA
kc5tja wrote:
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

At least it wasn't HCF. :)

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Aug 31, 2010 2:04 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
BigDumbDinosaur wrote:
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 :) ).

ElEctric_EyE wrote:
The display does initialize! running from EEPROM (SRAM/OE disabled)
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)

ElEctric_EyE wrote:
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.
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Aug 31, 2010 2:16 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
kc5tja wrote:
...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.


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.

Dr Jefyll wrote:
...Afterthough: instead of the loop, you could execute STP! It suits this situation to a tee...


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

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 297 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15, 16, 17 ... 20  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 34 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: