24bit parallel colour data to HDMI

[AndrewP]

BigEd wrote:

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.

If I remember correctly I could copy about 1000 characters every frame with loop unrolling on the C64. That's about 50000 (25000?) characters per second (and I really don't remember correctly if can't remember the frame rate). Looking it up now the C64 can memcpy about at 54KB/s without loop unrolling so 50000 characters per second is probably correct.

[AndrewP]

I've posted a fuller message here on my thoughts on how an '816 system can do fast, high resolution graphics without a dedicated off-the-shelf IC or FGPA.

When I was looking at RISC-V CPUs I a) had no idea what I wanted to achieve and b) looked at the high performance, high pin count variants that were BGA packages running hundreds of megahertz. That was scary and way beyond my ability to work with. I was never really that interested in the RISC-V micro-controllers as I've thrown in with the Raspberry Pi Pico in that space.

On the FPGA-is-a-black-box thing. I'm not thinking of CPLDs as being black boxes in terms of design and usage. I'm thinking of them as being black boxes in terms of looking at a circuit board and working out what's going on. I like to follow these traces here into that gate there and realise that's probably a part of address decoding or whatever. That unverbalised feeling I have around programmable logic devices has something to do with permanence and longevity. Once the board is soldered it's there and will run forever with no change unless a new board is printed. I like that.

[Sean]

Proxy wrote:

that HD63484 ACRTC is looking pretty damn good. Utsource has lots of them in stock it seems, at pretty good prices too.
plus you can apparently chain them together... though i still don't fully understand how that would work in terms of VRAM and accessing it.
But besides that, i'm a bit confused about it's operating speed.
for example if you were to try and generate 640x480 @ 8bpp, each memory access would grab 2 bits worth of data (16-bit VRAM bus), and it takes 2 cycles per memory access. that works out to 1 pixel per cycle, which at a pixel clock of 25MHz would mean the chip would need to run at 25MHz as well.
that's a bit of an issue considering that it's rated for at most 8MHz... and it boasts resolutions 4096x4096 @ 1bpp or 1024x1024 @ 16bpp. but how? are they just running the display itself much slower? or is it just marketing handwavy "technically it can do this, but noone does" non-sense?

either way there seem to be pretty much no projects around this chip online, so i'd love to see someone throw something together and see how well it works.

The rated speed for the 63484 (8 MHz) is not usually the pixel clock speed, as I understand it. In many ways, the 63484 works like a much more advanced version of the venerable 6845 - it is providing the counters and sync and what not and you need to provide additional hardware like shift registers and pixel clock. bitsavers.org has a lengthy application note and a quite lengthy user manual for it, in addition to the normal datasheet and databook entry.

The application note (http://www.bitsavers.org/components/hit ... 198604.pdf) describes several potential hardware configurations. Take a look at page 151, Dot Clock, 2CLK, Load Signal Generation Circuit. The 2CLK is the main clock signal to the chip, is derived by dividing the dot clock per a table in the document. The load signal is also derived by dividing the dot clock, and drives VRAM access and load into the shift registers.

To maximize throughput some memory interleaving to pull multiple bytes at a time from VRAM might be needed. Maybe two bytes like the even-odd scheme in the 80-column Commodore PETs. Or perhaps interleave four banks to pull down four bytes at a time - this would allow for one VRAM memory access cycle to load in 8 pixels of 4bpp color graphics, in the same time frame it could have handled a single monochrome character from one bank of VRAM without interleaving.

[sark02]

RISC-V is a nice little instruction set. Very easy to learn if you ignore all the extensions and stick with the core 32-bit ISA.

If you're competent with any assembly language, it's simple to pick up. Assembly langues are (almost) all the same: registers, arithmetic, load/store, conditional branches, and subroutines. And the tools and simulators are available to get you started... writing your first little snippet of code... and if you feel like it, you can jump to 'C'... but that's a choice.

On HDMI: In the past I've gotten my FPGA boards from Digilent, but I'm sure nowadays there are many options. Digilent did used to have example Verilog for a (DVI) HDMI interface, though.

Regardless of your output resolution, if you want to stay more retro with what your 6502 or '816 sees, then you design a C64-style 40x25 character display and then have the FPGA read in a 40x1 row into its internal memory (along with character bit patterns) and then generate an output 640x16 screen fragment without having to go back onto the system bus.
If you're willing to get into Verilog, it really is a lot of fun. A lot to learn, but it's all just counters and state machines in the end, and you can simulate everything and examine waveforms before you load the bitfile onto a real FPGA.

[tcdev]

I've done a few frame-buffer to DVI/HDMI designs, albeit with an FPGA. I've used both the TFP410 and ADV7511.

The TFP410 implements a 12-bit dual-edge mode primarily for reduced pin-count IIUC. Otherwise the 24-bit mode is quite straightforward. You can configure the device either using the I2C interface, or via tying the various configuration pins on the board. A video controller is simply a handful of counters that fetch data from the frame buffer at the appropriate times. Whether you're implementing DVI or HDMI (video) is neither here nor there, as the back-end is exactly the same, it's just the connector and the transceiver chip you use that differs.

What brought me here was a search for 12-bit dual-edge mode on the TFP410. I've always used 24-bit mode but my latest project requires the use of 12-bit mode, and I'm having trouble getting it working. I have a very blue display, which suggests the 2nd edge isn't being latched. I've just about exhausted my options reading and re-reading the data sheets and now it's time to pull out the scope...

[tcdev]

sark02 wrote:

If you're willing to get into Verilog, it really is a lot of fun. A lot to learn, but it's all just counters and state machines in the end, and you can simulate everything and examine waveforms before you load the bitfile onto a real FPGA.

I've worked as an FPGA developer on-and-off for more than 10 years now. I originally started with VHDL as it was the customer's requirement, though exposure to Verilog was required as there were Verilog modules that we had to interface to. I actually prefer to write synthesised code in VHDL and the testbenches in Verilog.

After a break from FPGAs for a couple of years (not by design, it just worked out that way) I was recently contracted to do another FPGA design. However the client was keen for me to look at myHDL, which is a Python-based HDL development language. I was a bit skeptical - and I should add I didn't really know Python at all - but I looked into it and used it to prototype the project. FYI you write the HDL in 'Python' and then when it all works you convert it to Verilog to use in your design.

I have to admit that I'm now a fan of myHDL, and will continue to use it for the actual implementation of the project. You're only using a subset of Python, and it pretty much reads like Verilog anyway. Where the process really comes into its own is the speed and power of the simulation. I was actually writing a video controller as part of the project, and not only could I simulate it quickly and easily, I could actually have the simulation write .PNG files for each frame! Try that with a Verilog simulator!!! There are a few quirks and I think I also came across a bug (in simulation, not synthesised code), but on the whole I find it more productive and certainly less painful than the traditional VHDL/Verilog languages. Food for thought!

[BigEd]

(Welcome, tcdev!)

[John West]

tcdev wrote:

I could actually have the simulation write .PNG files for each frame! Try that with a Verilog simulator!!!

I did! OK, it's .tga rather than .png, and it's VHDL rather than Verilog. But it does the job.

VHDL is not a fun language. I'm sticking with it because I already know enough to be dangerous, and the hard part is in the design, not in the expression. The language doesn't make that much difference for me.

(I had to change the file extension to .txt - the forum software appears to have enough sense to not like VHDL)

[Chromatix]

In terms of making the problem tractable, I strongly recommend pixel doubling, both horizontally and vertically. This will reduce both the quantity of memory you need and the time needed to update it. A 1280x720 scanout then becomes a 640x360 framebuffer, which is much closer to what was typical for an 8-bit home micro (the BBC Micro could manage 640x256, though the pixels weren't square and the aspect ratio was taller). If you design an 8x12 character set, you can easily fit an 80x30 text terminal in that.

For horizontal pixel doubling, you just hold the same colour at the HDMI transceiver's inputs for two clocks, instead of reading a new pixel each time. This is likely to simplify low-level timing considerations on the output side considerably.

For vertical pixel doubling, you read the same row from memory for two consecutive scanlines. This would mainly reduce memory requirements and draw time, rather than simplifying low-level timing. But if you stuff the row into a FIFO during the first scanline of the pair, and take the data from the FIFO for the second scanline, then you can alternately dedicate the VRAM devices to scanout and update, which may be easier than trying to interleave accesses or find suitable dual-port devices.

Also, just because the HDMI transceiver accepts 8+8+8 bits per pixel, doesn't mean you need to store them all explicitly. It's a time-honoured technique to reduce the colour fidelity to reduce memory capacity and bandwidth requirements. This could be as simple as a 2bpc 64-colour scheme (already almost 16-bit micro standard, and well beyond most 8-bit home micros), or an 8bpp with CLUT, which you could default to the 216-colour Web palette and have 40 entries left over for "spot colours".

[Proxy]

On a side note 640x360 is it's own standard resolution known as 360p.
So you wouldn't even need pixel doubling, and it runs with a nice and even 18MHz pixel clock.
I also aim for that with my CPLD based card but halved to 320x180 so that a full 8bpp framebuffer fits into 64kB of VRAM.
I like to use this site to look for common resolutions and their requirements like pixel clock, front/back porch, etc.
https://www.improwis.com/tables/video.webt