The V11 JFIF viewer for the Atari Falcon 030-only version 2.18, 9/1/94. By David R. Oldcorn of Volume 11 Software Development All Falcon-specific parts copyright 1993-1994 Volume 11 Software/DR Oldcorn Based on the JFIF C conversion software originally by the Independent JPEG Group. DSP56001 code and interface written 23/7/93 - 28/7/93 (not included) GIF and Graphics Interchange Format are trademarks of Compuserve, Inc. Usage: About the easiest setup is to set it on a function key and as a JPG extension triggered system, so double-clicking a JPG file will show it onscreen, and an F-key will bring up the viewer. Once it is running in viewer mode the controls are as follows: File selection screen: A-Z: select drive to be displayed. Cursors: move file cursor RETURN: show file / enter subdirectory BACKSPACE: exit subdirectory *: show info on current file Esc: exit to desktop Space: mark file for slideshow Tab: start slideshow (show all if no files selected) Shift+Tab: continuous slideshow (as above but doesn't pause) Insert: switch to preferences screen Help: show keylist & program info Delete: delete currently selected file... will prompt! In display mode: Cursors: move screen Esc: exit now Return: exit / next slideshow file Space: halfsize picture Backspace: switch interlaced frame alternacy (not enormously useful, but there to show up an unusual problem with interlace on a friend's TV). On preferences screen: Cursors: move cursor / alter contrast settings Space: change status Shift+Curs: +- 10 to contrast settings Return/Esc/Insert: exit This 030 version is entirely public domain, and you are free to distribute it as much as you like AS LONG AS it and this file are NOT ALTERED in ANY way, and that it is always accompanied by this file. The full DSP version of this software is available for œ5 from: Volume 11 Software Development, PO Box 311, Broughton Preston PR3 5DZ (England) All monies should be made payable to D. Oldcorn. Note that the DSP version is not at all public domain in any way, shape or form and may not be copied for distribution. I can be contacted until at least August 1994 on email at: oldcornd@cs.man.ac.uk If you have an email account, and want the DSP version, then I can send it to you by email if you want - it's quicker for you, and cheaper for me! All feedback, suggestions and comments welcome. Disclaimer (just in case anything goes wrong I am not responsible): This software will not necessarily perform to the specifications set out below due to unforseen problems, and you take all the blame for anything that goes wrong when you try to use it. If this idea disturbs you, please do not attempt to use this software. GENERAL NOTES All pictures are displayed in Falcon 16-bit Truecolour. Even the ST formats (Degas etc.) are run in TC mode, so all the halfsize features still work. Working memory is: size of file buffer + about 50K + about 100K(DSP) + size of selected image buffer The file buffer is 8K for Targa and JPEG with continuous read on, and the file size for everything else. For VERY large pictures operating in hardware scroll mode can require around 2.5-3 Megs due to the very large final image. Memory available to the program is the size of the biggest UNFRAGMENTED free block in the TOS memory space. This does NOT include the default screen (the desktop / select screen) so running the viewer from high colour or large desktop screens will reduce the amount of memory available. Best mode for memory is 640x200 2 colour. Running the viewer after other programs can result in it having surprisingly little memory, as main memory can become fragmented. If you get an 'out of memory' error, set a lower res video mode, turn hardware scroll off and probably set halfsize on - this will limit the screen size by not allocating memory for areas outside the left and right of the visible screen area (it WILL still allocate for VERTICAL scroll but if halfsize is on this is unlikely to be necessary). It has displayed JPEGs as big as 640x2500 and 1700x1700 (halfsized) on my 4 Meg machine. In slideshow mode, remember it has to hold TWO pictures in memory at once... so you won't be able to show very big pictures one after another without running out of memory. That said, if you're running it in a clear Falcon with just the Control Panel installed, you should have about 3.8 megs free, so the pics will have to be big to cause problems. Things can get really messy if it runs out of memory in slideshow mode, as attempts to report this fact will usually go unnoticed. It will generally sit and ping a lot! Due to a slightly unhinged design flaw in the Falcon video XBIOS (which was always present on the ST too, but because direct hardware accesses were OK you could get round it) the screen resolution can't be changed without clearing the screen (to white, of all things) which 1) leads to the flicker when an image starts loading and 2) leads to flickering and unusual output when the slideshow swaps an image, especially if it has to change resolutions VGA mode is limited to 320x240 because the Falcon doesn't support 640-wide screen modes in VGA Truecolour. The hardware scroll and halfsize should still be OK so you WILL be able to see a full picture. All VGA modes are currently untested, because I don't have a VGA handy. Some feedback has indicated to me that all the VGA bits are completely cream crackered so don't bet on it working. Full PAL height uses direct access to the video hardware to remove the top and bottom borders produced when using overscan on a PAL (50Hz) TV or monitor, this may not work on later versions of the hardware. When you select this mode your monitor may do something strange, if it does don't use it (on 4 different TV's and 2 different monitors there haven't been any problems so far). This produces the maximum 600 data lines, although you'll probably need a vertical resize to see the top 30 and bottom 10 of these. The STe hardware scroll registers are also used for pictures which are wider than the screen. These should be valid on all Falcons, but an option is given to disable horizontal scrolling, in which case the hardware register will not be accessed, and the extra memory required for the screen will not be allocated. All hardware accesses can be optionally disabled, which will prevent any possibility of any illegal hardware access. It pings when it's finished loading whatever it's loading It's not MultiTOS compatible but it is quite legal in terms of memory usage and management. Running this under MultiTOS would be completely pointless. (As far as I can tell, the incompatibility is caused by changing screen res + direct screen access: although this program could manage without res changes, if it used the VDI it'd take weeks... currently plotting one pixel takes 9 instructions in YCrCb...) Error messages will not be printed unless using 'info' on a file. If a slideshow is begun with no selected files, it will run every file in the current directory. Holding SHIFT when slideshow is activated will cause it to run without pauses. If no files are being written it will run in a continuous loop. It has a buffering system to reduce the amount of memory used on JFIFs and Targas, by default this will not operate on display from floppy (as it is VERY slow!) but can be changed from the options menu. GENERAL NOTES ON JFIF CONVERTER. Current version implements a subset of JFIF. BUT most standard JFIF's will certainly be supported. It will only handle images in YCrCb and greyscale (the only two logical colourspaces for general use). Noninterleaved scans are not supported, if I ever see one it will be. Non-integral upsampling ratios are not supported. This should cover the vast majority of JFIF files. (This covers ALL the JPEGs I have encountered, and all which can be created using the Independent JPEG group's CJPEG software). It is recommended that ALL stored JPEGS should be 2x2 1x1 1x1, the software is most efficient at these sampling ratios. Error checking is performed, and faulty files will halt the decompacter and/or produce garbage. Resyncing is NOT guaranteed even if restart markers are included, but in most cases some kind of resync should be possible. Halfsize reduction is performed by a supersampled zoom at the upsampling stage (only approximately if you are using non-1x1/2x2 ratios, but this should be fairly rare). NOTES ON DSP CODE: The DSP version is slightly more limited than the plain vanilla 030 version, due to the limited memory available to the DSP and the logistics involved in programming a fast, efficient DSP version. As a result, some JPEGs will have be processed by the 030 entropy decode rather than the DSP, which will be slower - anything with restart markers will have to be done on the 030, and anything with silly sampling ratios (CrCb ratios must be 1x1 1x1 to be OK, and Y must be 1x1, 2x2, 2x1 or 1x2). The DSP version completely ignores any detected errors in the input file (e.g. corruption leading to invalid Huffman table entries being referenced). If you suspect this, run the 030 entropy decode, which will produce an error message if there is a problem. On average it runs about 4 to 5 times faster than a pure 030 scan. If a full DSP scan can't be done, and the DSP is available, it will use DSP iDCT and 030 Huffman, which will run about half of full DSP speed. 030 mode will also be selected if the DSP has been locked out for any reason. Other DSP programs should run OK after the JPEG process has terminated. The DSP system is specially optimised for 640-wide 2x2 1x1 1x1 images and makes maximum use of available 030 and DSP power on these images. NOTES ON GIF CONVERTER Interleaved scans are not currently supported, because I haven't got any interlaced GIF's! If no colour map is present it will do something silly. Halfsize reduction and cutdown are not supported (i.e. hardware scroll mode only for images bigger than the screen). It's bloody slow, but that's LZW for you. FILE WRITE MODE The viewer is capable of writing an output file whilst displaying some of the available formats (JFIF and Targa). The output format can be either JFIF or Targa (uncompressed 24 bit or 8 bit greyscale). When it writes, it will write a new file whose name is the same as the old one except for an appropriate extension change. If this file already exists it will attempt to find a unique filename by tagging A's onto the name or by moving the last letter of the filename up one (if all 36 last letters A-Z and 0-9 are used it will not write). I particularly do not guarantee that this is 100% working, and any files deleted by accident are your problem. It hasn't ever happened to me but I never trust these things. If an error occurs the program may do one of three things: 1. Ignore it and carry on, probably producing a corrupted image 2. Halt the write process, closing the file, reporting the error 3. Go Bye Bye (unlikely) If (Esc) is pressed during write, the file will be closed and will be incomplete. NOTES ON JFIF COMPRESSOR The compressor implemented is a standard JPEG compression, with full quality setting (1-100, as CJPEG) and Huffman coefficient optimisation, which will reduce the size of the compressed file by about 5-10% (it is especially efficient on small files). Using the optimiser will only add a few seconds to the compression time, but more memory will be required. Sample ratios are fixed at 2x2 1x1 1x1 (YCrCb) and 1x1 (greyscale). Nothing else is particularly useful anyway. Memory usage can be large, at least 100k or so, and it will attempt to use as much memory as possible, to reduce time in disk access. This is especially useful during optimisation, where it will attempt to use memory if possible, but otherwise will use a (VERY large) temporary file on disk called TMPFILE$.$$$. This will be about 900Kish for 640x480. If it runs out of space things may be a little confused, but hopefully it will close everything and delete the temp file. BE WARNED users of AHDI before 6.06, filling a drive can sometimes result in the loss of boot sector on the next logical drive, which can be very difficult to recover. Known bugs: If really badly out of memory has been known to crash quite heavily, but with new slideshow memory checking this is now rare/gone? VGA is completely duff I think History: 2.18: Error handling actually reports something a bit more useful. Optimisation shown in info. JFIF can now write just greyscale. Delete file option added. 2.17: JFIF write while decomp (oooh, doesn't it sound simple - this added 50K to the source and 5K to the object). Some small bugs fixed, vskip locked to valid values, and a rare but extremely dangerous out-of-memory crash when switching res prevented, I hope! Fixed Targa cutdown so it actually works! 2.16: Targa write while decomp, if wanted, plus Targa read, greyscale and 24-bit RGB only, will do more when I can get some more example Targa files. Targas run through new buffered memory system to massively and essentially remove memory overhead. JPEGs now do too. This may be a bit slow on write-and-decomp. Options handler made a bit less obfuscate, and speeded up quite a bit. Entire output handler moved over to a more flexible format ready for JPEG compacter to be introduced. Changed PAL600... it's now a bit of a misnomer cos it's now only about 590 lines.... 2.15: Rebuild to modular version started. Memory overhead dropped by changes to huff handlers, which also fixed a restart marker problem. Added quality factor to JPEG info. Changed the restart marker processor slightly so if it finds errors it at least TRIES to carry on. 2.14: Save preferences, and switch to assemble 030-only version. File sizes now shown. GIF bugs fixed. PAL600 fixed for TV's that have fiddly syncpulse requirements. Screen scroll system fixed properly. DSP lock and error detection now reported to options screen. Upsampler reworked to allow halfsizing of all JPEG's. Halfsize bug fixed. Enabled a key to swap frame alternacy to occasionally improve display of some JPEGs on Ken's TV. Contrast expansion added. Went over to DSP code 2.02 to fix a bug if the first image loaded was greyscale. 2.13: Added other file format handling: Degas, Spectrum 512 (you won't BELIEVE how much fiddling this routine's been through, since I had to manually tune it - and a stupid bug didn't help!). Fixed memory allocate to only allocate on 4-byte boundaries beacuse otherwise the video system complains. 2.12: Fixed a series of bugs in MCU transform and upsampler to get more sampling ratios working properly. Improved GIF converter a bit. Added SOF1 marker to let low-quality sampled images work properly. Added 'slideshow all' mode if no files are marked. Switched over to 16-bit Truecolour, but can't see the difference, so I dunno whether it works! 2.11: Fixed PAL600 bug caused by manky video programming. Introduced Info. Introduced source history. Which is why it doesn't go too far back! 2.10: Added slideshow mode, including view-and-decompress any pic, including major rewrites to all the video code. Code rearranged into logical sections (select/view & scan, JPEG, GIF). Added no-hardware access mode. Fixed some minor bugs with selector. Rewrote DSP output transform to fix some more sample ratios for DSP. 2.09: Rewrote upsampler for more than just 2x2/1x1 sample ratios. Went over to DSP code 2.01, and rewrote IDCT-on-DSP output transform accordingly. Moved big non-initialised data to BSS segment. DSP code history: 2.02: Fixed bug to force greyscale images to work OK 2.01: All coefficient output converted to be range-limited. Some speed modifications made. 2.00: Huffman/IDCT on DSP. 1.0: IDCT on DSP. Rough Execution times for 640x480 colour JPEG: 030 version: 18 seconds DSP version: 6 seconds Currently supported file formats: JPG - JPEG File Interchange Format GIF - CompuServe GIF (TM) PI? - DEGAS uncompressed PC? - DEGAS compressed SPC - Spectrum 512 compressed TGA - Targa, 24-bit colour and 8-bit greyscale uncompressed only Regular updates should be available - when I either think of new ideas, or manage to find a new JPEG it won't handle! Coming soon: Starball, an ST / Falcon Pinball game, which is completely awesome, in every respect. Falcon features include 50 frames per second operation and stereo soundtracker sound. Even on the ST it'll blow your socks off. Believe it!