Is it possilble to use timer interrupt in Apple II?

[bluebird]

I want to use timer interrupt in Apple II/Apple II+/Apple IIe.
For example, I want to install 300ms timer interrupt and want its ISR
called periodically.

Is there any example?

[Michael J. Mahon]

There is no timer interrupt standardized across all Apple II systems.

Only the Apple IIc (of the systems you mention) has a built-in timer
interrupt--at the vertical blanking rate, or 60Hz. All other systems
in your list have this interrupt only if a mouse card is installed, or
some other card that can generate interrupts.

If the machine has an interrupt source, then only the ProDOS operating
system has standard provisions for handling interrupts. All interrupts
are handled in one ISR chain, and your ISR must "claim" its desired
interrupt by recognizing and processing it. There is no "vectoring".

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."

[David Empson]

bluebird <mild...@gmail.com> wrote:

The Apple II/II+/IIe doesn't have any built-in hardware which can
generate a periodic interrupt.

You can gain some form of timed interrupt with many expansion cards, but
the degree of control over the period of the interrupt may be limited.

For example, the Apple II Mouse Card can generate a screen refresh
interrupt (60 Hz in an NTSC II/II+/IIe, probably 50 Hz in a PAL IIe).

Some clock cards can also generate timed interrupts but they may be
limited to 1 Hz or a specific set of higher frequencies, and may require
changing jumpers or DIP switches to enable or configure the interrupt.

A more general purpose I/O expansion card containing a VIA chip could
generate arbitrary periodic interrupts under program control.

I expect that something like the Carte Blanche could also do this, if
someone has set up an appropriate configuration for it.

--
David Empson
dem...@actrix.gen.nz

[bluebird]

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?

[Michael J. Mahon]

bluebird wrote:
> That's very bad news.
>
> Then we can't make any operating system in Apple II environment.

Well, a _multiprogramming_ OS is problematic, but the Apple II
supports a number of capable operating systems (some even support
a _form_ of multiprogramming!).

> Is there any workaround for multi-threading without any expansion slot
> card?

Everthing depends on what programs the system must support.

A relatively small number of Apple II programs use only resources
that can be effectively virtualized by an operating system. Most
freely access the hardware control addresses and most if not all
of the memory map. Few are candidates for sharing one Apple.

Of course, since you mention multithreading, perhaps you are
planning to write your own multithreaded program, and are looking
at a kernel to support it, in which case no conflicts will arise
in a correct program. ;-)

Take a look at Contiki. It's an example of a solution:
http://www.sics.se/contiki/about-contiki.html

[Albert D. Kallal]

"bluebird" <mild...@gmail.com> wrote in message
news:5b2e7db1-50d9-4fe9...@h14g2000pri.googlegroups.com...

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
pleaseNOO...@msn.com

[bluebird]

Dear Albert,

Thanks for your long explanation.
I understand what you are talking about.
(I know what preemptive and nonpreemptive means.)

I only talked that I can't make preemptive kernels without any h/w
support.
Thanks.
BR,

[bluebird]

Very cool stuff.
Thanks for your kind explanation.

[bluebird]

Dear Albert,

I tried to make Super Serial Card communication with PC.
At first, I implemented it with status machine method which checks SSC
status and tx/rx the data.
The method I applied is the same with what you talked to me.
=> There is no execution blocking while sending/receiving.

But I thought it will be more simple with interrupt handling.
I don't know whether SSC generates interrupt in relation with RX/TX.
=> Currently, I am going to try it with BRK interrupt.
(Actually, I am novice in Apple II S/W, H/W)

------------------------------------------------------
I wanted to know whether setting timer interrupt is possible not.
If setting timer interrupt is not possible, making RTOS(which is
preemptive as you know) is impossible.

Thanks for your kind explanation again.

[Albert D. Kallal]

"bluebird" <mild...@gmail.com> wrote in message

news:8407bfa8-a4b6-4838...@r24g2000prf.googlegroups.com...

Thank you very kindly right back.

To be 100% fair, you were asking more about threading then
actual preemptive multi-tasking anyway. If you wanted to dig in
your heals you could state that multi-tasking and that of
threading ability are not the same question!

However, now that you mentioned the SSC?

Hum, my recollection is that card DOES generate an interrupts.

The SSC could work two ways to control character flow to
a printer or modem. The card would send out a ctrl-s, or
a ctrl-q for software flow. It also supported hardware
(one pin high, or low (off/on) to allow flow of data.
(you mention the tx/rx pins in your post).

However, the card ALSO did support an hardware interrupts
if turned on. This was/is preemptive over the os.

So, while the keyboard and good many things on the Apple hardware
does not generate an hardware interrupts, the SSC card was able to
generate a hardware interrupt. It is a switch setting on the card
and if turned on, a Jump (JMP) instruction to a particular memory
location (based on the slot #) would in fact occur.

I don't have any docs in front me, and it been MANY years.

I would strongly suggest you start another question here and ask
if the SSC supports hardware interrupts. My memory says
almost for certain it does...

[Wizard Of Oz]

This may not be the answer you are looking for. Back in the 80's I had
a card called a "Thunderclock". Actually it was a clone of that device.
It could generate an interrupt every millisecond. Of course on a ][+
there isn't a lot you can do with that small of an interval. The //e
clone I had later allowed a little more to be done but still...

The circuit was fairly simple. Using modern technology someone could
probably put all the functionality (plus a bunch more) on a single chip.
Maybe the people making hardware would consider adding a clock to their
product if there isn't one there already. Of course I wonder how the
system would handle multiple clocks...

Later
Mike

[D Finnigan]

Albert D. Kallalwrote:

>
> I would strongly suggest you start another question here and ask
> if the SSC supports hardware interrupts. My memory says
> almost for certain it does...
>

Your memory is correct. The SSC can be set via switch 2-6 to generate an IRQ
when a new character comes in.

Some terminal programs take advantage of this feature. There is even a
NetChess program for Apple II which won't work unless this switch is on.

[Michael J. Mahon]

Albert D. Kallal wrote:
> "bluebird" <mild...@gmail.com> wrote in message
> news:5b2e7db1-50d9-4fe9...@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?

Actually, most cases of multiple objects moving on the screen is
done by simply advancing all objects by one time step in a common
routine, not by assigning different threads to each object.

This is the usual way of supporting _apparent_ concurrency on a single-
threaded machine.

> 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.

One of the most common is a "service loop" style, where the program
constantly executes a loop in which short service routines run if a
condition is met.

This style is quite common in embedded controller programming, and
on the Apple II it is often done even in Applesoft!

> 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!

This was purely a Microsoft design decision. The Applesoft interpreter
is constantly interrogating the keyboard, but is looking only for the
ctl-C character to cause a "break". It could have easily implemented
a type-ahead capability with no more overhead, but didn't.

> 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?

The answer is that (like Applesoft) Pascal is a fully interpretive
system, and it is easy to embed a keyboard poll into the interpreter
so that it is tested very frequently during execution.

In fact, this implements an "interpreter interrupt", exactly analogous
to the way a hardware interrupt is polled by the fetch/execute loop of
the processor.

Actually, though you can easily poll the keyboard between disk
operations (like read block or write block), you cannot do any polling
of anything else while a disk read or write is occurring. This includes
at least the rotational latency while the disk driver is reading,
waiting for the correct sector header.

Of course, if disk I/O is performed by the system one block at a time,
then it can poll between blocks. Still, the latency for polling would
vary between the rotational span of one block and that time plus a full
rotation, or about 100-200 milliseconds (which would be a problem for
a fast typer).

> 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 .

Because DOS and ProDOS disk operations do not poll between blocks, not
because of anything fundamental.

Type-ahead requires not only thorough support by the programming
environment and OS, but also recovery code to occasionally purge
the type-ahead buffer (for example, when an error occurs and the
buffer is likely to be useless).

Many users find type-ahead buffering confusing in some cases, since
it decouples the user's input from the system's operations. While
an experienced command line user might be quite at home with it,
a user running an accounting package where keys switch screens might
prefer to wait to see the actual state of the program before proceeding
with his next input.

Although you used it only as an example, it is not difficult to see
how one design team could choose to implement it and another might
not.

> 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).

It is useful to regard interrupts as "procedure calls from heaven",
in the sense that the "call" occurs only when a hardware poll in the
processor's fetch/execute loop observes the assertion of the interrupt
request line (after masking).

Any interpretive system can easily implement "interpretive interrupts"
based on polling any condition in the hardware or software. (In fact,
interpreters often "interrupt" if their stack or heap overflows.)

As a practical matter, saving and restoring state, either during
interrupt processing or during a task/thread swap, is a frequent
activity, and therefore must be relatively efficient. The 6502's
lovely page zero, with all its "address registers", becomes a real
liability if it must be saved and restored. Therefore most practical
multithreading approaches for the 6502 choose to severely restrict
a task's/thread's use of page zero to save overhead.

[Michael J. Mahon]

As David noted, any card containing a 6522 VIA with a connected IRQ
line could generate almost any interrupt interval. The Mockingboard
is one (relatively) common card that can do this.

[D Finnigan]

Michael J. Mahonwrote:

>
> As a practical matter, saving and restoring state, either during
> interrupt processing or during a task/thread swap, is a frequent
> activity, and therefore must be relatively efficient. The 6502's
> lovely page zero, with all its "address registers", becomes a real
> liability if it must be saved and restored. Therefore most practical
> multithreading approaches for the 6502 choose to severely restrict
> a task's/thread's use of page zero to save overhead.
>

Or one could use a RamWorks or equivalent Aux RAM card which provides
multiple 64k banks, and therefore, multiple page zeroes.

[Albert D. Kallal]

"Michael J. Mahon" <mjm...@aol.com> wrote in message

>> 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 .
>
> Because DOS and ProDOS disk operations do not poll between blocks, not
> because of anything fundamental.
>

Yes, that was EXACTLY my point. I did not claim there was anything
fundamental here, but I was just pointing out how smooth and nice
the UCSD system was. There no question that the applesoft system
could have bee built differently, but it was not. I did think
there was ANY OTHER possibility or conclusion in what I had pointed
out? Was there????

>
> Although you used it only as an example, it is not difficult to see
> how one design team could choose to implement it and another might
> not.
>

Sure, I have software running on mainframe systems in several countries
around the world. The developers that use my editor and screen builder
systems will find that in some places I do flush out the type ahead buffer.

As for the disk drive and the ability of UCSD to poll the keyboard between
each disk block read, I am betting that a fast typist would be able to skip
some chars with the floppy, but with a hard disk, it was even smoother.

Really, all I can say here is that at the end of the day the UCSD was just a
smooth well behaved system that I can't ever recall it freezing up on me as
compared to the applesoft environment in which I did have to resort to the
rest-button many a time...

I have many fond memories of working in applesoft and even in the 6502
assumer.

However, my experience in writing lots of software in the UCSD Pascal system
was nothing short of an great all around high quality experience.

That little tiny 8 bit 6502 was sure the little engine that could! Despite
such limited hardware, the overall experience of the UCSD was high quality,
ran smooth, ran well, and was simply real a joy to use. The UCSD system
changed my mind that little desktop computers were not toys anymore.

On the other hand, I did bust up and wear out the "L" key playing castle
wolfenstein on that same computer. If I recall correctly, I flipped the key
underneath with one of the shift keys to
return that L key to working order.

I have not fired up my Apple II in many years. I still have that apple II,
and it has a working 10 meg Dovong hard drive attached to it...

--
Albert D. Kallal (Microsoft MVP)
Edmonton, Alberta Canada
pleaseNOO...@msn.com

[winston19842005]

On 12/6/09 4:32 AM, in article NSKSm.40366$ZF3...@newsfe13.iad, "Albert D.
Kallal" <PleaseNOOO...@msn.com> wrote:

I'm impressed. The only version of UCSD I've used, IV.0 on a TI-99/4A, the
type-ahead buffer does not work during disk access. So, if I'm typing during
disk access, characters are dropped (usually all during the actual
read/write) and then it picks up from there.

I have to wonder if other concurrency is affected (such as sprite lists,
where you can program a series of sprite commands to be executed
concurrently with your program).

And the TI has a timer interrupt. As a matter of fact, the TI-99/4 did not,
and required such a modification to add one to use UCSD Pascal in the first
place. And the system configuration file (whose name fails me now) has the
proper setting for "Uses Clock=YES", which supposedly helps make disk
updates more efficient.

But your example of disk reads during keyboard typing is a bit strange to
me, an apparent physical access to the drive for each keystroke? I would
expect some buffering to take place - so that even on the TI I could type
without character loss until the next block is read into the buffer
(blocksize being 512 bytes on the P-system).

[Albert D. Kallal]

"winston19842005" <bjjl...@NOSPAMbellsouth.net> wrote in message
news:C7428EA9.11B11%

> But your example of disk reads during keyboard typing is a bit strange to
> me, an apparent physical access to the drive for each keystroke? I would
> expect some buffering to take place - so that even on the TI I could type
> without character loss until the next block is read into the buffer
> (blocksize being 512 bytes on the P-system).

I had built my own custom input routine...and if I told the compiler to
dynamic load this, it was un-loading after each call to the char input
routine (which was in Pascal)....

So, it was a custom char input and edit routine written in Pascal...not an
built system one...

[Michael J. Mahon]

Albert D. Kallal wrote:
> "winston19842005" <bjjl...@NOSPAMbellsouth.net> wrote in message
> news:C7428EA9.11B11%
>
>
>
>>But your example of disk reads during keyboard typing is a bit strange to
>>me, an apparent physical access to the drive for each keystroke? I would
>>expect some buffering to take place - so that even on the TI I could type
>>without character loss until the next block is read into the buffer
>>(blocksize being 512 bytes on the P-system).
>
>
> I had built my own custom input routine...and if I told the compiler to
> dynamic load this, it was un-loading after each call to the char input
> routine (which was in Pascal)....
>
> So, it was a custom char input and edit routine written in Pascal...not an
> built system one...

I'd expect it to stay loaded until either explicitly unloaded or
replaced by another dynamically loaded unit--at least that's the
way I've implemented dynamic loading in the past. (If there's
sufficient available space, I'd cache them with LRU replacement.
Of course, space is tight in an Apple II, but routines can be quite
small. ;-)

[DaveSchmenk]

On Dec 7, 7:34 am, "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com>
wrote:

snip

>
> Really, all I can say here is that at the end of the day the UCSD was just a
> smooth well behaved system that I can't ever recall it freezing up on me as
> compared to the applesoft environment in which I did have to resort to the
> rest-button many a time...
>
> I have many fond memories of working in applesoft and even in the 6502
> assumer.
>
> However, my experience in writing lots of software in the UCSD Pascal system
> was nothing short of an great all around high quality experience.
>
> That little tiny 8 bit 6502 was sure the little engine that could! Despite
> such limited hardware, the overall experience of the UCSD was high quality,
> ran smooth, ran well, and was simply real a joy to use. The UCSD system
> changed my mind that little desktop computers were not toys anymore.
>
> On the other hand, I did bust up and wear out the "L" key playing castle
> wolfenstein on that same computer. If I recall correctly, I flipped the key
> underneath with one of the shift keys to
> return that L key to working order.
>
> I have not fired up my Apple II in many years. I still have that apple II,
> and it has a working 10 meg Dovong hard drive attached to it...
>
> --
> Albert D. Kallal    (Microsoft MVP)
> Edmonton, Alberta Canada

> pleaseNOOSpamKal...@msn.com

Apple Pascal was my introduction to structured programming and I have
fond memories of it also. I loaded Apple Pascal 1.3 on a CFFA -
rather wasteful without subdirectories but the performance improvement
was amazing. Truly a development environment ahead of its time (at
least for micros).

As Michael alluded to earlier, building an interpreted environment
allows one to incorporate features not easily implemented in the
native environment. My 6502 Java VM (VM02) will run a scheduler pre-
emptively even without a timer interrupt after interpreting 256
bytecodes (and check the keyboard, too). Not unlike the UCSD system's
keyboard polling during execution of p-codes. The UCSD system just
lacked a scheduler and a threading architecture. Timing is an
estimate at best without a true clock source, but it works
surprisingly well for simple tasks.

In fact, I would argue that pre-emptive scheduling on an Apple II
isn't all that necessary. Devices that need interrupts to function
well like the serial card and mouse card support interrupts. I only
wish the Uthernet card had hooked up the IRQ line :-
( Multiprogramming as in cooperative multithreading should cover just
about all the real-life cases you could fit in an Apple II. Just
playing around with a scheduler to handle such an environment is very
instructional and forces you to deal with the idiosyncrasies of the
6502. Adding pre-emptive scheduling (with or without actual timer
interrupts) on top of that is fairly trivial. This is exactly how I
did it developing VM02.

Dave...