You can go back to 1984 and get a Hitachi ACRTC which can draw lines for you - and most probably there's a simple CPU in there to do that.

While looking for specific examples of DPI compatible displays, I found these multiple-interface displays from CrystalFontz. Some of the smaller ones come with optional breakout boards to make prototyping easier; the native cable is designed for a surface-mount ZIF socket. They also require only a single 3.3V supply for the logic and drivers, plus some higher voltage for the backlight LEDs.

As well as the DPI mode (which allows attaching a VGA-style scanout system for high-framerate video), the display has internal graphics RAM at full 18-bit RGB resolution, which can be written to in rectangular sections (possibly as small as a single pixel) using SPI or 8-bit MPU bus commands, using as few as 2 I/O addresses. The timings for writes appear to generally be compatible with an 8MHz 6502, or possibly faster if a wait-state is used, and you could use a lookup table to expand 8-bit pixel data to full 18-bit width for extra performance. Pixel data can also be read back, but the read-command timings tend to be much slower (say 1-2 MHz). Internal scanout from the graphics RAM comes with a vsync or composite-sync signal, and can be configured for hardware scrolling (which saves redrawing the whole screen for a linefeed).

So this seems to be one of the simpler methods of getting a high-quality, high-performance display up and running. It strikes me that a kit providing a hobbyist-friendly interface to one of these might be popular, especially if it comes with a microcontroller to be programmed by the user as an accelerator (ie. write your own font generator and line functions).

I've used similar displays on other projects in the past - one was an OLED display on a dive computer that was connected to a parallel interface on a PIC chip. That was quite a few years back though. Also I played with one of the SPI displays that are popular on the Raspberry Pi - the technique I used there was to effectively keep a software framebuffer in RAM and blit it to the display via SPI running at 32 or 48Mb/sec in a single transaction. That technique is good for a little over 20fps, depending on the display size, but not good on a 6502 due to the speed and RAM limitations, however the same display also has drawing commands that can be sent via SPI - such as plot, line, etc. A couple of cheezy videos here:

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

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

These both work by doing the drawing (poking the pixels) to an in-memory 'frame buffer' and then blitting the entire thing to the display about 22 times a second. (900Mhz Raspberry Pi)

The company behind those range of displays really do "smart" displays - so they have a microcontroler (ARM) and SD card, you send icons, images, buttons, etc. to the display via a compiler system, then a cheap device like ATmega can call up a screen, set a dial, move a slider in a very high level manner.

No good for playing space invades though.

-Gordon

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

I had the impression that these displays were pretty dumb in themselves, and thus amenable to tinkering - hence the point made about the *reprogrammable* microcontroller to put on the hobbyist adapter. I think that's one of the most flexible ways to build a display without either making it "too smart" or increasing the part count too much.

So, say, an SPI display connected to a $5 reprogrammable "microcontroller" with a parallel interface ...

-Gordon

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

I do think there's a difference. With the 9918/F18A etc you are still "poke"ing direct values into the registers and RAM footprint that the raster generator directly reads from. You're not giving it commands to do high-level processing work on your behalf, like the SPI displays. The bytes you set are the full stateful control of the hardware itself just like the VIC-II chip or whatever; the interface is just slightly different without the shared memory bus.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Yes, that's more-or-less the sense of my "amenable to tinkering" comment.

VGA is awesome. For many different reasons. First, VGA is easy (relatively speaking) compared to NTSC. NTSC is actually difficult when you start messing with color bursts. I built an NTSC card years ago using a slow PIC and some TTL logic. It was cool, but difficult to get right.

As much as I love NTSC, it's getting harder to find good displays that handle them well. Modern TV's don't really like the old NTSC signals and CRT's are big and hard to find.

VGA monitors are a dime-a-dozen. They are everywhere. I've bought several from thrift stores for < $10. And, they are still being made. Many brand new, still produced, HDMI monitors will have a VGA port.

HDMI is DRM'd, has copyrights, and is a legal mess if you ever really want to get serious with it. I would imagine that many devices out there that support HDMI are technically doing it without legal permission. VGA has no such restriction.

VGA can be driven with a, again, relatively slow frequency of 25.175 MHz. 640x480 can use "fat pixels" of 2x2 to get a great "retro sized" screen of 320x240. And, VGA is razor sharp on a low-end monitor.

VGA can be driven with a modest micro-controller (the Propeller can drive 6-7 VGA displays at once...each with different content). Even TTL driven VGA isn't terribly difficult.

So I'm the exact opposite of what you were asking...I don't understand why more people don't push VGA instead of HDMI.

_________________
Cat; the other white meat.

HDMI is indeed a bit of a minefield. One way round it is to use a licensed device such as a Pi to produce the signal. Another is to use DVI instead, which has none of the encumbrances, and is (I think) pluggable into an HDMI display with a simple adapter.

Yes, HDMI and DVI-D are essentially identical at the electrical level, and only really differ in the physical connector. The adapters are completely passive.

Because of that, I suspect the legal stuff has a lot more to do with HDCP, which nobody in their right mind would even try to implement on a hobby machine. That, and the HDMI trademarks, which probably have licence-to-use requirements involving a standards compliance audit.

None of which eases the difficulty of simply producing the signals in the first place.

If you're resorting to a simple adapter, then VGA is still viable.

HDMI is certainly important if you truly want the resolution/frame rate. But I don't think that's the key issue for most hobby folks. They're happy to get a dot, ANY dot, on the screen in the first place, much less 2.3M of them (almost an order of magnitude over base VGA).

It would be curious how available a graphic chip set is that could be used by a random CPU. (The premise being modern GPUs can drive HDMI.)

10s on Google dredged up this article. https://www.edaboard.com/showthread.php ... on-HD-2400)-with-a-STM32-microcontroller

Clever, but looks horrible .

I've a feeling DVI is much more friendly for a Beeb (for example) than VGA, because it offers 50Hz frame rates.

(Edit: but see below)

I used VGA in my last Parallel Video Board projects to achieve 320x200 all the way up to 1080p. I highly recommend it. I recently tried to get into HDMI thinking it was just another connector interface standard. The HDMI IC I chose did not specify all the registers needed to program it because one did need a license from HDMI.org and probably for reasons very well point out by Chromatix...

Ed, I think VGA clocking refresh standards do include 50Hz too?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I found this page a while ago, when randomly curious about such things, describing driving HDMI straight from a FPGA. Does it underrepresent the complexity? Of course, it only covers video and not audio.

https://www.fpga4fun.com/HDMI.html

Regarding trademarks and such, I presume you can put a HDMI connector on there and label it "Digital Video Out" without literally calling it "HDMI™".

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Oops, yes indeed, you're right. I must be thinking about something else.

(Edit: but see below)