A simple 6502 computer (doesn't work though)

[Dr Jefyll]

LIV2 wrote:

Should the A14 input of the SRAM be connected to A14 instead of GND so that writes to IO space don't write to the lower half of the RAM?

I, too, did a double-take when I first saw the schematic on Garth's site. But the unusual connection is intentional, as Garth explains here.

[LIV2]

Except that with the RAM's A14 tied low instead of connected to A14 any writes between $4000-$7FFF write to $0000-3FFF don't they? I thought the idea was to have the writes go through to the ram's $4000-7FFF half where it can not be read back and thus won't interfere with I/O etc

[1024MAK]

I agree with LIV2:-

With the RAM A14 tied low, this reduces the available RAM by half. So the 32K byte chip is now effectively a 16K byte chip.

The RAM chip’s /CE pin is only driven active low when the PHI2 signal is high and A15 is low. This maps all access to 0x0000 to 0x7FFF, a 32K byte range.

With CPU A14 connected to the RAM /OE pin, this means that when the CPU address bus has A14 low, RAM addresses 0x0000 to 0x3FFF can be read by the CPU (a 16K byte range).

When the CPU address bus has A14 low or high, the CPU can write to the RAM, (addresses 0x0000 to 0x7FFF) but writes in the 0x4000 to 0x7FFF range will actually write to RAM addresses in the 0x0000 to 0x3FFF range.

If instead the RAM chips A14 line is connected to the CPU’s A14 line, then any writes to 0x4000 to 0x7FFF range will write to RAM addresses in the 0x4000 to 0x7FFF range and the 0x0000 to 0x3FFF area will not be overwritten. The CPU will be unable to read data back that is written in the 0x4000 to 0x7FFF range, but that does not matter if you only want 16K bytes of RAM.

Mark

[barrym95838]

(I'm not a hardware guy, but I always get a smile out of discussions involving Write-Only Memory, especially since my own biological memory seems to be slowly converting to the same, one addressable unit at a time)

[Oneironaut]

Did you know that a standard 7404 inverter also works as a 4 megabyte Serial Write Only RAM?
You send a clock to pin 1 and pulse data into pin 3.

Really, it is true.
Prove me wrong!

Brad

barrym95838 wrote:

(I'm not a hardware guy, but I always get a smile out of discussions involving Write-Only Memory, especially since my own biological memory seems to be slowly converting to the same, one addressable unit at a time)

[Dr Jefyll]

1024MAK wrote:

If instead the RAM chips A14 line is connected to the CPU’s A14 line, then any writes to 0x4000 to 0x7FFF range will write to RAM addresses in the 0x4000 to 0x7FFF range and the 0x0000 to 0x3FFF area will not be overwritten

Johan, I think LIV2 has identified the problem. (Good spot, btw!) Your schematic doesn't match Garth's where A14 is concerned.

PS- Brad, are you sure it's 4 megabyte?

[LIV2]

I'm not sure if it's the cause of this though as the only memory usage in the example code is the stack but I/O writes are effectively going to $0000 so there must be something else

I think barrym95838 was on to something when he suggested inlining the delay, there could be some other problem writing/reading ram that is screwing up the return address.

[jgroth]

barrym95838 wrote:

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:

Code: Select all

; 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
; Sun Jun 30 06:49:08 2019

;Line   ;Offset ;Hex            ;Source

        ;******  Command line definitions

        =false                  emulator=false

:1      ;******  Processing input file: via.asm

5       =$6000                          via1base = $6000
7       =24576                          via1rb   = via1base+0     ; write output register b, read input register b
8       =24578                          via1ddrb = via1base+2     ; data direction register b
10      .8000                   nmi:
11      .8000                   irq:
12      .8000                   coldstart:
13      .8000   a2 ff                   ldx #$ff
14      .8002   9a                      txs                     ;Initialise stack register
15      .8003   8e 02 60                stx via1ddrb        ; set all PB pins to be outputs
16      .8006                   loop:
17      .8006   9c 00 60                stz via1rb
18      .8009   a2 ff                   ldx #$ff
19      .800b                   loop2:
20      .800b   a0 ff                   ldy #$ff
21      .800d                   loop3:
22      .800d   88                      dey
23      .800e   d0 fd                   bne loop3
24      .8010   ca                      dex
25      .8011   d0 f8                   bne loop2           ; wait for a while
26      .8013   ce 00 60                dec via1rb
27      .8016   a2 ff                   ldx #$ff
28      .8018                   loop4:
29      .8018   a0 ff                   ldy #$ff
30      .801a                   loop5:
31      .801a   88                      dey
32      .801b   d0 fb                   bne loop4
33      .801d   ca                      dex
34      .801e   d0 fa                   bne loop5
35      .8020   80 e4                   bra loop
38      .8022                   delay:
51      >fffa   00 80               .word   nmi         ;NMI
52      >fffc   00 80               .word   coldstart   ;RESET
53      >fffe   00 80               .word   irq         ;IRQ

;******  End of listing

The VIA gets stuck on high this time.

[Chromatix]

It looks like you've mis-nested loop4 and loop5. That would probably influence the results by throwing the CPU into an infinite loop.

Another thing to try, once you've fixed that and tried it, is to delete the LDX/Y #$FF instructions entirely. The tiiming loops should work fine without them, since the index registers are not otherwise used.

[jgroth]

Chromatix wrote:

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 works:

Code: Select all

; 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:16:44 2019

;Line   ;Offset ;Hex            ;Source

        ;******  Command line definitions

        =false                  emulator=false

:1      ;******  Processing input file: via.asm

5       =$6000                          via1base = $6000
7       =24576                          via1rb   = via1base+0     ; write output register b, read input register b
8       =24578                          via1ddrb = via1base+2     ; data direction register b
10      .8000                   nmi:
11      .8000                   irq:
12      .8000                   coldstart:
13      .8000   a2 ff                   ldx #$ff
14      .8002   9a                      txs                     ;Initialise stack register
15      .8003   8e 02 60                stx via1ddrb        ; set all PB pins to be outputs
16      .8006                   loop:
18      .8006   a9 55                   lda #$55
19      .8008   8d 00 60                sta via1rb
20      .800b   a2 ff                   ldx #$ff
21      .800d                   loop2:
22      .800d   a0 ff                   ldy #$ff
23      .800f                   loop3:
24      .800f   88                      dey
25      .8010   d0 fd                   bne loop3
26      .8012   ca                      dex
27      .8013   d0 f8                   bne loop2           ; wait for a while
29      .8015   a9 aa                   lda #$aa
30      .8017   8d 00 60                sta via1rb
31      .801a   a2 ff                   ldx #$ff
32      .801c                   loop4:
33      .801c   a0 ff                   ldy #$ff
34      .801e                   loop5:
35      .801e   88                      dey
36      .801f   d0 fd                   bne loop5
37      .8021   ca                      dex
38      .8022   d0 f8                   bne loop4
39      .8024   80 e0                   bra loop
42      .8026                   delay:
55      >fffa   00 80               .word   nmi         ;NMI
56      >fffc   00 80               .word   coldstart   ;RESET
57      >fffe   00 80               .word   irq         ;IRQ

;******  End of listing

Chromatix wrote:

Another thing to try, once you've fixed that and tried it, is to delete the LDX/Y #$FF instructions entirely. The tiiming loops should work fine without them, since the index registers are not otherwise used.

Same program without LDX/Y #$FF in the delay loops.

Code: Select all

; 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:21:25 2019

;Line   ;Offset ;Hex            ;Source

        ;******  Command line definitions

        =false                  emulator=false

:1      ;******  Processing input file: via.asm

5       =$6000                          via1base = $6000
7       =24576                          via1rb   = via1base+0     ; write output register b, read input register b
8       =24578                          via1ddrb = via1base+2     ; data direction register b
10      .8000                   nmi:
11      .8000                   irq:
12      .8000                   coldstart:
13      .8000   a0 ff                   ldy #$ff
14      .8002   a2 ff                   ldx #$ff
15      .8004   9a                      txs                     ;Initialise stack register
16      .8005   8e 02 60                stx via1ddrb        ; set all PB pins to be outputs
17      .8008                   loop:
19      .8008   a9 55                   lda #$55
20      .800a   8d 00 60                sta via1rb
21      .800d                   loop2:
22      .800d                   loop3:
23      .800d   88                      dey
24      .800e   d0 fd                   bne loop3
25      .8010   ca                      dex
26      .8011   d0 fa                   bne loop2           ; wait for a while
28      .8013   a9 aa                   lda #$aa
29      .8015   8d 00 60                sta via1rb
30      .8018                   loop4:
31      .8018                   loop5:
32      .8018   88                      dey
33      .8019   d0 fd                   bne loop5
34      .801b   ca                      dex
35      .801c   d0 fa                   bne loop4
36      .801e   80 e8                   bra loop
39      .8020                   delay:
52      >fffa   00 80               .word   nmi         ;NMI
53      >fffc   00 80               .word   coldstart   ;RESET
54      >fffe   00 80               .word   irq         ;IRQ

;******  End of listing

and it still works
So next thing to try is to put the delay loop in a subroutine to check if the RAM works as it should.

[jgroth]

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

Code: Select all

; 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

        ;******  Command line definitions

        =false                  emulator=false

:1      ;******  Processing input file: via.asm

5       =$6000                          via1base = $6000
7       =24576                          via1rb   = via1base+0     ; write output register b, read input register b
8       =24578                          via1ddrb = via1base+2     ; data direction register b
10      .8000                   nmi:
11      .8000                   irq:
12      .8000                   coldstart:
14      .8000   a2 ff                   ldx #$ff
15      .8002   9a                      txs                     ;Initialise stack register
16      .8003   8e 02 60                stx via1ddrb        ; set all PB pins to be outputs
17      .8006                   loop:
19      .8006   a9 55                   lda #$55
20      .8008   8d 00 60                sta via1rb
28      .800b   20 18 80                jsr delay
29      .800e   a9 aa                   lda #$aa
30      .8010   8d 00 60                sta via1rb
37      .8013   20 18 80                jsr delay
38      .8016   80 ee                   bra loop
41      .8018                   delay:
42      .8018   a2 ff                   ldx #$ff
43      .801a                   loop2:
44      .801a   a0 ff                   ldy #$ff
45      .801c                   loop3:
46      .801c   88                      dey
47      .801d   d0 fd                   bne loop3
48      .801f   ca                      dex
49      .8020   d0 f8                   bne loop2
50      .8022   60                      rts
54      >fffa   00 80               .word   nmi         ;NMI
55      >fffc   00 80               .word   coldstart   ;RESET
56      >fffe   00 80               .word   irq         ;IRQ

;******  End of listing

BTW, the result is the same whether A14 is grounded or connected to CPU's A14, VIA's port gets stuck.

[Chromatix]

Maybe write a simple RAM testing routine that doesn't use the stack. Walking bit inversions, self-addressing, that sort of thing.

[barrym95838]

Do you have a spare SRAM you can swap in? Or maybe try initializing your stack pointer to something like #$EE instead of #$FF?

[Chromatix]

Clearly the correct operation of zero-page and the stack page is the most critical. Without them, a significant proportion of 6502 opcodes become useless. But I think we can now assume that the VIA and ROM are working correctly.

So here's an attempt to verify pages 0-3 (the first kilobyte) without relying on correct RAM functionality, and using the VIA for status output:

Code: Select all

coldstart:
 LDX #$FF
 STX via1ddrb
 STZ via1rb ; output $00 -> filling zeroes
 INX
fillzero:
 STZ $00,X
 STZ $100,X
 STZ $200,X
 STZ $300,X
 INX
 BNE fillzero
 INC via1rb ; output $01 -> checking zeroes
checkzero:
 LDA $00,X
 BNE error0
 LDA $100,X
 BNE error1
 LDA $200,X
 BNE error2
 LDA $300,X
 BNE error3
 INX
 BNE checkzero
 INC via1rb ; output $02 -> filling ones
 DEC A
fillones:
 STA $00,X
 STA $100,X
 STA $200,X
 STA $300,X
 INX
 BNE fillones
 INC via1rb ; output $03 -> checking ones
checkones:
 CMP $00,X
 BNE error0
 CMP $100,X
 BNE error1
 CMP $200,X
 BNE error2
 CMP $300,X
 BNE error3
 INX
 BNE checkones
 INC via1rb ; output $04 -> filling self-address
 BRA filladdr

; Error routines in the middle so they can be reached from both ends
error0:
 LDY #$00
 TXS
 BRA errorloop
error1:
 LDY #$10
 TXS
 BRA errorloop
error2:
 LDY #$20
 TXS
 BRA errorloop
error3:
 LDY #$30
 TXS
errorloop:  ; rapidly cycle through indication of test stage, error page (moved to high nybble), error index within page
 INX
 BNE errorloop
 INC A
 BNE errorloop
 TSX
 TXA
 LDX via1rb
 STY via1rb
 TAY
 TXS
 LDA #0
 BRA errorloop

filladdr:
 TXA
 STA $00,X
 STA $100,X
 STA $200,X
 STA $300,X
 INX
 BNE filladdr
 INC via1rb ; output $05 -> checking self-address
checkaddr:
 TXA
 CMP $00,X
 BNE error0
 CMP $100,X
 BNE error1
 CMP $200,X
 BNE error2
 CMP $300,X
 BNE error3
 INX
 BNE checkaddr
 INC via1rb ; output $06 -> filling self-page
fillpage:
 STZ $00,X
 LDA #1
 STA $100,X
 LDA #2
 STA $200,X
 LDA #3
 STA $300,X
 INX
 BNE fillpage
 INC via1rb ; output $07 -> checking self-page
checkpage:
 LDA $00,X
 BNE error0
 INC A
 CMP $100,X
 BNE error1
 INC A
 CMP $200,X
 BNE error2
 INC A
 CMP $300,X
 BNE error3
 INX
 BNE checkpage
 INC via1rb ; output $08 -> test complete
done:
 WAI
 BRA done

I've edited it to ensure that none of the branches should be out of range, and to make the output sequence slow enough to read.

[jgroth]

barrym95838 wrote:

Do you have a spare SRAM you can swap in? Or maybe try initializing your stack pointer to something like #$EE instead of #$FF?

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