32x64 LED monitor

Forum for discussion of electronic television. Generally, stuff to do with CRTs and not using mechanical displays.

Re: 32x64 LED monitor

Postby nanowaver » Fri Jan 01, 2021 4:40 am

Steve
thank you for the hex listing. How is each pixel actually coded. I realise it's one byte pixel but what do the byte values represent? A grey scale?

Barry
nanowaver
"Fester, enough of the light-bulbs!"
 
Posts: 16
Joined: Sat Sep 29, 2018 5:37 am
Location: Sheffield, UK

Re: 32x64 LED monitor

Postby Steve Anderson » Fri Jan 01, 2021 12:58 pm

Yes, it's a straight linear curve...well, a non-curve I guess. 0x00=black, 0x80=mid-grey and 0xFF=white, other values pro-rata. Can't get any simpler than that! It's an 8-bit linear greyscale with each value representing the video level of each pixel. Same as an 8-bit monochrome TIFF or BMP file without any header/footer. It's an almost RAW file. Don't forget it's only the video, it doesn't include the sync pulses, you'll probably have to add those in hardware.

If you look carefully at the printed listing version above you can make out the circle within the frame...do it at a moderate distance and it's easier to see.

Here I use (and here only) the file extension .nbt for NBTV video (club standard) and .sst for the Cop McDonald B/W SSTV 8-second format.

Somewhere 'out there' is the original article where it came from, most likely the newsletter, but which issue I don't know.

Later...found it/them. Newsletter 21/2 (Dec. 1995) & 24/1 (Sometime (Sep?) 1998). But neither have that printed listing, another one somewhere?

Steve A.

It seems that in both cases the syncs were encoded into the EPROMs, but the listing above doesn't seem to include them.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: 32x64 LED monitor

Postby nanowaver » Fri Jan 01, 2021 7:13 pm

Steve

Many thanks. Now I can have a play!

73 Barry, G8AGN
nanowaver
"Fester, enough of the light-bulbs!"
 
Posts: 16
Joined: Sat Sep 29, 2018 5:37 am
Location: Sheffield, UK

Re: 32x64 LED monitor

Postby Steve Anderson » Sat Jan 02, 2021 2:09 pm

Once either I or someone else can confirm the HEX file above is correct and error-free I'll post it in the 'Software' section of this forum as it is a popular/familiar image. If there are errors, let me know and I'll correct them first.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: 32x64 LED monitor

Postby nanowaver » Sat Jan 02, 2021 6:48 pm

Steve

I am doing this at the moment by displaying the data as an 8 level false colour image on a TFT display. I have found a few minor errors so far but have only looked at 1/3 of the image so far. Will report back in a few days.

Barry
nanowaver
"Fester, enough of the light-bulbs!"
 
Posts: 16
Joined: Sat Sep 29, 2018 5:37 am
Location: Sheffield, UK

Re: 32x64 LED monitor

Postby Steve Anderson » Sun Jan 03, 2021 12:13 pm

nanowaver wrote:I have found a few minor errors so far...Barry

Not surprising, I manually typed it in from that rather blurry image in a previous post and had to guess some values, and/or it's a simple typo...

When you're done let me know where the corrections are required and I'll update the HEX file.

Steve A.

HEX file posted 31/12/2020 removed to correct minor errors, corrected/updated version will be posted in due course. SA.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: 32x64 LED monitor

Postby nanowaver » Sun Jan 03, 2021 11:16 pm

Steve

Attached is a photo of the corrected test card being displayed on a 2.2 inch TFT display where each pixel in the test card is actually displayed as a block of 5 x 5 TFT pixels. I used this for checking the hex data.
My corrections are noted in the partial Arduino sketch listing below. I tried to attach the complete listing but it won't allow it.
Major corrections are starred but I also made pixel 64 in every line = green (on my 8 colour scale) for consistency as some were black and some were green. Maybe pixel 64 on each vertical line was intended to be black?

//vertical line 3 (0C0) ******* row 3 corrected ******
int sig3[] = {0x00, 0x00, 0x00, 0x80, 0x80, 0x6E, 0x00, 0x00, 0x00, 0x05, 0x7B, 0x80, 0x80, 0x7B, 0x05, 0x00,
0x00, 0x00, 0x6E, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x7F, 0x66, 0x3C, 0x1A, 0x08, 0x01,
0x00, 0x00, 0x01, 0x08, 0x1A, 0x3C, 0x66, 0x7F, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
0x80, 0x80, 0x80, 0x80, 0x6E, 0x00, 0x6E, 0x80, 0x80, 0x80, 0x6E, 0x00, 0x6E, 0x80, 0x80, 0x80};

//vertical line 9 (240) **** corrected row 2 *****
int sig9[] = {0x00, 0x00, 0x00, 0x80, 0x80, 0x6E, 0x00, 0x00, 0x40, 0x80, 0x80, 0x40, 0x00, 0x00, 0x6E, 0x80,
0x80, 0x7E, 0x17, 0x4A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xA8, 0x28, 0x00, 0xD0,
0xFF, 0xFF, 0xFF, 0xFF, 0x80, 0x00, 0x80, 0x00, 0x80, 0x00, 0x80, 0xFF, 0xFF, 0xFF, 0x4A, 0x17,
0x7E, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x6E, 0x00, 0x00, 0x6E, 0x80, 0x80, 0x80, 0x80};

//vertical line 22 (580) ***** row 3 corrected ***
int sig22[] = {0x00, 0x00, 0x00, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
0x80, 0x7E, 0x17, 0x4A, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xD7, 0x00, 0xD7,
0xFF, 0xFF, 0xD7, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xD7, 0xFF, 0x4A, 0x17,
0x7E, 0x80, 0x80, 0x80, 0x6E, 0x00, 0x13, 0x13, 0x80, 0x80, 0x6E, 0x00, 0x6E, 0x80, 0x80, 0x80};

The 8 level false colour scale I used is this

// 8 colour scale (black, blue, red, magenta, green, cyan, yellow, white)
uint16_t c[] = {0x0000, 0x001F, 0xF800, 0xF81F, 0x07E0, 0x7FF, 0xFFE0, 0xFFFF};

Hope this is useful

Barry
Attachments
IMG_3504.JPG
IMG_3504.JPG (107.45 KiB) Viewed 5291 times
nanowaver
"Fester, enough of the light-bulbs!"
 
Posts: 16
Joined: Sat Sep 29, 2018 5:37 am
Location: Sheffield, UK

Re: 32x64 LED monitor

Postby Steve Anderson » Mon Jan 04, 2021 11:52 am

Barry, I'll need another coffee or two before I can comprehend the above!!

I don't know why it was done in such a manner, but it works out correct. The single black (0x00) pixel the end of each line, plus the three at the start of the line make up the sync/blanking time. 400Hz line-rate = 2.5ms/line, therefore 1 pixel = 2,500/64 = 39.0625us, 4-off = 156.25us, ideal sync/blanking time.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 5360
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Previous

Return to Electronic NBTV

Who is online

Users browsing this forum: No registered users and 10 guests

cron