I have a really strange (I think) quandary. I have a 65c22 connected to a microcontroller. Handshake is enabled on Register 0C. Ports A and B are connected to the MCU. I have a program on the MCU that responds to the handshake on CB and CA when data is written to the ports. However… when Port B sends a byte, I get that byte. When Port A sends a byte, I get the byte that was formerly in that location, not the byte I just wrote?!

Has anyone had this issue before??? Suggestions?

Jon

[Edit] I also just noticed that when I write from Port A to a peripheral, Bit 1 of the IFR ($0D) gets stuck "on", no matter how much I read or write to Port A thereafter.

I suggest you give us more information.

We need a lot more detail. Can you tell us the whole story? For example, what sort of data (8-bit? 16-bit?) is moving, and in which direction, and does the microcontroller cue the transfers, or does the 65xx? Why do you need both Port A and Port B? Also you mentioned CA and CB but do you mean CA1 and CB1? What about CB2 and CB2? Some code examples and even photos might be helpful. Try to fill in the picture, please!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

Ah, good morning! Let me get all that for ya.

Jon

Basically, this is an exercise for me, to learn how to move data to and from peripherals through the 65c22 (and other ICs that can sit on the bus). So, the data I'm moving, to and from, is 8-bit data chunks. The 65c02 cues the transfers, both ways. This is the default initialized state of the VIA registers ($00-$0F):
00 00 FF FF 0C 5D BD AA 92 37 FF 00 99 00 80 00

VIA PORT A controls the data and PORT B sets the register on the MCU (a PIC1845K40 for my demo purposes). Here is the little program I'm using (a work in progress) on the 65c02:



Ports A and B are both in Handshake mode ($0C at 0x99). When you write a byte to Port B, it sets an address byte on the MCU, and a flag that tells the MCU to expect data. When you write to Port A, it sends the data, clears those flags, and takes some action, e.g., store the data in a register or perform some operation on the values currently in the registers.

However, Port A will only get the correct value if I pre-load it into B. That's why "STA value" is before the register load. After the register load, writing any value to Port B will send the pre-written value to Port B.

There is a delay in it because I was (and still am) using a LCD connected to the PIC to monitor the values being received from the 'c22.

I haven't done transfers back to the VIA yet from the MCU.

Jon

[edit] The MCU sends the proper handshake acks on CB1 and CA1.

[edit2] Here is my tentative bit-check routine:

This is still very hard to grasp. One thing you can do to help is to use consistent symbolic names for all the VIA registers you access. For example you have VIA_DDRR = $8802 , and that's fine, but you don't always stick to the policy. For example the line LDA $880D ;load $0D fails to use a symbolic name. Also the code requires more comments, IMO.

And nowhere -- not in the code comments nor elsewhere in your post -- do you have any overall description of what's being attempted. For example (I'm just making this up) you could say, "In this experiment the 'C02 asks the PIC to output bytes one by one, with CA2 (driven by the 'C02) going low to make the request, and CA1 (driven by the PIC) acknowledging by going low when a byte has been placed on the data lines PA7-PA0." Even that lacks detail, however, since it makes no mention of how PORT B sets the register on the PIC. Please make more of an effort to tell the whole story.

It's possible that writing a properly detailed description will help you clarify things in your own mind. And it's certain that a properly detailed description will help clarify things for us!

Yes.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I'm going to go with not even that being fine. "DDR" is obviously the data direction register for one of the two ports (A and B), but for which port? And what does the "R" mean?

Some developers can actually handle having more or less random names for things because they memorize these perfectly even without any hints in the name itself to say what it means. Other developers think they can do this but can't; they are the ones that end up writing terribly buggy code. And of course if you're asking anybody else to read your code, regardless of what type of developer they are there's no hope that they'll know what random letter you picked for what.

I suggest you start by going through every single symbol name you have and work out exactly what each part of the symbol name is supposed to be communicating to the reader. If it's not clear, first change the name clarify it as best you can and then, if it's still not obvious, add a comment if necessary. If it's not consistent with other symbol names (e.g., does every name dealing with something dedicated to port A have "A" in the name?), make it consistent. In all cases remind yourself that you are not writing this code just for the computer: the code is also supposed to be a clear explanation to another human reader of what you are trying to accomplish.

After you do this you may not even need to post the revised code; it's reasonably likely just clarifying your code will reveal to you many of the problems in it.

_________________
Curt J. Sampson - github.com/0cjs

_________________
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?

Well, it wasn't the labels. I have added more comments to explain what is going on. In any event, there is a new problem.

The first issue - lagged values written from Port A - is solved. I have no idea why, though. And, nonetheless, a new, unrelated (I think) problem cropped up. I have labeled (in the comments) where the issue crops up. Essentially, the PIC is writing values to PORT A on the 'c22. The 'c22 should be receiving them and storing them at the indicated addresses in RAM ($F0 and $F1, in these examples). However, either nothing is written (0x00) or it gets "0D 0D" in $F0 and $F1 respectively.

The interesting thing is that, if I only do ONE value (just try to store the first value in $F0), that works

Okay, geniuses, have at it

Actually, you have some explaining to do first. For example, what is `VIA_DDRD` and why is it important to us? Why are we spending time reading that line of code and what should we expect to learn from it?

If you're answer is, "it's unimportant and I'm wasting your time with that" you can perhaps anticipate what kind of response you're likely to get from the people you're asking to help you.

I very much suspect you're not writing this code with the aim of clearly showing the problem to others not familiar with your machine, but that this is just something you've hacked out and tweaked multiple times more or less at random while trying to figure out what might work and what doesn't, and never spent any time cleaning up.

It's particularly telling that a problem has gone and you have no idea why it's gone. You need to go find out what made it go away. Go back through your revision control logs to figure out which change fixed the problem. If you don't have revision control logs, well, now you see part of your problem, too: you might well be changing things without any idea that you are changing them, which can "fix" some parts of the program while breaking others. You'll never get a reliably working piece of software that way.

Sorry if this all sounds a bit harsh, but flailing rather than making carefully considered changes, and not understanding exactly what you're changing, will doom you to having continual problems like this for as long as you program. And asking others to help clean up a mess that you didn't need to create in the first place is not going to get you a lot of support.

_________________
Curt J. Sampson - github.com/0cjs

If that was the case, I would just look at prior forum posts and not bother y'all with this. However, there are no posts (and I searched) that dealt with these specific issues on the 'c22. Moreover, There is really no parallel code in the repository for shooting data back and forth to and from peripherals through the 'c22. Again, if there was, I would not have bothered.

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.

Fair enough?

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.

Jon

To be more constructive, perhaps, I'd suggest that this kind of joint exploration and investigation needs be a joint effort: the person with the problem needs to pay some attention to the time and attention that's needed to debug something, and pay back the effort (or pay it forward) by endeavouring to explain what's going on, what's been tried, and so on.

If there's not goodwill on both sides, and recognition of the effort needed on both sides, it doesn't go so well.

Look, this is a forum where participation is at one's own pleasure; it is not compulsory, right? There is no obligation to help anyone, while there is also an implicit invitation to help everyone you'd like. You can do it all, or you can do nothing, and everything in-between.

People who can't add anything useful, or do not wish to, don't have to. People who would like to chime-in can. Personally, I deeply appreciate everyone who gives me the time of day, and I am happy to return the favor - not because of any obligation, but because it is my pleasure to do so.

Jon

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


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.

_________________
Curt J. Sampson - github.com/0cjs

It's possible, Jon, that you're underestimating what it takes to debug code that's not your own code and that you can't run.

People here are very helpful, but you need not to come across as entitled: you need to cooperate. If you look like you're willing to learn, you will find willing teachers. If you give the impression that you view this site as populated by robots which answer questions, you will not do so well.