twhgbo (01/11/83)
Re: ihuxx.297: Osborne I Comments/Questions TIMER for OSBORNE I You are correct about the O-1 having had a timer program built in to the ROM. I have an Osborne with the version 2.1 ROM which still updates a clock for hours, minutes and seconds, if you preset it with a user program. The version 2.1 ROM was installed with a (free) upgrade in January 1982, and with the up- grade the originally supplied user program (entitled SETUP) disappeared; a new version of SETUP was supplied, which did not offer to set the clock. However, it turned out that the original program still worked, so I could set the calen- dar and the clock, and the clock continued to "tick" as long as the system was powered up and not RESET. Now I have noticed that the current version of the system does not maintain the hr:min:sec clock, and have wondered how it was done on mine. I have disassembled the ROM, but have not completely analyzed it. However, I do know the following: 1. The system does use interrupts (or at least one). It is set into interrupt mode 2 at power-on. The interrupt appears automatically to place the system in "shadow" mode, so that the interrupt vector points to a location in ROM rather than RAM. The one interrupt vector which I have discovered is located in RAM at 0EFF8H, and transfers control to the timer routine in ROM. It appears that the interrupt occurs at 60 hz. (every 16.67 ms.), and its main purpose is to refresh the display. The timer update routine is a part of the refresh proced- ure. Clearly, the display refresh procedure must still be part of the ROM, and it would be reasonable to suppose that it is still handled by an interrupt vector- ed to the same location (0EFF8H)--simply because of programmer inertia. I sug- gest that one could vector the interrupt to high RAM, and deal with the clock update there, then return control to the appropriate location in ROM for the display refresh. 2. I needed a timer which was faster, and adjustable, in order to write a terminal program which operates correctly (without dropping characters) at 1200 baud. For this I studied the operation of the REFRESH register. It turns out that the R register cycles from 00H to 0FFH in about .25 ms. A simple loop which examines the R register upon entry, saves the result, and repeats until the new contents of the R register is numerically *less than* the old contents will count one "tick" approximately every .25 ms. An outer loop on the B register, using DJNZ, can be used to count the ticks needed to accumu- late the desired number of milliseconds (say 8-10 for each character at 300 baud, about 2 per character for 1200 baud). [True--the first entry into the inner loop may give a "short tick"--less than .25 ms. The remaining entries will be reasonably accurate.] T. W. Hildebrandt UNC-Greensboro