I call it "half-OT" as lots of early CRPGs were Apple-based ;-)

I can confirm your observation: There doesn't seem to be nearly as much available in electronic form (files or websites) than for other popular systems. Part of the reason could be that the Apple II wasn't as successful (it came much earlier, had higher prices) as the megasellers C64 or NES. On the other hand the Apple II wasn't perceived strictly as a game machine but rather as a universal computer with good graphics talents - at least until the machines with hardware sprites came out.

Actually, I have my knowledge from books (not with the pdf-extension - the ones with real paper ;-)

Though most books about Apple II graphics are also rather disappointing as they only deal with BASIC statements, there are some really excellent ones - for example "Graphically Speaking", based on a magazine column by Mark Pelczarski, author of the Graphics Magician which may ring a bell with you - but they are either hard to come by or rather expensive.
The original Apple reference manuals of the Apple II/IIc/IIe can give you very precise informations about the hardware - but they aren't tutorials and they expect you to be somewhat knowledgable in the Apple II (programming) world.

However, what I did find through the usenet group "comp.sys.apple2" two years ago is here:
http://www.computist-project.net/core/thumbs/core.html
The first issue of this short-lives magazine deals with graphics and has some useful articles as well as example listings. You can download a 20 MB PDF there.

What you don't find in there can be answered by me or in "comp.sys.apple2" - the people there are a terribly helpful bunch with some gurus from back then with a knowledge far far exceeding my humble bits and pieces.

You think too complicated ;-)

Here's the basic stuff about the 6-color standard hi-res mode which works on all Apple II models is the most widely used mode in games (I ignore the lo-res modes with 40x48 pixels and the so-called "double-hi-res" mode which came with the IIc/e and wasn't as widely used):

What the Apple II *doesn't* have:

There are no colors in the text mode (only white text on a black screen), no user-definable character sets, no color registers(!), no separate color memory (like the C64 has), no hardware sprites, no display interrupts and except on the IIe no vertical blank detection mechanism (and by that I don't mean a CPU-cycle friendly "vertical blanking interrupt").
In fact an NTSC-capable Apple doesn't even output colors to the screen! Wait - how can that be? You see, the output are always (white) pixels - but at a certain timing. This results in the display to generate the colors - by artifacting. The Apple II was designed that way by genius Stephen Wozniak (aka The Woz) who exploited all kinds of things to keep the chip count on his motherboard low.

What's there, then?

You can have either 192 or 160 lines of graphics - the latter having four text mode lines at the bottom, as said before, but the memory usage is always the same: 8 KB. Because of this large framebuffer and having to write everything in 6502 assembler (no hardware sprites...) Apple II game programmers were often the best 6502 programmers - they had to write extremely efficient code.

The memory for the bottom four text lines (if enabled) is the same as in the text mode which resides at another fixed location.
In fact you can switch the four lines on or off with a single POKE (or equivalent machine code).

These hi-res modes have two framebuffers starting at fixed addresses ($2000 and $4000) which can be switched by software.
So you can - with careful timing - generate flicker-free animations.

The lines are sadly not linear but that can be a good thing as they don't cross page boundaries (which could cost a 6502 instruction an additional memory cycle).
The lines always consist of 40 linear bytes but the bits in them are reversed and bit 7 is used as a "color bit" that shifts the video timing a half pixel resulting in the video display generating different colors.

I can't get into too much detail here but let's just say: It's one of the most complicated frame buffer designs you'll ever see.
The link above should give you enough material to read and you surely will come to the same conclusion: That many games naturally used two bytes for their tiles (or a multiple of two like the innovative Origin RPG "Moebius" which used four bytes per tile).

The reason for the jumble frame buffer architecture is that Woz used the counters of the DRAM refresh logic to drive the video output logic - at the same time and with a minuscule amount of TTL chips. IMHO this is his masterpiece on the Apple II mainboard (the other being the separate floppy disk controller but that one can't be explained in a forum posting by a mere human ;-)

So, from a (game) programmer's view the choice was pretty easy when he wanted to use either colored text or text and graphics at the same time: He _had_ to use one of these graphics modes.
But how to "print" something on them? Use BASIC commands or ROM routines? Nope - the motto was: "Write your own character generator!" or in other words: Printing text to the graphics screen became a standard exercise and lots of people got good at it and later expanded their character printing into a "tile printing" routine. "Plotting" text characters pixel by pixel to the hi-res screen was something for beginner's articles in low-level magazines - several Apple II specific ones offered machine code listings.

Also because of the way the color generation worked "good" programmers/designers didn't use the built-in character data as the basis for their hi-res printing routines but rather defined their own character sets (good examples: The "Where in the world is Carmen Sandiego"-series from Broderbund or the Sherlock Holmes graphics adventure "Another Bow" from Bantam Software).

The Apple has no such mode but I agree with your position as the TI had a pretty fixed hardware.

Using illegal 6502 opcodes would be another example for this: On the Apple II you can't use them as the majority of the models was produced with a 65C02 that didn't support them but on the C64 you could use them without problems as the CPU wasn't changed (and emulators usually support them).

The 6502 in the Apple - unobstructed by stolen CPU-cycles of a video chip (like the 8-bit Ataris and the C64 have) - has quite a good memory access. And as a 11x11 matrix easily fits in a single 6502 memory page (256 bytes) it can be addressed very quickly.
I remember having re-created the U4 LOS-algorithm more than twenty years ago on my trusty Atari (simply by observing what was happening while playing on my friends C64) but I had no speed problems at all - and I won't dare to call my code optimized.
The Atari was clocked 80% higher than the Apple but the video processor stole quite a large chunk of the memory accesses resulting in a comparable performance compared to all other popular 6502-based machines like the unaccelerated Apple or the C64 .

When in doubt I would make the gameplay a bit slower and NOT leave out sounds or other things that make a game world detailed - thus making each step a bit more "meaningful". At least if you aren't deliberately making an action-oriented game.
In the Apple II version of Ultima IV you can walk one or two steps per second(!). The problem doesn't seem to be the screen refresh/tile rendering but the whole gaming world including NPCs, monsters etc.

I'm in no way accustomed to the TI architecturen (other than knowing that it is quite complicated - at least in the standard 16K configuration with the built-in BASIC that is written in an interpreted language itself) so I dutifully agree ;-)

There - I said I tried to be short!

take care,
Calibrator

Every programmer halfway knowledgable in 6502 and with an understanding of Apple hi-res graphics can write a fast tile graphics routine, even I can give you one with source in Merlin format. It's more or less only a memcopy routine with a lot of special cases exploited.

When you examine the Apple hi-res graphics hardware you'll notice some things that are a given: You have to combine a multiple of two horizontally adjacent bytes (even, uneven byte position) to be able to replicate tiles without color problems. This is because of a clever color bit that Woz introduced to get the high amount of colors you mention in the next paragraph.
So if you want lots of tiles you work with the smallest possible tile width - two bytes. This pretty much defined the height of the tile as well: 14 to 16 lines to get an optically pleasing effect.

In fact most Apple rpgs (especially the ones released *after* Ultima) and strategy games of the time used these tile size.
Several of the strategy game programmers at the time used BASIC or compiled BASIC (or weren't as proficient as young Garriott) so the rendering is much slower. However, thinking a day about the algorithm before implementing it can give you a tenfold speed increase.

This is absolutely true - it gives the game a somewhat darker mood. Thank god the conversions of U3 and U4 were more faithful to their originals.

AFAIK all Apple Ultimas used their own DOS (or a modified third-party DOS).

Very possible.

This mode is a standard mode, not a hacked one.
It has 160 lines of hi-res graphics and four text-mode lines, while the pure hi-res graphics mode uses 192 lines.

On the contrary: You would get more tiles on screen without the text window at the bottom.

You can see this
The original Apple U2 uses 20x10 tiles - which fills the whole graphics window. (The C64 does the same but with character/text graphics).
The enhanced Apple U2 uses the same 20x10 tiles but draws a blue border at the screen edges - I guess they make a simple overdraw (which reduces speed a little). What they should've done is reducing the tile window to 19x9 - this way they wouldn't have any overdraw, had less tiles to draw and the avatar would be positioned exactly in the middle of the screen.
In other words: They didn't spend too much time with the "enhanced" Apple version as the PC had less speed problems.

In later Ultimas they used a different tile window which uses a 11x11 matrix - an additional vertical tile line.
Of course: 9 horizontal tile lines less than U2, but this is surely to save CPU cycles as the rendering with the line-of-sight algorithm is much more complicated (Nice disassembly on your site, BTW!).

max. 20% ;-)

On the other hand you lose those sucky green and purple tinted characters when you can use your own carefully designed ones.

Thanks for the link!

take care,
Calibrator

I'm 100% sure that there is no U2 version that supports the Mockingboard as I would've
read about that in countless usenet postings and the keepers of this website gladly
would've included it together with U3, U4 and U5: http://www.applevault.com/ultima/

Actually, I'm not sure which (if any) version has music at all - I don't remember any in
the C64 conversion.
There are also some japanese MSX2 and FM Towns versions and they may have music
but I doubt it (I wonder who did the conversion).

Now, I haven't played any Apple U2 version - would've done that if I had the chance -
but the C64 is pretty much all you need. It's fast, has enough colors and some sounds.
I don't know if the slower disk access is a problem but I don't remember that a problem
back then.

take care,
Calibrator

Re Bill:

;-)

About the enhanced Apple II U2.
From what I've read this version was available *only* in the Ultima Trilogy - not
separately.
About the differences: The graphics overhaul mostly consisted of a blue border
around the tile window - similarily to U4 but without the party stats, obviously.
Also, the the up and down cursor keys are usable now and one can play with the
keyboard set to lower case letters (for those who don't know: the original Apple
II/II+ had no lower case without non-standard third-party upgrades).
Both the original and the upgraded versions were 100% machine code so don't
expect a speed increase.

Re Matt:

I, too, think these retro-blogs are invaluable as they show what's playing those classics
(or forgotten games like Wizard's Crown) with todays eyes and brains. You can really get
an impression what computer gaming used to be in the past - if you weren't there in the
first place.
I play video games for more than a quarter of a century now and I often reminisce what
primitive presentation and often content used to be the standard back then - and how
games will be in another 25 years...

Re Stu:

In the later episodes of the Blogging Ultima blog he carefully tries to not avoid subquests.
A problem might be that he always played for some hours and wrote the blog entry on the next day.
This way not a lot of the content is invariably lost, the tedious bits are barely mentioned etc.
I also don't consider him a cheater - he may have exploited things a bit but not as a rule
(and who can throw the first stone of not having done this in the past?).

Cheating:

I always used cheats as a last resort type of help and mostly in adventure games.
But even then I don't play with a walkthrough near the game but get a tip, return
to the game and play with my own brains again. This way I'm simply more satisfied
and have the feeling that I've accomplished something.
Now I don't consider me either very intelligent nor dumb but some games have such
deviously designed puzzles that I would never come to a solution. I can live with
that but not with weak interface design or tiny objects consisting of very few pixels
to find in a graphics adventure. In such a case I'm more likely to ask for "external help".

I also think Zen philosophy can be applied to a video game: The way is the goal.

take care,
Calibrator

You deserve something you know will be good after GoD...

Wii: 1345 2773 2048 1586 | PS3: ArmchairArcade
Bill Loguidice, Managing Director | Armchair Arcade, Inc.