★ APPLICATIONS ★ DIVERS ★ Compacted listings are easier on your fingers ★ |
| Data64 (Computing with the Amstrad) | Applications Divers |
IAN SHARPE shows how to cut the key tapping THE worst thing about magazine listings is having to type them in, particularly reams of meaningless data statements containing machine code. At least Basic makes some sense as you enter it. Normally we manage to get 13 bytes and a checksum on each line with our current 40 characters wide column. The hex numbers are in a string and MID$ is used to extract each byte when the code is being poked in. Wouldn't it be nice if there was a way of compacting the information so that there were fewer characters to type in? Program I will turn an area of memory into data statements and include them in a Basic loader. It has the added bonus that two bytes (or a word) will only occupy three characters rather than the usual four. This allows us to get 18 bytes in a data statement and there is still room for the checksum. The compaction is achieved by working in base 64 instead of base 16 (hex). There are two main uses for this program. Submitting work to Computing with the Amstrad is the most obvious, but whenever you mix Basic and machine code and don't want a separate binary file, this method will use less memory than a hexadecimal loader. On the Amstrad it is possible to deal with numbers as single bytes in the range 0 to 255 (FF in hex) or as doublebyte words between 0 and 65535 (FFFF in hex). A normal loader works a single byte at a time or at best reads whole words and then splits them into two bytes. When writing down hexadecimal we use the letters A-F to show the extra digits that do not appear in base 10. If we extend this idea to use other characters it is possible to write numbers in bases greater than 16. A minor problem is that if one of these characters is a colon the data would be cut short because Basic takes this as the end of a statement (or delimiter). A look at the character set reveals that the range of characters starting just after the colon at the semicolon and ending at lower case z is just enough to represent base 64. The advantage of this is that the maximum number we need - FFFF in hex - is only three digits in the higher base so we can put more bytes on a line. Figure I shows how two bytes can be split into three characters. The only drawbacks are that the data is a bit less legible and the Basic needed to unravel it is longer than before. Figure I: Splitting two bytes into three characters >> For machine code that runs to more than a few lines of data there is an overall saving in size with the the new loader, and the longer the code the greater is the saving. Data64 uses some machine code to speed things up and get round the problems Basic has with numbers greater than 32767. The loader for this is at the start of the program and is an example of base 64 output. I assembled the code below Basic because any location above it might be in the area you want to turn into data. Before you run the program, lower HIMEM and load your machine code above it. If there is an initialisation routine such as finding out which model of CPC it is sitting in or setting up an RSX, then don't call this before you turn the memory block into data. The program is written with a 40 character wide column in mind but is easily adapted to other widths by altering the values of the loop counters. You will be asked for the start and end addresses of the area of memory you want to save as data, so make a note of this when you are assembling. Conversion is fairly rapid and the results are saved to tape or disc. If you subsequently renumber the program the value of the line number variable In in the error checking routine will need altering. Line 60 in Program I is an example of this. The only unfamiliar character in the data is ' which can be obtained by pressing Shift and I If contributors use this loader for all but the shortest listings we can save space in the magazine for other things and of course, you'll do less typing.
|
