sam-falvo
commented
8 years ago Course correction: My attempts at implementing blitter logic into STS has fallen flat; my next approach is to just fall back to an Atari ST-inspired BIOS. See #197 .
That means no PutChar, either, since the BIOS emulates a simple printer on the screen. mgia_chrout has margin fault logic baked in. I suppose it can be changed in the future; however, starting simple.
larsbrinkhoff
Spent much of yesterday addressing this problem, perhaps a bit indirectly.
What I'm looking for here is a system library (either resident in ROM or on secondary storage) that I can open whenever I want access to the user's display. In the Kestrel-2 version of STS, this was known as
LIB.textiface, since it offered a simple, textual interface that more or less emulated a glass teletype. I have programs where a glass tty emulation would be ideal (the shell, for instance); however, I also have programs where emulating a block-oriented terminal would be ideal (e.g., frankly, most programs), and still others where random-access would be ideal (e.g., a text editor).My original plan was to transcribe
LIB.textifaceto the V1.5 for the Kestrel-3, but I realized, if I had a general purpose blit utility, I could support not just fixed 8x8 fonts like I have been, but also proportional-width fonts, as well as printing various text styles like bold, skewed (emulated italics), underline, etc. The blitter would also provide a single, if unoptimized and relatively slow, facility for drawing horizontal and vertical lines as well as rectangles. In other words, this facility would provide a high degree of leverage. So, I spent yesterday working on several different implementations of blitters, and finally settled on a design that I'm happy with. I've documented the final design in #192.The second thing I worked on w.r.t. generating textual output is how to handle the discrepency between simple direct access and glass teletype emulation. The solution is to issue callbacks when what you want to print will fall off the right-hand edge or the bottom edge of what you define as the current window. This is inspired by GEOS/64's own
PutCharandPutStringsystem calls. GEOS actually uses this facility to implement greedy word-wrapping as well; I'll need to study how that works later. For now, I'm just happy to have the option to wrap text raggedly in a "window", of not wrapping at all (just advancing to the next line), or of aborting the print operation completely. Or, something else entirely. I can provide standard, system-provided callbacks for the most common cases, of course. Libraries first, frameworks second..So far as I can tell, to satisfy the needs of the STS Shell, the order of authorship in order to get this issue closed is:
Bitmapas an abstract data type.PutCharincluding relevant callbacks.PutStringis defined strictly in terms ofPutChar.Note that I do not mention a character matrix above. A character matrix is necessary for emulating block-oriented terminal interfaces, or for 8-bit Commodore-style text editor-based interfaces. However, I would argue that these are specialized interfaces for specific kinds of applications. And, on second thought, with a blitter and its concomitant ability to draw rectangles and lines at our disposal, the need for block-oriented/panel-based textual interfaces diminishes since we can just launch regular GUI applications.