| ★ APPLICATIONS ★ DIVERS ★ MEMDUMP (COMPUTING WITH THE AMSTRAD) ★ |
| Memdump (Computing with the Amstrad) | Applications Divers |
ROLAND WADDILOVE offers an interrupt-driven machine code routine to persuade your Amstrad to give up its secrets A MEMORY dump is a very useful tool for examining each byte of a micro's memory, allowing you to check the state of the variables, check that your machine code routines are working properly and so on. The disassembler in the November issue of Computing with the Amstrad featured such a dump, enabling you to list any part of the Amstrad's memory map in hexadecimal and Ascii. It produces a sort of snapshot of the memory. The contents displayed are what was there when the program was run. If any of the memory locations have since changed it will not show up unless the memory is dumped again and two compared. And it might even happen that the locations you're interested in are themselves altered by the dump program. Under most circumstances this is perfectly acceptable. However sometimes we need to be able to monitor locations to see how they change and what values they range over. Some locations for instance, change quite rapidly, particularly those used by firmware for variable storage. In these cases what is needed is a dump utility which is fast and which corrupts the memory as little as possible. This is the purpose of MemDump - an interrupt-driven machine code routine which sits at &A000 in the memory. Called 10 times per second, it prints the contents of 32 memory locations on the screen. Since it is interrupt-driven it is possible to run another program at the same time, allowing you to monitor how the second program uses memory or the effect it has on the firmware variables. The rate at which MemDump scans memory can be altered easily from as fast as 50 times a second to as slow as several seconds. This should be sufficient for most purposes. To change the rate, alter the value loaded into the DE registers at & A08C to the number of fiftieths of a second required. At present this is set at 5/50ths of a second. The routine adds three new commands using RSXs. The first, iENABLE, changes to Mode 2, sets up a text window and enables the interrupt routine. The second command iDISABLE, disables the routine and the third, IMONITOR, (numeric expression) sets the start address of the dump. The window provides a neater display, the top two lines being used for the dump and the rest of the screen free. Using them will not do any harm though, it just produces a messy display. Changing mode will make the display unreadable, as MemDump uses its own print routine designed specifically to print in Mode 2. The character definitions are grabbed straight out of the lower ROM and poked directly into the screen memory, without using the firmware at all. Why? Well, it would be impossible to print 32 memory locations 50 times a second using the firmware calls, they're just too slow. Program 1 is an assembly listing of MemDump. If you haven't an assembler (shame on you - there was one in our July issue) use Program 2 to enter the hex codes. You don't need to enter the first number, this is the address. The machine code can be saved with: SAVE"MENDUMP",B,&A00,&170 Once you've got MemDump you'll want to use it. One of the most interesting areas of memory to examine is from &AC00 to &B900, which is used by the firmware. The keyboard input buffer is around &ACA0. It may change on the different Amstrad models so you'll need to hunt around a bit. Use |MONITOR to scan through addresses close to &ACA0, pressing keys at random on the keyboard and looking for altered bytes - you'll soon spot the buffer. Basic's variables are stored around &AE00. Here you'll find the start address of the Basic program in memory, if any, its end address, where the variables start and end, HIMEM and so on. If you monitor this area while a program is running you'll find two two-byte locations which contain the address of the line Basic is executing and the address of the statement it's currently executing. This raises many possibilities for future experiments, such as interrupting Basic and changing the pointers so that it carries on executing somewhere else. The Amstrad's memory is largely unexplored, particularly the newer models so you're on your own. Happy hunting!
|
