6502.org

Good afternoon!

I've finally gotten back to building 6502 SBCs. I've run into an issue that is boggling my mind. I've been trying to fix it for two weeks and I've been losing sleep.

My current design uses a WDC 6522 to bit-bang SPI to a MAX3100 UART. I've had this working without issue in the past. I'm thinking the problem must be really simple and I'm overlooking something incredibly obvious.

Using port A, I've set bit 0 to SCLK, bit 1 to MISO, bit 2 to CS, and bit 7 to MOSI. I have absolutely no problem sending the write configuration bytes, and I can send text to my PC. Apparently I have the baud rate set correctly. The issue is I can't read anything. Bit 7 is ALWAYS 0. I've scoped it and the 3100 sets the bit to 1, and I can probe that 1 at the 6522, but no matter what I do it doesn't show up when I read port A.

I've re-wired it to use port B, no dice. I wrote my transmit routine to wait until the transmit buffer is empty (indicated by the second bit returned when sending any command, I'm using read config 0, 1), but since the transmit buffer empty is indicated with a 1, it never leaves the loop. If I run it with a slow clock (approx 600Hz) and leave out the buffer empty check it transmits fine, but I can't receive anything either.

I've also hooked the 3100 to an arduino and it works without issue. I made certain that the DDR was set correctly by setting it every call to the buffer empty check, even though I'm sure it wasn't changed from initialization. I set the DDR to %01111111, marking bit 7 as input.
I also switched it to bit 6 and used bvc but I got the same result. I'm at a loss. My SBC is on a PCB, so I can't wire in a DIP 6522 (I'm using a PLCC), but I can't imagine the chip is bad - everything else seems to work. Also I didn't need that BIT instruction before. The inc instruction was enough to set the negative flag.

I also just tried manually using an LED to follow an input pin: I can flash the LED by writing to it directly, but it won't follow the input. I used LDA instead of BIT too.

Hopefully this post wasn't too scatterbrained. My migraine isn't helping. If you have any ideas, please let me know! The oscilloscope shows signals that make complete sense. I"m positive the 3100 is working. I've read the datasheet and I tried setting the ACR so latching is disabled, and I've disabled IRQs just in case they could've been an issue, both on the 6522 and the 3100. I want to implement a Rx IRQ but that's pointless right now.

I'm going to go take some Tylenol. I hope everyone is well!
Steve

Is this just a error in writing the post?  Your code wants bit 7 to be MISO (master-in / slave-out), not MOSI.

Edit:  See if my code at viewtopic.php?p=90041#p90041 helps.

Do get well.

Edit(Moved to top as it is my prime suspect issue) If your LED setup is causing you trouble I would double check the port constants so that you haven't mixed up DDR or PORT etc. For example, mixing up DDR and PORT would make the LED flash if you have set your output to 1 and toggle the DDR pin, but reading the DDR would just read the state of the DDR, whatever it was set to.

Be sure to double check the CS and clock output from the 6522 as well and that they are wired to the correct pin on the MAX3100. And that your constants DDRA and PORTA are correct.

Also note that DOUT on the MAX3100 means data out from the MAX3100 to the host, not data out to the outer world.

Iirc the state of the RTS pin might play a role as well but that is probably a later problem.

Edit2: Also the obvious, are you sure you are at the right pins on the 6522, i.e. physical leg on the chip?

Does it mater if it's a bull market or a bear market?

(Sorry, couldn't resist. )

Thanks for all of the replies! I grabbed the relevant part of the schematic and made it greyscale.
It is an error in my constant naming. I have it backwards but I don't actually reference MOSI anywhere. In my schematic I have PA1 connected to DIN and PA7 connected to DOUT, which I believe is correct. It does transmit fine.
Here are my port contants: I have also included a shot from my oscilloscope. Unfortunately it's only a two channel, so it only has DOUT and SCLK, DOUT is yellow(top) and SCLK is blue(bottom). The pulses in the centre are correct- the short blue pulse clocks past the first bit (receive buffer is empty, which is represented by a low), which when SCLK goes low causes DOUT to immediately go high, which seems to indicate I don't have to actually toggle SCLK again to get the state of the transmit buffer since it goes high right after I send SCLK low. That's not how it's coded, so the second longer SCLK pulse is like that because while SCLK is high I'm checking to see if DOUT/PA7 is high and branching. DOUT is high, but reading PA7 gives me a 0 (I took that shot with the probe on PA7). I then set CS high (which the 3100 datasheet says cancels/disregards whatever it was reading).


I hope this clarifies(?) anything I may have missed.

It isn't populated right now. It has a 3.3k resistor to 5V.

I've added the entire schematic.

Thanks!
Steve

In my POC units, I use a DS1813 to debounce /NMI.  The firmware intercepts the NMI and if it is generated while the MPU was running a RAM-based program, the program will be interrupted and the M/L monitor will take control.  It’s a handy way to break a runaway loop without losing the environment.


That adds context to what you are doing.

A couple of things, not meant to be criticism, but to make it easier to deduce what your device is supposed to do.

Devices such as U5, U6 and U7, which are generic logic with multiple but otherwise identical gates, should be drawn out as individual gates instead of as rectangles with pin designations.  For example, someone might not know that U7 is a trio of triple-input NANDs and hence would be clueless about the device’s purpose.  However, if drawn with the individual gates, that someone will immediately understand, assuming they know standard logic symbology.

Rectangles-with-pin-designations are best used for devices that are not easily drawn out as gates, e.g., a bus transceiver, or are specialized in some way, e.g., a UART.  For those, it is common practice to, if possible, put all the input pins on one side of the rectangle, all the output pins on the other side, and put VCC at the top and ground at the bottom.  Attempting to recreate the shape of the device’s package as you are doing with U1 and U11 only complicates reading the schematic and may mistakenly convey the impression that the pin-out is specific to that package (the QFP and PLCC versions of U1 and U11 have the same pin-outs).

To illustrate what I mean, here is the glue logic for my POC V1.3 unit:


It’s best to be sparing in your use of net symbols.  If possible, “wire up” things to make it easier to determine what is connected to what.  In my schematics, which often run to multiple pages, I mostly use net symbols to continue a circuit from one page to another, such as in this full schematic for POC V1.3:


By avoiding net symbols for connections on the same page, the casual reader is less likely to miss something.

I see 74F logic in there.  Is that what you are using?

Also, you have several floating inputs on U7.  That’s a no-no with CMOS logic.

Lastly, what is your memory map?

This was my plan. As you see from my missing some floating inputs, I didn't finish going through the whole thing. I can't believe I missed that. The others are wired fine. I have googled some info that has some conflicting opinions. Some say LS logic can float, others say it needs to be tied up (apparently it uses a bit less power to tie them to 5V as opposed to ground). Others say tie them up with resistors. I suppose it's best to tie them up somehow so you can be certain they aren't oscillating.
I've done descriptive gates on some schematics. To be honest I never thought I'd be sharing it with anyone. I know what the chips do so it wasn't really an issue for me, but I can definitely see how it would hamper things when looked at by others. I also just used the symbols that EasyEDA provided.

Oh, and I have no issues with constructive criticism. The reason I use netlabels liberally is I've always found it to be a huge pain to wire out a schematic and not have it look like a huge mess. I've never gotten bus wiring to work, ever. Perhaps I should try KiCad.

All of the logic is F series. I just never changed the part labels on the schematic.

Thanks for the links, I'll check them out.

Steve

I forgot the memory map.

$E000-$FFFF ROM
$D000-$DFFF IO

Everything else is RAM. I have a bunch of nice UM61512's that are fast and work great.

Steve

Hi Steve,

Unless I'm missing something, it looks like RAMOE is just the inverse of ROMOE. If that is true, then RAMOE is low for $0000-$DFFF. Your IO is also low during $D000-$DFFF. This may be why your IO reads are not working. RAMOE needs to be from $0000 to $CFFF only.

Daryl

This makes complete sense. I guess it's time to redo or rethink that part of the logic.
Is HC logic fast enough for 14MHz+ operation? One of my goals was to eventually have a small ROM read a small routine from an sdcard, jump there, disable the rom and clock stretching circuitry and copy a second stage kernel to upper RAM. I didn't want to have a ROM copy circuit (although I guess the clock stretch circuit adds enough components that only run for an instant). Basically with this setup I don't need to write a ROM every time I want to change something.

I know about AC and other logic types, I just haven't checked to see if the chips I need each have an AC variant, and I know that AC is also more susceptible to noise.

Thanks for the help, everyone. Honestly, I don't think I would have figured this out on my own.
Steve