Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!pro-pac.cts.COM!tsouth From: tsouth@pro-pac.cts.COM (Todd South) Newsgroups: comp.sys.apple Subject: Re: Serial Cards AND rehooking of I/O Message-ID: <8805221916.AA08586@crash.cts.com> Date: 22 May 88 14:17:12 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: pnet01!pro-simasd!pro-pac!tsouth@nosc.mil Organization: The Internet Lines: 80 In Article: <6141@sigi.Colorado.EDU> williamm@tramp (Michael Williams) writes: > : > 000F SEI ; Disable Interrupts <--- Do I really want this ??? > : > 004C TEST LDA KSWL ; Determine if entered from KEYIN > 004E BNE OUT > 0050 CPY KSWH > 0052 BNE OUT ; If not, goto OUT > 0054 LDA #7 ; If KEYIN then set serial > 0056 STA KSWL ; input entry and goto SERIAL IN > 0058 BVC NOAC ; (V clear if came from START, initial entry) > (NOAC is a Serial In check, to which SIENTR) > (eventually goes) > 005A OUT LDA #5 ; If entered from COUT > 005C STA CSWL ; set serial output entry and > 005E SEROUT ... ; Code for the Serial Out > : > > Problems: > (a) At 000F, should the Interrupts be disabled? Is it the > responsibility of the software to re-enable them? Yes and No, it all depends on what you are trying to do with the code. If you are going to make it so that it runs on something like *ONLY* a 300 baud modem then even though protocol says you need to handle interrupts, I doubt that you will seriously have to worry here. But, believe me! If you are going to use ProDOS it would be adviseable to include interrupt handling. Also, make sure that you only turn off interrupts for the SHORTEST TIME POSSIBLE!!! The only time in your code that you need to disable the inter- rupts is when you ACTUALLY read in the character. If you turn it off for long periods (as you apparently have in the above code) you will start losing data on a regular basis. This is why circular buffers are real popular ways of getting modem input, mate! > (b) Within TEST, It appears that the input entry is rehooked to --07, which > is SERIN, by modifying KSWL (Keyboard Switch). But wouldn't KSWH need > to be modified to $CN (N is the slot number)? Else, the input will > simply be rehooked to a routine at $0007, not $CN07. Huh? Where'd you get that? You need to realize (I think) that the code you are writing is intended to replace the ROM code. This means that it will already have setup the KSWL/H and CSWL/H when it is initialized, if you follow old and accepted techniques. If these vectors are setup, you can only access the slotROM areas which are kicked in when the card is initialized. This means that the $Cn number will not change as long as that is the active card. > (c) Same for the output rehook. CSWL is modified to --07, which would set > the rehook to SEROUT *if* CSWH were modified to $CN as well. > > From the SEROUT and SERIN routines are called COUT1 and KEYIN, which will, > I believe, make a connection to the standard 40-colmn routines. > These will need to be modified as well, but for now I am simply trying to > understand the rehooking of the input and output. Read above... > > --> If ANYBODY has ever worked with rehooking the I/O, maybe you can help me > with this. ESPECIALLY if you have ever setup a system for 80-colmn, but > at this point not even that is necessary. What you need (I hate to say it) is a copy of the Super Serial Card manual. It is damn worth the price of the card, as the *fully* commented ROM source listing will teach you much! It shows some really neat tricks for chaining the 80-column firmware, and allows you to chain into non-standard 80-col's also. > Eternal thanks to any help, > Remo Todd South -- UUCP: {nosc, ihnp4, cacilj, sdcsvax, hplabs!hp-sdd, sun!ihnp4} ...!crash!pnet01!pro-simasd!pro-pac!tsouth ARPA: crash!pnet01!pro-simasd!pro-pac!tsouth@nosc.MIL INET: tsouth@pro-pac.CTS.COM - BITNET: pro-pac.UUCP!tsouth@PSUVAX1