CONVERT 640X200 VIDEO SCREEN TO 640X480

[beanhauler]

Has anyone tried this before by converting 8 bit parallel data running at 8MHZ to a VGA that expects 640x480?
Wondered if you used a FPGA /cpld and reclocked the parallel data into a window  and output via a DAC to VGA?
Data is in a 32 kb block that is being accessed by a MSM6255 VIDEO CONTROLLER.
Video infill is configured as 640 x 200 lines. May have to copy to another memory block and either upscale or fit in a window?

 

[Rasz]

ancient laptop or a POS terminal?

here is the other way around https://dorkbotpdx.org/blog/paul/large_lcd_reverse_engineering/
is yours also using dual port ram?

You could modify this VHDL to suit your needs https://sites.google.com/site/tandycocoloco/mda-cga-ega-to-vga https://github.com/lfantoniosi/mce2vga

[beanhauler]

Thank you

intersting stuff. Its a la3200 logic analyser and i think is using the cursor on the chip to overlay the video which is coming from a standard 32k ram chip.
not dual ported .
suppose i could grab the pixel lines but that may need unravelling then which may be more difficult.

i really need a 640x200 screen but they are just too expensive. Need an old pos as you say.

[Rasz]

> i think is using the cursor on the chip

not necessarily, I hastily read the first link I gave you and missed the purpose of dual port ram in the pos terminal (it wasnt for the display at all). It looks like by design MSM6255 has a pass thru mode, so whatever is controlling it has raw access to display ram.

another option is http://www.smbaker.com/raspberry-pi-virtual-floppy-for-isa-pc-xtat-computers modified with CY7C007 32KB dual port sram, some Chinese sources still have them in $2-20 range. Solder in place of M5M5256D and you have hdmi output + bonus wifi/usb access to raw data

[beanhauler]

definitely some food for thought
If i used a dual port ram it would  allow me access to the video ram quite nicely but i still then have a problem translating this from 640x200 to 640x480
I'll have to go away and think about this.

Thanks for your ideas though

The shared video ram currently is being driven by a 6303 running at 8 meg so LCD Clock is running @8 mhz...bit slow for a 640x480
If i used a dual ported ram i suppose i could up the read to something a bit quicker but would then have to pad 640-200 lines.
Dont know enough about dual ported ram need to do some homework.

[RJSV]

I'm maybe not the best, at signal processing theory, but here goes:

    First, you could bypass that graphics processing expertise, and just double up your lines, do each of the 200 source lines twice, then supplement with 80 blank lines, for a total 480. Clocking must be at the (higher) rate, and put those blank lines at bottom of screen.
It might work to custom program a stand-alone processor, or FPGA to generate that clock, rather than 5 or 6 TTL series ICs to generate that.

    Elsewise, I believe from reading, your DSP code should create a continuous function, from 200 points,
and then RE-SAMPLE, at the faster rate (times 2.4).
However, my mistake here, that would only apply if you were changing the horizontal scan.  At least I helped mention the method, in that other case.
   Oh, and your screen might be with content 'squished' and with small blank area at bottom, rather than a more natural fully occupied screen.
   For a real challenge, I believe you need a buffer, and write code to deal with the screen in VERTICAL slices:. those would then get the DSP process, expanding each  200 pixel slice, into your second buffer, 480 pixels per vertical slice.
   Myself, I would go for simply doubling up the horiz rows, and live with the blank space at bottom of display. Besides, I don't have any re-scaling code handy.
  I'm maybe not the best help, here, and trying to remember, an author out of Brazil, had good book on Digital Image Processing.

[Rasz]

If i used a dual ported ram i suppose i could up the read to something a bit quicker but would then have to pad 640-200 lines.

Thats what rpi zero is there for, uses its 26gpios to read dual ported SRAM, interpret and display over hdmi
https://thepihut.com/blogs/raspberry-pi-tutorials/34512708-troubleshooting-a-raspberry-pi-hdmi-vga-adapter
as you can see 640x480 is supported with simple $5-8 hdmi-to-vga adapter

[beanhauler]

Thanks for your suggestion
Slight issue with the example is the size of the dual ported memory
The lcd driver is fishing the video in a round robin on 15 address lines which is 32k locations
The ISA bus example is limited to 10 which is only a 1K or 1024 size.
If i rip out the video ram and opt for a dual port i would need an equivalent size dual port of 32kx 8 because of the processor mapping[6303]
The lcd driver chip is capable of addressing 32k for video access and the display only requires 16k of video data so i think it maybe being told where to start and end.
This complicates matters because it may use this to zoom the screen or add the little box overlays and text to the screen.
I think it works like this....suspend the driver chip and write new data to the video buffer. Address the driver chip and tell it where to start and end in a 16K window.
My only hope would be to wait for the driver to suspend.As soon as it goes on its merry way for 16K locations grab the data off the bus in parallel with the graphics driver store it and buffer and reclock to a dac and vga one frame at a time using fast memory. Messy but probably
the only way.
I do have  dump of the main program but its in asm which is tough going even in IDA.
Trouble is all the 640x200 9 inch screens are mega expensive and not worth it for an old logic analyser.

[RJSV]

I know you've moved further on solving the pixel count upgrade, however, I remembered that book, on graphics DSP, describing software up-sampling etc.
Sorry it maybe doesn't relate, directly...
  The book is "Graphics Image Warping",
By George Walberg    I believe out of Brazil

[RJSV]

Uh, sorry, I need to correct that book ref:

   "Digital Image Processing", by George Walberg

[Rasz]

Slight issue with the example is the size of the dual ported memory
The lcd driver is fishing the video in a round robin on 15 address lines which is 32k locations

hence substituting MSM6255M5M5256D  with CY7C007

>The ISA bus example is limited to 10 which is only a 1K or 1024 size.

its PCB is limited to dip48 ram chip, but not the overall design concept. rpi has 26 gpio, enough for 32KB sram

>If i rip out the video ram and opt for a dual port i would need an equivalent size dual port of 32kx 8 because of the processor mapping[6303]

CY7C007

>The lcd driver chip is capable of addressing 32k for video access and the display only requires 16k of video data so i think it maybe being told where to start and end.

do you have another logic analyzer to sniff SRAM content while this one is running?

>This complicates matters because it may use this to zoom the screen or add the little box overlays and text to the screen.
I think it works like this....suspend the driver chip and write new data to the video buffer. Address the driver chip and tell it where to start and end in a 16K window.

for sniffing MSM6255 even something as basic as $4 CY7C68013A board from ebay should be enough, you only need hmm 10 bits at 8MHz?

>My only hope would be to wait for the driver to suspend.As soon as it goes on its merry way for 16K locations grab the data off the bus in parallel with the graphics driver store it and buffer and reclock to a dac and vga one frame at a time using fast memory.

this isnt the nineties, just throw rpi at it and display over hdmi/vga at whatever resolution you want. Only drawback is waiting ~25 seconds for rpi to boot.
Even if you want to do it the hard way with fixed logic you dont need a dac, its B/W signal after all so one pin and resistor ladder with fixed color will suffice.

>Trouble is all the 640x200 9 inch screens are mega expensive and not worth it for an old logic analyser.

vintage hardware, vintage collectors pricing ;-)


EDIT: another alternative is https://github.com/hoglet67/RGBtoHDMI , again rpi, but this time with cpld to grab digital mda/cga/ega signals
whole $20 worth of hardware + rpi zero https://stardot.org.uk/forums/viewtopic.php?f=8&t=20404 (wonder if seller is the same IanB as on eevblog forum)
As a bonus its Bare Metal ARM programming, meaning no waiting for the thing to boot.

looking at http://pdf.datasheetcatalog.com/datasheet/oki/MSM6255.pdf pages 21-24 and 30 MSM6255 is just scanning its output in reverse order on UD/LD pins. You will have to write your own code interpreting captured data.

[beanhauler]

just bought the cy7c68013a board so i can sniff the sram content.
be interesting to see on the msm6255 when dien is low what addresses are output to the video ram chip to dump its output on the data bus.
whether there is any change in address range or its the same old for whatever button is pressed on the la3200 panel.
trouble is i cant see the output so its difficult to know but may be able to glean from the user manual.
Anyway that does not really matter as long as the data byte for byte can be captured.
Important point is though that if i substitute 6255 with cy7c007 the 6303 probably sets up the 6255 on boot and reads back to verify its there
If it finds it gone it may be upset. it does need to tell it to jump into graphics mode.
If i remove it i would have to emulate it using a cpld or such like. i think leave it where it is as its none the wiser.
Of course if i reversed the 6303 program i coul dmodify the code and stuff in another  512

One thing that is puzzling me though is how the layout works although it is black and white.
Referring to the screen layout for the 6255 its arranged in 200 rows of chars or bytes at 8 bits each which are 4Fh long or 80 bytes per row
This translates to 640 bits funnily enough
so if i interpret this into rgb land one pixel is either black or white. If its 1 then i can colour using the rgb to hdmi option to say peak white all 0.7V or for black 0 then turn it blue ov ov 0.7v and let the pi do the rest?. The pi will need a frame pulse and a line sync perhaps or sync on green?

[Rasz]

just bought the cy7c68013a board so i can sniff the sram content.
be interesting to see on the msm6255 when dien is low what addresses are output to the video ram chip to dump its output on the data bus.
whether there is any change in address range or its the same old for whatever button is pressed on the la3200 panel.
trouble is i cant see the output so its difficult to know but may be able to glean from the user manual.
Anyway that does not really matter as long as the data byte for byte can be captured.

note that cy7c68013a has only 16 gpios so you wont be able to sniff sram content (without clever tricks, like observing its all written sequentially and later just assuming this fact while only capturing couple first address lines), but enough to listen on msm6255 being configured and programmed

for 16bit logic capture you will need either https://sigrok.org/wiki/Fx2lafw or https://www.usbee.com/dx.html software package + 08a9:0015 vid/pid programmed

Important point is though that if i substitute 6255 with cy7c007 the 6303 probably sets up the 6255 on boot and reads back to verify its there
If it finds it gone it may be upset. it does need to tell it to jump into graphics mode.

It was a mistake, I meant M5M5256D, too much copy&paste

One thing that is puzzling me though is how the layout works although it is black and white.
Referring to the screen layout for the 6255 its arranged in 200 rows of chars or bytes at 8 bits each which are 4Fh long or 80 bytes per row
This translates to 640 bits funnily enough

are you sure its not 4 shades?

so if i interpret this into rgb land one pixel is either black or white. If its 1 then i can colour using the rgb to hdmi option to say peak white all 0.7V or for black 0 then turn it blue ov ov 0.7v and let the pi do the rest?. The pi will need a frame pulse and a line sync perhaps or sync on green?

look into source directory in https://github.com/hoglet67/RGBtoHDMI  it has both CPLD firmwares specific to particular signals its emant to intercept (separaet for cga, another one for rgb ones, composite etc) and rpi software for interpreting the data and pushing it out HDMI at whatever resolution and scaling you want. All in a mix of C and ARM assembly.

[beanhauler]

Thanks for your comments.
That bit about 4 shades. If i only have 1 bit per screen pixel that 0 or 1 i cant see how i get 4 shades.
unless there are more than 1 bit per pixel?
description is in attached

[Rasz]

>Screen updating is carried out by the LCD controller which outputs the
display data as 4 parallel bits, UD0-UD3, which are latched by the
display using LIP, the display data latch signal

+CLP pin makes it 6 bits to capture, cy7c68013a will have no problem grabbing that. Then after looking at the data format you can decide how to approach the problem.

[Rasz]

video series about  https://github.com/hoglet67/RGBtoHDMI 

[rh100605]

I seem to have missed the problem being solved here as any screen replacement on the LA3200/4800 has to fit into the front panel to align with the soft keys underneath.

If the backlight is the problem I  have replaced the backlight in one of these screens with led ccfl replacements available on Ebay and it is much better than the original. You just pull out the old tube and push back in two parallel LED strips cut to size and then install a 12 volt supply.

If the entire display has failed then as the 6303 develops a graphic image 640x200 by assembler code into the SRAM, to develop 640x480 is possible only by line doubling.
Where can you find a 640x480 screen that fits in the front panel?  (at a reasonable cost!)
I have only found 10.1 inch 800x600 and 1024x800 colour LCDs with adapter boards.

As a matter of interest I have found the content of any SRAM by replacing with a 32kx8 battery backed SRAMs (Dallas Semiconductor DS1230) or the  STK16C88-W45 and then , when removed, using a ROM reader to unload it. I reverse engineered the disassembler code this way.

I look forward to hearing from you