Hello, I'm new to working with the 6502 and I have a pretty shallow understanding of electrical engineering. I wanted to take the plunge because I figured that it would be a good (but apparently frustrating!) way to learn.

I based my design very heavily on Grant Searle's simple 6502. It looks like this:



The parts list is as follows:

CPU - W65C02S6TPG-14
ROM - AT28C256-15PU
RAM - AS6C62256-55PCN
ACIA - MC68B50CP
NAND Gates - SN74LS00N
Hex Inverter - SN74LS04N
Crystal - ECS-18-13-1X

The binary flashed to the EEPROM comes from Searle's Simple 6502 page. Given that it's a 16k image and I have 32k of space, I doubled up the image.

I'm using a CP2102 for UART to USB. I have not been able to get anything to appear in a terminal session. Screen immediately terminates and Putty hangs with a solid cursor.

I'm sure there's something wrong that's glaringly obvious but I am out of my depth here. Any advice would be greatly appreciate!

You probably have one or more simple things wrong, that will not take much to fix, but could be very hard to find. I guess this is basic debugging from here, establishing what we know does work and what we are not sure of. As a comment though, the serial communications is likely to be one of the hardest things to get going so it's probably best to verify some of the more basic capabilities first.

Since the serial port is the most likely culprit I'd start with trying some simple tests here. Firstly, try swaping TXD and RXD, just in case you have them around the wrong way. Also check the baud rate, the source code should tell you what this is set to, it'll also depend on the clock running correctly. Check baud, parity, stop bits and confirm that putty has the same values as the source code specifies. I'd also try a simple loopback test to confirm everything is working on the computer side. Just connect TXD to RXD from the CP2102, open up putty and start typing, it should echo your characters back.

I'd also recheck all the connections and make sure there are no wiring mistakes. If you have a multimeter check all the 5v and GND pins and make sure they are reading correctly.

We can probably assume that the code is fine, but it would pay to check that you have burned the ROM correctly (using a verify step on your programmer) and that the code is built for the same memory map that you have (specifically the address of the 68B50.

Often people start with verifying that the CPU is working correctly. Doing this depends a lot on what tools you have available. If you have a logic probe or an oscilloscope then the first place to start is verifying the the clock is working correctly. If you don't have something that can measure this then you can probably move on to the next step which will also confirm that the clock is working.

That next step is to confirm that the CPU is working. One way to do this is to reprogram the ROM with NOP instructions, this is hex EA. If you fill the ROM with EA's then the CPU will step through the addresses. We can check this by looking at the address pins, we should see A0 stepping twice as fast as A1 and so on, so A15 should be changing the slowest. Even a multimeter may give some useful information here? R/W should remain high at all times. You will need to modify the address decode for this to work, if you have built the circuit on a breadboard this should be quite simple, just pull up the CE pin on the RAM, pull down CE on the ROM, and pull up CS0 on the 68B50.

I just noticed you are using a WDC 65C02, this may be a problem as they don't recommend using PHI2 OUT (I think). Try using the clock signal directly instead of PHI2 in the address decode.

That's quite a bit to get started with, maybe it would be helpful if you let us know what testing tools you have, such as a multimeter, oscilloscope, logic probe etc.

Welcome!


Can you make sure you really got the desired image in the top half of ROM?

Be sure to go through the 6502 primer also, which covers many aspects of making your own 6502 computer. http://wilsonminesco.com/6502primer/ . The first circuit on the last page (http://wilsonminesco.com/6502primer/potpourri.html) is even simpler than Grant's. It has parallel I/O rather than serial, but you can add lots of I/O ICs, including 6551 UARTs, without any additional address-decode logic. I'm not fond of the 6850, because it doesn't even have its own baud-rate generator onboard.

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

FWIW, I had the exact same problem last night with my SBC (search for Potpourri6502). I connected a 65C51 (even though I said I was going to hold off on serial for now...lol). It's been bothering me for days. I simply could not get it to work. Same situation...NOTHING appeared to go over the serial pins and the terminal just froze after a few seconds. At first I thought it might be the way I have the crystal connected. So I replaced that and just used my function generator directly. Same issue. After about 2 hours last night I gave up. I have had the worst luck with that 65C51.




I agree. As I got two VIA's to work flawlessly with almost no effort. Proved my design was working.




I *really* debated doing this. The primer at Garth's site uses PHI2O (pin 39, IIRC). Even though it's not recommended, I did it anyway. Fortunately, mine has worked solid for a week now. Running hours each day. I think you can get away with it if your speeds are low enough. Again, maybe I got "lucky" and have a nice stable version.



I recommend this 100% In fact, Garth's design is what I made my SBC after with only a couple slight modifications. I recommend starting with a VIA instead of serial too. That's what I did.

I just made a simple program that cycled through PORTA of the VIA and turning on some LED's. Be sure to put some massive delays between each cycle or it will be so fast that all of the LED's appear solid. Unless you run the MPU really slow (100 Hz or so) and/or single-step the MPU.

_________________
Cat; the other white meat.

Computers have no sense of humor. One single connection made improperly can be fatal to it working.

Do you have this built up on a solderless breadboard?

Have you measured the Vcc at each device?

What are you doing with A15 on the EEPROM?

How do you have PUTTY set up?

Also, Grant is using the ACIA's interrupt to control /RTS to the host and you are using the ACIA's /RTS signal. I'm not that familiar with the 6850, but will this provide proper timing if the receive interrupt is enabled and being used for flow control? It seems that /RTS is configured via the CR6 and CR5 bit. If Grant's code is not setting those bits correctly then using ACIA's /RTS would not work.

_________________
Bill

CP2102 works. I tried both the method you described and I had a router laying around that I hooked it up to. Baud rate, parity, and stop bits are set to what the source code specifies (115200 baud, 8 bits, hardware handshake, no parity, 1 stop bit)


Working on this now. Unfortunately I I don't have much in the way of equipment, but in a little bit I'll be back at my alma mater where I can probably make use of one of the oscilloscopes in the labs.


I'll check on this and report back.


Made this change on the breadboard and it doesn't seem to be the (only) issue. Thanks for letting me know though!



I appreciate the suggestions! As I mentioned, I'll double check the code matches the memory map, and soon enough I'll have access to an oscilloscope which should help make this less of a shot in the dark.

Yes it's built on a breadboard. Correct me if I'm mistaken, but I don't think there's an A15 on my EEPROM Putty is set up as follows: 115200 baud, 8 bits, hardware handshake, no parity, 1 stop bit

As to your last point, I'll have to read up on the concepts here because I'm not familiar. Thanks for your help!

If you are using a straight copy of Grant‘s code, I see no reason why you should not use Grant‘s circuit for the ACIA (68B50). It’s always best to get a known working configuration / design working first. Once you know that it works, you can then fiddle with it.

In terms of simple tools / test gear, a simple logic probe (even something made up on breadboard) is often helpful for investigating digital circuits.

Mark

I don't understand why you didn't tie the ROM's A14 to ground so your SBC would use the lower 16k of ROM.
Also, You said you built it on a breadboard. Garth Wilson mentions the problems with capacitance and inductance using solderless breadboards for building a single board computer.

Good, you can make changes easily. Check the Vcc on each chip as sometimes the contacts on these breadboards can be wonky (highly technical term).

My bad. I mean A14. I see you may have it connected to A14 from the CPU. It should not matter, but I would have connected it to ground.

Looks good. The hardware handshake though means your /RTS needs to be working as expected. It may not be as you are taking the signal from a different place than intended by the designer.

Try connecting the ACIA's interrupt as /RTS rather than the ACIA's /RTS. Probably best to leave it there too.

_________________
Bill

Should not be a real problem for a small, slow build like this as long as the contacts are good and some bypassing is used. Bypass capacitors should be connected from Vcc to ground across the chip not between the rails on the BB.

_________________
Bill

As Jack Ganssle illustrates on the oscilloscope in the short video at https://www.youtube.com/watch?v=MJpDFnRQw8s&t=1m58s (cued up), the problem is not the clock frequency, but the rise & fall time on the edges which can be very fast (like 1ns) on WDC's '02 and 74AC logic. Stray capacitance and inductance causes fast edges to produce a lot of ringing and ground bounce that can produce double-clocking, runt pulses, and interference with other signal lines that should not be affected by a transition on another. At a 1ns rise time, a one-foot-long piece of wire out in the air is longer than a half-wave antenna. If the starting corner on the wave form is sharp, you may only get away with a few inches at most.

At a minimum, wires should be as short as possible (not big arches), and ground buses should be jumped to each other in multiple places along the length of each breadboard, rather than depending on the connection to go down to the end and around to get to the next one. (That goes for power buses too.) A few here have had problems with this; so the ones who did not were probably just inside the raggedy edge of working, enjoying the luck and not knowing it.

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

Nonetheless, most breadboard designs are fine. One reason is that we tend to make synchronous designs. Generally, it's the level of signals which matters, around the instant of the clock edge. The only edge which matters, for these beginner purposes, is the clock edge: that must indeed be clean, and be seen as clean by the devices which use it. A common mistake is not to have a clean and solidly distributed power supply with decoupling at every chip.

I do understand the dangers inherent in solderless breadboard builds, and of course minimizing the length of signals and ensuring low impedance power buses are very important regardless of the speed of the devices. However, they are a really accessible and inexpensive way to prototype and are probably used, at least to some extent, by most of us. I know I use them -- a lot.

My 2nd to last build had issues and I got a lot of help from 6502.org on that one. Many of the suggestions were regarding tidying up my breadboarding. It, in the end, turned out that my problem was in clock generation and distribution. I have no doubt that the improved breadboarding helped too and that brings me to an idea.

Since solderless breadboarding is so economical, accessible and prevalent, perhaps we should start a thread on good breadbaording practices to gather our collective knowledge in one place so it's easier to find. I know there are other threads on different kinds of builds such as PCBs and wire wrapping. Maybe all these topics could even be collected in their own sub-forum on build skills.

Any merit there?

_________________
Bill

Yes!

Mark