PICO vga/uart/ps/2

[drogon]

barnacle wrote:

I'm unclear whether the VDU codes are in-band signalling or separate basic commands. For this use case I need something in-band, hence the (possibly simplified) ansi.

Neil

In-band signalling. Just like ANSI but simpler codes. I was interested in getting BBC Basic running which is why I used the Acorn codes rather than ANSI.

So clear screen (fairly universal): PRINT CHR$(12);

Move to XY: PRINT CHR$(31);CHR$(X);CHR$(Y);

and so on.

BBC Basic has a CLS command which does the equivalent of PRINT CHR$(12); and a MOVE x,y command which does the 31/x/y for you and a few others. Similar for the graphics commands - BASIC turns them into character sequences.

Also to define characters which is easier as the font is always 8x8, so send the code followed by the character then 8 bytes of font data.

VDU 23,240,153,189,219,126,36,60,36,36

then

VDU 240

or PRINT CHR$(240);

Prints the "invader" character.



This is one part of how Acorn separated the "language" from the "OS". So different language ROMs didn't have to worry about screen pokes, etc. As an old time user of the Beeb, I adopted it for my 6502/65816 and ARM SBC projects - my terminal is a smart terminal that run on my Linux desktop that interprets the Acorn codes and does the right thing. This enabled my to run BBC Basic over it using all it's internal text and graphics commands as well as my BCPL system when I needed to do screen stuff - like the editor and so on.

(The ARM port doesn't use Linux but still serialises the calls from the application to the screen but also provides direct calls which are faster as it's all running on the same CPU)

-Gordon

[visrealm]

BigEd wrote:

rather than tiles, which are good for games, perhaps use a linked list of lines - one-pixel lines. Then you can scroll by updating the list. There's a per-line overhead of dereferencing the line address for each line output to the screen, but there's always time in hsync to do stuff so that shouldn't be too bad.

I like this idea. You can pretty much do what you're doing but have a "register" which is the start line. Then wrap it around. Brilliant!

[barnacle]

So many options, so little time

I've just done some rough timings, writing and scrolling 1500 lines of text to the screen, takes about 22 seconds. So that's around 15ms per scroll (the entire screen is scrolled after each line is written), less than a frame, not worried about that.

Neil (somebody optimised movemem() nicely )

[barnacle]

After observing that this test requires 120k characters to be written in addition to the actual screen memory moves, I optimised the draw character routine to replace 128 drawPixel calls per character with 64 direct writes to the display memory, and using some pre-calculation outside the loop.

Which has reduced the time to under 17 seconds...

Neil (must see how much of that is the actual scroll.)

[John West]

BigEd wrote:

I have the vaguest idea there was a system like this back in the day.

I had a similarly vague idea, that maybe it was the Atari 400/800. I never had one of those, but I remember it having some kind of display list.

It looks like an impressive system for the time. To create a display, you write a program for the display list processor. This has instructions like "draw N blank lines", "draw lines in text mode X", "draw lines in graphics mode Y" (these two seem to draw multiple lines, so you'd get full characters in text modes, and be able to fill the screen with graphics without needing hundreds of instructions), and "wait for vsync".

The "draw text/graphics" instructions can also set the address register to read graphics data from, and some instructions are also able to trigger a CPU interrupt.

So you could say

• * Set the address and draw a graphics line
  * draw a graphics line (repeated a few more times)
  * Set the address and draw a text line
  * draw a text line

to get a large graphics area at the top and small text area at the bottom, with no CPU intervention. If you want a gap between them, just tell it to draw blank lines there.

The Amiga's Copper seems a natural development from this (I believe it was the same designers).

[barnacle]

Minor updates today: I timed the two character drawing routines for writing 120,000 characters to the screen: the old version was nine seconds and change and the optimised version just 0.9 seconds - call it eight microseconds per character. Which means I can write incoming data - other than any screen scrolls - ten times faster than a 115200 serial port. I can live with that.

(Hmm, writing the screen with 2,400 characters would therefore take just under 20ms; nearly as fast as moving the memory...)

I've modified terminal() slightly to accommodate 0x0c (CLS) and 0x0a or 0x0d as carriage return. At the moment I have a serial port on /dev/ttyACM0 courtesy of the Arduino framework, which is handy, saves me doing one.

The aim is that there will be Pico buffers for UART incoming and outgoing, PS/2 incoming, and screen outgoing (i.e. to the vga output). I haven't fully thought out the interface yet but I have enough pins for sixteen or thirty-two addresses, chip enable, and read-not-write (if I can work out how to program it ).

First thought of an interface - subject to lots of changes if it doesn't work...

Code: Select all

address   read                 write
0         status bits          status/command bits
1         UART Rx (ACM0)       UART Tx (ACM0)
2         PS/2 char (raw or cooked)
3                              char to write to terminal (vga)
4                              foreground colour
5                              background colour
6/7                            cursor or graphics start 'x'
8/9                            cursor or graphics start 'y'
10/11                          graphics end 'x'
12/13                          graphics end 'y'
14                             graphics command (point, line, square, circle etc)

Still thinking about this, but my idea is that a write to the serial or vga text would immediately call the appropriate routines; similarly a graphics command would assume that the appropriate data has already been loaded.

Neil

[barnacle]

I found a PIO ps/2 keyboard reader, and modified it to fit, so now I can generate text video (or pictures!) _and_ read a keyboard (and talk to the serial port). Still need to add the conversion routine I've outlined elsewhere, but that'll get me to a screen writer.

In fact, I could drag out an old 6502 emulator and put it in the rp2040, and then I could put basic in there with it... wait, stop, that way lies madness!

Neil

[jgharston]

For an idea of the implementation of Acorn VDU sequences, see console C library or even ansi.mac.

[barnacle]

I'm probably not going to go that far; I don't intend to run any BBC software and I'll have single byte direct cursor addressing anyway.

At the moment, terminal() prints a character at the current cursor position and advances the cursor, scrolling down a line or scrolling the whole page up as necessary if it gets past the 80th column, or if it meets a CR or LF. BS (0x08) moves the cursor back and erases the character it finds there, and that's it; everything else gets printed. Largely so that I can use internal rp2040 routines as a quick output if needed.

I want to implement a full-screen text editor at some stage, but the control from that really needs to come from the 6502; terminal() has no way to know what is for example on the invisible line above the visible display, or the invisible line after.

It's always going to be possible to change it later.

Neil

[visrealm]

barnacle wrote:

In fact, I could drag out an old 6502 emulator and put it in the rp2040, and then I could put basic in there with it... wait, stop, that way lies madness!

That's exactly what the PICO-56 does. Emulates a 65C02, TMS9918A, dual AY-3-8910's, PS/2 keyboard, NES controllers, UART, etc. on a Pico. Runs a version of EhBASIC modified with graphics subroutines, etc.

[barnacle]

Well that's slightly annoying... I was hoping to find some timer-counters hiding inside the rp2040 that I might use to generate a ph0 signal without having to do any thinking, but no. Looks like I can do it only by writing a PIO program; not a major issue, it's likely only two instructions, but I'm loathe to use space I have a feeling I'll need for the bus interface.

On the other hand, the ps2 keyboard translator dropped straight in and worked first time. I wonder if I should make ctrl-alt-del force a hard reset?

Neil

[BigEd]

Would the PWM timers be able to generate a clock for you?
https://datasheets.raspberrypi.com/rp20 ... f#page=525

[barnacle]

I kinda skipped over the section; you could be right.

Looks as if it counts at system clock rate - currently 125MHz - so a TOP of 16 would give a ph0 of 7.8MHz. I shall play...

Neil

[barnacle]

And yes, that works fine; frequencies from 1MHz upwards, on demand, no processor load.

Thanks, Ed.

Code: Select all

void start_ph0 (void)
{
  /* set the pwm to GPIO 14 at 1MHz, 50% (ish)
   *  clock is 125MHz, so TOP = 124, trigger at 62 for 1 MHz
   */

#define ph0 14
#define F_TICKS 124
#define F_HALF (F_TICKS / 2)

  gpio_set_function (ph0, GPIO_FUNC_PWM);
  uint16_t slice_num = pwm_gpio_to_slice_num (ph0);
  pwm_set_wrap (slice_num, F_TICKS);
  pwm_set_chan_level(slice_num, PWM_CHAN_A, F_HALF);
  pwm_set_enabled (slice_num, true);
}

Neil
edit: corrected 'dma' to 'pwm'

[BigEd]

Great!