BigDumbDinosaur wrote:
Have you done that for the Picaso µVGA-II SGC module?
Nope, I don't have one.
BigDumbDinosaur wrote:
Quote:
Save for the most simple of applications on consoles (i.e. a serial console), you will likely need an addressable buffer representing the display anyway...
All this is is a console. I'm not trying to, nor interested in, replicating the screen kernel of a C-64. As you will soon see if you study the Picaso µVGA-II SGC's command set, a cursor is not a simple matter, nor is line-by-line scrolling (although the latter can be simulated with some built-in functions).
That's because the Picaso is NOT a Console. It's a VGA frame buffer with high level commands to talk to it. So, "of course" you'll have to roll a "console like" behavior out of it. Save, perhaps, for the hardware cursor, you'd be in the same boat with an old school CGA card: scrolling, wrapping, etc. etc.
If you had intended to have any kind of application that used the screen as more than a "glass tty", an internal buffer is effectively required, especially for anything like a text editor.
The command set looks straightforward. At its core, you effectively have GOTOXY and PUTCHAR. With these you can "do anything". With the added PUTSTRING, you can do some things more efficiently. With the Screen Cut/Paste, things (notably scrolling) get much faster. Your worst case is a screen repaint where every single character is a different color and font (and you would need to create your own fonts for BOLD and UNDERLINE if those at all interested you). In that nightmare scenario you need to send, for an 80x25 screen, 6 * 80 * 25 = ~12,000 bytes (more if you're playing with fonts). At 115KBaud, that's 1/10 of a second. Meaning you'd get, at best, 10 frames/sec of full frame text animation. Not great.
Naive Scrolling (including insert/delete line) can fall under that meme of "full screen animation", but with the screen cut and paste, you can do it with ~500 bytes. That's much faster.
The two issues with the blinky cursor are the necessity of a screen buffer so it can know what character it is over, and the coordination of the cursor state and access to the display. Simply, this display gives you the worst of both console worlds. It's a graphics device, meaning you have to manage the entire screen yourself, but at the same time it's a serial device, so you can't just "draw on VBLANK" from the screen buffer (because a screen repaint is simply too slow). So the blink cursor has to be managed and coordinated with the regular output stream to the device. Simplest way it probably simply having some internal lock, and use that to gate access to the display.
Your primitives can be "cursor aware" so they know that if the cursor happens to be lit at the moment, they can keep it on when they draw their data, meanwhile the interrupt driving the cursor checks the lock and if it's not available, it simply bails until next time, otherwise it rewrites the character underneath the current cursor position.
You're right, this code is a distraction, but frankly it's as much of a distraction as the PC keyboard decoding software you would need (and were apparently planning) to write as well. If you didn't mind having a static (non blinking) cursor, it's even simpler as that's really the only messy part of the system.
Login
Register
FAQ
Search
Although a home-brew computer could instead incorporate some sort of video display controller, Picaso already has the RGB output circuitry and VGA connector. It also has an SD memory card adaptor (with low level or DOS compatible access)! And Picaso needn't be attached to the computer in question. As a stand-alone unit it could be used with different projects as required.
