 |
| 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.
