Retro-style terminal with video generation in software

[Martin]

"Chasing the beam" (programming a micro to output video) is always an interesting challenge. There are plenty of examples of doing it with Arduinos on the web - but all at fairly low resolution.

I was looking at using the SPI "hardware" of an 8-bit Arduino to generate the 'pixel clock' - it can be coaxed up to 8MHz which theoretically allows about 416 pixels in the active part of a standard PAL scan line - and you get 460 'safe to use' interleaved scan lines vertically (or 230 if you just output the same data for odd and even frames).

The 8-bit Arduinos don't have enough SRAM to handle that much display in graphics mode, but in text mode it might be possible. For VT100 you really need more than 2 colours - the chip probably isn't fast enough to output 2 or more bits per pixel at that speed but in character mode you only need to change colours at 1/8 the pixel rate (assuming characters to be 8 pixels wide - which would likely be needed anyway, because using a narrower font would make more work for the micro - and it probably couldn't then hope to keep up with the beam).

There's probably enough time in the vertical blank intervals to handle the other tasks: serial port or keyboard scanning, and updating the video (character) RAM.

I don't know whether the 8-bit AVR chips are capable of maintaining the SPI clock rate between consecutive bytes. That may not matter if it produces a consistent gap between adjacent 8-pixel characters, but any jitter would ruin the display. I need to do some experiments.

Edit: using assembler, I could get the SPI bytes steady, and next to each other, but the processor isn't fast enough to access the character data then calculate the address and fetch the next byte from the font table in time. Graphics mode is easier for the CPU, but the ATmega328 is hopelessly short of RAM, and even the 2560 only has sufficient RAM for about a quarter of the screen area.

The Seeeduino XIAO is probably a better way to go for performance/price ratio. I've been meaning to put one of those to work in an R/C transmitter too - smaller than a Pro Mini, much more performance, 12-bit A/Ds, can be programmed with the Arduino IDE, and still less than £5 each.

[Phil_G]

Hi Martin, there was the Arduino retro computer viewtopic.php?f=80&t=62 that does 47 characters horizontally and 29 rows using the 'MRETV' library. Maybe changing the 328P crystal above or below 16mhz would help with alignment and pixel squishing.
BTW in all the pre- IBM PC years at the BT Computer Centre I never saw a colour VT100 - ours (many hundreds of them) were all monochrome
All the old CP/M stuff is fine on monochrome, WordStar etc uses reverse video and highlighting for menus etc, just as it was back in the day
I just ordered a couple more of the TV screens, they're superb. £12 each now, delivered: https://www.ebay.co.uk/itm/353160850645
The character display using Geoff Grahams PIC chip is crystal clear, nice contrasty characters with sharp edges - the photos dont do it justice!

Next job is to find a miniature keyboard - I bought a Chatpad to modify but the latest ones have a sealed epoxy blob where the easily-reprogrammed PIC used to be, and no ICSP pads like the old one had, so will have to 'decode' the PS2 format instead, its all been done & readily available
The Chatpad is a bit too small though - could do with something inbetween-sized!
Cheers
Phil

[Martin]

Interesting.

I've thought about it a bit more and I think I can do better than the MRETV author on an 8-bit Arduino. He was looking up 8 pixels of font and outputting them in 16 clock cycles.

Unrolling the loop for each horizontal scan line saves the decrement/branch test for reaching the end of the row (3 cycles).
He was also doing a multiply (2 cycles) but shift can multiply by 8 in just one cycle.
And he was doing an unnecessary add (I think) to offset for the vertical pixels within each character - that can be done by offsetting the font start address within each horizontal blanking interval.
If you copy the font table to SRAM from FLASH (768 bytes) that allows a font-table access in 2 cycles rather than three, but added to the screen RAM, that probably breaks the RAM limit on a NANO. Could work on an Arduino MEGA 2560 though.
Putting all those techniques together gets the output-8-pixels "loop" down to 8 clock cycles.

Now to satisfy the SPI at 8MHz we only need to source bytes at 1MHz - which is 16 cycles - but by saving a few cycles it opens up the possibility of adding character colour (VGA mode) or shades of grey in composite mode.

I think I might get 52 x 29 characters occupying 1508 bytes. I'm not sure why MRETV only got 47 wide. That would leave just about enough room on a NANO to have two bits of 'colour data' per character.

[Martin]

Sounds good. But surely x8 is three left shifts, once cycle each?

Yes, you're right, of course. I was confused because I've been working on ARM assembler lately - and the ARM can do any number of shifts up to 31 bits in one instruction. The AVR can only shift one bit per cycle, so multiplying by 8 is faster, providing you already have the number 8 hanging around in a handy register.

[Martin]

Craft by Linus Åkesson shows what's possible. This was on an ATmega88 which has only a quarter of the Flash memory and half the RAM of a NANO. He did clock it at 20MHz though.



Check out his Bit banger to see what he managed on an ATtiny 15 - that runs at a 1.6 MHz clock, and has only 1kB of FLASH and only 32 bytes (yes bytes!) of RAM.

[Martin]

My assembler tests have found the SPI output register (SPDR) on the ATmega328 and similar chips can't be reloaded until one clock cycle after it's finished sending a byte: when I try to sandwich consecutive bytes right up against each other, then every other byte is not transmitted. So using SPI limits you to 8 pixels every 17 clock cycles. It probably looks quite good on the screen in character mode - you'd get an automatic half-pixel gap between successive 8-pixel-wide characters.

It might even be worth stretching it out to 18 clock cycles to get a full pixel space - that would allow the font to be defined using all 8 bits, but it would be rendered 9-pixels wide with the 9th pixel always blank.

The downside is fewer characters per row. Using standard composite video timing (as near as you can get), it drops from a safe 52 characters per row to 49 or 46. I guess that's why MRETV has 47?

I'm now going to try using the USART instead of the SPI - I think that might allow the bytes to be adjacent, and that would look better for inverse video as well as getting back up to 52 characters. If it works, then the pro-micro or Leonardo (ATmega32U4) might be worth considering - the ATmega32U4 could perhaps handle a USB keyboard on its USB port which would be good for a terminal - there are many more USB keyboards than PS2 ones around these days.

[Martin]

I've got one of those cheap "reversing camera" monitors. Mine is nominally 7-inch with 2 composite inputs, plus sound. I bought it a few years back. I used to set it up at the flying field with a scanner/receiver for (analogue) FPV signals, so that other fliers or spectators could watch what the FPV fliers were seeing through their goggles.

I rigged it up to an 8-bit Arduino and used timer 1 to generate the sync pulses with the USART outputting pixel data. A couple of diodes and resistors to combine the two signals into a composite. I'm getting a rock-solid display.

So far, it's purely in C so the pixel data is just an incrementing counter test pattern - the compiler doesn't produce tight enough code to do a font lookup, and doesn't quite pipeline the test pattern bytes fast enough - hence the vertical white bars interrupting the picture.

But promising enough to continue...

[Martin]

I took a brief break from debugging the font pixel pushing, to display a graphic image (which is simpler). I'm running on an Arduino Mega for debug because it has several serial ports which makes debugging easier, but it's the same CPU at the same speed as a NANO - and almost identical with the ATmega32U4 of a pro micro or Beetle.

The image is 320x200 so 8000 bytes. But it's held in program memory so even a NANO would have room to hold about seven such images, plus the actual program which is pretty tiny. The mega has 256kB of flash, so we could store over 30 such frames and play a (very) short video!



I noticed while uploading the video that there's a stray apostrophe in the Mode Zero forum tag line which I screen-captured as part of my test image. The word, its, signifying belonging, shouldn't have an apostrophe - it's an exception to the normal 'belonging' rule because the apostrophe is used in the more commonly occurring "it is" contraction.

[Martin]