PDP11 Framebuffer Style n-User Video Display - instead of VT[?]?? terminals author Neil Franklin, last modification 2004.05.15 . = nedded 1 time, * = needed n times, - = feature, ? = facultative Existing terminals are/were: . PDP11 CPU . tty driver (just bytes to/from par/ser converters) . PDP11 Bus . multi(8|16?)-port RS232 card (requires baud rate setting at both ends) * RS232 transmitters + * RS232 recievers * RS232 cables (many wire but still slow) * terminal * RS232 recievers * ASCII <= 31 or even ESC seq interpreter (massive HW bloat, and n times) * upgrade needs new terminal for everyone, as hardwired, or possibly in ROM * cursor position to address computation * timing signal generation, and position to address computation * frame buffer (possibly shift register based) * video screen * beep loadspeaker + * keys * matrix scanner * matrix to ASCII/ESCseq convertion * RS232 transmitters Direct framebuffers would use less parts, reduce cost: . PDP11 CPU . frame driver (incl ASCII <= 31 or even ESC seq interpreter) - many upgrades possible replacing this, just new install for everyone ? separate driver for graphics extension, command chars Tek4014-like . PDP11 Bus . multi(4)-framebuffer card . write address register (cursor position to address from frame driver) . timing signal generation, and position to address computation * frame buffer ? extensible with an 1 channel per card wave or bitmap graphic overlay * video amplifier * video cable (75ohm coax) * video monitor - visual bell, to save sound cabeling/amplifier/speaker + * keyboard - keys (max 64, 48 print-ascii, 2 shift, return/space/tab/corr, cursor, fn?) - matrix scanner (6bit cnt, 3bit 3:8dec, 8x8 matrix, 3bit 8:1mux) or (6bit cnt, 4bit 4:16dec, 16x4 matrix, 2bit 4:1mux) * keyboard cable (4wire: cnt clk/reset, key-data from mux, 5V, GND) (clk up/dn every video line, reset every frame scan back) or (2wire co-ax: self clocked, DC 5V + AC data, GND) * multi(16)-keyboard card (or multi(4)-framebuffer card subsection) * matrix buffer (4* 16words of 4keyb*4bit-each, for fast software scanning) or (8* 8words of 2keyb*8bit-each) (matrix to ASCII or ESC seq convertion in frame driver, when keymove found) Lots of stuff in driver, soft, becomes modifyable, upgradable, more for less: - conversion no cursor control, to ctrl-hjkl, to esc-pos, to ANSI - cursor keys with same set of generated stuff - same correction key either or , delete or ESC seq - support multiple command sets, switchable, for backwards compatible - interpretations of ctrl-num and ctrl-shift-anything - but also include arrow keys, and possible home/end/pgup/pgdn keys - cursor editing of line input, before handing to kernel (avoids line editor limits, without needing RAW mode, process swap) - cursor editing and re-sending of any line, c64-like editors - automatic "more" when more than lines since last user input - scrollback of stuff shown - scroll delete of unwanted output, together with auto-ctrl-c - ti/te scroll away and back in mode for non-scroll paged viewing/editing - screen blanker, and locker using real user password - input line history in terminal, not in shell and fail elsewhere - virtual consoles, multiple /dev/tty[p] behind one set of hardware - split screen for n 1/n-height terminals, n consoles visible - driver als user process, use /dev/ttyp with driver doing fork()/exec() - take over UID from previous login, auto-login further fork()ed shells - re-use terminal without logout killing shell, "screen"-like - I/O multiplexer for teacher/pupil/class showing display and actions - "terminal printer" implemented as file and print to lp on close - visual bell/beep by flashing display - mode line to display CAPSLOCK, INSERT, PRINT, SCROLLBACK[line], --More--, ... - user configs settable by escape sequences, or directly reading file, or ioctl No need to upgrade hardware for any of above only upgrade card (not monitors or keyboards) for better display abilities - 1970 80x[12|25]*64char ([1|2]kx6bit) SRAM|shift + 64*[5..8]x[5..8] ROM - 1975 80x25*256char/attr (1/4 4kx16bit) DRAM + [64|128|256]*8x8 ROM|SRAM (if SRAM sixels for loading font, also allows 8x16char=128x128pix graphic) - or 1975 80*8x102, 64*8x128, 6*80x136, 5*80x163, 4*80x204 (4kx16bit) DRAM or 80*80x204 (2 4kx16bit), or 60*8x204 (1.5 4kx16bit) (sixels for font and direct graphics, needs shifting for 6->8/16bit) or 80*6x204 (2 4kx12bit) (2*6bit wide allows shift-less sixels) - 1980 80*8x200 (1/2 16kx16bit) DRAM, this may be VAX (1/4 16kx32bit) or 80*8x200@2bpp (16kx16bit) DRAM, switchable 40*8x200@4bpp (sixels for font and direct graphics, needs shifting for 6->8/16/32bit) - after this increase res/depth until limit of video monitor (700x500*8bit) or then switch to custom hi-res monitors, with 4x3 aspect ratio, like VT220 addon for stuff not needed for everyone edit-/compiling, only 1 per set of 4 driven by separate open() device, not mixed with text output ? 1970 VT55/VT105-like waveform/curve graphics, parameter SRAMs ? 1975 512x128, 480x204 or 640x204, ev at 2|4bpp, and ev offset registers ? 1980 most likely none, unless main buffer still char cell, or for more bpp Disdvantages - card dependent on PDP11 bus, not usable in other systems - not so bad, as same for all other IO cards and some devices replacing CPU+mem+diskctrl is so much expense that videoctrl no problem - design (16|12)bit for just minimal set of IO registers, so easy portable later in 32bit (VAX) use direct memory map, (1/4 16kx32bit = 620x204) - software is OS dependant, needs porting, but only multi-user OSes - can be reduced by making open source, also adds features, compile for size