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

[Toinet <antoine.vignau@laposte.net>]

Hello There,

On 6 juin, 10:18, ol...@web.de (Oliver Schmidt) wrote:
> 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.

I fully agree and I a getting white hair now :-)

>
> >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).

I meant: "load the entire disk image into memory starting at bank $2"

>
> >- start the program in $B700
>
> Me too. So I presume your idea is identical to mine.

Yes, and put #$60 in X :-)

>
> >The requirements
> >- rewrite of the $BD00..$BFxx (xx is important) area. $B800..$BCC
> >would be of no use
>
> Would you mind to elaborate?

Sure. If you rewrite the $B700..$BFFF code and want to keep
compatibility with ProDOS, I also consider that READ is mandatory to
include but WRITE and FORMAT are not. That leaves room in that area
for coding the RWTS interpreter and probably the ProDOS file buffer
(see later, the $400 bytes buffer)

>
> >- 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.

DOS 3.3 or not DOS 3.3, that is the question. Your remark is the first
where we probably diverge (but I don't say I dislike your ideas
though :-) - I see a RESET as the way to go back to the main menu
where you select an image to launch it.

>
> >- 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 ?!?

Yes, I see them live in the same bank. My idea is a "RWTS interpreter
for ProDOS", yes, that's the right expression :-)

>
> >- 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.

Auto-detection? What a big word it is! Just kidding!

>
> >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.

The number of programs using DHGR under DOS 3.3 is probably close to
0. The number of programs using DHGR in a disk image format (.DSK) is
probably around 10 (some Epyx programs, some DataEast games, TBC)

>
> >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.

That's where (and later with language card) my 8-bit knowledge and
interest stop me. Even with schemes and other drawings, my
understanding of that weird Apple II memory limits my skills.

I base my "project" (ahem) on the following idea: "have a disk image
loader and player (let's say, launcher) under ProDOS" - I won't mind
nor care if a program does not run. WIth todays' emulators or real
Apple IIs, that "project" is not mandatory, correct me if I'm wrong.

>
> >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?

See above. On a IIgs, you would load the entire image in memory and
deliver the right track/sector really easily instead of browsing
through a ProDOS file.

>
> >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...

OK. I understand where we diverge:
- You say ProDOS has to be adapted
- I say, ProDOS is the standard.

I understand your idea but I do not share the goals. I don't want in
2010 another rewrite of an OS just to support the few programs (just
like you with DHGR) that are either X, Y or Z (replace with your
examples above) - In 2010, we have emulators and others cards that
make me believe that I want a simple image reader (just like an
iDisk :-) - As usual, my thought is for discussion.

If you really want to go into it, I can either show the ProDOS 1.0
source code or the 2.0.3 version but I don't believe it is a good idea
for a stable software to be rewritten to take care of the old DOS 3.3.

I must be honest, I don't like DOS 3.3 (compared to ProDOS :-) I don't
understand why one still wants to use it in 2010 (or let's say,
starting from 1984)

>
> 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?

Use ProDOS as the mandatory layer, rewrite the RWTS and that's it. If
that may support DOS 3.3, then that's perfect.

>
> 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?

Probably when your project is concerned, with mine, it is not :-) See
above.

>
> >I am adding a IIgs version to my to-do list, target date is "when
> >ever" :-)
>
> Maybe synegery effects between our to-do lists?

Quite close but the platform (and thus the approach) is different.
That is a good start :-)

>
> Regards,
> Oliver

Regards,
antoine