I was wondering if anyone had used both these DUARTs and was aware of any compatibility issues? My SBC (6809 based, ahem) currently uses a EXAR 88C681CP/28 quite successfully, but these are difficult to get hold of so I bought a couple of Philips SCN2681AC1N28 as spares. Both are the 28pin DIP "sawn off" versions of this popular DUART, which I believe was descended from the original 68681 Motorola part? But I might have that backwards.

Anyway, either both the ones I sourced are damaged or there is some differences that I can't account for looking through the datasheets:

SCN2681: http://www.buchty.net/ensoniq/files/mc2681.pdf
88C681: http://www.farnell.com/datasheets/7281.pdf

Note the typo on the 88C681 datasheet (not a good start!) Pin 1 *is* A0, not N/C on the 28 pin DIP.

I haven't yet stuck a Analyser on the board to find out more about what might being going on, but from what I can tell the presence of the device on the bus is completely preventing any kind of memory access, since the first thing my software does at the reset vector is trigger a ahem "diagnostic tone" on the piezo.

Any help from you knowledgeable folks is greatly appreciated.

Lawrence

_________________
8 bit fun and games: https://www.aslak.net/

The PDIP28 versions of 88C681 and 2681 are indeed electrically interchangeable. However, 88C681 timing varies, especially the tAH value. Also, the 88C681 has a two-deep TxD FIFO, which the 2681 does not have. Furthermore, the interrupt behavior is not the same. My interpretation is that the 88C681 is a replacement for the the 2681, but not vice versa.

Incidentally, you should go here for the 2681's data sheet. The copy to which you linked is substantially out of date.

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

After some digging, it turns out the previous problem I saw (no MPU access to the EEPROM) was down to a completely unrelated issue with my rig.

Though there might be bus timing differences, your hint at interrupt differences lead me to study the register layout in more detail. It seems there are subtle differences in a few different areas. The area which tripped me up was, of all places, the baud rate generator. Ie. the rating code mappings. Anyway the IC is working nicely in my SBC. It's a shame I can't swap the parts in and out, but they are different after all. I think I will code against the NXP part, since they are easy to come by.



Noted. BTW, do you know where I can find the BRG Extended application note? I can't find "Extended baud rates for SCN2681, SCN68681, SCC2691, SCC2692, SCC68692 and SCC2698B" anywhere.

Man those NXP 'sheets are terse.

_________________
8 bit fun and games: https://www.aslak.net/

From page 8 of the 2692 data sheet:

The baud rate generator operates from the oscillator or external clock input and is capable of generating 23 commonly used data communications baud rates ranging from 50 to 130.4K baud. A 3.6864MHz crystal or external clock must be used to get the standard baud rate. The clock outputs from the BRG are at 16X the actual baud rate. The counter/timer can be used as a timer to produce a 16X clock for any other baud rate by counting down the crystal clock or an external clock. The four clock selectors allow the independent selection, for each receiver and transmitter, of any of these baud rates or external timing signal.

They explain it in that paragraph. You configure the DUART to either generate default baud rates, or you program the counter/timer to control the baud rate, which gives you access to non-standard rates. There's a blow-by-blow description of the relevant registers. It just takes some reading... However, I took pity on you. See the attachments.

As an aside, I recommend you use the 26C92 or 28L92 if you want dual channels, the 28C94 if you want four channels or the 28L198 if you want eight channels. The programming models for all them are very similar and all have transmit FIFOs, which the 2692A, 2698B and older NXP UARTs do not have. In particular, the 2698B will generate an IRQ storm when all channels are transmitting, which will seriously affect system performance. I have quite a bit of experience with that part and can attest to its transmit inefficiency. The lack of a TxD FIFO really hurts.

Incidentally, if you shop via eBay and see a 2698 being advertised you should verify that it is a 2698B. The original 2698 has some errata, as well as some feature differences. You really don't want the 2698A.


Depends on how you define "terse." I've read worse (WDC's data sheets are pretty terse).

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

BDD thanks for the EXTBDRT document. I never found that one in the internet (was I too lazy or just blindfolded, I don't know).

But I still have a problem to get those NXP UARTs to work. I have now a SCC2691 connected to my small workbench computer (using a GTE G65SC816-4 ) running at 2MHz. This should not be too fast. But I can't seem to setup the registers. The CE is just the address range $8000 to $9FFF decoded with a 74HC138 and the REN and WEN are generated with another 74HC138 with R/W connected to A and G2 to PHI2 (and G1A=G1B=GND). No buffers in the Address or Databus. All the other I/O on my computer works perfectly (CDP65C51-4, which is the current RS-232 to my PC, the W65C22 and also a 74HC574 latch and a 74LS367 digital input).

The bad thing is that there are no registers that you can read back, so I have no clue whether I can successfully write/read the registers. I tried to set MR1 and MR2 but never can read back the same value (worse, no matter how I reset the MR Pointer using the dataregister, the MR1 and MR2 always read back the same value).

the X-TAL seems to work perfectly (on my scope on XTAL2 it shows a very smooth sine with 4.4Vpp, so the oscillator does work). I have no clue how to proceed. Do you have any hint? Or a code sample how to initialise this baby?

And I must say Aslak3 is right saying the datasheets leave much to the imagination. Although it seems everything is described, the structure is horrible and the information is not linked in any way, e.g. there is one table mapping Addresses to Registers, but the addresses are only mentioned there. Then you have the table with the bit definitions but for some bits you just have a "see text" reference. So the information is scattered all over the various pages. They are really not nice to read.

Peter

I don't know if that one is online. I got it from directly from Philips technical support some years ago.


I'm not familiar with the GTE MPU. Does it generate false address bus states like the W65C816S? If so, you may be getting tripped up by it.


Can you post a schematic (not in color!) to illustrate your interface to the 2691? I have my suspicions but can't confirm them without seeing a schematic.


Quick note: you reset the MR pointer by writing the bit pattern %00010000 to the command register (CR). Always allow a minimum of three DUART clock cycles to elapse after accessing CR. That would be at least 0.814 µsecs, assuming a 3.6864 MHz clock. Violating that requirement will result in an internal error in the 2691, which may require a reset to clear. After resetting the MR pointer, you should be able to read back what you wrote into MR1.

In situations like this, your logic probe and 'scope are your friends. Some things to consider:

• Have you verified that the 2691 is being selected when you try to access it?
  
  
• Are you sure nothing else is being inadvertently selected at the same time?
  
  
• Are the /RDN and /WRN inputs being strobed at the right time?
  
  
• Is /CE being asserted before /RDN or /WRN are strobed?
  
  
• Is your glue logic correctly accounting for tAS and tAH?

Not having a copy of your schematic before me, I can't offer a whole lot of advice right now.


4.4 Vpp sounds good. What frequency are you using, and are you sure the crystal is resonating at that frequency and not at some subharmonic?


See the attached ZIP file. This is code for setting up and driving the 26C92, but can be readily adapted to the 2691 (all Philips 26xx UARTs use the same basic programming model). The code is in the Kowalski simulator's assembler format (with macros for implementing 65C816-unique instructions) but should be easy to decipher, as there is lots of commentary. Included files are:

Code:

816macs.asm            65C816 instruction macros
65c816.asm             65C816 hardware definitions
26c92.asm              26C92 hardware definitions
buffers.asm            I/O buffer definitions
config_constants.asm   26C92 register configuration constants
config_loop.asm        code that configures the 26C92 at reset
config_table.asm       data table used during 26C92 configuration
datatypes.asm          atomic data types
directpage.asm         direct page definitions
foreground.asm         foreground functions
interrupt.asm          interrupt service routine
masks.asm              various runtime mask values

In the Kowalski assembler, @ is used to define a bitwise value, which is contrary to the MOS Technology standard, which uses % for that purpose. Also note that the 26C92 has an MR0 register, as well as TxD FIFOs, the latter which are accounted for in the interrupt service routine.

An additional file, assemble.asm, assembles all of the above. I used it to verify that there were no unresolved references.


Sorry. Learning how to read between data sheet lines is a skill that develops over time. I've been perusing data sheets for some 40 years and still wonder where the authors of some of them got their education.

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

Hi BDD,

first of all, thanks a lot for this amount of information. The Appnote regarding extended data-rate seems really not to be online, although it is mentioned at many places in the WWW and in the documentation (you even can find it being mentioned in NXP documentation repository). I will have a deep look into it, thats for sure, once I get the standard baudrates working. The GTE CPU is just the predecessor of the WDC and according to the datasheet it behaves absolutely the same regarding dummy cycles.

Here a schematic of the decoding logic

/WR and /RD go to the SCC2691 (WRN and RDN) and to /WE and /OE of the RAM, however the RAM has it's /CE connected to A15. So it is guaranteed that not both are selected the same time. Regarding the CR, I have read that you have to reset the MR pointer to gain access to MR1 again after having it accessed and tried that of course.

- The SCC2691 is definitively accessed, I can set and clear Bit 3 (Power-Down) in the ACR and the oscillator nicely switches on and off
- This is what I'm checking at the moment, or what I concluded from your point, perhaps somewhere in my monitor addresses in the range $8000...$9FFF are accessed without intention (I have to admit that this SBC is running an old version of a monitor I have created and I remember that I already used this old piece of hardware and software to check other hardware some years ago, that was put to this range as well, perhaps some remains of these tests are killing me now)
- I think the 74HC138 strobes WRN and RDN at the correct time
- CEN, if the datasheet of the CPU is correct, is way ahead of WRN and RDN
- tads of the CPU is max 75ns after the falling edge of PHI2, at 2MHz there are another 175ns to go before the leading edge of PHI2 will come and qualify the /WR and /RD signals, the HCT138 has a worst case of 50ns so leaving 200ns PHI2=high with stable address, I think tas and tah of the UART are satisfied.
- I'm using a 3.6864MHz baudrate X-TAL and the scope shows that frequency as well

So next steps will be to make sure nothing else is selected and no other code is using the address range of the UART. If this does not help I will swap the CPU (I have some W65C816 spare laying around). As mentioned the power-mode bit can be toggled and it works. As next I was thinking of checking the MPI, If I understand the datasheet correct this is always read with the ISR (I was thinking to connect A4 to MPI). Yes datasheets can be very hard to understand. For me as non-native english speaking person perhaps even more and even with (almost) 40 years of experience. But you must admit there are well-written, well-structured datasheets that are a pleasure to read and learn (I especially liked the Burr Brown ones, many times they included a lot of background information and theory) and there are other datasheets.

I don't see your circuit accounting for the invalid address bus states. You need to qualify your chip selects accordingly, otherwise the 2691 will get confused. You can do that with a OR gate, whose inputs are attached to VDA and VPA and whose output drives G1 on IC1.

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

Bingo, added this OR gate and at first sight I can now write MR1 and MR2 and get the same values back. Thanks.

Hi BDD,

As always, the OR gate was only the second-last error (here a saying goes "you always only find the second-last error"). Because even without the OR, using LDA and STA absolute long should not have caused the SCC2691 to go berserk as these instructions do not have added cycles. And indeed there was another problem with my setup, the wire from the SBC to D6 of the SCC2691 was broken. Finally I can send and receive characters. Thanks for your support

Peter

That's right. And as long as you're willing to be careful with your coding practices, you can avoid any trouble from dummy cycles. There's no great mystery to the invalid states. Basically you just need to be aware that:

• when using indexed addressing to perform a read, the CPU may initially produce an address that's $100 less than the correct address

If you need to use indexed addressing, just be sure to arrange things so that that "too-low-by-$100" address doesn't hit an I/O device (at least not one whose status can be altered by a read). It's not hard to code defensively and avoid the problem that way. It can also be helpful to arrange the IO decoding so the sensitive device maps to an address that's more than $100 away from memory (at least memory that may be indexed into).


That said, I agree with BDD that it's probably worth adding a gate anyway. Although you're not likely to slip up with the coding, it could happen. And the cost of the error might be a very nasty and hard-to-find bug.

That'll work!

Here's a handy tip: if it's a 6522 you're trying to protect, and the 6522's active-high chip-select input is unused (tied high), just tie that input to VDA on the '816 instead. (No need to add a gate.) Doing it this way ignores VPA, and you will be unable to fetch code from the 6522. But that's a limitation most of us can tolerate.

cheers
Jeff

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

I actually did something similar with the IO-Decoder on my other (SBBC) computer, all IO-CS are qualified with VDA only, I never plan to execute code from my IO. But here I really forgot and in addition the SCC2691 is really counting every access and acts on it.

Yeppers. Tracking down that "nasty and hard-to-find bug" in POC V1.0 is still fresh in my mind.


Once I had patched POC V1.0, I had I/O selection rigged up so the expression VDA && !VPA applied, working on the premise that one wouldn't expect machine instructions to come from an I/O device. In POC V1.1, I simplified the logic to VDA || VPA so said qualification would cover RAM, ROM and I/O, working on the premise that if I did something stupid and tried to execute "machine instructions" from an I/O device I deserved to suffer through a crash.

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

What's counter-intuitive about this is that omitting the gate is not a compromise. IOW, the short-cut solution is actually as good as or better than if the gate were included. Here's the comparison:

• if the gate is included (ie, an OR fed by VPA and VDA, whose output, when high, is one of the conditions necessary to enable the decoder or the IO device itself), then code and data accesses will enable the IO device but dummy bus cycles will be prevented from doing so.
  
  
• if the gate is omitted (and instead we tie VDA to an active-high input on the decoder or the IO device itself), then only data accesses will enable the IO device. Code accesses and dummy bus cycles will be prevented from doing so. The assumption is that we have no interest in fetching code from the IO device.

What this means is that the OR gate has no benefit, and merely adds complexity and propagation delay, unless there's no alternative. The gate may be justified in context of a retrofit (as with cbscpe), but anyone doing a "clean sheet of paper" design stands to benefit if they can omit the gate. This may seem awkward, given that the hardware for memory decoding may share components with the hardware for IO decoding. One solution, as noted above, is to take VDA straight to the only device(s) that needs it (eg 6522). IOW introduce VDA "downstream" in the decoding chain, not "upstream." Then the upstream hardware is simplified, having no need to concern itself with VDA (or with VPA).

As a footnote, fetching code from an IO device is not an entirely absurd notion! For example, the Z-80 CPU offers various interrupt modes, and IIRC one of the modes (inherited from 8080 ?) relies on the interrupting device placing an instruction on the bus during the interrupt acknowledge cycle. Another example is my KimKlone computer, which features a Forth-ish variation of the 65xx $6C (indirect jump) instruction. During the 2 cycles immediately following the op-code fetch, the 16-bit operand is fetched from T2 of a VIA -- not from memory.

cheers
Jeff

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

The above assumes, of course, that devices other than I/O hardware don't care about false bus states that occur during the intermediate cycles of certain instructions. In my POC unit, the I/O hardware is the only area of concern at this time—both the 26C92 DUART and the 53CF94 SCSI controller will malfunction if exposed to false bus states. The Dallas DS1511Y timekeeper doesn't seem to care, nor does the SRAM I am using. The EPROM may care, but since I apply VDA || VPA qualification to all devices, I don't really know.

Something that needs to be clarified about these invalid bus conditions is that they most often happen with indexed instructions and not all hardware is affected by them. What is apparently happening is that during the next to last cycle of the instruction (e.g., cycle 4 of LDA <addr>,X), the MSB of the address bus is seemingly valid but the LSB is not, unless the indexing register contains $00. The 65C816 indicates this case by de-asserting both VDA and VPA. On the final cycle, the LSB has been corrected and at that time, VDA is asserted to indicate that the address bus is now valid.

The effect of not qualifying the addresses with VDA and/or VPA is that back-to-back accesses spaced by one Ø2 clock period may occur on the same device, but at two different addresses or in the case of I/O hardware, two different registers. With I/O hardware, such accesses may inadvertently trigger unexpected/undefined device activity and/or violate timing, both of which happen with the 26C92 (actually, all members of the Philips/NXP 26xx family), and the latter occurring with the 53CF94 (also noted with the NCR 53C94 and by inference, probably a problem with the older and slower NCR 53C90). A careful read of the device's data sheet should clarify the matter.

If your RAM and ROM don't care about false bus states, then you should be able to omit the OR gate and use VDA alone to qualify your I/O accesses. However, there may be a potential "gotcha" with latching the bank address in some cases if full qualification is not implemented.


In theory, I could write a driver that would allow execution of instructions from a SCSI device using some hinky programming that loads up to 16 bytes from disk, CD-ROM or tape into the 53CF94's FIFO and then fetches them as code. As a practical matter, I can't think of a good use for such acrobatics with what I am doing.

Along those lines, the Philips/NXP 28C94 QUART (quad UART) that I'm planning to use in POC V2. has an interesting feature whereby it can be made to place a vector value on the data bus when a channel interrupts (and can stack vectors if multiple IRQs occur). The device has a hardware input that can be used to tell it that the MPU is responding to an IRQ (hmmm...another possible use for VPB) and by means of some preliminary device programming during reset, the 28C94 will drive D0-D7 with the vector value in response to assertion of this input. I'm intrigued by this feature, as it could potentially reduce ISR activity, since the DUART would be telling the MPU which channel(s) to service—no polling necessary.

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