BASIS.SYSTEM and file/aux type associations

[i***@gmail.com]

Forking the thread...

John Brooks: What is your vision for maintaining the file/aux type mapping for launching applications via BASIS.SYSTEM? Has any progress or further thought happened here?

(Integrating with BASIS.SYSTEM would be great for A2Desktop for the GUI-minded folks; I've added an issue to my tracker for when I get back to that project.)

[John Brooks]

Post by i***@gmail.com
Forking the thread...
John Brooks: What is your vision for maintaining the file/aux type mapping for launching applications via BASIS.SYSTEM? Has any progress or further thought happened here?
(Integrating with BASIS.SYSTEM would be great for A2Desktop for the GUI-minded folks; I've added an issue to my tracker for when I get back to that project.)

I'm not sure what techniques GS/OS 6.0 Finder uses for managing and mapping file/aux types, and whether it is worth trying to use or mimic parts of that system.

There are some Apple tech notes related to file type & aux type:

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

http://www.1000bit.it/support/manuali/apple/technotes/ftyp/ft.about.html


My (in-progress) thinking about a simple file type mapping system (ignoring aux types) was to append a binary blob to the end of the BASIS.SYSTEM launcher that would contain:

1) 256 bytes: Pathname index for each ProDOS File Type

2) <N bytes>: Array of up to 256 pascal strings, each with the full pathname of the mapped SYS file


A separate file type mapping text file, and a separate processing tool (in basic?) that would generate the binary blob and append it to BASIS.SYSTEM.

The file type mapping text file would simply contain the hex file type or range, and the associated SYS pathname, in priority order:

$04=/HD/Util/TextView.system
$06=/HD/Util/BigBin.system
$19-$1B=/HD/Apps/Appleworks/Aplworks.system
$50-$CF=/HD/Util/ToFinder.system
$F1-$F4=/HD/DOS3.3.LAUNCHER
$FA=/HD/IntBasic.system
$00-$FF=/HD/Basic.system

BASIS.SYSTEM logic would be pretty simple:

1) If no file was passed at $2006, then quit (IE ProDOS boot)

2) Do a ProDOS GET_INFO on the filename at $2006 to get the filetype

3) Index into 256-byte blob lookup table by filetype to get pathname index

4) Count through blob pathname array until we reach the indexed SYS path

5) Copy the SYS file pathname to $0280 per ProDOS 8 tech ref spec

6) Move the selected filename and our SYS loader code down to $1000

7) Load SYS file at $2000

8) Copy selected filename to $2006 & JMP $2000


Thoughts?

-JB
@JBrooksBSI

[i***@gmail.com]

Hrm. That seems problematic from a maintenance perspective. If BASIS.SYSTEM is upgraded you lose your configured mapping unless you remember to find your mapping text file and run the tool. (Which is likely something you did years ago and forgot about...) Similarly, it means the BASIS.SYSTEM file on its own can't be copied about/shared.

On the flip side, it avoids the obvious alternative of cluttering the top level directory with a separate FILETYPEMAP TXT file. But... given the pros/cons I think I'd lean towards the separate file (which means BASIS.SYSTEM needs to parse it at runtime).
Allow comments / blank lines, please!

Post by John Brooks
$04=/HD/Util/TextView.system

Support common type string aliases (SYS, BAS, BIN, TXT, etc - the ones ProDOS shows in CAT) ? Although this could just be provided by a standard comment header that gives them.

Post by John Brooks
$06=/HD/Util/BigBin.system
$19-$1B=/HD/Apps/Appleworks/Aplworks.system
$50-$CF=/HD/Util/ToFinder.system
$F1-$F4=/HD/DOS3.3.LAUNCHER
$FA=/HD/IntBasic.system
$00-$FF=/HD/Basic.system

Is SYS $FF overridable? (what would that mean?)

Post by John Brooks
Thoughts?

Behavior when the target SYS is not present? e.g. show a helpful error, wait for keypress, QUIT

Behavior when the type is unknown - just beep/QUIT as today?

[f***@hotmail.com]

Sounds great! I would like to reserve the following hex type for my lores movies, and can supply working playback code to integrate. My assembly isn't great, but I can probably figure out pointing it to a different filename buffer. (Again, many thanks to Mike Mahon for writing the original code, and qkumba for bug squashing!)

$F7 - UD7 - User Defined 7 - /HD/VIDEO.SYSTEM AKA PLAYBACK.BIN (you sure you want to hardcode in the volume name??)

I have a video playback system that works but is kludgy like the "hardcode a file&pathname into DOS3.3LAUNCHER" method. doesn't work if you rename the volume. also requires a separate launch file for each video. Would love to just change the file type to view them.

Would be cool to view lores/doublelores/hires/doublehires images directly from Bitsy. Maybe even up-down arrow to show the next file in the directory like a slideshow.


Again, agree with the general thoughts about DOS3.3.LAUNCHER being a hack, but if working for maximum compatibility and maximum back catalog, it seems silly to ignore since it works. And would take minimal coding to update for BASIS (not saying I know enough to do it, though).

Can you pass filenames to AppleWorks when you launch it? Can't say I've ever seen that one.

Really quite amazing that BASIS can work in Bitsy Bye in under 1000 bytes or whatever it is. Off topic, but just noticed for the first time last night that you can also jump to a letter immediately by hitting it's key. Great news for people like me who aren't into 10 sub-directories by letter.

Agree with the separate text file method. The update tool will require it's own maintenance, and would be another file in root just like the config file would be. KISS principle/UNIX philosophy and all that.

Frank

[Hugh Hood]

Post by f***@hotmail.com
Can you pass filenames to AppleWorks when you launch it? Can't say I've ever seen that one.

Actually, this has been done before, and works by associating the file
type of the passed data file with a special AppleWorks UltraMacros
_Task_ file (a launchable SYS file), rather than with the AppleWorks
program itself, which is 'APLWORKS.SYSTEM'.

Upon 'selecting' the data file, the Task file is launched, which in turn
(using some assembly routines) reads the passed filename, starts
AppleWorks, and then loads the passed filename to the AppleWorks Desktop.

Tom Hoover (old GEnie guy) did one of these for AppleWorks 3 with
UltraMacros 3 and Doug Gum (Office Productivity Software) did one of
these for AppleWorks 3 with UltraMacros 4.

Both of them worked with the GS/OS Finder (which allows icon info to
associate file types with apps), but they were also able to use the
better selectors (such as ProSel) to do the same job on a straight
ProDOS 8 system.

For AppleWorks 5.1 and GS/OS only, I've got a completed (but unreleased
due to laziness in writing docs explaining the source code) Task file
called "AW51FinderLoad", which I bill as "An Apple IIgs GS/OS Finder
Multi-File Loader".

With it, from the Finder you can select up to 36 files from types
ADB/ASP/AWP/TXT, hit <OA-O> to open, and AppleWorks 5.1 is launched and
automatically loads all 36 files. Rather than use the ProDOS $2006
protocol, which is limited to (1) filename, this method makes use of the
GS/OS Message Center.

That concept, however, is not original to me. Back in 1991, (2) clever
guys from the Netherlands named John L. Tegelaar and Ton W. van Santen
released a shareware AppleWorks 3 launcher that also used the GS/OS
Message Center. It had some limitations, but I thought it was quite
ingenious at the time.




Hugh Hood

[John Brooks]

Post by Hugh Hood

Post by f***@hotmail.com
Can you pass filenames to AppleWorks when you launch it? Can't say
I've ever seen that one.

Actually, this has been done before, and works by associating the file
type of the passed data file with a special AppleWorks UltraMacros
_Task_ file (a launchable SYS file), rather than with the AppleWorks
program itself, which is 'APLWORKS.SYSTEM'.
Upon 'selecting' the data file, the Task file is launched, which in turn
(using some assembly routines) reads the passed filename, starts
AppleWorks, and then loads the passed filename to the AppleWorks Desktop.
Tom Hoover (old GEnie guy) did one of these for AppleWorks 3 with
UltraMacros 3 and Doug Gum (Office Productivity Software) did one of
these for AppleWorks 3 with UltraMacros 4.
Both of them worked with the GS/OS Finder (which allows icon info to
associate file types with apps), but they were also able to use the
better selectors (such as ProSel) to do the same job on a straight
ProDOS 8 system.
For AppleWorks 5.1 and GS/OS only, I've got a completed (but unreleased
due to laziness in writing docs explaining the source code) Task file
called "AW51FinderLoad", which I bill as "An Apple IIgs GS/OS Finder
Multi-File Loader".
With it, from the Finder you can select up to 36 files from types
ADB/ASP/AWP/TXT, hit <OA-O> to open, and AppleWorks 5.1 is launched and
automatically loads all 36 files. Rather than use the ProDOS $2006
protocol, which is limited to (1) filename, this method makes use of the
GS/OS Message Center.
That concept, however, is not original to me. Back in 1991, (2) clever
guys from the Netherlands named John L. Tegelaar and Ton W. van Santen
released a shareware AppleWorks 3 launcher that also used the GS/OS
Message Center. It had some limitations, but I thought it was quite
ingenious at the time.
Hugh Hood

That sounds like a cool and very useful utility, Hugh. If you include a readme with your post above and put AW51FinderLoad on asimov, I'll bet people will find it useful.

Is there any utils available to take a doc name at $2006 and pass it to Appleworks 5.1?

-JB
@JBrooksBSI

[Hugh Hood]

Post by John Brooks

Post by John Brooks
Is there any utils available to take a doc name at $2006 and pass it to Appleworks 5.1?

John,

I'm not aware of anything currently written to read a file name at $2006
and pass it to AppleWorks 5.1 for auto-loading.

If there's sufficient interest, I'll take a look at it and my approach
would be:

1. Create a SYS file to associate with the desired file types
(ADB/AWP/ASP and perhaps TXT) and receive the passed name at $2006;

2. Have the SYS file move the name from $2006 to an area where an
AppleWorks 5.1 boot won't step on it (e.g. $BAB0-$BAFF);

3. Have the SYS file then launch an AppleWorks compiled macro Task file
that will in turn start AppleWorks, read the filename, and load it to
the Desktop.


The earlier AppleWorks 3 solutions I mentioned dispensed with step 1,
but required the necessary machine code to be grafted into a then
unmodifiable compiled macro Task file, which is not an approach I would
favor.

Post by John Brooks
That sounds like a cool and very useful utility, Hugh. If you include
a readme with your post above and put AW51FinderLoad on asimov, I'll
bet people will find it useful.

Thanks, John. Maybe that will encourage me to get off my tail and just
finish the docs and source code comments (both macro and assembly),
though. ;-)

In the meantime, here's a little movie for the curious showing
AW51FinderLoad in action with (3) AWP files and (1) TXT file selected at
the same time from the Finder:

<http://home.earthlink.net/~hughhood/AW51LauncherDemo.mov>





Hugh Hood

[Hugh Hood]

Post by John Brooks
Is there any utils available to take a doc name at $2006 and pass it to Appleworks 5.1?

John,

I should have you something soon that works to read a pathname of a
single AppleWorks file passed by your BASIS.SYSTEM and have AppleWorks
5.1 load it to the Desktop.

It's not a slick as my GS/OS Message Center loader that will pass up to
36 files to load at one time, but OTOH it can be used on any II that
runs AppleWorks 5.1.

Just so I'm clear -- you'll be passing a full pathname (e.g.
/HD/Sub/FiletoLoad) @ $2006, correct?

Thanks.




Hugh Hood

[barana]

Post by Hugh Hood

Post by John Brooks
Is there any utils available to take a doc name at $2006 and pass it to Appleworks 5.1?

John,
I should have you something soon that works to read a pathname of a
single AppleWorks file passed by your BASIS.SYSTEM and have AppleWorks
5.1 load it to the Desktop.
It's not a slick as my GS/OS Message Center loader that will pass up to
36 files to load at one time, but OTOH it can be used on any II that
runs AppleWorks 5.1.
Just so I'm clear -- you'll be passing a full pathname (e.g.
Thanks.
Hugh Hood

Hugh, you're a legend, You've just won the first best coder of the year award for 2018.

[Hugh Hood]

barana,

Thanks for the compliment, but I'm afraid that even on my best days I'm
just a plodding tinkerer.

Fortunately, this group enjoys the participation of some guys who have
legit programming chops -- Wannop, Vignau, McFadden, Brooks, Ferrie,
Buckels, Mahon, Schmidt -- and a handful of others who I trust will
forgive me for omitting their names.

OTOH, if you were just joking, I'm laughing too. ;-)




Hugh Hood

[John Brooks]

Post by Hugh Hood

Post by John Brooks
Is there any utils available to take a doc name at $2006 and pass it to Appleworks 5.1?

John,
I should have you something soon that works to read a pathname of a
single AppleWorks file passed by your BASIS.SYSTEM and have AppleWorks
5.1 load it to the Desktop.
It's not a slick as my GS/OS Message Center loader that will pass up to
36 files to load at one time, but OTOH it can be used on any II that
runs AppleWorks 5.1.
Just so I'm clear -- you'll be passing a full pathname (e.g.
Thanks.
Hugh Hood

Yes, we can pass the full path if needed. I prefer setting the ProDOS prefix to the containing folder and sending only the 15 character filename to open at $2006, but some .system files want the prefix set to the directory containing the .system file and don't start up properly if the directory is set somewhere else.

-JB

[Hugh Hood]

Post by John Brooks
I prefer setting the ProDOS prefix to the containing folder and
sending only the 15 character filename to open at $2006, but some
.system files want the prefix set to the directory containing the
.system file and don't start up properly if the directory is set
somewhere else.
-JB

John,

I can work with that. The SYS file I'm writing won't care about $280
except for retrieving the path of the passed filename from your launcher
to stash away for AppleWorks' use.

In fact, I'll try to write it so that it works either way.




Hugh Hood

[Hugh Hood]

John,

Well, I spoke too soon. As you predicted, I am having trouble with my
AppleWorks 5.1 pre-launcher .SYS file if the $280 prefix doesn't hold
the name of the directory containing the APLWORKS.SYSTEM .SYS file that
the pre-launcher loads and JMPs to.

If the .SYS file prefix can be passed somewhere else where is is 'safe',
I don't mind moving it back into place at $280 after reading and saving
the prefix for the file to open, efficiency considerations aside.

Otherwise, I'd ask you consider passing the full pathname + filename at
$2006 (for the file to *open*), and let $280 contain the name of the
directory (for the .SYS file to *execute*). If you're concerned about
exceeding the customary $41 byte length on extra long paths, I can
modify the $2003+ protocol bytes to $EE $EE $xx, if necessary.

As you know, it's easy enough to separate the pathname and the filename
placed at $2006.

Thanks.





Hugh Hood

Post by Hugh Hood

Post by John Brooks
I prefer setting the ProDOS prefix to the containing folder and
sending only the 15 character filename to open at $2006, but some
.system files want the prefix set to the directory containing the
.system file and don't start up properly if the directory is set
somewhere else.
-JB

John,
I can work with that. The SYS file I'm writing won't care about $280
except for retrieving the path of the passed filename from your launcher
to stash away for AppleWorks' use.
In fact, I'll try to write it so that it works either way.
Hugh Hood

[John Brooks]

Post by Hugh Hood
John,
Well, I spoke too soon. As you predicted, I am having trouble with my
AppleWorks 5.1 pre-launcher .SYS file if the $280 prefix doesn't hold
the name of the directory containing the APLWORKS.SYSTEM .SYS file that
the pre-launcher loads and JMPs to.
If the .SYS file prefix can be passed somewhere else where is is 'safe',
I don't mind moving it back into place at $280 after reading and saving
the prefix for the file to open, efficiency considerations aside.
Otherwise, I'd ask you consider passing the full pathname + filename at
$2006 (for the file to *open*), and let $280 contain the name of the
directory (for the .SYS file to *execute*). If you're concerned about
exceeding the customary $41 byte length on extra long paths, I can
modify the $2003+ protocol bytes to $EE $EE $xx, if necessary.
As you know, it's easy enough to separate the pathname and the filename
placed at $2006.
Thanks.
Hugh Hood

Post by Hugh Hood

Post by John Brooks
I prefer setting the ProDOS prefix to the containing folder and
sending only the 15 character filename to open at $2006, but some
.system files want the prefix set to the directory containing the
.system file and don't start up properly if the directory is set
somewhere else.
-JB

John,
I can work with that. The SYS file I'm writing won't care about $280
except for retrieving the path of the passed filename from your launcher
to stash away for AppleWorks' use.
In fact, I'll try to write it so that it works either way.
Hugh Hood

.

Post by Hugh Hood
Well, I spoke too soon. As you predicted, I am having trouble with my
AppleWorks 5.1 pre-launcher .SYS file if the $280 prefix doesn't hold
the name of the directory containing the APLWORKS.SYSTEM .SYS file that
the pre-launcher loads and JMPs to.

When a non-SYS file is selected in Bitsy Bye, three path vars are set:
1) The ProDOS PREFIX is set to the directory containing the selected file
2) $280 contains the partial path to the selected file
3) $380 contains the full (root) path to the launcher (BASIS.SYSTEM or BASIC.SYSTEM)

I recommend using the $380 full path for your Appleworks launcher for now. However the launcher full path address will likely change in the future as both ProDOS and the launching machinery are evolving.

Hope that helps,
-JB
@JBrooksBSI

[Hugh Hood]

Post by John Brooks
1) The ProDOS PREFIX is set to the directory containing the selected file
2) $280 contains the partial path to the selected file
3) $380 contains the full (root) path to the launcher (BASIS.SYSTEM or BASIC.SYSTEM)
I recommend using the $380 full path for your Appleworks launcher for
now. However the launcher full path address will likely change in the
future as both ProDOS and the launching machinery are evolving.
Hope that helps,
-JB
@JBrooksBSI

John,

Very good.

May I ask you to confirm that I am understanding your (3) path variables
properly in conjunction with $2006+?


Consider these example files:

A. AWP File selected by Bitsy Bye to Open:

Full Pathname = /HARD2/FILES/WORDPROC/MYAWPFILE


B. SYS file instructed to be launched by BASIS.SYSTEM:

Full Pathname = /HARD1/APPLEWORKS5/AW5LAUNCHER


C. SYS file that will then be launched by AW5LAUNCHER:

Full Pathname = /HARD1/APPLEWORKS5/APLWORKS.SYSTEM

--------------------------------------------------------------

OK,

1. From AW5LAUNCHER an MLI GET_PREFIX call should return the Prefix of
the file selected from Bitsy Bye to open;
[result = /HARD2/FILES/WORDPROC/ ]

(off topic -- where in memory does ProDOS (not BASIC.SYSTEM) actually
store this Prefix?)


2. $280+ also contains the Prefix of the file selected from Bitsy Bye to
open;
[result = /HARD2/FILES/WORDPROC/ ] {same result as in #1}


3. $2006+ contains just the name of the file to open;
[result = MYAWPFILE ]


4. AWLAUNCHER can then extract *its* PREFIX from the $380 full pathname
in order to move it to $280 as APLWORKS.SYSTEM requires.
[result = /HARD1/APPLEWORKS/APLWORKS.SYSTEM (from which AWLAUNCHER will
remove APLWORKS.SYSTEM]



If I've misunderstood how you plan this to work, please set me straight.

I understand that location $380 may change.

And with advance apologies to the ca65 guys, this source is in Merlin.
Old habits and all. ;-)

Thanks.




Hugh Hood

[John Brooks]

Post by Hugh Hood

Post by John Brooks
1) The ProDOS PREFIX is set to the directory containing the selected file
2) $280 contains the partial path to the selected file
3) $380 contains the full (root) path to the launcher (BASIS.SYSTEM or BASIC.SYSTEM)
I recommend using the $380 full path for your Appleworks launcher for
now. However the launcher full path address will likely change in the
future as both ProDOS and the launching machinery are evolving.
Hope that helps,
-JB
@JBrooksBSI

John,
Very good.
May I ask you to confirm that I am understanding your (3) path variables
properly in conjunction with $2006+?
Full Pathname = /HARD2/FILES/WORDPROC/MYAWPFILE
Full Pathname = /HARD1/APPLEWORKS5/AW5LAUNCHER
Full Pathname = /HARD1/APPLEWORKS5/APLWORKS.SYSTEM
--------------------------------------------------------------
OK,
1. From AW5LAUNCHER an MLI GET_PREFIX call should return the Prefix of
the file selected from Bitsy Bye to open;
[result = /HARD2/FILES/WORDPROC/ ]
(off topic -- where in memory does ProDOS (not BASIC.SYSTEM) actually
store this Prefix?)
2. $280+ also contains the Prefix of the file selected from Bitsy Bye to
open;
[result = /HARD2/FILES/WORDPROC/ ] {same result as in #1}
3. $2006+ contains just the name of the file to open;
[result = MYAWPFILE ]
4. AWLAUNCHER can then extract *its* PREFIX from the $380 full pathname
in order to move it to $280 as APLWORKS.SYSTEM requires.
[result = /HARD1/APPLEWORKS/APLWORKS.SYSTEM (from which AWLAUNCHER will
remove APLWORKS.SYSTEM]
If I've misunderstood how you plan this to work, please set me straight.
I understand that location $380 may change.
And with advance apologies to the ca65 guys, this source is in Merlin.
Old habits and all. ;-)

.

Post by Hugh Hood
1. From AW5LAUNCHER an MLI GET_PREFIX call should return the Prefix of
the file selected from Bitsy Bye to open;
[result = /HARD2/FILES/WORDPROC/ ]

Yes, as long as BASIS.SYSTEM did not alter the prefix (which it shouldn't IMO).

Post by Hugh Hood
(off topic -- where in memory does ProDOS (not BASIC.SYSTEM) actually
store this Prefix?)

The current prefix is just above the clock driver. LC bank 1 $D7 page is layed out like this:
$D700-$D741: Pathname buffer (first path char at $D700)
$D742-$D7BF: Clock driver
$D7C0-$D7FF: Prefix buffer (last pfx char at $D7FF)

Post by Hugh Hood
2. $280+ also contains the Prefix of the file selected from Bitsy Bye to
open;
[result = /HARD2/FILES/WORDPROC/ ] {same result as in #1}

Yes, but ideally, BASIS.SYSTEM would load the SYS file associated with the selected data file at $2000, move the selected file name from $280 into $2006, then place the full path of the SYS file at $280 to meet the ProDOS 8 tech ref specs.

Post by Hugh Hood
3. $2006+ contains just the name of the file to open;
[result = MYAWPFILE ]

Yes, unless BASIS.SYSTEM chooses to do a ProDOS GETPREFIX, write the prefix to $2006 and then append the selected filename from $280 to make a full prefix at $2006.

Post by Hugh Hood
4. AWLAUNCHER can then extract *its* PREFIX from the $380 full pathname
in order to move it to $280 as APLWORKS.SYSTEM requires.
[result = /HARD1/APPLEWORKS/APLWORKS.SYSTEM (from which AWLAUNCHER will
remove APLWORKS.SYSTEM]

$380 contains the full path to BASIS.SYSTEM. This must be a full path because the prefix is set to the dir of the selected file. However, this 'full path' is always the root, so it's really just the volume name with BASIS.SYSTEM appended.

If your AWLAUNCHER <is> BASIS.SYSTEM, in the root directory, then $380 is what you want for a full pathname. If your AWLAUNCHER is in a subdirectory and will be called by BASIS.SYSTEM in the root, then you can have BASIS.SYSTEM set things up however you'd like, including putting full-pathnames at $280 and $2006.

-JB
@JBrooksBSI

[James Davis]

Post by John Brooks

Post by Hugh Hood

Post by John Brooks
1) The ProDOS PREFIX is set to the directory containing the selected file
2) $280 contains the partial path to the selected file
3) $380 contains the full (root) path to the launcher (BASIS.SYSTEM or BASIC.SYSTEM)
I recommend using the $380 full path for your Appleworks launcher for
now. However the launcher full path address will likely change in the
future as both ProDOS and the launching machinery are evolving.
Hope that helps,
-JB
@JBrooksBSI

John,
Very good.
May I ask you to confirm that I am understanding your (3) path variables
properly in conjunction with $2006+?
Full Pathname = /HARD2/FILES/WORDPROC/MYAWPFILE
Full Pathname = /HARD1/APPLEWORKS5/AW5LAUNCHER
Full Pathname = /HARD1/APPLEWORKS5/APLWORKS.SYSTEM
--------------------------------------------------------------
OK,
1. From AW5LAUNCHER an MLI GET_PREFIX call should return the Prefix of
the file selected from Bitsy Bye to open;
[result = /HARD2/FILES/WORDPROC/ ]
(off topic -- where in memory does ProDOS (not BASIC.SYSTEM) actually
store this Prefix?)
2. $280+ also contains the Prefix of the file selected from Bitsy Bye to
open;
[result = /HARD2/FILES/WORDPROC/ ] {same result as in #1}
3. $2006+ contains just the name of the file to open;
[result = MYAWPFILE ]
4. AWLAUNCHER can then extract *its* PREFIX from the $380 full pathname
in order to move it to $280 as APLWORKS.SYSTEM requires.
[result = /HARD1/APPLEWORKS/APLWORKS.SYSTEM (from which AWLAUNCHER will
remove APLWORKS.SYSTEM]
If I've misunderstood how you plan this to work, please set me straight.
I understand that location $380 may change.
And with advance apologies to the ca65 guys, this source is in Merlin.
Old habits and all. ;-)

.

Post by Hugh Hood
1. From AW5LAUNCHER an MLI GET_PREFIX call should return the Prefix of
the file selected from Bitsy Bye to open;
[result = /HARD2/FILES/WORDPROC/ ]

Yes, as long as BASIS.SYSTEM did not alter the prefix (which it shouldn't IMO).

Post by Hugh Hood
(off topic -- where in memory does ProDOS (not BASIC.SYSTEM) actually
store this Prefix?)

$D700-$D741: Pathname buffer (first path char at $D700)
$D742-$D7BF: Clock driver
$D7C0-$D7FF: Prefix buffer (last pfx char at $D7FF)

Post by Hugh Hood
2. $280+ also contains the Prefix of the file selected from Bitsy Bye to
open;
[result = /HARD2/FILES/WORDPROC/ ] {same result as in #1}

Yes, but ideally, BASIS.SYSTEM would load the SYS file associated with the selected data file at $2000, move the selected file name from $280 into $2006, then place the full path of the SYS file at $280 to meet the ProDOS 8 tech ref specs.

Post by Hugh Hood
3. $2006+ contains just the name of the file to open;
[result = MYAWPFILE ]

Yes, unless BASIS.SYSTEM chooses to do a ProDOS GETPREFIX, write the prefix to $2006 and then append the selected filename from $280 to make a full prefix at $2006.

Post by Hugh Hood
4. AWLAUNCHER can then extract *its* PREFIX from the $380 full pathname
in order to move it to $280 as APLWORKS.SYSTEM requires.
[result = /HARD1/APPLEWORKS/APLWORKS.SYSTEM (from which AWLAUNCHER will
remove APLWORKS.SYSTEM]

$380 contains the full path to BASIS.SYSTEM. This must be a full path because the prefix is set to the dir of the selected file. However, this 'full path' is always the root, so it's really just the volume name with BASIS.SYSTEM appended.
If your AWLAUNCHER <is> BASIS.SYSTEM, in the root directory, then $380 is what you want for a full pathname. If your AWLAUNCHER is in a subdirectory and will be called by BASIS.SYSTEM in the root, then you can have BASIS.SYSTEM set things up however you'd like, including putting full-pathnames at $280 and $2006.
-JB
@JBrooksBSI

John,

You and Hugh are using different BASIC.SYSTEM/BASIS.SYSTEM systems. Is yours a typo?--Or is there a real difference here?--And, if so, what is the difference?

James Davis

[John Brooks]

Post by i***@gmail.com
Hrm. That seems problematic from a maintenance perspective. If BASIS.SYSTEM is upgraded you lose your configured mapping unless you remember to find your mapping text file and run the tool. (Which is likely something you did years ago and forgot about...) Similarly, it means the BASIS.SYSTEM file on its own can't be copied about/shared.
On the flip side, it avoids the obvious alternative of cluttering the top level directory with a separate FILETYPEMAP TXT file. But... given the pros/cons I think I'd lean towards the separate file (which means BASIS.SYSTEM needs to parse it at runtime).
Allow comments / blank lines, please!

Post by John Brooks
$04=/HD/Util/TextView.system

Support common type string aliases (SYS, BAS, BIN, TXT, etc - the ones ProDOS shows in CAT) ? Although this could just be provided by a standard comment header that gives them.

Post by John Brooks
$06=/HD/Util/BigBin.system
$19-$1B=/HD/Apps/Appleworks/Aplworks.system
$50-$CF=/HD/Util/ToFinder.system
$F1-$F4=/HD/DOS3.3.LAUNCHER
$FA=/HD/IntBasic.system
$00-$FF=/HD/Basic.system

Is SYS $FF overridable? (what would that mean?)

Post by John Brooks
Thoughts?

Behavior when the target SYS is not present? e.g. show a helpful error, wait for keypress, QUIT
Behavior when the type is unknown - just beep/QUIT as today?

If BASIS.SYSTEM is upgraded, then the mapping text file could be reprocessed with the new tool & new BASIS template to generate an upgraded BASIS.SYSTEM. If the original text file is lost, it could probably be recreated from the binary blob inside the old BASIS.SYSTEM.

I think of it like linux device-tree descriptors that are compiled into .dtb binary blobs which can then be dumped back to source text.

Post by i***@gmail.com
Similarly, it means the BASIS.SYSTEM file on its own can't be copied about/shared.

I'm not sure that copy/sharing of a mapping config would be that useful (ie, work correctly) since it would require the destination drive to have the same SYS files in the same directories as the source drive.

Post by i***@gmail.com
On the flip side, it avoids the obvious alternative of cluttering the top level directory with a separate FILETYPEMAP TXT file.

I was thinking more about launch speed. ProDOS is pretty slow opening files & directories, particularly on 5.25, 3.5, & smartport drives on the //c. Keeping the launch process to a single shim file (BASIS) of only a few blocks, means the launch delay will (hopefully) be tolerable.

For a non-SYS file, there are at least 3x more loads than launching a type $FF system file:
1) Bitsy Bye loads BASIS
2) BASIS loads SYS file
3) SYS file inits and loads selected file

Post by i***@gmail.com
Allow comments / blank lines, please!
Support common type string aliases

Sure. The good thing about having a separate tool generate a binary blob is that the source text syntax can be more flexible and evolve without increasing the size of BASIS or slow down the launch speed.

Post by i***@gmail.com
Is SYS $FF overridable? (what would that mean?)

Not with the current ProDOS & apps. The only way I can think of to customize the launch of SYS files is to have a 'launch file' MLI command added to ProDOS, then modify apps to use the new MLI command.

Post by i***@gmail.com
Behavior when the target SYS is not present?
Behavior when the type is unknown - just beep/QUIT as today?

The mapping file could include a default launcher (GS/OS Finder or Basic.system) that was used if the mapped SYS path gives an error.

-JB
@JBrooksBSI

[Oliver Schmidt]

Hi,

[...]

Post by John Brooks
5) Copy the SYS file pathname to $0280 per ProDOS 8 tech ref spec

[...]

Post by John Brooks
7) Load SYS file at $2000

[...]

Post by John Brooks
Thoughts?

You for sure know the details better than me but maybe it would be
prudent to do 5) after 7) in order to avoid interference with real
time clocks writing to $200 on ProDOS calls.

Regards,
Oliver

[Oliver Schmidt]

Hi,

Post by John Brooks

Post by i***@gmail.com
What is your vision for maintaining the file/aux type mapping for launching applications via BASIS.SYSTEM? Has any progress or further thought happened here?

I'm not sure what techniques GS/OS 6.0 Finder uses for managing and mapping file/aux types, and whether it is worth trying to use or mimic parts of that system.

The GS/OS 6.0 Finder uses icon files. The finder searches for icon
files in a folder named 'Icons' on every mounted volume.

The major purpose of icons files is to provide a graphic
representation (aka icon) for documents of a certian "type". But
beside that graphic representation icon files contain the absolute
path to the program to open documents of that type.

One icon file can contain the information of many document "types". A
document "type" is defined by a tuple of
- filename mask
- file type
- aux type

There are graphical editors to edit such icon files. On
http://www.whatisthe2gs.apple2.org.za/icon-mania/ there's a screenshot
of such an icon editor showing the dialog to edit the document type
definition and program to load documents of that type -
Loading Image...

If the program given for a document type is a ProDOS 8 program and the
user opens a document of that type the Finder switches to ProDOS 8 and
starts the program in question using the ProDOS 8 startup file
protocol to provide the document path to the program. So from my
perspective it's the very functionality we're looking here to provide
for ProDOS 8.

John already stated that he sees two repesentations for the
file/aux-type-to-program-mapping:
1. An internal representation being part of the BASIS.SYSTEM file
optimized for quick access.
2. An external representation in a separate file.

All this leads me to the proposal of using a GS/OS Finder icon file as
this external representation. The file format is fully documented -
http://www.gno.org/pub/apple2/doc/apple/filetypes/ftn.ca.xxxx

I suggest to put all mappings relevant for BASIS.SYSTEM in a single
icon file with the fixed name 'Icons/ProDOS.icons'. It's not uncommon
to use the plural if there are multiple icons in an icon file.

I propose a ProDOS 8 text mode program that is able to read and write
this very file. The program is an interactive editor for the mappings
in that file. Additionally the program allows to export the mappings
to BASIS.SYSTEM.

That ProDOS 8 program doesn't care at all about the actual icon being
part of each mapping created. Rather it just uses the same icon for
all mappings in ProDOS.icons. That single icon is part of the program
itself and identical to the GS/OS icon for ProDOS and BASIC.System,
see -
Loading Image...

Of course the user is free to alternatively use a GS/OS based
graphical icon editor to edit ProDOS.icons in just the same way he
would edit other icon files. This way he could create individual icons
for the mappings. Such a user would then use the ProDOS 8 text mode
program only for reading ProDOS.icons and exporting the mappings to
BASIS.SYSTEM.

Anyway, with this approach any mapping created for BASIS.SYSTEM would
automatically be used in the very same way by the GS/OS 6.0 Finder
too.

If there's a momentum to welcome this proposal I'm willing to
contribute the ProDOS 8 program described. I'd create it using the
cc65 C compiler.

I'm in contact with John regarding this topic so the ProDOS 8 program
would be delivered together with BASIS.SYSTEM.

Please provide feedback!

Regards,
Oliver

[i***@gmail.com]

This sounds reasonable to me.

I'm far enough along in the disassembly of Apple II Desktop to understand how file launching works (so... many... layers...) and while ideally the logic could be built in, it is likely that chaining to BASIS.SYSTEM will be necessary or just as efficient - there isn't enough room available without swapping a code overlay in.

Having a well-defined external format leaves the possibility open for the future; swapping an overlay in *would* allow for the code to signal failure on unknown types rather than requiring a reload of the whole A2D shebang. (Code overlays are already used for a handful of less common operations, and if a "Slinky" RamDisk is available will be loaded from that, so it isn't too horrible...)

[i***@gmail.com]

Post by i***@gmail.com
I'm far enough along in the disassembly of Apple II Desktop to understand how file launching works (so... many... layers...) and while ideally the logic could be built in, it is likely that chaining to BASIS.SYSTEM will be necessary or just as efficient - there isn't enough room available without swapping a code overlay in.

Hrm... I take that back. Right now there's probably room to squeeze a simple parser into the main chunk of A2D logic (which includes the open action handler) without an overlay. There isn't room to do everything in the "invoker" code that then gets called which actually loads/invokes the next program (BIN/SYS/S16 or BAS via BASIC.SYSTEM) since that squeezes into $160 bytes down around page 2/3 to free up most of main memory, but the initial logic could pass the name of the "interpreter" file along if it isn't one of the known types.

(This is all a bit off topic, but this *is* the use case that made me kick off the thread. If anyone is interested in further progress on deconstructing A2D, let me know...)

But anyway: again, Oliver's proposal sounds good to me.

[John Brooks]

Post by i***@gmail.com

Post by i***@gmail.com
I'm far enough along in the disassembly of Apple II Desktop to understand how file launching works (so... many... layers...) and while ideally the logic could be built in, it is likely that chaining to BASIS.SYSTEM will be necessary or just as efficient - there isn't enough room available without swapping a code overlay in.

Hrm... I take that back. Right now there's probably room to squeeze a simple parser into the main chunk of A2D logic (which includes the open action handler) without an overlay. There isn't room to do everything in the "invoker" code that then gets called which actually loads/invokes the next program (BIN/SYS/S16 or BAS via BASIC.SYSTEM) since that squeezes into $160 bytes down around page 2/3 to free up most of main memory, but the initial logic could pass the name of the "interpreter" file along if it isn't one of the known types.
(This is all a bit off topic, but this *is* the use case that made me kick off the thread. If anyone is interested in further progress on deconstructing A2D, let me know...)
But anyway: again, Oliver's proposal sounds good to me.

.

Post by i***@gmail.com
(This is all a bit off topic, but this *is* the use case that made me kick off the thread. If anyone is interested in further progress on deconstructing A2D, let me know...)

I'm interested in your A2D progress and planned roadmap.

I'd like to coordinate with anyone working on file utilities or big ProDOS apps as I've been working on various ProDOS 2.5 improvements that will likely be valuable.

-JB
@JBrooksBSI

[Hugh Hood]

Post by Oliver Schmidt
I suggest to put all mappings relevant for BASIS.SYSTEM in a single
icon file with the fixed name 'Icons/ProDOS.icons'. It's not uncommon
to use the plural if there are multiple icons in an icon file.
Anyway, with this approach any mapping created for BASIS.SYSTEM would
automatically be used in the very same way by the GS/OS 6.0 Finder
too.
Please provide feedback!

Oliver,

I think you have a very solid idea there for mapping files to
applications, as it's both functional and compatible. A text-based P8
icon editor sounds good, too.

Moreover, the Icon spec allows for '*' to be used to specify the boot
volume, which can be a big help in certain circumstances.

I hope JB seriously considers your proposal, although I'm not smart
enough to predict what he may already have up his sleeve.





Hugh Hood