Altair 8K BASIC source restoration project

[Udo Munk]

All files mentioned are available at:

http://www.autometer.de/unix4fun/z80pack/ftp/altair/

Sometime around 2009 I found a PDF document on the Internet, that
starts with a Reference Manual for Altair 4K and 8K BASIC. Filename
of that is AltairBasic_1975.pdf. I cannot remember anymore where I
found this, sorry, I just archived it for later use in 2009, and
use of it is now.

Someone appended a few pages with handwritten notices. I can't read
and understand everything written, English is not my native language
and I have problems to guess about the parts I can't read. If anyone
can read/guess it completely I would appreciate a machine readable file
with the text, thanks.

Then someone added a listing of an assembly of an 8K BASIC interpreter.
This source was typed in by someone, the filename is basic8k78.org.

Looks like it was written for a cross assembler running on some minicomputer,
I can't remember about an assembler using the syntax in this source. It
was not written for the 8080 microcomputer systems, their assemblers all
followed the Intel syntax pretty close.

To get the thing assembled I used Microsoft m80 and for that I had to
make modifications, mostly for the character literals used like 'A+128.
This is not accepted by any assembler I know, so changed that all to
'A'+128 and so on. The file with this modifications done is named
basic8k78-1.mac and it assembles error free with m80.

This BASIC interpreter uses some ROM monitor for I/O, which I don't know
and I don't have. So I added tty I/O functions with the appropriate names
for the Altair 88-SIO2. The name of this file is basic8k78-2.mac.

If you build an Intel hex file from this last version with:
m80 basic,basic=basic
l80 basic,basic/n/x/e
on a CP/M system you will get the file with name basic8k78.hex.

And if you run that on the Altair machine it looks like that:

11704 BYTES FREE

BASIC, Version of 02/03/78
START

OK
*

It is a working BASIC interpreter and runs small BASIC test programs. It
might still have bugs from typing in the source.

Now the big question is: where does this come from? The early Altair BASIC
version were written by Microsoft and if one compares this 8k source
with the annotated BASIC 4K 3.2 here:

http://altairbasic.org/

one finds some similarities e.g. in the tables for all the BASIC commands.
In the strings with the commands bit 7 is set in the last character. In the
table with arithmetic ops the precedence for +- is 79H in both versions.

Anyone any idea about this?

[Steve Nickolas]

On Wed, 9 Jul 2014, Udo Munk wrote:

> one finds some similarities e.g. in the tables for all the BASIC commands.
> In the strings with the commands bit 7 is set in the last character.

Pretty typical of MS BASIC. At least, the 6502 dialect does this too.

-uso.

[Dennis Boone]

> Looks like it was written for a cross assembler running on some
> minicomputer, I can't remember about an assembler using the syntax in
> this source. It was not written for the 8080 microcomputer systems,
> their assemblers all followed the Intel syntax pretty close.

The handwritten notes include instructions on saving (csave) over a
communications line to a mainframe running the Stanford Timesharing
System, one of the first timesharing systems available for S/360.
WYLBUR was the editor component of that system. STS was of course
ported to S/370 and later hardware, which are more likely to have
been the actual host in the MITS era. One presumes that there's some
sort of modem arrangement attached where the basic system expects a
cassette unit to exist, and clearly there was some sort of software
for acting like a terminal.

De

[Udo Munk]

I know, I had a Commodore PET 2001 with the 6502 BASIC. This is why I believe
that the older part in uppercase of this source was written by Microsoft.
The 78er date is from someone who worked with this old sources 1978 and used
lowercase for the changes made.

[Udo Munk]

Very interesting, thanks, that explains some things I didn't understand.
Someone modified csave and cload in such a way, that it probably works
like you are saying.

The functions for terminal I/O have comments about a "3010". Seems to be
a video terminal because clear screen was implemented. I searched for an
IBM 3010 terminal already, but I couldn't find anything useful.

[G. Beat]

WYLBUR, now there is an application from my distant past (30+ years ago).

IBM numbering:
3174 : Cluster controller for IBM SNA (system network architecture) terminals
3178 : lower cost terminal (1983)
3179 : low cost colour terminal (1984)
3104 : low-cost R-loop connected terminal for the IBM 8100 system

[glen herrmannsfeldt]

2741 : The terminal I first used with WYLBUR
3705 : The device that allows ASCII terminals to be used.

-- glen

[Udo Munk]

On Thursday, July 10, 2014 8:31:17 PM UTC+2, glen herrmannsfeldt wrote:

So maybe there was a IBM 3010 terminal? I can only remember about
using 31xx and 32xx terminals.

[glen herrmannsfeldt]

Udo Munk <udo....@freenet.de> wrote:

(snip, I wrote)

>> 2741 : The terminal I first used with WYLBUR
>> 3705 : The device that allows ASCII terminals to be used.

> So maybe there was a IBM 3010 terminal? I can only remember about
> using 31xx and 32xx terminals.

The ASCII 3101 is the only one in terminfo for unix.

-- glen

[Dennis Boone]

> The ASCII 3101 is the only one in terminfo for unix.

It's 80s era though.

De

[Jeff Jonas]

>WYLBUR, now there is an application from my distant past (30+ years ago).

My high school's primary computer access
was via an IBM RJE (remote job entry) terminal & modem.
Card reader, line printer & console w/keyboard for operator intervention.
(Francis Lewis high school in the 70s also had a PDP8/e
for interactive EDU-25 BASIC to 2 Teletypes).

I used to read the MOTD (message of the day) on the blast pages.
Once it said something about not running BOBO and Wylbur at the same time.
I thought Wylbur was the guy from the Mr. Ed TV show
since we didn't have any interactive terminals at the time!

Around 1977 the NYC Board of Education/UAPC administrative system
was upgraded with a 3705 or equivalent
allowing plain terminal access: DECwriter, ADM3A.
The line printer was still used for report cards and student schedules,
but the office terminals were great for short things: updates, changes.

UAPC had a fun naming scheme: BAT-everything,
just like the 60s Batman TV show.
Use BAT-info to list the BAT-files.

[glen herrmannsfeldt]

Jeff Jonas <je...@panix.com> wrote:
>> WYLBUR, now there is an application from my distant past
>> (30+ years ago).

> My high school's primary computer access
> was via an IBM RJE (remote job entry) terminal & modem.
> Card reader, line printer & console w/keyboard for operator
> intervention.
> (Francis Lewis high school in the 70s also had a PDP8/e
> for interactive EDU-25 BASIC to 2 Teletypes).

My 11th and 12 grade high school had CALL/OS access on a
S/370 system (1974 - 1976). I believe that CALL/OS was
pretty old by then, maybe free from IBM. One ASR33 terminal
per school in the district, which seems to have 26 high schools.

CALL/OS allows time-shared BASIC, FORTRAN, and PL/I access,
though the PL/I compiler doesn't allow for the full (PL/I F)
language. (I had the PL/I (F) manuals already, and would find
some things that didn't work.) I did mostly PL/I, others
more BASIC and FORTRAN.

(Montgomery County Public Schools in Maryland.)

I don't know if they also had something for middle schools.

-- glen

[Jeff Jonas]

glen:

>My 11th and 12 grade high school had CALL/OS access on a
>S/370 system (1974 - 1976). I believe that CALL/OS was
>pretty old by then, maybe free from IBM. One ASR33 terminal
>per school in the district, which seems to have 26 high schools.

Ack! What a horrible student to terminal ratio!
What a far cry from the one-laptop-per-child!

>CALL/OS allows time-shared BASIC, FORTRAN, and PL/I access

I guess your FORTRAN didn't require
every statement starting at column 7.

> though the PL/I compiler doesn't allow
> for the full (PL/I F) language.

I'm glad to hear you learned PL/I too.
That was the most useful step towards C at the time,
not that structured programming was in vogue at the time.

The RJE terminal allowed us to connect to 3 mainframes:

UADP (University Application Data Processing)
was solely for administration at the time.
Student jobs were allowed in later years.
Richard Wonder worked there and was dating one of the teachers,
so I shuttled messages between then until they got private terminals.

MIDP was the NY Board of Education System.
I think it was an IBM 370 running HASP, then JES2.

CCNY's IBM 360 had many more languages from which to choose:
WATFIV (student version of FORTRAN),
PL/C (student version of PL/I), SNOBOL,
and overnight jobs for number crunching.

-- jeffj

[glen herrmannsfeldt]

Jeff Jonas <je...@panix.com> wrote:

(snip, I wrote)

>>My 11th and 12 grade high school had CALL/OS access on a
>>S/370 system (1974 - 1976). I believe that CALL/OS was
>>pretty old by then, maybe free from IBM. One ASR33 terminal
>>per school in the district, which seems to have 26 high schools.

> Ack! What a horrible student to terminal ratio!
> What a far cry from the one-laptop-per-child!

>>CALL/OS allows time-shared BASIC, FORTRAN, and PL/I access

> I guess your FORTRAN didn't require
> every statement starting at column 7.

Hmm. I don't remember now. I think it did, but maybe the editor
made it easy to do.

In college, we had a PDP-10 and TOPS-10, and I never liked the
way that DEC Fortran compilers used tabs. A tab would get you
to column 8 (or 9, I forget now) but count it as column 7.
I always spaced out to column 7 instead.

-- glen

[Charles Richmond]

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:lpqevh$vvh$1...@speranza.aioe.org...

Glen, even with IBM FORTRAN IV, you did *not* have to begin in column 7.
You had to begin in column 7 or *later*. You could start all your
statements in column 10 if you wanted.

--

numerist at aquaporin4 dot com

[glen herrmannsfeldt]

Charles Richmond <nume...@aquaporin4.com> wrote:

(snip, I wrote)

>> In college, we had a PDP-10 and TOPS-10, and I never liked the
>> way that DEC Fortran compilers used tabs. A tab would get you
>> to column 8 (or 9, I forget now) but count it as column 7.
>> I always spaced out to column 7 instead.

> Glen, even with IBM FORTRAN IV, you did *not* have to begin in column 7.
> You had to begin in column 7 or *later*. You could start all your
> statements in column 10 if you wanted.

Yes. And if tab went to, and counted as, column 9, that would
have been fine, but it goes to column 9 and counts as 7.

-- glen

[Axel Berger]

Charles Richmond wrote on Sun, 14-07-13 04:15:

>You could start all your statements in column 10 if you wanted.

I made a point (still do, but now of course in files, not on punch
cards) of entering all numerical data as floats and converting to
integer, to prevent an extra or missing space from becoming significant.

[dott.Piergiorgio]

Il 12/07/2014 05:25, glen herrmannsfeldt ha scritto:
> (I had the PL/I (F) manuals already, and would find
> some things that didn't work.) I did mostly PL/I, others
> more BASIC and FORTRAN.

I guess that you will have mail from the good ol' Al ;)

Generally, this thread drift suggest me to be on BOLO for updates on
bytesavers ;)

Best regards from Italy,
dott. Piergiorgio.

[Udo Munk]

I uploaded new files to the z80pack repository. A few typos have been fixed
and the generated hex code has been verified against the listing, the sources
now are believed to be free of typos. Also sources were modified so that rmac
is used instead of m80, because m80 computes some wrong values without any
warning for some of the expressions used in this source.

[billc...@iscmns.org]

I've arrived at this thread a bit late... :)

Back in 1978 I was paid to disassemble MITS basic for a well know blue chip company. (We never ripped off the copyright owner - it was merely an exercise). The diassembler was written in PL/M-80 and symbols, comments and control sections were hard coded in the PLM.

I recall the BASIC interpreter had many jumps into the middle of instructions, and self mofifying code. Ugh! Later I optimized the code by, for example, making functions such as MID$ ( a single byte rather than 2. I added some disk I/O too. It's all a distant memory now! :)

[Udo Munk]

On Monday, December 1, 2014 8:46:53 PM UTC+1, billc...@iscmns.org wrote:
> I've arrived at this thread a bit late... :)
>
> Back in 1978 I was paid to disassemble MITS basic for a well know blue chip company. (We never
> ripped off the copyright owner - it was merely an exercise). The diassembler was written in PL/M-80
> and symbols, comments and control sections were hard coded in the PLM.

Very interesting, that explains why it looks like a BASIC interpreter written by Micro-soft but
the source obviously isn't original MS source. Also the IBM devices are explained now,
that really puzzled me because Gates and his friends were (ab)using a PDP-10 machine for
writing the MITS BASIC interpreter.

> I recall the BASIC interpreter had many jumps into the middle of instructions, and self modifying

> code. Ugh! Later I optimized the code by, for example, making functions such as MID$ ( a single
> byte rather than 2. I added some disk I/O too. It's all a distant memory now! :)

Well, so far the author of this sources was unknown, I think we should add some comments
to the sources, so that others later know where this came from. Maybe you could write up
something as far as you can remember, that could be added as comment to the source file.

[glen herrmannsfeldt]

billc...@iscmns.org wrote:

> I've arrived at this thread a bit late... :)

> Back in 1978 I was paid to disassemble MITS basic for a well know
> blue chip company. (We never ripped off the copyright owner - it
> was merely an exercise). The diassembler was written in PL/M-80
> and symbols, comments and control sections were hard coded
> in the PLM.

> I recall the BASIC interpreter had many jumps into the middle of
> instructions, and self mofifying code. Ugh!

Yes, a favorite trick for many 8 bit processors is to put a two
byte instruction in the place where a 16 bit immediate value goes
in a compare instruction. If you execute the compare and ignore
the result, it isn't executed. Yes, it makes it harder to
disassemble.

And also, many early microprocessors required self-modifying code
to do some of the things that needed to be done.

> Later I optimized the code by, for example, making functions
> such as MID$ ( a single byte rather than 2. I added some
> disk I/O too. It's all a distant memory now! :)

-- glen

[Steve Nickolas]

On Tue, 2 Dec 2014, glen herrmannsfeldt wrote:

> Yes, a favorite trick for many 8 bit processors is to put a two
> byte instruction in the place where a 16 bit immediate value goes
> in a compare instruction. If you execute the compare and ignore
> the result, it isn't executed. Yes, it makes it harder to
> disassemble.

Never seen it done on the Z80, but it's a classic trick on the 6502.

-uso.

[Bill Gunshannon]

In article <m5jk3v$tnc$1...@speranza.aioe.org>,

glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> billc...@iscmns.org wrote:
>
>> I've arrived at this thread a bit late... :)
>
>> Back in 1978 I was paid to disassemble MITS basic for a well know
>> blue chip company. (We never ripped off the copyright owner - it
>> was merely an exercise). The diassembler was written in PL/M-80
>> and symbols, comments and control sections were hard coded
>> in the PLM.
>
>> I recall the BASIC interpreter had many jumps into the middle of
>> instructions, and self mofifying code. Ugh!
>
> Yes, a favorite trick for many 8 bit processors is to put a two
> byte instruction in the place where a 16 bit immediate value goes
> in a compare instruction. If you execute the compare and ignore
> the result, it isn't executed. Yes, it makes it harder to
> disassemble.

I first came across this working with the TRS80 version of Tiny Pascal.
I dis-assembled the Model I version hoping to re-ORG it to clear the ROM
and make it runnable on the Model III. Surprise!!! Didn't work. :-)

>
> And also, many early microprocessors required self-modifying code
> to do some of the things that needed to be done.

Again, on the TRS80. There was one INP subroutine and they poked the
address after it for different ports before calling it.

Those were the days.... :-)

bill

>
>> Later I optimized the code by, for example, making functions
>> such as MID$ ( a single byte rather than 2. I added some
>> disk I/O too. It's all a distant memory now! :)
>
> -- glen

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[retrogear]

> >> I recall the BASIC interpreter had many jumps into the middle of

> >> instructions, and self modifying code. Ugh!

> >
> >
> > And also, many early microprocessors required self-modifying code
> > to do some of the things that needed to be done.
>
> Again, on the TRS80. There was one INP subroutine and they poked the
> address after it for different ports before calling it.
>

I'm in the process of restoring the source of Imsai Imdos and they also did
all of the above. It contains much self-modifying code. It supported both the FIF and DIO floppy controllers which they poked in the corresponding port addresses.

Larry G

[j]

IIRC, instructions in the middle of a comparison were pretty common on the
HP-65 calculator back in the 70's too. The 'if-false-skip-2-steps' logic
allowed that. But the later HP-67 skipped one step so it didn't last.
-John

[glen herrmannsfeldt]

Bill Gunshannon <bi...@server3.cs.scranton.edu> wrote:

(snip, I wrote)

>> Yes, a favorite trick for many 8 bit processors is to put a two
>> byte instruction in the place where a 16 bit immediate value goes
>> in a compare instruction. If you execute the compare and ignore
>> the result, it isn't executed. Yes, it makes it harder to
>> disassemble.

> I first came across this working with the TRS80 version of Tiny Pascal.
> I dis-assembled the Model I version hoping to re-ORG it to clear the ROM
> and make it runnable on the Model III. Surprise!!! Didn't work. :-)

I think my disassemblers from that time noted jumps into instructions,
such that one could figure this out. But I might not have added that
until I saw programs actually do it.

(snip regarding self-modifying code)

> Again, on the TRS80. There was one INP subroutine and they poked the
> address after it for different ports before calling it.

The 8086 added IN and OUT instructions with the port in a register.

I don't remember that the 8086 has an INT instruction with the
interrupt number in a register, though.

Seems like the EXECUTE instruction has been lost over the years.

IBM S/360 has EX that allows one to execute one instruction,
with a new value for the second byte (where the length code goes
in many instructions, or the SVC value in SVC instruction) that
avoids many cases that would otherwise need self-modifying code.

All S/360 processors are designed to work right with self-modified
code, including the case where instruction prefetch might have already
fetched the instruction. It might flush the pipeline on pipelined
processors, though.

The 8086 does not detect modifications to already fetched
instructions, which as I remember is how you tell the 8088
from the 8086. (That is, the official Intel method.)

-- glen

[hl351ge]

It's even worse on Z80; not only the use of LDHL #xxyy (sorry, I prefer
the 8080 mnemonics of Zilog's) where the payload xxyy is a valid 2 byte
instruction (often mvi a,#yy) is quite common in the BASICs I have
analyzed, but sometimes you also find the use of undocumented IXH/L,
IYH/L codes which are synthesized from the common H/L instructions (such
as "add h") by prefixing them with $dd and $fd. Prominent example for
extensive abuse of them is the 12K Zapple BASIC - the whole floating
point code in it not only swaps between both register banks
continuously, but also extensively does IXH/L arithmentic as part of the
mantissa of numbers is stored in IX.

-hl

P.S. Disassembly listing of Zapple BASIC on PM request

[Johny B Good]

On Wed, 03 Dec 2014 09:36:45 +0100, hl351ge <hl3...@gmx.net> wrote:

>Am 02.12.2014 um 08:27 schrieb Steve Nickolas:
>> On Tue, 2 Dec 2014, glen herrmannsfeldt wrote:
>>
>>> Yes, a favorite trick for many 8 bit processors is to put a two
>>> byte instruction in the place where a 16 bit immediate value goes
>>> in a compare instruction. If you execute the compare and ignore
>>> the result, it isn't executed. Yes, it makes it harder to
>>> disassemble.
>>
>> Never seen it done on the Z80, but it's a classic trick on the 6502.
>>
>> -uso.
>
>It's even worse on Z80; not only the use of LDHL #xxyy (sorry, I prefer
>the 8080 mnemonics of Zilog's) where the payload xxyy is a valid 2 byte

Sorry! I had to read that twice. If you mean you prefer Zilog's
assembly language mnemonics and more logical syntax over that of
Intel's, then I agree. I've seen assembly listings for Z80 code
written in TDZL(?) pseudo 8080 code style, presumably for the benefit
of those unfortunates who had previously only written in 8080
assembler and it highlights the clumsiness of 8080 assembly coding
even more.

>instruction (often mvi a,#yy) is quite common in the BASICs I have
>analyzed, but sometimes you also find the use of undocumented IXH/L,
>IYH/L codes which are synthesized from the common H/L instructions (such
>as "add h") by prefixing them with $dd and $fd. Prominent example for
>extensive abuse of them is the 12K Zapple BASIC - the whole floating
>point code in it not only swaps between both register banks
>continuously, but also extensively does IXH/L arithmentic as part of the
>mantissa of numbers is stored in IX.
>

You can do some seemingly zany and imaginitive assembly language
coding once you're totally familiar with a particular processor's
quirks and foibles. :-)
--
J B Good

[Steven Hirsch]

On 12/03/2014 12:11 PM, Johny B Good wrote:

>> It's even worse on Z80; not only the use of LDHL #xxyy (sorry, I prefer
>> the 8080 mnemonics of Zilog's) where the payload xxyy is a valid 2 byte
>
> Sorry! I had to read that twice. If you mean you prefer Zilog's
> assembly language mnemonics and more logical syntax over that of
> Intel's, then I agree. I've seen assembly listings for Z80 code
> written in TDZL(?) pseudo 8080 code style, presumably for the benefit
> of those unfortunates who had previously only written in 8080
> assembler and it highlights the clumsiness of 8080 assembly coding
> even more.

I'm glad it's not just me. I've never been comfortable reading (never mind
writing) in Intel mnemonics. If I have any non-trivial code maintenance to
perform, the first thing I do is translate it to Zilog form.

[Ed]

Johny B Good wrote:
> ...

> If you mean you prefer Zilog's
> assembly language mnemonics and more logical syntax over that of
> Intel's, then I agree.

Which logical syntax? This one ...

ADD A,s
ADC A,s
SUB s
SBC A,s
XOR s
etc

:)

[dottor Piergiorgio M. d' Errico]

Il 04/12/2014 00:24, Steven Hirsch ha scritto:
> I'm glad it's not just me. I've never been comfortable reading (never
> mind writing) in Intel mnemonics. If I have any non-trivial code
> maintenance to perform, the first thing I do is translate it to Zilog form.

well, I think I would use 8080 mnemonics if I write code intended to run
also on 8080...

side question, what was the incompatibility between 8080 and Z80 whose
prevented 4k Basic running on z80 machines ?

[Udo Munk]

On Thursday, December 4, 2014 10:25:35 AM UTC+1, dottor Piergiorgio M. d' Errico wrote:

> side question, what was the incompatibility between 8080 and Z80 whose
> prevented 4k Basic running on z80 machines ?

The problem is that the Z80 uses the parity flag also for overflow, so
the flag is set different after arithmetic instructions and the following
branches are wrong then. Not a problem normaly, but they saved a few bytes
by not doing an ORA A to check for 0 e.g. Understandable if one needs to
get a BASIC interpreter into 4KB, but also the 8KB and extended versions
have this problem.

[hl351ge]

Religious war on style, as usual.

Sorry, thread is dead for me.

Contributions here are unwanted.

-hl

[Johny B Good]

I presume you're referring to the "Cart before The Horse" syntax.
This would be the least problematical issue to the neophyte
programmer, especially for one using CP/M.

A better example would have been the LD of Z80 assembly code versus
the STO and MOV of 8080 code.

I think there more inconsistencies in 8080 assembler but I can't
recall them. The last time I programmed in Z80 assembler was some 30
years ago. Thankfully, I still possess my Zaks book to refresh my
memory of the more obscure instructions.

My repair attempts to revive the machine I did all of my assembly
language programming on, a Transam Tusacan S100 bus desktop computer,
are currently in hiatus. If I succeed in resurrecting said computer,
I'll be dipping into that book with a veangance. :-)
--
J B Good

[Ed]

Johny B Good wrote:
> On Thu, 4 Dec 2014 18:31:18 +1100, "Ed" <inv...@nospam.com> wrote:
>
> >Which logical syntax? This one ...
> >
> > ADD A,s
> > ADC A,s
> > SUB s
> > SBC A,s
> > XOR s
> > etc
> >
> >:)
>
> I presume you're referring to the "Cart before The Horse" syntax.
> This would be the least problematical issue to the neophyte
> programmer, especially for one using CP/M.

I was referring to the inconsistent use of A, s Where it becomes
an issue IMO is when your Z80 assembler fails to pick out the illegal
syntax.

> A better example would have been the LD of Z80 assembly code versus
> the STO and MOV of 8080 code.

I never heard of anyone claiming difficulty learning 8080 assembly
before the Z80 came on the scene.

Zilog's intent for the Z80 was to be fully software compatible with
the 8080 so it could take advantage of the existing 8080 user and
software base. What they couldn't copy without ending up in court
was Intel's mnemonics.

> The last time I programmed in Z80 assembler was some 30
> years ago. Thankfully, I still possess my Zaks book to refresh my
> memory of the more obscure instructions.

Indeed it was Zaks book that incorrectly listed SUB s as SUB A, s

I'm unaware of any 8080 literature that got Intel's syntax wrong.

FWIW I use Zilog mnemonics for general asm work because it's more
widely used than Intel's. In Forth assembler I use TDL (extended Intel)
mnemonics because they're compact to use and implement - which
befits the Forth paradigm. Because I can justify each of these usages
to myself, I find neither mnemonic system particularly difficult or
confusing to program. If anything, it's fun to be able to switch between
the two. Like riding two different bikes and appreciating each for
what it is :)

[billc...@iscmns.org]

Alas I threw out my ISIS 8" floppies and listings 25 years ago! Nevertheless I recall 2 key snippets of information about this source. Reserved words (like "FOR", "NEXT" etc.) were compressed into non ASCII bytes with the top bit set. This obviously made the internal source code smaller and faster to scan. Other characters were plain ASCII bytes.

Secondly routines tended to preserve HL which was the internal (compressed) source code pointer. Keeping this key variable in a register, allowed for faster execution.

[Jon Saxton]

On 2014-12-05 03:03, Johny B Good wrote:
> On Thu, 4 Dec 2014 18:31:18 +1100, "Ed" <inv...@nospam.com> wrote:
>
>> Johny B Good wrote:
>>> ...
>>> If you mean you prefer Zilog's
>>> assembly language mnemonics and more logical syntax over that of
>>> Intel's, then I agree.
>>
>> Which logical syntax? This one ...
>>
>> ADD A,s
>> ADC A,s
>> SUB s
>> SBC A,s
>> XOR s
>> etc
>>
>> :)
>
> I presume you're referring to the "Cart before The Horse" syntax.
> This would be the least problematical issue to the neophyte
> programmer, especially for one using CP/M.
>
> A better example would have been the LD of Z80 assembly code versus
> the STO and MOV of 8080 code.

Yes. Consider these

mvi b,38 ld b,38
mov c,a ld c,a
sta 4000h ld (4000h),a
lxi h,4000h ld hl,4000h
lhld 4000h ld hl,(4000h)
shld 4000h ld (4000h),hl
sphl ld sp,hl
stax d ld (de),a
ldax d ld a,(de)

Using Intel mnemonics you need to remember nine different instructions
which all do the same thing, namely copy 8 or 16 bits from one place to
another. Using Zilog mnemonics you have one instruction. With the
Intel mnemonics you have to understand each of the nine instructions
separately to know its effect but the operands of the Zilog instruction
tell you explicitly.

Now consider

dad d add hl,de
push b push bc

Intel instructions which operate on 16-bit registers do so using 8-bit
register names. Zilog instructions use the 16-bit register names
explicitly.

Now to the supposed inconsistency with instructions which sometimes
specify the recipient register and which sometimes do not. From the
list above, we have

sub e ; Recipient register not specified
sbc a,e ; Recipient register named

That may seem inconsistent but specifying the recipient register is only
necessary in the case where there is a matching 16-bit instruction, so
we have

sbc a,e
sbc hl,de

but not

sub e
sub hl,de

The recipient register is only specified to disambiguate the 8-bit and
16-bit forms. One could argue that the syntax is inconsistent and there
may be some merit in that. The Intel assembler solves the problem in a
different way, namely by having distinct instructions.

For what it is worth, the SLR assembler allows sub a,e and similar. M80
is more pedantic.

There is no reason to program for an 8080 using Intel mnemonics. All
you need do is avoid Z80-specific instructions. Then you can enjoy the
simpler syntax of the Zilog mnemonics without compromising the ability
for the target program to run on the comparatively small number of 8080
and 8085 systems in existence. (I never knew for sure but I suspect
that in the heyday of CP/M-80 about 95% of systems used a Z80.)

> I think there more inconsistencies in 8080 assembler but I can't
> recall them. The last time I programmed in Z80 assembler was some 30
> years ago. Thankfully, I still possess my Zaks book to refresh my
> memory of the more obscure instructions.
>
> My repair attempts to revive the machine I did all of my assembly
> language programming on, a Transam Tusacan S100 bus desktop computer,
> are currently in hiatus. If I succeed in resurrecting said computer,
> I'll be dipping into that book with a veangance. :-)
>


--

Former sysop of Tesseract RCPM+ which operated
in the 1980s from Dural, NSW, Australia.
http://triton.vg/TesseractRCPM+Catalog.html

[Steven Hirsch]

On 12/05/2014 09:03 AM, Jon Saxton wrote:

> Yes. Consider these
>
> mvi b,38 ld b,38
> mov c,a ld c,a
> sta 4000h ld (4000h),a
> lxi h,4000h ld hl,4000h
> lhld 4000h ld hl,(4000h)
> shld 4000h ld (4000h),hl
> sphl ld sp,hl
> stax d ld (de),a
> ldax d ld a,(de)
>
> Using Intel mnemonics you need to remember nine different instructions which
> all do the same thing, namely copy 8 or 16 bits from one place to another.
> Using Zilog mnemonics you have one instruction. With the Intel mnemonics you
> have to understand each of the nine instructions separately to know its effect
> but the operands of the Zilog instruction tell you explicitly.

(snip..)

Couldn't have stated it better. For me, it goes well beyond an issue of
"style". I can absorb the intent of Zilog mnemonics at a glance, while the
Intel form requires one additional access to a mental lookup table.

To each their own, but I get very bogged down reading code in Intel format.

Steve

[dottor Piergiorgio M. d' Errico]

... until someone gives you a listing in zilog mnemonics asking if the
related binary can run on an 8080...

hence my opinion: intel mnemonics when the binary should run on both
processor, and zilog mnemonics when is Z80 only.

Ideally, a listing using mixed mnemonics (that is, using zilog mnemonics
when using Z80 specific instructions, and intel mnemonics for the rest)
should allow an immediate recognition of where one must put his/her/its
hands when backporting....

example:

lxi h 4000h
exx
ld h'l' 2000h
exx
sphl
...

[Steve Nickolas]

On Fri, 5 Dec 2014, billc...@iscmns.org wrote:

> Alas I threw out my ISIS 8" floppies and listings 25 years ago!
> Nevertheless I recall 2 key snippets of information about this source.
> Reserved words (like "FOR", "NEXT" etc.) were compressed into non ASCII
> bytes with the top bit set. This obviously made the internal source
> code smaller and faster to scan. Other characters were plain ASCII
> bytes.

Yeah, I think every Microsoft version did that.

-uso.

[Steven Hirsch]

On 12/05/2014 01:04 PM, dottor Piergiorgio M. d' Errico wrote:
> ... until someone gives you a listing in zilog mnemonics asking if the related
> binary can run on an 8080...

Someone, somewhere must have written a utility that parses Zilog format ASM
and flags Z80 specific ops. If this doesn't exist, it should :-)

[John Elliott]

Steven Hirsch <snhi...@gmail.com> wrote:
> Someone, somewhere must have written a utility that parses Zilog format ASM
> and flags Z80 specific ops. If this doesn't exist, it should :-)

XZI does this -- takes Z80 source, outputs 8080 source, and lists line
numbers with opcodes that aren't supported on the 8080.

--
John Elliott

Thinks: This is what a nice clean life leads to. Hmm, why did I ever lead one?
-- Bluebottle, in the Goon Show

[Steven Hirsch]

On 12/05/2014 06:14 PM, John Elliott wrote:
> Steven Hirsch <snhi...@gmail.com> wrote:
>> Someone, somewhere must have written a utility that parses Zilog format ASM
>> and flags Z80 specific ops. If this doesn't exist, it should :-)
>
> XZI does this -- takes Z80 source, outputs 8080 source, and lists line
> numbers with opcodes that aren't supported on the 8080.

Nice! Thanks for the tip.

[Ed]

Jon Saxton wrote:
> ...

> Using Intel mnemonics you need to remember nine different instructions
> which all do the same thing, namely copy 8 or 16 bits from one place to
> another. Using Zilog mnemonics you have one instruction.

> ...

Which requires additional parameters and syntax to distinguish one from
the other - all of which must be learnt, remembered and used.

If the 'hard to remember/use' argument held any water, Zilog mnemonics
would be in there alongside Intel!

> Now to the supposed inconsistency with instructions which sometimes
> specify the recipient register and which sometimes do not. From the
> list above, we have
>
> sub e ; Recipient register not specified
> sbc a,e ; Recipient register named
>
> That may seem inconsistent but specifying the recipient register is only
> necessary in the case where there is a matching 16-bit instruction,

> ...

It's an inconsistency that you have to 'remember' - but why if Zilog
mnemonics were meant to be intuitive and easy to learn?

> For what it is worth, the SLR assembler allows sub a,e and similar. M80
> is more pedantic.

Multiple standards. What a mess. You don't get that with Intel mnemonic
assemblers.

> There is no reason to program for an 8080 using Intel mnemonics. All
> you need do is avoid Z80-specific instructions.

I do that ... and worry I've inadvertently put in some Z80 code that will
come back to bite me later e.g. the Altair Clone which only supports 8080.

Each argument for Zilog mnemonics can be countered with another against.
It's the same for Intel. Like it or not, CP/M users are stuck with two
mnemonic systems. It's the legacy of having a Z80.