_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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?



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:



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

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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:



or even



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

Hi Chad,


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:



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:



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.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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



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

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?

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-Board/blob/master/platforms/PP%206502/export/PP%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?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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?)...

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

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!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

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!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad