JOE PRITCHARD starts a two-part article on how to achieve random access filing on the CPC ONE of the major applications for computers is that of -storing data. This is especially true if you've got a disc drive. The CPC uses a system called sequential filing to store information on disc, using Basic's PRINT#9, INPUT#9, and LINE INPUT#9 commands. If you were to attempt to write a simple database to store names, addresses and telephone numbers the following few lines would write a single record to disc: 100 PRINT#9,name$
110 PRINT#9,address$
120 PRINT#9,phone$You could write as many of these to the disc as you wanted, restricted only by the disc size. Even so, this is far more than you could fit into the computer's memory at one time, even if you could use the CPC6128's bank switching facilities. In fact, you would be using the disc surface as extra storage memory for your records. However, there's a snag to this. Figure I shows how information is stored on the disc; you can liken it to a train of connected carriages. If you start at the first carriage and want to get to the restaurant car some distance away, you have to walk through all the carriages between the one you're in and the restaurant car. In doing so each carriage is traversed in sequence; this is a sequential access system. 
Figure I: How information is stored The same principles apply to the records in your name and address file - to get to the 30th on the disc, you have to read through the first 29. To avoid loading all the records into memory - which you often have to do to have large programs - each of the first 29 records would have to be read in with INPUT#9 and discarded immediately before reading in the next. Not terribly efficient, is it? Sequential access gets very time-consuming, especially if there are a few hundred records on the disc. In addition you may want to arrange the records in a file so they're in a particular order such as alphabetical surnames. There are two ways of achieving this: Sorting: A complete new file is made on the disc by reading the old one a record at a time and writing the information out to the new file in alphabetical order. The new file takes up the same amount of space as the original, so it's not very efficient in these terms. Indexing: You set up a second file - an Index file - that holds a series of integers, each representing the position of a record in the original file. These numbers are arranged so that when the database wishes to access the original file in a particular order, it looks at the Index file to see in what sequence it should retrieve the records. The Index file is much smaller than the data file, so this method is quite efficient. Figure II shows the two methods. Both are rather useless on a sequential access filing system; in the case of sorting, you have to make many time-consuming passes through the data file to extract the records in the order you require them. Figure II: Sorting and indexing >> Faster methods of sorting the file would need to access it in some other way than sequentially. And as for indexing, it's not really on; you could generate the index quite happily, but when you came to access the records you would really need to dip randomly into the file to extract the records in the indexed order. You can do this by repeated passes, one pass per index file entry, but as you can imagine, this brute force approach only works on very small numbers of records. The time taken to get to a record in a sequential access system is thus dependant upon how far in the file the target record is. So even if you manage to get things sorted alphabetically, extracting all the surnames beginning with S still means processing A to R first. What can you do? The solution to these problems, and a host of others, is to use a technique called random access. Actually, there's nothing random about it; it means that you can retrieve a single record no matter where it is in the file, without having to go through the records that precede it. Sorting and indexing is simple, and the solution to the problem of getting all the S surnames out is very much easier and quicker. The only limitation is that records usually need to be all the same length. However, this isn't a drawback; it's a good idea to have same length records in a file, even in sequential systems. In fact, all you need is some means of getting Basic to adopt this system of storing information on disc, and you're laughing! Well, this article isn't going to tell you how to modify Basic, but it will explain how you can produce a simple random access system on the CPC with a couple of short machine code routines. I'm going to use the basic unit of disc storage - the sector - as the basis for random access filing. Normally you never need to bother about this; Amsdos and CP/M take care of which tracks and sectors are used for which files, and keeps a record of such information on the disc. When you save a program, Amsdos splits it into sector-size chunks and transfers them to the disc a sector at a time. The sectors used are then recorded as part of the catalogue entry for the file. We will be writing directly to the tracks and sectors, but there are three problems connected with this: - The side of a disc used for this can't be used for anything else. The fact that you've written directly to a track or sector won't be detected by the disc operating system or CP/M because you won't be writing catalogue entries. A DIR or CAT command will have no effect.
- Don't try this technique out on any discs with other programs on; you may accidentally overwrite something valuable.
- You can't access these files with PRINT#9, INPUT#9 or LINE INPUT#9.
Right, having got the bad news out of the way, let's get down to business. The first thing you need to work out is how to read and write single sectors on the disc. You can format CPC discs in three ways - system, data and IBM. The difference doesn't usually cause too many problems but when you're directly accessing the disc, the firmware routines are very strict about knowing which format you're using. For this reason, I'll stick to data format, because it offers more room than the others - there are 40 tracks, with nine sectors per track, each holding 512 bytes. Data format numbers these sectors &C1 to &C9 with the &C indicating the type. Different formats have different track numbers, and if you try reading a disc of one type with a machine code program that's expecting another, you'll get an error. Amsdos on the other hand, gets round this by adapting itself to whichever format is in use. All firmware routines in the CPC are accessed by calling a given address in an area of ram called a jump block which in turn calls the rom routine. The jumpblock for the sector read and sector write routines we'll be using, only exists in a CP/M environment. The routines reside in the extra rom used by the 6128 or 464 plus disc drive, for storing the disc routines -we'll call this the Dos rom. Using any of its routines involves selecting the Dos rom for use instead of the usual upper rom, calling the desired routine, then re-selecting the upper rom. Fortunately there are rom routines that allow you to do this with reasonable ease. The CPC allows a number of roms to occupy the upper rom address space, and gives each a unique identifying select address -usually seven for the Dos rom. You can pass this to a firmware routine called at &B90F to select and enable the Dos rom, then call the rom routines needed. Their addresses can be found using the firmware routine KL FIND COMMAND — the addresses are &C03C for Read Sector and &C03F for Write Sector. Don't forget, these are in the Dos rom and not the Basic rom. For each call, the set up parameters are the same; HL points to a 512 byte buffer to hold the data to be transferred, E holds 0 for drive A and 1 for drive B, D holds the track number and C holds the sector number (&C1 to
&C9 for our data format discs). Finally, you use a further rom call to restore the upper rom. Program I pokes the machine code into memory which enables you read and write individual sectors. Thesef routines are rather primitive, but allow you to read and write sectors from the disc. Assuming you've located the machine code at &8000, a sector can be written with: 1000 REN write a sector
1010 POKE &803E,0: REM drive number
1020 POKE &803F,track
1030 POKE &8040,sector
1040 CALL &800D
1050 RETURNThis will write whatever is in the data buffer at address &8041 to the sector specified in lines 1020 and 1030. To test the routine, I suggest you get a data format disc and try Program II which reads any sector on the disc and displays its contents on the screen. Don't forget to load the machine code first. Of course, all these pokes in Basic aren't very pretty, and it's not always clear what's happening. This can be improved by turning the machine code programs into RSX commands. - I'll provide a listing for this in my next article, when I'll also show you how this technique can be used to good effect in databases and suggest other uses for it. I'll also show you how to write to sectors in safety.
CWTA | ★ AMSTRAD CPC ★ DOWNLOAD ★ |
CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 789 millisecondes et consultée 943 foisL'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko. |
|
|
| 
