Your Spectrum
Issue 10, December 1984 - QL Microdrive Cache
Home Contents KwikPik
Ingredients required: your QL and a copy of QL Archive. You'll be glad to hear that the following experiments won't affect anything that's on the cartridge. OK, put your QL into SuperBasic and when MDV1_ has stopped spinning, place your Archive tape in the drive. Now, load up the short Basic program used to load Archive. Type:

LOAD MDV1_BOOT

Notice how long it takes to load. Use LIST and you should see the program. Now, get rid of the program by typing:

NEW

Type LIST to prove the program has gone ... there's no trickery here! Now, let's load it again:

LOAD MDV1_BOOT

Well, didn't that load quickly! The QL can't have looked at the cartridge for more than a quarter of a second. Don't believe it? Type LIST and you'll see that the program is back.

THEORY AND FACT

Let's be scientific about this and presume that the Microdrive tape was in exactly the right place to get the program. If it was, it should be just past that program now. Assuming the tape can't go backwards (a fair assumption I think) and even if it could, the QL wouldn't know it needed to go backwards (definitely a fair assumption), then it follows that if we try to load the program again, the QL must have to go all the way round the tape to get it. So, type:

NEW

Followed by:

LOAD MDV1_BOOT

And it did it again, didn't it? So what's going on? Despite the fact that we have NEWed the program, the QL knows it has a copy of it in RAM. All it does is check that we haven't changed cartridges (with that quick quarter-second peep at the tape) and, if we haven't, it restores the program not from tape but from RAM.
You can probably see a couple of potential problems with this. Suppose we change cartridges for an identically named cartridge with a different program also called BOOT on it. This takes a bit of setting up but you'll find that it doesn't fool the QL. When you format a cartridge, the machine writes a random number to the tape along with the name. The quarter-second peep at the tape will tell the QL you've swapped cartridges and it'll actually load BOOT from the tape.

CHANGE THE TUNE

More obviously, suppose we 		title
change the copy of BOOT that's in memory and then NEW it. When we try to load the program again, if the QL uses the version that was just NEWed, we'll get the changed copy of the program back and not the original that we've asked it to load.
So, LOAD MDV1_BOOT if you haven't got it in memory at the moment. Then add lines:

5 REMark Here's a new line
6 REMark Here's another
7 REMark These shouldn't be here when
8 REMark we load the program

Now (roll of drums), NEW the program. And, type:

LOAD MDV1_BOOT

The QL peeps at the tape for a quarter of a second and then loads the program from RAM. Has it fouled-up and restored the changed version of the program? Actually, it hasn't. If you type LIST, you'll see that it's loaded a perfect copy of the original program without having to get it off the tape again.
This is nothing short of clever! Unless I'm mistaken (and Sinclair Research is welcome to say so) the QL is using a 'cache' memory for the Microdrives. When you read some sectors off tape, they're stored in this temporary cache and then copied to wherever they are needed.

SECRET CACHE

Next time you read the 'drives the QL has a quick peep to see if you've changed the tape. If you haven't, the contents of the cache memory are still current. If the sectors you want are in there, the QL turns off the Microdrives and copies the information from RAM instead. NEW really does scrap the program, but there's a copy of it in the cache and thus the QL can load it again very quickly.
Okay, so the QL's got a cache memory. There's nothing dramatic about that as with a little bit of hassle you can get one fitted to many business micros. You can even find the odd one with a cache as standard. However, I did promise 		something out of the ordinary. Normally cache memories are quite small and in a 128K QL (sorry, 96K ... 32K is screen RAM), you wouldn't expect the cache to be very big.

SIZING IT UP

To test the size let's see if we can overflow it by reading a lot of information off the Microdrives. In this case, the cache should overflow and only be able to retain copies of the last few sectors read. Then if we ask for the information again, the QL will have to re-read the tape. So, suppose we copy the contents of the Archive demonstration database to the screen. Type:

COPY MDV1_GAZET_DBF TO SCR_

You'll see the database file in all its naked glory appear character by character on the screen. Keep an eye on MDV1_. Notice that the QL is reading a few sectors every few seconds. It takes a while. When it's finished, repeat the command:

COPY MDV1_GAZET_DBF TO SCR_

Amazing isn't it? The QL checks that you haven't switched tapes and then gaily trots out the whole database file from the cache memory without looking at the tape again!
So just how big is the cache? This little example seems to suggest that, unlike any ordinary computer, QDOS (the program producing these miracles) uses the free memory it has available to form a cache for the Microdrives.

JOKING APART

There must be a lot more things going on to make such a system practical ... if you come up with any further comments let us know. But the practical results of this big cache are obvious ... it's going to be a lot quicker reading stuff off Microdrives than anybody previously suspected. Next time anyone tells you the QL has a noddy architecture or that QDOS is a joke, sit 'em in front of your machine and hand them this article!
Home Contents KwikPik