Steve Nickolas

This time I'm armed with a basic understanding of the ProDOS API, but
still don't understand the inner workings of DOS.

I've thought of a few things which would be potentially viable with such a
system: INTBASIC (lomem version) and a number of small BASIC programs with
chargens (many of them break under ProDOS). Mostly this is advantageous
to people with higher capacity disk drives.

The source of PDOS RDOS tells me what I need to know about interfacing on
a basic (lol) level to ProDOS but I haven't seen something similar for DOS
3.3. I am thinking I will want to merely patch out the file manager and
RWTS, and replace INIT with BYE. Doing the former is the most difficult.

-uso.

Antoine Vignau

Purchase Beneath Apple DOS :-)
av

Steve Nickolas

On Tue, 13 Dec 2011, Antoine Vignau wrote:

> Purchase Beneath Apple DOS :-)
> av
>

I actually have a copy. >:P

I guess it's more that "documentation" doesn't really tell me much, but
"examples" do.

-uso.

Antoine Vignau

On 13 déc, 20:23, Steve Nickolas <lyricalnan...@usotsuki.hoshinet.org>
wrote:
> On Tue, 13 Dec 2011, Antoine Vignau wrote:
> > Purchase Beneath Apple DOS :-)
> > av
>
> I actually have a copy. >:P
>
> I guess it's more that "documentation" doesn't really tell me much, but
> "examples" do.
>
> -uso.

Read the source code of DOS 3.3 (http://www.brutaldeluxe.fr/
documentation/dos33/apple2_SRC_DOS33C_1983.pdf) and get Exploring GS/
OS and ProDOS 8 by Gary B. Little, that will help you,

Antoine

BluPhoenyx

On 12/13/2011 12:49 PM, Steve Nickolas wrote:
> This time I'm armed with a basic understanding of the ProDOS API, but
> still don't understand the inner workings of DOS.

The inner workings of DOS were always hazy to a number of folks. Factor
in the myriad hacks by the community and DOS was a jumble of routines
which could give most anyone a headache. However, most INTEGER DOS
programs don't require such intricate details about DOS they require an
understanding of what the programmer was attempting to accomplish within
the confines of DOS. Given the flexibility of ProDOS 8 I suspect most
Apple DOS programs could be ported.

> I've thought of a few things which would be potentially viable with such
> a system: INTBASIC (lomem version) and a number of small BASIC programs
> with chargens (many of them break under ProDOS). Mostly this is
> advantageous to people with higher capacity disk drives.

Integer BASIC has often been desired by the II's BASIC programming
fans.I myself have toyed with the idea several times. I could never
justify the effort though as there are other alternatives available. For
instance, there is APEX an integer based interpreted language with an
adjustable base which allowed for a broad range of values on a variable
sized base. Alternately, ZBASIC could be configured for use as an
integer only environment. Being both compiler and interpreter it offers
some interesting possibilities.

Please don't misunderstand, I applaud your efforts and should you make
such an interpreter I expect to be among the first in line to acquire a
copy. I mostly wanted to point out that most of those old gems might be
better off if the effort were put directly into porting them instead.

> The source of PDOS RDOS tells me what I need to know about interfacing
> on a basic (lol) level to ProDOS but I haven't seen something similar
> for DOS 3.3. I am thinking I will want to merely patch out the file
> manager and RWTS, and replace INIT with BYE. Doing the former is the
> most difficult.

The thing is, DOS wasn't meant to be interfaced with. It was a means to
an end. A simple method created to allow BASIC programmers access to the
floppy disk storage medium. The trick was to make the DOS commands feel
like part of the actual BASIC environment. Well, that's just me waxing
philosophical about it. Perhaps there will be some technical posts about
how (or not) it can be done.

Cheers
Mike T

Steve Nickolas

On Wed, 14 Dec 2011, BluPhoenyx wrote:

> On 12/13/2011 12:49 PM, Steve Nickolas wrote:
>> This time I'm armed with a basic understanding of the ProDOS API, but
>> still don't understand the inner workings of DOS.
>
> The inner workings of DOS were always hazy to a number of folks. Factor in
> the myriad hacks by the community and DOS was a jumble of routines which
> could give most anyone a headache. However, most INTEGER DOS programs don't
> require such intricate details about DOS they require an understanding of
> what the programmer was attempting to accomplish within the confines of DOS.
> Given the flexibility of ProDOS 8 I suspect most Apple DOS programs could be
> ported.

As do I. This was why I was trying to do this.

>> I've thought of a few things which would be potentially viable with such
>> a system: INTBASIC (lomem version) and a number of small BASIC programs
>> with chargens (many of them break under ProDOS). Mostly this is
>> advantageous to people with higher capacity disk drives.
>
> Integer BASIC has often been desired by the II's BASIC programming fans.I
> myself have toyed with the idea several times. I could never justify the
> effort though as there are other alternatives available. For instance, there
> is APEX an integer based interpreted language with an adjustable base which
> allowed for a broad range of values on a variable sized base. Alternately,
> ZBASIC could be configured for use as an integer only environment. Being both
> compiler and interpreter it offers some interesting possibilities.
>
> Please don't misunderstand, I applaud your efforts and should you make such
> an interpreter I expect to be among the first in line to acquire a copy. I
> mostly wanted to point out that most of those old gems might be better off if
> the effort were put directly into porting them instead.

I suppose easier said than done.

The idea I've thought of is just patch DOS 3.3 so that file i/o is done
through the ProDOS api. I think there's enough room in the code to do
this and leave the 256 bytes at the top free (hell, just removing INIT
allowed me to have DOS 3.3 and ProDOS resident at the same time).

>> The source of PDOS RDOS tells me what I need to know about interfacing
>> on a basic (lol) level to ProDOS but I haven't seen something similar
>> for DOS 3.3. I am thinking I will want to merely patch out the file
>> manager and RWTS, and replace INIT with BYE. Doing the former is the
>> most difficult.
>
> The thing is, DOS wasn't meant to be interfaced with. It was a means to an
> end. A simple method created to allow BASIC programmers access to the floppy
> disk storage medium. The trick was to make the DOS commands feel like part of
> the actual BASIC environment. Well, that's just me waxing philosophical about
> it. Perhaps there will be some technical posts about how (or not) it can be
> done.

Heh.

I think the biggest trick I've seen was the print chr$(4) stuff being used
from machine code. Works great under DOS 3.3... don't work at all under
BASIC.SYSTEM. (Then, I guess just trying to implement that would take
care of a lot of things. I haven't had the luck in handling stuff like
OPEN or whatall though and at best would just have the minimal stuff. And
I'm not good at writing parsers in 6502...) I think actually poking into
the guts of DOS is prolly rare, though it should be possible to keep most
of the guts intact.

There is an INTBASIC variant that loads at $0800. Necessarily it would
need the standard hooks like DOS 3.x uses in order to function, but it is
fully capable of running there.

-uso.

Michael J. Mahon

Steve Nickolas wrote:
> On Wed, 14 Dec 2011, BluPhoenyx wrote:
>
>> On 12/13/2011 12:49 PM, Steve Nickolas wrote:
>>
>>> This time I'm armed with a basic understanding of the ProDOS API, but
>>> still don't understand the inner workings of DOS.
>>
>>
>> The inner workings of DOS were always hazy to a number of folks.
>> Factor in the myriad hacks by the community and DOS was a jumble of
>> routines which could give most anyone a headache. However, most
>> INTEGER DOS programs don't require such intricate details about DOS
>> they require an understanding of what the programmer was attempting to
>> accomplish within the confines of DOS. Given the flexibility of ProDOS
>> 8 I suspect most Apple DOS programs could be ported.
>
>
> As do I. This was why I was trying to do this.
>
>>> I've thought of a few things which would be potentially viable with such
>>> a system: INTBASIC (lomem version) and a number of small BASIC programs
>>> with chargens (many of them break under ProDOS). Mostly this is
>>> advantageous to people with higher capacity disk drives.
>>
>>
>> Integer BASIC has often been desired by the II's BASIC programming
>> fans.I myself have toyed with the idea several times. I could never
>> justify the effort though as there are other alternatives available.
>> For instance, there is APEX an integer based interpreted language with
>> an adjustable base which allowed for a broad range of values on a
>> variable sized base. Alternately, ZBASIC could be configured for use
>> as an integer only environment. Being both compiler and interpreter it
>> offers some interesting possibilities.
>>
>> Please don't misunderstand, I applaud your efforts and should you make
>> such an interpreter I expect to be among the first in line to acquire
>> a copy. I mostly wanted to point out that most of those old gems might
>> be better off if the effort were put directly into porting them instead.
>
>
> I suppose easier said than done.
>
> The idea I've thought of is just patch DOS 3.3 so that file i/o is done
> through the ProDOS api. I think there's enough room in the code to do
> this and leave the 256 bytes at the top free (hell, just removing INIT
> allowed me to have DOS 3.3 and ProDOS resident at the same time).
>
>>> The source of PDOS RDOS tells me what I need to know about interfacing
>>> on a basic (lol) level to ProDOS but I haven't seen something similar
>>> for DOS 3.3. I am thinking I will want to merely patch out the file
>>> manager and RWTS, and replace INIT with BYE. Doing the former is the
>>> most difficult.
>>
>>
>> The thing is, DOS wasn't meant to be interfaced with. It was a means
>> to an end. A simple method created to allow BASIC programmers access
>> to the floppy disk storage medium. The trick was to make the DOS
>> commands feel like part of the actual BASIC environment. Well, that's
>> just me waxing philosophical about it. Perhaps there will be some
>> technical posts about how (or not) it can be done.
>
>
> Heh.
>
> I think the biggest trick I've seen was the print chr$(4) stuff being
> used from machine code. Works great under DOS 3.3... don't work at all
> under BASIC.SYSTEM.

But for many commands, you can just put them into the keyboard
buffer and call DOSCMD in BASIC.SYSTEM. That's pretty close!

-michael

NadaNet 3.1 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."

Steve Nickolas

On Wed, 14 Dec 2011, Michael J. Mahon wrote:

> But for many commands, you can just put them into the keyboard
> buffer and call DOSCMD in BASIC.SYSTEM. That's pretty close!

Yeah, but if you don't have source, you'd have to DASM to be able to do
that. Stringhacking, otoh, is a lot easier. >:P

-uso.

Oliver Schmidt

Hi Steve,

> This time I'm armed with a basic understanding of the ProDOS API, but
> still don't understand the inner workings of DOS.

You write "this time" and "once again" but even after some search I
don't find the discussion you seem to refer to...

> The source of PDOS RDOS tells me what I need to know about interfacing on
> a basic (lol) level to ProDOS but I haven't seen something similar for DOS
> 3.3. *I am thinking I will want to merely patch out the file manager and
> RWTS, and replace INIT with BYE. *Doing the former is the most difficult.

I seem to be unclear of what you want to want to archive. For many
BASIC programs the existing BASIC.SYSTEM is already a sufficient "DOS
3.3 emulation". And when it comes to RWTS access then the general
question would be how to map those accesses to ProDOS. Not talking
about implementation issues but about conceptual questions. If some
program reads some sector on some track it most likely presumes a DOS
3.3 layout with a DOS 3.3 catalog / vtoc / etc. The only way I see
such a program working in a successful / meaningful way on a higher
capacity drive is to work with DOS 3.3 partitions or DOS 3.3 disk
images.

The further is already implemented: DOS.MASTER

The latter was discussed here:
http://groups.google.com/group/comp....ecd7714a8d5f94

I don't see that something simpler than these two approaches would
give a significant benefit over what BASIC.SYSTEM already does:

Regards,
Oliver

Steve Nickolas

On Thu, 15 Dec 2011, Oliver Schmidt wrote:

> Hi Steve,
>
>> This time I'm armed with a basic understanding of the ProDOS API, but
>> still don't understand the inner workings of DOS.
>
> You write "this time" and "once again" but even after some search I
> don't find the discussion you seem to refer to...

Every couple years I get the idea. I remember bringing it up at least
twice here, hence "once again".

>> The source of PDOS RDOS tells me what I need to know about interfacing on
>> a basic (lol) level to ProDOS but I haven't seen something similar for DOS
>> 3.3. *I am thinking I will want to merely patch out the file manager and
>> RWTS, and replace INIT with BYE. *Doing the former is the most difficult.
>
> I seem to be unclear of what you want to want to archive. For many
> BASIC programs the existing BASIC.SYSTEM is already a sufficient "DOS
> 3.3 emulation". And when it comes to RWTS access then the general
> question would be how to map those accesses to ProDOS. Not talking
> about implementation issues but about conceptual questions. If some
> program reads some sector on some track it most likely presumes a DOS
> 3.3 layout with a DOS 3.3 catalog / vtoc / etc. The only way I see
> such a program working in a successful / meaningful way on a higher
> capacity drive is to work with DOS 3.3 partitions or DOS 3.3 disk
> images.

BASIC, yes. But I've dealt with a few DOS programs where they do things
BASIC.SYSTEM doesn't like (a lot of chargens do that), or they access DOS
through the print chr$(4) trick in machine code (almost anything
compiled), - these programs could be made to work in this way, even if the
RWTS is not DOSsy enough, even if the catalog is not DOSsy.

THIS is what I hope to achieve, and it doesn't need the "dos.master"
approach of doing a block-mapping emulation of the drive over top of DOS
3.3.

-uso.