Disk Logging Desk Accessory ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Log all disk i/o and display as required. copyright Keith Bedford August 1989, may be used and distributed freely. To Install: Copy to bootdisk as dsklog.acc and reboot (in any resolution). The RWABS vector will revectored to the program and all subsequent i/o routed through it. Details of each i/o will be logged, including the time between actually initiating the i/o and a response being received. When the memory buffer is full (120 entries as released) logging wraps around to the start of the buffer. To display log: Invoke as any other Desk Accessory (from leftmost option of Gem menu bar), note that any Gem program should allow access. A window is opened and the last (newest) page of log data displayed as below: Op Dk Sctr/count Buffer Rslt/Secs where Op is the operation (Read or Write) performed on disk Dk, which started at sector Sctr for count sectors to or from buffer. The return code was Rslt and the operation took Secs to complete. Page through the log entries using the elevator or scroll by using the scroll arrows. The window cannot be fulled, resized or moved. Other windows can be topped and manipulated and the log window returned to. Disk i/o will continue to be logged whilst the log window is open, however the display will start to get confused. Close the window to exit. Applications: As cache programs work this way it provides a good way to decide which cache mechanism would be best to use, run your favourite editor / compiler / word processor / spreadsheet or whatever and then see how the i/o's were performed. Some programs read lots of single pages even when several could be read at once, these will benefit from a read-ahead cache, ie one that reads a complete track (or 10 sectors) in the hope that the sectors following the one requested will be asked for next. Other programs always read as much data as possible, these will benefit more from a cache that keeps the most frequently accessed sectors in memory. Different disk formats can be tried to see which gives the best results (ie fastest transfers) and you can see where delays occur. The last disk operation a failing program performs can be determined, typically PD programs expect resource or data files to be somewhere obscure that was blindingly obvious to the programmer but not to you! And the error messages are usually gibberish (Err #53) or misleading. If you can navigate around a disk you can now see the last directory that was read. Two example uses are documented in ramdisk.tst and fformat.tst. Bugs: Sometimes the DA refuses to run from the Menu bar, I can't discover why but believe its a Gem problem (no programmer believes his programs are faulty!). Although the program works in any resolution, changing resolution whilst it is installed will crash the ST and require a RESET. I dont know why this is, I believe I've seen similar problems with other DA's, does any bright spark know what the problem is? Possible enhancements: The missing Gem window functions could be added, I didn't think they were required for this application but someone might. The buffer is cleared by RESETting, it could be kept in high memory with a checksum attached to it, on booting the DA should verify the checksum and if ok keep the log data already in the buffer. The size of the buffer could also be changed dynamically. The log could be output to a disk file or printer. I have released the source file to allow anyone to make any changes they require, and also use it as inspiration for writing their own Desk Accessories and Gem programs. Programming notes: Desk Accessory: As can be seen from the source file - dont release unrequired memory, do connect to AES, register as a Desk Accessory supplying your menu text and drop into Event-multi to wait to be called. Messages will arrive that aren't for you - check that the message is an accessory open and carries your application-id before acting upon it. Never exit from a Desk Accessory, just go back to Event-multi. The hardest thing about Desk Accessories is testing and debugging them, its best to do as much testing as possible as a program which can be executed directly or under a debugger. The source file contains comments on changes to be made to run DKLOG as a program for example. Gem Windows: Release unrequired memory, connect to Aes, open your window, lock Gem whilst you are updating it, release Gem and drop into Event-multi to wait for user instructions. When you get a message check its for you then carry it out and back to Event-multi unless the message was close-window, in which case exit the program (assuming a simple single window program). Many of the routines in the source file can be re-used, as follows: Open window ~~~~~~~~~~~ opnwndw: Parameters on stack: +18 - screen column for first window column +16 - screen row for window title +14 - number of columns in window +12 - number of rows in window +8 - text for title +4 - text for information line Processing: Find graphics handle, open a virtual workstation, saving handle. Calculate screen resolution from number of colours, convert character coordinates to pixels. Calculate window position and size and create. Set title and info line and open window. Set writing mode (replace) and clipping rectangle. Set colours and clear window. Define writing area within window. Set mouse shape (not needed for Desk accessory). This window will automatically be used by the following routines. Lock Gem ~~~~~~~~ start_update: No parameters Processing: Remove cursor from screen Lock Gem Clear window ~~~~~~~~~~~~ clrwndw: No parameters Processing: Fill window with white space Write to window ~~~~~~~~~~~~~~~ wrwindow: Parameters passed on stack: +4 - horizontal co-ord +6 - vertical co-ord +8 - text address Processing: convert co-ordinates to pixels copy text to buffer until first non-printable character display buffer Unlock Gem ~~~~~~~~~~ end_update: No parameters Processing: Return cursor to screen Unlock Gem Set window elevator size ~~~~~~~~~~~~~~~~~~~~~~~~ windsize: Parameter on stack: +4 - size of window as a function of buffer size Processing: Call Aes to set size of elevator Set window elevator position ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ windpos: Parameter on stack: +4 - position of window within buffer Processing: Call Aes to set position of elevator Close and delete window ~~~~~~~~~~~~~~~~~~~~~~~ closewindow: No parameters Processing: Close virtual workstation Close window Delete window Call AES ~~~~~~~~ Parameter: D1 ->parameter list, on return d0.w = intout Call VDI ~~~~~~~~ Parameter: D1 ->parameter block Note the use of pre-defined parameter blocks for most Aes and Vdi calls, it is usually most efficient to let the assembler do the work for you, both in speed and size of generated code. Leave Basic programmers to set up enormous parameter blocks at run time.