Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4381 > unrolled thread

QuickViewDHGR - A simple Apple II graphics viewer

Back to article view | Back to comp.sys.apple2.programmer

Contents

  QuickViewDHGR - A simple Apple II graphics viewer markpmlim@yahoo.com.sg - 2018-03-18 23:34 -0700
    Re: QuickViewDHGR - A simple Apple II graphics viewer gids.rs@sasktel.net - 2018-03-19 13:59 -0700
      Re: QuickViewDHGR - A simple Apple II graphics viewer markpmlim@yahoo.com.sg - 2018-03-19 18:25 -0700
      Re: QuickViewDHGR - A simple Apple II graphics viewer "Bill Buckels" <bbuckels@mts.net> - 2018-03-20 02:12 -0500
        Re: QuickViewDHGR - A simple Apple II graphics viewer "Bill Buckels" <bbuckels@mts.net> - 2018-03-20 02:19 -0500
          Re: QuickViewDHGR - A simple Apple II graphics viewer James Davis <JPD.Enterprises@outlook.com> - 2018-03-20 11:55 -0700
        Re: QuickViewDHGR - A simple Apple II graphics viewer gids.rs@sasktel.net - 2018-03-20 09:59 -0700
          Re: QuickViewDHGR - A simple Apple II graphics viewer markpmlim@yahoo.com.sg - 2018-03-20 18:21 -0700
            Re: QuickViewDHGR - A simple Apple II graphics viewer markpmlim@yahoo.com.sg - 2018-04-17 00:15 -0700
              Re: QuickViewDHGR - A simple Apple II graphics viewer markpmlim@yahoo.com.sg - 2018-05-13 18:10 -0700
                Re: QuickViewDHGR - A simple Apple II graphics viewer markpmlim@yahoo.com.sg - 2018-09-24 04:22 -0700
      Re: QuickViewDHGR - A simple Apple II graphics viewer gids.rs@sasktel.net - 2018-03-20 09:04 -0700
        Re: QuickViewDHGR - A simple Apple II graphics viewer gids.rs@sasktel.net - 2018-03-20 20:53 -0700
      Re: QuickViewDHGR - A simple Apple II graphics viewer gids.rs@sasktel.net - 2018-03-20 09:31 -0700
        Re: QuickViewDHGR - A simple Apple II graphics viewer markpmlim@yahoo.com.sg - 2018-03-20 14:35 -0700
    Re: QuickViewDHGR - A simple Apple II graphics viewer "Bill Buckels" <bbuckels@mts.net> - 2018-03-20 01:01 -0500
    Re: QuickViewDHGR - A simple Apple II graphics viewer "Bill Buckels" <bbuckels@mts.net> - 2018-03-21 04:23 -0500

#4381 — QuickViewDHGR - A simple Apple II graphics viewer

Hi,

QuickViewDHGR is a simple utility for viewing Apple II Standard HiRes and Double Hires graphics. Its deployment target is Mac OS X 10.5 or later.

The application has a single display window which has a tab view to present the graphic as a colored and a monochrome image at 280x192 resolution.

http://macgui.com/gallery/showphoto.php?pic_id=4861


The window can be resized to show the Apple II graphic at 560x384 resolution with a click on the check box.

http://macgui.com/gallery/showphoto.php?pic_id=4862

The application has 2 embedded plugins; the QuickLook plugin is used to preview the graphic and to generate a thumbnail for it. This plugin peeks at file offset +120 to decide whether to present the preview (or thumbnail) as a colored or monochrome graphic. (Ref: FTN $08/$0000-$3FFF.)


http://macgui.com/gallery/showphoto.php?pic_id=4863
http://macgui.com/gallery/showphoto.php?pic_id=4864


The Spotlight plugin is limited to a search for the image size.

Currently, the following ProDOS file formats are supported: 
a) plain BIN files (~8 192 and ~16 384 bytes)
b) plain FOT files (auxiliary types $0000-$3FFF)
c) compressed FOT files (auxiliary types $4000 and $4001)

QuickViewDHGR will accept plain files (no FinderInfo metadata) whose lengths are approximately 8 192 and 16 384 bytes.

Note: there is no guarantee that the application will produce a recognizable image if the input file is not an Apple II graphic in the first place or the file is corrupt.

Acknowledgements:
Bill Buckel for making available his BMP2DHR project; the Apple II double-hires graphics produced by his utility were used during program testing.

Robert Giddings for all the resources provided and beta-testing QuickViewDHGR.

Regards.

Mark

[toc] | [next] | [standalone]

#4384

On Monday, March 19, 2018 at 12:34:51 AM UTC-6, mark...@yahoo.com.sg wrote:
> Hi,
> 
> QuickViewDHGR is a simple utility for viewing Apple II Standard HiRes and Double Hires graphics. Its deployment target is Mac OS X 10.5 or later.
> 
> The application has a single display window which has a tab view to present the graphic as a colored and a monochrome image at 280x192 resolution.
> 
> http://macgui.com/gallery/showphoto.php?pic_id=4861
> 
> 
> The window can be resized to show the Apple II graphic at 560x384 resolution with a click on the check box.
> 
> http://macgui.com/gallery/showphoto.php?pic_id=4862
> 
> The application has 2 embedded plugins; the QuickLook plugin is used to preview the graphic and to generate a thumbnail for it. This plugin peeks at file offset +120 to decide whether to present the preview (or thumbnail) as a colored or monochrome graphic. (Ref: FTN $08/$0000-$3FFF.)
> 
> 
> http://macgui.com/gallery/showphoto.php?pic_id=4863
> http://macgui.com/gallery/showphoto.php?pic_id=4864
> 
> 
> The Spotlight plugin is limited to a search for the image size.
> 
> Currently, the following ProDOS file formats are supported: 
> a) plain BIN files (~8 192 and ~16 384 bytes)
> b) plain FOT files (auxiliary types $0000-$3FFF)
> c) compressed FOT files (auxiliary types $4000 and $4001)
> 
> QuickViewDHGR will accept plain files (no FinderInfo metadata) whose lengths are approximately 8 192 and 16 384 bytes.
> 
> Note: there is no guarantee that the application will produce a recognizable image if the input file is not an Apple II graphic in the first place or the file is corrupt.
> 
> Acknowledgements:
> Bill Buckel for making available his BMP2DHR project; the Apple II double-hires graphics produced by his utility were used during program testing.
> 
> Robert Giddings for all the resources provided and beta-testing QuickViewDHGR.
> 
> Regards.
> 
> Mark


Thanks to Mark for making a couple of excellent utilities available for viewing graphics and disk images on the Mac.  Mac computers had been falling behind with emulation support utilities until now.

My 2 cents worth regarding File Type $08

I have a few big disagreements with Apple's technote FTN$0008.

First it uses a screen hole in graphics memory.  No other File type does, so why start now?

Second, there is more than enough graphics identifiers to handle all screens of text or graphics for a II+/IIe/IIc. (a file type is already reserved for the IIGS)

Third, Apple reserved the Aux type of $4000 and $4001 for Packbytes compressed hi-res and dbl hi-res screens that are created with a IIGS tool call and which can only be decompressed on a IIGS as there are no Packbytes decompressors for the II+/IIe/IIc and with the advent of LZ4 (as well as other compression schemes), which has a way higher compression ratio and way faster decompression speed, it no longer makes sense.

Fourth, Apple no longer supports us

Fifth, it will be easier to implement and identify screens and not necessary to load the file first to load a byte from a screen hole


A filetype of $08 can be used in conjunction with the Aux type to indicate all modes of screens that can be created on the Apple II.

I am asking the the Apple II community to adopt the file type of $08 with the following Aux values.



Hi-byte - only one bit can be turned on at a time 

bit #7 ($80) - on = SHR graphics - mostly for Carte Blanche cards on a IIe
       - or can be considered reserved
       - or reserved for Fadden's file type and other specialty file types 
bit #6 ($40) - on = Dbl hi-res - with this bit on would get $40xx 
bit #5 ($20) = on = Hi-res - would get $20xx 
bit #4 ($10) = on = Dbl lo-res - would get $10xx 
bit #3 ($08) = on = lo-res - would get $08xx 
bit #2 ($04) = on = 80-col text screen 
bit #1 ($02) = on = 40-col text screen 
bit #0 ($01) = on = Data block


Lo-byte - identifiers for following compression types


$00 = uncompressed B/W (hi-byte $20,40,80)
$01 = uncompressed color (hi-byte $08,$10,$20,40,80)

$00 = Normal Text Screen RLE (Hi byte is 1, 2 or 4) 
$01 = Mouse Text screen RLE (Hi byte is 1, 2 or 4) 
$02 = Text file compression using Prodos method (Hi byte is 1, 2 or 4) 
$03 = Text file compression using dictionary libraries (Hi byte is 1, 2 or 4)

$66 = fhpack (with hi byte set to $80) 

* Mainly related to Hi-res compression 
$80 = RLE 
$81 = Axe Packer 
$82 = Beagle Scrunch 

* Mainly related to Dbl hi-res compression 
$90 = Beagle Dbl Scrunch 
$91 = Pic Pac Dbl Res

* Mainly related to Super Hi-res Compression used when a Carte Blanche card is installed in a IIe

$C0 = Apple Packbytes  (Hi byte $20 for hi-res $40 for dhr, $80 for super hi-res) 
$C1 = Paintworks 
$C2 = Apple Preferred 
$C3 = Dream Graphics 

* Mainly related to Non platform specific compression 


$E0 = LZ4 
$E1 = LZW
$E2 = LZSS
$E3 = LZ? reserved
$E4 = LZ? reserved
$E5 = Huffman 

* Specialty
$F0 = Zip   
$F1 = gzip 
$F2 = 7z 
$F3 = Exocrunch




Included here is my file type and Aux type changer to batch change all binary files to $08 and Aux type calculated by using the above chart.

To calculate the Aux value, get the hi-byte first beside the type of screen it is.  i.e. dbl hi-res has $40.  Then get the lo byte value $00 for uncompressed b/w or $01 for uncompressed color or one of the compression bytes.  Put the two together to get a 16-bit value.  In this case $4000 would be an uncompressed b/w dbl hi-res image.  Enter the decimal value for AX in line #6:  $4000 = 16384

Next do a CATALOG and put the last 5 digits of the ENDFILE in L$ in line #5.  And last, change line #6 to the decimal values for the file type and decimal value for the Aux type for each file to be changed to.  And RUN the program.

This will batch change all binary files with a file length of $4000 (16384) over to the $08 file type and an Aux value of $4000 to indicate an uncompressed b/w dbl hi-res image.

  5 FT$ = "BIN":L$ = "04000": REM change files from File Type and with ENDFILE value
  6 FT = 8:AX = 16384: REM change files to the File Type and to the value from the chart above
 10 D$ =  CHR$ (4)
 15  IF  PEEK (897) <  > 128 THEN  PRINT D$"- FT.AUX"
 30  ONERR  GOTO 70
 35  PRINT D$"PREFIX": INPUT V$
 40  PRINT D$"OPEN"V$",TDIR": PRINT D$"READ"V$
 45  INPUT A$: INPUT A$: INPUT A$
 50  FOR X = 0 TO 1: INPUT A$
 55 F$ = MID$(A$,1,15) : FOR I = 1 TO 15: IF MID$(F$,I,1) = " " THEN F$ = LEFT$(F$,I-1): I = 15
 57 NEXT
 60 IF MID$(A$,18,3) <> FT$ OR MID$(A$,67,5) <> L$ THEN X=0: NEXT
 60  & F$,FT,AX :N = N + 1:X = 0: NEXT
 65  POKE 216,0: PRINT D$"CLOSE"N$
 70 PRINT N-1 " files processed"
SAVE FT.CHANGER

CALL-151
0300:A9 4C 8D F5 03 A9 10 8D F6 03 A9 03 8D F7 03 60
0310:20 74 03 20 B7 00 C9 2C D0 03 20 BE DE 20 7B DD
0320:20 FD E5 C9 00 F0 04 C9 40 90 05 A2 B0 4C 12 D4
0330:A8 8C 80 02 88 B1 5E 99 81 02 88 10 F8 20 00 BF
0340:C4 80 03 B0 2C 20 4C E7 8A A0 04 99 80 03 A9 07
0350:8D 80 03 20 BE DE 20 67 DD 20 52 E7 A0 05 A5 50
0360:99 80 03 A5 51 99 81 03 20 00 BF C3 80 03 B0 01
0370:60 4C D0 03 A9 0A 8D 80 03 4C 06 E3 00 00 00 00
0380:0A 80 02 00 00 00 00 00 00 00 00 00 00 00 00 00
0390:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3D0G
BSAVE FT.AUX,A$300,L$A0


Enjoy!

[toc] | [prev] | [next] | [standalone]

#4386

On Tuesday, March 20, 2018 at 4:59:07 AM UTC+8, gid...@sasktel.net wrote:
> On Monday, March 19, 2018 at 12:34:51 AM UTC-6, mark...@yahoo.com.sg wrote:
> > Hi,
> > 
> > QuickViewDHGR is a simple utility for viewing Apple II Standard HiRes and Double Hires graphics. Its deployment target is Mac OS X 10.5 or later.
> > 
> > The application has a single display window which has a tab view to present the graphic as a colored and a monochrome image at 280x192 resolution.
> > 
> > http://macgui.com/gallery/showphoto.php?pic_id=4861
> > 
> > 
> > The window can be resized to show the Apple II graphic at 560x384 resolution with a click on the check box.
> > 
> > http://macgui.com/gallery/showphoto.php?pic_id=4862
> > 
> > The application has 2 embedded plugins; the QuickLook plugin is used to preview the graphic and to generate a thumbnail for it. This plugin peeks at file offset +120 to decide whether to present the preview (or thumbnail) as a colored or monochrome graphic. (Ref: FTN $08/$0000-$3FFF.)
> > 
> > 
> > http://macgui.com/gallery/showphoto.php?pic_id=4863
> > http://macgui.com/gallery/showphoto.php?pic_id=4864
> > 
> > 
> > The Spotlight plugin is limited to a search for the image size.
> > 
> > Currently, the following ProDOS file formats are supported: 
> > a) plain BIN files (~8 192 and ~16 384 bytes)
> > b) plain FOT files (auxiliary types $0000-$3FFF)
> > c) compressed FOT files (auxiliary types $4000 and $4001)
> > 
> > QuickViewDHGR will accept plain files (no FinderInfo metadata) whose lengths are approximately 8 192 and 16 384 bytes.
> > 
> > Note: there is no guarantee that the application will produce a recognizable image if the input file is not an Apple II graphic in the first place or the file is corrupt.
> > 
> > Acknowledgements:
> > Bill Buckel for making available his BMP2DHR project; the Apple II double-hires graphics produced by his utility were used during program testing.
> > 
> > Robert Giddings for all the resources provided and beta-testing QuickViewDHGR.
> > 
> > Regards.
> > 
> > Mark
> 
> 
> Thanks to Mark for making a couple of excellent utilities available for viewing graphics and disk images on the Mac.  Mac computers had been falling behind with emulation support utilities until now.
> 
> My 2 cents worth regarding File Type $08
> 
> I have a few big disagreements with Apple's technote FTN$0008.
> 
> First it uses a screen hole in graphics memory.  No other File type does, so why start now?
> 
> Second, there is more than enough graphics identifiers to handle all screens of text or graphics for a II+/IIe/IIc. (a file type is already reserved for the IIGS)
> 
> Third, Apple reserved the Aux type of $4000 and $4001 for Packbytes compressed hi-res and dbl hi-res screens that are created with a IIGS tool call and which can only be decompressed on a IIGS as there are no Packbytes decompressors for the II+/IIe/IIc and with the advent of LZ4 (as well as other compression schemes), which has a way higher compression ratio and way faster decompression speed, it no longer makes sense.
> 
> Fourth, Apple no longer supports us
> 
> Fifth, it will be easier to implement and identify screens and not necessary to load the file first to load a byte from a screen hole
> 
> 
> A filetype of $08 can be used in conjunction with the Aux type to indicate all modes of screens that can be created on the Apple II.
> 
> I am asking the the Apple II community to adopt the file type of $08 with the following Aux values.
> 
> 
> 
> Hi-byte - only one bit can be turned on at a time 
> 
> bit #7 ($80) - on = SHR graphics - mostly for Carte Blanche cards on a IIe
>        - or can be considered reserved
>        - or reserved for Fadden's file type and other specialty file types 
> bit #6 ($40) - on = Dbl hi-res - with this bit on would get $40xx 
> bit #5 ($20) = on = Hi-res - would get $20xx 
> bit #4 ($10) = on = Dbl lo-res - would get $10xx 
> bit #3 ($08) = on = lo-res - would get $08xx 
> bit #2 ($04) = on = 80-col text screen 
> bit #1 ($02) = on = 40-col text screen 
> bit #0 ($01) = on = Data block
> 
> 
> Lo-byte - identifiers for following compression types
> 
> 
> $00 = uncompressed B/W (hi-byte $20,40,80)
> $01 = uncompressed color (hi-byte $08,$10,$20,40,80)
> 
> $00 = Normal Text Screen RLE (Hi byte is 1, 2 or 4) 
> $01 = Mouse Text screen RLE (Hi byte is 1, 2 or 4) 
> $02 = Text file compression using Prodos method (Hi byte is 1, 2 or 4) 
> $03 = Text file compression using dictionary libraries (Hi byte is 1, 2 or 4)
> 
> $66 = fhpack (with hi byte set to $80) 
> 
> * Mainly related to Hi-res compression 
> $80 = RLE 
> $81 = Axe Packer 
> $82 = Beagle Scrunch 
> 
> * Mainly related to Dbl hi-res compression 
> $90 = Beagle Dbl Scrunch 
> $91 = Pic Pac Dbl Res
> 
> * Mainly related to Super Hi-res Compression used when a Carte Blanche card is installed in a IIe
> 
> $C0 = Apple Packbytes  (Hi byte $20 for hi-res $40 for dhr, $80 for super hi-res) 
> $C1 = Paintworks 
> $C2 = Apple Preferred 
> $C3 = Dream Graphics 
> 
> * Mainly related to Non platform specific compression 
> 
> 
> $E0 = LZ4 
> $E1 = LZW
> $E2 = LZSS
> $E3 = LZ? reserved
> $E4 = LZ? reserved
> $E5 = Huffman 
> 
> * Specialty
> $F0 = Zip   
> $F1 = gzip 
> $F2 = 7z 
> $F3 = Exocrunch
> 
> 
> 
> 
> Included here is my file type and Aux type changer to batch change all binary files to $08 and Aux type calculated by using the above chart.
> 
> To calculate the Aux value, get the hi-byte first beside the type of screen it is.  i.e. dbl hi-res has $40.  Then get the lo byte value $00 for uncompressed b/w or $01 for uncompressed color or one of the compression bytes.  Put the two together to get a 16-bit value.  In this case $4000 would be an uncompressed b/w dbl hi-res image.  Enter the decimal value for AX in line #6:  $4000 = 16384
> 
> Next do a CATALOG and put the last 5 digits of the ENDFILE in L$ in line #5.  And last, change line #6 to the decimal values for the file type and decimal value for the Aux type for each file to be changed to.  And RUN the program.
> 
> This will batch change all binary files with a file length of $4000 (16384) over to the $08 file type and an Aux value of $4000 to indicate an uncompressed b/w dbl hi-res image.
> 
>   5 FT$ = "BIN":L$ = "04000": REM change files from File Type and with ENDFILE value
>   6 FT = 8:AX = 16384: REM change files to the File Type and to the value from the chart above
>  10 D$ =  CHR$ (4)
>  15  IF  PEEK (897) <  > 128 THEN  PRINT D$"- FT.AUX"
>  30  ONERR  GOTO 70
>  35  PRINT D$"PREFIX": INPUT V$
>  40  PRINT D$"OPEN"V$",TDIR": PRINT D$"READ"V$
>  45  INPUT A$: INPUT A$: INPUT A$
>  50  FOR X = 0 TO 1: INPUT A$
>  55 F$ = MID$(A$,1,15) : FOR I = 1 TO 15: IF MID$(F$,I,1) = " " THEN F$ = LEFT$(F$,I-1): I = 15
>  57 NEXT
>  60 IF MID$(A$,18,3) <> FT$ OR MID$(A$,67,5) <> L$ THEN X=0: NEXT
>  60  & F$,FT,AX :N = N + 1:X = 0: NEXT
>  65  POKE 216,0: PRINT D$"CLOSE"N$
>  70 PRINT N-1 " files processed"
> SAVE FT.CHANGER
> 
> CALL-151
> 0300:A9 4C 8D F5 03 A9 10 8D F6 03 A9 03 8D F7 03 60
> 0310:20 74 03 20 B7 00 C9 2C D0 03 20 BE DE 20 7B DD
> 0320:20 FD E5 C9 00 F0 04 C9 40 90 05 A2 B0 4C 12 D4
> 0330:A8 8C 80 02 88 B1 5E 99 81 02 88 10 F8 20 00 BF
> 0340:C4 80 03 B0 2C 20 4C E7 8A A0 04 99 80 03 A9 07
> 0350:8D 80 03 20 BE DE 20 67 DD 20 52 E7 A0 05 A5 50
> 0360:99 80 03 A5 51 99 81 03 20 00 BF C3 80 03 B0 01
> 0370:60 4C D0 03 A9 0A 8D 80 03 4C 06 E3 00 00 00 00
> 0380:0A 80 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0390:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 3D0G
> BSAVE FT.AUX,A$300,L$A0
> 
> 
> Enjoy!


> Fifth, it will be easier to implement and identify screens...
Having a specific identifier will be a great help. For example, while working on QuickViewSHR, to identify $C0/$0001 files, I had to unpack the file contents, check its size is exactly 32 768 bytes before proceeding to create a bitmap which is used to instantiate a Mac OS X graphic.

On the other hand, the utility can identify $C0/$0002 (Apple Preferred Format) and $C0/$8005 (Dream Grafix) files quickly by checking their markers.

> Included here is my file type and Aux type changer to batch change...
Implementing a batch changing feature in QuickViewDHGR should be straightforward.


Finally, thanks to David Finnagan for making his website www.macgui.com available for the posting of the screenshots of QuickViewDHGR. In fact, without his support and suggestions over the years, NuShrinkItX and QuickViewSHR would not have attained their present status.

Mark

[toc] | [prev] | [next] | [standalone]

#4391

<gids.rs@sasktel.net> wrote:

>there are no Packbytes decompressors for the II+/IIe/IIc

If that were even true, how do you explain this code then... (written in 
Aztec C65 for the Apple II) see below...

( distributed with http://www.aztecmuseum.ca/extras/B2S.zip see the 
following thread
https://groups.google.com/forum/#!topic/comp.sys.apple2.programmer/JJ3blfdKBCI )

It is perfectly trivial to compile this in either cc65 or in Aztec C65 for 
the II+/IIe/IIc... taken from the source code for pntlode.c...


/* the following is a modified version of Andy McFadden's UnpackBytes from
   CiderPress's SHR image viewer.

   CiderPress is written in C++ for Win32 so obviously this has been
   back-ported and changed somewhat to work in an 8 bit Aztec C program but
   the algorithm is the same and so is the control structure...

   Since Andy is an expert in these matters there is no point in reinventing
   the wheel. The Ciderpress SHR code is well commented and when combined
   with Apple's technical notes provides a very rich environmnent to learn
   all about working with these images. Thank you Andy for taking the time
   to pass-on this knowledge.

   */


/*
 * Unpack the Apple PackBytes format.
 *
 * Format is:
 * <flag><data> ...
 *
 * Flag values (first 6 bits of flag byte):
 * 00xxxxxx: (0-63) 1 to 64 bytes follow, all different
 * 01xxxxxx: (0-63) 1 to 64 repeats of next byte
 * 10xxxxxx: (0-63) 1 to 64 repeats of next 4 bytes
 * 11xxxxxx: (0-63) 1 to 64 repeats of next byte taken as 4 bytes
 *    (as in 10xxxxxx case)
 *
 * Pass the open file handle in "fh", expected packed source
 * length in "srcLen", and expected unpacked output size in "destRem".
 *
 * Returns 0 on success, nonzero if the buffer is overfilled or underfilled.
 */

/* read video data in 7680 byte chunks */
#define BLOCK_SIZE 7680


int UnpackBytes(fh, destRem,srcLen)
int fh;
unsigned destRem,srcLen;
{

 unsigned dest;
 unsigned char ch, *auxbuf,*buf;
 int i, flag, count, bytes, status = 0;

    /* use hi-res screen2 as a buffer area */
    buf = (unsigned char *)0x4000;
    auxbuf = (unsigned char *)0x5E00;

    /* make sure we can at least read the file...
       I am only trying for 256 bytes for now. */
 if (read(fh,buf,BLOCK_SIZE) < 256) return -1;
 bytes = 0;

 /* set destination to scanline 0 in auxiliary memory area */
 dest = 0x2000;

 while (srcLen > 0) {

  ch = buf[bytes]; bytes++;
  if (bytes == BLOCK_SIZE) {
   read(fh,buf,BLOCK_SIZE);
   bytes = 0;
  }

        flag = (0xc0 & ch);
        count = (0x3f & ch) +1;
  srcLen--;

  if (flag == 0x00) {
   /* 1 to 64 bytes follow, all different */
   for (i = 0; i < count; i++) {
    if (srcLen < 1 || destRem < 1) {
     status = -2; break;
    }
    auxbuf[i] = buf[bytes]; bytes++;
    if (bytes == BLOCK_SIZE) {
     read(fh,buf,BLOCK_SIZE);
     bytes = 0;
    }
    srcLen--;
    destRem--;
   }


   if (i!=0){
    maintoaux(0x5e00,0x5dff+i,dest); dest+=i;
   }
            if (status != 0) return status;
   }
   else if (flag == 0x40) {
   /* 1 to 64 repeats of next byte */
   if (srcLen < 1) return -3;
   ch = buf[bytes]; bytes++;
   if (bytes == BLOCK_SIZE) {
    read(fh,buf,BLOCK_SIZE);
    bytes = 0;
   }
   srcLen--;
   for (i = 0; i < count; i++) {
    if (destRem < 1) {
     status = -3; break;
    }
    auxbuf[i] = ch;
    destRem--;

   }
   if (i!=0){
    maintoaux(0x5e00,0x5dff+i,dest); dest+=i;
   }
            if (status != 0) return status;
  }
  else if (flag == 0x80) {

      /* 1 to 64 repeats of next 4 bytes */
   if (srcLen < 4 || destRem < 4) return -4;
   srcLen -= 4;
            for (i = 0; i < 4; i++) {
    auxbuf[i] = buf[bytes]; bytes++;
    if (bytes == BLOCK_SIZE) {
     read(fh,buf,BLOCK_SIZE);
     bytes = 0;
    }
   }

   for (i = 0; i < count; i++) {
    if (destRem < 4) return -4;
    destRem -= 4;
    maintoaux(0x5e00,0x5e03,dest); dest+=4;
   }
  }
  else {


   /* flag == 0xc0)
      1 to 64 repeats of next byte taken as 4 bytes */

   if (srcLen < 1 || destRem < 4) return -5;

   for (i = 0; i < 4; i++) auxbuf[i] = buf[bytes];

   for (i = 0; i < count; i++) {
    if (destRem < 4) return -5;
    destRem -= 4;
    maintoaux(0x5e00,0x5e03,dest); dest+=4;
   }

   bytes++;
   if (bytes == BLOCK_SIZE) {
    read(fh,buf,BLOCK_SIZE);
    bytes = 0;
   }
   srcLen--;
  }


 }

 /* require that we completely fill the buffer */
 if (destRem > 0) status = -6;

 return status;
}



and with the advent of LZ4 (as well as other compression schemes), which has 
a way higher compression ratio and way faster decompression speed, it no 
longer makes sense.

Fourth, Apple no longer supports us

Fifth, it will be easier to implement and identify screens and not necessary 
to load the file first to load a byte from a screen hole


A filetype of $08 can be used in conjunction with the Aux type to indicate 
all modes of screens that can be created on the Apple II.

I am asking the the Apple II community to adopt the file type of $08 with 
the following Aux values.



Hi-byte - only one bit can be turned on at a time

bit #7 ($80) - on = SHR graphics - mostly for Carte Blanche cards on a IIe
       - or can be considered reserved
       - or reserved for Fadden's file type and other specialty file types
bit #6 ($40) - on = Dbl hi-res - with this bit on would get $40xx
bit #5 ($20) = on = Hi-res - would get $20xx
bit #4 ($10) = on = Dbl lo-res - would get $10xx
bit #3 ($08) = on = lo-res - would get $08xx
bit #2 ($04) = on = 80-col text screen
bit #1 ($02) = on = 40-col text screen
bit #0 ($01) = on = Data block


Lo-byte - identifiers for following compression types


$00 = uncompressed B/W (hi-byte $20,40,80)
$01 = uncompressed color (hi-byte $08,$10,$20,40,80)

$00 = Normal Text Screen RLE (Hi byte is 1, 2 or 4)
$01 = Mouse Text screen RLE (Hi byte is 1, 2 or 4)
$02 = Text file compression using Prodos method (Hi byte is 1, 2 or 4)
$03 = Text file compression using dictionary libraries (Hi byte is 1, 2 or 
4)

$66 = fhpack (with hi byte set to $80)

* Mainly related to Hi-res compression
$80 = RLE
$81 = Axe Packer
$82 = Beagle Scrunch

* Mainly related to Dbl hi-res compression
$90 = Beagle Dbl Scrunch
$91 = Pic Pac Dbl Res

* Mainly related to Super Hi-res Compression used when a Carte Blanche card 
is installed in a IIe

$C0 = Apple Packbytes  (Hi byte $20 for hi-res $40 for dhr, $80 for super 
hi-res)
$C1 = Paintworks
$C2 = Apple Preferred
$C3 = Dream Graphics

* Mainly related to Non platform specific compression


$E0 = LZ4
$E1 = LZW
$E2 = LZSS
$E3 = LZ? reserved
$E4 = LZ? reserved
$E5 = Huffman

* Specialty
$F0 = Zip
$F1 = gzip
$F2 = 7z
$F3 = Exocrunch




Included here is my file type and Aux type changer to batch change all 
binary files to $08 and Aux type calculated by using the above chart.

To calculate the Aux value, get the hi-byte first beside the type of screen 
it is.  i.e. dbl hi-res has $40.  Then get the lo byte value $00 for 
uncompressed b/w or $01 for uncompressed color or one of the compression 
bytes.  Put the two together to get a 16-bit value.  In this case $4000 
would be an uncompressed b/w dbl hi-res image.  Enter the decimal value for 
AX in line #6:  $4000 = 16384

Next do a CATALOG and put the last 5 digits of the ENDFILE in L$ in line #5. 
And last, change line #6 to the decimal values for the file type and decimal 
value for the Aux type for each file to be changed to.  And RUN the program.

This will batch change all binary files with a file length of $4000 (16384) 
over to the $08 file type and an Aux value of $4000 to indicate an 
uncompressed b/w dbl hi-res image.

  5 FT$ = "BIN":L$ = "04000": REM change files from File Type and with 
ENDFILE value
  6 FT = 8:AX = 16384: REM change files to the File Type and to the value 
from the chart above
 10 D$ =  CHR$ (4)
 15  IF  PEEK (897) <  > 128 THEN  PRINT D$"- FT.AUX"
 30  ONERR  GOTO 70
 35  PRINT D$"PREFIX": INPUT V$
 40  PRINT D$"OPEN"V$",TDIR": PRINT D$"READ"V$
 45  INPUT A$: INPUT A$: INPUT A$
 50  FOR X = 0 TO 1: INPUT A$
 55 F$ = MID$(A$,1,15) : FOR I = 1 TO 15: IF MID$(F$,I,1) = " " THEN F$ = 
LEFT$(F$,I-1): I = 15
 57 NEXT
 60 IF MID$(A$,18,3) <> FT$ OR MID$(A$,67,5) <> L$ THEN X=0: NEXT
 60  & F$,FT,AX :N = N + 1:X = 0: NEXT
 65  POKE 216,0: PRINT D$"CLOSE"N$
 70 PRINT N-1 " files processed"
SAVE FT.CHANGER

CALL-151
0300:A9 4C 8D F5 03 A9 10 8D F6 03 A9 03 8D F7 03 60
0310:20 74 03 20 B7 00 C9 2C D0 03 20 BE DE 20 7B DD
0320:20 FD E5 C9 00 F0 04 C9 40 90 05 A2 B0 4C 12 D4
0330:A8 8C 80 02 88 B1 5E 99 81 02 88 10 F8 20 00 BF
0340:C4 80 03 B0 2C 20 4C E7 8A A0 04 99 80 03 A9 07
0350:8D 80 03 20 BE DE 20 67 DD 20 52 E7 A0 05 A5 50
0360:99 80 03 A5 51 99 81 03 20 00 BF C3 80 03 B0 01
0370:60 4C D0 03 A9 0A 8D 80 03 4C 06 E3 00 00 00 00
0380:0A 80 02 00 00 00 00 00 00 00 00 00 00 00 00 00
0390:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3D0G
BSAVE FT.AUX,A$300,L$A0


Enjoy! 

[toc] | [prev] | [next] | [standalone]

#4393

"Bill Buckels" <bbuckels@mts.net> wrote:
<snip>

A bunch of extra stuff because of the horrendous amount of topquoting that 
gets done in googlegroups but never disgraced usenet, I forgot to delete the 
other extraneous pap from my news reader before posting. But when google 
users republish the bible without shame or restraint every post stuff 
happens...

Bill 

[toc] | [prev] | [next] | [standalone]

#4397

On Tuesday, March 20, 2018 at 12:19:16 AM UTC-7, Bill Buckels wrote:
> "Bill Buckels" <bb...@mts.net> wrote:
> <snip>
> 
> A bunch of extra stuff because of the horrendous amount of topquoting that 
> gets done in googlegroups but never disgraced usenet, I forgot to delete the 
> other extraneous pap from my news reader before posting. But when google 
> users republish the bible without shame or restraint every post stuff 
> happens...
> 
> Bill

Yes, google makes it easy to forget news-group protocol and develop bad habits.  :-(

[toc] | [prev] | [next] | [standalone]

#4396

> >there are no Packbytes decompressors for the II+/IIe/IIc
> 
> If that were even true, how do you explain this code then... (written in 
> Aztec C65 for the Apple II) see below...
> 
> ( distributed with http://www.aztecmuseum.ca/extras/B2S.zip see the 
> following thread
> https://groups.google.com/forum/#!topic/comp.sys.apple2.programmer/JJ3blfdKBCI )


Thanks for the link Bill.  I don't believe this was available at the time Apple wrote the standard for FTN$0008.

And so much more has happened since then.

And I will be more than happy to add this decompressor to the universal graphics viewer I will eventually work on.  I will eventually get around to your Huffman one as well.

Good to see you back after your hiatus.

[toc] | [prev] | [next] | [standalone]

#4400

On Wednesday, March 21, 2018 at 12:59:15 AM UTC+8, gid...@sasktel.net wrote:
> > >there are no Packbytes decompressors for the II+/IIe/IIc
> > 
> > If that were even true, how do you explain this code then... (written in 
> > Aztec C65 for the Apple II) see below...
> > 
> > ( distributed with http://www.aztecmuseum.ca/extras/B2S.zip see the 
> > following thread
> > https://groups.google.com/forum/#!topic/comp.sys.apple2.programmer/JJ3blfdKBCI )
> 
> 
> Thanks for the link Bill.  I don't believe this was available at the time Apple wrote the standard for FTN$0008.

Looking thru FTN.ABOUT.92.06, it is apparent there is no separate File Type category for files which are compressed.

Apple II graphic files packed with the Apple IIGS PackBytes function are listed under the FOT($08) category. Apple IIGS graphic files that are packed are grouped under PNT($C0). If we were to follow this unwritten rule, a LZ4 compressed file for Apple II graphic files will have to be $08/$xxxx and Super-Hires $C0/$xxxx. Perhaps that's why Andy Fadden sets the ProDOS file/aux pair of his LZ4-derived file format as FOT/$8066.

There is, of course, merit in Robert's proposal. We don't have to put forward another pair of ProDOS file/aux types if someone writes an Apple II graphic viewer or editor that loads HiRes/Double Hires files compressed with LZW.

Since Apple no longer supports the Apple II and there is no body responsible for assigning ProDOS file and auxiliary types to Apple II files, one utility might end up using ProDOS file/aux types that are also used by another program.

As an example, QuickViewSHR is using $C0/$0004 for the 3201 format. This format consist of 2 sub-formats with a 4-byte header with the identifiers either embedded as CE D2 CC 00 or C1 D0 D0 00. If I am not mistakened, this ProDOS file/aux type pair is also in use by another utility.

Changing the ProDOS file/aux type pair of the 3201 is easy; QuickViewSHR has an option to batch change files of this format to $C0/$0004. 


Mark

[toc] | [prev] | [next] | [standalone]

#4510

Hi,

QuickViewDHGR had been updated to view Apple II HiRes Graphics compressed with Andy Fadden's LZ4FH algorithm.

A simple slideshow had also been added.

I have almost completed yet another simple utility (YASU) that compresses an Apple II HiRes/Double HiRes graphic using any of these 3 algorithms: LZ4, LZ4FH and PackBytes.

https://www.macgui.com/gallery/showphoto.php?pic_id=4893


System Requirements: Any machine running Mac OS X 10.5 or later.

Contact me if you are interested in trying out the program.

Regards.

[toc] | [prev] | [next] | [standalone]

#4541

Hi,

As mentioned in previous postings, the utility CompressIIX compresses/decompresses Apple II Graphics (HiRes and Double HiRes). The user has a choice of 3 codecs viz. LZ4, LZ4FH  and PackBytes.

The new utility LZ4CompressorX will compress and decompress files with support for the following:
(a) Apple LZ4 Frame format
(b) Legacy LZ4 block format
(c) Generic LZ4 Frame format

System requirements: Mac OS X 10.5.x or later.
Note: all compressions are done with the LZ4 block API.

https://www.macgui.com/gallery/showphoto.php?pic_id=4918


The Apple LZ4 Frame format is the output produced by Apple's Data Compression Library using its LZ4 algorithm when an uncompressed file is deflated.

The Legacy LZ4 block format consists of a single compressed block (after passing an uncompressed file through Yann Collet's library functions) with a 16-byte legacy header prepended. This option is recommended for Apple II/IIGS users since the decoders already written will have no problems with this format.

The Generic LZ4 Frame format is the output produced when an uncompressed file is deflated by the Yann Collet's frame library function.

Since the functions in Apple's Data Compression Library are only available in macOS 10.11 or later, I have to get Yann Collect's library functions to 

 i) compress files that will generate output that conforms to the Apple LZ4 Frame format, and,
ii) decompress files that will input LZ4 files with this format and output the inflated data.

In addition, the program has a QuickLook plugin:

https://www.macgui.com/gallery/showphoto.php?pic_id=4919


Resource forks are not supported.

Regards.

[toc] | [prev] | [next] | [standalone]

#4787

For those who have an Mac OS X computer running 10.9 or later, Swift Playgrounds can be used to aid program development.

Before QuickViewDHGR was developed, a Swift playground for viewing coloured Apple II Double Hires graphic files was actually written. As a matter of fact, the source of the instantiation of the CGImage object in QuickViewDGHR was ported over from the playground.

The source code for the playground is now available at:

https://github.com/markpmlim/AppleIIDHGRConverter

Please let me know if there are errors in the source code or in the description of the project.
 
Requirements: XCode 8.x

[toc] | [prev] | [next] | [standalone]

#4394

Oops.  Made a list minute correction and line numbers got out of whack.

change the line numbers from this

>  60  & F$,FT,AX :N = N + 1:X = 0: NEXT
>  65  POKE 216,0: PRINT D$"CLOSE"N$
>  70 PRINT N-1 " files processed"


to this

 65  & F$,FT,AX :N = N + 1:X = 0: NEXT
 70  POKE 216,0: PRINT D$"CLOSE"N$
 75 PRINT N-1 " files processed"

[toc] | [prev] | [next] | [standalone]

#4401

On Tuesday, March 20, 2018 at 10:04:19 AM UTC-6, gid...@sasktel.net wrote:
> Oops.  Made a list minute correction and line numbers got out of whack.
> 
> change the line numbers from this
> 
> >  60  & F$,FT,AX :N = N + 1:X = 0: NEXT
> >  65  POKE 216,0: PRINT D$"CLOSE"N$
> >  70 PRINT N-1 " files processed"
> 
> 
> to this
> 
>  65  & F$,FT,AX :N = N + 1:X = 0: NEXT
>  70  POKE 216,0: PRINT D$"CLOSE"N$
>  75 PRINT N-1 " files processed"


The worst part of posting these corrections is, I had them all fixed, and thought I had copied the fixed version to the clipboard to paste here.  Grrr!

One more fix.  Change the "1" to a "2" in line #55

55 F$ = MID$(A$,2,15) : FOR I = 1 TO 15: IF MID$(F$,I,1) = " " THEN F$ = LEFT$(F$,I-1): I = 15


And lastly, there is no extensive directory navigation, so graphics files have to be in the same directory as this utility, and don't forget to change lines #5 and #6 to the correct filetype and file length, or you will still get the -1 files processed error.

Thanks to all who have notified me of these errors.

[toc] | [prev] | [next] | [standalone]

#4395

> I am asking the the Apple II community to adopt the file type of $08 with the following Aux values.
> 
> 
> 
> Hi-byte - only one bit can be turned on at a time 
> 
> bit #7 ($80) - on = SHR graphics - mostly for Carte Blanche cards on a IIe
>        - or can be considered reserved
>        - or reserved for Fadden's file type and other specialty file types 
> bit #6 ($40) - on = Dbl hi-res - with this bit on would get $40xx 
> bit #5 ($20) = on = Hi-res - would get $20xx 
> bit #4 ($10) = on = Dbl lo-res - would get $10xx 
> bit #3 ($08) = on = lo-res - would get $08xx 
> bit #2 ($04) = on = 80-col text screen 
> bit #1 ($02) = on = 40-col text screen 
> bit #0 ($01) = on = Data block
> 
> 
> Lo-byte - identifiers for following compression types
> 
> 
> $00 = uncompressed B/W (hi-byte $20,40,80)
> $01 = uncompressed color (hi-byte $08,$10,$20,40,80)
> 
> $00 = Normal Text Screen RLE (Hi byte is 1, 2 or 4) 
> $01 = Mouse Text screen RLE (Hi byte is 1, 2 or 4) 
> $02 = Text file compression using Prodos method (Hi byte is 1, 2 or 4) 
> $03 = Text file compression using dictionary libraries (Hi byte is 1, 2 or 4)
> 
> $66 = fhpack (with hi byte set to $80) 
> 
> * Mainly related to Hi-res compression 
> $80 = RLE 
> $81 = Axe Packer 
> $82 = Beagle Scrunch 
> 
> * Mainly related to Dbl hi-res compression 
> $90 = Beagle Dbl Scrunch 
> $91 = Pic Pac Dbl Res
> 
> * Mainly related to Super Hi-res Compression used when a Carte Blanche card is installed in a IIe
> 
> $C0 = Apple Packbytes  (Hi byte $20 for hi-res $40 for dhr, $80 for super hi-res) 
> $C1 = Paintworks 
> $C2 = Apple Preferred 
> $C3 = Dream Graphics 
> 
> * Mainly related to Non platform specific compression 
> 
> 
> $E0 = LZ4 
> $E1 = LZW
> $E2 = LZSS
> $E3 = LZ? reserved
> $E4 = LZ? reserved
> $E5 = Huffman 
> 
> * Specialty
> $F0 = Zip   
> $F1 = gzip 
> $F2 = 7z 
> $F3 = Exocrunch
> 
>

I was asked how compressed files would differentiate between b/w and color, and I had not spent a lot of time contemplating on it.  At first I thought that compressed files should remain non-partial to a color mode for graphics, but then again since we are really on dealing with graphics, a b/w and color bit could be used at the same time.

Here is what I came up with to indicate b/w or color for compressed files.  Bit #0 is now used as the b/w or color indicator and compression types are now even numbers starting at 2.

The values then can be calculated for any screen, b/w or color, and any type of compression.  For lo-res screens, b/w would be ignored, and for text screens, color would be ignored.

a dbl hi-res screen in color, compressed to LZ4 would have a value - $40E3
a dbl hi-res screen in b/w, compressed to LZ4 would have a value - $40E2
an uncompressed screen in b/w - $4000
an uncompressed screen in color - $4001
hires b/w - $2000
hires color - $2001


$00 = B/W (hi-byte $20,40,80) 
$01 = color (hi-byte $08,$10,$20,40,80) 

$00 = Normal Text Screen RLE (Hi byte is 1, 2 or 4) 
$01 = Mouse Text screen RLE (Hi byte is 1, 2 or 4) 
$02 = Text file compression using Prodos method (Hi byte is 1, 2 or 4) 
$03 = Text file compression using dictionary libraries (Hi byte is 1, 2 or 4) 

$66 = fhpack (with hi byte set to $80) 

* Mainly related to Hi-res compression 
$82 = RLE 
$84 = Axe Packer 
$86 = Beagle Scrunch 

* Mainly related to Dbl hi-res compression 
$92 = Beagle Dbl Scrunch 
$94 = Pic Pac Dbl Res 

* Mainly related to Super Hi-res Compression used when a Carte Blanche card is installed in a IIe 

$C2 = Apple Packbytes  (Hi byte $20 for hi-res $40 for dhr, $80 for super hi-res) 
$C4 = Paintworks 
$C6 = Apple Preferred 
$C8 = Dream Graphics 

* Mainly related to Non platform specific compression 


$E2 = LZ4 
$E4 = LZW 
$E6 = LZSS 
$E8 = LZ? reserved 
$EA = LZ? reserved 
$EC = Huffman 

* Specialty 
$F2 = Zip   
$F4 = gzip 
$F6 = 7z 
$F8 = Exocrunch 

[toc] | [prev] | [next] | [standalone]

#4398

> Here is what I came up with to indicate b/w or color for compressed files.  Bit #0 is now used as the b/w or color indicator and compression types are now even numbers starting at 2.

Having Bit #0 as the graphic mode indicator will be helpful for QuickViewDHGR's plugin. At least I can skipping having to check file offset 120 for values 0 - 7.

There are some monochrome graphics which looks good.

http://www.macgui.com/gallery/showphoto.php?pic_id=4865

Once again, courtesy of Bill.

I have just added an LZ4 decoder to QuickViewDHGR's. The 16-byte header is compatible to those used across many computer platforms including the AppleIIGS. 

https://www.brutaldeluxe.fr/products/crossdevtools/lz4/index.html

bytes 0-3 - 03 21 4C 18 
bytes 4-7 - original file size little endian
bytes 8-11 ignore; unknown
bytes 12-15 compressed data size little endian

I wonder if we could use bytes 8-11 as e.g. an identifier. QuickViewDHGR accepts drops of foreign files i.e. those without the ProDOS file/auxillary pair embedded within a Mac OS X FinderInfo metadata attachment to the file. Or can we use a 4-byte trailer like Apple's LZ4 format?

Then there is the case for assigning a ProDOS file/auxillary pair to Apple II LZ4 compressed files.

Mark

[toc] | [prev] | [next] | [standalone]

#4389

<markpmlim@yahoo.com.sg> wrote:

>QuickViewDHGR is a simple utility for viewing Apple II Standard HiRes and 
>Double Hires graphics. Its deployment target is Mac OS X 10.5 or later.

Congratulations Mark! Keep 'em coming...

>Acknowledgements: Bill Buckel for making available his BMP2DHR project; the 
>Apple II double-hires graphics produced by his utility were used during 
>program testing.

Thanks for thinking kindly of me:)

Regards,

Bill

[toc] | [prev] | [next] | [standalone]

#4404

<markpmlim@yahoo.com.sg> wrote:
>QuickViewDHGR is a simple utility for viewing Apple II Standard HiRes and 
>Double Hires graphics. Its deployment target is Mac OS X 10.5 or later.

The DHR (Double Hi-Res Raster) Image Format

The Sprites (and optional black and white Sprite Masks) produced by Bmp2DHR 
are in my XPACK program's DHR format, but XPACK only produces Full Screen 
DHGR images so this is something new.

The Sprites produced by Bmp2DHR have an extension of DHR. (Sprite masks have 
an extension of DHM.) Like A2FC and AUX, BIN file pairs, they are stored on 
an Apple II Disk as ProDOS FileType $06 with an Auxiliary Type of $2000 or 
$4000 by default. On a DOS 3.3 disk they are stored with header information 
required by DOS 3.3. Use command option "DOS" if you need these DOS 3.3 
headers pre-pended to your DHGR output file(s).

The Header of a DHR (or a DHM) is in two parts;
3 bytes of ID data with the letters 'D', 'H', 'R' (or 'D','H','M') in 
upper-case.
1 byte - width in bytes (multiples of 4 bytes - 7 pixels)
1 byte - height in rasters

The DHR is a raster based image with scan-lines of raw DHGR data alternating 
between auxiliary and main memory. Therefore a BASIC program cannot load 
these any easier than in a C program, since the DHGR screen is interleaved 
the same way that the HGR screen is interleaved and not linear, so a 
considerable amount of supporting code is required. Bank switching between 
auxiliary and main memory banks 0 (main board) and 1 (language card) is also 
no easier in a BASIC program than in a C program.

For a full-screen DHR, there are 192 pairs of linear rasters, each of 40 
bytes of auxiliary memory data followed by 40 bytes of main memory data. 
Splitting the rasters into pairs keeps bank switching to a minimum while 
still allowing for linear reading and display from disk or buffer. Because 
of the way DHGR's interleaf  works, there is no faster way to load a screen 
fragment.

The full screen DHR loads raster by raster and displays as quickly as a 
buffered read can display on the Apple II. At 15365 bytes per screen this 
format provides a modest disk space saving over the 16384 bytes of the A2FC 
or AUX, BIN equivalent.

As mentioned earlier, a caveat for any file in DHR raster format is the 4 
byte / 7 pixel pattern of the DHGR display. The width descriptor in the 
header is given in byte width rather than pixel width. Image fragments in 
DHGR must necessarily be aligned on 4 byte boundaries to display properly. 
Bmp2DHR pads DHR formats as required in an optional background color if 
desired.

By comparison, HGR image fragments (in my RAG format and not currently 
produced by Bmp2DHR) are aligned on 2 byte boundaries for proper display but 
they are still somewhat recognizable if not aligned properly. If DHGR image 
fragments are not aligned on 4 byte boundaries they are a mess.

http://www.appleoldies.ca/bmp2dhr/sprites/
 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web