Apple I Integer BASIC dump/listing?
Rodney Hester
Anyone know of where I could find a hex dump or listing of the original
Apple I Integer BASIC? Have searched Google (web and groups) pretty
thoroughly, which netted PDFs of the Owner's Manual and preliminary BASIC
Manual, but no actual listing. :/
Any help appreciated!
Rodney
Michael Black
that time that they might not have given much consideration to this.
Once the money was there for the Apple II, they could afford to do
things right.
I have the collected volumes of Dr. Dobbs, and it sure wasn't printed
in there. Steve Wozniak did publish bits of Apple code in there in
the early days (the disassembler comes to mind; I used it on my
OSI SUperboard), and there was at least another article, but no BASIC.
He had an article in BYTE, must have been 1977, about the Apple II that didn't
have code but did go into the inner workings of the hardware and
software (the bit I most remember is about the Sweet-16 interpreter.
I can't see him publishing it in one of the other magazines. So I
guess you are limited to something from Apple, if there was such a thing.
Of course, if you could find someone with an Apple I, hopefully they'd have
the binary, and you could disassemble it.
Michael
Wayne Stewart
If there's nothing at the Apple I qwners club
http://www.applefritter.com/apple1/
You could post a query on the message board
http://www.applefritter.com/cgi-bin/YaBB/YaBB.pl?board=apple1
Wayne
Vince Briel
http://www.applefritter.com has a listing but it has a few errors. I'll
email you a better copy when I get a chance.
Vince
"Rodney Hester" <ro...@optonline.net> wrote in message
news:bjn77v$l11a5$1...@ID-194148.news.uni-berlin.de...
Eric Smith
> http://www.applefritter.com has a listing but it has a few errors. I'll
> email you a better copy when I get a chance.
Where? I don't see one. Is it source code, a disassembly, or a hex
dump?
Vince Briel
http://www.applefritter.com/apple1/members/nelson/basic_disassembly.txt
Enjoy
Vince
"Eric Smith" <eric-no-s...@brouhaha.com> wrote in message
news:qh1xuo4...@ruckus.brouhaha.com...
Ben Yates
> Ahhh.. Here's the link:
>
> http://www.applefritter.com/apple1/members/nelson/basic_disassembly.txt
>
I hope all the comments were added by the disassembler, because they
are pretty useless. Even I could guess that TXA is transfer x to
accumulator...
Ben
Michael J. Mahon
Really...
At least it would have been handy if the disassembler had put in the
computed target addresses of the relative branches (if not generated
labels). ;-)
I'm guessing that the disassembler was written in BASIC by someone
with only a "reference card" familiarity with assembly language.
But, at least it captures the code (though apparently with some errors).
-michael
Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/
Matthew Russotto
Michael J. Mahon <mjm...@aol.com> wrote:
>Ben Yates wrote:
>
>>"Vince Briel" <vbr...@comcast.net> wrote in message
>>news:<mWP7b.411726$o%2.187426@sccrnsc02>...
>>> Ahhh.. Here's the link:
>>>
>>> http://www.applefritter.com/apple1/members/nelson/basic_disassembly.txt
>>>
>>
>>I hope all the comments were added by the disassembler, because they
>>are pretty useless. Even I could guess that TXA is transfer x to
>>accumulator...
>
>Really...
>
>At least it would have been handy if the disassembler had put in the
>computed target addresses of the relative branches (if not generated
>labels). ;-)
>
>I'm guessing that the disassembler was written in BASIC by someone
>with only a "reference card" familiarity with assembly language.
Looks to me like an Apple II Monitor listing postprocessed with some
routine and slightly hand-massaged.
--
Matthew T. Russotto mrus...@speakeasy.net
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue." But extreme restriction of liberty in pursuit of
a modicum of security is a very expensive vice.
Michael J. Mahon
>In article <20030911163108...@mb-m16.aol.com>,
>Michael J. Mahon <mjm...@aol.com> wrote:
>>Ben Yates wrote:
>>
>>>"Vince Briel" <vbr...@comcast.net> wrote in message
>>>news:<mWP7b.411726$o%2.187426@sccrnsc02>...
>>>> Ahhh.. Here's the link:
>>>>
>>>> http://www.applefritter.com/apple1/members/nelson/basic_disassembly.txt
>>>>
>>>
>>>I hope all the comments were added by the disassembler, because they
>>>are pretty useless. Even I could guess that TXA is transfer x to
>>>accumulator...
>>
>>Really...
>>
>>At least it would have been handy if the disassembler had put in the
>>computed target addresses of the relative branches (if not generated
>>labels). ;-)
>>
>>I'm guessing that the disassembler was written in BASIC by someone
>>with only a "reference card" familiarity with assembly language.
>
>Looks to me like an Apple II Monitor listing postprocessed with some
>routine and slightly hand-massaged.
No, because the Apple II Monitor disassembler lists the target
addresses of relative branches, and no one would "massage"
that away.
The general form of the Apple II disassembler took shape on
the Apple I (see the Applefritter article on the Disassembler
program by Woz and Allen Baum).
Vince Briel
> At least it would have been handy if the disassembler had put in the
> computed target addresses of the relative branches (if not generated
> labels). ;-)
Please consider that Woz wrote Integer Basic by hand with no assembler. The
fact that there is some reference to instructions specific to their actions
is pretty good.
It was done by hand. Achim did it by writing a program to read the tape file
and interpet the 1's and 0's into bytes and then into hex thus having the
first known text copy of Apple I Integer Basic. There was a lot of work, yet
everybody seems to nit pick at the little things. Has anybody considered
that English isn't even this guys native language?
Instead of knocking guys who do things like this and blow them out of the
vintage community why don't you show some respect.
What have you done?
Michael J. Mahon
>> At least it would have been handy if the disassembler had put in the
>> computed target addresses of the relative branches (if not generated
>> labels). ;-)
>
>Please consider that Woz wrote Integer Basic by hand with no assembler. The
>fact that there is some reference to instructions specific to their actions
>is pretty good.
I certainly do consider that. Which is why a disassembly of Integer
BASIC is the closest thing to source that we'll ever have.
As a user of several disassemblers and a reader of (too) many
disassemblies, I really appreciate being able to see where a branch
branches, as opposed to having to compute it. I would expect that
anyone writing a disassembler would want the same, since the hex
listing contains the relative displacement, and one of the primary
purposes of a disassembly is to enable a reader to understand the
code (the other primary purpose is to enable re-assembly after
any changes are made).
>It was done by hand. Achim did it by writing a program to read the tape file
>and interpet the 1's and 0's into bytes and then into hex thus having the
>first known text copy of Apple I Integer Basic. There was a lot of work, yet
>everybody seems to nit pick at the little things. Has anybody considered
>that English isn't even this guys native language?
I assume that you mean that he did it on a modern computer with a
sound card. I agree, that's a nice piece of work. I had no context for
where the listing came from, who did it, or when. I merely added to
someone else's observation that the "comments" appeared to be
machine-generated. (In fact, the "comments" add no information
to the disassembly for anyone who has learned the instruction set.)
Since I had no idea who did it, I gave no consideration to his native
language (though I guessed that it wasn't assembler ;-).
>Instead of knocking guys who do things like this and blow them out of the
>vintage community why don't you show some respect.
Sorry you thought I was "knocking" someone current. I assumed that
the disassembly was run years ago on an Apple I after loading Integer
BASIC, and guessed that it was a (one of a thousand) home-grown
disassembler of the period. My aplogies for a bad assumption
(but it's still not a "good" disassembly).
I was comparing it to what would be obtained by playing the cassette
into an Apple I (or II, with appropriate cassette read changes) and
then disassembling it with the Woz/Baum disassembler. This
would be a fairly straightforward exercise for anyone familiar with
the Apple I or Apple II who had one at his/her disposal.
If anyone is "blown out of the vintage community" by what are fairly
typical (and occasionally nit-picky ;-) comments in a newsgroup, then
they are 1) taking it much too personally, and 2) not very committed
to being "in" the community in the first place.
I try to be polite and respectful. That doesn't mean that I don't criticize.
I do try to make my criticisms constructive, and I try to compliment
nice work when appropriate (as I complimented yours, particularly
after learning that sales are not an aim but a courtesy).
Paul Schlyter
Vince Briel <vbr...@comcast.net> wrote:
>> At least it would have been handy if the disassembler had put in the
>> computed target addresses of the relative branches (if not generated
>> labels). ;-)
>
> Please consider that Woz wrote Integer Basic by hand with no assembler. The
> fact that there is some reference to instructions specific to their actions
> is pretty good.
>
> It was done by hand. Achim did it by writing a program to read the tape file
> and interpet the 1's and 0's into bytes and then into hex thus having the
> first known text copy of Apple I Integer Basic. There was a lot of work, yet
> everybody seems to nit pick at the little things. Has anybody considered
> that English isn't even this guys native language?
>
> Instead of knocking guys who do things like this and blow them out of the
> vintage community why don't you show some respect.
>
> What have you done?
Also: with that disassembler listing available, it shouldn't be too
hard for anyone who really wanted to to write a program which
processed the listing such that the relative branches were replaced
by target addresses. And by letting the program pass through the
listing twice, it could also insert labels.
Who will be the first to post such a processed listing of the Basic
for the Apple I ????
And then there's another interesting project: porting Apple I Basic
to the Apple II ..... :-)
>> I'm guessing that the disassembler was written in BASIC by someone
>> with only a "reference card" familiarity with assembly language.
>>
>> But, at least it captures the code (though apparently with some errors).
>>
>> -michael
>>
>> Check out amazing quality sound for 8-bit Apples on my
>> Home page: http://members.aol.com/MJMahon/
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://www.stjarnhimlen.se/
http://home.tiscali.se/pausch/
Paul Schlyter
Michael J. Mahon <mjm...@aol.com> wrote:
>As a user of several disassemblers and a reader of (too) many
>disassemblies, I really appreciate being able to see where a branch
>branches, as opposed to having to compute it.
So why don't you write a post-processor for that disassembly which
changes the offsets to taget addresses? You could probably do it in
an hour or two, or definitely no longer than an afternoon. Wouldn't
it be better spending your time that way than posting complaints that
the target addresses aren't there?
>I would expect that
>anyone writing a disassembler would want the same, since the hex
>listing contains the relative displacement, and one of the primary
>purposes of a disassembly is to enable a reader to understand the
>code (the other primary purpose is to enable re-assembly after
>any changes are made).
Vince Briel
your right, a little nit picking shouldn't discourage people from this
group. That being said...
> Also: with that disassembler listing available, it shouldn't be too
> hard for anyone who really wanted to to write a program which
> processed the listing such that the relative branches were replaced
> by target addresses. And by letting the program pass through the
> listing twice, it could also insert labels.
Yes, maybe somebody can take a raw listing and fix it for us? The Apple I is
afterall Apple II's little brother. Good idea.
> Who will be the first to post such a processed listing of the Basic
> for the Apple I ????
Who wants to take it on? I personally don't have time right now.
>
> And then there's another interesting project: porting Apple I Basic
> to the Apple II ..... :-)
Ah, but that's the thing. Apple Integer basic was written as a crossover for
both machines. The Apple II was under development at the time of writing
Integer Basic. If you look at the listing, you'll notice commands for
graphics and color that were not Implimented in the Apple I yet were there
none the less.
Then after a while people were asking for a floating point version for the
Apple I and Apple's response was that there will be a FP Basic for the Apple
II but not the one. This was the start Apple no longer supporting the Apple
I.
At first I thought these posts to comp.sys.apple2 were off subject, but
really they are tied in as is the Apple ///.
The main reason for all this work is that much of the software is not
archived and is in danger of being lost. Most Apple I owners don't want to
power-up their Apple I's to list programs for fear of damaging their
machines. Even the owner of the tapes was afraid of stretching them just by
copying them after 25+ years of non-use.
I don't have a disassembled copy of Integer Basic for the Apple II. Was that
listed with any of the Apple II books? I can't remember. I'm curious as to
seeing the difference between the Apple I and Apple II listings.
Vince
Ben Yates
(Forgive if this is a duplicate - Google is always good at "Internal
Server Errors" when I go to post a long message...)
I can't agree with the above, because I've seen what _can_ be done. Go
to http://www.99er.net/download.html and download tiintern.pdf.
This guys native language isn't English, so? This is a published book
by Heiner Martin, translated by Peter Coates.
It contains a complete disassembly of the ROM and three GROMS in a
TI-99. This is impressive, considering that in 1985, when this was
published, GPL (the langauge of GROMS) were still a closely guarded
secret. Heiner had to write his own GPL disassembler.
Check out the index:
Index:
Preface ......................................... 8
The ROM ......................................... 9
The ROM Listing ................................ 11
Graphic Programming Language ................... 80
The GPL Commands ............................... 81
The GPL Command formats ........................ 95
The GROM 0 ..................................... 98
The GROM 0 Listing ............................. 99
The Hexdump of Sample GROM .................... 126
The Basic GROM'S .............................. 132
The Basic Value Stack ......................... 134
The Basic Symbol Table ........................ 135
Listing of GROM 1 ............................. 136
Listing of GROM 2 ............................. 171
References to Extended Basic .................. 209
And a sample ROM disassembly (with _useful_ comments):
I/O Sound:
05D6 024E ANDI 14,>FFFE System flag
05D8 FFFE
05DA E380 SOC 0,14 Pointer GROM or VDP in system flag (00 or 01)
05DC C813 MOV *3,@>83CC Load pointer sound list
05DE 83CC
05E0 D80E MOVB 14,@>83CE Load sound byte
05E2 83CE
05E4 0460 B @>0070 To GPL interpreter
05E6 0070
And a sample GPL diassembly (again with _useful_ comments):
Begin Basic:
216F : ST @>8373,>88 Substack
2172 : CALL GROM@>27E3 Prepare VDP
2175 : MOVE >000E TO VDP@>02C2 FROM GROM@>20CB TI Basic ready
217C : CLR @>8388
217F : CALL GROM@>4012 PAB existing, close files
2182 : ST @>8334,>FF Pointer to current data
2185 : DST @>836E,>06F8 Value stack pointer
2189 : DST @>8324,@>836E Basis value stack = top character table
218C : DST @>8332,@>8370 End line table
218F : DST @>8330,@>8332 Start line table
2192 : CALL GROM@>222B Set pointer
Ben
Paul Schlyter
Vince Briel <vbr...@comcast.net> wrote:
>> Who will be the first to post such a processed listing of the Basic
>> for the Apple I ????
>
>Who wants to take it on? I personally don't have time right now.
Perhaps you have time in a week or two or so? At least you have
time to spend on Usenet.... :-)
If no-one ever "have the time", it won't be done....
> The main reason for all this work is that much of the software is not
> archived and is in danger of being lost. Most Apple I owners don't want to
> power-up their Apple I's to list programs for fear of damaging their
> machines. Even the owner of the tapes was afraid of stretching them just by
> copying them after 25+ years of non-use.
If so, the hardware and the tapes are in effect already damaged, since
they're considered unusable....
> I don't have a disassembled copy of Integer Basic for the Apple II. Was that
> listed with any of the Apple II books? I can't remember. I'm curious as to
> seeing the difference between the Apple I and Apple II listings.
No books from Apple ever contained a disassembly of Integer Basic.
However, it should be quite easy to obtain one from the Apple
monitor. And if the output is "piped" through, say, a serial port
(by e.g. a "Ctrl-P 2" monitor command), it can easily be captured by
another computer. This can of course also be done in an emulator.
Michael J. Mahon
>In article <20030913041524...@mb-m28.aol.com>,
>Michael J. Mahon <mjm...@aol.com> wrote:
>
>>As a user of several disassemblers and a reader of (too) many
>>disassemblies, I really appreciate being able to see where a branch
>>branches, as opposed to having to compute it.
>
>So why don't you write a post-processor for that disassembly which
>changes the offsets to taget addresses? You could probably do it in
>an hour or two, or definitely no longer than an afternoon. Wouldn't
>it be better spending your time that way than posting complaints that
>the target addresses aren't there?
Point well taken, Paul.
Paul R. Santa-Maria
> Who will be the first to post such a processed listing of the Basic
> for the Apple I ????
Well, if you check Google Groups you will see that I posted a
partially commented disassembly of Integer BASIC for the
Apple II back in May 2000.
My re-disassembly of the Apple I Integer BASIC took me
50 minutes starting with the original. I did waste some
time before I realized that it was an Apple text file with
CR only end-of-lines which confused one of the tools I used.
$ECF1 was $G5. I changed it to $55. I do not know what
that byte really is.
I stripped off everything except the hex bytes, added .BYTE
to beginning of every line, assembled it to get a binary
file, ran it through my disassembler using only a start
address of $E000 and the routine address tables at
$EA10 (low byte) and $EA88 (high byte). (See the code
at $E6EC through $E6FE.)
Trivial.
--
Paul
Monroe, Michigan USA
Michael J. Mahon
Very nice job--particularly the reverse-engineering and comments!
After Paul Schlyter's prodding, I also "processed" the original
disassembly into a dump, then re-disassembled it using just
the Apple II monitor disassembler. (I figured I'd try something
simple first, since I didn't plan to reverse-engineer it much.)
That turned up several errors, including the $ECF1 error you
mentioned (which I guessed at $B5) and several "address"
errors, where the original disassembly address was off by one.
After comparing my disassembly (uncommented) with yours,
I notice some "version" differences. These are two very
similar, but different, versions of Apple I BASIC, apparently.
I've put my disassembly on my web page for anyone who
is interested.
Eric Smith
> Who will be the first to post such a processed listing of the Basic
> for the Apple I ????
It's much easier and faster to simply do another disassembly using a
better disassembler:
http://www.brouhaha.com/~eric/retrocomputing/apple/apple1/basic/
Michael J. Mahon
Thanks for another very helpful disassembly. ;-)
In a brief perusal, I note several differences from the version of
Apple I BASIC on Applefritter, in particular the regions:
EE53.EE62, EEA6.EEC8, and EF85.EFB2.
Although there may be other, earlier, differences, the fact that
these all occur toward the end of the program suggests that
they may be patches/additions. I can't guess the chronology,
but someone more familiar with the program could probably
put this together.
Of some interest is the reassignment of some zero page locations,
such as LOMEM and HIMEM.
This makes me wonder just how many versions of Apple I BASIC
were actually shipped. It is not hard to believe that it was a work
in progress at the time of the Apple I.
Thinking back to how Woz keyed it in each time he used it
suggests that he may have been continually tuning/enhancing it.
I know that anytime I have had to re-type a program, I can't
help making changes to it that seem obvious in the process of
re-entering it, but were not noticed while it was being written.
It seems that the "mass" of an existing code base is a barrier
to making large or structural changes.
On several occasions, I have lost the source to a program,
making it necessary to re-enter it, either from a listing or from
memory, and the result was always better than before. This
is further support for my motto that: "The wastebasket is our
most important design tool; and it's seriously underused." ;-)