HDMI2AV, AV2HDMI

One of these cheap MINI boxes promise to convert a HDMI signal to a good ol' Composite Video, and the other box promises to do it the other way. I'll mostly discuss the HDMI2AV box, which gives Composite out.

I put the HDMI2AV to work with the Commodore 1084S. The picture failed miserably, and it looked as if nothing could be done. I was not in the mood to begin troubleshooting it, so I let it be for a while.

Simple perspective correction makes the monitor look more bubbly than it is

Marq got a working one (in Finnish) so we tried the supposedly faulty box on his setup. To my surprise it performed well, so the blame might be put at the connector, or the RCA cable could be flimsy. Although the good cable did produce a faulty image too, when prodded enough.

Again, trying the converter with the trusty old Commodore 1084S, I got a picture. After fiddling around with the Linux Mint extended display, trying out various Youtube videos and the ZX Spectrum emulator from Torinak, I wanted to try other hardware.

I just had to go through the various HDMI-equipped retro gear, starting with the Mini Amiga from Retro Games. It works nicely, and here I can also switch between 50hz and 60hz on the go. After choosing 50hz I could see no problems with scrolling and movement, it's all very smooth.

Retro Games Amiga Mini. The moiré-type pattern is from photography.

The lagginess of the Mini is tricky to prove as the bundled controller is not all that great. I doubt the video box adds any lag really. With games like Stunt Car Racer the lag can't even be perceived.

The Mini has various display settings that affect the image. When running my own disk images from the memory stick, I often had a small image in wrong ratio at the center of the screen. The three display zoom options didn't do much, this is something that needs to be set from the game-specific menu. The non-intuitive thing to do is to set the vertical crop from 200 to zero. This way the screen image can also take more space horizontally, just as the built-in games do.

The generated composite image obviously isn't comparable to a real Amiga RGB, it's more like the composite out from the TV modulator back in the day.

ZX Spectrum Next

ZX Spectrum Next did rather well at first sight, but the frequency apparently doesn't quite match. There are a bunch of TV modes to choose from, but none of them solved the tiny but perceptible, regular "nudge" in the frame rate.

With old Spectrum games this rarely matters but the newer Next software might suffer. Then again they were made for modern displays in mind. Also, the Next has real RGB and VGA outputs, so this experiment is somewhat pointless. I just need the correct cable.

Retro Games' The Spectrum only has a HDMI out, and luckily it did better in the frame stability department. The screen size, aspect ratio and scaling are a little off. Using the display adjust knobs from behind the 1084S monitor, I could get the aspect ratio closer to reality. The borders won't extend far enough. Again, depending on the game this doesn't matter too much, as the borders are often black anyway. This was a very good result.

Retro Games The Spectrum

This was the first time I needed the additional 5V power to the HDMI2AV. This is most likely because I had to use a different USB power supply, one that did not give enough juice to the HDMI, and not because of some design choice intrinsic to The Spectrum.

The HDMI-only The C64 also performed fine, although I didn't test it all that much. Scrolling looked smooth in Uridium and the like. The C64 does have some lag, but again with the bad joystick it's sometimes difficult to say.

I didn't have my memory stick at hand, so I couldn't run some of my testing favorites. The C64 palette is somewhat muted so on overall the image didn't "live" as much as with the Speccy colours.

The C64 carousel screen

Just to note, the Neo6502 board from Olimex (which I have never really discussed in my blog) did not produce an image through the HDMI2AV box.

All in all, the HDMI2AV is good for experimenting with that good old CRT feeling. If I want to nitpick, there's a persistent diagonal pattern that goes through the image. Depending on the material and colours used this can be more or less distracting. The slight "lacing" effect can also be a little off-putting. 

To be honest the composite video quality back in the day wasn't always great, it's just that the image was crap in a slightly different way. Although the box is likely most versatile when connected to a PC and the various emulators, I was perhaps most impressed with the Amiga Mini and The Spectrum, where I feel some value is added.

As for the AV2HDMI box, I've barely tried it. It would really deserve its own blog post, but I don't now have many experiments at hand.

It looks as the box can produce an adequate picture on a modern display. I didn't see missing frames or atrocious lag, but as the 60hz is the only frame rate available, it's not going to be smooth with most retro gear anyway.

There didn't seem to be a big difference between the 720p and 1080p options, if anything the 720 looked to be enough and with less resolution artefacts. Who knows, it might be faster to generate.

Jonsbo DS8 and Raspberry

Nano on Raspberry Pi

When I tried the Jonsbo DS8 8" display the first time, I only got it working on common desktop computers. The Retro Games C64, Amiga and Spectrum did not display, and neither did ZX Spectrum Next.

I was quite sure it would connect to a Raspberry Pi, and true enough, it didn't really require all that much tinkering to get a visible result.

I have a minimal Raspi SD card that only boots the terminal. This worked quite fine after setting up the screen resolution in the config.txt.

Most of my Raspberrys are tied up to some project or the other, and this one had USBs and Ethernet connectors removed (don't ask). The only keyboard I could use with it is a stripped Deltaco that connects to the said USB with jump wires.

The config.txt at the root of the Raspberry install needed editing.

These looked like the key parameters to getting the Jonsbo to show on a Raspberry Pi (3B+ in this case).

hdmi_group=2
hdmi_mode=87
hdmi_timings=800 0 80 16 32 1280 0 16 4 12 0 0 0 60 0 61440000 0

display_rotate=3

hdmi_group 2 is 480p 60hz with DMT timings (Display Monitor Timings), and hdmi_mode 87 prefers the resolution we've set, so it is kind of custom mode and the 480p probably doesn't matter.

I can't vouch for all parameters on the hdmi_timings, most of them are likely remnants from a past setup, and hopefully don't have a huge significance.

Resolution is obviously in the 800 and 1280 values, and the display frequency is the 60. The last value is the aspect ratio, best left zero. The pixel (61440000) is a value from width*height*frequency, so 800x1280x60.

The hdmi_timings parameters list:

hdmi_timings=<h_active_pixels> <h_sync_polarity> <h_front_porch> <h_sync_pulse> <h_back_porch> <v_active_lines> <v_sync_polarity> <v_front_porch> <v_sync_pulse> <v_back_porch> <v_sync_offset_a> <v_sync_offset_b> <pixel_rep> <frame_rate> <interlaced> <pixel_freq> <aspect_ratio>

There's also a max_framebuffer_height parameter, it might not need to be set, but just to be sure I set it to 1280.

BMC64 on Raspberry Pi 3B+

With the above I could also get a BMC64 "baremetal" C64 emulator to run (a blogpost here), although the display might not be ideal for that. But it goes to show the display_rotate config is not problematic for such software.

Choosing different machines from the Machines list (defined in machines.txt) may change the parameters so the display is no longer visible. I had yet no luck in adding the relevant parameters under the listed machine.

Photography reveals the tear while running vtester.prg

Not saying the Pi image is yet perfect, there was a persistent tear going near-vertically to the right of the middle of the screen. I haven't seen it on when using the display on a PC/Mac, so it might be a matter of getting rest of those hdmi_timings values correct, or the Raspi doesn't do compositing. For now I don't have the patience to find out.

A strange flickering incident

I used my C64 Videotest software for looking at screen scaling and frame rate. One of the tests alters the background color between black and white for one frame each, repeatedly. This can show unevenness in the frame rate. 

It was on for a while, and after exit, to my surprise the screen kept showing a sort of flicker. Not only that, but this flickering was contained to the area where the vtest.prg had operated.

I left the BMC install aside, and went back to the Linux install on a separate SD Card. The flickering persisted. What had happened? Had the display really broken?

Turning it on and off, or even removing cables for an hour, did not heal it.

I did notice that using it as a secondary display on a desktop computer, I could see no flickering. This was already promising.

Then I went and fiddled with the config.txt in the terminal install, as it was easier to change the parameteres in nano and reboot. The pixel frequency value in hdmi_timings was 40000000, which looked arbitrary. I then looked for the formula mentioned further above, and used 61440000 instead. The flickering disappeared, or became nearly non-existent.

Just to be sure I changed the value back to 40000000, and yes, the flickering was back.

I let the display lay powered off overnight, cables removed. The next day the flickering had nearly gone even if I tried the wrong pixel frequency setting. I guess it was an analogue problem.

So, although I can safely use the display for my computer and probably for Raspberry too, the fact remains that something changed. I doubt a display should freak out from simply flickering colours. One vague idea might be that as the config values were wrong to begin with, these helped make the display somehow more susceptible to problems.