I've been working on the initial BIOS version to get my new Pocket SBC running for a bit now and I do have it functioning quite well. Here's a link to the hardware project:

viewtopic.php?f=4&t=4988

I've found some odd operation of the SCC2691 for initialization and operation. For initializing the chip, it's a more complicated set of instructions versus something as trivial as the 65C51. I initially got it to work by simply doing load and store operations, i.e., LDA #$value, STA UART_REGISTER. After getting the configuration and sequence sorted, I decided to put it into an indexed load/store with two tables; one that holds the register offset and the other that holds the register data. As the NXP UARTS use a set of Mode Registers at the same physical address, you issue a command to reset the Mode register pointer, then store the desired value for MR1 followed by MR2. For some odd reason, this method doesn't work. The first Mode register gets loaded with all bit active ($FF) while the second Mode register gets loaded with the correct value. I've tried this multiple ways and in every case, if I used a load/store that is indexed addressing (W65C02) the first Mode register never gets loaded correctly.

I'm currently using two routines to get the UART functioning; The first is a simple set of commands that set power down mode as inactive (ensure the chip is in power up mode) followed by a sequence of commands that clear the Break Change Interrupt, Disable the Receiver, Disable the Transmitter, Clear all errors. The second routine uses an indexed set of tables to set up the various registers for operating mode, i.e., baud rate, interrupt masks, counter/timer preload values, etc. The last part of this routine does the load/store of the Mode registers. I also use the same table of reset commands for handling the Receive Break function of the UART with one extra command to enable the receiver. The odd part is I have to issues a Power On mode command again with the indexed list (this was done in the first Reset routine) otherwise the UART never works. It's not clear why I need to issue the Power Up command again with the second routine, but it won't work without doing it.

Once the chip is working, it's basically flawless in receive and transmit along with handling the received break function. I use this in the Monitor/BIOS to break out from the Macro loop of the Monitor (allows a sequence of instructions to be executed in an endless loop). In fact, I'm quit happy with the results of both the new board and the new UART as a console. However, the NXP UARTs also have some caveats that need to be managed so you don't hose them up. There are a couple test modes that are invoked by simply doing a read to a register. One is for the baud rate and a second is a 1X/16X clock test. As one of the monitor functions displays memory addresses in hex and ASCII, if the routine is executed against the UART, it locks up the system. I've done some initial debug around this and it turns out there is no way to reset the chip via software, a physical hardware reset is required. I have a Panic routine invoked via a NMI trigger which save registers, pertinent pages and restores the vectors and I/O initialization (which runs to completion) but the UART won't start working again until a physical reset is done.

An earlier bit of code was not locking up, albeit the console display of the I/O page (UART addresses) was garbled up a bit. Unfortunately I can't seem to find the cause for the recent locking up on reading the registers. Also, reading the receive register will also increment the FIFO buffer which adds yet another issues to be dealt with. I'm not currently decided on how to manage the memory display in the Monitor code just yet, but I'm thinking of having an excluded address list that will return a bogus value for any accesses to those addresses.

In any case, using the SCC2691 is a bit of a challenge versus the 65C51 for something as simple as a console. Overall, I'm still glad that I made the switch (of UARTs) and the new SBC. It's been a good project so far and I'll likely have the initial BIOS and Monitor versions done shortly. It also gives me the base code and knowledge to move to the newer NXP UARTs with minor code changes. If anyone else has done some (65C02) coding around the SCC2691, I'd be interested to hear any experiences to compare with mine so far.

_________________
Regards, KM
https://github.com/floobydust

You haven't posted the code, or mentioned where IO is located. But let's say IO is at $C000. In your code it sounds as if the actual STA to the UART is indexed by X or Y, like this:


As an experiment you can try changing that snippet to what's shown below. The altered code still addresses the same location but in the process it'll force a page crossing to occur because the base address now has $FF in the low byte. I might be barking up the wrong tree but I suspect the page crossing will fix your problem. If you get a sec to try this pls report back the result.


cheers
Jeff

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

My feeble dinosaur brain seems to recall another discussion we had going about this, which, if I recall, centered on the 65C02 doing an undocumented "false" read of an address when an indexed write instruction is being executed. As what you are doing is programming the 2691 via a series of indexed stores, I think what is happening is the false read is resulting in the 65C02 touching MR twice, once during the false read and again during the actual write. False reading MR when it has been set to MR1 will cause it to autoincrement to MR2, which means you would not be able to write to MR1 using a "straight" indexed access. Therefore, I think you should try out Jeff's address offset suggestion to see if it magically fixes itself. If not, another route to consider would be using indirect addressing, which should not result in the false read.

Incidentally, I would consider this behavior of the 65C02 to be chip errata, as it is not documented in the data sheet and potentially precludes the use of indexing on I/O hardware, including 65xx family devices. This problem does not arise with the 65C816 when the VDA and VPA outputs are used to qualify accesses, as the machine cycle in which the false read would occur is signaled by VDA and VPA both being low.

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

Thanks Jeff/BDD,

I'm posting the two setup routines here. This takes the guessing out of what I'm actually doing. The UART is addressed at $FE80, so the initial recommendation (which is a really good one) won't work unless I reprogram the 22V10 and change it (which I can do). Also note that the instructions are sent in reverse as listed due to the indexed count being decremented.



...and the data used: Basic configuration is for 38.4K baud, 8 data bits, 1 stop bit, no parity. MPO/MPI are configured for RTS/CTS handshaking. Timer/Counter is loaded to generate an interrupt every 10ms. Interrupts are enable for Receive/Transmit, Timer/Counter and Received Break.



Fortunately, the above code is working properly for setup of the 2691. I'm thinking about moving the UART I/O address to page $FF and simply clipping off the addresses for memory display and search routines within the Monitor code. Then again, this does make things a bit ugly overall... as the table-driven disassembler could also end up clobbering the UART registers on reads if allowed to go that far. Still, this is a fun project and a good exercise in thinking as well as coding

_________________
Regards, KM
https://github.com/floobydust

The idea of the workaround is to force a page crossing. So, instead of accessing relative to $FE80, you would need to adjust X so you access relative to $FDFF. If X comes from a table, that's easy, otherwise you need to add $81 to X which would take a few instructions.

It looks like X does come from a table in your case.

Actually, tinkering with .X won't help, as that is his table index. The device index is in .Y, which is loaded from the register table with LDY INIT_OFFSET-1,X. So what could be done would be to change STA SCC2691_BASE,Y to INY followed by STA SCC2691_BASE-1,Y. MR is at offset $00 in the 2691, so the above would make it seem to the MPU that MR is really at offset $01. I would think this would result in correct operation, assuming my theory about what the 65C02 is doing is correct.

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

Oops, X ≠ Y. But still, I believe the idea is to force a page crossing, so the unwanted access affects the previous page and not the I/O page. So I think the table contents need to change, and the base needs to change too. These two lines
become

Yes, forcing a page crossing should make the 'C02 stop doing the false read, if one can believe the data sheet. My thinking is based upon the notion that the false read is occurring at the unindexed base address, with the following write occurring at the indexed address. In the case of the 2691, if the index is $00, then MR (mode register) is touched twice, causing it to autoincrement to MR2 and setting the stage for the problem being seen. Different ways of fixing the same issue, as it were.

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

Okay, good. And I don't think it'll be necessary to reprogram the 22V10. Instead the test I suggested can be altered.

First let me doublecheck something. (I don't want to add another hiccup to the discussion.) Although you didn't post the part of your code where SCC2691_BASE is declared, you did say, "The UART is addressed at $FE80." I take that to mean the constant SCC2691_BASE has the value $FE80, and I will proceed on that premise.

So...is the same as

In order to alter this in a way that forces a page crossing we do as Ed said: STA (SCC2691_BASE & $FF00)-1,Y or, in other words,Notice the base address has been reduced from $FE80 to $FDFF -- a difference of $81. To compensate you need to increase the index by $81, which can be most efficiently done by adding $81 to every entry in the table from which Y got loaded, more or less as follows. (Yes there are prettier ways of doing this. )I hope it's clear how this will force a page crossing. Please give this a try and report back.

I agree there's a problem with the data sheet, but the exact explanation involves some hair-splitting. I think it'll be best if we discuss that after the problem has been resolved.

J

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

Well, I did a much simpler test to prove all of this. As the BRG Test register is the Register Read of $02 (register offset from base), writing to that address is the Command Register (which is done a lot!). So, examining the BRG Test baud rates, if programmed for either 38.4K or 19.2K, they stay the same. So I changed the soft config byte from $CC to $AA (7200 baud) and called the INIT routine. I then had to change the baud rate to match the 7200 and was able to communicate to the UART. I then ran the INIT routine again and then had to change the baud rate to 57.6K to talk to the UART. Run the INIT routine again and I have to switch the BAUD rate back to 7200. It just toggles back and forth!

So, no doubt... this is the problem, i.e., the 65C02 "is" doing a false read when using indexed addressing. This certainly puts some inhibitors on how you use the NXP UARTS with the 65C02.

_________________
Regards, KM
https://github.com/floobydust

The issue isn't that hard to work around. And the ugly "test" code I suggested can be prettified; I only wrote it coarsely so it'd be clear. Or you can use BDD's suggestion of using the C02's indirect address mode. Are you willing to try the (ugly) test?

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

Which, of course, explains the MR contretemps.


Well, you can try out Jeff's suggestion and see if that "fixes" it. Or perhaps use (<zp>),Y addressing to do the setup, where .Y would continue to be the offset of the register that is being configured, and <zp> would be loaded with the UART's base address.

There is no question in my mind that this behavior is chip errata on the part of the 65C02—not a defect of the 2691—and should be reported to WDC.

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

Oops, nope. I misunderstood; thought you meant indirect address mode without indexing. The non-indexed indirect approach has no issues and is pretty easy to code; you just modify the lowbyte of the ZP pointer each time as required. But indirect mode with indexing (via Y) will give the same problem we've already seen -- namely, an unwanted read before the write. (And the same workaround -- a forced page crossing -- can be applied.)

Right. The 'C02 is advertised as being "fixed," as compared to various issues affecting the NMOS '02 -- including unexpected bus behavior during indexing. The advertised fix is real and valuable, but less extensive than one might wish -- a few of the problem circumstances still give trouble.

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

Okay,

I did a quick code change based on Jeff's suggestion. I made a new indexed looped routine to reset the Mode Register Pointer and load the two Mode Registers. I coded the addresses normally first to ensure that the bug was present, i.e., no offset to force a page boundary change. This resulted in MR1 not being loaded. I then put in the offset of $81 to push the effective store address from $FE80 to $FDFF and the init routine now works properly.

I also noticed another caveat with the SCC2691 while initially debugging this problem early on. Once the MRs are loaded, you can turn the SBC off for several minutes... and the register contents still hold in the 2691. In other words, the test with bad code (indexed store) appears to work as MR1 never lost it's contents. So for debugging this I keep a short piece of wire handy and simply short out the +5V to ground at the EEPROM (pin 28 to in 14). This ensures the 2691 registers are cleared.

So once again... another interesting exercise and finding another bug with the 65C02. And of course, another set of thank-yous to Jeff and BDD Now that this is fully understood and documented, I'm going to use my existing code that loads the MRs separately and document why this is the case. If I decide to move the UART base address in the future (which is easy using the 22V10), I'll need to alter the routine addresses to ensure I get another page boundary crossing for it to work. I'll write this up and send it to WDC, along with another bug I found in the WDC Assembler while working on this project. Oh, the fun of it all!

_________________
Regards, KM
https://github.com/floobydust

FWIW, the Apple II Super Serial Card (using the 6551) has this exact bug fix in its firmware. The false read would look like an access to the data register which would clear the 'character available' status register bit.