Need Help with some UARTs

[Yuri]

Okay,

Redrew this in KiCAD.

Getting tired and haven't put in the other devices yet, but I'm hoping this is clearer what the select logic is doing. I added some hash marks next to the low level logic labels as KiCAD seems determined to put the bar right next to the border of the label itself.

[GARTHWILSON]

The programmer driver software should have the facilities to do sets, splits, offsets, etc., so that the assembler can put the vectors at $FFFA-FFFF where the 6502 expects them, and then if you use an 8KB (E)EPROM, they will occupy its highest six bytes.  The assembler shouldn't have to concern itself with that aspect.  If you figured you were going to start the reset routine at, say, $FF00, and you told the assembler to put it at $1F00 because it was going into an 8KB EPROM that would take up the highest 8K of the memory map, the vector would say $1F00, which might be down in RAM or even I/O, which wouldn't work.  Jumps would foul up too, as would accesses to tables in ROM.

[Yuri]

BigDumbDinosaur wrote:

...
What is WLA? Is that an assembler?

Yep, here's a link to the GitHub page if you'd like:
https://github.com/vhelin/wla-dx

Seems to be popular for doing custom SNES development, but it handles several different CPUs.

[BigDumbDinosaur]

Yuri wrote:

Okay,

Redrew this in KiCAD.

Have you not read the preceding comments about mixing logic types? You should not use 74-series TTL devices, e.g., 74F, in a CMOS system. In your circuit, given that it will be running at a relatively low Ø2 rate, you should use 74HC devices.

You cannot connect RDY directly to VCC. That was also pointed out to you many posts ago. RDY is a bi-directional signal and will be driven low in the event the MPU executes a WAI instruction, whether intentional or not. The way you have it would result in the MPU trying to short out the power supply. Use a 3.3K pullup resistor on RDY.

I recommend you use separate pullup resistors on NMIB, BE and SO. Doing so will allow you to use those inputs in the future without having to cut connections. A convenient way to do so is to use a SIP-style, bused resistor network, which you can also use to pull up RDY.

Also, that hookup to IRQB on the 65C02 is wasteful. One section of a 74HC08 is all that is needed. Or use one section of a 74HC11 and tie the unused input(s) to VCC.

Quote:

BigDumbDinosaur wrote:

...
What is WLA? Is that an assembler?

Yep, here's a link to the GitHub page if you'd like:
https://github.com/vhelin/wla-dx

Seems to be popular for doing custom SNES development, but it handles several different CPUs.

I don’t do GitHub. I can never make head or tails out of it.

[GARTHWILSON]

Jeff Laughton has some good diagrams about the voltage thresholds in his forum topic TTL Compatible... NOT! ( WDC ), in the head post and later on page 3 of the topic.

[Paganini]

Yuri wrote:

Okay,

Redrew this in KiCAD.

That's a much nicer schematic!

Quote:

Good question, I have not physically disconnected the IRQ line, but I have turned off interrupts on the CPU. The NMI pin is tied high, so I don't think those are the cause. Perhaps somewhat ironically I did not see this behavior until I started trying to use interrupts and was wondering why everything was behaving oddly, so I started stripping my code down to the bare bones. Which is how I ended up with just a simple program that just does a 16-bit count in the zero page.

No interrupts, no use of the UARTs, just the 16-bit count in ZP, and writes to the 65C22 to display to the LCD module.

I had almost exactly these symptoms with Blue April last year. Depending on whether or not interrupts were enabled while executing one stretch of code it would jump to random addresses. I laboriously narrowed it down to something like just two instructions - if I disabled interrupts while executing those two instructions, it was fine. The two instructions had *nothing* to do with the ISR, however. I eventually figured out it was due to power line noise; Blue April is a backplane design, and if I reorganized the card modules to get them away from the voltage regulator the problem went away.

[Yuri]

BigDumbDinosaur wrote:

Yuri wrote:

Okay,

Redrew this in KiCAD.

Have you not read the preceding comments about mixing logic types? You should not use 74-series TTL devices, e.g., 74F, in a CMOS system. In your circuit, given that it will be running at a relatively low Ø2 rate, you should use 74HC devices.

I did. I'm drawing what the circuit currently looks like, not what I will be changing it to. My goal was just to show what the logic around the address decoding is doing.

Quote:

You cannot connect RDY directly to VCC. That was also pointed out to you many posts ago. RDY is a bi-directional signal and will be driven low in the event the MPU executes a WAI instruction, whether intentional or not. The way you have it would result in the MPU trying to short out the power supply. Use a 3.3K pullup resistor on RDY.

I must have missed that. I went back and looked, but I don't see that comment. (There a lot of comments about caps and the logic families, but I don't see anything about adding pullups on the the pins?)

Anyhow, the data sheet does specify it's bidirectional, so that's my bad for not paying closer attention to that.

Quote:

I recommend you use separate pullup resistors on NMIB, BE and SO. Doing so will allow you to use those inputs in the future without having to cut connections. A convenient way to do so is to use a SIP-style, bused resistor network, which you can also use to pull up RDY.

I have some 10ks that I ordered in a SIP package that should come in soon. I have some individual 3.3Ks, but not in a SIP. The NMIB, BE, and SO pins are pure inputs though. I can definately see the case for something like NMIB or BE so one or more devices could drive the line, but SO is suggested that it shouldn't be used any longer according to the datasheet.

Quote:

Also, that hookup to IRQB on the 65C02 is wasteful. One section of a 74HC08 is all that is needed. Or use one section of a 74HC11 and tie the unused input(s) to VCC.

Well I needed a not gate for the enable line of my 74139 that's doing the address decoding. So that one IC is doing that and the logic to handle the interrupts. If I use a 7408 I'd need another IC to put a not gate in there, which was space I didn't really have on that bread board. In the future I might look at replacing the address decoding with a GAL or something. (As soon as I can figure those things out)

Quote:

...
I don’t do GitHub. I can never make head or tails out of it.

Then here's the documentation page of the assembler:
https://wla-dx.readthedocs.io/en/latest/

It isn't the greatest thing sense sliced bread, but I had it working and doing assembles of 65816 and 6502 stuff. So that's what I've stuck with for now.

[barnacle]

Yuri wrote:

BigDumbDinosaur wrote:

Yuri wrote:

Okay,

Redrew this in KiCAD.

Have you not read the preceding comments about mixing logic types? You should not use 74-series TTL devices, e.g., 74F, in a CMOS system. In your circuit, given that it will be running at a relatively low Ø2 rate, you should use 74HC devices.

I did. I'm drawing what the circuit currently looks like, not what I will be changing it to. My goal was just to show what the logic around the address decoding is doing.

A minor issue with Kikad is that the libraries are not complete, particularly with respect to some logic families. In particular, many HC parts are only in the library as LS variants. Since they are functionally (i.e. the same logic and pinouts) compatible, this isn't a problem; you can draw your schematic with LS parts.

But to avoid confusion now or later, you need to remember to relabel the parts on the schematic... This also means that the BOM generated will have the right parts listed on it. (yes, yes, I am guilty of forgetting).

Neil

p.s. the proper way to handle this issue would be to use the existing LS parts to clone into HC (or VHC, or LVC, or whichever family you're using) and use those cloned parts on your schematic. For added niceness, supply them to Kikad for inclusion. Though I suspect most of us (holds hand up) are too lazy to do that last step

[Yuri]

So HC parts arrived yesterday, and I have everything switched out. The 16550s were apparently TTL so I've gone back to the 65C51.

Looks like after just a few minutes of testing everything has stabilized. (Usually the issue shows up in a few seconds). Going to let this run for a bit while I work.

One thing I have noticed in all of this a that the RAM IC seems to run rather warm, even though I'm not driving it anywhere close to it's max speed. Is that normal or do I have something else wrong by chance?

Thanks for the help!

[BigDumbDinosaur]

Yuri wrote:

So HC parts arrived yesterday, and I have everything switched out. The 16550s were apparently TTL so I've gone back to the 65C51.

You should note that the 16550 has a design defect that prevents the proper use of the FIFOs. What you want is the 16550A or later.

Quote:

One thing I have noticed in all of this a that the RAM IC seems to run rather warm, even though I'm not driving it anywhere close to it's max speed. Is that normal or do I have something else wrong by chance?

No, it isn’t normal. The RAM in my POC V1.3 unit, which runs at 16 MHz, is stone cold. It could be you have a periodic bus contention issue.

[Yuri]

BigDumbDinosaur wrote:

Yuri wrote:

So HC parts arrived yesterday, and I have everything switched out. The 16550s were apparently TTL so I've gone back to the 65C51.

You should note that the 16550 has a design defect that prevents the proper use of the FIFOs. What you want is the 16550A or later.

Quote:

One thing I have noticed in all of this a that the RAM IC seems to run rather warm, even though I'm not driving it anywhere close to it's max speed. Is that normal or do I have something else wrong by chance?

No, it isn’t normal. The RAM in my POC V1.3 unit, which runs at 16 MHz, is stone cold. It could be you have a periodic bus contention issue.

Intresting.... The RAM I'm using is rated for 15ns, so it should be able to handle the speed fine. I did however double checking that everything is correct, and ran my homegrown memory diag test. It seems to be working fine just getting toasty.

As a test I took the same model IC (but a physically different one) and plugged it into a bread board with all lines tided low with the exception of the #WE pin which I tied high. I left the data pins disconnected, and just ran the chip that way, and it got a bit warm but nothing too bad. The moment I put a 6.3MHz clock into the #CE line it warmed right up.

I also took one of my 512Kbyte modules and did the same thing. It didn't really seem to get warm at all.

Going to pick up an IR thermometer tomorrow and check to make sure the chip is staying with in the 70C tolerance that the datasheet specifies.

[BigDumbDinosaur]

Yuri wrote:

Intresting.... The RAM I'm using is rated for 15ns, so it should be able to handle the speed fine.

Who is the RAM’s manufacturer and what is the part number?

[BigEd]

Might be relevant that the internals of a RAM are really quite complicated: lots of internal clocks, triggering off external events. There's a whole internal sequence which takes time, and which has to be launched at each point that an access might be starting. If, for example, the address lines remain stable after CE falls, that's one case. If the address lines are still settling when CE falls, that's another case, and might take more power.

[Yuri]

BigDumbDinosaur wrote:

Yuri wrote:

Intresting.... The RAM I'm using is rated for 15ns, so it should be able to handle the speed fine.

Who is the RAM’s manufacturer and what is the part number?

Renesas Electronics America Inc

71256SA12TPG

I've attached the datasheet

[Yuri]

So I think I may have noticed the issue here. The system comes up and runs, but when I tried plugging the serial cable into the 65C51 it refused to even boot. I started digging and the cheep bread board power supply I have is delivering 8.3V for some reason according to my meter. >_<

So, now to track down a better power supply.