_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That is actually pretty interesting. And it looks like it wouldn't be too hard to make it understand BBC VDU codes instead of minicomputer rubbish.

I'm not familiar with the BBC VDU, so I can't opine on ease or difficulty. The process would fundamentally be the same as implementing the WYSE 60 command set, in that a leading <ESC> would be used to indicate that a command follows. You could use almost any method as long as a command can be unambiguously identified in the incoming data stream.

Where the VT-100/ANSI/ECMA48 method is a pain is in it using ASCII numerals that have to be internally converted to binary to be usable, as well as the general "wordiness" of commands. ASCII numerals make it friendly for someone writing code to run on a DEC mini, but not so friendly for the bloke writing the terminal's firmware and trying to parse a command whose command "word" is the final character of the sequence.

What I like about WYSE's approach is the character immediately after the <ESC> tells the terminal what it is supposed to do and also indirectly tells the terminal how many datums to expect after the command "word." That makes parsing much less complicated than in the VT-100 scheme. A sorted look-up table can be used to determine which command is to be processed and code specific to that command can then be run to parse the remainder of the command. Even in assembly language, it would be simple. Simplicity of implementation is why most general-purpose terminals have WYSE 60 emulation (also, the 60 was the most widely-used terminal right up until use of dumb terminals died out—I estimate I installed several thousand of them over the years).

As far as implementing a different command structure in Geoff's design, there are one or two source code files that would have to be edited and then the entire mess would have to be compiled and flashed. It would be akin to a bare metal project, except you'd be programming in C instead of assembly language (my understanding is PIC assembly language is pretty unfriendly). You'd also need a PICKit or similar to actually flash the MCU. That can be done in-circuit if a suitable header is present, as is the case on my unit.


BTW, here is a pic I took of the PCB before assembly.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Right, so the VDU commands are a lot like the WYSE ones, but approximately one byte shorter - because they don't have an ESC prefix. Instead the ASCII control codes (1-31) are more thoroughly used, as most of them are redundant in a post-1960s world. But some of them are well-defined in ASCII, but bizarrely not used by the VT, while they are used for their original purpose in VDU.

Anyway… there's not much hope of 100% BBC Micro compatibility in this little terminal device. But many of the VDU codes can be usefully implemented.

There are two cursors and windows, for text and graphics. The text cursor is defined in character cells, and the graphics cursor in pixels (or fractions thereof). VDU codes 4 and 5 switch text printing to begin at the text and graphics cursors respectively. Graphics plotting always begins at the graphics cursor. By default both the text and graphics windows cover the whole screen.

VDU codes 8, 9, 10, 11 (BS, HT, LF, VT) move the text cursor by one cell in each direction. Code 12 (FF) clears the text window, and code 16 clears the graphics window. Code 13 (CR) moves the cursor to the start of the current line. Codes 14 and 15 switch on and off, respectively, a "page mode" which halts the display after scrolling through a screen's worth of text.

Code 17, which takes one post-byte, sets the text colour. If the MSB of the post-byte is set, it actually sets the text background colour. For a monochrome display, only the least-significant bit of the colour value would be significant.

Code 18, which takes two post-bytes, does the same for the graphics colour. The second post-byte is similar to text colours. The first post-byte sets the plotting mode (eg. replace, invert, XOR, AND, OR); normally this is left at 0 for "replace".

Code 19 takes 5 post-bytes and is used for setting the colour palette and low-level programming of the video hardware. It's probably fine to just read and discard the post-bytes.

Code 22 takes one post-byte to change screen mode. This could be used as an escape to switch back to VT mode.

Code 23 takes nine post-bytes and is used to redefine characters in the screen font, nominally in an 8x8 matrix.

Code 24 is used to define the graphics window. Eight post-bytes provide the left, bottom, right, top edge positions in graphics coordinates, 16 bits each. Subsequent graphics operations (and text drawing from the graphics cursor) are clipped to that window.

Code 28 does the same for the text window. Only four post-bytes are needed, since the coordinates are in character cells.

Code 25 is the general graphics plotting command. Five post-bytes; the first gives the graphics operation to perform, the rest is just a pair of coordinates. A short history of coordinates provided to this command is used to complete commands that need more than one pair; eg. a triangle fill requires two history entries plus the new coordinate. There is a "move" command which does does nothing except update the history. The latest entry in the history serves as the graphics cursor.

Code 26 restores both windows to the full screen.

Code 29 moves the graphics origin, taking four post-bytes. By default it's at the bottom left of the screen (positive up and right).

Code 30 returns the text cursor to the top-left position. Code 31 takes 2 post-bytes and moves it to an arbitrary position.

Code 127 backspaces and rubs out the corresponding cell.

Code 27 (ESC) is unused.

I've skipped a few that aren't relevant…

Well, the VT-100 doesn't use the random ASCII control codes for other stuff because doing so would break strict ASCII compatibility - and when DEC was in its heyday, it was still far from being a "post-1960s world." I don't know how much vintage data-processing equipment ever really made use of the more esoteric control characters (I always got the impression that most of the gear used for that kind of thing was oriented towards IBM and EBCDIC,) but there would've been value in not breaking compatibility, even if you weren't going to make actual use of those functions.

Right, but what about the cursor movement codes? I see ESC sequences in the VT manual for performing those, when just one byte would suffice.

Unfortunately, if you're not relying on eight-bit transmission of what is technically a seven-bit character code, there aren't any places to fit in more elaborate one-byte cursor controls; aside from the really basic ones like tabs and backspace (which may well be interpreted as printing whitespace rather than just moving the cursor,) there are no direct cursor control codes in the set, and no free spaces to put any ($80-FF being not technically part of the standard.) ASCII was already well-established before anyone needed it to print to a screen (the very first standalone video terminal wasn't even announced until four years after the standard was established, and it would be well into the '70s before CRTs would really supplant teletypes in most installations,) so the makers of ASCII terminals just had to make do with what they had.

Which isn't to say that the VT-100 standard isn't over-engineered and an inefficient use of bandwidth; even DEC's own VT52 had a more condensed (if more limited) set of escape sequences. But eh, what're you gonna do?

Which could make them ambiguous in the real (i.e., ASCII) world where a common standard is required. What you have described is a very narrow and specific hardware example.

<ESC> was defined in the ASCII standard so a receiving device could unambiguously detect when the following character(s) are to be interpreted in some way instead of being sent on to be displayed. Even the Commodore 128 used escape sequences to affect the video in some fashion, thus insulating the programmer (BASIC or otherwise) from having to know anything about the video driver or the underlying hardware.

In the timesharing BASIC dialects that were developed during the minicomputer era (and are in use to this day), the abstraction was even greater. For example, to print flashing, reverse video text to the terminal, one could write PRINT 'BR','BB',"Flashing Text",'EB','ER' in their program and the BASIC interpreter would generate the escape sequences needed to turn on reverse video ('BR') and flashing ('BB'). Internally, the character string would be tokenized to <ESC>BR<ESC>BBFlashing Text<ESC>EB<ESC>ER, the <ESC> bytes telling the interpreter that the next two characters were a display control command. The programmer didn't have to know anything about the terminal's command language, as the interpreter would take care of that.

That said, this topic isn't really one about how to control a display. Whatever floats your boat is the right way to do it. However, standards do have a purpose and the use of <ESC> to tell a device that something special is coming is nearly universal in computing—for example, any printer that understands PCL is using escape sequences. It's been that way since I started back in 1970 and will probably stay that way into the foreseeable future.


...which is why the VT-100 command set evolved the way it did. DEC was a laggard when it came to adopting 8-bit serial transmission, opting instead to stick with 7 bits with parity. By the mid-1980s, parity in terminal interfaces was dying out (it really didn't have any purpose, as a framing or other error would immediately be obvious to the terminal user) and 8N1 had become the de facto standard. I can't recall the last time I configured a terminal server to use parity (parity does live on in some serial data acquisition devices, such as credit card readers).


Dunno about "over-engineered." More like "over-complicated." Even after 8-bit ASCII became commonplace, DEC stuck with their scheme, apparently as some form of vendor lock-in (it didn't work—WYSE and others added VT-100 emulation to their products).

As I earlier said, the more compact WYSE 60 command structure had a lot to do with that terminal's overwhelming success (also, the quality of its display was a factor). In a complex screen layout in which there are many fields requiring many cursor-plotting functions, bandwidth consumption on the slower serial interfaces of the 1980s was a real concern. For example, sending four bytes to position the cursor (WYSE) instead of eight (VT-100), multiplied by 15 or 20 such commands per screen significantly reduced bandwidth consumption in a large installation (in the past, I routinely installed systems with 30-40 terminals, all running off a single UNIX box). Reducing the total outflow reduced low-level kernel processing, since serial I/O in those systems was interrupt-driven.

Getting back to the topic, a change of terminal personality definitely can be done if one is familiar with C and knows the details of the terminal to be emulated. I understand that a development environment can be downloaded from Microchip's website and installed to write code. A PICKit is needed to flash the MCU. The genuine Microchip PICKit costs about 50 USD through the usual electronics sources. There are Chinese clones that vary in quality. As always, caveat emptor.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Part of my Ruby project has a BBC VDU to ANSI converter so I can drive Minicom on my desktop from Ruby and have it understand all (almost all) the standard VDU commands including a function key hack/remap o-tron. That happens inside the ATmega host processor though but it wasn't hard to put together. If you can upload a new image to the PIC then it should not be too hard.

At boot time Ruby detects an ANSI terminal or a Ruby Terminal - the latter is my own SDL terminal application that runs on my desktop that does the VDU decoding directly.

this:

https://www.youtube.com/watch?v=rPGCT0lah4Q

is a C program running on Ruby that draws circles. the circle drawing is just:



which ought to be familiar enough to Beeb enthusiasts.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

PIC32MX chips are clocked at around 50Mhz and with its 5 stage pipelining it achieves around 70+ MIPS. Most the screen drawing is done by DMA transfer to an SPI peripheral initiated by some timer interrupts. I suspect the code is idle most (>90%) of the time.

Decoding the ASCII number strings isn't taxing the PIC. Its taxing the 65C816 when it generates them.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

There are PICs and there are PICs. Old 8 bit PICs, although I never had the misfortune to have to use them, indeed look pretty ghastly. But this one is a PIC32, which means it isn't a PIC at all. PIC32 is actually MIPS. I've done a fair amount of MIPS programming (the Playstation 2 used one), and once you get used to the branch delay, it's a rather pleasant experience. Full 32 bit, plenty of registers, and no ugly hacks (apart from the branch delay).

But it's also a very good target for compilers. Most of the time there's no need for assembly.

IMHO, the VDU codes are no more ambiguous than using the ESC prefix.

Except for DEL ($7F), all of the VDU control sequences are introduced by a code below 32, which is detectable with a simple NOR gate (2-NOR in 7-bit ASCII, 3-NOR in 8-bit). Detecting ESC specifically requires a full 7 or 8 bit comparison respectively, which at minimum requires two cascaded 4-input gates (one NAND, one NOR) to perform the 7-bit detection.

Now, suppose you pick up a console stream in the middle of transmission. How do you tell if the very first character received is in the middle of a control sequence? It is equally difficult in both cases. The only advantage to the ESC prefix is that its relatively likely that the logic will synchronise to the correct sense of control versus data in a short period of time. But in the case of WYSE, it is not guaranteed because the ESC code is valid in the interior of control sequences. So in fact it is still ambiguous.

It *is* possible to design a console protocol that is unambiguous. Is that a project we should initiate?

And no status register or hardware stack!! (It has conditional instructions instead)

Here's a bit from one of my lockdown projects, a PIC32 native Forth. This is the = ( n1 n2 -- true/false ) word.

The 'lw/addui' recover the next on stack (nos) from memory. The 'seq' compares the top of stack register (tos) to the next on stack (nos) and sets tos to either 0 or 1 which the 'neg' changes into 0 or -1.

The MIPS assembler has lots of synthetic instructions. In this case 'seq' is translated into an 'xor' which will result in a 0 only if the values are the same and 'sltiu' (set less than immediate unsigned) which sets v0 to 1 if v0 is less that one and zero otherwise. The 'neg' is mapped to a subtract using the 'zero' register to get 'tos = 0 - tos'.

This is actual generated code:

The 'jr ra' (jump to return address) is like a return from subroutine but while the first instruction from the return address is being fetched the following 'sub' (neg) is executed in the 'delay slot' as it is already in the execution pipeline.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Feel free, but let me draw your attention to this: https://xkcd.com/927/



-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I've used Geoff's design too as a dedicated composite video display. Quite a versatile little gizmo.


I do plan on building up a terminal too, but will probably just layout my own board as I'll likely not need all the options.

One interesting note, if you want to plot a dot you can use the circle command and set the radius to 0. It would be nice to have a special command to plot a dot. Between 11 and 15 characters is a lot just to get a single pixel lit up.

_________________
Bill