23 August 2004 Editor plans I want to explain where I'm going with this Karig thing — just because it is nice to have a look at the larger picture once in a while. Karig Karig won't be a "finished" operating system for writing documents, listening to music, or surfing the Web. It will be a programmer's toy — an integrated development environment (IDE) that would allow me not only to polish my coding skills and to teach myself about graphics programming, but also to experiment with the I/O ports and thus with the hardware. Karig will be the system that I will use to piece together a "real" OS, should I decide to do so — a real operating system with memory protection, interrupts, multitasking, and so on. So I hope to make Karig so that it can reboot the system to run the other OS, and so that the other OS can exit and reboot Karig. Karig will essentially be a block editor. Blocks will be one-kilobyte chunks of storage. Karig will work with blocks instead of files — that is, Karig won't have a file system; it will simply load data from and save data to blocks. This will be possible because the blocks will be numbered, starting with block zero at the beginning of the disk (or partition), and ending with the highest-numbered block at the end of the disk (or partition). Karig will provide two graphic screens. The first screen is the editing screen, which I will use to examine and edit blocks and to compile and debug code. The second screen is the output screen, and the words I write to do graphic stuff such as drawing lines or shapes or fancy lettering will draw on this second screen, so that the first screen is not disturbed. Editing screen The editing screen will have three parts: the block viewer, the status bar, and the shell. Block viewer The screen consists of thirty lines; the middle twenty-eight lines are reserved for the block viewer. The block viewer displays the contents of the current block. Karig will offer keys to display the contents as one kind of data or another. At a minimum, I will need to see blocks as:
The block viewer would need to display where in the block any new text would go, so it must show a cursor. It probably won't be a blinking cursor; it'll probably just be a color designed to stand out against the background. Status bar The status bar is the line of text running across the top of the screen. It would display error messages when there is an error, and at other times it would display the cursor location, followed by a list of interpretations of the binary value at the cursor location. The status bar fields would include the following:
If I add support for editing bitmaps from within Karig, I may also add these fields to the status bar:
So a typical status bar might look like this: ![000000BC 3FF K 4B534944 [blue-gray] 091A13](stat.png){kind=small}
I might also add a field to display the current cell as precode — that is, as the first letters of a word, printed in the color specified in the precode cell. I should also add a field or two to display the top item on the data stack — as cell value, precode word, and four ASCII characters. Each "screen" would show the block contents as one particular type of data, but the status line would show the cell at the cursor as all of the supported data types. Shell The shell is the line running along the bottom of the screen. When the user types, the text appears in this line. The typical way to change data in the block, or to do something in general, will be to type some text into the shell and then hit a command key. The command key selected will determine what Karig should do with the text. Thus there will be a command key to do each of the following:
Another way to do something, of course, is to hold down a key while hitting one or more letter keys. I'm considering giving Karig an incremental-search feature: You'd hold down a FIND key while typing text, and as you hit each letter, the cursor would move forward to the next instance of the string you'd typed thus far. (If the string is not found in the current block, Karig would keep searching until it finds a block with the string.) This is similar to the LEAP command on the Canon Cat. Commands Karig will have various keystroke commands for moving around. You'd be able to jump forward to the next byte, cell, precode word, line (each line being 64 bytes long), and block; you'd also be able to jump backward of course. You'd be able to jump to the block whose ID is in the cell where the cursor is; I'd be able to build and follow data structures out of blocks using this feature. There are other commands I'd like to have. One will switch to the output screen; another will switch back to the editing screen. I'll probably use the editor and compiler to add other commands as the need arises. Conclusion This editor will obviously be a very simple one. There is no facility for highlighting multiple characters or cells; there is no wordwrap; there is no clipboard for cutting and pasting text. The Karig editor will essentially be a hex editor with simple text-editing features, one that allows you to write and compile new features for it from within it, and to assign features to keys. I expect that it'll be a nice toy to play with for a while. However, Karig will essentially be temporary software. I will eventually want to go on and develop the beginnings of a real file system, something that will store strings of data of arbitrary length, rather than just fixed-length blocks. I will want to start building a real OS, with hardware drivers in their own address space, and more flexible memory management, and real multitasking. But I'll discuss my ideas on this at another time. Check the index for other entries. |
