Re: Laser 128 - questions...

[mjmahon@aol.com (Michael J. Mahon)]

Ed Eastman replied:

>Michael J. Mahon wrote:
> > So it is interlaced, with the odd half of screen 1 followed by the 
>odd  half of screen 2 in the first field, followed by the even half of 
>screen 1 and the even half of screen 2?
>
>Interlaced no, squished to fit, yes.  Perhaps my interpretation of 
>interlaced is different than yours.  I believe you are suggesting that 
>the mode shuffles the lines together like a deck of cards or stacks them 
>side by side for a right/left merging.  It does not.  It stacks page one 
>and page two of either HGR or DHGR screens like two bricks, one on top 
>of the other.  Each graphic is squished so it all fits in the normal 
>display area and effectively gives you twice the verticle resolution for 
>any A2 standard video mode.  (I'm uncertain which video modes it does 
>NOT work in.  I am not sure it works HR and DHR.)

Ed, since each hi-res page has 192 lines, and since the monitor
you are using is only capable of approximately 60Hz vertical
deflection and approximately 15kHz horizontal deflection, the
only way to get more than 260 or so lines (including vertical
blanking interval) is to interlace.

By that, I mean that all the odd-numbered lines of both screens
are displayed first (the first 192 active lines), then all the even-
numbered lines of both pages are displayed between the odd
lines of the first field.  This will create an image of screen 1
over screen 2, each screen containing 192 active lines.

This is the way that "ordinary" TV gets about 500 lines, and
is the only way that a TV-standards display can do so.

Laser chose a video order that is harder to achieve by modifying
an Apple than simply displaying screen 2 interleaved with screen 1
(which is still an interlaced display, but with all of the first field being
screen 1 in normal order, and all of the second field being screen 2
in normal order).

The only advantage I can see to the choice Laser made is to allow
ordinary graphics "paint" programs to be used to paint separately
the top half and the bottom half of the QGR screen (allowing for the
2:1 vertical pixel compression).

>40 column Text mode, page 1 or 2: 40h x 24v as text
>$400-7ff or $800-bff
>
>80 column Text mode: 80h x 24v as text
>$400-7ff (main ram) & $400-7ff (aux Ram)
>
>(lores) Gr mode, page 1 or 2: 40h x 48v x 16c
>$400-7ff or $800-bff
>
>(lores) DGR mode: 80h x 48v x 16c
>$400-7ff (main ram) & $400-7ff (aux Ram)
>
>HGR mode, page 0 1 2 or 3: 280h x 192v x 5c
>$0-1fff, $2000-3fff, $4000-5fff, $6000-7fff
>
>DHR mode 1 or 2: 560h x 192v x 16c
>$2000-3fff (main ram) & $2000-3fff (aux ram)
>$4000-5fff (main ram) & $4000-5fff (aux ram)
>
>Laser128 only:
>QGR mode, single page consisting of page 1 and page 2 of normal mode: 
>280h x 384v or 560h x 384v
>Memory is page 1 _and_ page 2 of given mode, page one in the upper half 
>of the screen, page two on the lower half.

The problem with _any_ extension of a popular platform is that it takes
a long time--maybe never--before there are enough of them in the platform
mix so that it makes any sense for a developer to invest in supporting the
extension.

The worst case scenario is that it gets to be barely critical mass, and
has the effect of splitting the market for developers, so each part of
the market gets only its "share" of developers.

If the extension is critical and enabling, then new kinds of applications
will be written, but only after critical mass is achieved.  If the extension
is only "more of the same", it rarely enables the development of really
compelling apps, and that, in turn, limits the value of the extension.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/