Discussion:
New dbl hi-res file type
Add Reply
I am Rob
2018-02-05 19:29:29 UTC
Reply
Permalink
Raw Message
According to this technote

http://www.1000bit.it/support/manuali/apple/technotes/ftyp/ftn.08.0000.html

is a documented supported Apple type for hi-res and dbl hi-res graphics.

Since I am currently doing work with dbl hi-res images, I would like to adopt this type. The Aux byte would hold $78.$7F.

The file type of $08 and Aux type $78 would be HGR B/W
The file type of #08 and Aux type $79 would be HGR color
The file type of $08 and Aux type $7A would be dbl hi-res B/W
The file type of $08 and Aux type $7B would be dbl hi-res color
The other 4 from $7C.7F are for page 2 of the graphics screen

A 3-letter type for hi-res can be HGR and, for dbl hi-res the type can be DHR.

I am revising my external CATALOG command to handle these types.

If there becomes a modified Basic.system, would there be any benefit to giving graphics screens their own file type and aux type instead of the usual binary type of $06?

It is too bad the IIe or IIc doesn't have a softswitch to change between color screen and B/W screen like the IIGS does. That would have been neat to have the computer switch to the correct mode according to the graphic type.

Rob
James Davis
2018-02-06 02:14:03 UTC
Reply
Permalink
Raw Message
Post by I am Rob
According to this technote
http://www.1000bit.it/support/manuali/apple/technotes/ftyp/ftn.08.0000.html
is a documented supported Apple type for hi-res and dbl hi-res graphics.
Since I am currently doing work with dbl hi-res images, I would like to adopt this type. The Aux byte would hold $78.$7F.
The file type of $08 and Aux type $78 would be HGR B/W
The file type of #08 and Aux type $79 would be HGR color
The file type of $08 and Aux type $7A would be dbl hi-res B/W
The file type of $08 and Aux type $7B would be dbl hi-res color
The other 4 from $7C.7F are for page 2 of the graphics screen
A 3-letter type for hi-res can be HGR and, for dbl hi-res the type can be DHR.
I am revising my external CATALOG command to handle these types.
If there becomes a modified Basic.system, would there be any benefit to giving graphics screens their own file type and aux type instead of the usual binary type of $06?
It is too bad the IIe or IIc doesn't have a softswitch to change between color screen and B/W screen like the IIGS does. That would have been neat to have the computer switch to the correct mode according to the graphic type.
Rob
Why? Do you have a problem viewing B&W on a Color TV/Monitor?
Brian Patrie
2018-02-06 21:32:45 UTC
Reply
Permalink
Raw Message
Post by James Davis
Post by I am Rob
It is too bad the IIe or IIc doesn't have a softswitch to change between color screen and B/W screen like the IIGS does. That would have been neat to have the computer switch to the correct mode according to the graphic type.
Why? Do you have a problem viewing B&W on a Color TV/Monitor?
You mean other than fine vertical lines looking like crap?
MG
2018-02-06 03:07:12 UTC
Reply
Permalink
Raw Message
Post by I am Rob
http://www.1000bit.it/support/manuali/apple/technotes/ftyp/ftn.08.0000.html
The file type of $08 and Aux type $78 would be HGR B/W
The file type of #08 and Aux type $79 would be HGR color
The file type of $08 and Aux type $7A would be dbl hi-res B/W
The file type of $08 and Aux type $7B would be dbl hi-res color
The tech note already states that if the file is $2000 bytes long, it is an HGR image, and if it's $4000 bytes long, it's a DHR image. Additionally,
Post by I am Rob
The other 4 from $7C.7F are for page 2 of the graphics screen
The file documents using a screen hole at offset $78 (equivalent $2078 or $4078) in the image to store essentially the same, if not a little more, information.

Any existing software out there that uses this type and follows the FTN will be looking at the size and the screen hole contents to give that information, the aux type won't matter. Any new software using your proposed aux type will either have to store redundant information in the screen hole, or potentially be incompatible with software that follows the FTN.

MG
I am Rob
2018-02-06 09:02:52 UTC
Reply
Permalink
Raw Message
Post by MG
Post by I am Rob
http://www.1000bit.it/support/manuali/apple/technotes/ftyp/ftn.08.0000.html
The file type of $08 and Aux type $78 would be HGR B/W
The file type of #08 and Aux type $79 would be HGR color
The file type of $08 and Aux type $7A would be dbl hi-res B/W
The file type of $08 and Aux type $7B would be dbl hi-res color
The tech note already states that if the file is $2000 bytes long, it is an HGR image, and if it's $4000 bytes long, it's a DHR image. Additionally,
Post by I am Rob
The other 4 from $7C.7F are for page 2 of the graphics screen
The file documents using a screen hole at offset $78 (equivalent $2078 or $4078) in the image to store essentially the same, if not a little more, information.
Any existing software out there that uses this type and follows the FTN will be looking at the size and the screen hole contents to give that information, the aux type won't matter. Any new software using your proposed aux type will either have to store redundant information in the screen hole, or potentially be incompatible with software that follows the FTN.
MG
I don't think there is any software that currently follows the FTN, none that I have seen, anyways.

I can't use the screen hole if I want to compress the hi-res or dbl-hi-res image.

The Aux byte is no longer needed for the starting address of $2000 or $4000, which means it will probably have a value of zero.

With the File type of $08, any program should automatically look at the Aux byte. The mode values that Apple proposes to store in the screen hole could just as easily have been stored in the Aux byte instead of ignoring it altogether. That is what the Aux byte is meant for, no?

Plus I was itching to use the reserved bits in the Access byte of the file header to indicated a compressed file. I just didn't know how to identify the file as hi-res or dbl-hi-res and maybe even super hi-res until now.

Apple doesn't (or I should say "didn't) have any standard for other graphics compression methods other than the original 3, so any new codes added to the list of file types would not be recognized by anyone but the author, anyways.

Is it necessary, or even worth it, to go to Apple to get a new file type registered, just so the remaining few programmers have a standard they can go by?

I suppose, at this stage, any programming done beyond the standard is kind of redundant.
Bill Buckels
2018-02-06 11:11:33 UTC
Reply
Permalink
Raw Message
According to me, the DHR file format is an image fragment... see here:

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

According to me the technote missed the boat by several years... see here:

http://www.appleoldies.ca/cc65/docs/dhgr/dhishow.pdf

Proving once again (in my mind at least) that any attempts to rewrite
history will fail.

Here's some excerpts:

ProDOS DHGR FileType $06 Auxiliary Type $2000 or $4000

DHGR Files are stored on the Apple II as ProDOS Binary FileType $06,
Auxiliary Type $2000 or $4000. In DOS 3.3 they are stored the same way, as a
BLOADable Binary File Type $04 (the same as a DOS 3.3 program), with a load
address of $2000 or $4000, and are appended with the load address in the
first two bytes of the DOS 3.3 four byte binary header, followed by the next
2 bytes which give the length of the file itself. In ProDOS this information
is stored in the filing system so DHGR files are 4 bytes longer in DOS 3.3
compared to their ProDOS equivalent.

Because these raw files are a memory image of the DHGR Screen on the Apple
II, so they can be displayed simply, by loading directly to DHGR Screen
Memory without any decoding or reformatting.

AUX, BIN File Pairs are targeted towards AppleSoft BASIC programs where they
can be BLOADed using the DOS 3.3 or ProDOS BLOAD command. Beagle Graphics
also works with these file pairs, and names auxiliary memory files ".AUX"
files. Sometimes these were BSAVEd to 8184 bytes. So this creates two sizes
of AUX, BIN files; 8184 bytes which is the extent of the visible part of the
screen, and 8192 bytes which is the extent of the screen's memory segment. A
loader program must handle both sizes.

A2FC files are targeted towards later versions of ProDOS or applications
written in higher level languages like David Snider's Dazzle Draw Paint
Program (Broderbund Software, 1984) where they may have originated:

http://jmsteinerfilms.com/2013/01/04/qa-with-gaming-pioneer-david-snider/

But they were not called A2FC files in Dazzle Draw nor later (1988) in Jason
Harper's "] [gif" converter. Jason Harper's later Super Convert read these
without needing a file extension, and then re-saved these as SHR (Super-Hi
Res) files, yet another reason that ProDOS FileType $08 was not widely used
for DHGR. And why anyone with a IIgs and of a serious nature, and with a
ready supply of more capable graphics to convert would have wanted a DHGR
file "back in the day" is also an interesting thought.

DHGR Standardization - ProDOS File Type $08

In November 1988 Apple Computer decided to standardize DHGR File Types by
re- assigning ProDOS File Type $08. By that time DHGR, which itself was a
design after- thought on the Apple //e, had already been in use for 5 years,
since the release of the Revision B Motherboard sometime around 1983-84,
when DOS 3.3 still had wide use. DHGR bitmapped graphics files, with wide
support in applications like Mark Simonsen's Beagle Graphics (Beagle Bros.)
and David Snider's Dazzle Draw (Broderbund), had long been established as
Binary Files with the Auxiliary Type being the Load Address of either DHGR
Screen One or Two.

Apple Computer's after-thought in re-assigning File Type $08 also extended
back to HGR (Hi-Res) files, which long predate the Apple //e and ProDOS.
They also had new names for HGR and DHGR; "Limited Color" and "Full Color".
Apple's 1988 re-assignment included a description for using ProDOS FileType
$08 Auxiliary Types $4000 (HGR) and $4001 (DHGR) for files compressed with
PackBytes. In his CiderPress program's HGR viewer source code, Andy McFadden
comments "FOT with auxtype $4000 is a compressed hi-res image. FOT with
auxtype $4001 is a compressed DHR image. In practice, nobody uses
these...".

Apple's re-assignment indicates that a portion of an image can be stored,
but due to the way the HGR and DHGR Screens are interleaved in a non-linear
manner, it is hard to understand how this might have been intended to work.

Regards,

Bill
Bill Buckels
2018-02-06 11:19:21 UTC
Reply
Permalink
Raw Message
http://www.appleoldies.ca/bmp2dhr/sprites/

Here's some excerpts...

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.

Including Load Position in the ProDOS Filing System

If a programmer wanted to load these according to a specific position on the
DHGR display, it would be possible to give the starting scan-line and
starting byte to the desired position on the screen, and store that as the
Auxiliary Type instead of the load Address of 0x2000 or 0x4000 which is
meaningless for an image fragment:

The program would read the header and perform a file integrity check to
ensure that the file size was as expected.
Part of the verification would also be to determine if the Auxiliary Type
fell within the DHGR visible screen boundaries and if the file itself would
fit.

Having satisfied this requirement the image fragment could be positioned at
that point by the program.
Doing so would save disk-space and load time when constructing a pre-planned
screen in a DHGR program, since full-screens are larger by comparison to
creating full-screens from fragments especially if blank screen space is
plentiful.

Background Color - Command Option "B"

Image Fragments can be used for continuous tone input files like digital
photos and complex images, or for "hand-made" pixel art like Sprites for
game programming and animation. Of course this is a generalization of sorts.
However, if animating a Sprite over some kind of background is "your thing"
then you will likely want to provide Bmp2DHR with a background color (a
transparent color). The default background color in Bmp2DHR is black. This
can be changed to any of the other 14 or 15 DHGR colors using command option
"B" followed by a DHGR color name or number.

The color numbers in Bmp2DHR follow the "Lo-Res Color Order", just like
Beagle Graphics used in their DHGR Patterns image, shown displayed below in
Sheldon Simms tohgr DHGR NTSC color conversion palette, which is also
Bmp2DHR's default palette (P5). The only output from Bmp2DHR that does not
follow the Lo-Res color order is VBMP output. I also follow the Lo-Res color
order in my cc65 demo programs, and everything else that I have written for
DHGR.

Regards,

Bill
Bill Buckels
2018-02-06 11:38:55 UTC
Reply
Permalink
Raw Message
Post by Bill Buckels
According to me the technote missed the boat by several years...
Here's another link to more of my extensive documentation and large body of
work in this regard...

http://www.appleoldies.ca/bmp2dhr/basic/#_Toc410744124

Rebranding BSAVE for "The Great Unwashed"

The fact of the Apple II BSAVE file format standard on the Apple II family
of computers is (obviously) indisputable. Before DHGR the BSAVE binary
graphics file format was used to save and load Hi-Res Graphics (HGR)
screens; before ProDOS 8, DOS 3.3 supported HGR BSAVE binary files. But
selling Computers and Computer Software depends on the same marketing
strategies as selling refrigerators and color TVs and everything else.

Towards the end of 1988, Apple Computer attempted to re-brand and up-market
the BSAVE graphics file format used on the Apple II in "their own image" in
their ProDOS File Type $08 specifications, as part of their File Type Notes.
However this was analogous to calling a CAT a DOG; by the time Apple
Computer re-branded BSAVE, two Apple II DHGR variations of BSAVE were
already in wide use; Beagle Graphics AUX, BIN 8192 byte file pairs for both
DOS 3.3 and ProDOS (since August 1984), and Dazzle Draw's A2FC 16384 byte
single file variation of BSAVE for ProDOS 8 (also since 1984). These are
also the two DHGR BSAVE formats created by my Bmp2DHR utility. And as
mentioned earlier, in 1984 when the DHGR "ship was sailing" with the BEAGLEs
and Broderbund "on-board", Apple Computer did not seem as interested in
developing some new DHGR standard for BSAVE graphics images as selling
Macintosh mice bundled with a Paint Program that only aspired to saving in
AppleSoft BASIC compatible HGR BSAVE format as ProDOS Binary File Type $06.
Having yet another standard for the same "standard" file makes no sense to
me at all.

Regards,

Bill

PS - the document above might in itself offer a pretty good read on the
topic of DHGR for those limited to programming in BASIC...

See here:

http://www.appleoldies.ca/bmp2dhr/basic/
I am Rob
2018-02-06 17:31:22 UTC
Reply
Permalink
Raw Message
Post by Bill Buckels
Post by Bill Buckels
According to me the technote missed the boat by several years...
Here's another link to more of my extensive documentation and large body of
work in this regard...
http://www.appleoldies.ca/bmp2dhr/basic/#_Toc410744124
Rebranding BSAVE for "The Great Unwashed"
The fact of the Apple II BSAVE file format standard on the Apple II family
of computers is (obviously) indisputable. Before DHGR the BSAVE binary
graphics file format was used to save and load Hi-Res Graphics (HGR)
screens; before ProDOS 8, DOS 3.3 supported HGR BSAVE binary files. But
selling Computers and Computer Software depends on the same marketing
strategies as selling refrigerators and color TVs and everything else.
Towards the end of 1988, Apple Computer attempted to re-brand and up-market
the BSAVE graphics file format used on the Apple II in "their own image" in
their ProDOS File Type $08 specifications, as part of their File Type Notes.
However this was analogous to calling a CAT a DOG; by the time Apple
Computer re-branded BSAVE, two Apple II DHGR variations of BSAVE were
already in wide use; Beagle Graphics AUX, BIN 8192 byte file pairs for both
DOS 3.3 and ProDOS (since August 1984), and Dazzle Draw's A2FC 16384 byte
single file variation of BSAVE for ProDOS 8 (also since 1984). These are
also the two DHGR BSAVE formats created by my Bmp2DHR utility. And as
mentioned earlier, in 1984 when the DHGR "ship was sailing" with the BEAGLEs
and Broderbund "on-board", Apple Computer did not seem as interested in
developing some new DHGR standard for BSAVE graphics images as selling
Macintosh mice bundled with a Paint Program that only aspired to saving in
AppleSoft BASIC compatible HGR BSAVE format as ProDOS Binary File Type $06.
Having yet another standard for the same "standard" file makes no sense to
me at all.
Regards,
Bill
PS - the document above might in itself offer a pretty good read on the
topic of DHGR for those limited to programming in BASIC...
http://www.appleoldies.ca/bmp2dhr/basic/
Thanks for the notes, Bill. You basically just confirmed everything I was thinking.

For the most part, I am not worried about the 2 popular BSAVE formats, since I want to use my LZ4 compression more, and since there is no standard for it, and since Apple no longer has an invested interest, and since I just plain want to, I will have to just create my own standard.

I want to have my own standard in place before I released too much into the wild.
Brian Patrie
2018-02-06 21:57:32 UTC
Reply
Permalink
Raw Message
Post by Bill Buckels
http://www.appleoldies.ca/bmp2dhr/sprites/
http://www.appleoldies.ca/cc65/docs/dhgr/dhishow.pdf
Proving once again (in my mind at least) that any attempts to rewrite
history will fail.
ProDOS DHGR FileType $06 Auxiliary Type $2000 or $4000
DHGR Files are stored on the Apple II as ProDOS Binary FileType $06,
Auxiliary Type $2000 or $4000. In DOS 3.3 they are stored the same way, as a
BLOADable Binary File Type $04 (the same as a DOS 3.3 program), with a load
address of $2000 or $4000, and are appended with the load address in the
first two bytes of the DOS 3.3 four byte binary header, followed by the next
2 bytes which give the length of the file itself. In ProDOS this information
is stored in the filing system so DHGR files are 4 bytes longer in DOS 3.3
compared to their ProDOS equivalent.
Because these raw files are a memory image of the DHGR Screen on the Apple
II, so they can be displayed simply, by loading directly to DHGR Screen
Memory without any decoding or reformatting.
AUX, BIN File Pairs are targeted towards AppleSoft BASIC programs where they
can be BLOADed using the DOS 3.3 or ProDOS BLOAD command. Beagle Graphics
also works with these file pairs, and names auxiliary memory files ".AUX"
files. Sometimes these were BSAVEd to 8184 bytes. So this creates two sizes
of AUX, BIN files; 8184 bytes which is the extent of the visible part of the
screen, and 8192 bytes which is the extent of the screen's memory segment. A
loader program must handle both sizes.
A2FC files are targeted towards later versions of ProDOS or applications
written in higher level languages like David Snider's Dazzle Draw Paint
http://jmsteinerfilms.com/2013/01/04/qa-with-gaming-pioneer-david-snider/
But they were not called A2FC files in Dazzle Draw nor later (1988) in Jason
Harper's "] [gif" converter. Jason Harper's later Super Convert read these
without needing a file extension, and then re-saved these as SHR (Super-Hi
Res) files, yet another reason that ProDOS FileType $08 was not widely used
for DHGR. And why anyone with a IIgs and of a serious nature, and with a
ready supply of more capable graphics to convert would have wanted a DHGR
file "back in the day" is also an interesting thought.
DHGR Standardization - ProDOS File Type $08
In November 1988 Apple Computer decided to standardize DHGR File Types by
re- assigning ProDOS File Type $08. By that time DHGR, which itself was a
design after- thought on the Apple //e, had already been in use for 5 years,
since the release of the Revision B Motherboard sometime around 1983-84,
when DOS 3.3 still had wide use. DHGR bitmapped graphics files, with wide
support in applications like Mark Simonsen's Beagle Graphics (Beagle Bros.)
and David Snider's Dazzle Draw (Broderbund), had long been established as
Binary Files with the Auxiliary Type being the Load Address of either DHGR
Screen One or Two.
Apple Computer's after-thought in re-assigning File Type $08 also extended
back to HGR (Hi-Res) files, which long predate the Apple //e and ProDOS.
They also had new names for HGR and DHGR; "Limited Color" and "Full Color".
Apple's 1988 re-assignment included a description for using ProDOS FileType
$08 Auxiliary Types $4000 (HGR) and $4001 (DHGR) for files compressed with
PackBytes. In his CiderPress program's HGR viewer source code, Andy McFadden
comments "FOT with auxtype $4000 is a compressed hi-res image. FOT with
auxtype $4001 is a compressed DHR image. In practice, nobody uses
these...".
Apple's re-assignment indicates that a portion of an image can be stored,
but due to the way the HGR and DHGR Screens are interleaved in a non-linear
manner, it is hard to understand how this might have been intended to work.
"Re-assigned" is the wrong term. They extended the definition of the
FOTofile type, which goes back to AppleSOS on the Apple III.

I'll pull a guess out of my backside, and suggest that the partial image
capability only applies to the compressed formats, which might be
linearly mapped.
Bill Buckels
2018-02-06 22:42:27 UTC
Reply
Permalink
Raw Message
Post by Brian Patrie
I'll pull a guess out of my backside, and suggest that the partial image
capability only applies to the compressed formats, which might be linearly
mapped.
Even considering the part of the anatomy from which your guess is derived,
I'd like to actually see someone implement the ft notes before agreeing :)
Although I have no problem flying by the seat of my pants either...

Bill
Antoine Vignau
2018-02-06 23:34:27 UTC
Reply
Permalink
Raw Message
So... adapt FTN.08.4000 (packed HGR image) and FTN.08.4001 (packed DHGR image) for your own usage, I recommend using FTN.08.4002 (LZ4 packed HGR image) and FTN.08.4003 (LZ4 packed DHGR image)

Apple II
File Type Notes
_____________________________________________________________________________
Developer Technical Support


File Type: $08
Auxiliary Type: $4000

Full Name: Packed Apple II Hi-Res Graphics File
Short Name: Packed Hi-Res File

Written by: Matt Deatherage November 1988

Files of this type and auxiliary type contain a packed Apple II Hi-Res
graphics screen.
_____________________________________________________________________________

Files of type $08 and auxiliary type $4000 contain a packed Apple II Hi-Res
graphics screen which has been packed with the same algorithm that PackBytes
on the Apple IIGS uses. This algorithm takes the 8K graphics screen and
produces a file with an indeterminate length and internal format, so no "mode
byte" at offset +121 is supported as it is with other files of type $08.

You can display a file of this type and auxiliary type by loading it, using
UnPackBytes to decrypt the data, moving it into a high-resolution display
buffer ($2000 or $4000 in the standard Apple II memory map), then simply
toggling the appropriate display soft switches.

File type $08 was originally defined as an Apple /// FotoFile, but now it is
useful for those applications that wish to save high-resolution or double
high-resolution data with a file type other than $06, which is a standard
binary file. If you choose to use this type, you should remember that older
applications which do not check the auxiliary type may attempt to interpret
these files incorrectly.

----------

Apple II
File Type Notes
_____________________________________________________________________________
Developer Technical Support


File Type: $08
Auxiliary Type: $4001

Full Name: Packed Apple II Double Hi-Res Graphics File
Short Name: Packed Double Hi-Res File

Written by: Matt Deatherage November 1988

Files of this type and auxiliary type contain a packed Apple II Double Hi-Res
graphics screen.
_____________________________________________________________________________

Files of type $08 and auxiliary type $4001 contain a packed Apple II Double
Hi-Res graphics screen which has been packed with the same algorithm that
PackBytes on the Apple IIGS uses. This algorithm takes the 16K graphics
screen (auxiliary memory portion first) and produces a file with an
indeterminate length and internal format, so no "mode byte" at offset +121 is
supported as it is with other files of type $08.

You can display a file of this type and auxiliary type by loading it, using
UnPackBytes to decrypt the data, moving the first half into auxiliary memory
at location $2000, moving the second half into main memory at location $2000,
then simply toggling the display soft switches and annunciators to turn on
double high-resolution mode.

File type $08 was originally defined as an Apple /// FotoFile, but now it is
useful for those applications that wish to save high-resolution or double
high-resolution data with a file type other than $06, which is a standard
binary file. If you choose to use this type, you should remember that older
applications which do not check the auxiliary type may attempt to interpret
these files incorrectly.
Bill Buckels
2018-02-07 00:33:57 UTC
Reply
Permalink
Raw Message
Post by Antoine Vignau
So... adapt FTN.08.4000 (packed HGR image) and FTN.08.4001 (packed DHGR
image) for your own usage, I recommend using FTN.08.4002 (LZ4 packed HGR
image) and FTN.08.4003 (LZ4 packed DHGR image)
That makes sense to me...

Bill
I am Rob
2018-02-07 03:51:25 UTC
Reply
Permalink
Raw Message
Post by Antoine Vignau
So... adapt FTN.08.4000 (packed HGR image) and FTN.08.4001 (packed DHGR image) for your own usage, I recommend using FTN.08.4002 (LZ4 packed HGR image) and FTN.08.4003 (LZ4 packed DHGR image)
If I were to be honest, I dislike Apples use of $4000 and $4001 in the Aux byte. Too confusing with the possible load address of graphics page #2. If a file type for compression were to be used, I would rather have seen something like this:

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

bit #15 - on = Super hi-res
bit #14 - on = Dbl hi-res - with this bit on would get $40xx anyways
bit #13 = on = Hi-res - would get $20xx
bit #12 = on = Dbl lo-res - woulde get $10xx
bit #11 = on = lo-res - would get $08xx
bit #10 = on = 80-col text screen
bit #9 = on = 40-col text screen
bit #8 = on = Data block

Lo-byte - counter from 0-255

0 = text uncompressed
$1 = Normal Text Screen RLE
$2 = Mouse Text screen RLE
$3 = Text file compression using Prodos method
$4 = Text file compression using dictionary libraries
$5 = Text file compression using LZ4
$6 = Text file compression using Huffman library

$80 - graphics uncompressed
$81 = RLE
$82 = Axe Packer
$83 = Beagle Scrunch
$84 = Apple Packbytes
$85 = Apple Preferred
$86 = Dream Graphics
$87 = LZW
$88 = LZ4
$89 = Zip
$8A = Huffman
$8B = Exocrunch
$8C = gzip
$8D = 7z
Antoine Vignau
2018-02-07 06:05:54 UTC
Reply
Permalink
Raw Message
BIN is always available for you to play with :-)
Apple normalized FOT but if don't like what they did, use another type!

Antoine
I am Rob
2018-02-07 18:39:33 UTC
Reply
Permalink
Raw Message
Post by Antoine Vignau
BIN is always available for you to play with :-)
Apple normalized FOT but if don't like what they did, use another type!
Antoine
I'm trying to get away from too many BIN files and have files that are, or can be, specifically recognizable by a file type.

2nd question: Apple may have normalized it, but they no longer support it. And as far as I can see, no one else does either.

Choosing another type is really not an option as this is the closest file type that fits with what I am currently doing, and resolves a lot of issues for having a dedicated graphics file type. I am trying somewhat to keep to Apple's standard of file types, without creating a totally arbitrary one.

I will be adopting the layout I mentioned above. Anyone can choose to adopt is as well or ignore it.
Antoine Vignau
2018-02-07 19:11:36 UTC
Reply
Permalink
Raw Message
If you want to use your own format, use F1 to F8 ;-)

antoine
I am Rob
2018-02-07 21:27:13 UTC
Reply
Permalink
Raw Message
Post by Antoine Vignau
If you want to use your own format, use F1 to F8 ;-)
antoine
What? I don't understand you with your F1unny F8rench accent ... -_-
f***@hotmail.com
2018-02-08 05:09:10 UTC
Reply
Permalink
Raw Message
Hey man! that demo/library/language/game you're working on that like 6 people in the whole world will see better follow the accepted usage for file type and naming conventions!! :)

Besides, $F7 and $F8 are already reserved for GR and DGR video files, respectively. I'm currently working with ISO to formalize $F6 for de-muxed 1-bit audio streams, so unfortunately the high end of the User Area is already pretty well developed these days. You might, however, still be able to pick something up down in the $F2-F3 aux type slums for a good bribe to the standards board though... :)

F
Post by I am Rob
2nd question: Apple may have normalized it, but they no longer support it. And as far as I can see, no one else does either.
Steve Nickolas
2018-02-08 05:50:35 UTC
Reply
Permalink
Raw Message
Post by f***@hotmail.com
Hey man! that demo/library/language/game you're working on that like 6
people in the whole world will see better follow the accepted usage for
file type and naming conventions!! :)
Besides, $F7 and $F8 are already reserved for GR and DGR video files,
respectively. I'm currently working with ISO to formalize $F6 for
de-muxed 1-bit audio streams, so unfortunately the high end of the User
Area is already pretty well developed these days. You might, however,
still be able to pick something up down in the $F2-F3 aux type slums for
a good bribe to the standards board though... :)
LOL

For all intents and purposes I've treated F1 as an "OVL" filetype (that's
what MECC did too, and I needed a filetype for extra pieces of code that
wasn't just BIN).

I guess the fact that people are actually starting to use ProDOS again
means we might need some sort of de-facto standards to fill in Apple's
holes...

-uso.
I am Rob
2018-02-08 06:15:37 UTC
Reply
Permalink
Raw Message
Post by f***@hotmail.com
Hey man! that demo/library/language/game you're working on that like 6 people in the whole world will see better follow the accepted usage for file type and naming conventions!! :)
Besides, $F7 and $F8 are already reserved for GR and DGR video files, respectively. I'm currently working with ISO to formalize $F6 for de-muxed 1-bit audio streams, so unfortunately the high end of the User Area is already pretty well developed these days. You might, however, still be able to pick something up down in the $F2-F3 aux type slums for a good bribe to the standards board though... :)
Nice try. You can't reserve F1-F8 for anything cause they have already been reserved by Apple for personal use by everyone. Your FFFFFFF'n videos will die a horrible death.
f***@hotmail.com
2018-02-08 08:32:16 UTC
Reply
Permalink
Raw Message
Maybe I took "User Defined" a little tooo literalllly??? It sounds like an invitation to define!
Post by I am Rob
Nice try. You can't reserve F1-F8 for anything cause they have already been reserved by Apple for personal use by everyone. Your FFFFFFF'n videos will die a horrible death.
James Davis
2018-02-08 21:26:27 UTC
Reply
Permalink
Raw Message
Post by f***@hotmail.com
Maybe I took "User Defined" a little tooo literalllly??? It sounds like an invitation to define!
Post by I am Rob
Nice try. You can't reserve F1-F8 for anything cause they have already been reserved by Apple for personal use by everyone. Your FFFFFFF'n videos will die a horrible death.
Just means you can use them for whatever you want, personally. Just don't expect the rest of the world to adhere to your personal definitions.
fadden
2018-02-09 18:52:32 UTC
Reply
Permalink
Raw Message
Please note that FOT with auxtype $8066 is reserved for fhpack:

"Packed images use the FOT ($08) file type, with an auxtype of $8066 (0x66 is ASCII 'f'). These files can be viewed with CiderPress v4.0.1 and later."

Any attempt to use this type for other purposes will be met with vigorous legal action! Or vocal moral outrage! Or repeated mailings of smelly socks!
I am Rob
2018-02-09 21:07:33 UTC
Reply
Permalink
Raw Message
Post by fadden
"Packed images use the FOT ($08) file type, with an auxtype of $8066 (0x66 is ASCII 'f'). These files can be viewed with CiderPress v4.0.1 and later."
Any attempt to use this type for other purposes will be met with vigorous legal action! Or vocal moral outrage! Or repeated mailings of smelly socks!
What the FOT?

This is actually working out pretty good. I can still use the $08 file type for my purposes and still support everyone else as well. This is what I have so far.



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

bit #7 - on = Super hi-res
- or can be considered reserved as there is a file type for SHR graphcs
- or reserved for Fadden who has threatened to mail his dirty socks
bit #6 - on = Dbl hi-res - with this bit on would get $40xx
bit #5 = on = Hi-res - would get $20xx
bit #4 = on = Dbl lo-res - would get $10xx
bit #3 = on = lo-res - would get $08xx
bit #2 = on = 80-col text screen
bit #1 = on = 40-col text screen
bit #0 = on = Data block

Lo-byte - counter from 0-255

$0 = compressed Hi-res with Packbytes (Hi byte $40)
$1 = compressed Dbl Hi-res with Packbytes (Hi byte $40)

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

$40 = Text file compression using LZ4 (Hi byte is 1, 2 or 4)
$41 = Text file compression using Huffman library (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
$92 =

* Mainly related to Super Hi-res Compression
$C0 = Apple Packbytes
$C1 = Paintworks
$C2 = Apple Preferred
$C3 = Dream Graphics

* Mainly related to Non platform specific compression

$E0 = LZW
$E1 = LZ4
$E2 = Huffman
$E3 = Zip
$E4 = Exocrunch
$E5 = gzip
$E6 = 7z
Brian Patrie
2018-02-10 12:10:52 UTC
Reply
Permalink
Raw Message
Post by I am Rob
Hi-byte - only one bit can be turned on at a time
bit #7 - on = Super hi-res
- or can be considered reserved as there is a file type for SHR graphcs
- or reserved for Fadden who has threatened to mail his dirty socks
bit #6 - on = Dbl hi-res - with this bit on would get $40xx
bit #5 = on = Hi-res - would get $20xx
bit #4 = on = Dbl lo-res - would get $10xx
bit #3 = on = lo-res - would get $08xx
bit #2 = on = 80-col text screen
bit #1 = on = 40-col text screen
bit #0 = on = Data block
Using up an entire byte for only 8 values seems terribly wasteful.
I am Rob
2018-02-10 18:24:39 UTC
Reply
Permalink
Raw Message
Post by Brian Patrie
Post by I am Rob
Hi-byte - only one bit can be turned on at a time
bit #7 - on = Super hi-res
- or can be considered reserved as there is a file type for SHR graphcs
- or reserved for Fadden who has threatened to mail his dirty socks
bit #6 - on = Dbl hi-res - with this bit on would get $40xx
bit #5 = on = Hi-res - would get $20xx
bit #4 = on = Dbl lo-res - would get $10xx
bit #3 = on = lo-res - would get $08xx
bit #2 = on = 80-col text screen
bit #1 = on = 40-col text screen
bit #0 = on = Data block
Using up an entire byte for only 8 values seems terribly wasteful.
In and of itself it might be if you don't understand it's purpose. But anyone who is an ML programmer should be able to see that this byte is used as a flag for the purpose of indicating a screen size or block size supported by the Apple IIe/IIc, and saved as a file.

There is a secondary byte that has 256 values for each bit in the hi-byte. this allows for 8x256 = 2048 unique identifiers, which is more than enough for this file type.

Considering that the original file type of $08 is to indicate a hi-res or dbl hi-res file, it was merely expanded to cover all screens supported by the IIe/IIc.

Which brought to my attention that the hi-bit can be used for the VOC card, carte blanche and for any screen size >560x192 screen size.
Post by Brian Patrie
bit #7 - on = any screen size > 560x192, including the VOC card, Carte Blanche, SHR, or specialty, etc
bit #6 - on = Dbl hi-res - with this bit on would get $40xx
bit #5 = on = Hi-res - would get $20xx
bit #4 = on = Dbl lo-res - would get $10xx
bit #3 = on = lo-res - would get $08xx
bit #2 = on = 80-col text screen
bit #1 = on = 40-col text screen
bit #0 = on = Data block
The advantages are that all secondary types that have been defined so far, are supported. And there are no disadvantages other than me bring this up and having to read so many dumb comments by smart people.
Bill Buckels
2018-02-10 22:35:22 UTC
Reply
Permalink
Raw Message
Post by I am Rob
bit #4 = on = Dbl lo-res - would get $10xx
This is too many dirty socks...

On the Apple II some stuff sometimes gets stored in between the small gaps
of the text screen. The raster format is friendly to that, but the BSAVED
DL1 and DL2 files clobber that area when loaded. A programmer is always
better off to use a raster approach for the reason of not clobbering memory
in the text screen area even when using single lo-res.

Here's the Double Lo-Res standard that I know and love...

http://www.appleoldies.ca/cc65/docs/dlgr/dloshow.pdf

/* The following loads two non-compressed double lo-res graphics image
formats:
Single File Raster Format - DLO
Bsaved Image Format file pairs - DL1 and DL2 */

char lodebuf[1920];
int dlodelo(char *name)
{
FILE *fp;
int y, status=-2;
int c, fl = 1016, height, packet, jdx, idx;
char tempchar[2], name1[20], name2[20], *ptr1, *ptr2;
asm("sta $c054");
/* MAIN MEM - safety play */
jdx = 999;
for (idx = 0; name[idx] != 0; idx++) {
name1[idx] = name2[idx] = name[idx];
if (name[idx] == '.') {
name1[idx] = name2[idx] = 0;
jdx = idx;
break;
}
}
if (jdx == 999) return status;
/* try to open a BASIC image pair */
strcat(name2,".DL1");
if ((fp = fopen(name2,"rb"))== NULL) {
/* if we can't open an image pair then try for a raster file... */
strcat(name1,".DLO");
if ((fp = fopen(name1,"rb"))== NULL) return -1;
fl = 1922;
ptr1 = (char *)&lodebuf[0];
ptr2 = (char *)&lodebuf[40];
}
else {
/* if we opened a DL1 then get ready to open a DL2 */
strcat(name1,".DL2");
}
switch(fl) {
case 1922:
/* is it a DLO ? - read the 2 byte header */
c = fread((char *)&tempchar[0],1,2,fp);
if (c!=2) {
fclose(fp);
break;
}
packet= (int)tempchar[0];
height= (int)tempchar[1];
if (height != 24 || packet != 80) {
fclose(fp); break;
}
c = fread(lodebuf,1,1920,fp);
fclose(fp);
if (c!=1920)break;
status = 0;
for(y=0,idx=0;y<height;y++,idx+=80) {
asm("sta $c055");
/* AUX MEM */
memcpy((char *)textbase[y],(char *)&ptr1[idx],40);
asm("sta $c054");
/* MAIN MEM */
memcpy((char *)textbase[y],(char *)&ptr2[idx],40);
}
break;
case 1016:
/* is it a bsaved image ? */
c = fread(lodebuf,1,1016,fp);
fclose(fp);
if (c != 1016)break;
asm("sta $c055");
/* AUX MEM */
memcpy((char *)0x0400,lodebuf,1016);
asm("sta $c054");
/* MAIN MEM */
if ((fp = fopen(name1,"rb"))== NULL) {
status = -1; break;
}
c = fread(lodebuf,1,1016,fp);
fclose(fp);
if (c != 1016)break;
memcpy((char *)0x0400,lodebuf,1016);
status=0; break;
}
return status;
}
Bill Buckels
2018-02-10 22:42:35 UTC
Reply
Permalink
Raw Message
Post by Bill Buckels
Here's the Double Lo-Res standard that I know and love...
http://www.appleoldies.ca/cc65/docs/dlgr/dloshow.pdf
We are looking for Binary Files (ProDOS FileType $06) with a Load Address
(Auxiliary Type) of $0400 which is the address of Page 1 of the Apple II
text screen. We are reasonably careful about which files we put into the
PICLIST. We only accept two file extensions; DLO and DL1. BSaved DL1 and DL2
files are in pairs, so we only put the DL1 file into the PICLIST...
Bill Buckels
2018-02-10 22:55:21 UTC
Reply
Permalink
Raw Message
Post by Bill Buckels
Here's the Double Lo-Res standard that I know and love...
http://www.appleoldies.ca/cc65/docs/dlgr/dloshow.pdf
For the sake of completeness, here's the rest of this series...

http://www.appleoldies.ca/cc65/docs/dlgr/dlodemo.pdf

Double Resolution Graphics modes were not available until after 1983 when
the second run of the Apple IIe came along, and even then, neither of these
modes was directly supported by AppleSoft BASIC. Until then, only 2
graphics modes (Lo-Res and Hi-Res) could be used. Lo-Res Graphics Mode for
the Apple II is such a coarse resolution that it is unsuitable for much more
than a medium for very primitive graphics demos or similar programs. When
DLGR came-along, doubling-up the horizontal resolution to 80 pixels x 48
rasters made it (barely) possible to display more recognizable Lo-Res type
graphics.
Bill Buckels
2018-02-10 16:54:08 UTC
Reply
Permalink
Raw Message
Post by fadden
Any attempt to use this type for other purposes will be met with vigorous
legal action! Or vocal moral outrage! Or repeated mailings of smelly
socks!
In Canada where Rob and I live, we generally allow the plaintiff to select
the torture method and it must be gender neutral... however we often find
for the plaintiff so might I suggest smelly socks in case you get the
package returned :)

Seriously though, I am a big believer in CiderPress, so if the professor
wants to continue providing me with opinions backed-up by C code examples
and the best utility of its kind ever, who am I to risk the smelly socks in
the mail... (?)

Bill
I am Rob
2018-02-07 03:02:02 UTC
Reply
Permalink
Raw Message
Post by Bill Buckels
Post by Brian Patrie
I'll pull a guess out of my backside, and suggest that the partial image
capability only applies to the compressed formats, which might be linearly
mapped.
Even considering the part of the anatomy from which your guess is derived,
I'd like to actually see someone implement the ft notes before agreeing :)
Although I have no problem flying by the seat of my pants either...
Bill
I think partial images can be saved, but has to be a multiple of 4 bytes. Then the portion image can be restored with 2 bytes Aux, 2 bytes Main. This would probably would require a header for width and height.
Bill Buckels
2018-02-07 16:51:46 UTC
Reply
Permalink
Raw Message
Post by I am Rob
I think partial images can be saved, but has to be a multiple of 4 bytes.
Then the portion image can be restored with 2 bytes Aux, 2 bytes Main.
This would probably would require a header for width and height.
Their specification does not allow for partial images does it? I know that
mine does...

http://www.appleoldies.ca/bmp2dhr/silly/#_Toc409447947

"Although the "Mixed-Up Toy" represents an Incredible Journey over almost 40
years of time and space, it is actually an incredibly trivial program and
revolves around one very simple routine written in the C programming
language that has one sole purpose; it loads DHGR image fragments to the
Apple II display"

Bill
I am Rob
2018-02-07 21:39:48 UTC
Reply
Permalink
Raw Message
Post by Bill Buckels
Post by I am Rob
I think partial images can be saved, but has to be a multiple of 4 bytes.
Then the portion image can be restored with 2 bytes Aux, 2 bytes Main.
This would probably would require a header for width and height.
Their specification does not allow for partial images does it? I know that
mine does...
http://www.appleoldies.ca/bmp2dhr/silly/#_Toc409447947
"Although the "Mixed-Up Toy" represents an Incredible Journey over almost 40
years of time and space, it is actually an incredibly trivial program and
revolves around one very simple routine written in the C programming
language that has one sole purpose; it loads DHGR image fragments to the
Apple II display"
Bill
Well done, Bill.

I have to say, you have come a long way with your BMP2DHR conversion program as well. Some of your graphics are, the least to say, pretty awesome in 16 colors.

Oh why, oh why couldn't you have been a Mac person? :o)
f***@hotmail.com
2018-02-11 05:30:53 UTC
Reply
Permalink
Raw Message
Despite my dumb comment, I like the idea of extending BASIC.SYSTEM. Do you plan to get some of these additions included in the proposed ProDOS 2.5?

Even better would be a single viewer application to decode these file types and display them. I might be tempted to go back and change all my image files to meet the spec, if that were the case. Maybe using the BASIS.SYSTEM framework? I will admit not having seen a good portion of the compressed files in the wild, however.

Would be great to have built-in support in BASIC for double-lores and double-hires modes as well. Been a pretty steep learning curve figuring out how to use them in assembly. Not sure if that's what you had in mind. Seems like a big omission on Apple's part, though.

f
I am Rob
2018-02-11 17:51:41 UTC
Reply
Permalink
Raw Message
Post by f***@hotmail.com
Do you plan to get some of these additions included in the proposed ProDOS 2.5?
Nothing extra has to be done to Prodos or Basic.system. If anything, a new 3 letter word to describe the file type may be used and implemented in the CATALOG function of Basic.system.
Post by f***@hotmail.com
Even better would be a single viewer application to decode these file types and display them. I might be tempted to go back and change all my image files to meet the spec, if that were the case. Maybe using the BASIS.SYSTEM framework? I will admit not having seen a good portion of the compressed files in the wild, however.
I already have small routines to view each of the screen files. I just have to amalgamate them into one and make a slideshow viewer or single screen viewer out of them.

Most of the compression schemes would not even be implemented for any of the Apple screens. They were just put into the list to show how other schemes could be added to the file type.
Post by f***@hotmail.com
Would be great to have built-in support in BASIC for double-lores and double-hires modes as well. Been a pretty steep learning curve figuring out how to use them in assembly. Not sure if that's what you had in mind. Seems like a big omission on Apple's part, though.
I have a couple of disk images that change Applesoft to draw to dbl lo-res and dbl hi-res under Dos 3.3. Applesoft can't be changed very easily under Prodos as the Language Card is used by Prodos, but there are a few plotting programs that support dbl lo-res or dbl hi-res that are ampersand driven.

One that supports both OSes but just the dbl hi-res, is DOUBLE STUFF, on the Nibble magazine disks, and is one of the better ones out there.

http://mirrors.apple2.org.za/ftp.apple.asimov.net/images/magazines/nibble/Nibble%20Programs.zip

Disk #32A


Here is a link to my dbl hi-res screen drawing program. Press OA-? for help

http://s000.tinyupload.com/index.php?file_id=85489792447675684085
Loading...