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

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.

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.

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

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

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

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

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

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

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

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

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

Dave

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

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

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

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