2

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?

6
  • 1
    Ampersands worked pretty well for RDOS (gswv.apple2.org.za/a2zine/Sel/RDOSstuff.html). OTOH, plenty of assembly-language programs used the I/O hooks to invoke BLOAD/BSAVE, so using text output scores well on the "works for anything" scale.
    – fadden
    Jan 14, 2023 at 23:25
  • @fadden: Would having a DOS entry point that could be invoked via JSR $03FD not fit the "works for anything" scale just as well for machine-language programs or any language that makes any effort at all to support DOS?
    – supercat
    Jan 15, 2023 at 18:35
  • many things work better. Few things are as easy for users and as consistent across multiple environments. The ProDOS BASIC.System TRACE integration was an interesting spin.
    – fadden
    Jan 15, 2023 at 22:52
  • I know the tags disambiguate this, but I can’t help thinking of MS-DOS 3.30 when reading the title… Jan 16, 2023 at 13:12
  • @fadden: Using in-band mode switching creates all sorts of problems. Even back in the day, there were issues with "Bobby Tales" exploits. For example, given 10 INPUT A$:PRINT A$;" IS THE GREATEST!", typing [control-D]SAVE BOBBY TABLES` at the prompt would create a file called SAVE BOBBY TABLES IS THE GREATEST!, and one could also reformat disks using similar techniques.
    – supercat
    Jan 16, 2023 at 15:50

1 Answer 1

3

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

7
  • I don't know if you've written code to do file I/O, but Applesoft+DOS is the most cumbersome language I've coded for. Given Apple's attitude toward supporting the Apple 1, what problem would there have been with offering people who bought disk drives free ROM upgrades so as to avoid having to make major design sacrifices to maintain compatibility with a few dozen antiquated machines?
    – supercat
    Jan 14, 2023 at 22:28
  • Perhaps the design was chosen before the problems were apparent, but if that's the case it would be interesting to know which annoyances were anticipated and which weren't.
    – supercat
    Jan 14, 2023 at 22:48
  • @supercat Not sure what you're talking about the Apple 1, but giving an off to a few dozend users isn't a big deal - unlike to several thousands of delivered Apple II (all units between 1977 and late 1979). Not to mention that the ROMs nor the BASIC did exist at the time the DOS was done. Applesoft was at that time only an add on. Later DOS had to be compatible. Last but not least, I did years of A2 programming back when it was new, and I never felt it to be cumbersome in any way. It was awesome.
    – Raffzahn
    Jan 14, 2023 at 22:54
  • Even for ROM-based integer BASIC, a design in which code wanting to perform a DOS command would CALL a certain address (which would install a CHROUT trap) and then do a PRINT, the closing CR of which would revert the CHROUT vector, would seem both easier to work with and more compatible existing code and practices than the design that takes over CHROUT "permanently". If you can point me to any code that interleaves reads and writes of different files using just the control-D interface, I'd love to see how it's done. The one notable production-worthy program I did in Applesoft (used for...
    – supercat
    Jan 15, 2023 at 18:16
  • 1
    @supercat The method you suggest would neither be convenient, not fture proof, as addresses may vary. The slow down was not only rather minimal, it would also have not affected your example in any way, as saving and restoring was without other output - or was it? The speed up you experienced isn't from faster text handling, but a changed algorithm. Instead of printing every variable and inputting it again, using STORE and RESTORE under ProDOS is the equivalent of a BSAVE/BLOAD operation. A method you could have as well done under DOS. Citing it as example is comparing apples and oranges.
    – Raffzahn
    Jan 16, 2023 at 1:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .