Motivation for DOS 3.3 using I/O hooks rather than ampersand-hook

Question

AppleSoft BASIC is designed so that if it encounters an ampersand while processing a program, it will jump to address $03F5, allowing code there to examine what follows and process it suitably. While ROM-based integer BASIC doesn't include such a hook, it would seem simple to include such a hook in a RAM-loaded version, or allow programs to use e.g. CALL 999,whatever as an alternative.

Having a hook support DOS commands that start with & would seem simpler, easier, and more efficient than having DOS intercept all I/O. Even having to write CALL 999,"O","MYFILE" would seem nicer than having to ensure that the last thing written was a CR, and then do PRINT CHR$(4);"OPEN MYFILE", and would avoid cutting the speed of character output in half.

Is there any documented rationale for the "I/O hooks" approach used by DOS?

Answer 1

As usual History and compatibility.

The Apple II was originally only released with Integer BASIC in ROM. Applesoft BASIC had to be loaded to RAM - not to mention that it was far from what we know, for example no High-Res graphics at all, as it was loaded into the graphics page:))

Let's look at the timeline:

• DOS 3.1 was first shown in June 1978.
• First Applesoft II came in mid 1978 and was only available as cassette and disk version. Both were loaded into 'low' memory, much like Applesoft I.
• The ROM Card for Applesoft II added another version in late 1978.
• The Language Card was only introduced later (1979) as part of the PASCAL system. A rather expensive package and it took another year before it could be bought separate.
• DOS 3.2 of February 1979 introduced the ability to load Applesoft II into language card.
• Only the Apple IIplus, introduced in June 1979 had finally Applesoft II by default in ROM.
• The mentioned DOS 3.3 was released as late as August 1980.

It's easy to see that DOS das done before Applesoft and had to work first of all with Integer BASIC, but there is more to it, which becomes obvious when looking at the requirements:

• Must work with Integer BASIC
• Must work with Applesoft I
• Must work with Applesoft II
• Must work with potential other languages
• Must work with RAM versions
• Must work with ROM versions Most of all:
• Must work with future versions

All of these have different entry points, different ways to hook routines, different addresses used for internal routines (like reading program text), different RAM structures and so on. Tough, isn't it?

But they have one thing in common, a mechanic that essentially every language must support: Writing text using the standard output vector. Hooking that will not only work with either language in all of their versions but as well with any future version. Awesome, isn't it?

Yes, every abstraction level does eat a bit of performance, but usually quite worth it.

---

So let's look at the suggested 'improvements'

AppleSoft BASIC is designed so that if it encounters an ampersand while processing a program, it will jump to address $03F5,

That feature is only present in Applesoft II, not in Applesoft or Integrer BASIC

allowing code there to examine what follows and process it suitably.

Such code would not only be limited to Applesoft, but as well be version specific, as it would need to use Applesoft's routines to fetch program code and variables. Since there were at least 4 different versions of Applesoft with different address layout and load addresses, this would mean DOS had to carry a mechanic to adapt to either.

That is unless one want's to copy these routines into DOS code, which would bloat it even more and add another problem: The way program text is stored is version specific, so it may not be the same for future versions (*1).

In addition, internal encoding of strings is as well not guaranteed - in contrast to using CSW, which is guaranteed to work in ASCII.

While ROM-based integer BASIC doesn't include such a hook, it would seem simple to include such a hook in a RAM-loaded version, or allow programs to use e.g. CALL 999,whatever as an alternative.

A RAM based version of several KiB in addition to 10 KiB DOS needs in a machine that is delivered with only 16 KiB base RAM?

Not to mention that it would as well needed to be stored on the boot disk? With only 114 KiB disk space (DOS prior to 16 Sector DOS 3.3) every KiB that needs to be spend reduces usable disk space considerable.

Having a hook support DOS commands that start with & would seem simpler, easier, and more efficient than having DOS intercept all I/O.

Not really. All it saves is some checking during a rather rare operation. Or how much does your application print all the time?

Even having to write CALL 999,"O","MYFILE" would seem nicer

Maybe. Then again, that's something rather related to taste. Starting with the question why 'O' instead of the more readable 'OPEN', or when going cryptic, why not just numbers - or different entry points?

than having to ensure that the last thing written was a CR,

Can't remember ever having that issue. Also it was resolved by ProDOS due enabling trace :))

[...] would avoid cutting the speed of character output in half.

Not sure how that is relevant in real world applications. Beside not really being half, Applesoft is still fast enough to fill the whole screen in a blink. And what real world, DOS using application does continuously fill screens - all without any processing inbetween?

The only somehow related application I can ever think of printing so much that it might matter would be operating a printer - which back then would break output speed on it's own.

In fact, ProDOS slows BASIC down even more than DOS by not just scanning every printout, but also enabling trace, which meant each and every statement produced output which not only had to be scanned like with DOS, but as well with a more complex scanning routine. So if at all, ProDOS will be slower than DOS for the same algorithm.

---

All of this seems like solutions for a non existing problem. Given BASIC isn't fast to start with, but most speed gets lost in BASIC, not in DOS. There are many good hints how to speed up BASIC (like not having each print in a line of its own) that will each bring way more performance than making DOS less user friendly.

---

*1 - Applesoft 3 was already close to being rolled out in 1980