EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: 255 on September 22, 2018, 01:48:59 am
-
Hi All,
I recently finished building a Z80 computer based on Grant Searle's design (32K RAM version.) However, I simply cannot get anything to display on my terminal program. I ensured proper continuity of the address and data buses as well as all the other control lines. It is not the FTDI cable, as I have tested it with another project and it functioned properly. I tried several terminal programs to no avail. I have triple checked each and every connection on the board with a multimeter and everything is wired perfectly without any shorting. I even replaced the 6850 ACIA with a 68B50 which is supposed to handle higher clock speeds. I rechecked the ROM image and that looked fine. I am running the computer off a 7.3728MHz oscillator, as per Grant's design, however, I think it may be too fast and causing timing issues. I have attached a photo of the clock signal, does it look OK? Any suggestions would be greatly appreciated.
-Adam
-
That clock looks like it may be excessively distorted, but unless you decrease the time/div by a factor of 10, and the volts/div by a factor of 5 so we can see a single cycle in detail, no one can be certain.
Also proper probing technique and scope setup is important: Both the variable time/div and volts/div controls need to be at their CAL positions. The Y offset needs to be adjusted with the input grounded to put the zero level right on a graticule line near the bottom of the screen, and you need to use a properly compensated x10 probe with as short a ground connection as is reasonably possible.
Assuming you've built it to the design at: http://searle.hostei.com/grant/z80/SimpleZ80_32K.html (http://searle.hostei.com/grant/z80/SimpleZ80_32K.html)
I think the next step would be to pull the RAM and ROM chips and patch in 8x 10K resistors as pulldowns to hold the databus low so the Z80 can only execute NOPs. You can then check that the address lines are cycling correctly in binary sequence at every chip that uses them and check the M1 instruction read cycle waveforms and timing, and the various control signals to the RAM and ROM.
If you suspect the clock is too fast, get a 3.6864MHz crystal to replace the 7.3728MHz one, and decrease the PC terminal baud rate from 115200 to 57600.
-
Thanks for the quick response.
I attached a photo of the clock signal at -x10 time/dev and -x5 volt/dev. Any better? I need to get my hands on a good digital scope with bus analyzing capabilities to check the machine cycles. In the mean time I will order up a 3.6864MHz oscillator.
-Adam
-
It doesn't look great, but it's probably passable. Since the info isn't available on the screen the amplitude is correct and it doesn't go negative, correct? Do you have a high frequency probe ground - some of the overshoot on the edges could be from the inductance of the ground lead.
Have you tried scoping any of the other pins when it's powered up to see if there's any activity even if nothing is making it to the terminal? If you're using sockets, maybe it's worth reseating some chips or connectors to see if there's just a loose connection.
-
Your scope bandwidth is greater than your clock frequency by a factor of over five so it *should* look a lot better than that. There's probably something *badly* wrong with your probing setup. Are you using a x10 probe, is it properly compensated and is your ground connection for the probe as short as possible?
For comparison, I've plotted a bandwidth limited square wave with all harmonics above the 5th removed. See attachment. Note the shape and the approx 10% ripple on the top and bottom of the waveform due to the bandwidth limiting suppressing higher harmonics.
The glich (small peak and dip) about 25% up the rising edge is particularly suspicious, as I have myself had trouble with glitches on the rising clock edge preventing Z80 instruction execution.
-
Do you have activity on the chip enable pins? Are you *sure* everything is wired properly? It only takes *one* wire in the wrong place for the whole thing to not work.
-
Could you elaborate on the high-frequency probe ground. Whats the best way to clean up how the wave form appears on the scope? Thanks.
-
Dave has some videos on good probing on scopes, but the long and short of it is that you want the shortest loop between the probing point and the probe's ground to minimize parasitic inductance, which can cause overshoot to show up which isn't actually in the signal being probed. For many probes, this involves a small spring with a wire sticking out in the direction of the probe tip as your ground instead of the normal hook attachment and the alligator lead ground that you're probably used to using.
This all being said, have you checked with the scope for activity elsewhere? If the rest of the thing isn't doing anything, then the clock could certainly be an issue, but if you're seeing activity in other parts of the circuit, then chasing down some overshoot in the clock goes down several positions on the list in terms of finding the cause.
-
Checking with the multimeter, I see a high signal on the ROM /E, a high signal on the ACIA E, and a low signal on the RAM /CS.
-
A multimeter really wont tell you much that's useful* on a Z80 system that's being clocked.
There's not much on google for a Soltec 5400 oscilloscope, but I have managed to determine its a 40MHz dual channel CRO with a delay timebase, 20mV/div Y input sensitivity (without using pull x10 mode) and a timebase that can do 1us/div or better. Its also got a Z modulation input at the back.
If you post a large sharp photo of the whole of its front panel square on, so we can see all the controls and inputs, and a separate photo of your probes, we can better advise you how to use it for probing medium speed complex digital logic circuits like your Z80. Even better, if you've got its user manual, scan it to PDF, put it on a file sharing site and post a link to it here (as it will be too big to attach)
You'd be surprised how much troubleshooting you can do on a CRO with those specs, if you feed Z80 M1 to the Ext trigger input so the display is locked to the Z80 instruction cycle, then use two x10 probes on its two Y channels to check signals around the board
* An analog multimeter or a DMM with high quality averaging on DC V ranges can tell you the approximate duty cycle of a digital waveform.
-
I found this set of videos on YT where someone is also making a GS derived Z80 computer.
https://youtu.be/UC8GLtA-59w?t=2m3s
Shows the clock signal as I would expect it to be. It doesn't look like he is using a fancy oscilloscope but I am not sure. But it is displayed on a laptop. I'll probably watch a bit more later.
-
Hi All,
I recently finished building a Z80 computer based on Grant Searle's design (32K RAM version.) However, I simply cannot get anything to display on my terminal program. I ensured proper continuity of the address and data buses as well as all the other control lines. It is not the FTDI cable, as I have tested it with another project and it functioned properly. I tried several terminal programs to no avail. I have triple checked each and every connection on the board with a multimeter and everything is wired perfectly without any shorting. I even replaced the 6850 ACIA with a 68B50 which is supposed to handle higher clock speeds. I rechecked the ROM image and that looked fine.
A *lot* of things have to be just right to allow a terminal session, i.o.w. the problem could be in any (as well as several) of many steps. I'd recommend starting small, e.g. using a zero'ed ROM/RAM and let the CPU spin through all those NOPs. Do you see then proper bus signals? And then work your way up (perhaps next step would be some trivial program which counts up on a given port etc.).
I am running the computer off a 7.3728MHz oscillator, as per Grant's design, however, I think it may be too fast and causing timing issues. I have attached a photo of the clock signal, does it look OK? Any suggestions would be greatly appreciated.
-Adam
I don't think you mentioned which chips you're actually using. The original Z80A was specified only for 4MHz, later versions (from other manufacturers) were much faster.
I've seen worse clock signals, so I wouldn't think that's the issue here, but I can't be sure.
-
As I said, I specifically don't like that glitch on the rising edge of the clock. Until the probing has been sorted out, and/or the clockspeed reduced, there's no way of telling if its a real problem, but I have seen Z80s fail to run when clocked with a glitchy rising edge.
I'm also 100% in favour of stuffing the data bus with NOPs and checking all the address and control lines right through to the ROM and RAM sockets. To do further debugging, one really needs to be able to burn ROMs with various short test programs in them, so ideally, you need a ZIF socket in the ROM socket and a compatible EEPROM to minimise the turnaround time, + a PC hosted programmer and a Z80 cross-assembler.
-
If your scope has a 1KHz scope cal point, you can use it to check that the 1KHz looks square, to confirm your scope probes are working ok and don't need adjusting (to straighten the square wave).
If you take a quick look at some of the data, address and other signal lines, are you seeing a randomish up/down pattern, probably showing the Z80 is trying to work ?
Or do you see any straight (stuck) lines (high numbered address lines, may be straight, which can be fine though), probably showing the Z80 is largely not working yet ?
Datalines are the most important, if they are "stuck", the Z80 is not doing much, yet.
What method of construction have you used, such as PCB, breadboard etc, and have you put in plenty of decoupling capacitors ?
-
The clock looks sort of clock shaped to me.
Looking at the schematic the clock is pretty simple. You might try a divide and conquer approach. Firstly can you eliminate everything downstream of U5B and measure again... if socketed remove the Z80 and the MC6850 and measure again. It's a relatively fast signal so you should have short leads.
After that I guess you need to look for life on the address bus... anything going on A0 (pin30)? Also /RD (pin21) and /WR (pin22)?
If you have life on the address bus, rd, wr then... address decoding... and then the ROM... and then the RAM?
Simple checks are also power and ground at the 2764.
-
Thanks for all the responses.
Unfortunately, my extremely obsolete Soltec 5400 scope has no documentation on the web. The front panel has no buttons or dials labeled "store" or "trigger" which means it is not a storage oscilloscope, right? I posted a picture of the front panel anyway. I ensured that all the chips have proper voltages at VCC and VSS. As far as the chips i'm using:
-Zilog Z80B CPU (data sheet says it is rated for up to 6MHz)
-CY62256L 32K SRAM
-ST M27C64A 8K EPROM
-ST EF68B50P ACIA (says it is only rated for 2MHz)
-74LS32N Quad-OR
-74F04 Hex-NOT
I have local 100nF bypass caps on the big 4 chips (CPU, RAM, ROM, ACIA) and one big 220uF board cap filtering the main power rails.
My computer is currently soldered onto perf-board. (see picture)
As far as trouble shooting the address and data buses, I will try to sneak in after hours into the EECS department at my school to use their rigols to see what kind of life i'm getting on the buses.
Thanks.
-
For the data busses, no need to get a full readout at this debug stage, just probing them like with the clock to see if they are doing anything is the important part.
That said, if your CPU is rated to 6MHz and your current clock is 7.3728MHz, we may have found a cause ;D
-
My instinct is telling me that the whole system is being overclocked, however, Grant Searle seemed positive that any Z80 or 6850 will work at this speed. I'll change out my oscillator once it arrives in the post.
-
Quick question, what is the proper way to calculate the baud rate if I swap out the 7.3728MHz crystal for a 4MHz one?
-
the Z84C0006PEC is only specified to 6,144MHz clock rate; some overclocking could work, but if you have issues, it's maybe an idea to reduce.
4MHz is not a good clock for baud rate; depending on dividers and desired rate, you could run at 6,144MHz; otherwise go down to 3.6865MHz - it's still very fast for the purpose.
-
Here are some pictures of some of the data/address lines.
photo 1: data 0
photo 2: data 1
photo 3: address 0
photo 4: address 1
The address cycle looks a bit garbled.
-
Yeah, the first picture looks a bit funky with the lower high level, but in the others you can tell that there's activity - even if nothing shows on the terminal, something is certainly going on. Using a lower clock could still potentially help, but it's much more on making sure every element is wired correctly and is operating (maybe the data and address lines are mostly good, but one line is dead, for example). Otherwise, this starts moving towards logic analyzer territory for debugging because it starts being about what instructions are actually being executed. It could be that the overclocking or some intermittent bit failure is causing it to continuously reset, which would be obvious with a logic analyzer but is hard to notice when you can only probe a data line or two at a time.
Since you see activity, I'd check other used pins for activity. If you see something on everything you expect it on, and it turns out the lower frequency doesn't help... then the debug starts getting trickier.
-
Quick question, what is the proper way to calculate the baud rate if I swap out the 7.3728MHz crystal for a 4MHz one?
I would divide the clock by two, or possibly four with a D-type flip-flip. Then your baud rates should be halved (or quartered).
-
The address cycle looks a bit garbled.
It's a very long time since I handled Z80's, but unless the address bus is tri-stating (probably not, can't remember off-hand if Z80 lets the address bus tri-state) at that time, it should be cleanly high or low. Exact voltage levels depend on if CMOS or TTL parts, I think you said it is CMOS, so should be full Vcc and Ground.
So that address line (which address line ?, are the other address lines ok ?), could be accidentally shorted to another pin or other wiring faults.
It seems too "neat" to be caused by the overclocking, but the overclocking could still be the cause.
garbled.
Garbled (unless it is the data lines going tri-state), usually means connections have ended up shorted together, or similar connection faults.
-
I seem to have got confused by your labelling of the traces.
Assuming:
photo 1: data 0
photo 2: data 1
photo 3: address 0
photo 4: address 1
is the correct ordering,
then the address lines shown seem ok at a quick glance (as you mentioned, digital storage scopes are better this this kind of work). But, there is not much activity on the data lines (doesn't seem to say what the timebase was set to ?).
I would have expected much more activity. With it looking similar to the address line traces. Assuming a big program is loaded up in it and it runs ok.
So maybe it is the overclocking, or there are problems with the Z80 accessing the memory devices.
The garbling, I was talking about, could just be because it was tri-stating the data lines, between access cycles. I mis-read you labels.
As other(s) have said. I would be tempted to check all address, data, control and chip select lines. With the scope and see if any of them look suspicious, while it is running.
It shouldn't take long to do, maybe 5 or 10 seconds per pin.
Anything which is always low, always high or is not at the correct logic high or low voltage levels (difficult to explain quickly, but tri-stating can go between logic levels, need to see control lines at same time, to see if tri-state is legit), is suspicious.
Trying without the overclocking, such as dividing the clock by 2, as suggested above by another poster is a good idea (or a lower crystal freq, as also mentioned).
-
Here is a closer look at address 0 after reset. What does this overwritten waveform entail, does it mean there is a possibility of a short, or is it something to do with the tristate logic ?
-
That waveform looks ok, as regards, faults.
In the top left hand corner of your scope, you seem to have a 0.1V cal probe connection point. I'm hoping it's around a 1KHz square wave test signal, for calibrating your probes (no manual on your scope, so I can't check this). You can make sure that the square waves look straight. If not, you may need to adjust the probes trim.
explanation here:
https://www.picotech.com/library/application-note/how-to-tune-x10-oscilloscope-probes (https://www.picotech.com/library/application-note/how-to-tune-x10-oscilloscope-probes)
It makes the waveforms, nice and sharp, for better results when doing this type of work.
You just connect the probe to the test point, if it looks a nice SQUARE waveform, fine. If not, there is usually a tiny adjuster at the end of your scope probe which can be turned (ideally with a plastic tool, to avoid metal interfering with the settings).
It is somewhat important. Otherwise you don't know if the slopes are just the scope probes being out of adjustment, or the signals really are like that.
-
Here is a closer look at address 0 after reset. What does this overwritten waveform entail, does it mean there is a possibility of a short, or is it something to do with the tristate logic ?
The OVERWRITTEN aspect of it is fine, as far as I can tell. It is because you are using a non-storage scope, so it merges lots of traces into the same place. Hence why it looks funny.
I'd suggest you use a non-storage scope, just for cursory checks, to look for dramatic faults, such as always low, always high or "funny" due to short circuits between pins (difficult to describe, it moves between the low and high levels, in a haphazard way, and should be distinguished from tri-stating. Tri-stating can be checked by looking at the control signals, to make sure the bus is suppose to be valid at that time, but is probably tricky to do with a non-storage scope).
More complicated fault analysis, ideally needs a proper digital storage scope. Which shows a fast, single shot, "picture/photgraph" of the digital signals. Rather than showing lots of repeated waveforms, on the same parts of the screen (non-storage).
A long time ago, non-storage scopes were used for complicated fault finding. Clever techniques (complicated triggering, making the signal repeat on purpose and stuff) and usage allowed this. These days, it is best to go for a digital storage scope.
-
The old-skool tricks that let you do serious debugging with a two channel non-storage delay timebase CRO were mostly based on making the CPU repeat a short sequence of instructions and generating ONE trigger pulse at a point within that sequence fed to the Ext trigger input. That meant that the scope trace X coordinate was locked to the instruction sequence timing, so you could probe a pair of signals, trace them onto tracing paper, then probe another two and repeat until you had all the signals you needed recorded on the paper, with correct relative timing. Nowadays, you'd photo them with a digital camera on a mount attached to the scope or from a mini-tripod so all the pictures are from exactly the same angle and distance.
Once you've set up a repetitive signal with stable triggering, the B timebase can be used for zooming in on a particular part of it. If you press the A INTENS button, it will use the B timebase for the sweep, and if the A timebase is set faster (lower time/div) it will bright up the trace, for a region controlled by the A timebase setting and the DELAY TIME POSITION knob just above the Ext input. Press the B button and the intensified region expands to the full width of the screen.
For the triggering from a particular logic pattern, one would typically use two banks of DIP switches, some magnitude comparators and pullup resistors on all the comparator inputs. One bank of switches would ground each bit individually of one set of the comparator data inputs, so switch open = '1' and switch closed = '0'. The other bank of switches would go between the signals being monitored for the logic pattern and the other set of comparator data inputs, so switch closed = active and switch open = Don't Care. With enough comparotors, switches etc. that would let you generate a trigger pulse on any single memory or I/O access.
However all the above is useless if you cant get the instructions to repeat fast enough to get a bright enough scope trace to read. If you were pushing the limits of trying to view a rare event, you'd have to darken the room to see the faint trace.
Nowadays, you'd stop faffing around with custom triggering a lot sooner than that, and just use it to establish that all the memory chips and I/O chips can be accessed with acceptable timing. One trick that can be used is to burn an EEPROM with an instruction sequence terminated by HALT. When it reaches the HALT, the Z80's /HALT pin will go low, and if its arranged to pull /RESET low once /HALT has been asserted for a short time, the CPU will reset and repeat the instruction sequence. You can then trigger the scope on the rising edge of /RESET.
Once you've got it basically accessing all the memory and I/O chips with acceptable timing, further troubleshooting is best done with a cheap logic analyser.
-
From the earlier pictures of the board itself I get bad vibrations from the layout. The X1 should be geographically very close to C6 and C7 (can't even see them) and the X1/C6/C7 combo very close to U5 pins 1 and 2.
Maybe you should tidy up your X1/C6/C7/U5/R3 combo to be close before moving on.
-
NivagSwerdna,
I think you misunderstand the board layout. Instead of a crystal, I used an oscillator which does not require C6 and C7. All those little 100nF caps you see on the board are local decoupling caps for the main chips. Sorry for not stating that earlier.
-
I don't have a datasheet of that device... XO-055BAT? But you are using that directly as your clock?
-
Yes, the oscillator is being used a clock source for the Z80 and the ACIA. Coincidentally, I think the oscillator may be the component causing the issues so I have a 3.6864 MHz oscillator arriving in the mail.
-
The Z80 datasheets suggest that it should be receiving a TTL level Square Wave with 50/50 duty cycle... I'm not sure that is what you are supplying.
The original design used U5 to achieve this. I'm not sure I can help any further without a schematic of your design.
-
I just realized that my oscillator operates on a 3.3V supply, not 5V. :palm: That's probably why my clock signal looks so bad. Anyway, that issue will be resolved when my 3.6864Mhz , 5V, oscillator arrives.
-
At least the Z80 chips made 40 years ago was quite picky about the clock. Looking at Z80 designs you often found some extra components driving the clock input, not just a ordinary TTL gate. Only 3.3V was out of the question.
-
I just realized that my oscillator operates on a 3.3V supply, not 5V. :palm: That's probably why my clock signal looks so bad. Anyway, that issue will be resolved when my 3.6864Mhz , 5V, oscillator arrives.
I would be worrying more about what it outputs... both in terms of shape and drive. It needs to be able to drive TTL and really it needs to be square! Good luck!
-
Incidentally, here is an example from years gone by... the pattern is very common... two gates in a 04 and in this case the clock is used in multiple locations in the circuit with a divide by 4 for the Z80A
-
Yes, a beefy bus driver (74LS367) and a low value pull up resistor. That's what it takes to drive the Z80 clock.
-
Yes, a beefy bus driver (74LS367) and a low value pull up resistor. That's what it takes to drive the Z80 clock.
Indeed. Here are a couple more...
-
So lets's consider how to get the O.P. something workable quicker than waiting for parts. IIRC, its important that the Z80 clock signal goes *really* low (max 0.45V) so 1 Vce_sat above 0V is the most it will tolerate, rises fast and cleanly, and swings rail to rail (to reach a minimum of Vcc-0.6V). This can be achieved by a LS TTL output with a 330R pullup, or with a HC CMOS output.
I suggest a 74LS74 or 74HCT74 flipflop rigged as divide by 2 to divide the existing clock (or any counter that can divide by two), feeding a 74HC or HCT gate or buffer, with several sections wired in parallel to get a good low impedance clock drive. As the O.P. says their oscillator is nominally 3.3V, two diodes should be inserted in its Vcc feed to drop the 5V rail to about 3.6V, with 0.1uF decouping right at its Vcc pin. The LS or HCT flipflops will be compatible with a 3.3V clock signal. If a LS flipflop is used and the buffer is HC, a 1K pullup on the flipflop output would be advisable.
-
The OP has a 7404 (i.e. U5) and according to the schematic this is enough to drive the Z80 (U2) and 68B50 (U3). The schematic is I venture well tried and tested.
So the only thing they really need is a XTAL and two small caps.
I would really like to see the datasheet for the XO but I cannot find anything listed for XO-555BAT
-
Is it not possible to replace all the clock circuitry with an integrated oscillator package?
Here is the data sheet of the oscillator I ordered:
https://www.mouser.com/datasheet/2/96/008-0258-0-786357.pdf (https://www.mouser.com/datasheet/2/96/008-0258-0-786357.pdf)
-
That oscillator module only guarantees an output swing from 10% Vcc to 90% Vcc when driving a CMOS load. 10% Vcc isn't low enough for logic '0' into the clock pin for many types of Z80, so for reliability, you'll probably need a 74HC buffer stage to get a true rail to rail clock.
-
Z80 DC Characteristics
Clock Input Low Voltage Min -0.3 Max 0.45V
Clock Input High Voltage Min Vcc-.6 Max Vcc+.3 V
So definitely living dangerously but you might get away with it.
-
So if I feed the output of the oscillator through an inverting buffer before it reaches the Z80 and ACIA, it should be better?
-
Yes, but add a pull up resistor (as in the examples above) to make sure the clock high is high enough. Also, if you have more than one spare gate use one for the Z80 and one for the other components.
-
You need a pullup if the buffer is bipolar TTL, (74nn, 74Snn, 74LSnn, 74Fnn) as the totem pole output stage cant drive rail to rail, but not if its CMOS (74HCnn, 74HCTnn etc.) as that will drive rail to rail. The 330R pullup recommended in the Z80 datasheet should *NOT* be used with a CMOS buffer as the approx 15mA extra the buffer will have to sink will compromise the logic '0' level and is almost certain to take it above the Z80 0.45V logic '0' threshold.
-
So if I feed the output of the oscillator through an inverting buffer before it reaches the Z80 and ACIA, it should be better?
So in the time you post it here and get an answer (or multiple so you can pick the one you like), you could just tried it, no? :-//
And do post results, it's been a long time that most of us dealt with Z80 (and I for one was hoping to never do it again).
-
CPUs of that era could be very picky about the clock - not just voltage levels, but rise/fall time as well. If you feed it through a 74HC14, that's one thing you don't need to worry about. Put it through a 74HC74 and you'll know that the duty cycle is good too. You're getting activity on the address bus, so the clock you have now is probably OK. But it's still worth doing just to be safe.
As guenthert says, pretty much everything in the system, hardware and software, has to be working for you to see data on the UART. Getting the UART going is generally the end of the "trying to get the hardware to work" stage and the beginning of software development.
The very first thing you do on a Z80 is wire the data bus to 0 (making sure that everything else that might drive it is disabled). Then have a look at the address lines. A0 should be toggling quickly, A1 at half that rate, A2 half that again, and so on. The Z80 does DRAM refresh cycles too, so it won't be quite that simple, but you'll be able to tell if it's happy. Check that the bus handshaking lines (MREQ, RD, M1) are doing sensible-looking things too.
Then give it a ROM with the simplest program you can: I like a JP back to itself, with the first byte just before a power-of-two address. That way you can use the appropriate address line as a trigger. Make sure the CPU can get to your code after reset. Make sure your reset circuit is good too. Check every pin on the chip. Is it doing what you expect it to?
Then you can start testing out I/O devices. If your program accesses them in a loop, do they get enabled? Can you make LEDs attached to outputs blink?
Once everything else is going, it's still not trivial to get a UART to talk. One bit in one config register can be the difference between working perfectly and nothing at all. And make sure you check the frequency of its clock. It's too easy to get that wrong.
-
I took out the RAM and ROM chips, and then tied all 8 data lines to GND. After inspecting each address line upon reset, I do notice that A0 toggles fast, A1 at half that speed, and so on until A7. A7, A8, A9, A10, A11, A12, A13, and A14 are all the same and all oscillate even faster than A0. Is this a problem? MREQ has this weird-looking waveform (see picture), RD looks much cleaner, and M1 looks OK. The reset circuit has been tested and functions properly.
-
I took out the RAM and ROM chips, and then tied all 8 data lines to GND.
Perfect. Reset Vector is 0000 and 00 is a NOP. Good job.
After inspecting each address line upon reset, I do notice that A0 toggles fast, A1 at half that speed, and so on until A7. A7, A8, A9, A10, A11, A12, A13, and A14 are all the same and all oscillate even faster than A0. Is this a problem?
Well A0...A6 sound good. Remove U3 as well.
-
After removing the ACIA, I still am getting the same signal on A7-A14.
Also, is it a problem that I am using a 74F04 instead of a 74HCT04 for all the inverting logic?
-
After removing the ACIA, I still am getting the same signal on A7-A14.
Also, is it a problem that I am using a 74F04 instead of a 74HCT04 for all the inverting logic?
Actually yes, maybe. 74F series is an open collector output with a minimal if any current supply when operating high, so it should have a fairly low value pull up resistor on the output, with logic 0 outputs pulling it down internally.
Check the datasheet for your chip, but I'm seeing typical operating output currents in logic high that are slightly negative.
-
The Z80 will refresh DRAM by adding refresh cycles. I don't remember the exact timing (been 35 years since I looked into this) but it has an incrementing refresh register that is output on A8 - A15 between nornal cycles. You should sample the address bus when M1 is active (machine cycle 1, opcode fetch).
-
You'll avoid a lot of confusion if you put the Z80 /M1 signal on one channel of your scope, triggering on its falling edge and adjusting the timebase to get a single cycle of it + a bit of the next cycle across the width of the screen, then probe the signal you are interested in on the other scope channel. You should be using x10 probes, so set the Volts/div to 0.2V for approx 2.5 div high waveforms. Set the 0V level for the channel showing /M1 to three divs below the centerline and 0V level for the other channel to the centerline. That way, when you change the signal you probe, you'll see its timing relationship to /M1 and can compare the timing in photos of different signals.
74F and 74AC parts are very fast (for the era) and can be difficult to use on boards without a ground plane. You *must* have local decoupling directly across the Gnd and Vcc pins right at the chip. Anything between 10nF and 100nF ceramic should do nicely.
N.B. a bad clock signal is not an all or nothing thing with a Z80. I've seen one case with a glitch on the rising edge where the address bus incremented normally as if it was executing NOPs, but the instructions in the EPROM were not being executed. There were /CS and /OE signals at the EPROM,and it was outputting data on the bus but the Z80 was ignoring it.
The fix was to apply a clock signal that was in-spec with no rising edge glitches, at which point it started executing correctly.
If you want to clock a Z80 slowly with a NE555, use a single feedback resistor from Out to the timing cap, and drive the Z80 clock from the Discharge pin with a 470R pullup resistor to +5V.
-
I finally received the 3.6864 MHz oscillator rated for 5V, and the 74HCT04 hex inverter chip. Unfortunately, after inserting the new parts into the board, it still doesn't work. But, I am getting a much cleaner clock signal. Did a bit more debugging with the scope and found that the the TX pin on the 68B50 is always high (obviously) yet, it looks like I am getting some kind of signal on the enable line. The first photo is the new clock signal and the second is the enable line on the 68B50. The /E signal looks like it has a 8% duty cycle or something.
-
Does it matter that I am using a 27C64 EPROM instead of a 2764? At this point I'm questioning everything.
-
No, the 27C64 is CMOS, you're probably not going to find much else these days. The only difference is it uses less power and the programming voltage may be different.
-
Quick question, what is the proper way to calculate the baud rate if I swap out the 7.3728MHz crystal for a 4MHz one?
Usually the baud rate is derived from the clock frequency divided by some kind of prescale value. E.g.
4MHz / 115200 = prescale of 34ish nearly 35
Depending on the hardware, you might by able to specify the prescale value, or you might only be able to choose from a preset list.
In the case of a 4MHz clock, you are going to want to concern yourself with the amount of error introduced by the chosen prescale value. A UART should be kept within low single digits of error % (IIRC < 5%). The closer to zero the better. Too much either way and for any given byte, one end of the link could miss entire bits or re-read a bit more than once, which is no good.
115200 @ 4MHz with the following prescale values gives these error percentages:
32: 7.84%
34: 2.08%
35: -0.8%
32 is out of the question, but if you can set 34 or 35 you are golden.
To determine the error rate, use this formula:
prescale * baud / clock
-
I ended up getting a 3.6864 MHz oscillator. I run it at 57600 baud since it is half the speed of my original 7.3728 MHz clock.
-
I ended up getting a 3.6864 MHz oscillator. I run it at 57600 baud since it is half the speed of my original 7.3728 MHz clock.
Did you manage to get it fully working then ?
If not, are all the logic gates/inverters now the 74HCT type ?
They use much less (DC) input current than the older TTL types, so are more likely to work, when the Z80 design doesn't use output buffers.
Also the 68B50 (if I understand things correctly) seems to be overclocked (datasheet seems to say max 1.5MHz, design seems to use around 3.6MHz or 7.2MHz, into its clock input).
One way of finding out if that is causing you problems, would be to half or quarter the clock frequency (i.e. around 1.8MHz or 0.9MHz master clock, to help diagnose the problem), with flip-flops or binary counter/dividers, and see if that makes it work, at the lower baud rates.
I.e. When you overclock (bad idea) the 6850/68B50, it is partly down to luck, if it works or not. Grant Searle seems to like the "overclocking" thing, but in practice, it can cause difficulties in making things work reliably.
-
No, my system still does not work. I have replaced the inverter chips with CMOS components but have left the OR-gates used for some of the address decoding as TTL since that is what Grant Searle used in his design. I will try to divide the clock using a flip-flop and see if the 68B50 likes that frequency.
-
No, my system still does not work. I have replaced the inverter chips with CMOS components but have left the OR-gates used for some of the address decoding as TTL since that is what Grant Searle used in his design. I will try to divide the clock using a flip-flop and see if the 68B50 likes that frequency.
That's good, but for one thing.
"Grant Searle used in his design."
He says in his text:
It is important to use 74HCT devices because:
1. They have extremely small input current requirements so many can be attached to the Z80 buses without any noticeable loading - no buffer ICs are necessary. There should be no problem in attaching a large number of devices providing the bus lengths are kept as short as possible. Quite a reasonable length can be achieved with no instability, though (see my picture below)
2. The outputs are virtually rail-to-rail (ie. 0V or 5V) unlike the 74LS devices.
3. The outputs have strong high and low currents so can drive (for example) LEDs connected to either ground or Vcc easily (must use current limiting resistors, as is normal for LEDs).
The text was mainly concerned about adding interfaces to the design.
http://searle.hostei.com/grant/z80/SimpleZ80.html (http://searle.hostei.com/grant/z80/SimpleZ80.html)
What concerns me, is that your method of construction, maybe adding a fair bit of capacitance and interference to the signals (i.e. wires and proto board). So that 74HCT series ICs, are more likely to cope with that. Compared to older TTL, which might cope, but was primarily intended for PCB construction.
If you can easily get hold of the appropriate 74HCT, then I'd suggest trying it. But leaving in older TTL devices, might be ok. But it is not necessarily worth making an order for it, because it only has a small chance of making your thing work.
tl;dr
The 68B50 possible overclocking problems, is the MOST likely thing to be causing your problems. The 74HCT thing, is just icing on the cake, and much less likely to fix your computer.
-
I've found that (the old generation, original) Z80 processors, have quite weak and sensitive (to capacitance etc) outputs. If there is too much wiring (length etc), and no (output) buffers, it tends to not work.
But if lead lengths are kept reasonable, it should work out just fine.
The 74LS TTL devices were good a long time ago. But don't cope as well as modern 74HCT (and other logic series), do, especially when prototype construction techniques are used. Because the voltages do not have to change by much (e.g. ground bounce), to mess up the logic levels. (Although HCT uses similar input voltages, it has considerably less current flowing, which usually improves things and the much bigger output voltage swing, also helps).
I would suspect that your 74LS device(s), are probably doing just great. I'm probably over-analyzing the situation, while trying to find out why your computer is not working yet.
-
I just tried the computer with a 1.8432MHz oscillator I had on hand and nothing. And yes, I did adjust the baud rate accordingly. Even though my computer never showed itself on the terminal, this project was such a good learning experience especially with all the experienced advice I got on this forum. I think I am am going to put it aside for now unless I get any sudden epiphanies. Thanks.
-Adam
-
There is one way of fixing it, but it would take a lump of time to set up and a modest $money investment.
But it might be worth the investment of a bit of time and money, as it would stand a good chance of fixing it.
Would be to buy one of the low cost logic analyzers currently on the market (I'm NOT familiar with them myself, as I have access to other equipment, which has been fine for me, so far). I think they are around the $20..$35+ mark.
It can then look at many or even all of the digital signals and take real time snap shots of them. This should allow you to see exactly what is going on, and may also be a useful learning exercise and fun.
E.g. Mini Saleae 16 Logic Analyzer USB 100M Max Sample Rate Support 1.2.10 Software U
(But ideally get advice from people who are familiar with what to get).
I beleive there are low cost "clones", available. From e.g. ebay.
https://www.saleae.com/ (https://www.saleae.com/)
(http://www.nkcelectronics.com/assets/images/logic_sw.jpg)
(https://images-na.ssl-images-amazon.com/images/I/91HXL5r1yXL._SL1500_.jpg)
-
tl;dr
So you buy or borrow one of the above (logic analyzers), and connect it up to your Z80 computer (and a USB port on a working PC or laptop).
Then by looking at all the extensive signals, you should be able to trace what has gone wrong.
They also can be useful, when fixing hard/complicated software issues.
-
Baby steps. I'm working on a Z80 system roughly based on Searle's design, and there's no way it would have worked 100% the first time. Started out with just the Z80 with the data lines pulled low - address lines cycled as expected. Added ROM, RAM, and decoding logic, along with a latch for some output leds. Tried just toggling leds and it didn't work. Pulled the ram out and it still didn't work. Ended up tracking it down to a bad quad nor chip I was using for my memory reads and writes. The ROM was never getting its chip select signal. Changed the '32 and it started working. So I wrote some more advanced code that involved calls, which requires a stack. Damn thing didn't work. Probing around, I found that the RAM's chip select was *always* being held active. Another damn bad '32 chip. Replaced that and that started working. I'm not saying that's what your issue is, but my point is that there are *so* many different chips and wires that must be perfect, it can be hard to troubleshoot an entire system. Much easier to divide and conquer. Get at least *something* working(like just the CPU, ROM, and an output latch with some leds), then build from there.