Discussion:
Thoughts: 8-bit version of LAUNCHER
(too old to reply)
Steve Nickolas
2017-07-28 09:53:53 UTC
Permalink
It was a stupid idea last time I suggested it, but the idea of lots of
people having large amounts of flash storage in their //es and a ton of
programs to run from it wasn't really around then.

Dunno if you remember the LAUNCHER from ProDOS-16:
Loading Image...

My idea is to implement the same interface using the 280x192 graphics
mode, and on 8-bit ProDOS.

-uso.
Mark D. Overholser
2017-07-29 00:59:21 UTC
Permalink
Post by Steve Nickolas
It was a stupid idea last time I suggested it, but the idea of lots
of people having large amounts of flash storage in their //es and a
ton of programs to run from it wasn't really around then.
https://i1.wp.com/apple2history.org/wp-content/uploads/2010/06/System-1.0-Launcher.jpg?ssl=1
My idea is to implement the same interface using the 280x192 graphics
mode, and on 8-bit ProDOS.
-uso.
I have thought about that too...

For ALL the Extra RAM, it would be nice to have a simple Memory Manager
to allocate space for a RAM Disk, and Different OS/Applications and a
Manager to Switch between them...

Future Applications could be designed to recognize the Memory Manager
and allocate memory as needed...


The Launcher could stay Resident, in RAM...

MarkO
Steve Nickolas
2017-07-29 03:40:51 UTC
Permalink
For ALL the Extra RAM, it would be nice to have a simple Memory Manager to
allocate space for a RAM Disk, and Different OS/Applications and a Manager to
Switch between them...
Future Applications could be designed to recognize the Memory Manager and
allocate memory as needed...
Well, there's rumors of a better vdisk driver in future releases of
ProDOS-8...
The Launcher could stay Resident, in RAM...
I would at *least* keep a stub, which could load the rest of the Launcher.
Perhaps on a GS or system with more than 128K I would keep the whole
thing.

Switching OSes wouldn't be necessary; programs are being ported to ProDOS.

-uso.
g***@sasktel.net
2017-07-29 05:20:25 UTC
Permalink
Post by Steve Nickolas
Post by Mark D. Overholser
The Launcher could stay Resident, in RAM...
I would at *least* keep a stub, which could load the rest of the Launcher.
Perhaps on a GS or system with more than 128K I would keep the whole
thing.
Switching OSes wouldn't be necessary; programs are being ported to ProDOS.
-uso.
I guess I don't have the same vision, as I don't see how this differs much with the BYE command which can call a file selector?

This way also gives full memory access to the programs that need it, such as Appleworks. With a memory manager and a stub for the Launcher would take away from that.

By also switching between programs in memory, all the data for each program would need to be temporarily saved to disk. At least this would benefit as a backup during a computer crash.

Maybe a type of virtual memory could also be useful. I have been working, off and on, on trying to use a var file as a means of saving strings that can be accessed virtually (or randomly) without the cumbersomeness of a random access file or a VAR file.
g***@sasktel.net
2017-07-29 05:22:16 UTC
Permalink
Post by g***@sasktel.net
I guess I don't have the same vision, as I don't see how this differs much with the BYE command which can call a file selector?
Didn't mean to save "differs" as it does differ quite a bit, I meant to say "benefits over the BYE command".
Michael J. Mahon
2017-07-29 06:21:11 UTC
Permalink
Post by g***@sasktel.net
Post by Steve Nickolas
Post by Mark D. Overholser
The Launcher could stay Resident, in RAM...
I would at *least* keep a stub, which could load the rest of the Launcher.
Perhaps on a GS or system with more than 128K I would keep the whole
thing.
Switching OSes wouldn't be necessary; programs are being ported to ProDOS.
-uso.
I guess I don't have the same vision, as I don't see how this differs
much with the BYE command which can call a file selector?
This way also gives full memory access to the programs that need it, such
as Appleworks. With a memory manager and a stub for the Launcher would
take away from that.
By also switching between programs in memory, all the data for each
program would need to be temporarily saved to disk. At least this would
benefit as a backup during a computer crash.
Maybe a type of virtual memory could also be useful. I have been
working, off and on, on trying to use a var file as a means of saving
strings that can be accessed virtually (or randomly) without the
cumbersomeness of a random access file or a VAR file.
Try using a binary file and BASIC.SYSTEM. You can use BLOAD and BSAVE with
B and L parameters to access any region of the file.

Of course, it OPENs and CLOSEs the file on each access, so performance
isn't its strong suit, but it's a great tool for prototyping or
applications for who's speed is less critical than making them possible.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Nick Westgate
2017-07-29 03:17:52 UTC
Permalink
My thoughts are that there is a lot of screen space wasted by Launcher, the content we want is text, and using a mouse is unnecessary, and in fact an inconvenience.
Post by Steve Nickolas
My idea is to implement the same interface using the 280x192 graphics
mode, and on 8-bit ProDOS.
Have you seen FastBoot 3.4 by Ron Dippold? It's on Alex Lee's 32MB hard drive image of 8-bit games.
http://www.whatisthe2gs.apple2.org.za/files/8-bit_Games.zip

It's pretty good, and uses most of the screen to display system files, binary files, and folders, and assigns each of them a key on the keyboard.

It could be improved though. It still gets a bit fiddly navigating the many folders in large hard drives. I think it would be better if FastBoot (or a new app) used the whole screen for selecting one type of content rather than squeezing them all onto the screen in 3 columns.

Cheers,
Nick.
Steve Nickolas
2017-07-29 03:45:13 UTC
Permalink
Post by Nick Westgate
My thoughts are that there is a lot of screen space wasted by Launcher,
the content we want is text, and using a mouse is unnecessary, and in
fact an inconvenience.
Well, it is unnecessary. The arrows can navigate the file list; ESC for
close, Enter for open, Tab for disk, Cmd-Q for quit. (I'd still support a
mouse if one were installed.)
Post by Nick Westgate
Have you seen FastBoot 3.4 by Ron Dippold? It's on Alex Lee's 32MB hard drive image of 8-bit games.
http://www.whatisthe2gs.apple2.org.za/files/8-bit_Games.zip
Requires a GS. My idea would work on an Integer ][, in theory.

-uso.
Nick Westgate
2017-07-29 10:22:14 UTC
Permalink
Post by Steve Nickolas
Post by Nick Westgate
Have you seen FastBoot 3.4 by Ron Dippold? It's on Alex Lee's 32MB hard drive image of 8-bit games.
http://www.whatisthe2gs.apple2.org.za/files/8-bit_Games.zip
Requires a GS. My idea would work on an Integer ][, in theory.
Blink. No it doesn't require a GS. That would be silly for a HD of 8-bit games.

Cheers,
Nick.
Nick Westgate
2017-08-02 23:16:29 UTC
Permalink
Post by Nick Westgate
Post by Steve Nickolas
Requires a GS. My idea would work on an Integer ][, in theory.
Blink. No it doesn't require a GS. That would be silly for a HD of 8-bit games.
Heh, I wish you had pushed back on this!

*MY* copy of the HD image works fine.

*Alex* has still not deleted the "P8CDA.SYSTEM" file which prevents the HDV from booting on 8-bit systems. I told him a year ago, and I've just emailed him again.

Anyway, FastBoot 3.4 requires an enhanced //e etc - presumably for mousetext.

A new Launcher which worked across all 8-bit machines would be a great addition, and I only suggested FastBoot as another source of inspiration.

Cheers,
Nick.
Polymorph
2017-08-03 01:34:48 UTC
Permalink
Post by Nick Westgate
Post by Nick Westgate
Post by Steve Nickolas
Requires a GS. My idea would work on an Integer ][, in theory.
Blink. No it doesn't require a GS. That would be silly for a HD of 8-bit games.
Heh, I wish you had pushed back on this!
*MY* copy of the HD image works fine.
*Alex* has still not deleted the "P8CDA.SYSTEM" file which prevents the HDV from booting on 8-bit systems. I told him a year ago, and I've just emailed him again.
It's funny, I nearly pushed back because I remember when I had tried running the image from WITA2GS on either my //c or //e was that the actual error was "Requires a IIgs", but it had been a month or two since trying it and I didn't want to look stoopid if I was mis-remembering. ;-)

Cheers,
Mike
Nick Westgate
2017-08-03 03:31:12 UTC
Permalink
Post by Polymorph
It's funny, I nearly pushed back because I remember when I had tried running the image from WITA2GS on either my //c or //e was that the actual error was "Requires a IIgs", but it had been a month or two since trying it and I didn't want to look stoopid if I was mis-remembering. ;-)
Fair enough. I'm surprised I didn't remember that error, because it's completely unexpected for a collection of 8-bit software!

Instead, I only remember successfully running it on a //e, forgetting that I had to delete that file to do it. ; - )

The image is apparently based on "The Definitive File Game Library" by "Captain Sensible - Shiftr Shiftr - The Screamer - Two Knives Tan" from 1988.

They note: "The Definitive File Game Library will only work on the Apple IIgs."

I wish they'd elaborated on what they did, because most of the games work fine on a //e. Some don't and I'd like to know why. Another project to file away for a rainy day!

Cheers,
Nick.
qkumba
2017-08-03 16:28:59 UTC
Permalink
They might have used a wrapper that required another memory bank in order to have most free memory available for the game itself.
There were several games wrapped like this (including one of the Lady Tut versions on Asimov).
qkumba
2017-08-03 16:30:37 UTC
Permalink
Regarding Alex's image, he notes on his site: "That message is only describing that 8-bit Apple IIs can't load the P8CDA application, which enables CDAs to be loaded on a IIGS without booting ProDOS 16 or GS/OS. For 8-bit users, simply delete the P8CDA executable (which enables useful CDAs on the IIGS, but doesn't for the IIe or IIc) and the message will not display again".
Nick Westgate
2017-08-05 00:37:50 UTC
Permalink
Regarding Alex's image, he notes on his site[...]
Thanks.

It's frustrating then that P8CDA doesn't just chain to the next SYSTEM file.

Cheers,
Nick.
Alex Lee
2017-08-05 13:15:21 UTC
Permalink
Post by Nick Westgate
Regarding Alex's image, he notes on his site[...]
Thanks.
It's frustrating then that P8CDA doesn't just chain to the next SYSTEM file.
It sure is. I thought I read in its documentation that it would move to
the next SYSTEM file automatically whether or not it's attempted to
load from a IIGS or otherwise. It might have been the Roger Wagner
published version that did this, but I maintained the older shareware
version because the newer P8CDA seems to be incompatible with DOS 3.3
Launcher (hi-res graphics don't display properly).
Post by Nick Westgate
Cheers,
Nick.
Alex Lee
2017-08-05 13:33:30 UTC
Permalink
Post by Nick Westgate
Post by Polymorph
It's funny, I nearly pushed back because I remember when I had tried
running the image from WITA2GS on either my //c or //e was that the
actual error was "Requires a IIgs", but it had been a month or two
since trying it and I didn't want to look stoopid if I was
mis-remembering. ;-)
Fair enough. I'm surprised I didn't remember that error, because it's
completely unexpected for a collection of 8-bit software!
Instead, I only remember successfully running it on a //e, forgetting
that I had to delete that file to do it. ; - )
The image is apparently based on "The Definitive File Game Library" by
"Captain Sensible - Shiftr Shiftr - The Screamer - Two Knives Tan" from
1988.
They note: "The Definitive File Game Library will only work on the Apple IIgs."
I wish they'd elaborated on what they did, because most of the games
work fine on a //e. Some don't and I'd like to know why. Another
project to file away for a rainy day!
Partly true. When I came across the Definitive File Game library files,
I only included them on the image if I couldn't find a single binary
from any other collection to minimise IIGS specificity. From memory, I
thought it might only be a dozen titles. Perhaps another collection I
borrowed from was IIGS specific as well and I wasn't aware of it.

I started compiling this collection as far back as 2012, so I can't
remember the details any better than what I wrote up for it from the
original blog post I released in 2014:
http://www.whatisthe2gs.apple2.org.za/time-out-for-some-8-bit-fun-iigs-style/


I kept in mind that I wanted it to be as 8-bit compatible as possible,
but I never did any testing on real or emulated 8-bit machines. John M
Holmes Jr has taken the image and modified it with a keener eye on
making it work on a IIe. AKAIK you can only find his 32meg image via
the Apple II Enthusiasts Group on Facebook:
https://www.facebook.com/groups/5251478676. If you do a search on 'John
M Holmes Jr' and scroll down, you'll eventually find his most recent
version.

Also, for anyone that's keen to run more stuff from a hard drive, my
most recent effort (thanks to qkumba and Marco Verpelli) has been
taking 3.5" disk versions of 8-bit eduwares and modifying them to run
from a hard drive / large ProDOS volume:

http://www.whatisthe2gs.apple2.org.za/8-bit-eduware-on-32meg-disk-image/

- Alex

Payton Byrd
2017-08-01 13:03:47 UTC
Permalink
Post by Steve Nickolas
It was a stupid idea last time I suggested it, but the idea of lots of
people having large amounts of flash storage in their //es and a ton of
programs to run from it wasn't really around then.
https://i1.wp.com/apple2history.org/wp-content/uploads/2010/06/System-1.0-Launcher.jpg?ssl=1
My idea is to implement the same interface using the 280x192 graphics
mode, and on 8-bit ProDOS.
-uso.
A2Command is already a very effective launcher that just happens to do a whole lot more. It launches any type of A2 binary that ProDOS can launch. One thing it doesn't do is store a profile per executable, but that's an easy to implement feature. And navigating a device doesn't get an easier than it is in A2Command.

http://a2command.codeplex.com/
Loading...