Any way to run .DSK images -directly- on Apple // ?
jeremym
My basement is overrun with Apple // floppies.
I recently purchased and successfully tested the USB -> 5.25 adapter
(FC2025) from deviceside.com.
As suspected.. Some disks make great DSK files, others totally fail.
Let's assume I get 60% made into .DSK files.
Is it possible for me to chuck those .DSK files into the trash heap at
that point?
I want to:
() Run these .DSK files on my real Apple 2.. without having to convert
to REAL FLOPPY AGAIN
and
() Run these .DSK files (as images) on AppleWin on the PC.
I have plenty of "Cardflash / HD" storage on the Apple 2.. so, any
idea of there's a way to:
() Transfer these .DSK files over to the Flashcard "as is"
then
() When on the Apple // have some 'booter program' that will let me
pick a .DSK file and .. BOOT it ! :-)
That's my goal.
Thanks in advance.
-Jeremy M
Michael J. Mahon
> Here's my scenario:
>
> My basement is overrun with Apple // floppies.
>
> I recently purchased and successfully tested the USB -> 5.25 adapter
> (FC2025) from deviceside.com.
>
> As suspected.. Some disks make great DSK files, others totally fail.
>
> Let's assume I get 60% made into .DSK files.
>
> Is it possible for me to chuck those .DSK files into the trash heap at
> that point?
Theoretically, a disk can be apparently copyable, yet the copy/capture
can fail to capture some critical parameter of the original disk that
the program will test--and fail to run. This is particularly true of
disks that use "nibble counts" or "nibble signatures" to cause a casual
copy to fail, while apparently succeeding.
If you know that the disks you have successfully captured are free of
such copy protection, they you are pretty safe in assuming that you
have captured a usable copy.
In the cases where a copy protection *was* used, but not captured,
it is still possible to remove the copy protection from the captured
image, creating a newly "deprotected" image. Unfortunately, this
process is not mechanical, but requires effort and creativity--so much
so that defeating a game's copy protection was much more fulfilling for
many users than playing the game! ;-)
Most copy-protected disks will not be able to be successfully captured
using the FC5025 and its software, so these will be among the 40% that
didn't work.
> I want to:
>
> () Run these .DSK files on my real Apple 2.. without having to convert
> to REAL FLOPPY AGAIN
> and
> () Run these .DSK files (as images) on AppleWin on the PC.
>
> I have plenty of "Cardflash / HD" storage on the Apple 2.. so, any
> idea of there's a way to:
>
> () Transfer these .DSK files over to the Flashcard "as is"
> then
> () When on the Apple // have some 'booter program' that will let me
> pick a .DSK file and .. BOOT it ! :-)
>
> That's my goal.
I think you'll find that there are programs that do what you are
trying to accomplish.
The bigger issue (on the assumption that 40% of "overrun" is still
unacceptable) is how to deal with the remaining 40% of disks.
It is likely that a good fraction of these are copy-protected disks,
as noted above. These disks must, in general, be deprotected to
run correctly.
The remainder of the failing disks may be either recoverable or
irrecoverable. In my experience, the vast majority of "failing"
disks are recoverable unless they are manifestly physically damaged.
One thing to try immediately is cleaning your disk drive--some of
the disks you have attempted to capture may have deposited oxide and
other debris on the drive head, interfering with its ability to read
some disks.
The next thing to try is a different disk drive. Subtle differences
in speed control and alignment may permit many "failing" disks to be
captured.
Yet another fairly easy fix that is applicable to quite a few older
diskettes is to relieve any "binding" between the media and the sleeve.
A gentle attempt to rotate the disk inside the sleeve will often reveal
considerable friction, usually due to the sleeve becoming flattened and
pressing against the disk. This pressure can be relieved by holding the
diskette perpendicular to the edge of a desktop, and sliding the edges
of the sleeve across the edge while pressing gently but firmly, being
careful to avoid any cutouts or places where cutouts come close to the
edge. This will gently deform the edges so that they hold the jacket
out very slightly away from the disk inside. Re-reading the disk will
now often be successful.
Since the process of recovery is somewhat demanding and frequently
requires effort, you must decide how valuable the diskettes are to you,
or whether you'd like to make them available to others to recover.
Of course, since "40% of overrun" is still a large number (and a
lot of recovery effort), prioritization (either yours or other's)
will necessarily be involved...
-michael
NadaNet 3.0 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Bill Garber
"Michael J. Mahon" <mjm...@aol.com> wrote in message news:g_Wdna5NuZAPEmTW...@giganews.com...
Let us remember that many of these copy-protected disks may have
already been de-protected and available in image format on one of
the many web sites carrying such disk images.
Bill
jeremym
"I think you'll find that there are programs that do what you are
trying to accomplish. "
Don't keep it a secret. :-)
What Apple // (compiled) application will enable me to "pick a .DSK"
from a picklist and launch it?
Thanks in advance.
PS: I grabbed only 5 disks to try. I knew some were copy protected and
some were not. My 40% success rate is very un-scientific at this
point.
Michael J. Mahon
> Michael Wrote:
>
> "I think you'll find that there are programs that do what you are
> trying to accomplish. "
>
> Don't keep it a secret. :-)
>
> What Apple // (compiled) application will enable me to "pick a .DSK"
> from a picklist and launch it?
>
> Thanks in advance.
I wasn't just being coy--I never use such programs, and I know that
others here have considerable first-hand knowledge of them. I also
recall that there is a bit of fiddling required that I'm not familiar
with. (I've just never been very interested in computer games. ;-)
Search the group for DOSMASTER, I think, and perhaps another...
Experts on this topic, please chime in! ;-)
> PS: I grabbed only 5 disks to try. I knew some were copy protected and
> some were not. My 40% success rate is very un-scientific at this
> point.
That's good--I hope you get a higher average "hit" rate on the rest!
Oliver Schmidt
<mjm...@aol.com> wrote:
>[...] I know that
>others here have considerable first-hand knowledge of them. I also
>recall that there is a bit of fiddling required that I'm not familiar
>with. (I've just never been very interested in computer games. ;-)
>
>Search the group for DOSMASTER, I think, and perhaps another...
>
>Experts on this topic, please chime in! ;-)
I second that - but for a slightly different reason...
I'm considering to implement a program that would allow to "run" .dsk
images on an Apple2 but I'd like to understand two things:
1. Is there already such a software?
The only thing I could find is DOS MASTER but from the documentation
its usage is way more complicated than just using a .dsk image as-is.
Don't get me wrong: DOS MASTER is surely a great piece of software and
btw. more flexible than being bound to the 140kB of .dsk images...
2. Is there a need for such a software?
To help you forming your opinion some additional info on what I have
in mind:
It would be a ProDOS system program requiring a 128kB machine. It
would know the .dsk image name to run from the 'startup file' method
and bring up a UI to choose the .dsk image if no startup file was
given. It would allow to assign up to four .dsk images to s5,1 s5,2
s6,1 s6,2.
It would be compatible _only_ with .dsk images containing software
that does its disk I/O through a "DOS 3.3 like" RWTS. That explicitly
includes DOS 3.3 clones like Diversi-DOS, David-DOS, ...
The general approach would be copy the running ProDOS from MAIN RAM to
AUX RAM. Then the .dsk image would be "booted" into MAIN RAM. A rather
small hook into the DOS 3.3 RWTS would switch to AUX RAM, call into
ProDOS to read/write the appropriate data from/to the .dsk image(s)
and swtich back to MAIN RAM.
That approach would require a double buffering of the data slowing
down disk access performance but on the other hand much of AUX RAM
could be used as (write-through) cache speeding up things.
Regards,
Oliver
magnusfalkirk
>
> I second that - but for a slightly different reason...
>
> I'm considering to implement a program that would allow to "run" .dsk
> images on an Apple2 but I'd like to understand two things:
>
> 1. Is there already such a software?
>
There is but it only works on the GS. Antoine created it, it's called
Mount It. it's at version 1.3.
> The only thing I could find is DOS MASTER but from the documentation
> its usage is way more complicated than just using a .dsk image as-is.
>
> Don't get me wrong: DOS MASTER is surely a great piece of software and
> btw. more flexible than being bound to the 140kB of .dsk images...
>
> 2. Is there a need for such a software?
>
I think it's a great idea. This way all I'd need to do is get the
image to the IIe/c and be able to run it, instead of needing to write
it to a real disk again.
> To help you forming your opinion some additional info on what I have
> in mind:
>
> It would be a ProDOS system program requiring a 128kB machine. It
> would know the .dsk image name to run from the 'startup file' method
> and bring up a UI to choose the .dsk image if no startup file was
> given. It would allow to assign up to four .dsk images to s5,1 s5,2
> s6,1 s6,2.
>
> It would be compatible _only_ with .dsk images containing software
> that does its disk I/O through a "DOS 3.3 like" RWTS. That explicitly
> includes DOS 3.3 clones like Diversi-DOS, David-DOS, ...
>
> The general approach would be copy the running ProDOS from MAIN RAM to
> AUX RAM. Then the .dsk image would be "booted" into MAIN RAM. A rather
> small hook into the DOS 3.3 RWTS would switch to AUX RAM, call into
> ProDOS to read/write the appropriate data from/to the .dsk image(s)
> and swtich back to MAIN RAM.
>
> That approach would require a double buffering of the data slowing
> down disk access performance but on the other hand much of AUX RAM
> could be used as (write-through) cache speeding up things.
>
> Regards,
> Oliver
Sounds good to me, I'd be willing to try it when ever you have it
ready to go.
Dean
vladitx
> The general approach would be copy the running ProDOS from MAIN RAM to
> AUX RAM. Then the .dsk image would be "booted" into MAIN RAM. A rather
> small hook into the DOS 3.3 RWTS would switch to AUX RAM, call into
> ProDOS to read/write the appropriate data from/to the .dsk image(s)
> and swtich back to MAIN RAM.
Oliver, don't forget to context-switch all ProDOS / Dos 3.3 global
state like zero page, $3xx page, text-screen holes, whatever else was
there. Also you'll have to deal with interrupts that may have been
running under ProDOS, and redirected I/O vectors. Maybe bunch of other
things.
Another thing that will require some hacking is to make possible
ProDOS to run out of AUX memory - it probably likes to play with the
soft-switches a lot.
Very interesting idea, though. Good luck!
Michael J. Mahon
I think this sounds terrific, Oliver! I really like the caching. ;-)
-michael
NadaNet 3.1 for Apple II parallel computing!
Oliver Schmidt
First of all thanks for thinking about it in detail :-)
>> The general approach would be copy the running ProDOS from MAIN RAM to
>> AUX RAM. Then the .dsk image would be "booted" into MAIN RAM. A rather
>> small hook into the DOS 3.3 RWTS would switch to AUX RAM, call into
>> ProDOS to read/write the appropriate data from/to the .dsk image(s)
>> and swtich back to MAIN RAM.
>
>Oliver, don't forget to context-switch all ProDOS / Dos 3.3 global
>state like zero page, $3xx page, text-screen holes, whatever else was
>there.
All this should be taken care of by using ALTZP - which I certainly
want to do because I for sure need both the MAIN and AUX language
card.
>Also you'll have to deal with interrupts that may have been
>running under ProDOS,
That's something I didn't think about so far. The worst case would be
that they just don't work - but even that wouldn't be a showstopper in
my opinion...
>and redirected I/O vectors. Maybe bunch of other
>things.
Again this should work out-of-the-box because of ALTZP:
- The DOS 3.3 vectoring in MAIN isn't touched by me at all.
- The ProDOS vectoring in AUX is never ever used.
>Another thing that will require some hacking is to make possible
>ProDOS to run out of AUX memory - it probably likes to play with the
>soft-switches a lot.
Don't forget that ProDOS is designed to work on 64k machines. So my
educated guess is that the ProDOS core doesn't do so at all. And the
/RAM driver will be unhooked for obvious reasons anyway.
>Very interesting idea, though. Good luck!
Thanks,
Oliver
Oliver Schmidt
>I think this sounds terrific, Oliver! I really like the caching. ;-)
Thanks for the positive feedback,
Oliver
Oliver Schmidt
>> 1. Is there already such a software?
>>
>
>There is but it only works on the GS. Antoine created it, it's called
>Mount It. it's at version 1.3.
Thanks for the pointer. I found it at:
http://www.brutal-deluxe.fr/products/apple2gs/mountit.html
However it does quite a different thing. It allows to _access_ the
files on a .dsk image from GOS/OS while I plan to _run_ the files on a
.dsk image from an actually active DOS 3.3 (clone).
>I think it's a great idea. This way all I'd need to do is get the
>image to the IIe/c and be able to run it, instead of needing to write
>it to a real disk again.
That's exactly the point. No fiddling with real disks nor DOS MASTER
partitions.
>Sounds good to me, I'd be willing to try it when ever you have it
>ready to go.
Thanks for your interest - but note "when ever" might easily turn out
to be measured in years ;-)
Regards,
Oliver
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.
The principle was simple:
- launch a ProDOS SYS file
- display a menu of all the images contained in a IMAGES directory
(just to bypass the 51 files limit of the root folder)
- select an image
- load it into the IIgs memory (safely with the Memory Manager :-)
- start the program in $B700
The requirements
- rewrite of the $BD00..$BFxx (xx is important) area. $B800..$BCC
would be of no use
- patch the RESET vector each time the RWTS is called and let it point
to a ProDOS QUIT MLI code
- 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
- handle the READ/WRITE/FORMAT RWTS calls
- 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
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.
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. I also know that a IIgs version
would restrict its use to IIgs owners :-)
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.
I am adding a IIgs version to my to-do list, target date is "when
ever" :-)
Antoine
Michael J. Mahon
Isn't the set of DOS 3.3 programs that use AUX memory (for storage
or for DHGR) just about empty? (And if not, why not? ;-)
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon
Oliver Schmidt
>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
Steve Nickolas
> You seem to see DOS 3.3 and ProDOS 8 living in the same bank ?!?
I've done it. Locks out the language card and a lot of DOS patches, but it
can be done.
-uso.
Toinet
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
Oliver Schmidt
>> You seem to see DOS 3.3 and ProDOS 8 living in the same bank ?!?
>
>I've done it. Locks out the language card and a lot of DOS patches, but it
>can be done.
That's what I guessed. Thanks for your feedback.
What was the goal of your program? Is it available somewhere? With
source code?
Regards,
Oliver
Steve Nickolas
It seems (with an A65 file) to be here:
http://usotsuki.info/thedosescape.zip
Doesn't do much, just patches DOS 3.3 RWTS to avoid the BFxx memory area so
that ProDOS remains resident (it was more an exercise than anything).
-uso.
Oliver Schmidt
>> >- 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
Oliver Schmidt
>> What was the goal of your program? Is it available somewhere? With
>> source code?
>It seems (with an A65 file) to be here:
>http://usotsuki.info/thedosescape.zip
>
>Doesn't do much, just patches DOS 3.3 RWTS to avoid the BFxx memory area so
>that ProDOS remains resident (it was more an exercise than anything).
I see - I just checked the A65 file. Thanks anyway :-)
Regards,
Oliver
sicklittlemonkey
> I'm considering to implement a program that would allow to "run" .dsk
> images on an Apple2 but I'd like to understand two things:
Cool idea.
Just a couple of points. The (sadly half-complete) Apple II Game
Server does this ... detects RWTS and replaces it with serial
routines. It works for a number of whole-disk DOS 3.3 RWTS-using
games, but a larger number didn't work for reasons as yet unexplored.
Also, the //c will need to be special-cased to turn off interrupts.
E.g. the firmware implements a keyboard buffer which uses interrupts
and stores keys in aux RAM.
Cheers,
Nick.
Oliver Schmidt
>> I'm considering to implement a program that would allow to "run" .dsk
>> images on an Apple2 [...]
>Cool idea.
:-)
>Just a couple of points. The (sadly half-complete) Apple II Game
>Server does this ... detects RWTS and replaces it with serial
>routines. It works for a number of whole-disk DOS 3.3 RWTS-using
>games, but a larger number didn't work for reasons as yet unexplored.
Thanks for adjusting my expectations.
>Also, the //c will need to be special-cased to turn off interrupts.
>E.g. the firmware implements a keyboard buffer which uses interrupts
>and stores keys in aux RAM.
To be honest I was totally unaware of this. Hopefully there aren't
many of those...
Regards,
Oliver