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

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

Hi Toinet,

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

I see.

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

I see.

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

I see. For "inserting" another ,dsk image "into a drive" while running
DOS 3.3 (or whatever).

I can very well imagine scenarios (i.e. games prompting to swap disks)
where this would be desirable. Maybe one could add an option to the
menu like "forward RESET to DOS 3.3" ?!?

On the other hand there will surely be scenarios (i.e. really running
DOS 3.3) where the user would prefer RESET to just work "normally" and
have something like CALL -17000 to go to the menu.

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

I see.

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

Do those games use the DOS 3.3 RWTS in a way compatible to what we're
discussing here? And do they spare the language card? If the answer to
one of the two questions is 'no' then they don't count for your
argument - do they?

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

It's in general easy: Any interpreter for ProDOS (in the sense of a
SYS file like BASIC.SYSTEM) has nearly 48kB available. But many
scenarios to be considered here need 64kB available.

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

- You're certainly right in what we're discussing here is certainly
far from mandatory.

- I in general follow you to say: "I'm not willing to implement tricks
or hacks just to get a certain title running". It's just that I feel
that your approach will mean quite some compromises regarding things
like i/o vectors, zero page usage, page 3 vectors, page $BF patches,
.. while mine approach circumvents all these without any special
effort.

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

That seems like an implementation detail to me. You need to calculate
an offset into 140kB of RAM. The very same offset can go into the
SET_MARK MLI call.

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

Hm, I'm still wondering if there's a misunderstanding. I'm not arguing
in any way to rewriting an OS.

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

There must be a misunderstanding. My idea is to
- unhook /RAM
- copy
  - Zero Page
  - Page 3
  - Page $BF
  - All language card RAM (bank 1 and bank 2)
  from MAIN to AUX
and that all!

My expectation is that I don't have to change/patch/fix a single byte
in the ProDOS (whatever version) currently running!

As long as ProDOS only accesses Disk II drives and/or Smartport drives
with appropriate ROMs ProDOS has no reason to play with softswitches -
and to my experience it in fact doesn't. So I expect ProDOS MLI to run
as-is from AUX.

And if the user is done with his DOS 3.3 (or whatever) the steps above
should be reversable ending up with ProDOS back in MAIN. The only
"unclean" thing is that my idea uses the AUX language card officially
reserved by ProDOS.

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

- There are assembly programs written to use the DOS 3.3 RWTS or DOS
3.3 file manager which were never ported to ProDOS.
- There are BASIC programs not compatible with ProDOS BASIC.SYSTEM.

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

These statements hold true for my idea all the same. It's just that I
think the overlapping use of the zeropage and page $BF by RWTS and
ProDOS are already reasons enough to keep them in two seperate banks. 

But apart from that: Beside doing it because it can be done, what
would you want to archive with the RWTS interpreter if it can't be
used by DOS 3.3? I'm pretty sure that every other RWTS user is less
"compatible".

I see beside DOS 3.3 mostly cracked games as RWTS users. I've seen
quite a lot of them consisting of (close to) 48kB of RAM content. But
how to get this content from the disk back into RAM? Use DOS 3.3 RWTS
and the content that belongs where RWTS itself resides is loaded
temporarily into the language card and then moved over RWTS after the
loader is done with RWTS.

Or the game loader requires RWTS (or the whole DOS 3.3) to be moved
into the language card in order to load (close to) 48kB right to the
final RAM locations.

If all this doesn't matter to you what use case do you have in mind?

>Quite close but the platform (and thus the approach) is different.

Maybe this somewwhat justified now (?)

>That is a good start :-)

:-)

Regards,
Oliver