16 Apr
2006
16 Apr
'06
8:51 a.m.
I've got a hex dump here of an Assembler/Text Editor for the 8080,
called (IIRC) ATE. It's what I used on my first computer (8080 S100 8k
+ KC tape). It's about 4k, so I had 4k for source + object, or it could
work as a 2-pass assembler reading the source off tape.
Does anyone know about this? Is it of interest to anyone? I could
either type it in, or scan the listing for someone else :-) The code
would need patching for console & tape I/O, and I don't have any
documentation on how to do this, or even how to use it, but it can't be
too difficult. Forgive me, it's been almost 30 years!
LJW
I've been quiet lately, see http://www.ljw.me.uk/porsche for an idea
why :-(
--
Lawrence Wilkinson lawrence at ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360
16 Apr
16 Apr
9:03 a.m.
Lawrence Wilkinson wrote:
I've got a hex dump here of an Assembler/Text
Editor for the 8080,
called (IIRC) ATE. It's what I used on my first computer (8080 S100 8k
+ KC tape). It's about 4k, so I had 4k for source + object, or it could
work as a 2-pass assembler reading the source off tape.
Does anyone know about this? Is it of interest to anyone? I could
either type it in, or scan the listing for someone else :-) The code
would need patching for console & tape I/O, and I don't have any
documentation on how to do this, or even how to use it, but it can't be
too difficult. Forgive me, it's been almost 30 years!
I have the sources for the original tools that came with
ISIS-II someplace -- if there's interest.
If all you have is a hex dump, I can disassemble it for you
to give you a better place from which to start patching.
--don
9:14 a.m.
Don Y wrote:
I have the sources for the original tools that came with
ISIS-II someplace -- if there's interest.
If all you have is a hex dump, I can disassemble it for you
to give you a better place from which to start patching.
--don
I would definately be interested in the ISIS-II cusps sources. Do you
have it in a form that can be e-mailed? If it is on an ISIS-II
compatible medium I could convert it to something "modern" if desired.
Thanks,
Dave
9:28 a.m.
Dave Mabry wrote:
Don Y wrote:
From what I recall, some tattered 8.5x11 sheets of paper :-(
(Hey, it's ~30 years old... bits of paper don't fare well :< )
I'll start a search but it may take a while. It could be
in several different places (some of which are cross country).
--don
I have the sources for the original tools that came with
ISIS-II someplace -- if there's interest.
If all you have is a hex dump, I can disassemble it for you
to give you a better place from which to start patching.
--don
I would definately be interested in the ISIS-II cusps sources. Do you
have it in a form that can be e-mailed? If it is on an ISIS-II
compatible medium I could convert it to something "modern" if desired. 
10:15 a.m.
On 4/16/2006 at 4:51 PM Lawrence Wilkinson wrote:
Does anyone know about this? Is it of interest to
anyone? I could
either type it in, or scan the listing for someone else :-) The code
would need patching for console & tape I/O, and I don't have any
documentation on how to do this, or even how to use it, but it can't be
too difficult. Forgive me, it's been almost 30 years!
I used something like that before I had the luxury of a diskette drive on
the MITS Altair. But I don't recall a 2-pass mode from paper tape, just a
BASIC-type editor that read the source into memory (or created it); each
statement had a line number. Assembly in place--i.e. no intermediate
binary output was the normal mode.
It wasn't a MITS-original product, but i think I got it from a friend who
had an IMSAI 8080. It may have even come from something like a Processor
tech box. When I got my first disk, I dropped it like a hot potato.
Cheers,
Chuck
12:04 p.m.
Chuck Guzis wrote:
I remember a 8080 editor/assembler book with a 4k hex/octal listing.
It was so primitive that instructions longer than 1 byte, had to be
assembled as 2 and 3 byte instructions.
Does anyone
know about this? Is it of interest to anyone? I could
either type it in, or scan the listing for someone else :-) The code
would need patching for console & tape I/O, and I don't have any
documentation on how to do this, or even how to use it, but it can't be
too difficult. Forgive me, it's been almost 30 years!
I used something like
that before I had the luxury of a diskette drive on
the MITS Altair. But I don't recall a 2-pass mode from paper tape, just a
BASIC-type editor that read the source into memory (or created it); each
statement had a line number. Assembly in place--i.e. no intermediate
binary output was the normal mode.
1:31 p.m.
On 4/16/2006 at 1:04 PM woodelf wrote:
I remember a 8080 editor/assembler book with a 4k
hex/octal listing.
It was so primitive that instructions longer than 1 byte, had to be
assembled as 2 and 3 byte instructions.
Do you want to rephrase that? I do recall a simple assembler that did not
implement alpha constant strings longer than 2 bytes (as a DW). To code a
long string you had to do something like this:
DW "EH"
DW "LL"
DW " O"
DW "OW"
DW "LR"
DW " D"
Very tedious!
Cheers,
Chuck
1:45 p.m.
Chuck Guzis wrote:
Do you want to rephrase that? I do recall a simple
assembler that did not
implement alpha constant strings longer than 2 bytes (as a DW). To code a
long string you had to do something like this:
DW "EH"
DW "LL"
DW " O"
DW "OW"
DW "LR"
DW " D"
Very tedious!
Cheers,
Chuck
More like:
JMP
DW THERE
THERE
; rest of code
2:01 p.m.
> Do you want to rephrase that? I do recall a
simple assembler that did not
> implement alpha constant strings longer than 2 bytes (as a DW). To code a
> long string you had to do something like this:
>
> DW "EH"
> DW "LL"
> DW " O"
> DW "OW"
> DW "LR"
> DW " D"
I seem to rememebr the cassette-based editor/assembler I had for the
TRS-80 Model 1 was like that. I am not even sure it supported ASCII
characters as constants, you may have had to enter everything in Hex
>
> Very tedious!
[...]
More like:
JMP
DW THERE
THERE
; rest of code
I think (although I don't have it), the assembler for the Philips P850
was like that (you had to put the second word of 2-word instructions as a
constant). The assemblers for the other P800 series machines (which had a
lot more memory) did it more as you'd expect.
-tony
2:18 p.m.
Chuck Guzis wrote:
Do you want to rephrase that? I do recall a simple
assembler that did not
implement alpha constant strings longer than 2 bytes (as a DW). To code a
long string you had to do something like this:
I found the book on the web after a
google search.
TEA, an 8080/8085 Co-Resident Editor/assembler
I can't find any used copies of the book however.
On the lighter side, I found a on-line archive of DTACK GROUNDED.
http://linux.monroeccc.edu/~paulrsm/dg/dg.htm
Interesting reading -- Nov 1981 $104 for a 4 MHZ 68000 CPU.
4:09 p.m.
On Sunday 16 April 2006 05:18 pm, woodelf wrote:
Chuck Guzis wrote:
Published by Sams? I have that. In fact, it's a two-volume set, though
apparently there's some difference in the editions I have or something as the
covers to the two are quite different.
They did some weird things to mnemonics in there.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Do you want to rephrase that? I do recall a
simple assembler that did
not implement alpha constant strings longer than 2 bytes (as a DW). To
code a long string you had to do something like this:
I found the book on the web after a google search.
TEA, an 8080/8085 Co-Resident Editor/assembler
I can't find any used copies of the book however. 
17 Apr
17 Apr
4:03 a.m.
At 03:18 PM 4/16/06 -0600, you wrote:
Chuck Guzis wrote:
I believe that I have a copy that I bought off of E-bay. I went and
looked for it but couldn't find it (I have WAY too many books around here!)
However I did find a book on DBUG by Titus, Titus, Rony and Larsen. It's
one of the Blacksburg series of Bugbooks. I've never used it but it says
that it can run in 1k!
Joe
Do you want to rephrase that? I do recall a
simple assembler that did not
implement alpha constant strings longer than 2 bytes (as a DW). To code a
long string you had to do something like this:
I found the book on the web after a
google search.
TEA, an 8080/8085 Co-Resident Editor/assembler
I can't find any used copies of the book however.
On the lighter side, I found a on-line archive of DTACK GROUNDED.
http://linux.monroeccc.edu/~paulrsm/dg/dg.htm
Interesting reading -- Nov 1981 $104 for a 4 MHZ 68000 CPU.
9:52 a.m.
My quip about "rephrasing" was of the statement:
">It was so primitive that instructions longer than 1 byte, had to be
assembled as 2 and 3 byte instructions."
I think that the OP meant "2 or 3 1-byte instructions". I'm not doubting
the primitiveness of the assembler being spoken about.
Does anyone remember the conflict between the MITS and IMSAI (actually, the
rest of the world) about using octal vs. hex representations of data? It's
very obvious just by looking at the two systems--the Altair 8800 spaces the
front panel toggles in groups of 3, whereas the IMSAI 8080 color-codes the
switches in groups of 4. I think that the early MITS assembler used octal,
although it's very hard to remember.
Cheers,
Chuck
10:05 a.m.
Chuck Guzis wrote:
My quip about "rephrasing" was of the
statement:
">It was so primitive that instructions longer than 1 byte, had to be
ROTFLMFAO!
When I was developing Z80-based products, an ongoing *battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> )
Octal? Hex? Just give me a symbolic debugger and let *it*
keep track of these minutae...
Ah for the days of toggling in bootstrap loaders with front
panel switches.. :-/ (at least bigger machines treated octal
as "real" octal and not this "spilt octal" nonsense...)
--don
assembled as 2 and 3 byte instructions."
I think that the OP meant "2 or 3 1-byte instructions". I'm not doubting
the primitiveness of the assembler being spoken about.
Does anyone remember the conflict between the MITS and IMSAI (actually, the
rest of the world) about using octal vs. hex representations of data? It's
very obvious just by looking at the two systems--the Altair 8800 spaces the
front panel toggles in groups of 3, whereas the IMSAI 8080 color-codes the
switches in groups of 4. I think that the early MITS assembler used octal,
although it's very hard to remember.
1:59 p.m.
On Monday 17 April 2006 01:05 pm, Don Y wrote:
Hehe. I remember that "big controversy", dunno at this point if it was in
some of the magazines or what.
Me, I wish they'd made those common TTL 7-segment decoder/driver chips
display something more like hex when you got into codes past 9...
Does anyone
remember the conflict between the MITS and IMSAI (actually,
the rest of the world) about using octal vs. hex representations of data?
It's very obvious just by looking at the two systems--the Altair 8800
spaces the front panel toggles in groups of 3, whereas the IMSAI 8080
color-codes the switches in groups of 4. I think that the early MITS
assembler used octal, although it's very hard to remember.
ROTFLMFAO!
When I was developing Z80-based products, an ongoing *battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> ) Octal? Hex? Just give me a symbolic debugger and let
*it*
keep track of these minutae...
Indeed.
Ah for the days of toggling in bootstrap loaders with
front
panel switches.. :-/ (at least bigger machines treated octal
as "real" octal and not this "spilt octal" nonsense...)
As did that H11 that I got to type in the boot loader any time I wanted to do
something with it, which I did indeed find exceedingly tedious.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
4:20 p.m.
When I was developing Z80-based products, an ongoing
*battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> )
I'm not promoting the Octal side (indeed I much prefer HEX), however
Zilog didn't "opt" for anything - they based their design and instruction
set decoding on the Intel 8080, which was laid out in a manner which
made sense with "Octal". And Intel DIDN'T use xsddsdsx, they DID use
xxdddsss - which made perfect sense from an Octal standpoint (which
is why so many people promoted the use of Octal with it).
Octal? Hex? Just give me a symbolic debugger and let
*it*
keep track of these minutae...
By the time the Z80 was common, so were good assemblers and
debuggers - but when the 8080 (ie: this instruction set) was designed,
there was no such software commonly available for "personal use" -
chances are your assembler was a pad of paper, a pencil and the Intel
databook (thats how I wrote my earliest software). More often than not
the debugger was a set of binary switches, or if you were really high-
tech, a very simple poke into memory monitor squeezed into a 1702.
The only "symbolic" thing about it was the pad of paper (sometimes
it was an integrated symbolic assembler/debugger, where you wrote
out the code on one side of the pad, the hex opcodes in the middle
and patches/debug notes on the right - of the same pad).
Thats why a lot of people opted for Octal with the 8080 - in Octal
the instruction set was fairly easy to remember ... For example
'1sd' gave you all the MOV combinations. If you had the instruction
set and it's encoding committed to memory, you could go a LOT
faster during the "assembly phase". It also made debugging
easier. I never got to like Octal, so I worked in hex anyway - I
made "cheat sheets" to look up the opcodes, which I eventually
memorized - I could go faster than most of the "Octal" guys...
Ah for the days of toggling in bootstrap loaders with
front
panel switches.. :-/ (at least bigger machines treated octal
as "real" octal and not this "spilt octal" nonsense...)
Agreed - one of the things I disliked most about Octal was the
ambiguity over representation of 16-bit quantities, and the fact
that you had to either "convert" to do it "right", or put up with a
little 2/3 digit in the middle (which made mental arithmetic
challenging) - The fact that you could just "stick two hex bytes
together" was reason enough for me to keep with it.
BTW - something I forgot to mention in my earlier post, Mits
wasn't going against "Everyone else" - there were a number
of other companies which embraced Octal for the 8080. Heath
is another "biggie", but I saw a good chunk of other Octal based
equipment during the time period.
Regards,
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
3:53 p.m.
On 4/17/2006 at 6:20 PM Dave Dunfield wrote:
By the time the Z80 was common, so were good assemblers
and
debuggers - but when the 8080 (ie: this instruction set) was designed,
there was no such software commonly available for "personal use" -
chances are your assembler was a pad of paper, a pencil and the Intel
databook (thats how I wrote my earliest software).
When I started to get into microprocessors, I wrote my own 8008
cross-assembler--and I used hex on a CDC 6600 (which was, curiously, an
octal machine--60 bit words with 6 bit characters). It just made sense. I
never finished the 8008 machine I was building, but went for the 8080 when
it came out as the MITS box. I revised the 8008 assembler to assemble
8080 codes. IIRC, my assembler was a one-pass job. There wasn't any good
reason to write a two-pass assembler, given the simplicity of the code I
was writing.
Hex actually made a lot of sense, not only from the standpoint of 8-bit
characters, but also due to the decimal arithmetic available on both the
8008 and 8080 MPU's. Try reading packed decimal coded in octal!
Cheers,
Chuck
18 Apr
18 Apr
5:21 a.m.
When I started to get into microprocessors, I wrote my
own 8008
cross-assembler--and I used hex on a CDC 6600 (which was, curiously, an
octal machine--60 bit words with 6 bit characters). It just made sense. I
never finished the 8008 machine I was building, but went for the 8080 when
it came out as the MITS box. I revised the 8008 assembler to assemble
8080 codes. IIRC, my assembler was a one-pass job. There wasn't any good
reason to write a two-pass assembler, given the simplicity of the code I
was writing.
I wrote my first 8080 assembler as a cross assembler on an IBM 360
mainframe (in fortran iirc)... took advantage of the "scads" of memory
available, and wrote it as a single pass which kept the output in core
and generated a "fixup" table to patch forward references at the end ...
worked, but the listing did not show the byte values for forward referenced
symbols correctly, so I abandoned the approach for my next 8080 assembler...
Which was a two pass assembler resident on the 8080 machine. One of
my first significant micro projects, this was a tiny little editor/assembler
which I managed to squeeze into about 2000 bytes so I could put it into
a 2716 (Hot new *BIG* EPROM!) - Worked only in hex (didn't support
decimal - or octal) - even the editor line numbers were in hex.
The mainframe cross assembler is completely gone ... I have no code
or copies of any of it anymore. I thought the first resident assembler
was also lost, however last year a hand-built machine from the time
period came to me with the editor/assembler still in ROM. I've got more
details up on the web site (look for "PIMPS"). I even put together an
I/O definition file to let my Horizon/Z80 simulator match the I/O of the
hand-built board so that you can actually run the thing (just in case
anyone has a burning desire to experience come of my earliest
code for micros).
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
17 Apr
17 Apr
6:21 p.m.
Dave Dunfield wrote:
But the Z80 isn't an 8085 nor is the 8085 an 8080. (granted, the
last two are much closer related than the first two).
And, there is no reason why xx ddd sss is any *better* than
xs dsd sdx or sd xxd ssd for an instruction encoding. *We*
used (split) octal because our MTOS supported hot patching
and it was convenient to "hand assemble" code patches on the
fly to fix bugs, etc. (gdb wasn't around for an 8080 in ~1976)
My first coding job was porting a 4004 based product to the 8080
(actually, the 8085 came out before we were done so that became
the target -- no real differences from the software standpoint)
When I was
developing Z80-based products, an ongoing *battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> )
I'm not promoting the Octal side (indeed I much prefer HEX), however
Zilog didn't "opt" for anything - they based their design and instruction
set decoding on the Intel 8080, which was laid out in a manner which
made sense with "Octal". And Intel DIDN'T use xsddsdsx, they DID use
xxdddsss - which made perfect sense from an Octal standpoint (which
is why so many people promoted the use of Octal with it). Octal? Hex?
Just give me a symbolic debugger and let *it*
keep track of these minutae...
By the time the Z80 was common, so were good assemblers and
debuggers - but when the 8080 (ie: this instruction set) was designed,
there was no such software commonly available for "personal use" -
chances are your assembler was a pad of paper, a pencil and the Intel
databook (thats how I wrote my earliest software). More often than not
the debugger was a set of binary switches, or if you were really high-
tech, a very simple poke into memory monitor squeezed into a 1702. The only "symbolic" thing about it was the
pad of paper (sometimes
it was an integrated symbolic assembler/debugger, where you wrote
out the code on one side of the pad, the hex opcodes in the middle
and patches/debug notes on the right - of the same pad).
Thats why a lot of people opted for Octal with the 8080 - in Octal
the instruction set was fairly easy to remember ... For example
'1sd' gave you all the MOV combinations. If you had the instruction
set and it's encoding committed to memory, you could go a LOT
faster during the "assembly phase". It also made debugging
Sure! And for the 4004 we carried a small sheet of paper
neatly folded in half and tucked in our wallets.
easier. I never got to like Octal, so I worked in hex
anyway - I
made "cheat sheets" to look up the opcodes, which I eventually
memorized - I could go faster than most of the "Octal" guys...
Exactly. Hence the advantage of things like the Nova over
the *80 devices -- you *know* you're dealing with words
instead of trying to cover both possibilities (with "split" octal).
I can still hear myself mumbling "High Low 377 377" (r.hl <- 0xFFFF)
Ah for the days of toggling in bootstrap loaders
with front
panel switches.. :-/ (at least bigger machines treated octal
as "real" octal and not this "spilt octal" nonsense...)
Agreed - one of the things I disliked most about Octal was the
ambiguity over representation of 16-bit quantities, and the fact
that you had to either "convert" to do it "right", or put up with a
little 2/3 digit in the middle (which made mental arithmetic
challenging) - The fact that you could just "stick two hex bytes
together" was reason enough for me to keep with it. BTW - something I forgot to mention in my earlier
post, Mits
wasn't going against "Everyone else" - there were a number
of other companies which embraced Octal for the 8080. Heath
is another "biggie", but I saw a good chunk of other Octal based
equipment during the time period.
18 Apr
18 Apr
5:01 a.m.
I'm not
promoting the Octal side (indeed I much prefer HEX), however
Zilog didn't "opt" for anything - they based their design and instruction
set decoding on the Intel 8080, which was laid out in a manner which
made sense with "Octal". And Intel DIDN'T use xsddsdsx, they DID use
xxdddsss - which made perfect sense from an Octal standpoint (which
is why so many people promoted the use of Octal with it).
But the Z80 isn't an 8085 nor is the 8085 an 8080. (granted, the
last two are much closer related than the first two). And, there is no reason why xx ddd sss is any *better*
than
xs dsd sdx or sd xxd ssd for an instruction encoding. *We*
used (split) octal because our MTOS supported hot patching
and it was convenient to "hand assemble" code patches on the
fly to fix bugs, etc. (gdb wasn't around for an 8080 in ~1976)
Doesn't this suggest that xxdddsss actually was *better* - since
you took advantage of the alignment with octal notation to make it
easier to hand-assemble...
Thats my whole point. The fact that the instruction set happens to
align well with Octal notation is the main reason that a lot of people
used it. It's interesting to note that almost all of the Intel docs are
in hex, or binary notations - but Mits, Heath and several others
thought that Octal was a better fit.
As noted earlier, I happen to be from the "hex" camp ... but I don't
think it's fair to dismiss the octal guys as "nuts" ... the use of octal
on the 8080 did have some benefit, and there were a lot of people
who went that route - to ignore or discount this does not present an
accurate depiction of the time period.
Now why some people chose octal for other processors, which
didn't have an architectural slant toward 8 is more of a mystery
to me....
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
19 Apr
19 Apr
6:55 p.m.
Dave Dunfield wrote:
But the Z80 and the 8085 are both based on the 8080 architecture
and instruction set - so much so that they will both run the vast
majority of 8080 code.
But that's a fallacy. You have to tweek the code in almost
all cases (especially if you are designing embedded systems
and not "desktop applications"). So, a smarter approach is
to handle things at the *source* level instead of the *object*.
But that's the point; it *doesn't* help you hand assemble.
1/4 of the opcode space is devoted to 8 bit moves. Yet,
I find 8 bit moves seldom used (at least in any of the
code that I've written/maintained). Sure, I may want to:
LD D,H
LD E,L
to save a *copy* of r.HL before indexing off of it
ADD HL,BC
But, how often do you LD C,H or LD L,B etc?
And, tracking 16 bit load/stores (LXI's, PUSH's, etc.)
requires memorizing an encoding for *4* possible arguments.
And who can recall the clever encoding of all of the
conditionals?
I.e. you end up committing the opcodes that you *use*
to memory and dig up the oddballs from a cheat sheet
when you need it. (e.g., PCHL/XTHL, etc.)
I'd have rathered some of the opcode space spent on
more useful instructions -- short load-immediates
(where the argument is encoded in the first byte of
the opcode), etc.
I'm not promoting the Octal side (indeed I much
prefer HEX), however
Zilog didn't "opt" for anything - they based their design and instruction
set decoding on the Intel 8080, which was laid out in a manner which
made sense with "Octal". And Intel DIDN'T use xsddsdsx, they DID use
xxdddsss - which made perfect sense from an Octal standpoint (which
is why so many people promoted the use of Octal with it).
But the Z80 isn't an
8085 nor is the 8085 an 8080. (granted, the
last two are much closer related than the first two). Is anyone really suggesting that it's an
"accident" that the Z80 happens to run 8080 code ... or did
Zilog begin with the 8080 instruction set definition (hence my point
that they (Zilog) did not make the decision on the bit arrangements
of the opcoodes).
But a Z80 *won't* run 808[05] code. Nor will a 64180 run
Z80 code. (and "Rabbits" don't run anything! :> ) Zilog made
a very conscious decision to make a "different 808x". Everything
from the pinouts, peripherals available, bus timing,
etc.
(where did RST 5.5 go? etc.). Nor did they adhere to
Intel's mnemonics (copywritten?) -- though converting from
one to the other is almost trivial with even the macroassemblers
available back then. Tek used a still different set of
opcodes in their tools, etc.
And, there is
no reason why xx ddd sss is any *better* than
xs dsd sdx or sd xxd ssd for an instruction encoding. *We*
used (split) octal because our MTOS supported hot patching
and it was convenient to "hand assemble" code patches on the
fly to fix bugs, etc. (gdb wasn't around for an 8080 in ~1976)
Doesn't this suggest that xxdddsss actually was *better* - since
you took advantage of the alignment with octal notation to make it
easier to hand-assemble... Thats my whole point. The fact that the instruction
set happens to
align well with Octal notation is the main reason that a lot of people
used it. It's interesting to note that almost all of the Intel docs are
in hex, or binary notations - but Mits, Heath and several others
thought that Octal was a better fit.
As noted earlier, I happen to be from the "hex" camp ... but I don't
think it's fair to dismiss the octal guys as "nuts" ... the use of octal
on the 8080 did have some benefit, and there were a lot of people
who went that route - to ignore or discount this does not present an
accurate depiction of the time period.
When I worked on 8085's, we let the MDS-800 handle the assemblies.
Burn a set of EPROMs (2 hours!), plug into the target and hope
you've stubbed enough places in the code so you could figure out
where it was based on examining odd display patterns, etc.
Stare at listings, burn another set of EPROMs after lunch.
Two turns of the crank in an 8 hour shift. Did the choice of
opcode assignments increase productivity??
When I was doing Z80-based designs (in the "split octal" world),
a helluva lot of energy was expended to support the "octal"
encoding -- rewriting the Zilog assembler to generate listings
in octal (INCLUDING displaying addresses in split octal!),
building run-time "monitors" to examine and patch code images
during execution, writing the associated software to do so, etc.
I'm convinced the fact that you could get a ten-key
keypad and an inexpensive LCD to display 6 digit SPLIT octal
values had more of an impact on the octal decision than
anything about the opcode encoding -- despite the fact that
it made USING the tools more difficult (since you can only
display a 16 bit value -- *address* -- in 6 digits, you have
to multiplex the display to let the user see the *data* at
that address :< ).
I recall getting an EM-180 and quickly distancing myself
from the octal vs. hex debate... I'll use *symbols*
instead
of dicking around with bit groupings.
Now why some people chose octal for other processors,
which
didn't have an architectural slant toward 8 is more of a mystery
to me....
I think the fact that 0..7 fits in a decimal representation
says a lot about the "why". :-( Amazing to consider how
much "resources" got wasted on silly (in hindsight) decisions.
Sort of like PC (and other) BIOS decisions placing silly
restrictions on the size of a disk or where the boot code
can be located, etc.
8:34 p.m.
On Wednesday 19 April 2006 09:55 pm, Don Y wrote:
But that's a fallacy. You have to tweek the code in almost
all cases (especially if you are designing embedded systems
and not "desktop applications"). So, a smarter approach is
to handle things at the *source* level instead of the *object*.
Feeling like I'm missing something here...
What are these differences you refer to? I have some vague recollection of
having heard of these someplace before, but the details are escaping me at
the moment.
<...>
Yep!
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
But the Z80 isn't an 8085 nor is the 8085 an 8080.
(granted, the
last two are much closer related than the first two).
But the Z80 and the 8085 are both based on the 8080 architecture
and instruction set - so much so that they will both run the vast
majority of 8080 code. But a Z80 *won't* run 808[05] code.
?
<...>
I'd have rathered some of the opcode space spent
on more useful instructions
-- short load-immediates (where the argument is encoded in the first byte
of the opcode), etc.
I too felt that some things could have been done differently. :-)
<...>
When I was doing Z80-based designs (in the "split
octal" world), a helluva
lot of energy was expended to support the "octal" encoding -- rewriting the
Zilog assembler to generate listings in octal (INCLUDING displaying
addresses in split octal!), building run-time "monitors" to examine and
patch code images during execution, writing the associated software to do
so, etc.
I'm convinced the fact that you could get a ten-key keypad and an
inexpensive LCD to display 6 digit SPLIT octal values had more of an impact
on the octal decision than anything about the opcode encoding -- despite the
fact that it made USING the tools more difficult (since you can only
display a 16 bit value -- *address* -- in 6 digits, you have to multiplex
the display to let the user see the *data* at that address :< ).
I really do believe that the choices of what you could get for display
hardware and simple decoding chips (hence my recent mention of the 7446 not
decoding hex) influenced a lot of things in that direction, with for example
the Heath H8 working that way too.
Though I have NO idea why the H11 used octal...
I recall getting an EM-180 and quickly distancing
myself
from the octal vs. hex debate... I'll use *symbols* instead
of dicking around with bit groupings.
Works for me. One of the reasons I parted with that 1802-based system I had a
while back, it had software, but the only way to get it into the machine
was by punching in a whole lot of hex digits on a keypad, a prospect I found
sufficiently daunting that I never even powered that machine up in all of the
years I had it.
Now why some
people chose octal for other processors, which
didn't have an architectural slant toward 8 is more of a mystery
to me....
I think the fact that 0..7 fits in a decimal representation says a lot about
the "why". :-( Amazing to consider how much "resources" got wasted
on
silly (in hindsight) decisions. Sort of like PC (and other) BIOS decisions
placing silly restrictions on the size of a disk or where the boot code
can be located, etc.
9:03 p.m.
On 4/19/2006 at 11:34 PM Roy J. Tellason wrote:
> But a Z80 *won't* run 808[05] code.
Well, a Z80 will run 8085 code that limits itself to 8080 instructions.
But the 8085 has two documented instructions (RIM SIM) that the 8080
doesn't have--and a few more "undocumented" instructions (nonetheless used
by many embedded programs) that neither the 8080 nor the Z80 has.
Initially I thought that the Rabbit was a good idea--until I started to
program it. What did you do with (insert a list of instructions)? And an
interesting bug or two. Feh.
Cheers,
Chuck
20 Apr
20 Apr
10:40 a.m.
On Thursday 20 April 2006 12:03 am, Chuck Guzis wrote:
On 4/19/2006 at 11:34 PM Roy J. Tellason wrote:
Yeah, I remember those two...
> But a Z80 *won't* run 808[05] code.
Well, a Z80 will run 8085 code that limits itself to 8080 instructions.
But the 8085 has two documented instructions (RIM SIM) that the 8080
doesn't have-- and a few more "undocumented" instructions
(nonetheless used by many
embedded programs) that neither the 8080 nor the Z80 has.
I remember some real early magazine articles, and have since found a bit of
stuff online, that talked about undocumented opcodes for the z80, but I've
not run across that info for anything else. And it seems to depend a lot on
what brand of chip, etc. so I've never been really tempted to use them.
Initially I thought that the Rabbit was a good
idea--until I started to
program it. What did you do with (insert a list of instructions)? And an
interesting bug or two. Feh.
I haven't yet looked at that, got enough going on here to keep me busy...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
1:41 p.m.
On 4/20/2006 at 1:40 PM Roy J. Tellason wrote:
I remember some real early magazine articles, and have
since found a bit
of stuff online, that talked about undocumented opcodes for the z80, but
I've not run across that info for anything else. And it seems to depend a
lot
on what brand of chip, etc. so I've never been
really tempted to use
them.
Well, since the information seems to be disappearing from the web in favor
of the "multiple copies of a dumb page" documentation, here they are for
your files:
08 DSUB HL = HL - BC Subtract BC from HL
10 ARHL HL = HL/2 Arithmetic right shift HL, (Low order bit to Carry)
18 RDEL DE = DE rotate left 1 Rotate DE left, High order bit to carry
20 RIM (You already know about this one)
28 LDHI DE = HL+imm Load DE with HL + immediate value
30 SIM (You already know about this one)
38 LDSI DE=SP+imm Load DE with SP + immediate value
CB RSTV Restart to 40H if overflow
D9 SHLX (DE) = HL Store HL in the location pointed to by DE
DD JN5 jump if Flags(5) clear Jump if bit 5 of flags is clear
ED LHLX HL = (DE) Load HL from the location pointed to by DE
FD J5 jump if Flags(5) set Jump if bit 5 of flags is set
Flag bit 5 is sometimes called the K flag (for Korrect sign).
AFAIK, all Intel 8085 versions have these implemented. I've heard that the
NEC versions don't, but haven't verified it.
But I note that one way to tell an 8085 from an 8080 or Z80 is to attempt
to set bits 3 and 5 of the flags register. The 8080 forces both of these
to 0; the Z80 allows both to be set. The 8085 allows setting of bit 5
only.
For what it's worth,
Chuck
26 Apr
26 Apr
10:18 p.m.
Chuck Guzis wrote:
On 4/20/2006 at 1:40 PM Roy J. Tellason wrote:
IIRC, this was actually DSBC (figuratively speaking)...
i.e. it subttracted the cy as well.
I remember some real early magazine articles,
and have since found a bit
of stuff online, that talked about undocumented opcodes for the z80, but
I've not run across that info for anything else. And it seems to depend a
lot
on what brand of chip, etc. so I've never
been really tempted to use
them.
Well, since the information seems to be disappearing from the web in favor
of the "multiple copies of a dumb page" documentation, here they are for
your files:
08 DSUB HL = HL - BC Subtract BC from HL 10 ARHL HL = HL/2 Arithmetic right shift HL, (Low
order bit to Carry)
18 RDEL DE = DE rotate left 1 Rotate DE left, High order bit to carry
20 RIM (You already know about this one)
28 LDHI DE = HL+imm Load DE with HL + immediate value
30 SIM (You already know about this one)
38 LDSI DE=SP+imm Load DE with SP + immediate value
CB RSTV Restart to 40H if overflow
D9 SHLX (DE) = HL Store HL in the location pointed to by DE
DD JN5 jump if Flags(5) clear Jump if bit 5 of flags is clear
ED LHLX HL = (DE) Load HL from the location pointed to by DE
FD J5 jump if Flags(5) set Jump if bit 5 of flags is set
Flag bit 5 is sometimes called the K flag (for Korrect sign).
AFAIK, all Intel 8085 versions have these implemented. I've heard that the
NEC versions don't, but haven't verified it.
But I note that one way to tell an 8085 from an 8080 or Z80 is to attempt
to set bits 3 and 5 of the flags register. The 8080 forces both of these
to 0; the Z80 allows both to be set. The 8085 allows setting of bit 5
only.
And a clever way to diagnose a failed data bus is to find the
processor stopped at 0x0076. Though it only works on systems
with lightly loaded (MOS) busses.
21 Apr
21 Apr
3:49 a.m.
Roy J. Tellason schrieb:
I know
of a least one software (which I had disassembled myself for
curiosity long ago) that actually uses undocumented Z80 instructions,
namely the ones that allow access to the higher and lower haves of the
index registers: this is the 12K-Zapple-Basic by TDL. Concerning these
instructions, they seem to work on most common Z80s, including Z80A, B,
and H variants, tried those myself. I haven't verified, due to lack of
HW, where they also work on the 64180, the z180 or z280.
Holger
On Thursday 20 April 2006 12:03 am, Chuck Guzis
wrote:
Undocumented instrs are not the whole story, particularly not for 8085
vs z80 issues, and especially not for RIM and SIM. I have had hard times
finding any 8085 system at all that required and used them; the typical
application seems to be a bit-banger RS-232 interface - usually any 808x
system that has a serial interface will employ a 8251 or alike for that.
Maybe some embedded two-chip system (8085+8355) will take advantage of
it, but this is probably only interesting for forensic analyses, not
really a hobbyist/conservation issue.
No, a really nasty difference comes from the different use of the parity
bit in the 8080 vs the same PSW bit in a Z80. Although I thought this
would also just be used for calculating/checking the parity bit for
bit-banger serial, it often appears in rather obscure scenarios where
one wouldn't expect it. At least, in a disassembly one often finds
incidents by searching for the JPE/JPO instructions.
On 4/19/2006 at 11:34 PM Roy J. Tellason wrote:
Yeah, I remember those two...
> But a Z80 *won't* run 808[05] code.
>
Well, a Z80 will run 8085 code that limits itself to 8080
instructions.
But the 8085 has two documented instructions (RIM SIM) that the 8080
doesn't have--
and a few more "undocumented"
instructions (nonetheless used by many
embedded programs) that neither the 8080 nor the Z80 has.
I remember some real early magazine articles, and have since found a bit of
stuff online, that talked about undocumented opcodes for the z80, but I've
not run across that info for anything else. And it seems to depend a lot on
what brand of chip, etc. so I've never been really tempted to use them
10:09 a.m.
On 4/21/2006 at 12:49 PM Holger Veit wrote:
Those upper-lower IX/IY undocumented instructions seem to be very
straightforward. DD/FD prefixes simply indicate whether IX or IY should be
used in place of HL. Undocumented EDs on the Z80 are another kettle of
fish, however.
On the 8085, one important use of RIM and SIM is handling of TRAP
conditions. I've got a system here that uses TRAP to diagnose accesses of
non-existent peripherals and memory parity errors as well a keyboard entry
akin to (Ctrl+Alt+Del).
Out of curiosity, I got my old Grid laptop with a NEC V30 CPU out and
started to try some of the "undocumented" 8085 opcodes on it. Well, the
few that I've tried aren't no-ops, but on the the other hand, they don't do
anything particularly exciting. For example, 28 seems to be identical in
operation to DAD H (29), while 38 seems to act identically to INR H (24).
FD appears to read the next byte and use it to set or clear the parity and
half-carry flags. My guess is that part of the CPI instruction logic's
being used, although the other flags (C, Z and S) don't seem to be
affected. I haven't tried any others--it's pretty obvious that undefined
opcodes in V30 8080 emulation mode simply take flying leaps into the logic
array. How this compares with, say, a NEC C8080A is something that I'm not
equipped to answer.
After all these years, I'm still not certain that those who exploited the
undocumented instructions in any of these chips saved much in the way of
speed or space. About the only significant exception I can think of is the
80286 LOADALL instruction, which was only semi-documented by Intel.
Cheers,
Chuck
what brand of
chip, etc. so I've never been really tempted to use them
I know of a least one
software (which I had disassembled myself for
curiosity long ago) that actually uses undocumented Z80 instructions,
namely the ones that allow access to the higher and lower haves of the
index registers: this is the 12K-Zapple-Basic by TDL. Concerning these
instructions, they seem to work on most common Z80s, including Z80A, B,
and H variants, tried those myself. I haven't verified, due to lack of
HW, where they also work on the 64180, the z180 or z280.
26 Apr
26 Apr
10:08 p.m.
Chuck Guzis wrote:
On 4/21/2006 at 12:49 PM Holger Veit wrote:
Those upper-lower IX/IY undocumented instructions seem to be very
straightforward. DD/FD prefixes simply indicate whether IX or IY should be
used in place of HL. Undocumented EDs on the Z80 are another kettle of
fish, however.
On the 8085, one important use of RIM and SIM is handling of TRAP
conditions. I've got a system here that uses TRAP to diagnose accesses of
non-existent peripherals and memory parity errors as well a keyboard entry
akin to (Ctrl+Alt+Del).
Out of curiosity, I got my old Grid laptop with a NEC V30 CPU out and
started to try some of the "undocumented" 8085 opcodes on it. Well, the
few that I've tried aren't no-ops, but on the the other hand, they don't do
anything particularly exciting. For example, 28 seems to be identical in
operation to DAD H (29), while 38 seems to act identically to INR H (24).
FD appears to read the next byte and use it to set or clear the parity and
half-carry flags. My guess is that part of the CPI instruction logic's
being used, although the other flags (C, Z and S) don't seem to be
affected. I haven't tried any others--it's pretty obvious that undefined
opcodes in V30 8080 emulation mode simply take flying leaps into the logic
array. How this compares with, say, a NEC C8080A is something that I'm not
equipped to answer.
After all these years, I'm still not certain that those who exploited the
undocumented instructions in any of these chips saved much in the way of
speed or space. About the only significant exception I can think of is the
80286 LOADALL instruction, which was only semi-documented by Intel.
IIRC, the only truly useful undocumented instruction in the 8085
was the SBC HL,DE equivalent (almost the opposite of DAD D).
Using these in a production device never seemed to sit well
at any of the firms I worked with -- you never knew when the
mask might change and you'd find yourself wondering why things
suddenly stopped working...
what
brand of chip, etc. so I've never been really tempted to use them
I know of a
least one software (which I had disassembled myself for
curiosity long ago) that actually uses undocumented Z80 instructions,
namely the ones that allow access to the higher and lower haves of the
index registers: this is the 12K-Zapple-Basic by TDL. Concerning these
instructions, they seem to work on most common Z80s, including Z80A, B,
and H variants, tried those myself. I haven't verified, due to lack of
HW, where they also work on the 64180, the z180 or z280.
21 Apr
21 Apr
10:25 a.m.
Holger Veit wrote:
I know of a least one software (which I had
disassembled myself for
curiosity long ago) that actually uses undocumented Z80 instructions,
namely the ones that allow access to the higher and lower haves of the
index registers: this is the 12K-Zapple-Basic by TDL. Concerning these
instructions, they seem to work on most common Z80s, including Z80A, B,
and H variants, tried those myself. I haven't verified, due to lack of
HW, where they also work on the 64180, the z180 or z280.
I think I have read that some versions of floating point routines
made use of the un-documented instructions. One version of Small-C
for the Z80 made use of this.
Holger
26 Apr
26 Apr
9:59 p.m.
Holger Veit wrote:
Roy J. Tellason schrieb:
If you are looking for a "desktop/hobbyist" application, that's probably
true. But, SID and SOD were cheap one bit ports that were exploited
in embedded products. Given how few *products* were developed in this
era, I find THEM more interesting than "general purpose/hobbyist"
computers (since some of the architectures really came up with
imaginative uses for the hardware available in processors in that
timeframe (e.g., using DMA controllers as counter timers, etc.)
On Thursday 20 April 2006 12:03 am, Chuck Guzis
wrote:
Undocumented instrs are not the whole story, particularly not for 8085
vs z80 issues, and especially not for RIM and SIM. I have had hard times
finding any 8085 system at all that required and used them; the typical On 4/19/2006 at 11:34 PM Roy J. Tellason wrote:
Yeah, I remember those two...
> But a Z80 *won't* run 808[05] code.
>
Well, a Z80 will run 8085 code that limits itself to 8080
instructions.
But the 8085 has two documented instructions (RIM SIM) that the 8080
doesn't have--
application seems to be a bit-banger RS-232 interface
- usually any 808x
system that has a serial interface will employ a 8251 or alike for that.
Maybe some embedded two-chip system (8085+8355) will take advantage of
it, but this is probably only interesting for forensic analyses, not
really a hobbyist/conservation issue.
No, a really nasty difference comes from the different use of the parity
bit in the 8080 vs the same PSW bit in a Z80. Although I thought this
would also just be used for calculating/checking the parity bit for
bit-banger serial, it often appears in rather obscure scenarios where
one wouldn't expect it. At least, in a disassembly one often finds
incidents by searching for the JPE/JPO instructions.
I know of a least one software (which I had
disassembled myself for
curiosity long ago) that actually uses undocumented Z80 instructions,
namely the ones that allow access to the higher and lower haves of the
index registers: this is the 12K-Zapple-Basic by TDL. Concerning these
instructions, they seem to work on most common Z80s, including Z80A, B,
and H variants, tried those myself. I haven't verified, due to lack of
HW, where they also work on the 64180, the z180 or z280.
The 64180/Z180 (I believe zilog actually licensed the Z180 from
hitachi -- they were bus playing with Z280 and Z380 and appear
to have skipped the Z180 market) adds even more variety to the
mix. (the IN0/OUT0, TST, etc. instructions)
and a few more "undocumented"
instructions (nonetheless used by many
embedded programs) that neither the 8080 nor the Z80 has.
I remember some real early magazine articles, and have since found a
bit of stuff online, that talked about undocumented opcodes for the
z80, but I've not run across that info for anything else. And it
seems to depend a lot on what brand of chip, etc. so I've never been
really tempted to use them
27 Apr
27 Apr
11:30 a.m.
Undocumented
instrs are not the whole story, particularly not for 8085
vs z80 issues, and especially not for RIM and SIM. I have had hard times
finding any 8085 system at all that required and used them; the typical
If you are looking for a "desktop/hobbyist" application, that's probably
true. But, SID and SOD were cheap one bit ports that were exploited
in embedded products. Given how few *products* were developed in this
26 Apr
26 Apr
10:13 p.m.
Chuck Guzis wrote:
But the Z80 timings are very different than an 808[05].
Sure, if you are writing an assembler, text editor, etc. this
isn't really important. But, if you are trying to catch
timing pulses off an RF front end or implementing tight
delay loops (e.g., generating sound), you don't want to
suddenly discover that each of the paths through your
code are nolonger what you thought they would be.
(counting T states... blech! something I hope never to have to
do again!)
On 4/19/2006 at 11:34 PM Roy J. Tellason wrote:
[actually, the attribution should have been mine...]
> But a Z80
*won't* run 808[05] code.
Well, a Z80 will run 8085 code that limits itself to 8080 instructions.
But the 8085 has two documented instructions (RIM SIM) that the 8080
doesn't have--and a few more "undocumented" instructions (nonetheless used
by many embedded programs) that neither the 8080 nor the Z80 has. Initially I thought that the Rabbit was a good
idea--until I started to
program it. What did you do with (insert a list of instructions)? And an
interesting bug or two. Feh.
It was a stupid idea, IMO. Designed to lock people into their
device AND toolchain (neither of which seem worthy of much
attention).
Can you spell ARM?
20 Apr
20 Apr
5:29 a.m.
But the Z80
and the 8085 are both based on the 8080 architecture
and instruction set - so much so that they will both run the vast
majority of 8080 code.
But that's a fallacy. You have to tweek the code in almost
all cases (especially if you are designing embedded systems
and not "desktop applications"). So, a smarter approach is
to handle things at the *source* level instead of the *object*. Is anyone
really suggesting that it's an
"accident" that the Z80 happens to run 8080 code ... or did
Zilog begin with the 8080 instruction set definition (hence my point
that they (Zilog) did not make the decision on the bit arrangements
of the opcoodes).
But a Z80 *won't* run 808[05] code. Nor will a 64180 run
Z80 code. (and "Rabbits" don't run anything! :> ) Zilog made
a very conscious decision to make a "different 808x". Everything
from the pinouts, peripherals available, bus timing, etc.
(where did RST 5.5 go? etc.). Nor did they adhere to
Intel's mnemonics (copywritten?) -- though converting from
one to the other is almost trivial with even the macroassemblers
available back then. Tek used a still different set of
opcodes in their tools, etc. And, there is no reason why xx ddd sss is any *better*
than
xs dsd sdx or sd xxd ssd for an instruction encoding. *We*
used (split) octal because our MTOS supported hot patching
and it was convenient to "hand assemble" code patches on the
fly to fix bugs, etc. (gdb wasn't around for an 8080 in ~1976)
Doesn't this suggest that xxdddsss actually was *better* - since
you took advantage of the alignment with octal notation to make it
easier to hand-assemble... And, tracking 16 bit load/stores (LXI's,
PUSH's, etc.)
requires memorizing an encoding for *4* possible arguments.
Yes - these are included in the "Non-octal" catagory above.
And who can recall the clever encoding of all of the
conditionals?
Tough if you think in hex (the conditon field would be split across two
nibbles ... but if you think in Octal, it's not so tough ... all conditions
are represented in the second triplet (from the right):
000 = 0 = NZ
001 = 1 = Z
010 = 2 = NC
011 = 3 = C
100 = 4 = PO
101 = 5 = PE
110 = 6 = P
111 = 7 = M
All transfer instruction are encoded: 11 ccc xxx
Where xxis:
000 = Rcondition
010 = Jcondition
100 = Ccondition
As noted
earlier, I happen to be from the "hex" camp ... but I don't
think it's fair to dismiss the octal guys as "nuts" ... the use of octal
on the 8080 did have some benefit, and there were a lot of people
who went that route - to ignore or discount this does not present an
accurate depiction of the time period.
When I worked on 8085's, we let the MDS-800 handle the assemblies.
Burn a set of EPROMs (2 hours!), plug into the target and hope
you've stubbed enough places in the code so you could figure out
where it was based on examining odd display patterns, etc.
Stare at listings, burn another set of EPROMs after lunch.
Two turns of the crank in an 8 hour shift. Did the choice of
opcode assignments increase productivity?? When I was doing Z80-based designs (in the "split
octal" world),
a helluva lot of energy was expended to support the "octal"
encoding -- rewriting the Zilog assembler to generate listings
in octal (INCLUDING displaying addresses in split octal!),
building run-time "monitors" to examine and patch code images
during execution, writing the associated software to do so, etc.
This would be because you didn't work in Octal (split or otherwise).
The same could be said for any encoding scheme - If some of your
users had demanded to use base 13 this too would have presented a
challange to you - but at least the "ultimate answer" would work out
correctly: (6x9=42 in base 13 :-)
I'm convinced the fact that you could get a
ten-key
keypad and an inexpensive LCD to display 6 digit SPLIT octal
values had more of an impact on the octal decision than
anything about the opcode encoding -- despite the fact that
it made USING the tools more difficult (since you can only
display a 16 bit value -- *address* -- in 6 digits, you have
to multiplex the display to let the user see the *data* at
that address :< ).
That was certainly part of it - as was the fact that 7447's could
display Octal quite nicely, but didn't work so well with Hex.
But I would also say that a higher percentage of single-board
8080 machines used Octal - because it does make sense
with the instruction set.
I recall getting an EM-180 and quickly distancing
myself
from the octal vs. hex debate... I'll use *symbols* instead
of dicking around with bit groupings.
Why even bother with that ... why not just use mouse clicks
and "drag and drop".
In the days of wirewrap systems, homebrew front panels
and pencil and pad assemblers, bit groupings mattered.
One question though --- since you use symbols and don't
"dick around" with bit groupings ... why is the use of Hex
over Octal so important to you? ... wouldn't one be just as
good as the other to the high level view (like some detail
burried way down in the mouse driver that you don't need
to care about when you click).
Now why some
people chose octal for other processors, which
didn't have an architectural slant toward 8 is more of a mystery
to me....
I think the fact that 0..7 fits in a decimal representation
says a lot about the "why". :-( Amazing to consider how
much "resources" got wasted on silly (in hindsight) decisions.
Sort of like PC (and other) BIOS decisions placing silly
restrictions on the size of a disk or where the boot code
can be located, etc.
7:33 a.m.
New subject: 8080-family hex vs. octal - was: 8080 Assembler-Text Editor (ATE)
Although I was well aware of the octal grouping of fields in the 8080, I
adopted hex right off from the start, as I did when coding for the 8008.
The problems dealing with "split" 16-bit quantites was too much of a hurdle
to warrant octal.
As far as memorizing opcodes, that's neither here nor there. While octal's
nice for decoding moves, it's less of an issue for conditionals. There's
still a very recognizable pattern:
JNZ = C2
JZ = CA
CNZ = C4
CZ = CC
RNZ = C0
RZ = C8
JNC = D2
JC = DA
CNC = D4
CC = DC
...
Cheers,
Chuck
26 Apr
26 Apr
10:24 p.m.
New subject: 8080-family hex vs. octal - was: 8080 Assembler-Text Editor (ATE)
Chuck Guzis wrote:
Although I was well aware of the octal grouping of
fields in the 8080, I
adopted hex right off from the start, as I did when coding for the 8008.
The problems dealing with "split" 16-bit quantites was too much of a hurdle
to warrant octal.
As far as memorizing opcodes, that's neither here nor there. While octal's
nice for decoding moves, it's less of an issue for conditionals. There's
still a very recognizable pattern:
JNZ = C2
JZ = CA
CNZ = C4
CZ = CC
RNZ = C0
RZ = C8
JNC = D2
JC = DA
CNC = D4
CC = DC
...
Yes, there are similar "patterns" in most instructions
(e.g., LXI B/D/H/SP; INX B/D/H; PSH B/D/H; etc.). But, in my
experience, you just memorized them because you always saw them
in certain combinations:
PUSH AF
PUSH BC
PUSH DE
PUSH HL
...
POP HL
POP DE
POP BC
POP AF
EI
RETI
I can usually hand disassemble code faster than relying on
interactive / batch disassemblers (especially if you have
inline data and/or self-modifying code) just because these
patterns get to be *so* noticeable that you dont even bother
disassembling the code -- you just start writing the commentary
for the code! (disassembling without adding commentary is
pretty useless)
11:27 p.m.
Dave Dunfield wrote:
Context: Mid 70's - several guys I knew (myself included)
had little boards with wire-wrapped 8080's, some switches and
Sure! I've still got a few Augat panels with "big" DRAM arrays
built out of 16Kx1 DRAMs that I hand wrapped (too risky to
do on perfboard to get a good solid Vcc/GND).
Although it's possible to create software that will run on an 8080
(or an 8085) and not a Z80 (I used to do this to really annoy a
friend who had a Cromemco Z80 system when I still used the
Altair 8080 :-) ... By and large, the Z80 is a superset of the
8080 - There are some flag differences which prevent it from
being a fully proper superset, however these affected very little
"real" code.
How do you define "real" code? If you're on a boat at sea and
your navigation system suddenly decides that this opcode should
not behave the way it "does", you might get a bit annoyed
when you can't find any of your lobster pots, etc. I think code
that controls the rudder of a several ton vessel moving at 20
knots is just as "real" as the code that draws a tic tac toe
board on a glass tty... :-(
Yeah, and my quick reference card gives them all nice
HEX values that I can dig up just as easy as you can
build an opcode using all of these little tables.
Probably not - but I seem to recall that even though the 8080 was
a rather expensive chip to get, it still didn't always come with an
MDS-800 - I don't recall any of the guys in our "homebrew computer
club" having an MDS-800 (or any production computer for that
matter).
Sure. But, the rules applying to hobbyists are obviously
different than those applying to corporations trying to bring
products to market. You wouldn't suggest we NOT purchase
the MDS and, instead, get a bunch of SDK's wired to our
target hardware?
You're missing the point: it was a waste of time to invest
all that energy in half-*ssed tools instead of moving to
more "current" technology. If your goal is to bring a product
to market (NOT to deal with hobbyists), you devote your
resources to things that can measurably improve your
productivity. Throwing resources (software and hardware
development time and money) on tools that don't make a
dramatic increase in your productivity is just foolish.
Like writing code in assembler when you could just as readily
use a HLL.
But, you're still dealing with the hobbyist world. Every product
*we* shipped was a "single board 808x/4004 machine"... yet, they
didn't "use octal" (and we shipped thousands and thousands
of machines).
If you're a hobbyist, your time is (often) worth nothing.
I've watched people disassemble video arcade pieces "by hand"
and reverse engineer all of the copy protection hacks in the
code.
Um, *why*?
Because they are curious and have decided that they can
AFFORD the time to engage in this activity. But a *business*
would never waste their time on this -- unless there was some
key IP that they were after, etc. (there are firms that expend
a great deal of resources on these sorts of activities!)
Mid 70's. No GUIs. No mice.
I never saw it as a huge waste of "resources" - In the early
You didn't rewrite ("re-bug") WORKING development tools
in a production environment to add these "features".
If you've got an assembler, linkage editor, etc. that all
WORK but produce HEX listings, why rewrite them to spit out
listings in split octal? Including addresses (of opcodes,
arguments, link maps, etc.) Are you going to gain that much
in terms of productivity to offset the time spent doing this?
And the bugs that get introduced in the process?
Wouldn't it be better to just live with the hex listings
and purchase a hex keypad for your "run-time monitor"?
After all, you're only going to build a handful of those...
what's it going to cost you vs. a decimal/octal keypad -- an
extra $10??
Spend the resources that you "wasted" hacking the toolchain
to purchase another *real* development system. Or, a
symbolic debugger. Etc. Don't sell your adherence to
The Old Ways as a virtue -- concentrate on getting ahead
of the curve and your competition!
But the Z80 and the 8085 are both based on the 8080
architecture
and instruction set - so much so that they will both run the vast
majority of 8080 code.
But that's a fallacy. You have to tweek the code in
almost
all cases (especially if you are designing embedded systems
and not "desktop applications"). So, a smarter approach is
to handle things at the *source* level instead of the *object*. a few bytes of RAM ... Didn't matter how
"smart" you were, you
worked at the machine level - hand assembling and entering
opcodes.
Thats when I first observed the octal/hex split - some guys chose
Octal for the obvious advantages in hand-coding, I went hex due
to my background...
Dunno. In my case, it was converting i4004 assembly language
to i8085 assembly language. The i4004 listings were all in Hex
so it (as were the i8085) so the idea of using anything other
than hex to represent data, etc never came up.
OTOH, with the Nova, octal seemed "normal".
But "split octal" on the Z80 was an abomination.
Is anyone really suggesting that it's an
"accident" that the Z80 happens to run 8080 code ... or did
Zilog begin with the 8080 instruction set definition (hence my point
that they (Zilog) did not make the decision on the bit arrangements
of the opcoodes).
But a Z80 *won't* run 808[05] code. Nor will a 64180 run
Z80 code. (and "Rabbits" don't run anything! :> ) Zilog made
a very conscious decision to make a "different 808x". Everything
from the pinouts, peripherals available, bus timing, etc.
(where did RST 5.5 go? etc.). Nor did they adhere to
Intel's mnemonics (copywritten?) -- though converting from
one to the other is almost trivial with even the macroassemblers
available back then. Tek used a still different set of
opcodes in their tools, etc. Macroassemblers? My first 8080 design had only
"reset", "Deposit",
"next" and "run" switches ... if you made a mistake entering an
opcode
you had to start all over again from 0000 0000 0000 0000.
(or 00 000 000 00 000 000 if you are from the Octal camp)
PS: RST 5.5 "went" the same place that SIM and RIM "went" ...
it stayed in the primordial nothingness which existed before
creation (RST 5.5 is an 8085 extension - the Z80 was based
on the 8080, never the 8085 - so RST 5.5 never existed as
far as the Z80 was concerned).
But that's the point; it *doesn't* help you
hand assemble.
1/4 of the opcode space is devoted to 8 bit moves. Yet,
I find 8 bit moves seldom used (at least in any of the
code that I've written/maintained). Sure, I may want to:
LD D,H
LD E,L
to save a *copy* of r.HL before indexing off of it
ADD HL,BC
But, how often do you LD C,H or LD L,B etc?
Actually, you did have to MOV things fairly often on the
8080 (dedicated registers and all - don't forget that in spite
of Intel always documenting it separately, 'M' was one of the
Octal register representations).
Sure, but that's just two instructions -- mov a to memory and
move memory to a.
I looked through two 8085 product listings (12KB and 16KB).
Aside from MVI's and MOV A/M,M/A, the only other MOV was
MOV A,B or MOV A,D (followed by ORA C and ORA E, respectively).
*Maybe* that's just a matter of personal style -- but the
code reflects 3 or 4 different authors so obviously we all
shared similar thoughts on how to use the processors resources.
And, there is no reason why xx ddd sss is any *better*
than
xs dsd sdx or sd xxd ssd for an instruction encoding. *We*
used (split) octal because our MTOS supported hot patching
and it was convenient to "hand assemble" code patches on the
fly to fix bugs, etc. (gdb wasn't around for an 8080 in ~1976)
Doesn't
this suggest that xxdddsss actually was *better* - since
you took advantage of the alignment with octal notation to make it
easier to hand-assemble... But more importantly - It's not just MOV ... IIRC,
the following
instructions on the 8080 have an octal field encoded:
"MOV", "MVI", "ADD", "ADC", "SUB",
"SBB", "INR", "DCR",
"ANA", "XRA", "ORA", "CMP",
"JZ", "JNZ", "JC", "JNC", "JP",
"JM", "JPE", "JPO",
"CZ", "CNZ", "CC", "CNC", "CP",
"CM", "CPE", "CPO",
"RC", "RNZ", "RC", "RNC", "RP",
"RM", "RPE", "RPO",
"RST"
Sure, and LXI, PSH, POP, INX have a "quad" field.
What's your point? How does memorizing the mappings of
registers to 3 bit fields help you remember the mappings
of condition codes to *that* 3 bit field?
Bottom line, you end up having to just memorize the opcodes
that you use frequently -- and remember WHERE on the quick
reference card each of the other opcodes will be found.
As to how often I use these instruction - how about
some hard
data instead of conjecture - I wrote a program to analyze 8080
source, and launched it against two of my earliest code examples,
namely - a small 8080 Monitor and BASIC interpreter that I wrote
for the UNB computer club in the 70's:
In the output below:
Directives - are any non-opcode source lines, EQU, ORG, DB etc.
Octal opcodes - are opcodes from the above list (with an octal field in them)
Non-octal opcodes - are all other opcodes (which don't have an octal field)
Filename : MONITOR.ASM
Total lines : 645
Comment/blank : 100
Directives : 39
Octal opcodes : 200
Non-octal opcodes: 306
Looks like 2/3 of the instructions encoded in my monitor have at least one
octal field representation.
Filename : BASIC.ASM
Total lines : 1975
Comment/blank : 386
Directives : 143
Octal opcodes : 494
Non-octal opcodes: 952
Looks like more than 1/2 of the instructions encoded in my BASIC have
at least one octal field.
But, again, that doesn't *mean* anything. Every JMP/CALL has an
octal field. But, do you REMEMBER them as "JMP ALWAYS" and
"CALL ALWAYS" and thus synthesize the opcodes from a 5 bit
template with an "ALWAYS" condition? Or, do you just remember
that C3 is JMP and CD is CALL?
Note that I have only use the octal fields depicted in
the Intel databook
(mainly the registers, the conditional coding and the RST vector) - in
practice (and this is going way back now) ... Octal makes sense for
other parts of the opcode as well - for example, all arithmetic opcodes
are encoded as 10 rrr aaa
Where aaa is a triplet encoding the arithmetic operation.
And you remember *those* encodings, as well??
I probably used 20-25 opcodes in 90% of what I wrote.
Aside from initial system startup (LXI SP, etc.), I can
probably disassemble most of what I'd written just by
keeping those 20 opcodes frsh in my mind (and, when
disassembling, your memory keeps getting refreshed
as you use certain code fragments over and over again)
And, tracking
16 bit load/stores (LXI's, PUSH's, etc.)
requires memorizing an encoding for *4* possible arguments.
Yes - these are included in the "Non-octal" catagory above.
And who can recall the clever encoding of all of
the
conditionals?
Tough if you think in hex (the conditon field would be split across two
nibbles ... but if you think in Octal, it's not so tough ... all conditions
are represented in the second triplet (from the right):
000 = 0 = NZ
001 = 1 = Z
010 = 2 = NC
011 = 3 = C
100 = 4 = PO
101 = 5 = PE
110 = 6 = P
111 = 7 = M
All transfer instruction are encoded: 11 ccc xxx
Where xxis:
000 = Rcondition
010 = Jcondition
100 = Ccondition >> As noted earlier, I happen to be from the
"hex" camp ... but I don't
>> think it's fair to dismiss the octal guys as "nuts" ... the use of
octal
Hmmm... *I* don't recall calling anyone "nuts". Rather, this started
with my observation:
When I was developing Z80-based products, an ongoing *battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> )
Octal? Hex? Just give me a symbolic debugger and let *it*
keep track of these minutae...
on the 8080 did have some benefit, and there were a
lot of people
who went that route - to ignore or discount this does not present an
accurate depiction of the time period.
When I worked on 8085's, we let the
MDS-800 handle the assemblies.
Burn a set of EPROMs (2 hours!), plug into the target and hope
you've stubbed enough places in the code so you could figure out
where it was based on examining odd display patterns, etc.
Stare at listings, burn another set of EPROMs after lunch.
Two turns of the crank in an 8 hour shift. Did the choice of
opcode assignments increase productivity?? Some of the guys claimed that thinking of the opcode
in Octal made
it much easier for them ... All I am saying is that I can see some
validity to their claim.
And the last P in my comment (above) was:
Octal? Hex? Just give me a symbolic debugger and let *it*
keep track of these minutae...
I don't imagine those hobbyists *prefer* using hex/decimal
keypads and 7 segment displays to write their code?
When I was
doing Z80-based designs (in the "split octal" world),
a helluva lot of energy was expended to support the "octal"
encoding -- rewriting the Zilog assembler to generate listings
in octal (INCLUDING displaying addresses in split octal!),
building run-time "monitors" to examine and patch code images
during execution, writing the associated software to do so, etc.
This would be because you didn't work in Octal (split or otherwise).
The same could be said for any encoding scheme - If some of your
users had demanded to use base 13 this too would have presented a
challange to you - but at least the "ultimate answer" would work out
correctly: (6x9=42 in base 13 :-) I'm
convinced the fact that you could get a ten-key
keypad and an inexpensive LCD to display 6 digit SPLIT octal
values had more of an impact on the octal decision than
anything about the opcode encoding -- despite the fact that
it made USING the tools more difficult (since you can only
display a 16 bit value -- *address* -- in 6 digits, you have
to multiplex the display to let the user see the *data* at
that address :< ).
That was certainly part of it - as was the fact that 7447's could
display Octal quite nicely, but didn't work so well with Hex.
But I would also say that a higher percentage of single-board
8080 machines used Octal - because it does make sense
with the instruction set. I recall
getting an EM-180 and quickly distancing myself
from the octal vs. hex debate... I'll use *symbols* instead
of dicking around with bit groupings.
Why even bother with that ... why not just use mouse clicks
and "drag and drop". In the days of wirewrap systems, homebrew front
panels
and pencil and pad assemblers, bit groupings mattered.
One question though --- since you use symbols and don't
"dick around" with bit groupings ... why is the use of Hex
over Octal so important to you? ... wouldn't one be just as
good as the other to the high level view (like some detail
burried way down in the mouse driver that you don't need
to care about when you click).
Hex vs.Octal is NOT important to me. Please reread my
original comment:
Octal? Hex? Just give me a symbolic debugger and let *it*
keep track of these minutae...
Now why some people chose octal for other processors,
which
didn't have an architectural slant toward 8 is more of a mystery
to me....
I think the fact that 0..7 fits in a decimal representation
says a lot about the "why". :-( Amazing to consider how
much "resources" got wasted on silly (in hindsight) decisions.
Sort of like PC (and other) BIOS decisions placing silly
restrictions on the size of a disk or where the boot code
can be located, etc. days, some guys liked Octal, some guys liked hex - I
worked
mainly in hex, but I didn't have a great deal of trouble going
back and forth - you were happy just to find someone who
knew the language - the particular dialect that he chose didn't
seem all that important at the time.
Clearly the debate can rage on forever - If you like hex, and
consider it the "only game in town", then thats OK by me. I
happen to see advantages to both viewpoints.
27 Apr
27 Apr
6:39 a.m.
Although
it's possible to create software that will run on an 8080
(or an 8085) and not a Z80 (I used to do this to really annoy a
friend who had a Cromemco Z80 system when I still used the
Altair 8080 :-) ... By and large, the Z80 is a superset of the
8080 - There are some flag differences which prevent it from
being a fully proper superset, however these affected very little
"real" code.
How do you define "real" code? If you're on a boat at sea and
your navigation system suddenly decides that this opcode should
not behave the way it "does", you might get a bit annoyed
when you can't find any of your lobster pots, etc. I think code
that controls the rudder of a several ton vessel moving at 20
knots is just as "real" as the code that draws a tic tac toe
board on a glass tty... :-( Actually, you
did have to MOV things fairly often on the
8080 (dedicated registers and all - don't forget that in spite
of Intel always documenting it separately, 'M' was one of the
Octal register representations).
Sure, but that's just two instructions -- mov a to memory and
move memory to a. But more
importantly - It's not just MOV ... IIRC, the following
instructions on the 8080 have an octal field encoded:
"MOV", "MVI", "ADD", "ADC", "SUB",
"SBB", "INR", "DCR",
"ANA", "XRA", "ORA", "CMP",
"JZ", "JNZ", "JC", "JNC", "JP",
"JM", "JPE", "JPO",
"CZ", "CNZ", "CC", "CNC", "CP",
"CM", "CPE", "CPO",
"RC", "RNZ", "RC", "RNC", "RP",
"RM", "RPE", "RPO",
"RST"
Sure, and LXI, PSH, POP, INX have a "quad" field.
What's your point? How does memorizing the mappings of
registers to 3 bit fields help you remember the mappings
of condition codes to *that* 3 bit field?
Bottom line, you end up having to just memorize the opcodes
that you use frequently -- and remember WHERE on the quick
reference card each of the other opcodes will be found. As to how
often I use these instruction - how about some hard
data instead of conjecture - I wrote a program to analyze 8080
source, and launched it against two of my earliest code examples,
namely - a small 8080 Monitor and BASIC interpreter that I wrote
for the UNB computer club in the 70's:
In the output below:
Directives - are any non-opcode source lines, EQU, ORG, DB etc.
Octal opcodes - are opcodes from the above list (with an octal field in them)
Non-octal opcodes - are all other opcodes (which don't have an octal field)
Filename : MONITOR.ASM
Total lines : 645
Comment/blank : 100
Directives : 39
Octal opcodes : 200
Non-octal opcodes: 306
Looks like 2/3 of the instructions encoded in my monitor have at least one
octal field representation.
Filename : BASIC.ASM
Total lines : 1975
Comment/blank : 386
Directives : 143
Octal opcodes : 494
Non-octal opcodes: 952
Looks like more than 1/2 of the instructions encoded in my BASIC have
at least one octal field.
But, again, that doesn't *mean* anything. Every JMP/CALL has an
octal field. But, do you REMEMBER them as "JMP ALWAYS" and
"CALL ALWAYS" and thus synthesize the opcodes from a 5 bit
template with an "ALWAYS" condition? Or, do you just remember
that C3 is JMP and CD is CALL? Note that I
have only use the octal fields depicted in the Intel databook
(mainly the registers, the conditional coding and the RST vector) - in
practice (and this is going way back now) ... Octal makes sense for
other parts of the opcode as well - for example, all arithmetic opcodes
are encoded as 10 rrr aaa
Where aaa is a triplet encoding the arithmetic operation.
And you remember *those* encodings, as well?? Yeah, and my quick reference card gives them all nice
HEX values that I can dig up just as easy as you can
build an opcode using all of these little tables.
I don't think so - (well with me probably, but up against one of the
good Octal guys no) - they could write the opcode down instantly,
and you would have to take time to look at the reference card.
>> As
noted earlier, I happen to be from the "hex" camp ... but I don't
>> think it's fair to dismiss the octal guys as "nuts" ... the use of
octal
Hmmm... *I* don't recall calling anyone "nuts". Rather, this started
with my observation:
When I was developing Z80-based products, an ongoing *battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> ) Octal? Hex? Just give me a symbolic debugger and
let *it*
keep track of these minutae...
Like your mouse below, symbolic debuggers didn't exist for many
of us in the mid 70's.
Probably not -
but I seem to recall that even though the 8080 was
a rather expensive chip to get, it still didn't always come with an
MDS-800 - I don't recall any of the guys in our "homebrew computer
club" having an MDS-800 (or any production computer for that
matter).
Sure. But, the rules applying to hobbyists are obviously
different than those applying to corporations trying to bring
products to market. You wouldn't suggest we NOT purchase
the MDS and, instead, get a bunch of SDK's wired to our
target hardware? Octal? Hex? Just give me a symbolic debugger and
let *it*
keep track of these minutae...
Yes - we know your view - what does this have to do with the
validity of the octal guys claims?
I don't imagine those hobbyists *prefer* using
hex/decimal
keypads and 7 segment displays to write their code?
Well... I think they *DID* prefer using keypads and displays - If
they hadn't, they would not have used them. In my case: I could
have dropped out of school and used my tuition money to buy a
development system, but I preferred to do something within my
means. I could have tossed the 8080 and taken up fly-fishing as
a hoppy, but I preferred make do with what was available to me.
For me, the keypad/display was "the way to go" at the time.
I went on to a career in development systems - and I can trace
the roots all the way back to the low-level basics I learned on
hand-built 8080 boards, and the tools I created over the years
to improve on that environment.
When I was doing Z80-based designs (in the "split
octal" world),
a helluva lot of energy was expended to support the "octal"
encoding -- rewriting the Zilog assembler to generate listings
in octal (INCLUDING displaying addresses in split octal!),
building run-time "monitors" to examine and patch code images
during execution, writing the associated software to do so, etc.
This would be because you didn't work in Octal (split or otherwise).
The same could be said for any encoding scheme - If some of your
users had demanded to use base 13 this too would have presented a
challange to you - but at least the "ultimate answer" would work out
correctly: (6x9=42 in base 13 :-) Like writing code in assembler when you could just as
readily
use a HLL.
I'm not even going to go there (I still write a substantial amount of
assembly language).
But, you're still dealing with the hobbyist world.
Every product
*we* shipped was a "single board 808x/4004 machine"... yet, they
didn't "use octal" (and we shipped thousands and thousands
of machines).
Who said that a product had to use Octal (or Hex for that matter)?
I thought we were talking about development methodology. Should
pocket calculators be developed using decimal encodings for the
micro - because the machine needs to work in decimal?
If you're a hobbyist, your time is (often) worth
nothing.
I've watched people disassemble video arcade pieces "by hand"
and reverse engineer all of the copy protection hacks in the
code.
Um, *why*?
Perhaps for the enjoyment, perhaps to learn
Because they are curious and have decided that they
can
AFFORD the time to engage in this activity. But a *business*
would never waste their time on this -- unless there was some
key IP that they were after, etc. (there are firms that expend
a great deal of resources on these sorts of activities!)
Often businesses in this industry grew from roots as a hobby,
especailly during the 70-80s.
Why even
bother with that ... why not just use mouse clicks
and "drag and drop".
Mid 70's. No GUIs. No mice. I never saw it
as a huge waste of "resources" - In the early
You didn't rewrite ("re-bug") WORKING development tools
in a production environment to add these "features".
If you've got an assembler, linkage editor, etc. that all
WORK but produce HEX listings, why rewrite them to spit out
listings in split octal? Including addresses (of opcodes,
arguments, link maps, etc.) Are you going to gain that much
in terms of productivity to offset the time spent doing this?
And the bugs that get introduced in the process? Wouldn't it be better to just live with the hex
listings
and purchase a hex keypad for your "run-time monitor"?
After all, you're only going to build a handful of those...
what's it going to cost you vs. a decimal/octal keypad -- an
extra $10??
Why would the Octal camp guys purchase Hex keypads?
Why would the Hex camp guys purchase Octal keypads?
Was there ever a "decimal camp"? - who used decimal
keypads (actually, I did, with little stickers over +, -, X, /,
C, = to convert them to A-F.
And yes, wouldn't it be better to just live with whatever
listing you get. (or even better - write the tool to produce
what you need in the first place).
Spend the resources that you "wasted"
hacking the toolchain
to purchase another *real* development system. Or, a
symbolic debugger. Etc. Don't sell your adherence to
The Old Ways as a virtue -- concentrate on getting ahead
of the curve and your competition!
We didn't "hack" toolchains - we wrote them. And the Octal
guys wrote tools that worked in Octal, Hex guys wrote tools
that worked in Hex - everyone was happy.
> days, some guys liked Octal, some guys liked hex
- I worked
> mainly in hex, but I didn't have a great deal of trouble going
> back and forth - you were happy just to find someone who
> knew the language - the particular dialect that he chose didn't
> seem all that important at the time.
>
> Clearly the debate can rage on forever - If you like hex, and
> consider it the "only game in town", then thats OK by me. I
> happen to see advantages to both viewpoints.
Nuff said - lets just agree to disagree.
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
9:23 a.m.
When I was
developing Z80-based products, an ongoing *battle*
was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
The octal camp claimed the Z80 was an "octal machine" (oh, really?)
and, for "proof", showed how so many of the opcodes could be
committed to memory just my noting the source & destination
register "codes" and packing them into an octal representation:
xx xxx xxx (of course, I wonder how well their argument would
stand up if Zilog had opted to encode the register fields
as: xs dds dsx?? :> )
It would appear that the *nuts* was implied: by (oh, really?)m Quotes
around "proof", suggestion that the opcode encoding is randomly
organized etc.
Octal? Hex? Just give me a symbolic
debugger and let *it*
keep track of these minutae...
Like your mouse below, symbolic debuggers didn't exist for many
of us in the mid 70's. I don't
imagine those hobbyists *prefer* using hex/decimal
keypads and 7 segment displays to write their code?
Well... I think they *DID* prefer using keypads and displays - If
they hadn't, they would not have used them. In my case: I could
have dropped out of school and used my tuition money to buy a
development system, but I preferred to do something within my
means. I could have tossed the 8080 and taken up fly-fishing as
a hoppy, but I preferred make do with what was available to me.
For me, the keypad/display was "the way to go" at the time. You're
missing the point: it was a waste of time to invest
all that energy in half-*ssed tools instead of moving to
more "current" technology. If your goal is to bring a product
to market (NOT to deal with hobbyists), you devote your
resources to things that can measurably improve your
productivity. Throwing resources (software and hardware
development time and money) on tools that don't make a
dramatic increase in your productivity is just foolish.
My points:
1) for many, Octal was natural - just because you consider it
half-donkeyed doesn't "make it so".
2) Had you been from the "octal camp", you would now be
stating how it wasn't suitable to put time and energy into
dealing with the half-assed hex crap. 3) Many of us started during this time period and
made do with
what we had (and learned a lot more because of it) - A lot of
us went on to productive lifetime careers in the business - so
there must have been some benefit to our approach.
Sure. All of the boards, code, cabinetry, etc. that I made
for home projects relied on techniques and materials that
I could purchase and manipulate on a hobbyist's budget.
But, I didn't refrain from using injected molded plastic
parts in designs at work! And, I didn't waste their time
engaging in discussions about whether it was best to fabricate
cases in wood or lexan (two materials I could easily work with
at home). The "wood camp" and "lexan camp" weren't appropriate
to the WORK camp!
4) I would argue that in the mid-70's, our
approach was in line
with "current" microprocessor technology, and high-end
development systems were "cutting edge" technology - I know
a lotta little (at the time) companies who worked near the
bottom.
5) Learning instruction set encodings, and finding ways to
simplify that and speed up our mental "access time" to it
DID dramatically improve our productivity.
Sure. But (aside from nostalgia), I assume only when you *have* to.
If I've got to maintain something written for a 2A03, I'll grumble
and cuss and push my rates up since I know I'll be *stuck* working
in ASM. If I have to write a BSP for a new ARM, I'll grumble a
little bit but I know there WILL be an end in sight and I (typically)
won't be stuck writing in ASM "forever". But, if I have to write a
protocol stack, I'm not even going to *think* about doing anything
more than, perhaps, checksum calculations in ASM.
Like writing code in assembler when you could
just as readily
use a HLL.
I'm not even going to go there (I still write a substantial amount of
assembly language). I never saw it as a huge waste of
"resources" - In the early
You didn't rewrite ("re-bug")
WORKING development tools
in a production environment to add these "features".
If you've got an assembler, linkage editor, etc. that all
WORK but produce HEX listings, why rewrite them to spit out
listings in split octal? Including addresses (of opcodes,
arguments, link maps, etc.) Are you going to gain that much
in terms of productivity to offset the time spent doing this?
And the bugs that get introduced in the process? > Clearly
the debate can rage on forever - If you like hex, and
> consider it the "only game in town", then thats OK by me. I
> happen to see advantages to both viewpoints.
Nuff said - lets just agree to disagree.
11:16 a.m.
My take on the hex-vs-octal 8080/Z80 debate:
My gosh, it doesn't take a mental giant to subdivide an 8 bit quantity into
either octal or hexadecimal! Hex is attractive for 8 bits in that there's
no "hole" to deal with in 16/24/32... bit quantities (although that can be
accomodated with application of a bit of grey matter).
Another reason I like hex for 8 bits is because I can output a line of 16
bytes in a dump format, complete with address and alpha translation on a
single 80-character line. Heaven knows why ZSID went to a two-line format
to do that. But if all you've got is octal, no problem, I can deal with
that, too. Or decimal, for that matter.
If you think that hex-vs-octal is hard mental work, try transposing musical
notation on the fly...
Cheers,
Chuck
1:23 p.m.
My take on the hex-vs-octal 8080/Z80 debate:
My gosh, it doesn't take a mental giant to subdivide an 8 bit quantity into
either octal or hexadecimal! Hex is attractive for 8 bits in that there's
no "hole" to deal with in 16/24/32... bit quantities (although that can be
accomodated with application of a bit of grey matter).
Another reason I like hex for 8 bits is because I can output a line of 16
bytes in a dump format, complete with address and alpha translation on a
single 80-character line. Heaven knows why ZSID went to a two-line format
to do that. But if all you've got is octal, no problem, I can deal with
that, too. Or decimal, for that matter.
Hi Chuck,
Well stated, and THANK YOU - thats exactly what I was trying to say.
Given the choice, and where it makes sense - I work in hex. but I don't
have a huge problem with other notations. I never suggested that anyone
rewrite their existing tools to support one or the other. Only that there is
some validity to others preference for different notations than I use.
On anything I have developed from scratch, I worked in hex - but all of
my tools accept binary, octal and decimal representations as well.
When I worked on the Altair, I worked in hex - even though the Altair
front panel was grouped in octal - it is simple enough to just visualize
the switches in groups of four.
When I worked on the H8 however, I usually worked in octal - the H8
has octal displays and octal keypad - the listings are all in octal, and
the tools all work in octal - It's easier to "go with the flow" than to be
constantly convertng - but I did that too when I moved code to and
from ...
No matter how "wizbang" your tools are, I think you still benefit from
a good low-level understanding of the architecture - no matter what
particular dialect you speak - the "important stuff" is still the same and
is what matters.
Cheers,
Dave
PS: And for-the-record yes, sometimes I prefer to use simple tools
and the debugger between my ears - Many a time I've found the problem
while the other guy was busy hooking up logic analyzer cables...
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
3:30 p.m.
On Thu, 27 Apr 2006, Don Y wrote:
What's the merit of arguing OCTAL vs. HEX? You
have a tool
that works and frees you from having to deal with bit twiddling.
"frees you from having to deal with bit twiddling"????
^^^^^
Isn't that WHY we do it????
That's like the sales pitch from the guy who wanted us to outsource our
software development, marketing, and in-house IT.
--
Grumpy Ol' Fred cisin at xenosoft.com
5:33 p.m.
Fred Cisin wrote:
On Thu, 27 Apr 2006, Don Y wrote:
Depends on whether or not you're the one paying the bills! :>
What's the merit of arguing OCTAL vs. HEX?
You have a tool
that works and frees you from having to deal with bit twiddling.
"frees you from having to deal with bit twiddling"????
^^^^^
Isn't that WHY we do it???? That's like the sales pitch from the guy who
wanted us to outsource our
software development, marketing, and in-house IT.
Well, the MARKETING can almost always be outsourced...
to some other group that knows equally little about your
market as the current group! :-)
17 Apr
17 Apr
5:05 p.m.
> When I was developing Z80-based products, an
ongoing *battle*
> was the use of hex vs. "split octal" (e.g., 0xFFFF -> 0377 0377).
I've worked on a machine where an 8-bit microcode adress was given in
4-digit split octal. That is, something like 1207 for A7 hex.
> The octal camp claimed the Z80 was an "octal
machine" (oh, really?)
I am trying to rememebr, but I _think_ the Intellec MCS8i has the front
panel data switches grouped in 3s (albeit only by white lines on the
panel), even though all the ROM monitor commands use hex
> and, for "proof", showed how so many of
the opcodes could be
> committed to memory just my noting the source & destination
> register "codes" and packing them into an octal representation:
> xx xxx xxx (of course, I wonder how well their argument would
> stand up if Zilog had opted to encode the register fields
> as: xs dds dsx?? :> )
Yes, but they didn't. Many of the simpler (8080) opcodes are easier to
encode in octal...
Would you claim the PDP11 was an octal or hex machine? It's 16 bit (so
hex would be more natural), but I've never seen the machine language
written in anything other than octal (or pure binary, of course). Again,
for many (but not all) instructions, there are 3-bit fields aligned on
octal digit boundaries for things like register selection.
Me, I wish they'd made those common TTL 7-segment
decoder/driver chips
display something more like hex when you got into codes past 9...
I think the display patters for 1010-1111 for the 7447A (I assume that's
one of the chips you were refereing to) came naturally from the logic
used to decode 0000-1001, along with the fact that 1111 should be a
blank. Rememebr when that chip was designed, every gate cost money :-),
it certainly isn't a 16 word * 7 bit ROM.
That said, I think it is a pity there wasn't a later TTL 7 segment
decoder chip (say a 74LS547 or something) that did display 0-F as you
might expect.
-tony
6:48 p.m.
Tony Duell wrote:
[attributions lost]
What was more amusing was two different versions -- "with tails" and
without! :>
Me, I wish
they'd made those common TTL 7-segment decoder/driver chips
display something more like hex when you got into codes past 9...
I think the display patters for 1010-1111 for the 7447A (I assume that's
one of the chips you were refereing to) came naturally from the logic
used to decode 0000-1001, along with the fact that 1111 should be a
blank. Rememebr when that chip was designed, every gate cost money :-),
it certainly isn't a 16 word * 7 bit ROM. That said, I think it is a pity there wasn't a
later TTL 7 segment
decoder chip (say a 74LS547 or something) that did display 0-F as you
might expect.
*Something* does this -- though I may have been driving LCD's
at the time (thus CMOS parts). But, I remember a 7441 (though
what I used it for I am unsure... :< )
6:59 p.m.
Don Y wrote:
Tony Duell wrote:
[attributions lost]
What was more amusing was two different versions -- "with tails" and
without! :>
The Fairchild 9368 and 9370 TTL chips provide full hex (0-9,A-F) decoding.
Available at least as early as 1975. But yes, they weren't exactly common
and they're difficult to come by today.
(7441 is the 1-of-10 NIXIE driver)
Me, I
wish they'd made those common TTL 7-segment decoder/driver chips
display something more like hex when you got into codes past 9...
I think the display patters for 1010-1111 for the 7447A (I assume that's
one of the chips you were refereing to) came naturally from the logic
used to decode 0000-1001, along with the fact that 1111 should be a
blank. Rememebr when that chip was designed, every gate cost money :-),
it certainly isn't a 16 word * 7 bit ROM. That said, I think it is a pity there wasn't
a later TTL 7 segment
decoder chip (say a 74LS547 or something) that did display 0-F as you
might expect.
*Something* does this -- though I may have been driving LCD's
at the time (thus CMOS parts). But, I remember a 7441 (though
what I used it for I am unsure... :< )
18 Apr
18 Apr
3:09 p.m.
What was more amusing was two different versions --
"with tails" and
without! :>
There's also the 'hooked 7' (segments a,b,c,f using the conventional
names), used by some Japanese manufacturers. AFAIK no TTL decoder ever
generated that one.
In the mid 70's there were several circuits in the UK magazines to turn 7
segment code back into BCD, so you could use clock/calculator/DVM chips
with built-in display drivers in other logic circuits. Most of those
encoder circuits, of course, made liveral use of the 'don't care states'.
Some of said circuits would handle both tailed and tail-less 6's and 9's,
but IIRC most of them failed on hooked 7's.
That said, I think it is a pity there wasn't
a later TTL 7 segment
decoder chip (say a 74LS547 or something) that did display 0-F as you
might expect.
*Something* does this -- though I may have been driving LCD's at the time (thus CMOS parts). But, I remember a 7441
(though
what I used it for I am unsure... :< )
1-of-10 decoder, commonly used to drive nixie tubes.
-tony
7:06 p.m.
Tony Duell wrote:
http://www.mitt-eget.com/
Several Calculator Fonts here.
What was more
amusing was two different versions -- "with tails" and
without! :>
There's also the 'hooked 7' (segments a,b,c,f using the conventional
names), used by some Japanese manufacturers. AFAIK no TTL decoder ever
generated that one. In the mid 70's there were several circuits in the
UK magazines to turn 7
segment code back into BCD, so you could use clock/calculator/DVM chips
with built-in display drivers in other logic circuits. Most of those
encoder circuits, of course, made liveral use of the 'don't care states'.
Some of said circuits would handle both tailed and tail-less 6's and 9's,
but IIRC most of them failed on hooked 7's.
But I want 9 segment Displays! :(
Ben alias woodelf
19 Apr
19 Apr
7 p.m.
woodelf wrote:
Tony Duell wrote:
http://www.mitt-eget.com/
Several Calculator Fonts here.
But calculators usually used their own silicon and could
do whatever they wanted for segment decode...
What was
more amusing was two different versions -- "with tails" and
without! :>
There's also the 'hooked 7' (segments a,b,c,f using the conventional
names), used by some Japanese manufacturers. AFAIK no TTL decoder ever
generated that one.
6:59 p.m.
Tony Duell wrote:
There was a Fairchild one, I forget the number.
I used a 7447 to replace the front panel on a Nova 2 (3?).
The OC outputs fit the Nova's bus nicely. And, by a bizarre
twist of coincidence, some of the digit encodings would
perfectly match the data intended to be seen on the bus
when a certain (reduced!) set of front panel switches
were keyed. So, we could boot, step, etc. a preloaded
core image without having all of that hardware dangling
off the front of the machine.
What was more
amusing was two different versions -- "with tails" and
without! :>
There's also the 'hooked 7' (segments a,b,c,f using the conventional
names), used by some Japanese manufacturers. AFAIK no TTL decoder ever
generated that one.
In the mid 70's there were several circuits in the UK magazines to turn 7
segment code back into BCD, so you could use clock/calculator/DVM chips
with built-in display drivers in other logic circuits. Most of those
encoder circuits, of course, made liveral use of the 'don't care states'.
Some of said circuits would handle both tailed and tail-less 6's and 9's,
but IIRC most of them failed on hooked 7's.
That
said, I think it is a pity there wasn't a later TTL 7 segment
decoder chip (say a 74LS547 or something) that did display 0-F as you
might expect.
*Something* does this -- though I may have been driving LCD's
at the time (thus CMOS parts). But, I remember a
7441 (though
what I used it for I am unsure... :< )
1-of-10 decoder, commonly used to drive nixie tubes.
17 Apr
17 Apr
10:59 p.m.
On 4/18/2006 at 1:05 AM ard at p850ug1.demon.co.uk wrote:
That said, I think it is a pity there wasn't a
later TTL 7 segment
decoder chip (say a 74LS547 or something) that did display 0-F as you
might expect.
Well, the MC4039 used the Moto XC170 mask ROM as its core. The Moto data
sheet for the 170 mentions that codes 1010-1111 could be reprogrammed to
other characters. The 4039 had 1010=blank, 1011=dot, 1100=hyphen,
1101-1111=blank.
The MC14495 also does the hex-to-7 segment decoding.
Of course, one could always glom onto a few HP 5082-7340 displays...
Cheers,
Chuck
6:27 p.m.
Roy J. Tellason wrote:
Me, I wish they'd made those common TTL 7-segment
decoder/driver chips
display something more like hex when you got into codes past 9...
Some do. I recall feeling "giddy" when I had a design with
individual control of the segments. Sure, there was another
(trivial) step for the display multiplexor to perform
(mapping "codes" to segments) but we were no longer stuck
with "mode 79", "mode 35", etc.
Of course, things were only marginally better for the user
as many of the (ahem) "words" that you could display
were really pathetic! :-( But, PGD's were neat looking.
Almost as neat as nixies!
19 Apr
19 Apr
6:23 a.m.
Don Y schrieb:
Roy J. Tellason wrote:
The 9368 has
proper hex decoding of the pseudo tetrades - but those days
it was almost impossible to locate, compared to the common 7447 types.
Eventually, I programmed 74188s for that purpose, after a short period
(as a pupil) where I made a diode matrix decoder based on a 74154 -
this soldered well on breadboards.
Holger
Me, I wish they'd made those common TTL
7-segment decoder/driver
chips display something more like hex when you got into codes past 9...
Some do. I recall feeling "giddy" when I had a design with
2:40 p.m.
Some do. I
recall feeling "giddy" when I had a design with
The 9368 has proper hex
decoding of the pseudo tetrades - but those days
it was almost impossible to locate, compared to the common 7447 types.
Eventually, I programmed 74188s for that purpose, after a short period (as a pupil) where I made a diode matrix decoder based
on a 74154 -
this soldered well on breadboards.
Another trick was to use the 7447 for 0-7 (or 0-9, depending on how you
felt), decode the other 8 or 6 inputs using a 1-of-n decoder (like a
7442), and re-encode those with a diode matrix, blank the outputs of the
7447 for those input combinations (either using the blanking input, or by
forcing the data inptus to 1111) and finally logically OR the outputs of the
diode matrix and the 7447
-tony
20 Apr
20 Apr
12:34 a.m.
New subject: LED hex decoding, (was: 8080 Assembler-Text Editor (ATE))
Tony Duell schrieb:
These days you can do it with a small GAL (like a 16V8), but it's not
quite as obvious as it sounds. There are only 8 product terms per output,
Sure you can do this nowadays. I was talking about 20 years ago.
Today, the 9368 is still available from several surplus chip vendors -
albeit for prices that makes one believe the chip was not silicon but
carbon (i.e. diamond).
Realistically, today one wouldn't even consider GALs for it - Noone
still makes counters with the classical 7490+7475+7447 triple. Multiplex
the whole stuff with a cheap PIC controller, or for special purposes,
use something like the CA3161/CA3162 which are also still available,
surprisingly. Heck, I recently even encountered a 8279, also an
interesting gadget from the past.
Some do. I recall feeling "giddy" when I
had a design with
The 9368 has proper hex decoding of the pseudo tetrades - but those days
it was almost impossible to locate, compared to the common 7447 types.
Eventually, I programmed 74188s for that purpose, after a short period
and IIRC some segments are on for more than 8 of the
input combinations.
What you do is that if there are 8 or fewer input combinations that turn
on a given segment, you program the product terms for those combinations,
if there are 8 or more, you program the product terms for the input
combinations where that segment is _off_, and then invert the signal in
the output logic macrocell.
Another trick was to use the 7447 for 0-7 (or 0-9, depending on how you
felt), decode the other 8 or 6 inputs using a 1-of-n decoder (like a
7442), and re-encode those with a diode matrix, blank the outputs of the
7447 for those input combinations (either using the blanking input, or by
forcing the data inptus to 1111) and finally logically OR the outputs of the
diode matrix and the 7447
This is not really straight forward, and probably not even resource
saving, is it? A diode is maybe 2 Eurocent, but in the past where such
tricks where necessary, a 7447 and a 7442 and some diode matrix summed
up to much more. But I remember I once have seen an application note for
this, maybe in the old TTL cookbook (?).
Holger
17 Apr
17 Apr
11:14 a.m.
Does anyone remember the conflict between the MITS and
IMSAI (actually, the
rest of the world) about using octal vs. hex representations of data? It's
very obvious just by looking at the two systems--the Altair 8800 spaces the
front panel toggles in groups of 3, whereas the IMSAI 8080 color-codes the
switches in groups of 4. I think that the early MITS assembler used octal,
although it's very hard to remember.
Yes - one of the things I didn't like so much about the Altair - I came from an
IBM mainframe background and HEX was "in my blood" (I still find myself
going 8, 9, 10, A, B, ... oh crap ...) when I am counting things (not computer
related) sometimes.
To be fair to MITS however - note that the Intel 8080 processor was deisgned
for octal - the register fields are three bits an on octal boundaries, as are the
condition bits and restart vectors - most of the instruction set was originally
documented in octal - I think Ed and gang just did "what seemed to make
sense at the time".
More than one Altair owner disagreed - I never modified my machine, but
just got used to "seeing the switches in groups of four" - At least a couple
of the photos I've seen on the net have lines drawn on the front panel to
separate the groups of four. Another Altair 8800 that I picked up later has
what I think is a really elegant solution. The owner simply used some of the
little plastic colored toggle switch lever covers to mark the second bank of
four switches from the right - makes it easy to see them in hex, and does
not permanently alter the machine.
And ... apparently some IMSAI owners also disagreed! - One of my
IMSAI front panels has the switch colors arranged in groups of three
(which points out a nice feature of the IMSAI kit - you could built it
either way).
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
1:31 p.m.
On Monday 17 April 2006 07:03 am, Joe R. wrote:
At 03:18 PM 4/16/06 -0600, you wrote:
I've found those to be somewhat interesting to read, and wouldn't mind
reading a copy of that one in particular (if you feel like parting with it
for a while :-).
Chuck Guzis wrote:
I believe that I have a copy that I bought off of E-bay. I went and
looked for it but couldn't find it (I have WAY too many books around here!)
However I did find a book on DBUG by Titus, Titus, Rony and Larsen. It's
one of the Blacksburg series of Bugbooks. Do you want to rephrase that? I do recall a
simple assembler that did
not implement alpha constant strings longer than 2 bytes (as a DW). To
code a long string you had to do something like this:
I found the book on the web after a google search.TEA, an 8080/8085
Co-Resident Editor/assembler I can't find any used copies of the book
however. I've never used it but it says that it can run in
1k!
Not surprising there. I was working on a monitor/debugger a while back and it
had just edged past fitting into a 2716 and would fit in a 2732 with lots of
extra room to spare, but I hadn't optimized it for space or cleaned it up
any when I put it aside, some time ago.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
12:37 p.m.
On 4/16/06, woodelf <bfranchuk at jetnet.ab.ca>
wrote:
I found the book on the web after a google search.
TEA, an 8080/8085 Co-Resident Editor/assembler
I can't find any used copies of the book however.
amazon.com lists a few used copes in the $4 - $10 range.
ISBN: 0672216280
16 Apr
16 Apr
3:05 p.m.
I've got a hex dump here of an Assembler/Text
Editor for the 8080,
called (IIRC) ATE. It's what I used on my first computer (8080 S100 8k
+ KC tape). It's about 4k, so I had 4k for source + object, or it could
work as a 2-pass assembler reading the source off tape.
Does anyone know about this? Is it of interest to anyone? I could
either type it in, or scan the listing for someone else :-) The code
would need patching for console & tape I/O, and I don't have any
documentation on how to do this, or even how to use it, but it can't be
too difficult. Forgive me, it's been almost 30 years!
You may be interested in my ALPS (Assembly Language Programming System)
which I developed originally for my Altair back in late 70's/early 80's - I have
versions of it for both my own DMF operating system, as well as NorthStar DOS.
It consists of three main programs:
[Most of my early Altair material was developed using this.]
EDIT
- Integrated line editor and 8080 assembler. Simple but decent line editor,
and two-pass assembler that has everything you need. IIRC there's about
25 commands. The entire program is 3K in size.
DIS
- 8080 disassembler - builds symbol table and has other goodies to
regenerate a workable source file - can produce output compatible
with EDIT above - this program is 2K in size.
TEST
- 8080 Debugger - Memory/Register Dump & Examine/Change,
block move fill etc. Breakpoints, Software-single step (can step
over subroutine calls etc.) Built in disassmbler - nice companion
to EDIT. IIRC about 15 commands.
This program is also 3K in size.
Both the NorthStar and DMF executables are included on the disks for
my Altair simulator - I have also included the source disk which contains
all of the source code to the three programs. You can build them on the
simulator under EDIT, or you can use the ADI disk image utility to
extract the source files to PC files if you like, and I believe they will
assemble with my PC ASM85 with little or no changes...
Dave
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
3:20 p.m.
You may be interested in my ALPS (Assembly Language
Programming System)
Forgot to mention - the documentation is posted on my web site - in the Altair
section, under Documentation, subsection "My own software".
--
dave06a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
6813
days inactive
6825
days old
59 comments
13 participants
participants (13)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
dave06a＠dunfield.com -
dgy＠DakotaCom.Net -
dmabry＠mich.com -
glen.slick＠gmail.com -
hilpert＠cs.ubc.ca -
holger.veit＠ais.fraunhofer.de -
ljw-cctech＠ljw.me.uk -
rigdonj＠cfl.rr.com -
rtellason＠blazenet.net