Re: Any way to run .DSK images -directly- on Apple // ?

[ol.sc@web.de (Oliver Schmidt)]

Hi Toinet,

>That thread reminds me of a (very) old wish of Olivier Zardini to have
>a program to launch "DOS 3.3" disk images. He asked me to write that
>piece of code around 1993 but I saw no interest in it at that time.

Yes, times have changed. The type of software we're discussing here
doesn't seem rocket sience. It's just that by the time many people
wrote stuff for the Apple2 it wasn't interesting - and now not many
people are left being able to write it.

>The principle was simple:
>- launch a ProDOS SYS file

Ok.

>- display a menu of all the images contained in a IMAGES directory
>(just to bypass the 51 files limit of the root folder)

Good idea.

>- select an image

Ok.

>- load it into the IIgs memory (safely with the Memory Manager :-)

What are you refering to with "it"? My idea is to load 'BOOT 2' into
$B700 - $C000 (just presuming a 64k salve disk).

>- start the program in $B700

Me too. So I presume your idea is identical to mine.

>The requirements
>- rewrite of the $BD00..$BFxx (xx is important) area. $B800..$BCC
>would be of no use

Would you mind to elaborate?

>- patch the RESET vector each time the RWTS is called and let it point
>to a ProDOS QUIT MLI code

Why? AFAIK the hardware does reset the softswitches to MAIN on RESET -
and there everything is setup by DOS 3.3 nicely. And btw. I wouldn't
want RESET to behave differently from running "pure" DOS 3.3.

>- save zero page variables used by ProDOS
>- pay attention to the DOS 3.3 patches (if DOS 3.3 is used) in the
>$BFxx..$BFFF area. See now why the xx was important? It is used by
>ProDOS

You seem to see DOS 3.3 and ProDOS 8 living in the same bank ?!?

>- handle the READ/WRITE/FORMAT RWTS calls

Ok.

>- do the magic, keeping into mind the different interleaving (if
>useful) between ProDOS and DOS 3.3, as well as the length of a sector
>vs the length of a block

Ok. At least for the initial code my idea is to just presume a DOS
3.3. ordering .dsk image. Maybe later support for .po images and/or
some autodetection. Such an autodection wouldn't limit the usefulness
as the existence of RTWS is in general obligatory anyway.

>From what I understand from Oliver's recent proposal and the use of
>AUX RAM is that DHGR games would not be supported unless the cache is
>above $6000.

I don't have an overview on the popularity of DHGR for DOS 3.3 (or at
least DOS 3.3 RWTS) based games. If there's a need one would need a
way to disable use of AUX $2000-$6000.

>Furthermore, there are disk images that use the AUX RAM to save data
>(e.g. sprites or code) - I know such a program would not allow all of
>the disk images to be played but as we have no memory protection
>scheme, I believe we can't assume having a reliable cache in AUX RAM
>and therefore it should not be used.

My idea is _not_ try to sqeeze the necessary code into the RWTS area
but only place a hook there as small as possible and keep the major
code part in AUX. The goal of this approach is compatibility with
- DOS 3.3 clones which use parts of RWTS code space for their fastload
patches
- DOS 3.3 (clones) moved into the MAIN language card

So what I have in mind would certainly be not compatible with code
using much/most/all of AUX, but
- I don't see broad AUX usage being popular for DOS 3.3 based games.
- One could find a way to disable caching limiting the amount of AUX
memory used greatly.

>I also know that a IIgs version
>would restrict its use to IIgs owners :-)

Could you elaborate what would be done differently on a IIgs version?

>As the access is performed through a file image then ProDOS requires a
>buffer area of $400 bytes, memory usage would be tight in the RWTS
>area $B700..$BFFF therefore the RWTS code would need to be really
>optimized.

My initial idea was similiar to what you (seem to) describe. But then
I noticed that both the $400 byte area and the necessary code would
really hardly fit - as you say. But then I noticed that many DOS 3.3
games make use of the language card in one or another way. So I
understood that the sweetspot for the tradeoff between
software-compatibility and hardware-requirements for sure is rather

- Compatible with DOS 3.3 programs using the language card
- Compatible with DOS 3.3 moved into the language card
- Compatible with heavily patched DOS 3.3 clones
- Require a 128kB machine

and so I went for the ProDOS-moved-into-AUX approach...

Unfortunately I don't know much about the IIgs memory but in a very
general view a IIgs has at least the memory and and options of an
extended //e. So I'm wondering why you seem to think about a
coexistence of DOS 3.3 and ProDOS 8 in the same bank - or do I miss
some point completely?

When I don't misunderstand you than you are concerned about
compatiblity with DOS 3.3 programs using AUX. But isn't it way more
important to be concerned about DOS 3.3 programs using the language
card?

>I am adding a IIgs version to my to-do list, target date is "when
>ever" :-)

Maybe synegery effects between our to-do lists?

Regards,
Oliver