Linked by Hadrien Grasland on Sun 27th Feb 2011 12:06 UTC
Hardware, Embedded Systems This is a situation where I need the help of you OSnews readers who are experienced with low-level development on ARM, SPARC, PowerPC, MIPS, and other hardware architectures we have on computers nowadays. The issue is that I'm currently designing the part of my hobby kernel which takes care of interrupts. Although I mostly work on x86 at the moment, I'd like to keep this code portable to other hardware architectures in the future. To do that, I have to know how interrupt handling works on as much HW architectures as possible.
E-mail Print r 0   · Read More · 40 Comment(s)
Thread beginning with comment 464193
To read all comments associated with this story, please click here.
Apple II
by zimbatm on Sun 27th Feb 2011 14:54 UTC
Member since:

I remember on the Apple II, the keyboard would write the current key at a predetermined address, and the "OS" would poll that address to know keydown events and such.

Not sure if it's useful to you though ;)

Reply Score: 1

RE: Apple II
by Neolander on Sun 27th Feb 2011 15:15 in reply to "Apple II"
Neolander Member since:

I certainly don't plan to go that far in hardware support ;) However, it was interesting to read, because it shows that there has been a time where interrupts didn't exist, or at least weren't as widespread as they are now, and makes me wonder why they chose this polling-based solution which sounds spontaneously less efficient.

Concerns about context switch cost or HW complexity, maybe ? I know that Apple went very far in reducing hardware complexity in their early days, the floppy drive of the Apple II being a good example of that too.

Edited 2011-02-27 15:16 UTC

Reply Parent Score: 1

RE[2]: Apple II
by zimbatm on Sun 27th Feb 2011 22:14 in reply to "RE: Apple II"
zimbatm Member since:

Hehe, I don't know the specifics but remember: it was a 1Mhz CPU, 40k or so of memory.

Take the design of a simpel game: init, then loop over: (read keyboard address, calculate action, render new state). In an old computer the challenge was to fit the game logic in that "calculate action" step so that it would not take too long. It is also the days where the display herz would be in sync with the computer herz and you had a fixed set of instructions you can run until the new image is shown (Amstrad?).
Nowadays, the loop would run thousands of times per second and the keyboard polling is a waste at that speed.

It was also the days where the manufacturer would give you detailed manuals with program examples. I remember the AppleII had all it's chips mounted on sockets and where replaceable.

By the way I wanted to verify my sayings. Didn't find the specifics, but I found this cool AppleII doc archive :*~@...
I like how the design is simple. IMO, the tendency is to forget why a particular was introduced and add another layer of indirection instead of fixing that particular to the new needs. Computer history is the solution :-)

Reply Parent Score: 1