PICO vga/uart/ps/2

[barnacle]

I'm following Troy's graphics controller chip series with interest and have been persuaded by the PIO module to move from the STM32 and Nucleo to the Pi Pico - specifically because it has a lot if internal memory and can generate 640 x 480 VGA in 4-bits per pixel without too much trouble.

Immediate requirements were to find a tool-chain that worked. Because the official getting started approach didn't/doesn't work with my Linux Mint setup (it couldn't download MS Visual Code, and apparently couldn't work with a pre-installed flatpak version of same) I looked at other approaches. The CLI approach appears to work, but one needs to keep a careful eye on one's working directory, or the damn thing compiles everything in your directories - which took half an hour.

Also, I wanted to work with C, not Python. I'm not fond of a language which can return '1', "1", or "Tuesday" and still be syntactically correct, and nor do I appreciate the effects of invisible white space...

So as a hopefully temporary approach I ended up with Arduino. I don't particularly like the UI, and the way it handles included files is truly appalling, but I can live with it.

This is a dot display just being used as a character display for now. But I have a number of further steps/issues to resolve:

• The arduino ide does not include the pio assembler. I have located one online here which appears to work: https://wokwi.com/tools/pioasm from which assembled .h files can be included. But...
• I have as yet no idea how to implement the interface between the 6502 bus and the rp2040. I am planning some small number of registers, but some of them may require multiple writes to fill a buffer which in turn is written to the screen.
• On the other hand I can copy my existing ps/2 translate() routine and the ps/2 input is just a shift register, so should be easy.

I started with a build here: https://github.com/Pancra85/VGA_graphics which is itself a rewrite of Hunter-Adams' college course. It took a little work, in particular to uncouple the second buffer and get the full 480 line output (for some reason, I don't appear to be outputting line 479 so still investigating).

However, I have the immediate task working - though I need to find a better font file than the two I have, I have some video working (unfortunately after taking this pic I pushed the auto button on the monitor and it has irretrievably moved everything six inches left... I'll sort it later.)

More to follow when it happens...

Neil

[BigDumbDinosaur]

barnacle wrote:

This is a dot display just being used as a character display for now...

Well, we all now know what you like to slurp while working with your computer toys. 

[Yuri]

barnacle wrote:

I'm following Troy's graphics controller chip series with interest and have been persuaded by the PIO module to move from the STM32 and Nucleo to the Pi Pico - specifically because it has a lot if internal memory and can generate 640 x 480 VGA in 4-bits per pixel without too much trouble.

Looking at the specs of the demo board from AdaFruit it looks like it can handle 15-bpp.
https://www.adafruit.com/product/5675

I'm hopeful I can get 15-bpp at 320x240 but we'll see.

Quote:

Immediate requirements were to find a tool-chain that worked. Because the official getting started approach didn't/doesn't work with my Linux Mint setup (it couldn't download MS Visual Code, and apparently couldn't work with a pre-installed flatpak version of same) I looked at other approaches. The CLI approach appears to work, but one needs to keep a careful eye on one's working directory, or the damn thing compiles everything in your directories - which took half an hour.

Not sure how you have it setup, my structure looks like so:

Code: Select all

/home/kfiresun/src/pipico/
|- pico-skd
`- hello
    |- CMakeList.txt
    |- pico_sdk_import.cmake
    `- hello.c

The CMakeList.txt only has the hello.c listed in it. You can get cmake to recursively read all files in a directory, but if you have a complex project structure that might not be the best idea.

Anyhow, my commands look like so:

Code: Select all

cmake . -DPICO_SDK_PATH=../pico-sdk -DPICO_BOARD=pico_w
make -j22

(Adjust -j22 to the number of threads your CPU can handle)

Quote:

Also, I wanted to work with C, not Python. I'm not fond of a language which can return '1', "1", or "Tuesday" and still be syntactically correct, and nor do I appreciate the effects of invisible white space...

I'm glad I'm not the only one who finds that "feature" of Python horrible. >_<

Quote:

This is a dot display just being used as a character display for now. But I have a number of further steps/issues to resolve:

Quote:

I have as yet no idea how to implement the interface between the 6502 bus and the rp2040. I am planning some small number of registers, but some of them may require multiple writes to fill a buffer which in turn is written to the screen.

Not entirely sure yet, I'm still trying to figure out what I can and can't do with the PIO state machines. I think they'll read multiple pins in one clock cycle though, at which point you should be able to shift the bits into the FIFO.

The RP2040 docs say that the PIOs are capable of doing read and writes to 8080 and 6800 buses.

The one thing I'm running into is that if I do 15-bpp then that's 17 of the 26 available GPIO pins, leaving me all of 9 pins for talking to the 6502 (not enough to do read/write, chip select, and 8 data bits)

I'm contemplating the idea of multiplexing the output of the VGA signals through 7 or so pins. 5-bits (one channel) and 2-bits indicating which channel, with the "fourth" channel being the sync bits.

Edit:

Visual Studio Code is a nice to have, but I would guess you could just as easily use what ever editor you wish. I tend to use nano for quick and dirty edits, and Visual Studio (not Code) for larger projects.

I've seen some people do some pretty amazing things with vi, emacs, and Atom though.

[barnacle]

Yeah, my desired resolution is limited by the internal ram to 640 x 480 at four bits per (I'm using three at the moment but that's an easy change). It may be possible to go to 600 x 800 (which would take 240,000 bytes of video buffer) but I think that's going to be very tight on ram to do everything else, so that's a long way down the road - e.g. if rpi deliver another version with more internal ram.

What I'm interested in is a standalone system that can be used both as a simple 6502 machine at monitor level, and as something with compact flash and the video controller in the 6502 address space. Using the rp2040 as the controller solves the issue of the 6502 having to swap in 150k of ram, but adds the complication of having to simulate access to 'registers'. I saw that the chip is able to interface to intel and motorola busses so that should be fine, but I have not yet found any examples (though I think Troy might have some hints).

I'm not interested in video games so there's no tiles or sprites or build it on the fly, which simplifies things, but I am considering using four pins as video output either driving rgb (or rggb) directly and through an r-2r DAC to drive all three pins with a sixteen level gray scale. Ideally under software control, but again, we'll see. However with that in mind I also want to use the rp2040 to provide the ps/2 interface - at least a receiver-only - and a bidirectional UART. A drop-in, on the bus generalised IO part that can handle at least those three things simplifies a lot of the rest of the design. And the fact that it's dirt cheap - four bucks for the pi pico, or a buck for the chip alone - doesn't hurt at all. (I think it's possible that the UART may actually work across the USB socket, which is a big bonus for me.)

I'm no fan of VSC: I've used it, but I don't really like its habit of getting in the way with hints and suggestions which invariably seem to obscure the bit of code I'm trying to look at :grr: and generally I use Geany and a command line to compile, even large code bases. I use the STM32Cube IDE for STM arm code, and also IAR for work stuff (an infinitely superior IDE) but one issue I find with many IDEs is that their idea of 'projects' and 'solutions' doesn't really fit with my stone age ideas. In particular, simply cloning a project is often a serious head bender... (try telling STM32Cube that you'd like to do the same project again but you've changed your mind on the actual processor...)

Neil

[BigEd]

barnacle wrote:

I saw that the chip is able to interface to intel and motorola busses so that should be fine, but I have not yet found any examples

I collected some links recently which might be helpful
https://github.com/oliverschmidt/a2pico
https://github.com/dp111/PicoTube
https://github.com/hoglet67/pico-swram
https://github.com/hoglet67/pico_bus6502

[barnacle]

Thanks Ed, I shall give them a look over. Appreciated.

Meanwhile, this morning's efforts:
- changed the font for one a bit more elegant (https://github.com/viler-int10h/vga-tex ... ADABL7.F16 - though given the way the display spreads the pixels it might be worth looking for a skinnier font)
- got rid of some naughty utf-8 characters in my Sherlock Holmes extract
- zoomed in past the beer

Neil

[barnacle]

Ed, the A2pico stuff has definite possibilities. Not sure I understand it yet (= bloody sure I don't understand it yet) but looks hopeful. Depends on the timing though; still need to investigate further.

Neil

[BigEd]

Glad I could help - look forward to seeing what you do...

[barnacle]

Currently deciding whether a text scroll - which requires about 150k memory moves - is fast enough to avoid the need to maintain a separate virtual tty screen and copy each character from that. Which of course still requires a lot of memory access...

Phase one is to make a basic 'any char to screen' tty (from the serial port for now). Phase two is to handle things like BS and TAB; phase three is to implement some subset of ANSI to allow colour selection and cursor positioning. Somewhere in there, probably, a flashing cursor (or maybe a vertical bar tied to the gaps between characters).

Only then do I get onto actually joining it to a bus; from there I can handle ps/2 and serial...

Before hauling one's self up by one's boot straps, it is first necessary to knit the boot laces.

Neil

[visrealm]

Hey. Nice work!

I would definitely consider a tile map for text mode. You could then even support a circular buffer for storing the tile ids. That way, scrolling the screen is as simple as updating the start address to render tiles from. Or you could do a basic tile map, then you only need to move all of the tile ids. Much less than 150k.

[barnacle]

True, but it requires a continuous process of building the display based on the tile map, whereas at the moment a character need only be rendered once, until it needs moving. I also want to keep the option open to generate some sort of graphical display, which again would be difficult to render on the fly (the processors inside are going to be doing other things too )

I have considered - but not implemented - a half-way house where text-as-ascii is stored in an 80 x 30 array, and rendered from there to the video buffer only when something changes, but only those parts that change (i.e. I don't need to redraw all 2,400 characters -> 150k pixels every time I hit a letter, only if I do a scroll). Scroll will definitely be faster than a redraw, with memmove().

Swings, roundabouts... I might know later today whether the scroll speed is adequate.

Neil

[visrealm]

Fair enough.

You'll find generating the VGA frame on the fly (one scanline at a time) isn't too intensive. Even if it keeps one of your CPU cores 100% busy (it won't), you still have another whole CPU core to play with

[drogon]

barnacle wrote:

Currently deciding whether a text scroll - which requires about 150k memory moves - is fast enough to avoid the need to maintain a separate virtual tty screen and copy each character from that. Which of course still requires a lot of memory access...

I understand there's a DMA engine on the RP2040, so use that for the memory move?

I use DMA on my Ruby Pi project to do screen clear, scrolling (1D moves) and character printing to the screen (1D to 2D move).

Quote:

Phase one is to make a basic 'any char to screen' tty (from the serial port for now). Phase two is to handle things like BS and TAB; phase three is to implement some subset of ANSI to allow colour selection and cursor positioning. Somewhere in there, probably, a flashing cursor (or maybe a vertical bar tied to the gaps between characters).

My Ruby 6502/816/Pi projects use the Acorn VDU character codes for basics like cursor move/home/XY and graphics (plot, line, triangle, etc.) which then allowed BBC Basic programs to "just work" using the built in keywords. The codes are somewhat simpler than ANSI.

-Gordon

[barnacle]

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

[BigEd]

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 have the vaguest idea there was a system like this back in the day. It's a little like the Amiga's Copper, but it's not that I'm thinking of.

It's a sort of display list processor - those were used for vector displays.