Z80 Homebrew Computer - fault finding

[nockieboy]

Uh.  Whilst I'm waiting for the oscilloscope probes to arrive, I thought I'd take a look at creating a test program that will cycle the 68B50 output so there's something for me to measure with the oscilloscope at the pins/USB connector. 

I thought I'd take a shortcut and just modify the monitor program that Grant Searle created to bootstrap the Z80 system and get the serial interface up and running by throwing a JP back to the start of the INIT routine where the startup message is displayed.  This should have the effect of the Z80 monitor being caught in a loop, constantly trying to output "Z80 SBC by Grant Searle" to the USB/TTL interface via the 68B50 (and thusly allowing me to test its connections in my own sweet time.)

Problem is I can't assemble the modified source file.  There seems to be a dearth of Z80 assemblers out there and those that do exist won't touch the assembly provided on Grant Searle's site without throwing over a hundred errors.  I'm going to have to edit the raw hex file directly, but was just wondering (without wanting to open a can of worms) if any of you more experienced Z80 systems-builders have a preference or suggestion for an assembler I could use on a Windows system?

[grumpydoc]

Windows, no idea being a Linux guy for this sort of thing but the zip file with the source on Grant's site includes a dos executable of tasm - can you run that under windows (using something like dosbox if necessary).

[CJay]

Umm, they compile just fine using the TASM that's included in the NASCOM Basic Zip file from Grant's site, can you not edit the source in the text files and recompile?

*edit*

Attached modified and compiled hex which has a JP added in line 169 that JP's back to line 167 and should continually print via serial the line:

Z80 SBC By Grant Searle

I hope.


Oh, and yeah, I really need to dig out that box of Z80 chips, this is a little addictive.

[nockieboy]

Umm, they compile just fine using the TASM that's included in the NASCOM Basic Zip file from Grant's site, can you not edit the source in the text files and recompile?

Uh. Epic fail on my part there. I completely forgot about TASM in the zip file. I'm not a lover of the CLI and will actively search out 21st-century GUI-fied versions which is probably why I overlooked it.

Attached modified and compiled hex which has a JP added in line 169 that JP's back to line 167 and should continually print via serial the line:

Z80 SBC By Grant Searle

I hope.


Oh, and yeah, I really need to dig out that box of Z80 chips, this is a little addictive.

Thank you very much! That's great - will get to work on that over the weekend (as well as biting the bullet and trying out TASM)!

Yes, you must get the box out and breathe some life into a Z80 again!

[grumpydoc]

Umm, they compile just fine using the TASM that's included in the NASCOM Basic Zip file from Grant's site, can you not edit the source in the text files and recompile?

For reference they compile almost unmodified with zasm in Linux, for some reason I had to change

CP       (serBuf+SER_BUFSIZE) & $FF

to

CP       lo(serBuf+SER_BUFSIZE)


I'm still not quite sure what it did not like about the original

[nockieboy]

Umm, they compile just fine using the TASM that's included in the NASCOM Basic Zip file from Grant's site, can you not edit the source in the text files and recompile?

For reference they compile almost unmodified with zasm in Linux, for some reason I had to change

CP       (serBuf+SER_BUFSIZE) & $FF

to

CP       lo(serBuf+SER_BUFSIZE)


I'm still not quite sure what it did not like about the original

The couple of interpreters I've tried have all had a fit trying to assemble the original source code.  One (8080asm I think) I'm sure was trying to interpet the assembly as Intel code no matter what I did with the Z80 setting in it and didn't like the LD commands, but was happy with MOV instead (that's part of the Z80's compatible instruction set I'm guessing), until I found out it didn't like the Z80 register names - at which point I gave up with it. 

[james_s]

I'm pretty sure I have TASM on my CP/M system, which is another Grant Searle creation. I'm using one of the Altera FPGA boards he used and I made a custom daughterboard that holds the RAM, video and interface connectors.

[nockieboy]

That compiled nicely CJay - thanks for that. TASM is working fine in DosBox. 

[CJay]

Umm, they compile just fine using the TASM that's included in the NASCOM Basic Zip file from Grant's site, can you not edit the source in the text files and recompile?

Uh. Epic fail on my part there. I completely forgot about TASM in the zip file. I'm not a lover of the CLI and will actively search out 21st-century GUI-fied versions which is probably why I overlooked it.

Ah, it's easy to fall into that trap, FWIW, I edited the file using Notepad++ which is an excellent utility, capable of formatting, highlighting and more for an awful lot of source code correctly and there's a Z80 assembler scheme for it. 

Makes life a lot simpler.

[nockieboy]

Ah, it's easy to fall into that trap, FWIW, I edited the file using Notepad++ which is an excellent utility, capable of formatting, highlighting and more for an awful lot of source code correctly and there's a Z80 assembler scheme for it. 

Makes life a lot simpler.

Ahah, I've been using Notepad++ for years, excellent piece of software and very flexible. Wish I'd written it myself.    I'll have a hunt for the Z80 scheme, that sounds handy.

In other news, I've burnt a ROM with the test code on it and it seems to be running according to plan (at least as far as I can tell from the address and data bus activity LEDs).  Whilst installing the test ROM, I took a closer look at the wiring for the 68B50 and noticed some schoolboy errors in the USB/TTL connection.  I'd got /CTS connected to /CTS and TxD and RxD connected to their identical twins.

So I've swapped /CTS from the USB to /RTS on the 68B50 and TxD now goes to RxD and vice-versa.  I was hoping it'd all magically work after correcting those mistakes, but still nothing from the terminal.

Will have  to wait for the oscilloscope probes so I can see what activity there is (if any) from the 68B50. 

[nockieboy]

Okay, the probes arrived in the post this morning so I've tried them out - what an improvement! 

Some updated oscilloscope traces follow - I've swapped out the 7.3268 MHz crystal for a 3.6864 MHz one to slow things down slightly and had a look at the clock signal. I'd originally got it divided by 4 through two D-type flip-flops, but strange things were happening so I swapped the clock divider out and the following images were taken at 3.6864 MHz.

The issue I'm finding at the moment (and it's probably user error to do with the oscilloscope/probes, maybe) is that when the clock circuit isn't connected to the rest of the computer, I get the following clean trace at 5V:

image share

But if I connect the clock signal to the rest of the computer, the trace looks like this:

image hosting site

What am I doing wrong?

For info, the clock circuit on the breadboard looks like this:

free image uploader

I've checked the signal from the TxD pin on the 68B50 and there's a signal on that, so it looks like it's trying to send information.

[grumpydoc]

It's probably struggling to drive the capacitance/inductance of the breadboard (which is why breadboards are not great for high frequency signals).

Just to make sure it is not a probe artefact it will be worth switching to the x10 position (with a corresponding change in the vertical volts/div).

It might help to add a small resistor to the output of the clock signal buffer - 33ohms is often about right.

Was it a 74HCT04 or a 74ACT04 that you used for the oscillator?

[nockieboy]

It's probably struggling to drive the capacitance/inductance of the breadboard (which is why breadboards are not great for high frequency signals).

So any attempt to slow the clock is a good thing?  I'll try to get the clock divider working nicely again.

Just to make sure it is not a probe artefact it will be worth switching to the x10 position (with a corresponding change in the vertical volts/div).

It might help to add a small resistor to the output of the clock signal buffer - 33ohms is often about right.

Was it a 74HCT04 or a 74ACT04 that you used for the oscillator?

Righto, will get back to you on progress with the resistor and probe changes.  I'm using a 74HCT04 for the oscillator.

[grumpydoc]

Righto, will get back to you on progress with the resistor and probe changes.  I'm using a 74HCT04 for the oscillator.

OK, good.

It's the edge speed which is the problem. HCT is fairly slow, ACT is really, really fast and will cause more issues on a breadboard - it was just that I vaguely recalled you mentioning something about ACT in a previous post (and confess I was a bit too lazy/busy to go back & look).

[CJay]

Just as a matter of interest, is the output/input of the 68B50 inverted for use with a typical RS232 driver?

Now you're seeing signals on the TX line of the ACIA it could be working just fine but if you're using a TTL to USB adapter it might need inverting.

The PC should be more than fast enough to deal with data at 57600bps so you don't need the handshaking signals, hard wire them to the 68B50 perhaps.

[nockieboy]

Just as a matter of interest, is the output/input of the 68B50 inverted for use with a typical RS232 driver?

Now you're seeing signals on the TX line of the ACIA it could be working just fine but if you're using a TTL to USB adapter it might need inverting.

The PC should be more than fast enough to deal with data at 57600bps so you don't need the handshaking signals, hard wire them to the 68B50 perhaps.

No, the 68B50 IO isn't inverted - it makes no mention of inverting the signals in the notes provided by Grant Searle... So we're all on the same song sheet, here's the schematic I've been basically working to (the only changes on my design are the RAM/ROM as mine are larger chips):

photo sharing sites

And here's what I've been working to with the USB/TTL connection:

upload img

So, aside from the 5V and GND connections (which I'm using to power the SBC), I'm only using three wires from the USB connection - TxDATA, RxDATA and ~CTS. TxD is connected to RxDATA on the 68B50, RxD is connected to TxDATA on the 68B50 and ~CTS is connected to ~RTS on the 68B50.  NOTE: I'm not using resistors as I'm powering the SBC from the USB cable.

Now, I'm hoping that's connected up as it should be - it's certainly how I'm interpreting the diagrams supplied by Grant Searle.  The USB/TTL cable I'm using is identical to this one:

http://www.ebay.co.uk/itm/FTDI-FT232RL-USB-to-TTL-Serial-RS232-Cable-6-Pin-ARM-PIC-Pi-Arduino-UK-Seller-/191639851857?hash=item2c9ea01351:g:h9QAAOSwDNdVqi-X

The wire colours / connections pin-out for the TTL connector are what I'm using from that page.

If this is wrong and I should have an inverter between the 68B50 and the TTL interface, please let me know and I'll get one connected up ASAP! 

[nockieboy]

Unfortunately I haven't had any time to work on the project since my last post  , but a thought occurs to me;  initially when I powered up the SBC, it was drawing 1.2 amps. 

That would have been through the USB/TTL cable - could/would that have blown the FT232RL circuitry in the USB lead?  If so, then perhaps the SBC has been working fine (with the exception of the initial 68B50 wiring error causing the short in the first place) and the USB/TTL lead isn't allowing the PC to communicate with the SBC?

Other than getting another USB/TTL lead, is there any way I can test the existing lead to see if it's functioning correctly?

[PA0PBZ]

Other than getting another USB/TTL lead, is there any way I can test the existing lead to see if it's functioning correctly?

Just short TXD and RXD, send some characters using your favourite terminal program and see if it echos.
 

[nockieboy]

Other than getting another USB/TTL lead, is there any way I can test the existing lead to see if it's functioning correctly?

Just short TXD and RXD, send some characters using your favourite terminal program and see if it echos.

Ah, thanks PA0PBZ - yes, it's working.    At least I can exclude that from my list of possible problems.

[CJay]

What current is it drawing now and how are you powering it?

[grumpydoc]

Unfortunately I haven't had any time to work on the project since my last post  , but a thought occurs to me;  initially when I powered up the SBC, it was drawing 1.2 amps. 

That seems quite high - a 10MHz CMOS Z80 should only be 50mA, the ROM/RAM about 10mA each. Even the relatively power hungry 68B50 should only be 100mA max.

Do you know where all that current is going?

[nockieboy]

Unfortunately I haven't had any time to work on the project since my last post  , but a thought occurs to me;  initially when I powered up the SBC, it was drawing 1.2 amps. 

That seems quite high - a 10MHz CMOS Z80 should only be 50mA, the ROM/RAM about 10mA each. Even the relatively power hungry 68B50 should only be 100mA max.

Do you know where all that current is going?

No no, I was talking about when I FIRST powered the SBC up originally and realised there was a problem which I then tracked down to the 68B50 being incorrectly hooked up to the power rail (I'd originally powered it the wrong way around thanks to confusion over Vcc/Vdd/Vss labelling in the datasheet) and as a result, the whole SBC was drawing 1.2 amps.  That was before I started this post, which I did to seek help getting the system working as it still was effectively 'dead' to the laptop terminal program, even after the 68B50 'fix'.

Since correcting the 68B50 wiring error (and replacing the 68B50 with a new one as a precaution) the whole SBC is drawing a very reasonable 0.07-0.10A, which I'm powering via the USB/TTL connection, as per the USB/TTL connection diagram I posted a few comments back.

So, currently, this is where I am with the project:

* SBC powers up, drawing 0.07-0.10A via the USB/TTL connection, currently clocked at 3.6864 MHz

* SBC shows appropriate address & data bus activity for the test monitor program written to the ROM (repeatedly prints a string to the serial interface to make the 68B50 testing easier - thanks CJay) after initial power-on reset (expected behaviour)

* I had briefly tested the TxD output of the 68B50 with my oscilloscope and got a repeating signal, indicative of the test monitor program repeatedly printing the string to the serial interface - I need to go back to this when I have some time, do some more testing of the 68B50 and upload a trace of the signal to this post for thoughts

* I have checked the USB/TTL lead in isolation and it is echoing characters to the terminal, so is believed to be fully functional

To test the USB/TTL lead, after shorting TxD and RxD together, I had to turn off all flow control to get the characters I typed echoed to the terminal screen.  I've tried the same with the SBC connected to the terminal (i.e. without flow control altogether) and there's still nothing at the terminal where I would expect garbage, so I'm wondering about something CJay mentioned earlier about signal inversion - perhaps the CTS/RTS signal from the 68B50 needs inverting and is holding up communication with the terminal?   

This is my next line of investigation anyway when I get 5 minutes. 

[PA0PBZ]

I've tried the same with the SBC connected to the terminal (i.e. without flow control altogether) and there's still nothing at the terminal where I would expect garbage, so I'm wondering about something CJay mentioned earlier about signal inversion - perhaps the CTS/RTS signal from the 68B50 needs inverting and is holding up communication with the terminal?   

Even when you have the polarity wrong the PC will see a start bit and will try to come up with something. Only when the baud rate is totally off (like the sbc being much faster than the PC) it will not detect a start bit and you will see nothing. If you modify your program to send "U" (which has a nice 0101 pattern) and then have a look with the scope what the puls width is we can find out what is going wrong.

[nockieboy]

Even when you have the polarity wrong the PC will see a start bit and will try to come up with something. Only when the baud rate is totally off (like the sbc being much faster than the PC) it will not detect a start bit and you will see nothing. If you modify your program to send "U" (which has a nice 0101 pattern) and then have a look with the scope what the puls width is we can find out what is going wrong.

Sounds like a plan - thanks PA0PBZ - will try that later! 

[nockieboy]

This is probably a stupid question, but can I just swap the 7.3728 MHz crystal with the 3.6864 MHz crystal and not have to change the capacitor values in the oscillator circuit to get the 3.6864 MHz clock frequency?  At the moment I've just swapped the crystal and left the rest of the circuit.