Jmstein7 wrote:
My hope is that relative newbies like myself, who would like to be able to use the broad parallel feature set of the 'c22, will be able to find this post, in the future, and have working code they can understand and employ.
Well, I wouldn't hold out much hope for that given that what we have so far is code that apparently nobody, even you, has much understanding of. (See again, "Something got fixed and I don't know how or why." That's not a sign of understanding.)
Quote:
Moreover, if you are familiar with the 'c22, then you should understand registers $00 through $0F without my explanation of simple reference labels, ab initio. It's in the datasheet. It should ring a bell. If you can't figure that out, then you probably can't add anything to this thread.
This is entirely the wrong way to go about things.
First, though I'm not hugely familiar with the 6522, I'm quite familiar with the 6820 and 6821, and you appear to be using only features of the 6522 that are directly copied from the 6820. So these
do ring a bell, and if I could trust you to reliably identify your registers the particular addresses would be irrelevant. But I can't trust you to reliably identify them because you don't explicitly mark your A and B registers and put in bizzare oddities like `VIA_DDRR` and `VIA_DDRD`. Sure, I could spend my time going back to the data sheet to sort that out instead of working on your real problem, but given that you seemingly feel no urge to do simple things to help make your code more clear, what's the point? Finding a problem in a mess is hard, and if you insist that the mess cannot be cleaned up to make finding the problem easier I know that I'm probably wasting my time anyway.
Nor is familiarity with the 6522 in particular likely to be necessary to solve this problem; you probably don't know that the 6522 has certain features and operation modes taken directly from the 6820 (with which
I am pretty familiar) and that you appear to be using just those features. (Though again, it's hard to say without being able to reliably identify which registers you're actually writing and how and when.)
This extends even further: programs that do I/O share a lot of general concepts and even someone not familiar with your specific family of hardware may find a problem you've created that is not with the particular hardware but is a more general problem that would also occur with completely different hardware.
Second, the concept of "mental workload" is familar from most areas of human endeavour that have any significant complexity, and we will know that increasing this workload increases human error. This is why airplane pilots use checklists: even though they could—and often do—memorize them, reducing the cognitive load through assists like this has been definitively shown to reduce error. The same goes for programming: you should not be thinking about "register 3" or whatever it is: you should be thinking at the level of a data register or data direction register or similar. Asking people to remember specific associations of numbers or random symbols with those registers is simply increasing their mental workload and increasing the chance of error.
Anyway, it sounds to me from the tone of your reply that you do not consider my advice to be relevant and nor do you mind if I don't help you out with your problem, so you should also feel free to ignore the above, if that's the way you want to go. But keep in mind that I am offering you a proven (from a couple of decades of professional programming experience) way to fix your problem here, even if it's not the way you would prefer to fix it. It's been my long experience that if you clarify your code, problems go away. Code that's an unclear mess creates problems as you change it. And you have the latter situation.