6502.org

A bit of an out-of-interest or forward looking post on my part but... has anyone generated an HDMI video signal from a frame-buffer?

I currently have an 8bit:8bit:8bit set of RGB data that I convert to a VGA signal using a bunch of discrete counters and an ADV7125 3-by-8bit DAC. With VGA not being as common as it once was I started wondering: how hard would it be to generate an HDMI signal?

It seems like it's basically impossible in the hobby world.

Unless...

I can find an off-the-shelf part that I can clock my parallel data into at manageable frequencies (on the order of a 100Mhz) and that can then internally generate the GHz HDMI signal.

The ADV7513 seems to be perfect but is not available at Mouser anymore. Has anyone used the ADV7513 before or is there a similar component still available alternative? The datasheet for the '7513 is four useless pages but there is also the HARDWARE USER’S GUIDE that seems pretty complete.

I can still find '7513s at AliExpress but have had limited success with orders from them. Should I buy a couple and hope for the best? And is there a reference circuit or something that I can test one in?

Thanks!
Andrew

There's a lot of stuff about licensing for HDMI, but people seem to get away with it in the hobby world by generating DVI-D and wrapping it in an HDMI connector. That won't carry audio though but that may not be an issue for you...

So it might be worthwhile going down to DVI-D route.

Alternatively there are many VGA to HDMI adapter units out there... Some even take audio input and are less than a tenner on Amazon.

-Gordon

You might be interested in this board https://1bitsquared.com/products/pmod-d ... -interface. They do TTL RGB to HDMI in 4, 12 or 24bpp, and the schematics are available. The board is based on the TFP410, which will soon be back in stock at Mouser (in June), if you want to build your own. Note that it needs 3.3V logic levels. I have not tested it myself

The TFP410 looks like the way to go. It puts out a DVI signal that a passive adapter should be able to convert into an HDMI connector. I KNEW Texas Instruments would have something like this, I just could not find it. Clocking out 24bit colour on the TFP410 looks a bit strange but should be quite manageable and I'm much happier with digital DVI rather than HDMI.
Yeah, I've still got a bunch of old VGA CRTs knocking around so VGA is fine. For now. VGA to HDMI adapters are definitely the easier and cheaper option. I'd like to support 720p as that's a more common flat panel resolution than the SVGA 800x600 that I'm using.

But still, a 'low' resolution of 720p is going to be an absolute pain for a double buffered frame buffer. And I'm going to have spew meaningful pixels to the whole thing. Hopefully future me will work it out...

I have used a TFP410 in this : https://www.zeridajh.org/hardware/bbc2dvi/index.html. Because, as you may know, HDMI is basically DVI (and TI likes to call it 'PanelBus' alright TI ...). Same video signal. Just without the extra bolt-ons that HDMI blessed us with (for a fee), which are really only protocol extensions over the same wires ... For more 'prototyping convenience' you may want to start with this (as I did) : https://nl.mouser.com/ProductDetail/Leo ... DoFg%3D%3D.
Not sure what you mean. You can choose to give it 24 bits as 24 single clock edge or 12 double clock edge (as I do).

My 'frame buffer' is in the FPGA (either a couple of pixel rows only in one version, or all of them to allow de-interlacing in another).

Might be a pain even to single buffer - 720p is 1280x720 which is 921600 pixels - just short of one MB for an 8-bit deep display. Or 14 banks of 64K in an '816 based system. (Although I suspect this may not be for a 65xx project...)

My current strategy is to offload the video ram, line, sprite drawing, etc. to another processor - in the current case it's my Linux desktop but I do have a $10 plan B for the future...

-Gordon

A bit plane approach instead of a linear frame buffer might speed up reading bytes on the display generation side. Wouldn't do anything for speeding up the updating the pixels on the CPU side, though - might even make it worse.

That looks great, and thanks for the prototyping suggestion!
I read the datasheet in a bit of a rush and got confused because it looked like half a pixel has to be clocked in on the rising edge and half on the falling edge. Which seemed odd as it has a full 24 data pins. Looking at the datasheet again I see I only read the "dual-edge input mode" section which is 12bits in rising, 12bits in falling. Not the single-edge input mode which is selectably either 24bits in rising OR 24bits in falling.
720p is a stupid amount of data store / generate / output. The 800x600 SVGA I'm using is still almost a half a megabyte - and even that is a lot of data for a '816 - but at least I can get away with 2x 256K SRAMS for the for the front buffer and another 2x 256K SRAMS for the back buffer. (They're actually 16bit SRAMS because I store palette information per-pixel but that is a whole other story).

An '816 running at 10MHz (100ns per clock) just can't move 1/2MB of data 60 times a second. But what it can do is tell a pair of DMA style blitters to write a line of pixels from main memory to graphics memory. Each blitter sits in a 25ns access window within the full 100ns cycle. They can, unfortunately, only read or write once in their 25ns window so it still takes two full cycles to write a single pixel. Two blitters together can write pixels at 10MHz (or 10 million pixels per second). Sharp readers will have already noticed that that is still not enough for even 800x600.

It's still almost three times too slow.

If I target 30fps instead of 60fps then it's not so bad, I intend 800x600 for 'productivity' stuff like text editors or whatever. Assuming I ever get this far and get to writing games then I'll target 400x300 at 60fps which is suddenly a lot more manageable by an '816 with hardware blitting support.

Now back to 720p. That would require at the very least 8x 256Kx16 SRAMS; and that's starting to become expensive and hard to manage. So. Many. CBT3244s. Not to mention the video circuit is already a pipe-lined nightmare to get each pixel's palette decoded and presented to the DAC at 40MHz. 74MHz is... going to be worse.

Definitely a problem for future - more experienced - me.

A sidenote of possible use : I discovered some years ago, when I was busy with my own project, that SiI164 is a clone of TFP410 (and does not have and/or need the thermal pad). The SiI164 is a lot cheaper, but does not seem to be easily available (much like the TFP410 right now ...). Both are available on Ebay though, here and there.

both the TFP410 and SII164 seem to be on Utsource.
on a side note, i also just found out that they carry lattice FPGAs like the MachX02 series (1200HC/2000HC), which would make for good Graphics cores.
though obviously like with Ebay and similar sites, there is a chance to get fake or dead chips. (which makes me consider getting a TQFP-100 socket to be able to test FPGAs before soldering them)

Thanks! That's good to know. I think I'll wait until Mouser have the TFP410 back in stock and then order a pair of them. Once I have a circuit tested and working I'll order some SII164s from AliExpress as they're much cheaper* but at least I'll be able to test them in a known good circuit.
So... one of the things I'm trying to do is use no programmable hardware. Why? Because I like a challenge. But more seriously it's because I feel that CPLDs and FPGAs are a bit of a black box when it comes to figuring out what a circuit is doing. I've managed to reduce my programmable logic devices down to a single 32KB ROM (and SD cards). Everything else is 74 series ICs or at least ASICs. Looking at the VERA from the X16 or the Vicky from the Foenix it seems like they become too complicated (to easily drive from an MPU with address lines) and too tailored to their host machine. What I really want is something that I can access as a simple IO mapped device and that will do something as simple as drawing a single line of pixels**. The 65C816 becomes a part of the graphics device.

And I like that.

It also means I need more than one 65C816. And I like that too

* possibly there's a reason.
** That needs 16 4bit presettable counters per blitter. Simple is not always that simple.

Not trying to dissuade you from your planned approach, but have you considered using the Hitachi HD63484 ACRTC? It looks like Quest Components still has about 200 of them available in the 8 MHz, and they are designed for high resolution graphics and incorporate drawing commands for vector graphics and blitter-like copying.

Sounds like you're after the holy grail of retro graphics devices. Something that might fit the period - but at the same time you're after todays resolution and colours...

Without some sort of hardware assist, higher resolutions are not going to be feasible - not unless you like watching the individual pixels being drawn, anyway.

I went down a similar route when I started out with my Ruby project - ended up quietly ignoring the video part for a while, then using a serial interface to a "smart" terminal program... Is that different from e.g. SPI interface to some FPGA device (fore-runner of the X16 Vera - which might still support SPI), or bus interface to the TI TMS9918A thingy?

Thinking (out loud) about options - a separate CPU and video RAM - how to implement it - a high speed parallel interface (Pair of VIAs?) or alternate phases of the clock on a shared memory system? Dual-port RAM (expensive!)

What's the 'best' resolution from say 64KB... Assuming 8bpp - it's quite low, sadly - 320x200x8 = 64,000 bytes. That makes it easy to fit into a single bank on a 65816 CPU though. Assuming no hardware 'blit' engine, even clearing that at 7 cycles per byte ('816 block move) needs 448,000 cycles, so 2 frames per Mhz - obviously having hardware assist makes that much faster - but how much hardware - your goal of no CPLDs then leaves you with an ever growing raft of TTL...

The Apple IIgs seems fairly tame - they obviously wanted to keep video in a single bank of RAM - the Acorn Communicator had just 32KB for video RAM, so probably no better (or worse) than the BBC Micro.


So I'm not convinced there is an easy way to get nice colour and high resolution graphics with our systems today without external assist of some sort. There is a limitation on how fast code can write to RAM, or if the video system is decoupled from the CPU, then how fast we can pump commands to it - and what sort of commands?

The solution of "throw a Pi/Pico/ESP32/Arduino/Propeller at it" is popular for other projects. The X16 Vera design has been open sourced (as far as I'm aware) and since the year dot we've been sending codes down serial lines to terminals to plot point and lines and position the text cursor (Tek 4014, The Blit and the BBC Micro is similar - and is how my Ruby system works) but somewhere, somehow there may be a better solution? Hard to tell. Even the RC2014 lot seems to have gone down the PiTerminal route to turn a Pi Zero into an ANSI Colour terminal via a serial interface.

My Ruby system runs the serial line at 115200 baud. commands are sent down the line to print text, move the text cursor, plot points, draw lines, plot sprites and so on. The "heavy lifting" is done by the far-end which is currently a C program running on my Linux desktop. The actual commands are the exact same commands that the BBC Micro uses - that way I can run BBC Basic and all it's text and graphics commands "just work".

I reckon it's fast enough to run Tetris or invaders but I've never sat down to try. I have a future plan to use a high speed parallel interface to do more or less the same thing through the VIA (and yes, I'll throw a Pi at it - which I have developed my own "baremetal" OS for which can boot to graphics terminal in a second or so but compared to a CPLD/FPGA, a Pi is a billion times more complex even if my stuff only uses 1/100th of its capabilities. At least I have control of the software and not some black-box FPGA which is nice (for me, anyway).

I will keep watching to see what happens though.

Cheers,

-Gordon

If we're looking at the time to write the whole screen - to clear it, say - what's the corresponding time on a C64, or on a Beeb? I suspect it's more milliseconds than a frame's worth.

it's not that you have to use Programmable logic, but as drogon said, with goals ever moving forward (higher resolutions, more colors, clearer audio, etc), the hardware has to move as well otherwise it will just become unusably slow.

also you're kinda making it sound like Programmable logic is some kind of black magic that just works once soldered, but you still need to put a lot of effort into the logic that runs on it. pretty much the same thought process when you design a logic circuit for discrete 74' ICs.

anyways, since the main bottleneck of Graphics is just moving data around (which is why modern GPUs have like 512-bit wide memory buses), you'd want to avoid the main system doing that. so the only way i see higher resolutions being a thing is to have a seperate system specifically for the graphics, controlled via some set of commands.

the idea of using a second 65xx CPU for graphics work is of course not new, but still pretty good!
a 65816 running at 10 or 20MHz (based of the pixel clock for 800x600) with fast SRAM would give you some decent performance.
but even that will only get you so far.
Dual Port RAM is one option, and not as expensive as you might think! the 32kB of DP-RAM on my current video card cost around as much as the 65816 running my SBC.
the problem with DP-RAM is that it's slow, bulky, and while you can use it to communicate between 2 CPUs, it's not ideal.
i'd say something like the IDT7201 would be a better fit. it's a unidirectional FIFO, 2 of those allow for fast bidirectional communication. with a status byte to read out the flags of the FIFOs it would take up 2 addresses on both sides.
on a side note i have been kinda fantasizing about a little cluster project with these FIFOs to create a ring network of multiple 65xx Computers that would directly plug into eachother. but so far it's nothing but a block diagram.

sort-of-EDIT? (sorry if this is getting too off topic!)
while writing this i thought more about the network idea, and how modern GPUs have so many cores that each of them can take care of a small set of pixels.
so, what if you had more than 2 CPUs? 4x 65C02's for example that all share the same fast single port SRAM with a video circuit. a lot of graphic operations can be split into multiple smaller pieces (like scrolling or drawing shapes).
my idea of connecting them was to have all CPUs run on the same clock with the same phase. but then use extra logic to restrict their time on the bus when PHI2 is high. using bus tranceivers and latches (latches because data is only read on the falling edge of PHI2, so the data needs to be stored), each CPU could get a small part of PHI2=High time without having the CPUs themself run at extreme speeds. but of course the more there is on the bus the faster the support logic needs to run, which comes dangerously close to FPGA territory.

anyways, overall i still think that for these kinds of graphical goals you likely won't get something useable without either progammable logic, a crazy setup like the multicore bus sharing, or both!
i still wish you luck with whatever you might have planned, and i'm eager to see it work!