From: "Jeff" <fyberoptic1979@...>
Aug 6, 2007
Since I sometimes don't know for sure if a particular parameter can
be use=
d with a certain Z80 instruction, I just try it anyway, and
then see if it=
compiles. If I get an error, I just check the
datasheet, and then learn =
from my mistake. Well it seems that
there's a little bug in AS80 which ca=
uses a minor issue if you try a
particular invalid command.
Basically, if=
you try to use "add hl, ix", you end up with "add ix,
ix". Same is true =
for "add hl, iy", getting "add iy, iy". I
couldn't figure out what was wr=
ong with some of my code, and testing
it in a Z80 simulator revealed what =
was going on. I manually checked
the opcode bytes too to make sure the si=
mulator might not be screwy,
but sure enough, AS80 was generating improper=
instructions in those
two cases.
Now of course, you can't actually add i=
x to hl, as the datasheet
would indicate, so my code was in error. But it=
obviously should
have errored out instead of continuing on, and using a d=
ifferent
instruction even.
I tried this both in versions 1.11 (found he=
re in the Files section),
and 1.41 (the newest on his site), same thing. =
So I contacted the
author about it, and he said he'd fix it. But I figure=
d I'd point it
out for anyone else here using that one, in case they might=
make the
same mistake I did.
Speaking of bugs, I also found that v1.41 =
is now giving me errors
when including a file of "db" strings (for the fon=
t I'm including
with the code), yet if I assemble the same code with v1.11=
, it works
fine. So I dunno what's going on there.
From: "Cyrano Jones" <cyranojones_lalp@...>
Aug 7, 2007
Since I sometimes don't know for sure if a particular parameter can
sed with a certain Z80 instruction, I just try it anyway, and
f it compiles. If I get an error, I just check the
learn from my mistake. Well it seems that
which causes a minor issue if you try a
Basically, if you try to use "add hl, ix", you end up with "add ix,
. Same is true for "add hl, iy", getting "add iy, iy". I
re out what was wrong with some of my code, and testing
lator revealed what was going on. I manually checked
oo to make sure the simulator might not be screwy,
was generating improper instructions in those
urse, you can't actually add ix to hl, as the datasheet
so my code was in error. But it obviously should
ad of continuing on, and using a different
Yeah!
=
I was trying to imagine just how this kind of mistake could
happen. I me=
an, does as80 actually have "add hl,ix" in a table
of opcodes??? I'll bet =
it doesn't.
All of the ix & iy instructions use same opcode as the
corespo=
nding hl instruction, except there is an extra byte
in front that tells cpu=
to use ix or iy instead of hl.
So, probably when as80 sees an ix anywhere=
in an instruction,
it emits the ix prefix byte, and then converts the ix t=
o hl,
and assembles it as an hl instruction. But it needs to check
if ix i=
s allowed in that position first!!!
A "DD" in front means use ix instead o=
f hl, and "FD" means
use iy. I don't think there are any valid instruction=
s with
both hl and ix, or hl and iy, and I guess that also means you
can't=
have both ix and iy either. And not all insts that can
use hl can substit=
ute ix (or iy).
"ex de,hl" is valid, but "ex de,ix" is not. AS80 does
c=
atch that! So much for my earlier theory...
ns 1.11 (found here in the Files section),
ite), same thing. So I contacted the
fix it.
That's great! And it's good to know it is still being maintaine=
d.
I remember finding a bug in a 6805 assembler that I downloaded
directly=
from Motorola. I was finding lots of "lost clusters"
on my hard drive, bu=
t I had no idea why. Windows would crash
for some totally unrelated reason=
, and when it rebooted and
checked the disk, it told me it was finding lost=
clusters.
Most of the time, it was not the program that crashed that
had l=
ost them, or even any program that I used that day.
Of course, windows wou=
ld crash quite often, and not find any
lost clusters.
After many frustrati=
ng weeks, a pattern emerged: I had used
the motorola assembler recently. I=
tested theory by using
chkdsk before and after, and sure enough, EVERY TIM=
E I ran
it, I had lost clusters.
Oh wow! I found a bug in Motorola's asse=
mbler!!! I
called them up (this was a long time ago) and told the
"tech su=
pport" guy. Turns out they knew about it already.
Turns out they knew abou=
t it for quite a while. Like 3 or
4 years. Turns out, they even had docu=
mented it, deep down
in a part of the doc that most people would never nee=
d to read.
I guess I'll just have to imagine how good it felt to hear
bac=
k that he was gonna fix your bug. :-)
(Oh yeah, right around that time Ph=
ilips had a design contest
where you could get their software and chip pro=
grammer for like
$30 bucks. I haven't used any Motorola parts since. Are
=
they even in business anymore?)
yone else here using that one, in case they might make the
I did.
rs
with the code), yet if I assemble the same code with v1.11, it works
e. So I dunno what's going on there.
What kind of error? Does it work if=
you paste the file in,
rather than include it? Or, is it a difference in =
handling
of the "db" itself?
From: "John R. Hogerhuis" <jhoger@...>
Aug 7, 2007
On 8/6/07, Jeff <fyberoptic1979@...> wrote:
Clearly you've never used a Forth assembler :-)
From: "Jeff" <fyberoptic1979@...>
Aug 7, 2007
Jones" <cyranojones_lalp@...> =
wrote:
e motorola assembler recently. I tested theory by using
d after, and sure enough, EVERY TIME I ran
I=
can only assume that they wrote the assembler in assembly as well,
becaus=
e it seems kind of unlikely to have such a problem from using
higher level=
language, as far as I can tell.
Sounds like that was back in the pre-Win2=
K days though, when Windows
would actually let you destroy and mess up thi=
ngs without stopping
you. These days most everything's all sandboxed (in =
the case of old
DOS apps), or usually only accessable via the Windows API.=
But
luckily people sometimes come up with ways to still interface with
=
hardware, such as the DLLs to write to I/O ports, letting me talk
directly=
to the parallel port and such.
There's still a charm about being able to =
still have that level of
hardware control, though, which is why I still ke=
ep Win98, as well as
Linux, on my laptop (and XP for when I actually want =
to use Windows
productively). I was working on some raw floppy drive cont=
roller
routines in assembly once and was using Win98 to test'em, especiall=
y
since it also let you drop straight into DOS mode. Though this was
als=
o about the time I realized that using floppy drives in projects
was a cra=
zy idea, when compact fash and SD were much easier to deal
with. And CF i=
s basically 8-bit IDE even, so interfacing a full hard
drive would still b=
e easier than a floppy.
!! I
ort" guy. Turns out they knew about it already.
t it for quite a while. Like 3 or
cumented it, deep down
need to read.
Yeah there's a level of disappointment to think that you've=
discovered something only to find out that it was found long before.
Bu=
t in that case, it's even more disappointing to think the company
would si=
t on it that long without bothering to fix it. Especially
when you pretty=
much need it to use their products!
=
Surprisingly so, after what you said.
work if you paste the file in,
rence in handling
It pretty much tells me "Redefi=
nition of label" for every label
following the included file. It didn't u=
sed to do this though; it
wasn't till my main file got bigger that it comp=
lained. It also
looks kind of odd, writing over some of the output text w=
hen it puts
out these errors. Like how it'll say stuff like "Reading line=
500"
and whatnot, you know. It starts spitting the error text out on top=
of it, instead of under it like a legit error.
I tried what you mentione=
d though, and strangely enough, it compiled
just fine when the data was ad=
ded into the main file. I didn't
really have enough info to go on to repo=
rt this one to the fellow,
but I think this might be enough to help him tr=
ack it down to the
'include' option somehow. I'll let him know the sympto=
ms. I'm sure
he'll feel overjoyed to be hearing from me yet again. ;)
=
From: "Jeff" <fyberoptic1979@...>
Aug 7, 2007
wrote=
:
lol I haven't, in=
fact! Should I take it that they weren't very
forgiving?
From: "John R. Hogerhuis" <jhoger@...>
Aug 7, 2007
On 8/7/07, Jeff <fyberoptic1979@...> wrote:
In Forth you just execute word after word. Either it's a number and it
goes on the stack, or it's a subroutine and it runs, consuming values
from the stack, possibly putting some back on.
So a Forth assembler typically has constants that represent the
operands. These end up as values on the stack.
SO
H L MOV,
MOV, pops the values pushed by H and L constants, Or's them together
with its base opcode, and appends the resulting instruction byte to
the dictionary.
Try some random combination of operands that it doesn't expect, and
hilarity ensues. It will put something in the dictionary, probably not
the instruction you expect though...
From: "Jeff" <fyberoptic1979@...>
Aug 14, 2007
The fellow took care of all the bugs I stumbled across and released
v1.42 =
on his site, for anyone that wants to grab the newest: (URL)
www.kingswo=
od-consulting.co.uk/assemblers/
That includes the "ADD HL, IX" bug I menti=
oned in my initial post, a
bug that was occurring when 'include'ing files =
larger than 8KB, and
an 'align' issue which was adding in more padding byt=
es than
necessary. It works like a charm for me now.
He apparently suppo=
rts several other processor types too with
different versions of his assem=
bler, such as 6502, which is cool. If
he made an 8052 version, I'd likely=
use it too!