Re: Is it possilble to use timer interrupt in Apple II?

["Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com>]

"bluebird" <mildstorm@gmail.com> wrote in message 
5b2e7db1-50d9-4fe9-a554-fe267fcd0c66@h14g2000pri.googlegroups.com">news:5b2e7db1-50d9-4fe9-a554-fe267fcd0c66@h14g2000pri.googlegroups.com...
> That's very bad news.
>
> Then we can't make any operating system in Apple II environment.
>
> Is there any workaround for multi-threading without any expansion slot
> card?
>

The above is not true at all, ask yourself in a game how you can have two or 
three objects moving in all different directions on the screen at the same 
time, and process keyboard and mouse clicks at the same time?

What it means if you write an operating system in this type of environment, 
you'll not use a preemptive, or timing mechanism to service the processes 
that run.

So you can make an operating system, but perhaps not the type you want.

I remember lots of programming and coding using applesoft basic. One of the 
things I really missed is that when a screen was repotting you could not 
type ahead. You could not use the type the head buffer, because there was no 
type ahead buffer!

However if you ever programmed using the UCSD Pascal system, you would 
notice that while the screen is re plotting and displaying text, you had a 
full type ahead buffer for as long as you wanted to type. And note carefully 
how this type ahead buffer was implemented. There was NO keyboard interrupt 
occurring here. That means as you pressed a key, there was ONLY a built in 
buffer of ONE key in the hardware. (and to be totally fair, I actually think 
the Pascal operating system had a limit of 59 characters?? Someone do jump 
in to correct me on how many characters the UCSD type ahead buffer was)

So the next question you have to ask yourself is how one earth did the UCSD 
Pascal development system have an very nice type ahead buffer and accomplish 
feat this without keyboard interrupts or without a timer system to stop the 
current code that's running, and then tell the system please check the 
keyboard?

Timer based hardware interrupted systems = preemptive multitasking:

In this type of system, the operating system will only give a program so 
much time before it chops its legs off, stops that program and then has the 
processor go to work on the next program that happens to be running in the 
operating system. In this kind of software development environment, the 
program running does not have to worry about trying to give up or release 
its processing to other applications that may be running. It is a single 
thread.

Software based, or what we call cooperative multitasking means that each 
piece of code you write in that system has to have at certain points in the 
code or by the software compiler design have parts in the code that will 
release itself back to the operating system.

So for example the UCSD Pascal system had display routines that during 
drawing characters and data to the screen it also had calls to service the 
keyboard input buffer. In fact, even for programming on the apple Macintosh, 
or other systems before preemptive multitasking occurred, you often had to 
write your own main event loop in your software eg:

loop
       call code to service display screen update

       call code to service input buffer routines

       Call code to server disk drive activity

       Call code to service printer activity

       call code to get users menu choice
       select menu choice
           Call menu option 1
           Call menu option 2
           Call menu option 3
      end select

repeat


So, you can most certainly design and develop an operating system that's not 
based on preemptive multitasking. There was a good many operating systems 
that worked in this fashion, and the Pascal UCSD system for the apple was an 
perfect example of such a OS.

You cannot imagine what a delightful experience it was to work on the apple 
II using UCSD and Pascal.

Not only was code editing and writing of programs absolutely beautiful and 
butter smooth with type-ahead, you also had the ability to have parts of the 
applications dynamically load right off the floppy drive.

I once compiled one of my text input routines to be dynamically loaded on 
the Apple II. This would mean that as long as you typed on the keyboard the 
floppy drive would actually spin and run for every character you typed (as 
it loaded the code). Really amazing, but the REST of the os (screen, 
keyboard input) etc. ALL continued to run butter smooth WHILE the floppy 
disk drive was running and loading code. If you kept typing, the floppy 
would spin! (and, that it was pretty cool because you made sure you type a 
few more characters before the floppy drive timeout occurred! If the floppy 
drive stopped, then type the a character, it took quite a while for the 
floppy drive spin back up to speed).

Contrast the above behavior as to when using Applesoft BASIC and you 
executed a load from the floppy drive - all the code and virtually 
everything else like the display froze during the disk drive load/activity .

So, just to be clear here you CAN write a OS on the Apple II. And, you can 
even write an multitasking system on the apple II. However, without a timer, 
it's going to be very difficult (if not impossible) without interrupts to 
write a preemptive multitasking system. In theory inserting some type of 
board with a timer would allow the interrupts to force the os to move on to 
the next program that requires servicing. (that next program might be disk 
i/o, display, or another user program).

-- 
Albert D. Kallal
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com