Hey, I'm new here

I seem to remember faintly that 6502-like processors had some constrains about the write-sensitive hardware registers. Namely, that write sensitive hardware registers should be decoded with some space between the registers to avoid false writes/reads. Like a page or so. So if you have registers of one device at address $f0xx, the other device should be decoded at $f1xx. Is that true or ********? It rings the bell for me but I am not sure. Or maybe the running code should be placed at least a page from write sensitive registers? Also forgive me if it's an utter ********, I did not mean to offend anyone's knowledge, and i am a 6502 newbie.

One of the bugs in the NMOS 6502 processors is that indexed addressing across a page boundary produces an invalid read. Maybe someone else can give the details, but I seem to remember that if the first byte of an address is at $10FF and the second byte is at 1100 for example, 1000 will get read, and if you had a 6551 sitting at address 1000 for example, a read at that address may clear the receive-data-register-full bit in the 6551's status register, causing lost bytes in a stream. It drove a few people nuts until they figured out what was going on. This and all other NMOS 6502 bugs were fixed in the CMOS 6502 (65c02) however, so it's no longer an issue there.

Another bug is with read-modify-write cycles in the NMOS version. It first writes the unmodified value, and then the modified value. This is also fixed with the CMOS version.

But you can use the NMOS just as fine if you avoid these bad patterns.

André

The invalid reads that occur can also adversely affect a device whose internal clock runs asynchronously to the MPU bus cycle. I ran into this with my POC design, in which the invalid read caused by a STA $ABS,X operation would get an ACIA confused during device setup.

The 2692 ACIA runs on a 3.6864 MHz clock, whereas the MPU in this particular design is running at 10 MHz. The ACIA requires a quiescent period after writing certain registers, during which no device access is allowed. Failure to meet that requirement will cause the most recently written register to fail to retain its data. I thought I was satisfying that requirement by using a delay subroutine to space out write ops. Yet the ACIA would mess up when using STA $ABS,X, but would work fine with STA $ABS.

The trouble was being caused by the invalid read operation the '816 was performing on the second to last cycle of the STA $ABS,X operation, goofing up the ACIA. The solution was to qualify all I/O accesses by using the VDA and VPA MPU outputs.

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

To clarify, it was read sensitive registers that fell victim to the problem. The 6522's IFR (Interrupt Flag Register) is an example of a read sensitive register. The sensitivity is a design feature, not a bug: it helps streamline interrupt service code. The 6522 is designed so that reading the IFR clears the interrupt flags so the code doesn't have to do so explicitly. Not all IO chips have read sensitive registers; therefore the issue can be ignored for some systems.

Note that coding errors (superfluous reads) can easily cause problems when read sensitive registers are present. The other problem area is unintended ("invalid") reads caused by CPU hardware.

The 65c02 does not output invalid addresses. However, the NMOS 6502 can. For example, LDA $7FFF, X with X=1 will result in a read of $7F00 then a read of $8000. 7F00 is invalid -- it is a partially complete addition of 7FFF + 1. But if you have a device at 7F00 it will get read.

The 65c816 also outputs invalid addresses, but it has the good grace to warn you (if you care to listen). So, make sure you include its VDA signal as part of the logic for enabling your IO device.


To me, this sounds as if the problem is specific to 2692's. In general we wouldn't expect to see a problem simply because a device's internal clock runs asynchronously to the MPU bus cycle. It's just a 2692 thing, right? -- or am I missing something?

Probably not, but you may be reading more into what I said than warranted. Note how I said "can also adversely affect..."

The designer needs to carefully peruse the data sheet for any device that uses a separate clock source to determine if there are constraints on consecutive register writes. The 2692 DUART has this characteristic, as does the SCC2698B octart, which is logically four 2692s on a single die. Both of these parts use a fixed 3.6864 MHz clock to time the baud rate, as well as regulate internal chip operations.

Here's the caveat from the 2692's data sheet:

CRA[7:4] – Miscellaneous Commands
Sequential writes to CR(7:4) should be separated by three edges of the X1 clock.

X1 refers to the 3.6864 MHz clock, which may be generated by a crystal or a can oscillator (I used the latter in the POC design).

CRA (command register A, also CRB for the second UART) is used to set up basic operating parameters. In some cases, it takes three X1 clocks for the setup to complete. If a new value is written into CR prior to the completion of the previous operation, device behavior is undefined, and as I learned with my design, results in improper or no operation. To satisfy that requirement, I insert a 10 millisecond delay between consecutive writes to CR, giving the 2692 more than ample time to complete the internal setup operation.

However, I initially didn't consider the effects of invalid memory bus conditions brought about by the '816 during intermediate operations. A query to NXP confirmed my suspicion that the mere act of placing the register's address on the address bus at the wrong time is sufficient to cause a malfunction. Use of the VDA/VPA logic outputs of the '816 resolved this issue by guaranteeing that no I/O device would be selected unless the address and data buses were truly valid.

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

Thank you all. Appreciated.