It is possible that the extra read access which occurs in the dead cycle is having a side-effect?

From this document which includes information on cycle-by-cycle timings:

(While the access in the dead cycle is officially under-documented as 'internal operation' we know that it has to be something, and these descriptions, which are presumably from observation, make sense if you consider the necessary internal operations of the machine.)

(I keep losing that document and I find it quite difficult to find each time I need it...)

Is the order in which the hardware registers are loaded important?

Your simple code sets the registers in the order 4, 7, 2

But your table versions loops through the table backwards decrementing Y so the order is 2, 7, 4

Might be worth reversing the data or changing the code to increment Y instead.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Good question, and good call -- I didn't think to consider this, but I'm sure with time I would have arrived at this conclusion sooner or later.

He is using a 65816, which while it has all the timing characteristics of a 6502, it makes detecting "internal operation" easier thanks to the VPA and VDA signals. If (VPA,VDA) = internal_operation, then you can inhibit the generation of chip select signals.

Did you test this exact code also with replacing the


with

i.e. replacing the STA absolute indexed with STA absolute to verify that it's not say in the order you write the bytes to the device? OTOH your linear alternative already writes the values in the opposite order than your looping code (where y is decremented). But it would help determining if the abs,x really is part of the problem.

Besides, your linear alternative writes a different value into reg2 than your looping version. May that also be a problem?

André

(edit: removed extra quote I forgot to remove the first time)

TMSTD (Ten MilliSecond Time Delay) watches a zero page location that is decremented with each watchdog timer interrupt, which is set up to occur at 10 millisecond intervals. I substituted a "do nothing" loop with the Y-register to verify that TMSTD wasn't somehow involved. It wasn't.

Anyhow, my hunch as to what was going on proved to be correct and after a little cut 'n patch session (ain't wirewrap wire and tiny flush-cutters great?), the problem has been solved. I will separately post what I did to fix it, as I think it may be very instructive to others who are working on '816 designs.

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

Not the read access itself. I will shortly be posting what my analysis turned up and how I fixed it.

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

In some cases, yes. The tables are organized backwards so the registers are loaded in the correct order.

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

The original ROM wrote to the absolute address of the DUART's registers, which worked fine.



The example I gave was strictly for illustration of the method. I wasn't trying to reproduce the entire data table.

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

Earlier I mentioned that I had encountered a weird bug in my POC unit which seemed to be related to the use of STA $ABS,X to write into the DUART registers. Several here had come close to guessing the possible cause:


You're getting extremely warm.


Bingo!

Recall I mentioned the watchdog timer (WTD) was working properly using the STA $ABS,X method to load its registers and that the scope confirmed that the WDT was behaving as it should. That started me thinking about the DUART and how it may react to invalid address bus conditions. This prompted me to do some more digging and analysis of the DUART's timing characteristics, which ultimately pointed me to the cause of the problem and the solution.

The DUART is clocked by a 3.6864 MHz signal which, in the POC, is derived from a TTL can oscillator—a crystal could also be used. The DUART clock not only drives the baud rate generator (BRG) and a 32 bit counter/timer (which I am not using), it produces the internal timing signals that regulate the entire device's operation, much as the Ø2 clock regulates the MPU's operation. Considering this, although write operations to the DUART's setup registers are in sync with Ø2, the device's reaction to them is slaved to the 3.6864 MHz clock. This behavior explains why consecutive writes to the same register must, in some cases, be separated by a delay—it is conceivable that if the MPU is fast enough, the second write may occur before the DUART has reacted to the first one, due to the latency of the DUART's clock signal.

Analysis of the DUART's timing diagram caused me to suspect that the problem was occurring late in the third clock cycle of the STA $ABS,X operation, a time when the address bus is being diddled by the MPU and is not yet valid. Latency within the DUART, coupled with a possibly invalid A0-A7 after A8-A15 had been asserted, could cause first one register and then another to be selected, totally confusing the DUART. This would not occur with STA $ABS, as no effective address computation is required for the latter instruction.

Therefore, it seemed prudent to qualify device selection so it could only occur after the fourth cycle had started and at a time when A0-A15 would truly be valid and reflect the final address. My original I/O decoding logic selected a device only according to the address, using an 74AC138 decoder. The revised decoding logic still uses the 'AC138, but qualifies its selection with the MPU's VDA (valid data address) and VPA (valid program address) outputs, preventing selection until after the fourth cycle of the STA $ABS,X instruction has started, at which time a valid address is guaranteed.

The following information is in the '816 data sheet and is what I used to work out the logic:


From the perspective of selecting devices for I/O, the third condition is the one to use. Condition one (both VDA and VPA low) is where the trouble was occurring, as that was when the MPU was fiddling with the address bus and confusing the DUART.

A little PCB surgery set up the new logic. First I tested with a ROM having ordinary STA $ABS code to verify that the POC was still upright with a pulse following surgery. Once that had been established, I modified the code to use STA $ABS,X, using identical parameters and in the exact same order:



The board booted with the above code, displayed the POST screen and cheerfully accepted typed input. This was with the POC running on a 1 MHz Ø2 clock. Next, I changed the oscillator and boosted Ø2 to 8 MHz. Everything worked fine. In fact, I programmed one of the function keys on the Wyse 60 to emit a complete sentence as fast as the terminal could physically send the characters and held the key down to ram data through the POC as fast as possible (about 200 chars per sec). Every line of text was echoed error free.

With the CBAT I/O test confirming that the new logic was working, I replaced the above setup code with the data tables and register loading loop. It all appears to work as it should.

The interesting question is why was only the DUART affected? I concluded it was a combination of it being driven by a clock signal that is asynchronous to Ø2, as well as the device's inherently slow operation when writing to the setup registers. You may well ask why didn't I slow down Ø2 to see if it was a case of a slow device not reacting quickly enough to A0-A15. Well, I went so far as to put a 1 MHz oscillator in the board, which resulted in Ø2 being 500 KHz. The error persisted, although in a different way, which is what ultimately pointed me in the right direction.

I think the conclusion that can be drawn from this little contretemps is that the VDA and VPA outputs should be part of the address decoding logic of any '816 design. Clearly, Bill Mensch anticipated some address bus hinkiness with the '816 when he designed it, and decided to provide outputs that would unambiguously indicate when it was safe to select hardware.

Looks like it's time for me to permanently revise the schematic and the board layout.

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

Interesting - good to see you had a fix.

It sounds like you wouldn't have the same fix available to you if you were using a 65C02. You might have to slow down the CPU (a lot) to let the DUART distinguish the two consecutive writes.

Or, perhaps, you could take advantage of the first write lacking the carry into the high byte, by basing your accesses at the top of the previous page:
instead of
and of course arranging for X to be one greater. Would that work?

It may be the 'C02 doesn't monkey with A0-A15 in the same fashion as the '816 during the second-to-last cycle of the STA $ABS,X instruction. If so, no special hardware logic would be required, as the DUART would see a stable address at the onset of the final cycle. I have no way to determine if this is the case, as the bus behavior of the '816 is the same in both modes (the POC ROM currently runs the MPU in emulation mode).


That would mean somehow altering Ø2 on the fly to some submultiple of its normal rate. That's assuming that timing per se is the culprit. My fix on the POC indirectly indicates that timing was not behind the DUART's wacky behavior with STA $ABS,X. It was strictly a case of address bus behavior late in the instruction execution.


Dunno. That would require that register offsets be one-based, which is not an issue in itself, but would add one cycle to every STA $ABS,X access. It might actually make things worse.

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

Unlike non-writing instructions (LDA, AND, CMP, etc.), STA abs,X always takes 5 cycles whether it crosses a page boundary or not.

Really! In which data sheet did you see that? Here's an excerpt from the W65C816S data sheet, a document with which I and several others around here have more than passing familiarity:

Absolute,X 4 (1,5) 4 (1,3,5)

and notes 1,3 and 5:

1. Page boundary, add 1 cycle if page boundary is crossed when forming address.
3. M = 0 or X = 0, 16 bit operation, add 1 cycle, add 1 byte for immediate.
5. Read-Modify-Write, add 2 cycles for M = 1, add 3 cycles for M = 0.

Please refer to table 3-1 on page 25 of the data sheet for more info.

I'm currently running my POC system in 'C02 emulation mode while I debug the hardware. The address of the DUART is $D000. Therefore, since I'm doing an STA $D000,X, only note 1 would apply and the instruction execution time will be four clock cycles, or 500 nanoseconds (Ø2 = 8 MHz). A page boundary crossing with this instruction ain't gonna happen, right?

You can rest assured that I spent plenty of time studying the '816 timing diagram and instruction execution specs as I was designing my POC. I won't go so far as to say I've got it all memorized, but I'm getting close.

In any case, the resolution of the problem I was experiencing had to do with address bus behavior right at the beginning of the final cycle of the STA $D000,X instruction. At that point in time, an incomplete address is asserted on A0-A15. The address doesn't become valid until the MPU's VPA signal is low and VDA is high. Whether that final cycle was number four, number five or number 16,777,215 isn't relevant.

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

Hmm, indeed the current datasheet says there's a page-crossing penalty. Other docs say as Bruce does. So, I ran a test on a real 65816, about 4 million repeats on a 2MHz system:

NOP : 21.87s - known to be 2 cycles
LDA abs,X, no page crossing: 26.24s - therefore 4 cycles
LDA abs,X, page crossing: 28.42s - therefore 5 cycles
STA abs,X, no page crossing: 28.42s - again 5 cycles
STA abs,X, page crossing: 28.42s - same again

To me this makes sense: in the 4th cycle of a normal load, the CPU performs the dummy load and also discovers there's no carry. So the next cycle can be the next fetch. For a store, it's not safe for the 4th cycle to be a dummy write, so it has to be a read. Therefore the earliest a write can safely be made - whether or not there's a carry - is the 5th cycle.

The datasheet is probably wrong(*1), unless the design was recently updated, in which case my older parts need an older datasheet.

I checked, and an NMOS 6502 performs exactly the same. (The above tests are in emulation mode, I repeated them and got the same cycle counts in native mode.)

Note that the datasheet doesn't seem to have room to describe operations with 2-byte loads or stores - it's over-simplified.(*2)

I'm tempted to say

if it's not in the datasheet, it isn't specified - but you might need to know, so measure it
if it is in the datasheet, it might be wrong - so measure it
if you get a new batch, the answer might have changed - so measure again

but I'm not going to!

Cheers
Ed

Edit:
(*1) Bruce found the section which gives the correct info.
(*2) Ditto - the table BDD consulted is not the detailed one.

Hmm...the 65C02 data sheet also says STA $ABS,X takes four clock cycles if a page boundary isn't crossed. However, the MOS 6510 data sheet says five cycles. Go figure. Looks like my earlier response may be in error.

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