Were there any games made for the Apple III?

[bpi...@gmail.com]

Published, or even home brew. Not talking about Apple II games running in emulation mode.

[Michael J. Mahon]

<bpi...@gmail.com> wrote:
> Published, or even home brew. Not talking about Apple II games running in emulation mode.

Application development for the Apple III was pretty tightly controlled by
Apple, and they were jealously guarding its image (such as it was) as a
business machine.

Since the machine was never openly documented, random developers were
severely handicapped. Quite a contrast with the Apple II...
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[bry...@yahoo.com]

On Thursday, December 12, 2013 2:43:16 PM UTC-8, bpi...@gmail.com wrote:
> Published, or even home brew. Not talking about Apple II games running in emulation mode.

Super Trek
a sophisticated Star Trek like game for the III

[Gav]

On Thu, 12 Dec 2013 14:43:16 -0800 (PST), bpi...@gmail.com wrote:
> Published, or even home brew. Not talking about Apple II games
running in emulation mode.

Im pretty sure Captain Magneto was Apple III native - never played it
on the III but the Mac version was pretty fun :)

[mikemaginnis]

On 2013-12-13 04:02:23 +0000, Michael J. Mahon said:

>
> Application development for the Apple III was pretty tightly controlled by
> Apple, and they were jealously guarding its image (such as it was) as a
> business machine.

I think it was less a case of anything being guarded than Apple's
inability to get much software finished by the time the /// initally
shipped. This was due more to executive management's decision to allow
marketing to define (and redefine... and redefine... and...) the
machine, which led to code having to be repeatedly rewritten to match
the new specs.

A complete COBOL package shipped on the same day the /// did, as did
Business BASIC, a superset of the original Applesoft found in the
earlier II line. /// Pascal, which included a complete (but buggy)
6502 assembly language IDE wasn't far behind and Fortran was completed,
but never officially shipped after Apple decided to turn its back on
the ///.

The rumor at the time was that you could get your hands on a copy of
Fortran only if you had attended one of Apple's developer "schools",
were an APDA member, and called the right person and begged for it.
Bob Consort later bought up Apple's stock of the Fortran packages and
sold them through ON THREE, along with a lot of other stuff directly
from Cupertino.

>
> Since the machine was never openly documented, random developers were
> severely handicapped.

The COBOL, Pascal and Business BASIC software packages documented quite
nicely the unique features of the /// and how to make use of them in
your chosen IDE. I've not seen a copy of Fortran, so I can't speak to
that. About the only thing that was never clearly documented was how
to use assembly to get at the ///'s features. Apple expected you to
use the IDE in Pascal if you really wanted to do that, so there wasn't
a mini-assembler (or much of anything else, really) in the ROM.

I'd say less, "handicapped" than "ignored". By the time there was
enough of a software base out there, Apple (and most everyone else) had
already moved on.

> Quite a contrast with the Apple II...

Mostly for the better...

--
- Mike

Podcast: http://open-apple.net

[mikemaginnis]

On 2013-12-12 22:43:16 +0000, bpi...@gmail.com said:

> Published, or even home brew. Not talking about Apple II games running
> in emulation mode.

If you do find anything that interests you, don't forget that an Apple
II joystick won't work in native mode on a ///.

[David Schmidt]

On 12/12/2013 5:43 PM, bpi...@gmail.com wrote:
> Published, or even home brew. Not talking about Apple II games running in emulation mode.

A related question came up just the other day on Applefritter:
http://www.applefritter.com/content/list-apple-software

[bpi...@gmail.com]

Wow, so only 3 commercial entertainment titles and a few unpublished home brews. Very sad. I may be acquiring a III soon so that's why I was curious. Anyone want to develop something new? :). I just started working on another Apple II game with a friend of mine, but I may create something for the III in the future, probably the first game made for the system in 30 years! However that be awhile since I have a baby due this Spring!

[Michael J. Mahon]

The best things happen when a platform is used in ways that the creator
*didn't* expect!

> I'd say less, "handicapped" than "ignored". By the time there was enough
> of a software base out there, Apple (and most everyone else) had already moved on.
>
>> Quite a contrast with the Apple II...
>
> Mostly for the better...

Surely, you jest...

Most game developers need all the speed they can get for animation, and the
III was well provisioned for a nice graphical advantage over the II. But
unless the system is documented *to the metal* this is difficult to
exploit.

The Apple III was diametrically opposed to Woz's open concept for the Apple
II. Consider having to be a member of a club (like APDA) to have access to
information and tools to write programs. Wow.

I'm surprised that resale of FORTRAN outside APDA didn't constitute breach
of license.

The platform innovations of the Apple II were all from Woz (and Allen
Baum), and their complete disclosure enabled the creativity of thousands of
hardware and software developers, making the Apple II the most versatile
platform the computer wold had ever seen.

By contrast, the Apple III was designed (and redesigned, and redesigned,,,)
by a committee and marketed as a closed platform, insulated from the vast
(and chaotic) creativity of the marketplace. Is it any wonder that it never
fulfilled its potential?

It always seemed to me that the packaging alone summed it up perfectly:
the Apple II in its pop-top plastic box, and the Apple III in its
impregnable screwed-down metal bunker.

Jobs was nothing if not a control freak. Woz was more, "Look what I
did--now, what can you do with it?"

I think the Apple III is an interesting bit of history, while the Apple II
is a machine that inspired a generation.

[David Schmenk]

The Apple II was built to be a tool. The Apple /// was built to be a business appliance. Too bad, the /// had some very clever hardware. If they had instead built the /// to be the IIe and priced it appropriately, it would have made a nice upgrade. And some great games would have come out for it - imagine 2 MHz, 256 KB, 560x192 graphics and 6 bit sound in 1981.

[mikemaginnis]

On 2013-12-13 19:38:21 +0000, Michael J. Mahon said:

> <Mike Maginnis> wrote:
>> On 2013-12-13 04:02:23 +0000, Michael J. Mahon said:

<snip>

>>>
>>
>>
>> The COBOL, Pascal and Business BASIC software packages documented quite
>> nicely the unique features of the /// and how to make use of them in your
>> chosen IDE. I've not seen a copy of Fortran, so I can't speak to that.
>> About the only thing that was never clearly documented was how to use
>> assembly to get at the ///'s features. Apple expected you to use the IDE
>> in Pascal if you really wanted to do that, so there wasn't a
>> mini-assembler (or much of anything else, really) in the ROM.
>
> The best things happen when a platform is used in ways that the creator
> *didn't* expect!

I don't believe I implied otherwise. ;)

>
>> I'd say less, "handicapped" than "ignored". By the time there was enough
>> of a software base out there, Apple (and most everyone else) had
>> already moved on.
>>
>>> Quite a contrast with the Apple II...
>>
>> Mostly for the better...
>
> Surely, you jest...

I do, but only a bit. The Apple ///'s memory management, for example,
was much more elegant than anything that ever appeared in any of the
8-bit Apple II's.

>
> Most game developers need all the speed they can get for animation, and the
> III was well provisioned for a nice graphical advantage over the II. But
> unless the system is documented *to the metal* this is difficult to
> exploit.

Maybe. I'm not a developer, so I'd be hard pressed to disagree. But,
with the exception of the Apple II emulation mode (a bad idea to begin
with), it wasn't like Apple was trying to prevent people from learning
how the machine worked. As demonstrated in the documentation that
eventually made its way out of Cupertino, the Apple /// was
well-documented. Apple simply lost the will to make any effort to get
it out to people once things went south with the first version of the
///. All of which were replaced by Apple, by the way, with reliable
///s.

>
> The Apple III was diametrically opposed to Woz's open concept for the Apple
> II. Consider having to be a member of a club (like APDA) to have access to
> information and tools to write programs. Wow.

Only for the unreleased FORTRAN. Cobol and Pascal were available on
retail shelves or by mail order to anyone who paid for them. Business
BASIC shipped with the machine.

>
> I'm surprised that resale of FORTRAN outside APDA didn't constitute breach
> of license.

According to Bob, Apple was happy to sell him the remnants of their
Apple /// software as a "bulk buy". He was already an Apple reseller,
so I imagine his license covered him. The FORTRAN stuff was all loose
(disks, manuals, boxes, etc) and each copy he sold had to be
"hand-gathered" and packed up for shipping.

>
> The platform innovations of the Apple II were all from Woz (and Allen
> Baum), and their complete disclosure enabled the creativity of thousands of
> hardware and software developers, making the Apple II the most versatile
> platform the computer wold had ever seen.

Again, the Apple /// was well-documented. Del Yocam's premature,
summary execution of the /// line is why it didn't get into users'
hands sooner. Sales of the /// had increased dramatically with the
introduction of the ///+ and from the developers I've talked to, the
/// had a much larger profit margin than the II's selling at the same
time, even when the ///+ was cut to $2,300 (naturally). Had the ///
been given the chance it deserved, I believe we'd have come a lot
closer to that open, everything described utopia you described.

>
> By contrast, the Apple III was designed (and redesigned, and redesigned,,,)
> by a committee and marketed as a closed platform, insulated from the vast
> (and chaotic) creativity of the marketplace. Is it any wonder that it never
> fulfilled its potential?

It didn't reach its full potential because Apple mishandled the PR in
dealing with the single initial engineering bug, not because it was a
closed platform. A rocky software rollout timed with the ///'s initial
release didn't help either. Once the bug was fixed and the
manufacturing / assembly line issues were addressed, the /// was a
solid computer.

>
> It always seemed to me that the packaging alone summed it up perfectly:
> the Apple II in its pop-top plastic box, and the Apple III in its
> impregnable screwed-down metal bunker.

The Apple /// lid requires the loosening of exactly two locking screws
to remove. If you want access to the entire motherboard, you need to
remove the bottom plate/board assembly, but the same could be said of
the Apple II. You see more of the II board when you pop the case, but
not all of it.

>
> Jobs was nothing if not a control freak. Woz was more, "Look what I
> did--now, what can you do with it?"

Jobs oversaw the case design, managing Jerry Manock and his partner and
issued the famous "no fan" edict, but was mostly looking for the
Apple's future in the Lisa and then Macintosh projects. By all
internal accounts, Jobs didn't have much do wiith the /// beyond that.

>
> I think the Apple III is an interesting bit of history, while the Apple II
> is a machine that inspired a generation.

I absolutely agree with the latter half of your statement, and somewhat
with the former, but I think there's more to the /// than relegation to
the dusty corner of "an interesting bit of history."

[Michael J. Mahon]

I detect the beginnings of "violent agreement". ;-)

However, the Apple II shipped with low-level documentation. When, some
years back, I tried to find low-level documentation for the III, the best I
could find was a column written for a magazine! I guess I never joined the
club.

Consider the WozPak versus a Pascal library.

That nice dynamic bank switching deserved a schematic diagram and a
definitive document on protocols for its (mis)use.

As for the case, that created an engineering nightmare. Look at the kludgy
way that the memory is connected--what a way to treat critical high-speed
signals--all because of the case design. And heat buildup... Socketed ICs
never gave the II a bad rep (though they are clearly a tradeoff of
reliability for hackability).

Someday I should tell you how I *really* feel about "appliance" being
shorthand for "hard to hack". ;-)

Of course, the III was just a first step in this direction. Apple has gone
much further down this path since, saying, "So long, and thanks for all the
fish!" to the hackers who enabled their success.

[Michael J. Mahon]

Exactly. And with a little more engineering and fewer arbitrary management
constraints, it would never have acquired its unfortunate reputation for
unreliability.

[Mike]

On Fri, 13 Dec 2013 16:22:32 -0600, Michael J. Mahon <mjm...@aol.com>
wrote:

Not at all ;)

>However, the Apple II shipped with low-level documentation. When, some
>years back, I tried to find low-level documentation for the III, the best I
>could find was a column written for a magazine! I guess I never joined the
>club.
>

The /// didn't ship with it, but it eventually escaped Cupertino.

>Consider the WozPak versus a Pascal library.
>
>That nice dynamic bank switching deserved a schematic diagram and a
>definitive document on protocols for its (mis)use.
>

Perhaps. We'll never know what might have been, but it's all been
nicely documented by /// hackers who wanted to know what Apple
wouldn't tell them. Bob Consorti, for example, managed to create his
own assembler IDE for the ///, which was faster and better than
Apple's own that was included in Pascal, and then turned around and
used it to develop a bunch of not so horrible ;) /// software from ON
THREE.

>As for the case, that created an engineering nightmare. Look at the kludgy
>way that the memory is connected--what a way to treat critical high-speed
>signals--all because of the case design. And heat buildup... Socketed ICs
>never gave the II a bad rep (though they are clearly a tradeoff of
>reliability for hackability).
>

And your statement there, really, is exactly what killed the ///. Not
the actual design flaw - there was only one: the decision to use tin
rather than gold in the memory connector - but the perception. There
was no "heat build up" problem with the Apple ///, as Jerry Manock has
proven on more than one occasion. This was misinformation spun into a
nasty rumor by the tech press. When Apple designed its new assembly
line in Dallas for the Apple ///, they spent a ton of money on shiny
new automatic DIP insertion robots. And programmed them incorrectly.
This led to the chips not being seated properly, a situation which was
worsened by the loving, gentle vibration of the trucks in which they
were transported to their various destinations. Eventually, when the
things were turned on and reached normal operating temperatures, they
already-loosened chips suffered contact issues.

The case was never designed to be any kind of heat sink, but was a
catch-all to try to deal with the then-upcoming new FCC rules about
computer RFI and still get the computer out the door in time to meet
their schedule and hopefully boost the IPO. Had there been a fan or
a lighter case, you'd still have had an Apple /// with loose chips -
just one that didn't fail quite as regularly or quickly.

The other issues, such as the new wave-soldering wash method that
caused the corrosion problems with the fineline traces, weren't
design problems either, but manufacturing failures which were handled
by correcting the chemical mixtures in the baths, and updating the
motherboard with a different number of layers.

Apple replaced all 14,000 faulty machines with new ones. There were
no reliability problems after that, and the ///+ added a nice bit of
polish.

>Someday I should tell you how I *really* feel about "appliance" being
>shorthand for "hard to hack". ;-)

Aw, where's your sense of adventure? That desire to rise to the
challenge of a "harder hack"? (I say that only as a gentle rib and
with a wry smile.)

>
>Of course, the III was just a first step in this direction. Apple has gone
>much further down this path since, saying, "So long, and thanks for all the
>fish!" to the hackers who enabled their success.

I respectfully disagree with you, but I also respect your right to say
it. :)

Mike Maginnis

Podcast: http://open-apple.net

[Mike]

On Fri, 13 Dec 2013 16:22:32 -0600, Michael J. Mahon <mjm...@aol.com>
wrote:

<snip>

>
>I detect the beginnings of "violent agreement". ;-)
>

Wait, I misread that... You mean you might have to agree with me? HOW
DARE YOU SIR! ;P

[Michael J. Mahon]

Mike <mi...@apple2scans.net> wrote:
> On Fri, 13 Dec 2013 16:22:32 -0600, Michael J. Mahon <mjm...@aol.com>
> wrote:
>
> <snip>
>
>>
>> I detect the beginnings of "violent agreement". ;-)
>>
>
> Wait, I misread that... You mean you might have to agree with me? HOW
> DARE YOU SIR! ;P

;-)

Thanks for the clarification regarding the III's manufacturing
problems--I'd never heard that part of the story.

But I had heard that the III+ was a fine machine, from an Apple employee
who regularly used one.

Certainly, the Apple II benefited greatly from the III-derived ProDOS and
Appleworks.

And Apple benefitted from the hubris-deflating experience of the III--at
least for a while. ;-)

[Christopher G. Mason]

On 12/13/2013 3:08 PM, David Schmenk wrote:
>
> The Apple II was built to be a tool. The Apple /// was built to be a business appliance. Too bad, the /// had some very clever hardware. If they had instead built the /// to be the IIe and priced it appropriately, it would have made a nice upgrade. And some great games would have come out for it - imagine 2 MHz, 256 KB, 560x192 graphics and 6 bit sound in 1981.
>

I keep reading about this 6-bit sound, but never heard any samples. Did
any programs take advantage of it? Perhaps its time for an Apple ///
demo. ;)

[Egan Ford]

On 12/13/13 1:08 PM, David Schmenk wrote:
> imagine 2 MHz

Correct me if I'm wrong, but 1.8 effective MHz after memory refresh, and
1.4 effective MHz after video refresh (video refresh can be disabled).

[Egan Ford]

On 12/14/13 1:08 PM, Christopher G. Mason wrote:
> I keep reading about this 6-bit sound, but never heard any samples.

I want to hear this as well.

[Egan Ford]

On 12/13/13 11:29 AM, bpi...@gmail.com wrote:
> Anyone want to develop something new? :)

I would love to. I purchased an Apple /// around October last year.
Unfortunately ~9 months ago it stopped working. I do not have the skill
to fix it, but hope to find the time to explore how to fix it soon.

I would prefer to cross-develop for the ///, but I have not tracked down
all the relevant documentation on how to do assembly programming on the ///.

Anyway, yet-another-project ...

[Egan Ford]

On 12/13/13 5:46 PM, Mike wrote:
<<< some awesome stuff >>>

> Mike Maginnis

Eagerly awaiting Mike's Apple /// book, "Capability and Complexity, The
life and times of the computer that almost could ..." :-)

[Steve Nickolas]

I hear you on that. I haven't found a good emulator that runs on anything
but a Mac, so I can't even test my own code... I have a crude one that was
made specifically to run it, and it's not really useful for real ///
stuff.

-uso.

[Michael J. Mahon]

A real D/A converter is a great thing.

My soft D/A does 5 bits at 11k samples/sec, but requires 100% of the
processor to do it! (SOUND.EDITOR, SYNTH, RT.SYNTH, etc.)

[David Schmidt]

You guys just need to get on the iron and do it!

Depending on the application, I use either ca65 for plain old SOS code
(ADTPro is probably 85% common between SOS and ProDOS, for example) or
the old Pascal system assembler for device driver work. The ca65 end of
things, Egan, you already know how to do.

In order to write a program that SOS will run, you just start with a
little header like this:

.ORG $2000-14 ; START ADDRESS
.BYTE $53,$4f,$53,$20,$4e,$54,$52,$50 ; "SOS NTRP"
.ADDR $0000 ; No extra header
.ADDR ASMBEGIN ; Tell 'em where it starts
.ADDR ASMEND ; Tell 'em where it ends
ASMBEGIN:
...
ASMEND:

Name it SOS.INTERP on a SOS boot floppy and it'll run at boot time.

Device driver work with the Pascal assembler can be a little trickier -
if you type in source code on a modern machine, you need to put the file
back on a disk image with something that knows how to write Pascal
Text-format files. I talk about that process a little here:
http://code.google.com/p/apple-iii-cffa3000-driver/

[Mike]

On Sat, 14 Dec 2013 17:28:43 -0700, Egan Ford <data...@gmail.com>
wrote:

I wouldn't hold your breath for that. To the surprise of no one, it
turns out I'm every bit as bad at writing as I thought I was.

[gid...@sasktel.net]

> I would prefer to cross-develop for the ///, but I have not tracked down
> all the relevant documentation on how to do assembly programming on the ///.

Start reading

http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20III/Apple%20III/Documentation/

a really good start

http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20III/Apple%20III/Documentation/Bank%20Switch%20Razzle%20Dazzle.pdf

[Steve Nickolas]

On Sat, 14 Dec 2013, David Schmidt wrote:

> You guys just need to get on the iron and do it!

Gotta have the metal to use the metal. :P

> In order to write a program that SOS will run, you just start with a little
> header like this:
>
> .ORG $2000-14 ; START ADDRESS
> .BYTE $53,$4f,$53,$20,$4e,$54,$52,$50 ; "SOS NTRP"
> .ADDR $0000 ; No extra header
> .ADDR ASMBEGIN ; Tell 'em where it starts
> .ADDR ASMEND ; Tell 'em where it ends

Same idea when I'm using CA65.

lodadr = $5CD0

.org lodadr-14
.byte "SOS NTRP"
.word 0
.word lodadr
.word prgend-lodadr

header: cld
ready:


I wonder whether I needed that CLD or not, but that's what I did. Worked
with an old MESS, but MESS is a punk.

-uso.

[mdj]

On Saturday, 14 December 2013 08:22:32 UTC+10, Michael J. Mahon wrote:

> > The Apple II was built to be a tool. The Apple /// was built to be a
> > business appliance. Too bad, the /// had some very clever hardware. If
> > they had instead built the /// to be the IIe and priced it appropriately,
> > it would have made a nice upgrade. And some great games would have come
> > out for it - imagine 2 MHz, 256 KB, 560x192 graphics and 6 bit sound in 1981.
>
> Exactly. And with a little more engineering and fewer arbitrary management
> constraints, it would never have acquired its unfortunate reputation for
> unreliability.

I do really admire the ///'s hardware features, especially the 'extended addressing' on indirect modes to allow 24-bit addressing for data. Bank switching is fine for code, and combined with the extended addressing it had a programming model that was a 16-bit stack pointer away from being an Apple IIgs. Unfortunately that's a *very* big architectural issue when you're trying to encourage your development community to write in high level languages which can't be made to run efficiently. Still, it was quite an achievement considering the deadlines the product was built under and that like the Apple II there's no custom hardware involved.

I don't know how close to 2Mhz it could get, but considering the losses for RAM refresh and that video on the /// is a DMA peripheral, I wouldn't expect an effective speed above 1.5Mhz. Better, but not amazingly so.

I think the ///'s biggest problem is that the jobs it was built to do were already done very well by its predecessor; VisiCalc and AppleWriter were excellent tools, and as we saw with AppleWorks a few years later, the ///'s hardware features just aren't required, and the Apple II's installed base was already pretty impressive.

It's really difficult to see even without the manufacturing foul-ups how it could have been a success. Apple's machines were expensive to begin with, and equivalent functionality at twice the price is nobody's bargain. The only machine that could really succeed the Apple II was a new Apple II, and the /// was intentionally designed to not be that.

I think it just proves the old adage, "less is more", and the machine they *finally* got around to building that did the job better became one of the most successful computer products in history.

Matt

[David Schmenk]

I believe that is correct. There was some key sequence to disable video and get higher performance. How user friendly is that?

Dave...

[Egan Ford]

On 12/14/13 9:49 PM, David Schmidt wrote:
> In order to write a program that SOS will run, you just start with a
> little header like this:
>
> .ORG $2000-14 ; START ADDRESS
> .BYTE $53,$4f,$53,$20,$4e,$54,$52,$50 ; "SOS NTRP"
> .ADDR $0000 ; No extra header
> .ADDR ASMBEGIN ; Tell 'em where it starts
> .ADDR ASMEND ; Tell 'em where it ends
> ASMBEGIN:
> ...
> ASMEND:
>
> Name it SOS.INTERP on a SOS boot floppy and it'll run at boot time.

Excellent. Thanks!

[Michael J. Mahon]

Reminds me of the Timex-Sinclair 1000, something I never thought I'd say in
the context of Apple machines. ;-)

[David Schmidt]

On 12/15/2013 1:36 AM, gid...@sasktel.net wrote:
>
>> I would prefer to cross-develop for the ///, but I have not tracked down
>> all the relevant documentation on how to do assembly programming on the ///.
>

[...]

> a really good start
>
> http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20III/Apple%20III/Documentation/Bank%20Switch%20Razzle%20Dazzle.pdf

Hey, that's _MY_ HTML version of (John Jeppson's article that I copied
from somewhere else and rendered into HTML by hand... oh, never mind.
The internet is all about backup, right? ;-)

You can (also) find that and other good stuff over on apple3.org...
http://apple3.org/iiimagazines.html#articles

[Egan Ford]

Thanks. Something to read over xmas break.