Scor­pio News

the keyboard interrupt vector to see if something has nicked it, if the application has changed it, Sidekick changes it back. Result, the program which ‘took’ the keyboard has now lost it, so Sidekick works, but the application doesn’t. Moral, if you’ve acquired a piece of ‘foreign’ or ‘liberated’ software which doesn’t seem to work, and Sidekick is resident, don’t give up on it until you’ve turned Sidekick off and tried again.

A worse situation than that is where two or more memory resident programs are asked to co-exist together, perhaps Sidekick and something else, say Fred. Can you imagine the fight if they are both polling for keyboard interrupts. Problems of this sort can often be solved by the order in which the programs are loaded. For instance, we already know that Sidekick picks up the original keyboard interrupt vector and replaces it with its own, having processed the keyboard interrupt it passes it on to the original vector. So if we loaded Sidekick first and then Fred, Sidekick would know that the keyboard vector had been changed by Fred and so change it back. However, if Fred were loaded first, we would change the vector to suit itself, then Sidekick comes along second, sees the new vector to Fred, picks that up as the output direction vector and replaces it with its own. All should work Ok, as Sidekick will see any keypress first, and if it’s not for itself, it will then pass it on to Fred. Of course, all that presupposes that Fred doesn’t indulge in the same tricks as Sidekick in the first place.

Mystery Time

Here’s one for the people who like mysteries. The utility called MODE, supplied with DOS, is used amongst other things to set the speed of, and to direct output to, the serial I/O. When executed for the first time, it leaves part of itself memory resident. Now the general way memory resident programs are handled are that they are loaded into low memory and a pointer is set to the top of the program pointing to the next ‘paragraph’ of memory usable as transient program area. Not that it concerns us here, but all programs for 8086 et al ere relocatable in ‘paragraphs’ (16 byte boundaries). Suffice to say, DOS knows where to starting loading the next program. All this takes place with MODE. One of my proprietary programs makes use of this relocatable bit, as there are times when I want to change the UART parameters from inside the program, and it was convenient to ‘RUN’ MODE from inside the program rather than hack some assembler together to do the job properly. It just so happened that there’s oodles of room available on top of the program to accommodate MODE, so no problem – or at least I thought there wasn’t!

After a while, it was found that the applications program ran out of memory if someone indulged in a lot of UART parameter swapping. The answer was obvious, every time MODE was run, it didn’t recognize that it had been run before, and so left the resident part behind, reset the load paragraph pointer upwards, and so slowly filled the memory until the application hiccupped and copped out. Ok? But how come MODE knew if it had already been run from DOS and didn’t leave the resident part behind then? Well I didn’t twig that quite so soon, as I didn’t initialize the serial I/O from the AUTOEXEC.BAT, but I did fire up Sidekick in the AUTOEXEC. I checked with a couple of other customers to see if this problem had occurred, it hadn’t, the only apparent difference was that they initialized the serial I/O in the AUTOEXEC and weren’t using Sidekick. Prewarned that Sidekick did naughty things. I turned it off, but it no difference, the memory still filled up. So it looked as if Sidekick could be eliminated.

Then I tried executing MODE before executing the program, and the problem went away. In other words, I guess (but I’m not sure) this is what is happening. By executing MODE first, the resident part is left in the rock bottom lowest part of RAM. The next time MODE is executed, it checks to see if it already exists, but it only checks at the lowest address in RAM. If it finds itself, it doesn’t bother to leave the resident part behind, if it’s not found, then the resident part gets left. So now MODE gets executed in the AUTOEXEC, followed by Sidekick – end of problem – only I’m not entirely happy about my explanation – they don’t say anything about that in the manual, it seems right, but does anyone know for sure?