[N8VEM: 19518] Assembly Problems

[Matthew Cook]

So I have been working for a while now off and on to learn some Z80 design
from an electronics and software standpoint. I think I posted here before,
but I was a bit too in over my head, and most of the work I had
accomplished failed ass I was taking on too much at once without enough
knowledge and testing... =(

Since then, I have done a bunch of tests so far which can be seen here on
my blog, https://z80project.wordpress.com/ . Where I am currently at is
trying to print some strings out of the UART and also trying to implement
interrupts. During my last test the circuit which can be seen in the
attached PDF worked flawlessly with a small assembly test which was to echo
the key typed in the terminal emulator back and forth from the UART. This
test was set up to make sure that I had the stack correctly initialized,
and that CALL and RET were functioning properly. The current test that I am
working on is a routine to print out a string. the code can be seen in the
attached file. The problem is that it just does not work. I am not sure
where I went wrong. It seems very straight forward. Could it be that I just
got lucky during my previous test (same hardware as in the current
schematic) to have everything working in an echo program? I feel like it
should be easier to print a string than to echo keys back and forth on the
UART, but I guess not.

Any way thanks for the help ahead of time. I don't know very much so far
since I have not gotten very far into the expanding the design to figure
out more advanced concepts. I am eventually going to try and write a
monitor program and bring my design to a PCB, but before then I want
everything to work well on the breadboard, and know enough about Z80 design
before moving it off.

[Neil Bradley]

blog, https://z80project.wordpress.com/ . Where I am currently at is trying
to print some strings out of the UART and also trying to implement
interrupts. During my last test the circuit which can be seen in the
attached PDF worked flawlessly with a small assembly test which was to echo
the key typed in the terminal emulator back and forth from the UART. This
test was set up to make sure that I had the stack correctly initialized, and
that CALL and RET were functioning properly. The current test that I am
working on is a routine to print out a string. the code can be seen in the
attached file. The problem is that it just does not work. I am not sure
where I went wrong. It seems very straight forward. Could it be that I just
got lucky during my previous test (same hardware as in the current
schematic) to have everything working in an echo program? I feel like it
should be easier to print a string than to echo keys back and forth on the
UART, but I guess not. 
Any way thanks for the help ahead of time. I don't know very much so far
since I have not gotten very far into the expanding the design to figure out
more advanced concepts. I am eventually going to try and write a monitor
program and bring my design to a PCB, but before then I want everything to
work well on the breadboard, and know enough about Z80 design before moving
it off.

I've done a ton of Z80 and 16550 work in my life and insofar as I can
tell, the code looks solid/accurate. The only thing that comes to mind is
that the DB9 connector only has tx/rx connected, and not DTR/RTS, etc...
connected up. I'm wondering if the problem is that whatever you're using
to monitor the traffic is set up for hardware flow control? If so, not
having RTS/DTR asserted (which should be connected to CTS/DCD on the other
end) is causing the issue.

The only difference between your init routine and mine is the
initialization of DTR/RTS/OUT1/OUT2, so I think your UART routines are
fine.

-->Neil

----------------------------------------------------------------------------
C. Neil Bradley - Excessive process falsely elevates the incapable and ties
the hands of the exceptional.

[Matthew Cook]

I am using Putty as my terminal emulator (no hardware flow control selected
"none") with a Radio Shack GIGAWARE USB TO SERIAL CABLE. I was not really
sure what to do with those signals so I left them out, but maybe I need
them? The errors I am experiencing are sometimes the message string doesn't
print, and sometimes it prints over and over instead of halting. I was
thinking it may have been some sort of INT or NMI trigger, so I sent those
to inf loops.

[Neil Bradley]

Post by Matthew Cook
I am using Putty as my terminal emulator (no hardware flow control selected
"none") with a Radio Shack GIGAWARE USB TO SERIAL CABLE. I was not really
sure what to do with those signals so I left them out, but maybe I need
them?

It can't hurt, and it might help. The thing is, if those signals are
floating to the host and hardware flow control (or DCD monitoring) is
turned on, it'll work intermittently.

At the very least, wire up DTR and RTS. Then you completely eliminate that
as a problem. You may as well wire up the rest of the signals, as it looks
like the MAX237 has enough inputs and outputs to deal with the other
signals.

Post by Matthew Cook
The errors I am experiencing are sometimes the message string doesn't
print, and sometimes it prints over and over instead of halting. I was
thinking it may have been some sort of INT or NMI trigger, so I sent those
to inf loops. 

I don't think that's the problem because you have a DI instruction at the
start of the code, and both !INT and !NMI are tied high.

Also, the infintie loop code is kinda strange - loading up HL with a
target address and jumping to self. What's wrong with:

INF_LOOP:
jr INF_LOOP

?

Additionally, part of the problem is likely this sequence:

START:
DI
CALL MAIN

You're doing a CALL before the stack pointer is set up. I'd do a JP or JR
instead.

What's the need for the LD A, $00 before the call to INIT_UART? It gets
set to $80 on immediate entry, anyway.

Also, are you 100% certain your RAM is working properly? You can get some
really goofy behavior if it's not quite right. Judging from the hardware,
it looks OK to me but the wire-up could have something wrong with it.

One test you can do is eliminate all call/ret sequences and see if the
code runs. That would help confirm or eliminate the RAM as a problem.

-->Neil

----------------------------------------------------------------------------
C. Neil Bradley - Excessive process falsely elevates the incapable and ties
the hands of the exceptional.

[Neil Bradley]

Post by Matthew Cook
I am using Putty as my terminal emulator (no hardware flow control selected
"none") with a Radio Shack GIGAWARE USB TO SERIAL CABLE. I was not really
sure what to do with those signals so I left them out, but maybe I need
them?

It can't hurt, and it might help. The thing is, if those signals are floating
to the host and hardware flow control (or DCD monitoring) is turned on, it'll
work intermittently.

Oh, I did spot one other problem.

The input to the inverter on the MR line to the 16550 isn't tied high, so
it's going to float. The input will float, and that'll cause the UART to
reset intermittently. Rather than wiring pin 3 of U?B to the switch, wire
it to pin 26 (reset) of the CPU.

-->Neil

----------------------------------------------------------------------------
C. Neil Bradley - Excessive process falsely elevates the incapable and ties
the hands of the exceptional.

[John Coffman]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The I/O select for the UART is not correct.&nbsp; /IORQ is not sufficient
to select a peripheral.&nbsp; Both /IORQ and /M1 are needed, since /M1 is
used to differentiate an Interrupt Acknowledge cycle from an I/O
cycle:<br>
<br>
&nbsp;&nbsp;&nbsp; I/O cycle:&nbsp;&nbsp;&nbsp; /IORQ (low)&nbsp; /M1 (high)<br>
<br>
&nbsp;&nbsp;&nbsp; IACK cycle:&nbsp;&nbsp;&nbsp; /IORQ (low)&nbsp; /M1 (low)<br>
<br>
/M1 is also used to distinguish instruction fetches from data
accesses.&nbsp; However, distinguishing these is usually not necessary.<br>
<br>
--John<br>
<br>
<br>
<br>
On 04/21/2015 08:18 AM, Matthew Cook wrote:
<blockquote
cite="mid:862b7840-ae7a-4e5a-861b-***@googlegroups.com"
type="cite">
<div dir="ltr">So I have been working for a while now off and on
to learn some Z80 design from an electronics and software
standpoint. I think I posted here before, but I was a bit too in
over my head, and most of the work I had accomplished failed ass
I was taking on too much at once without enough knowledge and
testing... =(&nbsp;
<div><br>
</div>
<div>Since then, I have done a bunch of tests so far which can
be seen here on my blog, <a moz-do-not-send="true"
href="https://z80project.wordpress.com/">https://z80project.wordpress.com/
</a>. Where I am currently at is trying to print some strings
out of the UART and also trying to implement interrupts.
During my last test the circuit which can be seen in the
attached PDF worked flawlessly with a small assembly test
which was to echo the key typed in the terminal emulator back
and forth from the UART. This test was set up to make sure
that I had the stack correctly initialized, and that CALL and
RET were functioning properly. The current test that I am
working on is a routine to print out a string. the code can be
seen in the attached file. The problem is that it just does
not work. I am not sure where I went wrong. It seems very
straight forward. Could it be that I just got lucky during my
previous test (same hardware as in the current schematic) to
have everything working in an echo program? I feel like it
should be easier to print a string than to echo keys back and
forth on the UART, but I guess not.&nbsp;
<div><br>
</div>
<div>Any way thanks for the help ahead of time. I don't know
very much so far since I have not gotten very far into the
expanding the design to figure out more advanced concepts. I
am eventually going to try and write a monitor program and
bring my design to a PCB, but before then I want everything
to work well on the breadboard, and know enough about Z80
design before moving it off.<br>
</div>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
-- <br>
You received this message because you are subscribed to the Google
Groups "N8VEM" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a moz-do-not-send="true"
href="mailto:n8vem+***@googlegroups.com">n8vem+***@googlegroups.com</a>.<br>
To post to this group, send email to <a moz-do-not-send="true"
href="mailto:***@googlegroups.com">***@googlegroups.com</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/group/n8vem">http://groups.google.com/group/n8vem</a>.<br>
For more options, visit <a moz-do-not-send="true"
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br>
</blockquote>
</body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;N8VEM&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:n8vem+***@googlegroups.com">n8vem+***@googlegroups.com</a>.<br />
To post to this group, send email to <a href="mailto:***@googlegroups.com">***@googlegroups.com</a>.<br />
Visit this group at <a href="http://groups.google.com/group/n8vem">http://groups.google.com/group/n8vem</a>.<br />
For more options, visit <a href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br />

[Matthew Cook]

@John Coffman: OK so quick solution to that is to make the E3 input of the
74LS138 tied to /M1 so the only way the chip is enabled is when /M1 goes
high and /IORQ goes low.
@neilbradley: I will wire those signals up as well. I always thought you
chose one hardware flow control pair (DTR/DSR) (CTS/RTS) to use an ignore
the others. I don't have a very good idea about the control signals
function, I will reference the datasheet.
I have no idea why I chose to do the infinite loop like that other than
because its byte-code is easy to spot in the hex file when I look it over.
Setting the accumulator to $00 was a relic from previous code. Not needed.
Nice catch I was "calling" before the stack pointer was initialized, that
is probably my problem... I didn't notice that.

I am not certain about the RAM. I was thinking of loading each address with

a number, then printing the numbers back. I have attached a test program
that should do just that, fill every 128 addresses of RAM with 1 -> 16. I
have not tested it yet, hoping someone has an easier solution to test all
of the addresses.

Pin 1 and 3 of the switch are actually physically the same point. The

symbol kind-of shows that, but I guess it could be clearer. Being a DPST
switch 2&4 are tied and 1&3 are tied.

[John Coffman]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 04/22/2015 08:48 AM, Matthew Cook wrote:
<blockquote
cite="mid:b73937d1-010e-4732-bfe4-***@googlegroups.com"
type="cite">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr">
<div>
<div>@John Coffman: OK so quick solution to that is to make
the E3 input of the 74LS138 tied to /M1 so the only way
the chip is enabled is when /M1 goes high and /IORQ goes
low.</div>
</div>
</div>
</blockquote>
</blockquote>
Yes.&nbsp; Simple circuit update.<br>
<br>
However, not related to your problem, since the board is not wired
for interrupts.<br>
<br>
--John<br>
</body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;N8VEM&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:n8vem+***@googlegroups.com">n8vem+***@googlegroups.com</a>.<br />
To post to this group, send email to <a href="mailto:***@googlegroups.com">***@googlegroups.com</a>.<br />
Visit this group at <a href="http://groups.google.com/group/n8vem">http://groups.google.com/group/n8vem</a>.<br />
For more options, visit <a href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br />

[Matthew Cook]

I have since found my problem which was actually much simpler than I
thought it would be.The wire attaching D4 to the data bus did not have
enough exposed copper and therefore was not connected causing an infinite
loop within printing strings.
Since it is very hard to continuity test on a breadboard I used two long
thin wires and exposed a lot of copper on one end which I wrapped around
each probe, and then could easily probe hard-to-get-to points on the
breadboard rats nest. My schematic and code functions perfectly now. I have
attached both if anyone is interested.

[Andy Smout]

looks good matthew! I would add a debounce cap to the reset switch to make
it cleaner, but nice work.
you should have a look at grant searle's z80 sbc as well - he mas a rom
basic conversion in his as well, might be of interest!
cheers, andy

I have since found my problem which was actually much simpler than I

thought it would be.The wire attaching D4 to the data bus did not have
enough exposed copper and therefore was not connected causing an infinite
loop within printing strings.
Since it is very hard to continuity test on a breadboard I used two long
thin wires and exposed a lot of copper on one end which I wrapped around
each probe, and then could easily probe hard-to-get-to points on the
breadboard rats nest. My schematic and code functions perfectly now. I have
attached both if anyone is interested.