Streamlining code with JSR

[GaryMac]

Hi All,

I'd like to tap the collective brains trust of the forum to see if we can sort out an odd problem I'm having.

I have built a small 65C02 based system, 32k RAM, 32k FLASH ROM, I/O at $8000, serial chip at $8500.

The code in the attached file testHex4-Working.S print the hex numbers from $0000 to $FFFF to the serial port. This works fine.

The other file, testHex4-NotWorking.S has had the first of the delay loops replaced with a JSR call to the same delay routine used in the working code but the high byte is printed as $08 for all values as shown below.

If someone has a moment, could you cast an eye over this and see where I'm going wrong before I go completely cross-eyed?

Thanks,
Gary

Code: Select all

0800
0801
0802
0803
0804
0805
0806
0807
0808
0809
080A
080B
080C
080D
080E
080F
0810
0811

[leepivonka]

So far I don't see a problem like that.

Is the hi byte stuck at $08, or does it just start counting at $08?

I would look at the map file from the linker next. Are all the segments appropriately placed & not overlapping?

delay_6551 delays a little over 500 cycles. Unless your clock speed is 500KHz, the comments are misleading.

[rudla.kudla]

I see, you do not call any jsr, even if it looks like you are prepared to do so. Does any call to JSR damage to output?
I suppose you do not have any debugging options on your machne, but maybe try to check some invariants in your code.

Like:

PLA
bmi BAD_VALUE
STA ACIA_DATA ; put character to Port

Where BAD_VALUE would either print something or just end, you will see no output.

[GaryMac]

High byte is stuck at $08.

The delay comments are not correct ATM. Lots of fiddling with code and not updating every time!! Once I sort out the issues I'll fix up the comments to be correct.

I've had a look through the MAP file. All seems to be in order. I've attached it for completeness.

Thanks,
Gary

leepivonka wrote:

So far I don't see a problem like that.

Is the hi byte stuck at $08, or does it just start counting at $08?

I would look at the map file from the linker next. Are all the segments appropriately placed & not overlapping?

delay_6551 delays a little over 500 cycles. Unless your clock speed is 500KHz, the comments are misleading.

[GaryMac]

The JSR is called twice at the end to do the CR/LF and they seem to be fine. It's the other ones that seem to kill it.

Debugging options are limited. I've run the code through a simulator and it seems to be doing what it's supposed to.

Thanks,
Gary

rudla.kudla wrote:

I see, you do not call any jsr, even if it looks like you are prepared to do so. Does any call to JSR damage to output?
I suppose you do not have any debugging options on your machne, but maybe try to check some invariants in your code.

Like:

PLA
bmi BAD_VALUE
STA ACIA_DATA ; put character to Port

Where BAD_VALUE would either print something or just end, you will see no output.

[hoglet]

GaryMac wrote:

Hi All,
I have built a small 65C02 based system, 32k RAM, 32k FLASH ROM, I/O at $8000, serial chip at $8500.

There a possibility this is a hardware issue, causing unreliablility when using the stack. These sort of faults can be highly specific and data dependent, so could explain why some JSRs work and others don't.

Do you have a schematic of what you have built, and a few photos of the construction?

Dave

[GaryMac]

Hi Dave,

Thanks for your thoughts. Attached is the schematic of the memory section and a couple of pics of the system as it stands.

The RAM chip tested OK. I had a similar thought so I made up an Arduino test rig to run through the RAM chip and check that values were stored correctly. All OK.

The two counter values stored in ZP seems to work OK in the non JSR version so it seems to be able to access the RAM OK.

Thanks,
Gary

hoglet wrote:

There a possibility this is a hardware issue, causing unreliablility when using the stack. These sort of faults can be highly specific and data dependent, so could explain why some JSRs work and others don't.

Do you have a schematic of what you have built, and a few photos of the construction?

Dave

[hoglet]

GaryMac wrote:

Attached is the schematic of the memory section and a couple of pics of the system as it stands.

Particularly with fast RAMs (like the 25ns 7C198 you are using), the timing of the trailing edge of the WE pulse is critical. If this edge is late (wrt the address changing), then you violate the RAM's 0ns address hold time and end up with unreliable writes.

The W65C02 address is only guaranteed stable for 10ns after the Phi2 edge, so you don't need to delay the end of the write cycle by much to be in trouble.

Things that might delay the trailing edge of RAM WE signal in your system include:
- Deriving the system clock from Phi2O rather than Phi2 (this is an easy mistake to make, and can add 5ns-10ns delay)
- Buffering the system clock
- Additional capacitance on the system clock (e.g. driving several loads on a bus)
- Using a slow NAND gate to generate RAM WE (HC/HCT devices will add 10ns-15ns)

What processor are you using? A W65C02S?

It would be helpful to see a schematic of the CPU board, to understand whether the address bus is buffered in any way, and how the clock named Phi2 is derived.

Dave

[GaryMac]

Hi Dave,
CPU schematic attached. Peripheral Phi2 is from the Phi2O pin39. Should it just be linked to PHI2 on pin37 and 39 left out of the socket?

I'm using HCT logic chips across the board (the schematic is showing 74HC00, it's actually a 74HCT00. Must correct that).

Gary

hoglet wrote:

Particularly with fast RAMs (like the 25ns 7C198 you are using), the timing of the trailing edge of the WE pulse is critical. If this edge is late (wrt the address changing), then you violate the RAM's 0ns address hold time and end up with unreliable writes.

The W65C02 address is only guaranteed stable for 10ns after the Phi2 edge, so you don't need to delay the end of the write cycle by much to be in trouble.

Things that might delay the trailing edge of RAM WE signal in your system include:
- Deriving the system clock from Phi2O rather than Phi2 (this is an easy mistake to make, and can add 5ns-10ns delay)
- Buffering the system clock
- Additional capacitance on the system clock (e.g. driving several loads on a bus)
- Using a slow NAND gate to generate RAM WE (HC/HCT devices will add 10ns-15ns)

What processor are you using? A W65C02S?

It would be helpful to see a schematic of the CPU board, to understand whether the address bus is buffered in any way, and how the clock named Phi2 is derived.

Dave

[BigDumbDinosaur]

GaryMac wrote:

CPU schematic attached...

I was going to take a look at your schematic, but can’t read it due to the color.  Can you post a monochrome version?

BTW, note what Dave (Hoglet) said about use of 74HC logic in conjunction with fast RAM.  You can get into a timing crunch due to the /RD and /WD signals trailing the fall of the Ø2 clock by too much, with the possibility of a wild write occurring as the address bus starts changing for the next cycle.  Probably better to use 74AHC logic, which is as fast as 74AC logic—more that 2× the speed of 74HC, but with the latter’s less-aggressive edges.

[hoglet]

GaryMac wrote:

Peripheral Phi2 is from the Phi2O pin39. Should it just be linked to PHI2 on pin37 and 39 left out of the socket?

Assuming you are using a W65C02 processor, then yes, it's better to derive the system clock from pin 37 and ignore pin 39.

GaryMac wrote:

I'm using HCT logic chips across the board (the schematic is showing 74HC00, it's actually a 74HCT00. Must correct that).

If the above doesn't resolve the issue, then it I would switch the 74HCT00 to a faster logic family.

Dave

[GaryMac]

Hi Dave,

PHI2 was the culprit. I've linked the peripheral Phi2 to the CPU Phi2 In and all is working now.

Many thanks to you and also to the others who put up suggestions.

Back to coding now.

Gary

hoglet wrote:

Assuming you are using a W65C02 processor, then yes, it's better to derive the system clock from pin 37 and ignore pin 39.

Dave

[BigDumbDinosaur]

GaryMac wrote:

PHI2 was the culprit. I've linked the peripheral Phi2 to the CPU Phi2 In and all is working now.

hoglet wrote:

Assuming you are using a W65C02 processor, then yes, it's better to derive the system clock from pin 37 and ignore pin 39.

It’s important to read data sheets in their entirety when integrating a device into a new design.  At two places in the 65C02 data sheet, WDC advises to not use the PHI1O and PHI2O outputs in new applications.  From section 3.8 on page 10...

• An external oscillator is recommended for driving PHI2 and used for the main system clock.  All production test timing is based on PHI2.

...and on page 26 right below the timing diagram...

1. Timing Notes:
2. Timing measurement points are 50% VDD.
3. PHI1O and PHI2O clock delay from PHI2 is no longer specified or tested and WDC recommends using an oscillator for system time base and PHI2 processor input clock.  (Emphasis added.)

As Garth notes in his 6502 primer on clock generation, the PHIxO outputs are functional.  However, as they lag the PHI2 input to some unspecified degree, driving peripheral hardware, e.g., a 65C22, from PHI2O will effectively result in a system with two partially-out-of-phase clock domains.

The main reason the PHIxO outputs persist in the modern form of the 65C02 is to permit the MPU’s use in an older machine in which those clock signals were primary to the entire system.  Such an arrangement was common in 1970s and 1980s applications where a crystal oscillator circuit like that depicted on the above-linked page was used to generate Ø2.  Such an oscillator’s output was insufficient to drive anything other than the MPU.

Garth also makes mention of the fact that the WDC parts are somewhat fussy about clock quality.  The signal amplitude should swing rail-to-rail, the rise/fall time should not exceed five nanoseconds, and, ideally, the signal should be symmetric.  Not all clock oscillators are capable of meeting those requirements, in which case, use of a 74AC74 flip-flop (or similar) can generate a strong and symmetric clock.  Some asymmetry is not an issue at low speeds (you can get away with murder at 1 MHz ), but may result in obdurate timing violations as the Ø2 frequency approaches the MPU’s limits.

I’m not trying to “bust your chops” here...only highlighting the importance of reading and fully understanding what the data sheet is trying to tell you.  Also, note that in the case of modern 65xx hardware, WDC is the only authoritative place for data sheets.  Be wary of downloading WDC data sheets from other locations, as they frequently are out of date.

That said, attached is the most-current 65C02 data sheet. 

65c02.pdf

65C02 Data Sheet (Feb. 2024)

(382.89 KiB) Downloaded 147 times

Also, I attached the 65C02 data sheet from 1990, which will highlight how much the quality of WDC’s data sheets has improved. 

65c02_1990.pdf

65C02 Data Sheet (Feb. 1990)

(2.32 MiB) Downloaded 154 times

[barnacle]

I still feel there is some scope for confusion caused by WDC's renaming of the clock signals.

In days of old, the input clock was PH0, with inverted and uninverted outputs on PH1 and PH2.

Now we have PHI2 as the input and PHIO1 and PHIO2 as the outputs.

Neil

[BigDumbDinosaur]

barnacle wrote:

I still feel there is some scope for confusion caused by WDC's renaming of the clock signals.

In days of old, the input clock was PH0, with inverted and uninverted outputs on PH1 and PH2.

Now we have PHI2 as the input and PHIO1 and PHIO2 as the outputs.

Adding to the confusion, Rockwell refers to these signals as Ø0 (IN), Ø1 (OUT) and Ø2 (OUT) in their data sheet.  In the narratives, they further confuse things by referring to the high phase of the clock as Ø2 and the low phase as Ø1.

65c02_1984_rockwell.pdf

Rockwell 65C02 Data Sheet (Oct 1984)

(13.12 MiB) Downloaded 152 times