Altair BASIC

[Udo Munk]

There are some more Altair BASIC paper tape version than I had so far for
z80pack here:

http://altairclone.com/downloads/basic/Paper%20Tape%20and%20Cassette/

If you like to read BASIC from paper tape with primary and secondary boot loader
you'll find instructions here:

http://www.solivant.com/altair_bootloaders/index.php?album=altair_bootloaders&pagen=0

For z80pack there is no need to fiddle with the boot loaders, because the emulated
machines just can read images in Intel hex format and the Altair BASIC versions
for z80pack are pre-loaded images. So I converted the missing versions into
images you just run with:

./altairsim -m0 -x basic....hex

Remember to set A11 to upper position for 3.2 versions, so that a SIO2 is used for
terminal I/O. Also don't type return at memory size question for the 3.2 versions,
because the memory test will run endless for a system with 64K R/W memory.

The easter egg for 8K version 3.2 is interesting:

MEMORY SIZE? A


WRITTEN BY BILL GATES & PAUL ALLEN & MONTE DAVIDOFF.

MEMORY SIZE? 65000
TERMINAL WIDTH?
WANT SIN-COS-TAN-ATN? Y

58927 BYTES FREE

ALTAIR BASIC VERSION 3.2
[EIGHT-K VERSION]

OK

Not written by MICRO-SOFT for royalties as version 4.0, guess the company was not
founded yet.

Bits and Bytes for the Altair are here:

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

[Steve Nickolas]

On Thu, 7 Jul 2016, Udo Munk wrote:

> The easter egg for 8K version 3.2 is interesting:
>
> MEMORY SIZE? A
>
>
> WRITTEN BY BILL GATES & PAUL ALLEN & MONTE DAVIDOFF.
>
> MEMORY SIZE? 65000
> TERMINAL WIDTH?
> WANT SIN-COS-TAN-ATN? Y
>
> 58927 BYTES FREE
>
> ALTAIR BASIC VERSION 3.2
> [EIGHT-K VERSION]
>
> OK
>
> Not written by MICRO-SOFT for royalties as version 4.0, guess the
> company was not founded yet.

That exact easter egg appears on some of the 6502 versions as well, only
it says "WRITTEN BY WEILAND & GATES".

-uso.

[Udo Munk]

The pre-loaded Altair 4K 4.0 version floating around on the Internet has a problem,
if you load it into z80pack 1.28 altairsim it will print garbage and won't work.

If you load it with option -m0 to initialise memory to 0 it runs OK. This is because
the pre-loaded image is a few bytes short. I created a new pre-loaded image
from the paper tape files mentioned above, that is complete and works without -m0.

I also created a pre-loaded image for Disk BASIC 5.0, you can load it into
altairsim, but disk commands won't work, because the machine has no 88-DSK
but a Tarbell FDC.

I also uploaded the paper tape files and the primary loader source for 2SIO,
together with some instructions how to create pre-loaded images from the
paper tape files your self, using z80pack altairsim.

[dott.Piergiorgio]

On 07/07/2016 22:16, Udo Munk wrote:
> Also don't type return at memory size question for the 3.2 versions,
> because the memory test will run endless for a system with 64K R/W
> memory.

Infinite loop whose in 4k basic is from $0DCD to $0DD8... blinkenlighten
are useful in those cases, indeed.

I still don't have disassembled the culprit aerea, but I'm sure I'm not
alone in coveting the sublime pleasure of patching gate$ of he££'s
idiocy and lamer coding...

Best regards from Italy,
dott. Piergiorgio.

[dott.Piergiorgio]

On 07/07/2016 23:42, Steve Nickolas wrote:

>> Not written by MICRO-SOFT for royalties as version 4.0, guess the
>> company was not founded yet.
>
> That exact easter egg appears on some of the 6502 versions as well, only
> it says "WRITTEN BY WEILAND & GATES".

in the commodore PET basic 2, there's WAIT 6502,X where X is a value
from 1 to 255... whose print X times "micro$oft!" (without the $, of
course..)

[Udo Munk]

On Wednesday, July 13, 2016 at 12:21:05 PM UTC+2, dott.Piergiorgio wrote:

> Infinite loop whose in 4k basic is from $0DCD to $0DD8... blinkenlighten
> are useful in those cases, indeed.

Most software problems can be solved with the blinkenlights and single
stepping through the programs. If that is too tedious load the software
into z80sim, there you have single stepping, breakpoints, tracing,
disassembly, well everything the InCircuit Emulators from Zilog/Mostek
Intel could do. For the I/O you need to manipulate the CPU registers,
so that it breaks out of a loop waiting for terminal input. Just supply
the register with the expected values to continue a program without
doing real I/O to not existing hardware.

> I still don't have disassembled the culprit aerea, but I'm sure I'm not
> alone in coveting the sublime pleasure of patching gate$ of he££'s
> idiocy and lamer coding...

When they wrote the 3.2 versions the problem simply didn't exist,
because even if you were working at MITS you won't have had a
machine with 64KB in 1975. In 1976 they fixed it them self with the
4.0 versions, so I think there is no point patching the older versions.
It's more interesting to archive the original versions and run them
as is and see, how the software was improved over the time.

[Udo Munk]

Albuquerque, March 1975:

MEMSIZ? 32000
WANT SIN-COS-ATN? Y
27520 BYTES FREE

8080 BASIC VER 1.0

READY
PRINT 1/3
.333333

READY
LET A=10

READY
LET B=5

READY
PRINT A+B
15

READY

Must have looked similar to this.

Al Kossov send me a paper tape file with the filename

basic_1.0_19750302_cpyApr02.ptp

to have a look at it. I think it is a copy of this paper tape:

http://www.computerhistory.org/revolution/personal-computers/17/312/1142

If I understand this right this is a copy of the paper tape that
Bill Gates and Paul Allen used in March 1975, to show Ed Roberts
their 8080 BASIC.

I got this version running on the z80pack Altair 8800 emulation. For
this I had to add a 88-SIO to the virtual machine first, because so
far I was emulating the 88-SIO2, which is different. This BASIC
version only works with the 88-SIO at ports 0/1 and doesn't support
any other serial cards as far as I can say.

This 4K BASIC has a size of 4575 bytes, so they had to optimize it
quite a bit to fit into 4096 bytes, explains some of the odd coding
seen in later versions. Even the prompt was reduced from READY to
OK for that.

Of course it has lots of bugs, but doesn't matter, this is a demo
version to show that it can be done.

Will upload the stuff tonight to the z80pack website.

[Al Kossow]

On 7/13/16 5:29 AM, Udo Munk wrote:

> Al Kossow send me a paper tape file with the filename

>
> basic_1.0_19750302_cpyApr02.ptp
>
> to have a look at it. I think it is a copy of this paper tape:
>
> http://www.computerhistory.org/revolution/personal-computers/17/312/1142
>

Correct. I wanted to verify that the copy that I made 15+ years ago was duplicated
correctly.

A bit of trivia. When you walk into the CHM Revolution exhibit, there is a thank you
to Bill Gates for his donation which helped complete construction of the exhibit. The
background is a hex dump of the end of this tape.

[Udo Munk]

On Wednesday, July 13, 2016 at 4:24:17 PM UTC+2, Al Kossow wrote:

> Correct. I wanted to verify that the copy that I made 15+ years ago
> was duplicated correctly.

I think the tape was duplicated correctly, can be loaded into machines
and one gets a more or less working BASIC interpreter with some bugs.

> A bit of trivia. When you walk into the CHM Revolution exhibit, there
> is a thank you to Bill Gates for his donation which helped complete
> construction of the exhibit. The background is a hex dump of the end
> of this tape.

Pretty cool, thanks for makeing it available.

[Udo Munk]

A short demo video for BASIC 1.0 is available at YouTube:

https://youtu.be/TWwU3Pv4BXo

Also uploaded the paper tape file and the Intel hex file I created from it here:

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

It won't run with z80pack 1.28, because it only supports the 88-SIO and not the implemented
88-SIO2. An easy hack is to copy the function pointer for the SIO functions in
z80pack/altairsim/iosim.c
in both arrays from locations 16/17 to locations 0/1, so that the SIO is connected to
I/O ports 0/1. Then this SIO sets Bit 5 for character available, while 88-SIO2 sets Bit 0.
So change the status in z80pack/iodevices/altair-88-2sio.c function altair_sio_status_in
from 1 to 32.

The later BASIC versions still can be used with the modified SIO, because they support various
output channels. For the 3.x versions all switches down, for the 4.x version switch A13 up.

[Udo Munk]

On Wednesday, July 13, 2016 at 12:21:05 PM UTC+2, dott.Piergiorgio wrote:

> I still don't have disassembled the culprit aerea, but I'm sure I'm not
> alone in coveting the sublime pleasure of patching gate$ of he££'s
> idiocy and lamer coding...

I tested 1.0 with a Z80 CPU, guess what, it works. No 'lamer coding' in there,
so the tricky programming in later versions is all due to get this fit into 4096 bytes.

One does't have to like what they did, but IMHO this is not lame coding, they
exploited the 8080 to a very high degree just to get this done.

Not that I like such coding for commercial products, just trying to look at it
as unbiased as possible for me.

[dott.Piergiorgio]

well, was bi££ gates who later set that annoying 640K limit.. so he was
he££ bent in programmed ob$ole$cence since day one, hence the
"political" content of my post..

anyway, disassembling and understanding that loop isn't too tedious, the
real (and fun) challenge lies in patching the code in the tight confines
of 4k...

[dott.Piergiorgio]

an unneeded trivia (I have a very low esteem of bi££ gate$..) but
speaking about CHM, how is going the talks for securing the last
operational IBM 407 ? hope to receive someday good newes ;)

[Udo Munk]

On Thursday, July 14, 2016 at 10:52:18 AM UTC+2, dott.Piergiorgio wrote:

> well, was bi££ gates who later set that annoying 640K limit.. so he was
> he££ bent in programmed ob$ole$cence since day one, hence the
> "political" content of my post..

In the first place that limit was set by IBM by reserving memory
above 640KB for memory mapped I/O. That was OK for a CPU that can
address 1MB. That they later sticked to this for compatibility
reasons with better machines, that could address more than 1MB,
clearly was a design failure.

> anyway, disassembling and understanding that loop isn't too tedious, the
> real (and fun) challenge lies in patching the code in the tight confines
> of 4k...

No, sure is not, don't use the link if you don't want a spoiler ;-)

http://web.archive.org/web/20011212110404/http://www.rjh.org.uk/altair/4k/init_dis_2.htm

[dott.Piergiorgio]

thanks, I'll try testing the z80pck hack. side note, esp. for cromsim,
having not only switches, but also a configuration files, should be a
good idea. I'm not 100% sure that the two 88-SIO are mutually
incompatible, but IMHO a mechanism for switching configuration per-run
should be considered for inclusion in a TODO list.

p.s. the 4575 bytes of basic "1.0" (in reality 0.something) rings
somewhat familiar to me: I'll recheck a little thing done in past with
Schorn's emulator, then, if I'm correct, will point an interesting detail.

[dott.Piergiorgio]

I agree that I have a visceral hate for IP abuse in general, whose in
Gate$'s case largely cross the thick red line of hypocrisy (I'm not
referring to the SCP case, but to the datum that the dominance position
in the propiertary software of m$ was built on the large installed base
of... pirate copies.)

BTW, when basic pre-4.0 was coded, the Z80 don't exist or was at the
proto stage (I don't remember on the spot the timeframe of early zilog,
my apologies in advance if I'm wrong), so the z80 incompatibility is a
moot point in regard.

but, the core issue, one should admit, was the marketing & technical
mistakes of MITS with the infamous 4k dynamic RAM board, whose led to
the earliest piracy (and a later HCC article hinted to gate$ realizing
very early the truth that DRM is basically an illusory, whose probably
led to the "pirates" hypocrisy I refer earlier)

OTOH, mr. Kossow's HCC part of his site recovers a very unique insight
in the form of these two newspaper articles, whose sheds huge lights not
only on the piracy issue, but also on Apple (if one cross the late
Jobs's pointing to the "mac philosophy" with the article date and the
delivery date of the very first batch of apple ][ the surprise is huge,
I hitted the proverbial roof with jumping from seat..)

I generally try to rein my bias when doing Historian duties, thank to
your reminding of this specific line of Duty.

[dott.Piergiorgio]

On 14/07/2016 11:30, Udo Munk wrote:

>> anyway, disassembling and understanding that loop isn't too tedious, the
>> real (and fun) challenge lies in patching the code in the tight confines
>> of 4k...
>
> No, sure is not, don't use the link if you don't want a spoiler ;-)

LOL, I know what is, thank for the spoiler :D

>
> http://web.archive.org/web/20011212110404/http://www.rjh.org.uk/altair/4k/init_dis_2.htm

[Udo Munk]

On Thursday, July 14, 2016 at 11:31:00 AM UTC+2, dott.Piergiorgio wrote:

> thanks, I'll try testing the z80pck hack. side note, esp. for cromsim,
> having not only switches, but also a configuration files, should be a
> good idea. I'm not 100% sure that the two 88-SIO are mutually
> incompatible, but IMHO a mechanism for switching configuration per-run
> should be considered for inclusion in a TODO list.

There are configuration files, but not completely implemented yet.
The both SIO's are not mutually incompatible, you can have both in
one system. The 88-SIO usually was configured for I/O ports 0/1
and the 88-2SIO for 16/17 18/19.
In z80pack 1.29 under development I have implemented both cards, both
connected to the tty at the same time. That would be a bit difficult
with real hardware, but in emulation this can be done. So far I
haven't found software not working with this, so probably will be
in the 1.29 release.

[Udo Munk]

On Thursday, July 14, 2016 at 11:54:31 AM UTC+2, dott.Piergiorgio wrote:

> BTW, when basic pre-4.0 was coded, the Z80 don't exist or was at the
> proto stage (I don't remember on the spot the timeframe of early zilog,
> my apologies in advance if I'm wrong), so the z80 incompatibility is a
> moot point in regard.

BASIC 1.0 was finished March 1975 and Zilog released the Z80 sometime
in 1976, so taking this in account was not possible. The 4.0 versions
were done in 1976, I don't know if the had access to Z80 manuals,
probably not.

Microsoft started to fix Z80 incompatibility with their software, when
they did the Apple Z80 card and CP/M for this, sometime in 1980.
A bit late, but better late than never ;-)

> but, the core issue, one should admit, was the marketing & technical
> mistakes of MITS with the infamous 4k dynamic RAM board, whose led to
> the earliest piracy (and a later HCC article hinted to gate$ realizing
> very early the truth that DRM is basically an illusory, whose probably
> led to the "pirates" hypocrisy I refer earlier)

DRM, copy protection and all that is totally nonsense, worse than snake oil.
You are working with a digital circuit with 2/3 of the instruction set
COPYING bits and bytes from A to B. If you don't want that then don't use
a microprocessor.

[dott.Piergiorgio]

and this throw away the emulation fidelity, I guess, hence my suggestion
of a configuration file, for selecting the SIO at least (as you known, I
remain perplexed about the usage of hard links for the disk image
allocation...)

btw, having two SIO (and in general, more than one console I/O ports)
together should be interesting, opening an avenue for the M of MP/M...
albeit I admit I never fooled around MP/M.

[Udo Munk]

On Thursday, July 14, 2016 at 12:55:34 PM UTC+2, dott.Piergiorgio wrote:

> and this throw away the emulation fidelity, I guess, hence my suggestion
> of a configuration file, for selecting the SIO at least (as you known, I
> remain perplexed about the usage of hard links for the disk image
> allocation...)

Configuration files are in the conf directories and in
iodevices/io_config.c is the parser for that. Still work in progress
and not finished yet, but the base is in there.

> btw, having two SIO (and in general, more than one console I/O ports)
> together should be interesting, opening an avenue for the M of MP/M...
> albeit I admit I never fooled around MP/M.

That is implemented for MP/M and Cromix, cpmsim and cromemcosim have
multiple console ports. With CDOS you can switch from one console to
another with stat. Could be done with CP/M too by using the IOBYTE in
BIOS's.

[Udo Munk]

If you want to fiddle with the BASIC 1.0 paper tape this might be helpful:

http://www.autometer.de/unix4fun/z80pack/ftp/altair/papertapes/readme2.txt

[dott.Piergiorgio]

On 14/07/2016 20:30, Udo Munk wrote:
> If you want to fiddle with the BASIC 1.0 paper tape this might be helpful:
>
> http://www.autometer.de/unix4fun/z80pack/ftp/altair/papertapes/readme2.txt

mhm... albeit the difference between 0A and 1B is indeed bits toggled to
1 (= holes), one should be sure that isn't the case of a damaged
papertape (for obvious reasons, the extremes of a tape are the most
vulnerable to damages) because a quick looks into docs of various
terminals (mainly the TTY ASR-33, but I looked into other cheap surplus
terminals of the era (useful for this the availability in pdf, ads.
included, of BYTE of 1975-6 vintage) and I'm positively sure that the
sequence of CR-ESC-LF don't make sense as terminal/TTY control. (OTOH, a
CR-LF-LF sequence makes sense, if the intent was having a blank line
between BYTES FREE and READY with a paper TTY)

perhaps looking into other bugs not in hexadecimal, but in binary should
be worth. Your opinion ?

side point, I noticed that in these days Mr. Kossow is uploading mainly
terminal documentation.. but I think is unrelated to this issue.

Best regards from Italy, and Vive la France !
dott. Piergiorgio.

[Udo Munk]

On Friday, July 15, 2016 at 10:44:13 AM UTC+2, dott.Piergiorgio wrote:

> mhm... albeit the difference between 0A and 1B is indeed bits toggled to
> 1 (= holes), one should be sure that isn't the case of a damaged
> papertape (for obvious reasons, the extremes of a tape are the most
> vulnerable to damages) because a quick looks into docs of various
> terminals (mainly the TTY ASR-33, but I looked into other cheap surplus
> terminals of the era (useful for this the availability in pdf, ads.
> included, of BYTE of 1975-6 vintage) and I'm positively sure that the
> sequence of CR-ESC-LF don't make sense as terminal/TTY control. (OTOH, a
> CR-LF-LF sequence makes sense, if the intent was having a blank line
> between BYTES FREE and READY with a paper TTY)
>
> perhaps looking into other bugs not in hexadecimal, but in binary should
> be worth. Your opinion ?
>
> side point, I noticed that in these days Mr. Kossow is uploading mainly
> terminal documentation.. but I think is unrelated to this issue.

Could be that a LF was supposed, hard to say, because the way I patched
it makes it look so:

-------------------
MEMSIZ? 8192
WANT SIN-COS-ATN? Y
3712 BYTES FREE

8080 BASIC VER 1.0

READY

-------------------

The 8080 BASIC... string has another CR/LF in front already.

Doen't really matter because it is a cosmetic change only and an
ESC confuses VT-100/ANSI terminals. Also if the ESC is on the original
paper tape they won't have notice this, because a teletype would ignore
it, not printable character.

[Al Kossow]

On 7/15/16 1:44 AM, dott.Piergiorgio wrote:

> side point, I noticed that in these days Mr. Kossow is uploading mainly terminal documentation.. but I think is
> unrelated to this issue.
>

Correct. I've been researching terminals for the MAME team.

It just happened I noticed this thread and thought trying the paper tape would be a good idea.
If I can get access to the original tape, I will see if the extra characters are on the original.

[Udo Munk]

On Friday, July 15, 2016 at 6:19:46 PM UTC+2, Al Kossow wrote:

> It just happened I noticed this thread and thought trying the paper
> tape would be a good idea.
> If I can get access to the original tape, I will see if the extra
> characters are on the original.

There is another thing that puzzles me. Why does ist start with
c3 16 02 and jumps to the warm start entry??

Because at cold start pretty much the first thing it does is:

107e - LD SP,114A
1081 - LD HL,0216
1084 - LD (0001),HL

If the first 3 bytes were c3 7e 10 that would make much more sense.

This tape must have been created from a machine, were BASIC was started
before, so that the cold boot entry rewrote addresses 1+2 with the
address for warm boot.

[dott.Piergiorgio]

On 15/07/2016 18:22, Al Kossow wrote:
> On 7/15/16 1:44 AM, dott.Piergiorgio wrote:
>
>> side point, I noticed that in these days Mr. Kossow is uploading mainly terminal documentation.. but I think is
>> unrelated to this issue.
>>
>
> Correct. I've been researching terminals for the MAME team.

I guess more precisely for the MESS part of MAME...

> It just happened I noticed this thread and thought trying the paper tape would be a good idea.
> If I can get access to the original tape, I will see if the extra characters are on the original.

I concur and agree. and if you can test it on an actual altair/TTY
combination, please do.

Best regards from Italy,
dott. Piergiorgio.

[dott.Piergiorgio]

I should look up, but your hypothesis makes sense; adding that the demo
@ MITS office was rushed (up to gate$ and Allen having coded the loader
during the trip from Seattle to Albuquerque, as the tale go...) makes
more sense.

Best regards from Italy,
dott. Piergiorgio.

[Al Kossow]

On 7/16/16 2:04 AM, dott.Piergiorgio wrote:

> I guess more precisely for the MESS part of MAME...
>

There is no such thing as MESS any more. It is just MAME.
The sources were combined a while ago.

[dott.Piergiorgio]

Hence I write "MESS part" ;)

[Tom Lake]

On Monday, July 11, 2016 at 3:12:19 PM UTC-4, Udo Munk wrote:
> The pre-loaded Altair 4K 4.0 version floating around on the Internet has a problem,
> if you load it into z80pack 1.28 altairsim it will print garbage and won't work.
>
> If you load it with option -m0 to initialise memory to 0 it runs OK. This is because
> the pre-loaded image is a few bytes short. I created a new pre-loaded image
> from the paper tape files mentioned above, that is complete and works without -m0.
>
> I also created a pre-loaded image for Disk BASIC 5.0, you can load it into
> altairsim, but disk commands won't work, because the machine has no 88-DSK
> but a Tarbell FDC.
>
> I also uploaded the paper tape files and the primary loader source for 2SIO,
> together with some instructions how to create pre-loaded images from the
> paper tape files your self, using z80pack altairsim.

How did you get any version of Altair BASIC to run on a Z-80? I have 3.x and 4.x versions of Cassette BASIC and 5.x of Disk BASIC and none of them run with a Z-80. I heard there were patches available to do that but have never seen them. ISTR it concerned the use of the carry flag.

Tom L

[Udo Munk]

On Monday, August 8, 2016 at 7:15:26 PM UTC+2, Tom Lake wrote:

> How did you get any version of Altair BASIC to run on a Z-80? I have 3.x and 4.x versions of
> Cassette BASIC and 5.x of Disk BASIC and none of them run with a Z-80. I heard there were
> patches available to do that but have never seen them. ISTR it concerned the use of the carry flag.

As you say, they won't run, z80pack also includes an emulation of the i8080, which is
the default CPU for Altair and IMSAI machines, as the original systems. The emulations
have options, so that you can run them with a i8080 or Z80, Z80 replacement cards
became popular after a while.

Altair BASIC 1.0 also runs on the Z80, this version wasn't optimised yet for memory size
by wrong usage of the parity/overflow flag.

The TDL Z80 S100 card was popular for Altair systems and the Manual mentions an
Appendix C with Altair BASIC patches for the Z80. So yes, there were known patches,
unfortunately the Manual Appendix is missing. If I remember right some magazines
like Dr. Dobbs etc. also had this informations.

[Udo Munk]

I've tested Altair BASIC Extended ROM version 4.1, this one runs in ROM at C000H.
It works on 8080 and Z80, seems to be the first version of the production releases,
that they fixed to work on Z80 systems.
I've uploaded an ROM image in Intel hex format to the z80pack repository.