Too late...I shipped the unit to Garth on Monday so he can change out the flop.

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

Haven't updated in a while as other issues (mostly medical) have been getting in the way. However, I did make some progress.

I shipped POC V2 back to Garth so he could change out the Ø2 clock flip-flop from a 74ABT74 to a 74AC74. The 'ABT74 could not drive Ø2 all the way to Vcc and use of a pull-up resistor to force the signal up to Vcc causes the clock waveform to become somewhat trapezoidal. With the 'AC74, Ø2 now cycles between zero and 5 volts, as it should, and a nice square wave is present. So Ø2 maladies are out of the picture.

Also, I had an issue with my Ø2 single-stepper occasionally double-clocking, which I believe was being caused by a trivial switching glitch generated by the DS1813 I'm using to debounce the pushbutton. That glitch wouldn't be of any matter with a reset circuit but was definitely not to the clock flop's liking. So I ended up redesigning the gadget to use a Schmitt trigger inverter, using the following schematic:


After initial use of the device, I increased R2 to 22K to slow down the device to compensate for my spastic hands.

With Ø2 contretemps out of the way, I was able to make some progress in actually debugging my contraption. POC V2 is not yet at the functioning state, so it's not quite time to put on the loud music, break out the beer and start the party. However, I'm working this in stages and so far, two hurdles have been cleared.

• The first hurdle was to determine if it was possible to select the QUART and access a register. The setup was to remove the MAX248 transceiver from the socket and burn a ROM that did nothing but repeatedly perform a read on the QUART's channel A receiver FIFO. I started with this ROM by single-stepped the clock and observed that when the LDA IO_ACIA+NX_RHRA instruction was executed (RHR means "receiver holding register," which is NXP-speak for the FIFO), the QUART's /CEN (chip enable) input went low, showing that selection was occurring during Ø2 low after VDA went high, which is correct logic. At that time, RWB and /RD (read data) were also high, which is also correct—/RD is generated by the CPLD and is the expression !(RWB & Ø2).
  
  On the next step of the clock, Ø2 was high, /CEN was still low and /RD was pulled, the latter correct for a read cycle. I noted at that time that the data bus had a random pattern on it (D0-D7 had $00 when Ø2 was low, i.e., the bank address), which would be logical, given that the FIFO would contain undefined content immediately following power-up. On the next clock step, Ø2 was again low, /RD was high and /CEN was high, which was correct. I had proved that I could complete a read cycle on the QUART. Following the single-step testing, I installed a 2 MHz oscillator (Ø2 = 1 MHz). and powered up. Observation of the relevant signals indicated that the QUART was being repeatedly selected and a read operation was being repeatedly performed.
  
  
• The second hurdle was to see what would happen with multiple writes to the channel A transmitter FIFO. I burned another ROM that wrote enough setup into the QUART to enable the transmitter and then repeatedly write $A5 into it. I also connected a second logic probe to the QUART's TxDA (channel A transmitter) output, which is a TTL-level signal output to the MAX248. TxDA is supposed to be high (mark condition) when the transmitter is enabled and quiescent, which it was right after reset. Again, I manually cycled the clock while watching /CEN and /WD (write data) as the MPU progressed.
  
  When the STA IO_ACIA+NX_THRA instruction was executed and while Ø2 was low, VDA was high, RWB was low, /WD was high—/WD is generated by the CPLD and is the expression !(!RWB & Ø2)—and /CEN went low. All of that was correct. On the next clock step, Ø2 went high and /WD went low. At that time, I saw a brief burst of activity on the logic probe connected to TxDA, which meant the QUART had transmitted something. The pattern on D0-D7 was %10100101, which is $A5, the test value. Following the activity, TxDA returned to the mark condition, as it should.
  
  I then replaced the single-stepper with the oscillator and powered up. There was continuous activity at TxDA for a few seconds, which would have corresponded to the write some data and halt code I had burned into the EPROM. Following that test, I put the MAX248 back into the socket and connected POC V2 to my console terminal, with my RS-232 tester in the circuit so I could watch the signals. At power-up, all RS-232 signals, other than RI (ring in, which is not used), showed voltage present. After releasing the reset line, I saw a burst of activity on the tester's RD indicator (receive data—the tester was "backwards" in the circuit, so RD is from the terminal's perspective), indicating something was being transmitted to the terminal. The terminal's display, which had previously blanked from a "no activity" timeout, woke up. However, there was no other evidence of data being received, even though $A5 should have caused the terminal to display % (italicized percent).

Based upon the above testing, it appears my CPLD logic has some degree of correctness to it, the QUART is not comatose and I can send something to the console terminal. I'm inclined to think that right now I must have a baud rate error, formatting error, or both, in the serial data stream. It could be I've got the wrong setup in the QUART, as it is difficult for me to read the data sheet. That said, I was using values that work on the 28L92 in POC V1.1, since all of these NXP UARTs are supposed to be programatically similar. In fact, the 28C94 data sheet all but says it's two 26C92s in one package, and I have successfully run the 26C92 in POC V1.1.

The other possibility is the bit patterns for baud rate and format are being written into the wrong registers, either due to a register decoding logic error or due to a typo somewhere in one of the assembler INCLUDE files that contains the 28C94 data.

Since software is easier to fix than hardware and I have no reason to further suspect hardware at this point, it's time to fire up the assembler.

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

I'm stumbling around with this, partially because the 28C94 data sheet has errors and inconsistencies, and is not well organized. I been trying to find other documentation on the part or some application notes, but so far the Internet has failed me. Almost makes me wish I had used the (more complicated) 28L194, whose data sheet is an easier read and is better organized. However, the 28L194 operates on a synchronous bus, which I'm not sure can be properly implemented with the 65C816.

At one point during the design of POC V2, I had considered using two 28L92s instead of the single 28C94, but nixed that idea because I don't have enough outputs on the ATF1504AS CPLD. Also, there was the matter of PCB real estate...

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

You might just have to go to putting parts on both sides!

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

Yeah, right. Even if I could, I'd still have insufficient pins on the CPLD to wire it up. All I/O chip selects are spoken for.

I'll tell you...I'm really tempted to whip up a design using the ATF1508AS and two (maybe four) 29L92s. Those UARTs work great and with 16 deep FIFOs, they don't bang away at the MPU with IRQs like some other UARTs. However, POC V2 has to be made operative before anything new can be designed. It's a rule around here!

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

I'm confused; the 68K DTACK-mchanism is classed as an asynchronous bus, but busses like the 6502 are considered synchronous? If the 28L194 operates in a 68K style, it can probably be made to work by delaying the Chip Select until after Read or Write have been asserted. I used this trick successfully with the SC16C654 on my board which I configured in 68K mode because it required less glue pins.

Regarding the 28C94 in your board: Have you tried the simplest of all interactions with the 28C94? It looks like you should be able to toggle the general purpose output pins with just a few register configurations.

IOPCRA = 01000000

Then toggle bit 5 of OPRab.

I've never used this part and am just reading the datasheet like the next guy but it looks like it should work? Could you point out some of the inconsistencies? Maybe we can help "resolve" them.

If I was a betting bloke I'd put at least $5 on your problem being down to the baud rate config or something similar.

BTW regarding your test pattern. Why not just use a 7 bit ASCII character? My favourite is 0x2A, the asterisk. Then when it works you can say you are "seeing stars". This might be an indicator that I need to get out more.



Both these things have constrained my designs too. It's jolly irritating.

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

A DTACK mechanism is not required to use the 28L94, but its clock input must be driven at some multiple of the X1 clock. The timing diagram looks tricky and that was part of the reason I dismissed the idea for the time being. There is also an eight-channel version with the same clocking requirements.

In any case, x86 mode is somewhat easier with the 65C816, due to the independent control of the read/write functions. In 68K mode, read/write works along the line of 65xx silicon, which make qualifying a read against the Ø2 clock impossible without extra silicon—unlike the 65C22, for example, the 28C94 doesn't know that the data bus is not data during Ø2 low.


I haven't, as I can select the device and read and write it. This has devolved to a serial interface problem, and as I know the logic levels on that side of the device are correct, it is a problem of configuration.


Go to page 17 for an example. In the right column, the data sheet abruptly goes from describing the layout of the clock select register to the command register, obviously an editing error. Also, the baud rate table (table 6) is a bit confusing, as it mentions BRG RATE = LOW and BRG RATE = HIGH (BRG meaning baud rate generator), but there is no immediate clue as to which register is used to set the baud rate generator rate (it's register %101101). Furthermore, there is are registers %101110 and %101111 listed in table 1 on page 6, but no satisfactory explanation for what they do.


I said as much in my earlier post.


I did switch the test pattern to a group of three seven bit ASCII characters.

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

It looks like they are going from describing the CR bits 7:4, then talking about the CSR bits 7:4 then bits 3:0 and then going back to the CR bits 3.. 0. It is sloppy indeed. And there doesn't seem to be any context for describing one register within another.



It looks like it's register 101101, hex 00 for LOW and hex 01 for HIGH? I'm not sure what's confusing there.



Details look thin but my guess is this is a "write any value" and it will flip the divider on or off based on where you write. I guess that's one way to avoid excessive logic. Interesting to see what the default might be, but my guess would be to not touch these ones.

I find most NXP datasheets terse and difficult to chew through, but this one doesn't seem excessively bad, that crappy CR, CSR, CR mistake notwithstanding.

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

Given that the values written into some registers are influenced by the values written into other registers, not keeping that information in context is just plain inexcusable.

None of the NXP data sheets are particularly well-written. This one seems to have set a new standard in that regard. The one for the 26C92 was not very good, especially in describing how to set up the FIFO interrupt level. The 28L92 data sheet is worse, since there are more options, but I was able to figure it out via experimentation. So far, this one has me buffaloed.


...as I noted in my rant.


We don't actually know that the two possible values are hex—there is no radix symbol, although one could infer that it's hex due to the format.


Unfortunately, it's write-only, so no obvious way to determine what the default is at reset.


This one is worse than some of the other NXP data sheets I've read.

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

It is. I wrote %00000001 into that register to select the right baud rate table. That same function is controlled by bits 0 and 2 of the MR0 register in the 26C92 and 28L92.


I wrote into register %101110, which is tersely described as "Set X1/CLK divide by two (use when X1 is < 4 Mhz)". As I am using a 3.6864 MHz oscillator to drive the X1 clock, it would seem that writing into that register would be appropriate. This register and the one that follows it are strange, as nothing in previous data sheets mentioned setting anything to account for the X1 frequency (up to 8 MHz is supported by the 26C92, 28L92 and 28C94). The other logical X1 frequency would be 7.3728 MHz, which would effectively double all the standard baud rates.

Anyhow, these changes succeeded producing some output and my simple test loop now writes a series of characters to the terminal screen, albeit slowly, despite the interface running at 115.2 Kbps. At least it's some progress.

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

That reads like it should be "> 4Mhz". Hmm. Are 7.328MHz crystals common?



Weee... She lives. She's just on life support at the mo.

When you say slowly, do you mean each character appears with a gap, but the baud rate at the terminal end is 115.2K? If so, this is odd indeed and could only be that your polling for FIFO empty is being delayed somehow?

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

As I said, the data sheet leaves something to be desired in clarity and accuracy.

7.3728 MHz is a standard oscillator frequency. Mouser lists about 160 stock items in that frequency.


She's off life-support. Writing into register %101111, which is described as "Set X1/CLK Normal", did the trick. The data sheet is messed up, it seems, in describing the X1/CLK divide function. Now I can hammer away as fast as the '816 can write into the FIFO and a full-speed display occurs, just like on a real computer.

Adding insult to injury, I changed my test code to copy the test character string from RAM to ROM and then used the RAM copy to write it repeatedly to the terminal. In fact, I did this from addresses $002000, $00D800, $01D800 and $0FFFF0, proving that memory decoding is working as it should. That last address is decimal 1,048,560, 16 bytes shy of POC V2's 1 MB address limit. I also tested with a 30 MHz oscillator on board, which runs Ø2 at 15 MHz. Works like a charm!

Now I have to get busy and slap together a BIOS.

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

This is a much belated CONGRATULATIONS! Very, very, cool!

A question about your BIOS and your QUART driver. Appreciate that this is probably OT. I assume you are planning on an interrupt-based driver. Have you implemented transmit interrupts in your previous BIOS? I have really, really struggled to get my head around this topic in my project. Rx interrupts are conceptually simpler - you just get an interrupt when you have some data to read. I have implemented these and am very pleased with the result; tasks waiting for an interrupt do not get scheduled until they Rx something. But transmit interrupts need some mental gymnastics I can't quite manage - your main code is interrupt when what has been sent has finished sending, but it is the main code which started the sending in the first place?! I just can't quite get this working. Any advice?

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

Thanks!


Yes. In fact, in POC V1.1, I have the 28L92 set up for 16 byte FIFOs, and the interrupts only come when the receiver FIFO is completely full or the transmitter FIFO is completely empty. That greatly reduces the frequency of IRQs.


Actually, it's fairly simple once it is given some thought.

You start out with the transmitter or its IRQ disabled. A flag¹ is set somewhere in memory to tell your driver that TxD is disabled. That's the initial setup, which should occur at power-on or reset.

When something has to be transmitted, the foreground part of your driver buffers the byte and then examines the TxD disabled flag. If TxD is disabled, the foreground clears the flag, enables the transmitter (or its IRQ) and returns to the caller. Shortly after enabling TxD, the UART will generate a TxD IRQ. If TxD is already enabled the foreground doesn't have to do anything and just returns to the caller.

Your interrupt service routine (ISR), after determining that an IRQ was caused by the UART's transmitter, would read a byte from the transmit buffer and write it to the UART. In the case of UARTs with FIFOs, such as the 28L91 or 16650, you would repeat the read-buffer/write-UART loop until either the UART says its TxD FIFO is full or the TxD buffer becomes empty.

If the UART says its FIFO is full your ISR simply terminates. Later on, the UART will again produce a TxD IRQ when the FIFO has emptied. The steps described in the previous paragraph would be repeated.

If the buffer becomes empty, you disable TxD or its IRQ and set the flag saying so, as was done during initialization. Following that, your ISR would terminate.

Hope this description helps to clear it up.

———————————————————————————————
¹In the case of a multi-channel UART, a single byte can be used as the TxD disabled flag, using individual bits to represent each transmitter in the UART.

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

Congratulations with POC 2 getting to work, and lots of fun with programming!

_________________
Marco