sburrow wrote:
The Pages will have to wait until I can get my screen scrolling vertically.
I think, at this point, I'd suggest splitting the editor and framebuffer support out and treating them as 2 separate entites:
- An operating system (or monitor if you like that sort of thing) function that does the screen/frambeuffer handling.
- Many applications all using the same OS/Monitor calls to do their screen handling for them.
And this is nothing new - early 6502 systems I used - the Apple II and the BBC Micro both did this - the Beeb in a much more "thorough" way, but that's the advantage of 4 years later, faster clock and more ROM...
And think of all those systems with terminals, printing, "glass ttys", vt100s, and whatnot...
My own Ruby does this too - although it has to by virtue of using a serial line to the framebuffer - the question might be how do you control the FB - do you have OS calls (Like the apple II to clear screen, position cursor, etc.) or do you output control codes (Like the Beeb).
The control code method has the advantage that you can then hook up a serial terminal if so desired...
The question then is what codes? Go all-out and go for ANSI/vt100 or something else?
Some time back I ported my RubyOS to the Cerberus 2080 system - it has an on-board framebuffer. I opted to keep the same control codes for applications and write a separate framebuffer handler. This hooks into the "putchar" mechanism and interprets the codes. The Acorn/BBC Micro ones are fairly simple (at the text level). The important ones are clear screen (12), move home (30) and move to XY (31, X, Y) The other usual ones - move cursor to start of line (CR, 13). Move cursor down a line (LF, 10 - causes a scroll if moving down from the bottom line) move cursor up a line (11, VT, scrolls the screen down a line if on the top line), left and right (8, 9). There are a few others (colour, graphics), but that's enough to make a working screen.
So even though it could, an application (e.g. BBC Basic) could poke pixels/characters at the screen, it doesn't - it just prints it and lets the operating system do the hard work. This may seem a bit odd when the code and framebuffer are all in the same memory space, same CPU but the Beeb was designed to have a 2nd processor, leaving the original one - the host - to handle screen, keyboard, filing, network, etc. with your code running on the 2nd processor. (And people are still using this today with more and more new 2nd processors coming on-board inlcuding the '816, RISC-V, PDP11, etc.)
What's missing in the Acorn/Beeb codes that's handy for an editor: clear from cursor to end of line and clear from cursor to end of page. Those can help an editor or other application manipulate text on the screen. I added them into my system - BBC Basic doesn't use them, but C (on the 6502) and BCPL (on the '816) applications can.
The up-shot of my Cerberus port was that BBC Basic "just worked" and all it's built-in commands like CLS, etc. worked as intended. (as they do on my Ruby system). the Ruby system has the advantage of having the framebuffer run on my Linux desktop and is written in C, but there is still that 115K baud line going into it.
And it's not that hard to translate Acorn/BBC code into ANSI codes - my ATmega "host processor" does that transparently, so I can hook up a terminal to it and the BCPL editor works as normal - as does BBC Basic...
So - separating the video/framebuffer code and you're starting to build on the monitor/OS - and you can make that code as optimal as possible. Scrolling an 80x32 text window can be blindingly fast when you keep a list of screen line start addresses and unroll the loop. applications can be smaller as the OS the offloading the IO functions more efficiently and life is fun...
And as part of something I'm working on, I have a 20x4 LCD hooked up to the Ruby board and I adapted my framebuffer code for that (and make it fairly generic), so I have in RAM a 20x4 byte framebuffer and I can write into that which then gets copied over to the LCD - it's not slow either and it means I can scroll the LCD up and down, move the cursor, make my editor work on it and run BBC Basic on it. The applications stay the same.
Cheers,
-Gordon