Mini-docs

JPX (and JPY) is a jpeg viewer for the 64.  The x is for experimental.
JPZ is the IFLI (full-color) version.

JPX loads jpegs from the current device/directory.  The display is a
320x200 "window" of the full picture, whatever its size.  The entire
picture may be viewed using special Cheese-O-Rama technology, by starting
the 320x200 window at any row/column (1 row = 8 vertical pixels; 1 col =
8 horizontal pixels).  Upon exiting, SYS 4096 will run the program again.

Sometimes, you will encounter pictures which make the decoder barf.  There
are three probable causes: 1) the application uses some goofy and lame
segment that the decoder doesn't understand, b) the jpeg is a progressive
jpeg, and iii) there is a bug in the decoder.

With the first and second possibilities the simplest solution (if you have
access to a unix machine) is to run "jpegtran" on the picture

	jpegtran file1.jpg > file2.jpg

Jpegtran can also rotate pictures, as well as other simple transformations.
The third possibility is, of course, impossible.  But drop me an email if
you encounter images which fail.


About this program and its future
---------------------------------

JPX is a simple program with a simple purpose: to serve as a tool for
debugging the decoding routines and develop several ideas.  It is
released in this "experimental" state to give a crude jpeg viewing
capability to the 64, and to get feedback from users (both suggestions
and problems!).  JPX is a _work in progress_!

The future of this little piece of code is the SuperCPU.  Once the
decoder is stable (and it's pretty close!), some simple modifications
can (and I expect will) be made to do things like save the image as
a geoPaint graphic, or decode the entire image to postscript.

That's great, but now broaden your vision a little and imagine loading
in a full image, cropping, rotating, resizing/scaling the picture,
touching it up here and there, lightening the image, viewing it using
several different methods, and being able to save the final result
in a variety of graphics formats, including 24-bit ones you can take over
to Kinkos or a PC, ones you can incorporate into GEOS or feed into GoDot,
or ones you can simply view on a 64.  Then imagine doing that to other
formats besides jpegs.

Now, why did you want to dork around with jpegs on a stock machine,
again?

Finally, once I'm happy with the code, the source will as usual be
released and be available in the Fridge.


Memory map (sort-of)
----------

There is a simple interface for the renderer, in case you feel motivated
to write one:

$A000	Init renderer
$A003	Render 8 lines.  .AY = (lo,hi) pointer to 8 lines of 8-bit luminance
	values, organized in 8x8 blocks (just like c64 bitmapped graphics).
$A006	Display picture

"Init" is called when the actual image decoding begins -- note that the file
is open, so be careful modifying $DD00 (use LDA $DD00 EOR xxx STA $DD00,
not LDA #$xx STA $DD00).  "Render" is called to render 8 lines of data,
organized in 8x8 blocks as as

	byte1 byte2  ...  byte8		byte64 byte65 ...
	byte9 byte10 ...  byte15	...
	...
	byte56 byte57 ... byte63

Note that the color data is decoded, but is currently discarded (one
thing at a time, eh?).  "Display" is called when the image is finished
and the file closed; it should wait for a keypress.  When it exits, the
main code restores text mode in bank 0.

Free memory includes $40-$7F in zero page, $5800-$7FFF and $C000-$FFFF.

Note that this memory map will surely be changing in future versions.


Credits
-------

JPX was written after a few weeks of research and one week of intense coding.
Errol Smith deserves special mention for getting the ball rolling, by pointing
me in the right direction (towards some decent jpeg documentation).
And the output would be merely a set of numbers if it weren't for the
very cool renderers by Adrian Gonzales (adrianglz@globalpc.net).

sjudd@ffd2.com
12/23/99