Streamlining code with JSR

Programming the 6502 microprocessor and its relatives in assembly and other languages.
GaryMac
Posts: 7
Joined: 15 Aug 2024

Re: Streamlining code with JSR

Post by GaryMac »

Hi Dave,

Consider my chops busted!!! I did read that ages ago, thought "Bugger, that's not how I've done it. I must fix that." and then clearly got sidetracked and didn't!! Thanks for the reminder and getting me back on track.

Gary
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

Re: Streamlining code with JSR

Post by barnacle »

That doesn't help at all :mrgreen:

After forty years, I still have to check the data sheets to remember that the processor wants the bus when phase 2 (or phase 0, or phi0, or whatever you want to call it!) is high.

Neil
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Streamlining code with JSR

Post by BigDumbDinosaur »

barnacle wrote:
That doesn't help at all :mrgreen:

After forty years, I still have to check the data sheets to remember that the processor wants the bus when phase 2 (or phase 0, or phi0, or whatever you want to call it!) is high.

I just refer to the clock as Ø2 and append “low” or “high” as necessary.  Conversation between the MPU and the rest of the world always occurs during Ø2 high.  The 65C816 complicates that rule, in that the data bus emits the A16-A23 address component during Ø2 low.  So you can’t make assumptions about when the data bus is idle.  Fortunately, the 816 will tell you by driving both VDA and VPA low when you can take over the buses.

Unlike the 65C02, the 816 doesn’t have extra clock signals to confuse the novice.  However, that didn’t stop WDC from muddying the issue with inconsistent terminology in the 816’s data sheet.  :twisted:
Last edited by BigDumbDinosaur on Tue Sep 17, 2024 8:19 pm, edited 1 time in total.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Streamlining code with JSR

Post by BigDumbDinosaur »

GaryMac wrote:
Hi Dave,

Consider my chops busted!!! I did read that ages ago, thought "Bugger, that's not how I've done it. I must fix that." and then clearly got sidetracked and didn't!! Thanks for the reminder and getting me back on track.

Gary

Dave aka Hoglet wasn’t who wrote that.  :D

Misunderstandings about the clock business are partially WDC’s fault.  The data sheet doesn’t really make it crystal-clear under what circumstances the PHIxO outputs should be used.  The general rule is they should be treated as no-connects and a “can” oscillator should be the sole Ø2 clock source in the system.  You’d connect the PHI2 inputs of any 65xx peripheral devices to the can oscillator, same as with the MPU.  That would be the computer equivalent of everyone singing from the same hymnal.  :D

The caveat about not using the PHIxO outputs to clock peripherals in new designs has to do with the much higher speeds possible with the WDC 65C02.  The propagation delay from Ø0 in to Ø1 out and Ø2 out is a fixed value that is almost entirely influenced by the MPU’s operating voltage and temperature.  At low clock rates, that prop delay is a small percentage of the clock period, so is unimportant in most applications.  As the clock rate is ramped up, the prop delay become more significant relative to the clock period, which tends to cause clocked peripherals to see changes to the clock phase later than seen by the MPU.  Particularly problematic is that RWB during a write operation will go high earlier than expected by peripherals, possibly violating write hold times.  By clocking peripherals with the same clock driving the MPU, everything stays in sync.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Post Reply