crew@pro-harvest.cts.com (Chris Wicklein) (06/25/90)
I was talking to somebody about how to handle keyboard interrupts to create "DA's for 8-bit IIs". I have a possible solution. When a key is pressed on an Apple //c an IRQ is generated by the 6551 running the second serial port. The //c can then optionally place the keycode in a buffer. Why not install in IRQ handeler that checks for, say the pressing of OA-D (for desk accessories) by waiting for a 'd' or 'D' then checking the paddle. This might just work. The IIgs has a similar opt. key buffer, so it might function in a similar manner. The above details are sketchy, and may not be technically correct, but they're a start. ARPA: crash!pro-harvest!crew@nosc.mil INET: crew@pro-harvest.cts.com BITNET: crew%pro-harvest.cts.com UUCP: crash!pro-harvest!crew "This message is strictly fact or my opinion."
jeffn@nuchat.UUCP (Jeff Noxon) (07/01/90)
In article <9164.apple.net.info-apple@pro-harvest> crew@pro-harvest.cts.com (Chris Wicklein) writes: > > I was talking to somebody about how to handle keyboard interrupts to create >"DA's for 8-bit IIs". I have a possible solution. > > When a key is pressed on an Apple //c an IRQ is generated by the 6551 >running the second serial port. The //c can then optionally place the keycode >in a buffer. Why not install in IRQ handeler that checks for, say the pressing >of OA-D (for desk accessories) by waiting for a 'd' or 'D' then checking the >paddle. This might just work. > > The IIgs has a similar opt. key buffer, so it might function in a similar >manner. The above details are sketchy, and may not be technically correct, but >they're a start. Desk Accessories on any 8-bit II would be tricky to accomplish. I was unaware that the 6551 generated an interrupt for a keypress, and this is probably incorrect. It would cause unsuspecting programs to go bonkers. It would be possible, however, to make a very simple modification (possibly one wire) that would associate a tap on the keyboard with a 6551 interrupt. The best way to do this in my opinion would be to use a clock card for preprogrammed timed interrupts, say every quarter-second. During the interrupt you would check the keyboard register and PB0 for the values you specify. If they match, you would axe the clock interrupts (we don't want to activate our DAs more than once) and bring up your DAs. It all sounds really great, but there is a really big problem here: ProDOS leaves no safe place in RAM for any of this to reside without being clobbered by other programs. My solution: Make a very SIMPLE and CHEAP peripheral card with a static RAM on it. The DA "loader" can locate the card by trying to change bytes in the slot ROM space. After it finds it, it can be loaded with interrupt handling code and interrupts enabled. Not much Sram is needed. 256 bytes is sufficent, but if you wanted to use the C800-CFFF space that would be an option. The Sram is cheap and makes it very easy to prototype the firmware, and provide updates. All this handler will do is save a block of memory to [hard] disk or to an extended RAMdisk. It can then overlay the rest of your desk accessory program and transfer execution. When you're done, the program is loaded back in, interrupts are re-enabled, and you pop back to what you were doing. I'm no EE, but if someone would tell me how to build the 5 minute card I described, I would even do it. Jeff -- Jefferson Eric Noxon | In front of every silver lining is a dark jeffn%nuchat.uucp@uhnix1.uh.edu | cloud. jeffn@nuchat.uucp | 713/721-6820 (CDT) Houston, TX |