mikeod@ico.isc.com (Mike O'Donnel) (12/05/90)
Thanks to the help of some fine netters I just got my
hand on a copy of INTTERM, an interrupt driven terminal
program for a Kaypro. But unfortunately it
doesn't work on my Kaypro. Apparently it works on
other systems. From looking at the code there are a
couple of questions I have.
1. Why is it necessary to wait for the disk drive
to deselect?
2. Why does it relocate handlers into different areas
of memory and could this possibly be stomping on
something.
3. Does anyone have a memory layout and tech. info for
the KPII-84 that they would send me?
Any help and info will be greatly appreciated.
Thanks, Mike O'Donnell
mikeod@itx.isc.commwilson@crash.cts.com (Marc Wilson) (12/07/90)
In article <1990Dec5.155950.22108@ico.isc.com> mikeod@ico.isc.com (Mike O'Donnel) writes: [saga on why INITTERM doesn't work on his Kaypro] >1. Why is it necessary to wait for the disk drive > to deselect? If you don't, your drives will stay selected forever. The Kaypro BIOS has a test loop in the character I/O routines. If you haven't talked to the drives by the time the counter gets to zero, it deselects and turns off the motors. When you run INTTERM, you are no longer using the BIOS, so your drives stay selected. This would be a real problem on the K10, where your HD would stay selected forever. >2. Why does it relocate handlers into different areas > of memory and could this possibly be stomping on > something. It moves itself above 8000h because it needs the ROM in order to talk to the screen. The ROM comes in at 0h-8000h. If an interrupt occurred while the program had the ROM enabled, the interrupt vector would point to a random location in the ROM, not in the program. Result: BLOOOIE! >3. Does anyone have a memory layout and tech. info for > the KPII-84 that they would send me? Yes. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marc Wilson ARPA: ...!crash!mwilson@nosc.mil ...!crash!pnet01!pro-sol!mwilson@nosc.mil UUCP: [ cbosgd | hp-sdd!hplabs | sdcsvax | nosc ]!crash!mwilson INET: mwilson@crash.CTS.COM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marc Wilson ARPA: ...!crash!mwilson@nosc.mil ...!crash!pnet01!pro-sol!mwilson@nosc.mil UUCP: [ cbosgd | hp-sdd!hplabs | sdcsvax | nosc ]!crash!mwilson INET: mwilson@crash.CTS.COM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wieland@ea.ecn.purdue.edu (Jeffrey J Wieland) (12/08/90)
In article <6131@crash.cts.com> mwilson@crash.cts.com (Marc Wilson) writes: >In article <1990Dec5.155950.22108@ico.isc.com> mikeod@ico.isc.com (Mike O'Donnel) writes: > >>2. Why does it relocate handlers into different areas >> of memory and could this possibly be stomping on >> something. > > It moves itself above 8000h because it needs the ROM in order to >talk to the screen. The ROM comes in at 0h-8000h. If an interrupt >occurred while the program had the ROM enabled, the interrupt vector >would point to a random location in the ROM, not in the program. >Result: BLOOOIE! Also, in order for intterm to run on an '83 series Kaypro II or IV, it has to relocate itself above where the video RAM gets bank switched in. I believe that the video RAM is mapped in just above the ROM. Jumping into the middle of VRAM wouldn't be too healthy, either. The '84's use a 6845 video controller, and talk to it through the Z80 IO ports, the video RAM is not memory mapped. The '84's have all sorts of snazzy video attributes, but their video is much slower than the '83's. On the '83's, people have even bypassed the ROM and used the Z80 block move instruction to update the screen to make it even faster (like a lot of PC programs do). Of course, this makes the programs non-portable. On the '84's, it should be possible to talk to the 6845 directly to speed things up. The BackGrounder II screen driver for the '84's does just this. It redraws the Kaypro's screen faster than anything else I've seen. > >>3. Does anyone have a memory layout and tech. info for >> the KPII-84 that they would send me? > > Yes. MicroCornucopia has a schematic and theory of operation for the '84's (and '83's and the 10's also). It's interesting to get even just to read through and say: "Oh -- So THAT'S why it works that way!" I'd give you MicroC's address if I had it here at work. Email me if you want to get it from them -- I'll get their address for you. -- Jeff Wieland wieland@acn.purdue.edu
donm@pnet07.cts.com (Don Maslin) (12/09/90)
wieland@ea.ecn.purdue.edu (Jeffrey J Wieland) writes: > >MicroCornucopia has a schematic and theory of operation for the '84's >(and '83's and the 10's also). It's interesting to get even just to >read through and say: "Oh -- So THAT'S why it works that way!" >I'd give you MicroC's address if I had it here at work. Email me >if you want to get it from them -- I'll get their address for you. >-- Bearing in mind that Micro C is no longer publishing, but is still selling some products, the address is: Micro Cornucopia P.O. Box 223 Bend OR 97709 - don Keeper of the CP/M System Disk | UUCP: {nosc ucsd crash ncr-sd}!pnet07!donm Archives for the Dino(saur)SIG | ARPA: simasd!pnet07!donm@nosc.mil - San Diego Computer Society - | INET: donm@pnet07.cts.com