Machine Code Made Easy - Part 28
Author
Description
From Fred 42
He's back! Yesssss... after a few issues in the wilderness
(England) I'm back for Christmas. And here's a bit of a festive
pressie for you, my fans (!) who have all missed me terribly, I
know. Oh shut up.
I won't bore you all with the details of my 8 weeks of drunken
debauchery. I don't think I can remember much of it anyway.
Suffice to say that "Student Life"'s a bit of a piss-up.
For anyone who's actually interested, I'm doing Maths and
Computer Science. I've been given Email facilities too, and if
you wanna drop me a note (for whatever perverse reasons you
might have) my address is:
<<address redacted>>
While we're on the subject, my home address has changed too:
<<address redacted>>
And during term-time:
<<address redacted>>
Now you can start sending me stuff again! Mind you, I won't have
my SAM with me down south, so I won't be able to look at discs
until the holidays.
Right, on with the show. Driver's been selling really well, and
all those customers are going to be needing some more luverly
applications and utilities. Within a week or two of the official
release Darren Clarke had finished writing a game called Mosaic,
so it can't be as difficult to understand my notes as I thought!
A few other top names in the SAM programming world have
expressed serious interest in doing stuff.
We're looking to release some kind of Driver Development Kit
shortly, which should consist of a customised version of Comet,
Driver and a whole bunch of documentation. I expect you'll have
to pay for it, with discounts if you already have Comet/ Driver,
but you'd get your money back as soon as you produced something
for Revelation to publish.
In addition, there are some more applications (including Alarm
Clock, Calendar, Art Grabber, Paintbrush, Cardfile) and other
bits and pieces coming out soon(ish) on a Driver Extras disk.
Details as soon as I have them.
Okey dokey, back to business. This is the last part of the
Driver special (unless I can think of something else for next
time), and I'm just gonna cover odd bits and pieces that we've
got left over.
CLIPBOARDING
Now I made great claims about clipboarding in the Driver manual.
You know, stuff about cutting bits from one file/ application
and pasting them in elsewhere. And I stand by it all - it is and
will be a great facility, especially when more applications come
out. And it's pretty darned easy to use.
Essentially, the clipboard is just some memory, reserved like
application data when it is needed and looked after by some
Driver routines. There are two ways applications use it: Cutting
(putting data on) and pasting (taking data off).
To this end, there are four jump table entries, as I mentioned a
few months back:
" 120. JCUT: Cut BC bytes from HL onto the clipboard. BC must
range from 1-256 and HL must be in the application page. CY is
returned if the clipboard is full. (It can grow as long as
memory allows)
123. JPASTE: Paste BC bytes from the clipboard to HL in the
application page. BC must be from 1-256. CY is returned if there
is no data left, with BC holding the number of bytes left
unpasted.
126. JEMPTYCLIP: Empty clipboard, releasing all its pages, and
reset the JCUT pointer to the start.
129. JRESETPASTE: Reset JPASTE pointer to the start of the
clipboard. "
These simply allow the application to wipe the clipboard clean,
add some raw data onto the end and read the raw data back again.
To structure things a bit better, we need rules to describe what
the raw data represents.
Let's call the things on the clipboard "objects": an object
could be a piece of text, a picture or whatever. You can fill up
the clipboard with as many objects as there are room for.
Each object is given a four byte header:
0 Object type
1-3 Object length (excluding header) in page/ offset form.
Since the clipboard is a serial store, to read an object later
on, you have to read through all the ones before it. It might be
the case that your application can only deal with certain data
types, in which case you read the headers and skip over any
unwanted ones, using the length in the header to guide you.
At the moment, there are only two object types:
0 ASCII text, with Epson control codes. This is the type used
by Notepad: the control code sequences begin with CHR$ 1 and end
with CHR$ 3, with CHR$ 2 in between the numbers. This lets
applications ignore control code strings should they wish.
1 Unmasked graphic block. A rectangular block, with some
addition parameters after the header (these bytes are, of
course, included in the length in the header):
0 Mode (0-3)
1 block width, in bytes. (0-255: the block need not necessarily fit on the screen)
2 block height, in lines. (0-255)
3.. graphic data, in raster lines one after the other.
Of course, there can be more than 2 types! It's up to
application writers to create new types and document them fully.
Subsequent applications might want to be able to deal with these
types, and thus the applications could share data. And before
you ask, Notepad, alas, cannot cope with graphics. Yet.
Using the four jump table entries is really easy, but the
routines vary so much from application to application that it's
pretty pointless giving you anything other than hints for your
cut/ paste routines. Firstly, you have to do things in blocks of
256 bytes (or less) which means having a buffer space inside the
application code. Before pasting, reset the internal paste
pointer, and don't forget to empty the clipboard when necessary.
Apart from that, it's really just a case of copying data from
your appliction data pages to the clipboard and vice versa.
I would suggest using at least three editing options:
Cut (Copies the selection and removes it from the file)
Copy (Copies the selection and does nowt else)
Paste (Paste from the clipboard and then empty it)
Notepad also has a "Multiple paste" option, which doesn't empty
the clipboard.
WRITING APPLICATIONS
Finally, after five or so months, we finally get to the bit
about actually putting the theory into practice. I used
SC_Assembler 256k on a 512k machine to create the source for my
Driver applications: this leaves half of the memory untouched
and available for Driver code and graphics, and application
data. (NB. When I was writing the Driver code itself, I needed
all 9 banks in SC_512, so I used an external meg for the File
Manager data.)
Anyway, using SC_256 meant installing Driver to page 16, and the
Driver data to page 18, without the keyword (the system heap is
filled by the assembler). My application object code was
assembled to pages 1/2, so I poked EDITOR.FLAG with 1 (the first
page number) before initialising Driver. Stuff about running
Driver without the keyword is detailed in the manual.
EDITOR.FLAG is at an offset of 1Eh into the Driver code, and on
initialisation is copied into the second slot of the Driver
application table, after File Manager. (Normally, its value is
FFh, meaning "empty").
You can do this for any page you like, but page 1 seems obvious
to me. Of course, until you put the application name at 80F0h
and icon at 8100h, the Driver Desktop will show garbage, and
before assembly any attempt to run the application would result
in a bit of a crash! You can design the icon using Iconmaster.
Finally, before even loading Driver, I reserved all the memory I
was going to use with OPEN TO 16: CLEAR 25000 or something like
that. This customised version of the assembler Basic let me
assemble the source, and return directly to Driver to test it.
Easy.
So, there's nothing to stop you buying a copy and programming
away right now. I expect that LERM and COMET can be altered
similarly to have Driver in memory, so you have no excuses!
DRIVER DATA
Right, finally for this month, here are details of the Driver
Data page. Some budding artists out there might want to re-draw
so of the graphics, or the character set and create alternative
driv??.dat files. It can also be useful (if a bit naughty!) for
applications to fiddle with data directly. Sprites are in the
form described for the pointer routines, and the icons are in
the usual raster-line format.
NB. REMEMBER THAT THE DATA PAGE NUMBER IS STORED IN SVAR 5C98h.
Offset Description
0000
-07FF Sprites (2k)
0800
-0FFF Character set (2k)
1000
-27FF Window data tables (6k)
2800
-37FF Blocks, icons & other graphics (4k)
3800
-3FFF Workspaces (2k)
SPRITES
0000 Arrow
00C6 Hourglass
01CC Arrowed cross
03F2 Caret
CHARACTER SET
The chars (ASCII 32-127) are stored as 16 byte blocks, using 4x8
fat pixels. Driver uses these as 3x7 fat pixels, so the two
least significant bits, and the last 2 bytes, should be left
blank. The data is NOT the same as with the ROM character set,
in that the graphics are stored absolutely, in pen 3 on paper 0.
(ROM sets are bit-mapped)
WINDOW DATA TABLES
The LSB of an address in a tables corresponds to the window
number 0-255, except in the window order table and the names.
1000 Order table.
1100 Types: D0 Reset to clear the window when drawn.
D1 Set for name.
D2 Set for close gadget.
D3 Set for move gadget.
D4 Set for size gadget.
D5 Set for x-scroll bar.
D6 Set for y-scroll bar.
D7 Set to make window selectively active.
1200 X coords (fat pixels).
1300 Y coords.
1400 X sizes (fat pixels).
1500 Y sizes.
1600 X-scroll bar positions. (0-255)
1700 Y-scroll bar positions.
1800
-27FF Names. (4k. 16 bytes per name)
OTHER GRAPHICS
2800
-29FF 8x8 blocks. Each 32 bytes long.
Numbered 0 - Move gadget
1 - Close gadget
2 - Size gadget
3 - Up gadget
4 - Down gadget
5 - Left gadget
6 - Right gadget
7 - Y scroll bar
8 - X scroll bar
9 - Scroll bar indicator
10 - Switch gadget (off)
11 - Switch gadget (on)
12 - Small file icon
13 - Small folder (closed)
14 - Small folder (open)
15 - Small folder (highlighted)
2A00
-2BFF Button icons. 32x16. 256 bytes each.
2A00 - Off
2B00 - On
2C00
-2FFF 16X16 icons. 128 bytes each.
2C00 - Attention (! in a triangle)
2C80 - Disk on blue background
2D00 - Disk on blue (highlighted)
2D80 - Printer
2E00 - Printer (highlighted)
2E80 - Disk on white
2F00 - Info. (i in an octagon)
2F80 - Question (? in octagon)
3000
-35FF 16x24 icons. 192 bytes each.
3000 - File Manager
30C0 - File
3180 - Folder
3240 - Folder (highlighted)
3300 - Bin (empty)
33C0 - Bin (full)
3480 - Bin (empty, highlighted)
3540 - Bin (full, highlighted)
WORKSPACES
Numbered 0-7. Each 256 bytes long at 256 byte intervals from
3800.
There you go then. I should be producing a complete technical
documentation for writing applications for the development kit,
but I've covered pretty much everthing I think. Stay tuned for
the next dramatic twists in the success story that is Driver...