Device driver model about cpm65 HOT 8 CLOSED

I had to restrain myself to not start writing a SCREEN driver, and first think hard on which functions we really need. Here's what I came up with based on what you wrote before, and what most non-dumb terminals would need:

function number in Y
positions in XA (X,A)
character in A
inhibit in A (true|false)
range in XA (top,bottom)
style in A

0. get driver version number.
1. get screen size.
2. clear screen.
3. set cursor position, clip at last column
4. get cursor position, clip at bottom
5. set cursor inhibit
6. put character on current position, and advance cursor to the right
7. delete character left from current position, and move cursor to the left
8. delete character right from current position, and move remaining characters
   to the left
9. insert empty line, moves current line and all lines below one line down
10. delete line, moves all lines below one line up
11. get key with timeout. (We'd need to define numbers for special keys like
    cursor keys. What about using high ASCII for that?)
12. inhibit key click
13. set text style.
    0 - normal
    1 - inverse video
    2 - bold
    4 - blink
    8 - underline
    ....
    (If a style is not available, default to 0. I suppose the BBC Micro has an
    advantage here in teletext mode?)
14. clear vertical area (top and bottom lines are supplied).
    (vt100 does this by combining deleting and inserting lines)
15. get character at current position?
    (This might be problematic for some systems if the text is rendered in
    bitmap mode, like the VIC-20 port. It would need a separate copy in memory
    of the text screen. Perhaps scratch this, and leave it to the user
    program to mirror the screen in memory if it needs this for, say, a game.)

Also been thinking about an AUDIO driver. Would be nice to have a common API for, say, three channels. I'll think about it later.

And I have some ideas on a 8080 recompiler. Somebody on AtariAge did a rudimentary Z80 recompiler years ago, helping him porting a ZX Spectrum game. It only supported the instructions he needed, so lots of them were missing, and it needed quite some manual intervention afterwards, but the idea is sound.

from cpm65.

I would prefer to omit these ones:

• delete character right from current position, and move remaining characters
  to the left
• insert empty line, moves current line and all lines below one line down
• delete line, moves all lines below one line up
• get character at current position?

The rationale is that if the hardware doesn't support it, these can't be emulated without keeping a shadow copy of the screen (e.g. to insert a character you have to be able to redraw the entire line). This makes it hard to come up with a fallback solution --- consider, say, trying to write a screen driver on top of VT52...

Another command which would probable to useful is clear to end of line. Most terminals support this and I've used it myself for my CP/M-80 vi clone: https://github.com/davidgiven/cpmish/blob/master/cpmtools/qe.c It's also a useful primitive for implementing the other clear functions.

from cpm65.

I agree. What I wrote about 15. get character does indeed apply to 8, 9 and 10, too. Somehow it didn't occur to me yesterday. So omitted they will be.

from cpm65.

Hmm, I think insert and delete line should not be omitted. There are no special requirements for the backend. Just copying screen memory up or down, without knowing its contents as characters. It could be a bitmap. We need some form of scrolling besides line feed at the end of the page.

Perhaps I'm misunderstanding something. I was thinking the idea was to make this work:

Boot with default TTY.
Load platform specific SCREEN driver from the command line
Load ADM3A or VT52 TTY driver from the command line, checks if there is a SCREEN driver, and if so, it overrides the default TTY and uses the SCREEN driver to manipulate the screen. If no SCREEN driver was found, print message and abort.
Run program that needs an enhanced TTY.

Edit: And delete until EOL is indeed very useful.

from cpm65.

I'm thinking of devices which might not have video memory access. For example, an actual terminal! e.g. something like the Ben Eater 6502 SBC hooked up to a VT52 emulator.

I'm thinking that for a computer with video hardware you 'd have:

BIOS (w/ basic TTY) -> SCREEN on real hardware -> full TTY

(although it's probably sensible to embed SCREEN into the BIOS as the basic TTY will likely share code). But for an SBC you'd have:

BIOS (w/ full TTY connected to serial port) -> SCREEN emulator.

I suppose you could put another TTY on it if you wanted...

from cpm65.

Ah, I thought the idea of the screen driver was to abstract away the hardware details of the host system so vt52 can be platform independent. After boot, TTY talks to the hardware or host OS directly. After loading SCREEN plus VT52DRV, TTY talks to SCREEN which talks to the hardware or host OS.

Your SBC example with a full blown VT52 terminal connected to the serial port wouldn't need any of them. Just a raw serial I/O port in the BIOS to the actual terminal that handles all screen related stuff itself.

from cpm65.

Yes --- there's two scenarios here:

• machine with video hardware; it has a platform-specific SCREEN driver, which SCREEN-aware programs can use directly, and programs which want to speak VT52 install VT52DRV.
• machine with a serial terminal; it has a TTY driver, which programs which want to speak VT52 can use directly, and programs which want to speak SCREEN will need to install a generic SCREEN-on-top-of-VT52 driver.

...not that I really expect to see that last, but I would at least like to support it.

I've done a really basic SCREEN for the BBC Micro (because it already has a decent terminal emulator built in) in #27...

from cpm65.

Closing for cleanup.

from cpm65.