I used an XGecu PRO TL866II plus, that is the original programmer and not a clone.

So I finally found out what's wrong with the circuit. The quality of that breadboard was so bad that the VIA didn't get high enough voltage to register a one although I did measure it and it looked OK. When I changed the breadboards to Global Specialities ones everything just started to work. :P So ...

Your code is on my list to try out.

Tried the RAM in the ref-board computer and it works just fine there.

This code does not work so something how I connected the RAM is wrong.

; 64tass Turbo Assembler Macro V1.52.1237? listing file
; 64tass -Demulator=false -o via.bin --nostart --no-monitor --line-numbers --tab-size=1 --list=via.lst via.asm
; Tue Jul 2 19:31:12 2019

;Line ;Offset ;Hex ;Source ...

It looks like you've mis-nested loop4 and loop5. That would probably influence the results by throwing the CPU into an infinite loop.
Well spotted Chromatix. I was really tired when I wrote that snippet. This has now been corrected and guess what the probe blinks as it should.
So this program ...

This might be a silly notion, but are you certain that you're always getting a clean rts from your jsr delay? Would it be helpful to try a version that in-lines the delay?
The inline version is below:


; 64tass Turbo Assembler Macro V1.52.1237? listing file
; 64tass -Demulator=false -o via.bin ...

So I tried this code:

coldstart: .block
ldx #$ff
txs ;Initialise stack register
stx via1ddrb ; set all PB pins to be outputs
loop:
stz via1rb
jsr delay ; wait for a while
dec via1rb
jsr delay
bra loop
.bend

delay: .proc
ldx #$ff
loop2:
ldy #$ff
loop3:
dey
bne loop3
dex
bne loop2 ...

All the code (besides the vectors) is within the first 32 bytes of the ROM for the decrement test, but not for the inversion test. Does inserting ten NOPs between the 'BRA loop' and 'delay:' - to move the latter subroutine to a consistent position - make the decrement test fail? These are bytes ...

loop: dec via1rb
jsr delay
bra loop

works fine ie the probe goes from high to low to high. But what doesn't work is code like this:

loop: lda #$00
sta via1rb
jsr delay
lda #$ff
sta via1rb
jsr delay
bra loop


That's curious! Is that the only difference between the two? They won't ...

Well, 6500 (and 6800) series processors use the Phi2-low time to prepare for a data transfer and the Phi2-high time to actually perform the transfer. Preparing for the transfer entails the propagation of a new address onto the address bus... and it also entails a potential change of "ownership" of ...

I only got access to CMOS cpus from WDC I'm afraid so that is what both boards are using.
No worries! -- that's still useful information. One board works and the other doesn't, despite the fact they both have CMOS cpu's. That's a strong indication that (as LIV2 suggested) the C02's version of the ...

I understand how spurious reads can cause a problem with devices like the SCC28L92 which has an indexed register that increments on read, but why would it cause problems writing to the 65C22? :!: Hmmm. It's a good question, LIV2. (And I admit my suggestion about the 'C02 bug was fairly hasty. Until ...

One step to try might be to pare it down further, if you're comfortable with that. You have a lot there that's not necessary. For example, the data sheet says, "The reset input clears all internal registers to logic 0 (except T1 and T2 latches and counters and the shift register). This places all ...

The dream is to get this computer to work.
DSC_0363.JPG

Looks interesting - what is it?

-Gordon
It's a 65C02 based computer with 32k ROM and RAM, an SC28L92 DUART, a Lattice MACH4A5 CPLD and some surrounding logic. A very experimental IDE interface is also there. Half of the implementation of ...