I'll take a look when I have some time.

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

Have you gotten any further with this? I can't find anything wrong with the code so I'm really interested in finding out whats wrong.

The code seems to be OK but there is always a chance to overlook something.

Perhaps trying it even more stepwise may help. As the VIA seems to work, I suggest the following:

1. Use VIA A, bits 0 and 1 as outputs driving a LED.
2. Use VIA A bit 7 as input for a pushbutton key.
3. Start a program which starts with bit 0 set and bit 1 reset.
4. wait for PB release (check for 0 - wait for 1 again using looooong delays between checks)
5. toggle bit 0 and bit 1 to indicate PB was released.
6. loop 4.

If this runs reliable you could insert DUART setup before step 1.
Then rerun - still working? (Perhaps DUART does somehow issues IRQs that will disturb s.th.)

If OK, then insert a single character transmission (!) between 5. and 6.
This way you can do single character shots and tie the TX control lines to either 1 or 0 until you have a transmission.

Once this works you can tie RX to TX and check how the RX control lines need to be tied until you finally can receive as well.

This would work with any baudrate (Tx and Rx clock are same). Perhaps you change the baudrate setting to s.th. very slow (300 baud). Then even a simple voltmeter could show whether there is action or not.

Good luck.

Remove the following line from the file "28L92setupTable.asi":

Code:

      .DA #DUART.CRA-DUART, #nxpcrpdd  ;CRA      leave power-down

Dunno if that is tripping you up, but the 28L92 doesn't have that function and the effect of writing the NXPCRPDD bit pattern into the 28L92's command register is undefined.

Other than that, I don't see anything that would prevent the DUART from working.

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

What timing! Right as I was picking this up again. Wow.

GaBuZoMeu: Given that I zero the IMR(disabling all IRQs from the thing), I doubt that it will be an IRQ messing with me. That said, I don't disable IRQs on the C02 itself, so it is possible.

BDD: Are you sure it doesn't have the power-down function? It does according to the datasheet I have. Is the documentation really that horrible?

Now, to get SB-Assembler working on this computer. It is not looking nice.

Does this mean the DUART is now running?

Oops! I was reading the wrong data sheet. I had several open at the same time and got mixed as to which one I was looking at.

From page 36 of the 28L92 data sheet (revision 07):


Just be careful to not write these bit patterns into CRB, as they are marked reserved.

I have removed the power-down control commands from POC V1.1's firmware, as I don't use them, and a hard reset will bring the 28L92 out of power-down mode.

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

GaBuZoMeu: No. I've switched from an aging, physically breaking down laptop to a more capable desktop, at least while I'm at home. This one has a broken install of sbasm, and I need to re-do it. Python was being a pain when I wrote that. It took about 3 reinstalls to get the settings in the installer right(Another reason I don't like Python).

I'd dual-boot this computer with Linux(things are so much nicer there), but I did it to the aforementioned laptop, and now Windows often crashes on bootup the first time around. I think that happens when I use the restart option in Windows to get back to Linux, because Windows can't get at the stuff it leaves in RAM over a restart. I'm told it does that. Very annoying how it makes the (occasionally incorrect) assumption that it's the only OS installed.

Ah, i understand. Best possible basis for reliable bug hunting...

I see it more as setting up my dev environment again.
I can't get sbasm working. I'm fairly sure it's some stupid Windows-Python interaction, because it's complaining about not being able to import things. But I've lost patience with it, so I'm going back to assembling it by hand.
I'm not debugging sbasm. I don't want to have to deal with python's structural whitespace and duck typing.

I feel like I've been butting my head against a stone wall with this DUART.

I got some slightly modified code in, and after a few bugs were removed, the 'c02 started pulling vectors in the middle of the loop! I have IRQ and NMI pointing at an RTI, and the reset goes to the beginning of the program, so it should be fine(the reset is mastered by the single-stepper), but I don't know why it's doing that. I could have accidentally entered a BRK in there somewhere, I suppose, given that I assembled it on paper and typed it into the programming software.

I'm getting frustrated with this hardware. Very frustrated. I think it's time to change tactics. I've been working from the outside, trying to get software into it. Maybe I should try getting inside it, and experiment with the DUART from the inside. I suspect that's the only way I'm going to find out what this thing is doing, or understand what I was doing wrong in the first place.
I still have the two ACIAs I bought. I think I want to put one of them on a little expansion board that connects to the VIA. That will give me enough serial port to run the keyboard and screen that I have. From there, I'll make a primitive monitor, and experiment with the DUART.

On another unrelated note, it's really hard to find a logic probe or in Australia with the suppliers I'm looking at.

LIV2: Sorry for the late reply. No. I haven't gotten the 28L92 to do its thing as a serial chip. Not yet.

EDIT: I'll have to wait until the protoboards come back in stock. Core Electronics is out of those, and they don't allow you to backorder them.

Well, the 28L92 does work and it's not at all difficult to program once you understand the general flow of things. I had essentially no trouble with getting the 2692 to work in POC V1.0—once I figured out the hardware bug involving <addr>,X addressing.

Later on, I removed the 2692 and installed a 26C92. Some changes to the driver to account for the transmit FIFOs and I was in business. Eventually, I removed the 26C92 and plugged in the 28L92. The only software change that was required was in one of the setup values used to configured the UART to use 16-deep FIFOs. Everything else worked.

What I think you need to do is:

1. Post the entire schematic for your device so we can see if there's anything amiss in the design. It could be there is something you have overlooked. The NXP data sheets are not paragons of lucidity, so you may have an inadvertent design error lurking within.
   
   
2. Post the entire firmware code you are using to run your device. Again, there could be something that you are overlooking. NXP's description of how the 28L92 operates can be somewhat opaque, which may have led to some code that the 'L92 doesn't like.

Is there an overseas supplier that you can use that won't kill you with shipping charges? You really do need a logic probe to help you sort this out. Plus it will be of value in debugging other builds in the future.

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

I think this particular chip is operational. The output port works; I tested that. I'm planning to acquire that understanding by experimenting with the thing interactively. I've not managed to do that by looking at the code. It seems like it should be simple enough, but it doesn't work when I code according to that.

At the moment, I'm trying to test each peripheral IC somewhat individually, so that code zip that I posted earlier was all the code that was in there at the time.
I'll dump the latest ROM that I was using and type up the piece of paper I assembled it on.

I'll also put together another schematic. The one earlier in the thread is not accurate to the design as it is now.

As far as a logic probe goes, not that I've been able to find. Just finding one at all is my problem.

You need to get a good logic probe so you can verify that your hardware is doing what you think it should be doing. Also, you can use the probe to watch the DUART's TxD output on whichever channel you are using. If you write a datum into that channel's FIFO you should see a brief burst of activity on TxD, since it is a CMOS output. If you see activity then it is likely the DUART is transmitting and your inability to see the results of the output are a communication error, such as improper data rate or format, or a hardware interface error between the DUART and the device with which it is communicating.


I reread the code to see if I had overlooked anything. Nothing jumped out at me.


It's important to keep your documentation up to date so you don't confuse yourself.

Lastly, once you get a logic probe you need to empirically prove your GAL is generating the correct logic outputs for all likely input conditions. I remain suspicious of the Atmel part.

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

I got one (B&K Precision DP21) via Amazon to Japan, a year or two ago. Very reasonable shipping.