Blue April - RC6502 Project Space

[GARTHWILSON]

Paganini wrote:

However, it seems like what's described in the primer is that when two 'S' VIAs are wire-ored together, VIA0 will try to pull IRQ low, but VIA1 will keep it high, preventing the interrupt form being issued. IOW, I'd expect to see *NO* interrupts

No; they will fight each other, and the result will probably be something between a valid logic 1 and a valid logic 0, in no-man's land, the exact final voltage probably depending on which VIA's IRQ\ output is a little stronger than the other one. Results may be rather unpredictable.

[Paganini]

OK! I'll cut that wire before I try any other troubleshooting then. Thanks Garth, that was crazy speedy!

[Paganini]

Here's a weird one. I've continued making progress on my PS/2 keyboard circuit. It's working as expected, except that I'm getting random intermittent lockups. Also, from time to time, the computer appears to be executing code that it should not be - for example, executing a "Print Message" subroutine that I'm not calling, but that I left in the firmware for future debugging use. It also sometimes re-executes code that is only supposed to execute one time, for example, the variable initialization code at the start of my main routine. My guess is that the lock ups are also due to executing code that should not be executed, but those times just don't happen to have any side-effects that are visible on my LCD.

Through the course of my investigations I've determined that it only happens if interrupts are enabled and actually being issued. For testing I made a simple momentary button circuit. It goes into the CA1 line of VIA0. I've also narrowed it down to one subroutine - the one that reads from my LCD. If interrupts are enabled during this routine, I get intermittent lockups and random code execution. If I disable interrupts during this routine, the problems seem to be fixed. Is there anything in here that looks particularly interrupt unfriendly?

Code: Select all

LCD_R    = %00000100    ; LCD R/W signal mask
LCD_E    = %00001000    ; LCD Enable signal mask

LCD_read:
;   Assume LCD is not busy, returns next nibble in A register
    sei
    lda    #%00001110
    sta    VIA1_DDRA    ; Set VIA1 Port A bits 7..4 to input
    lda    #LCD_R
    sta    VIA1_PORTA    ; tell the LCD we want to read
    lda    #(LCD_R | LCD_E)
    sta    VIA1_PORTA    ; send enable pulse
    lda    VIA1_PORTA    ; read the data
    and    #%11110000    ; clear out junk on low order bits
    pha    ; save it here
    lda    #LCD_R
    sta    VIA1_PORTA    ; take enable low again
    lda    #%11111110    ; set VIA Port A bits 7..4 back to output
    sta    VIA1_DDRA
    pla    ; return the data
    cli
    rts

The LCD is operating in 4-bit mode, so I always call LCD_read twice in a row. Note that VIA1 is a second 65c22; VIA0 is handling interrupts; VIA1 is not connected to the interrupt line (as described upthread... snip snip). My ISR is very short - right now it's just counting interrupts:

Code: Select all

irq:
    bit    VIA0_PORTA    ; clear interrupt
    inc    counter
    bne    exit_irq
    inc    counter + 1
exit_irq:
    rti

The only thing I can think is that the stack is somehow getting trashed... but by what?

[sburrow]

Paganini wrote:

Here's a weird one. I've continued making progress on my PS/2 keyboard circuit. It's working as expected, except that I'm getting random intermittent lockups.

So you are working on the PS/2 Keyboard stuff, but this code is just going back to basic interrupts, correct? I won't pretend to be a VIA expert, nor interrupt guru. BUT, I see you are using SEI and CLI, so I feel like I have to comment on that.

The story goes I was working on my own PS/2 Keyboard interrupt routine and also doing something else with the same VIA (just changing some output bits, nothing serious). And I too was getting these random mistakes. It would lock up the keyboard entirely, THEN it would unlock itself but spit out weird garbage. To this day I still don't know exactly what was going on, but clearing the keyboard variables in specific places helped fix it.

That said, I tried using SEI and CLI to fix the issue, and it made it terribly worse! The PS/2 keyboard does not wait for us to be ready for incoming data, it just sends it anyways. As far as this single button / counter code goes, I do not know, but it looks very similar to what I was doing: Altering something on the VIA and then interrupt and everything goes haywire. Not every time, but some times.

Try removing SEI and CLI perhaps? I'm sure you tried that, but it is my first guess. What is your interrupt setup code look like? You know, like the PCR and IER stuff. If I didn't ask, I'm guessing someone else would. Have you tried just like:

Code: Select all

inf_loop
INC VIA1_PORTA
DEC VIA1_PORTA
JMP inf_loop

or even

Code: Select all

inf_loop
INC VIA0_PORTA
DEC VIA0_PORTA
JMP inf_loop

while keeping interrupts on/off? Just suggesting super super super basic routines, and working up from there.

Sorry I wasn't a ton of help, I just wanted to mainly comment on the PS/2 Keyboard thing.

Chad

[Paganini]

Hi Chad,

Quote:

So you are working on the PS/2 Keyboard stuff, but this code is just going back to basic interrupts, correct?

Correct. I'm trying to simplify the problem, so just a single pushbutton to pull CA1 low and generate an interrupt. The weird thing is, the VIA that handles the interrupt is VIA0. The code that seems to be causing the problem is concerned with VIA1, which is driving the LCD display. Since my last post I've narrowed it down a bit:

Code: Select all

    sei
    sta    VIA1_PORTA
    lda    #%11111110
    sta    VIA1_DDRA
    pla
    cli

This is working. If I move sei down one instruction, or cli up one instruction I start to have problems. I didn't originally disable interrupts in this subroutine - I didn't see any reason to. My VIA setup routine looks like this:

Code: Select all

VIA_init:
    lda    #%1111110
    sta    VIA1_DDRA
    lda    #%0000000
    sta    VIA0_DDRA    ; Set VIA0 Port A to input (for reading from keyboard)
    lda    #$01
    sta    VIA0_PCR    ; Set VIA0 CA1 to trigger on Positive Active Edge
    lda    #%01111111
    sta    VIA0_IER    ; disable all VIA0 interrupts
    lda    #%10000010
    sta    VIA0_IER    ; enable interrupts on VIA0 CA1
    rts

I've tried a couple of different test loops; the one I'm using now is a little more complex than what you propose; the ISR just increments a counter in ZP (just like the one in Garth's primer), while my main loop just continuously prints out the value of that counter on the LCD.

[Paganini]

OK,

So I had to take a bit of a break for a week or so, thanks to COVID. I'm back on my feet now, though, and doing a little more investigating. The interrupt weirdness has to do with where the code is, not what the code is doing. I swapped a couple of subroutines in the source file, and the weirdness immediately started up again. This makes me think of a few possibilities:

1. My ROM is bad in that spot
2. I have something wonky going on with my address bus
3. This has something to do with crossing a page boundary.

My code has only just recently grown larger than 256 bytes. My initial interrupt test code easily fit into 256 bytes, so this is the first time my code has crossed a page boundary with interrupts enabled. I'm going to go google about this; meanwhile, if anyone knows any obvious pitfalls related to crossing page boundaries with interrupts enabled, I'm all ears.

Edit:

Here's a disassembly of the spot with the location counter
(In real life the org is $A000, not $0000):

Code: Select all

00fb   78                   sei
00fc   8d 01 92             sta $9201 ; VIA1_PORTA is here
00ff   a9 fe                lda #$fe
0101   8d 03 92             sta $9203 ; VIA1_DDRA is here
0104   68                   pla
0105   58                   cli

It seems like it must be related to the page boundary.

[BigEd]

Sounds like an address bus problem (or just possibly an address decode mistake.)

Worth beeping out the address lines - are they all connected to the pins they should be? Did you swap A7 and A8 or similar? Are any pair of lines shorted?

[Paganini]

All the address lines seem to go where they're supposed to. They are mostly PCB traces. My custom board only uses A0..A3 (connected to the RS lines on VIA1) and A9..A15) (connected to the address decode logic, which is a couple of 138 line decoders).

I added a page of NOPs at the start of my firmware to see if I would get the same behavior when crossing a different page boundary, and I started getting some TRULY wild behavior. The LCD prints all kinds of crazy gibberish. I'm not even sure how to describe it. It also seems to have something to do with having two VIAs in the system. If I disconnect the second one all the problems go away. The VIA on my LCD board has these lines connected to the system bus:

A15..A9, A3..A0,Phi2,RESB,R/WB,D0..D7

The address decoding is the same as this:

https://github.com/tebl/RC-Project-Boar ... 206502.pdf

Except that I added a jumper block to U3 so that I can use, e.g., the $x200, address range for I/O.

I guess I will have to try and simplify more. Assuming I made a mistake in the address decoding (or something) on my LCD board, I should be able to switch back to the breadboard circuit. Let me ask this: looking at the RC Project Board schematic, other than sharing the IRQB line, which I can take care of with a jumper, can you see any problems having two of them attached to the bus at once?

[Paganini]

Well this is encouraging; there's nothing wrong with my LCD board (YAY!), and everything works just fine if I use one VIA to manage both the LCD and the interrupt line. So the problem only happens when I have two VIAs attached to the bus at once. Was it just a coincidence that the problem happened at a page boundary? The plot thickens (or does it thin?)...

[BigEd]

The only thing which stands out is that JP2 but I can't quite think it through.

[Paganini]

As I understand it, I03B is a bus signal on a different KIM1 clone kit; JP2 is provided for compatibility in case you want to plug the project platform into that kit instead of the RC6502. I have pins 2 and 3 shorted so that the address decode logic supplies the CS2B to the VIA, rather than taking it from the bus.

Thanks for taking the time to look at it!

[GARTHWILSON]

On your .pdf, I can't tell what address you might have the second VIA at. It definitely sounds like you have them trying to run on the same addresses though.

The only considerations I can think of regarding page crossings are:

• Indexing will wrap ZP on the '02 rather than letting you index into page 1. (The '816 does let you index beyond the direct page though.)
• The 6502's stack pointer will always be in page 1, so there's wrapping there, too.
• Branch instructions on the '02 take one extra cycle if you branch across a page boundary. Most branches won't cross a page boundary. Further, if you're not doing something where the exact number of cycles matters, the crossing won't affect anything.
• The NMOS 6502 has a bug in that if an indirect jump looks to an $xxFF address to get the final address, the page won't increment as it should to get the high byte. This is fixed in all CMOS versions.
• On the NMOS 6502, indexing across a page boundary caused an extra read of an invalid address, which could cause trouble in some hardware. (CMOS does an extra read of the last instruction byte instead.)

In most circumstances, especially with the CMOS 65c02, there is absolutely no concern about code crossing page boundaries.

[Paganini]

GARTHWILSON wrote:

In most circumstances, especially with the CMOS 65c02, there is absolutely no concern about code crossing page boundaries.

I think it must have just been one of those weird coincidences. Continuing to investigate the address lines as Ed suggested, I seem to have a weird gremlin in one of my bus slots. If the RAM module is in that slot, I get the weird things. If I put the RAM module in a different slot, the weird things go away. I can put other things in the slot where the RAM was without any problems. My next theory is that the bum slot is one of the first things I soldered, so maybe I've got a bad joint on a line that only the RAM module uses. My alternate theory is that that bus slot is right next to the voltage regulator, so maybe there's some power noise / contamination that's trashing the RAM. This is a pretty wild set of triggers: two VIAs on the bus, interrupts enabled, crossing a page boundary, RAM board in slot 0. I'm going to go keep pushing my interrupt button for a while to make sure it really is fixed.

[BigDumbDinosaur]

Paganini wrote:

So I had to take a bit of a break for a week or so, thanks to COVID.

But...but...but...I thought masks and vaccines had this under control.

Quote:

I swapped a couple of subroutines in the source file, and the weirdness immediately started up again. This makes me think of a few possibilities:

1. My ROM is bad in that spot
2. I have something wonky going on with my address bus
3. This has something to do with crossing a page boundary.

I’d go with number 2. When burning a ROM, almost all programming software does a compare on the ROM contents and reports an error if there is a mismatch.

I've never encountered a problem with page crossings in the CMOS processors. If you are using an NMOS 6502, I suggest you replace it with a 65C02.

I suspect you have a gross design error in you hardware, but lacking a full schematic to read, it’s only a suspicion.

[Paganini]

BigDumbDinosaur wrote:

I suspect you have a gross design error in you hardware, but lacking a full schematic to read, it’s only a suspicion.

Sorry BDD; I didn't make the schematic. All those colors don't seem to add anything useful for me either - in fact when I print them out I use my monochrome laser printer!