[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Need Help with DOS 3.3 Launcher Launcher
- Subject: Need Help with DOS 3.3 Launcher Launcher
- From: rdippold@qualcomm.com (Ron "Asbestos" Dippold)
- Date: 30 May 94 02:36:10 GMT
- Followups-to: comp.sys.apple2.programmer
- Newsgroups: comp.sys.apple2.programmer, comp.sys.apple2
- Organization: QUALCOMM, Incorporated; San Diego, CA, USA
- Xref: bga.com comp.sys.apple2.programmer:1126 comp.sys.apple2:6618
I'm diving right back into Apple programming... amazing how much you
remember.
Since I got a lot of positive responses, I've modified my FastBoot
ProDOS 8 launcher so that it supports DOS 3.3 Launcher as well as SYS
and BIN files. You can put ProDOS 8, FastBoot, and D3L on a disk in
about 50 blocks, then put disk images on the rest of the disk and have
a bootable set of DOS 3.3 images that doesn't rely on GS/OS or the
Finder being there. When you select a DOS 3.3 Launcher Image,
FastBoot loads D3L, passes it the name of the image, then jumps to it.
I'll release it next week if I don't hear anything on the following.
Next I'll be working on an LZSS compressor for the disk images, which
will unpack to /RAM5 or hard disk and then run. 2:1 compression
doesn't seem too far out of the question on many images.
Now, on to the programming part, note the followups to csa2.programmer.
Works beautifully, but there's one gotcha - Apparently the D3L author
(John? I don't have the docs here at the moment) never thought anyone
would be crazy enough to run it without booting GS/OS first, and that
everyone would use the finder. If you boot directly into ProDOS 8,
D3L tries to allocate memory for its CDA and fails with an out of
memory error. It works fine if you launch P8 from GS/OS, but FastBoot
breaks that assumption if you boot right into ProDOS 8.
Currently I "fix" things by patching the image of D3L in memory, so
that if the memory allocation fails it simply doesn't load the CDA and
continues on. Everything works as it should, but there's no CDA.
There's no 16-bit launcher to exit to in this case, so having to
Ctrl-Reset out isn't a big deal. However, FastBoot then has to do the
control panel changes for speed and keyboard buffering, since D3L
assumes the CDA will be there to clean up after it, and it isn't in
this case.
I'm going to mail the author (but forgot to bring the docs today,
@#$!), but if we can't figure something out (and it may turn out the
CDA needs GS/OS to be loaded first to even work), I need some help.
FastBoot works great with D3L in current state, but I'd like to be
able to let D3L load that CDA and not do the control panel setup in
FastBoot (why duplicate the effort?). Does anyone have some code that
shows what a program needs to do after a cold boot into ProDOS 8 to
make the memory manager happy? Simply calling the Init toolset
function doesn't seem to be it.
I know it should be possible, because I've seen ProDOS 8 programs that
load CDAs, but I don't know if they're cheating or if they're actually
setting up the memory manager correctly.
--
Bigamy is having one spouse too many. Monogamy is the same.