|Issue 5||"Spectrolysis: Channels & Streams"|
As promised in our July issue, Ian Beardsmore continues his quest to open up a new stream to a new channel. Read on and check out his progress ...
Last issue, I was rambling on about
streams and channels, hoping to excite
the nerve endings of any readers out
there who could help me in my quest to
open up this little-known area of Spectrum knowledge. Well, for all those of
you still asleep in the back row, I've
managed to come up with most of the
answers - so, this month, I will be providing you with a routine to open a new
stream to a new channel! |
OPENING TIMEOpening a stream can be performed simply though various POKEs - the problem comes in creating a new channel. Whereas the streams area is absolute (the start of which is pointed to by the systems variable STRMS) the systems variable CHANS holds an address or vector which can, and does, move.
All this work was done on a Spectrum devoid of an Interface 1 unit, though the routine should be usable with said unit attached. Unexpanded, the Spectrum uses seven channels: -3 to -1 are for internal use, leaving Channels 0 to 3 for us to do something with. However, if we do use one of these it will have to be at the expense of the screen, keyboard or printer (yer pays yer money, etc). Much better, then, to create new space filled with channel data of our own channel - hence the need to CALL the 'make space' routine from the ROM!
As far as Sinclair Research is concerned the stream number is synonymous with the channel number, and as such is a source of confusion. While it's a useful rule of thumb, it's not a necessity. In theory, it would be quite possible to have, say, 16K of channel space ... but there are limitations - namely that only stream and channel numbers between zero and 15 (inclusive) will be accepted. In the example I have given, the output routine of our new channel - Channel 4 - points to an
address 62100, where it is presumed that a routine of our own devising would be stored.
A note about offsets is also needed. An offset is a number that, when added to the base address of a block of data, will give you the address to start working from. The routine included in this article uses two offsets: one a channel offset, to show where the channel data for our routine starts; the other, a streams offset, is the number of bytes into the streams area that the above offset is stored.
I said last month I was hoping to assemble a routine that would allow you to attach your own streams to your own channels - the channels being your own routines. This proved even more awkward than I had expected and took some time to accomplish. For the present, I'll only give the assembly listing and explanation.
One point to keep in mind when trying to CLOSE channels greater than Channel 3 - there's no endstop marker on the Lookup Table, which might just have some of you whizzing merrily through the ROM until the program finds some number that's acceptable.
CRASH THEORY CONTINUED
Further investigations into the 'Fun Crash' I gave you last month (well, it's a lot less energetic than a Fun Run!) have shown that CLEAR 64000 is not quite unique, even though it does seem to have some properties that are distinctly its own. But, in fact, a similar effect can be obtained with these addresses - 33024, 41472 and 51465; can anyone spot what they have in common? If highly intelligent readers of Your Spectrum cannot, then no one will. And what if I add a couple more addresses that can also be used, such as: 32000, 32256, 32512, 49152 ...?
Yes, no prizes for knowing that any address with a low byte value of 00 Hex will produce a similar sort of crash, though with nothing like the same spectacular pattern. I started to wonder what was so special about every 256th number that it produces a screen display,
whereas any other (leastways, the others
I've tried) results in a simple crash. Then
I discovered that the incomparable Sir
Clive had another trick up his sleeve -
my fine theory itself crashes, literally, at
address 52736. |
So far as I know, only one address above this produces a display before the crash - when the computer NEWs itself - and that's the well-tried (and far more interesting) 64000. But, hang on ... "Before the computer crashes and NEWs itself ...", do I hear you exclaim? That wasn't mentioned before! Well, I was just testing your alertness. The fact is that though 64000 seems to produce a continuous display, all the other addresses mentioned earlier do it to a regular time sequence.
Here's a very exciting graph - well, maybe not that exciting, but still quite interesting. The y axis represents time in minutes, and the x axis the address (always remembering that only every 256th address applies). There's a clear relationship between when the display starts coming up on-screen and when it NEWs itself. Obviously, the three addresses - 52480, 52736 and 52992- are the interesting ones, as here the pattern is completely broken, never to be repeated. I have left the 64000 display on for half an hour without it NEWing, so I make the assumption that it's permanent.
Now, all I want are some explanations ... any takers?