Very good answer! I'm sorry I forgot to link the disk images when I posted the question (I had uploaded them to my website for an unrelated post on another forum and forgot to link them here), I have added the links now. I wonder how exactly the palette bits work. They don't seem to be a bitmap. Perhaps there is some other chip with similar register usage that is documented better?

Is there anything I can do with the computer to help you get more details about this? Let me try to get a screenshot of the different dithering patterns so we can compare them to the register contents.

I was just going to suggest looking at the screen to match it with the palette registers. It seems there are only 4 bits ever set in the 16 bits available per color. Also the flat panel has a 4-bit interface. Maybe the bits map 1:1 to the interface pins. Are all colors dithered, or is the plasma screen also able to support some intermediate gray scale?

The colours are dithered using a variety of horizontal and diagonal stripe patterns with no obvious correspondence to the register contents. Let me draw you a picture when I get home later (I sadly don't own a usable camera right now).

Are you sure 16 kB are inaccessible? It seems like AD15 is only the GPE signal when in Hercules mode, otherwise it's just another address line. Which TBH makes this circuit even weirder.

I suppose this must be some sort of compatibility mechanism. True CGA cards have 16kB video RAM at B8000 and repeated as BC00. I suppose The 6366 has a mechanism to set the video RAM start address. If you set it to 32k, AD15 will be permanently high, allowing the CPU to see the upper 32k of the video RAM. Not sure how to set this up though.

Good point! Adding 32K to the start address to enable the second 16K of video RAM is a possible implementation. Another possible implementation would be some control bits that choose the function of AD15/GPE, and the "hercules" requirement is just the power-on default of the extended control bits.

The datasheet says: "A gray scaling/hatching display can be used with the Panel or a monochrome monitor." Seems like the PC7640 uses hatching. Possibly the chip has an integrated lookup table mapping gray scale values to hatching patterns.

Good point.

I wonder if it is possible to access the CRTC registers at port 3D4/3D5 like with a real CGA card.

As I understand it: That's the main point of the V6366: As long as you use it with a standard CRT monitor, it is 6845/CGA/Hercules compatible. There are a couple of V6366-based non-flat-panel video cards that work as generic CGA/Hercules compatible boards. The interesting question is: How much do the CRTC registers at 3D4/3D5 have effect on the flat panel display?

That is a good question! I have no idea. Have you found any code in the BIOS that sets up the 6845 CRTC registers?

The BIOS contains the typical IBM compatible MDA/CGA bios that sets up the 6845 registers, the mode register at 3B8/3D8 and the CGA color register at 3D9. It runs this standard code only on mode sets. The V6366 has to map that to flat panel stuff.

The V6366 specific code only runs if the output is switched between CRT and Panel, or (if that code weren't disabled) when the user changes the palette using hot keys.

I see. Makes sense. The weird thing is: I was unable to find any other contemporary laptops using the same graphics processor. My searches turned up nothing really useful. I can't imagine that there was such a wide variety of available LCD/Plasma-compatible display controllers back in the day that this one was never seen.

and surely the 6845 configuration is not directly used. After all, when the 640x480 plasma screen is used, a crisp 8x16 font is used, contradicting the CRTC configuration.

Sadly I do not have an RGBI or EGA monitor to verify whether unconventional CRTC configurations work on an external screen. On the plasma screen, they seem to fail.

It is likely that the 6845 timing configuration (3D4/3D5) is completely ignored, only the mode register bits (3D8) to set low-res/high-res/graphics are interpreted, and settings for those modes are in the 32 mode bytes at index 32-63 in 3DD/3DE.

possibly. But at least the video RAM start address must be evaluated for hardware scrolling to work.

As well as cursor shape and cursor position.

sure

You could try flipping bits in the extended configuration space one-by-one and test whether any bit enables the 400 line graphics mode. You would "just" need to disable the scan-line doubling feature...

Let me try this tomorrow! It's getting late here.

As far as I know, plasma screens don't use a flyback transformer powered by the horizontal frequency, so the chance of frying the screen should be quite low.

Good night.

I found the yamaha "display master cga" board, also called ydm6420 or g776420 to contain the V6366, and a press release that claims that a board called "display master" can do nearly anything at fdocuments.in/document/flat-panel-lcd-team-formed.html . These boards are quite easy to find and contain two ROM chips. Likely one for the character set and another ROM chip for BIOS extension. Alas, they are quite expensive, especially with shipping to my location (Germany).

Another track I am trying to follow: There is a Y6363-based video board by Tulip that supports "color emulation" (CGA on MDA monitor) if the BIOS of the tulip computer is correctly configured. This is most likely using similar features (timing override) as the plasma output on the Schneider PC7640, so maybe the BIOS can give a clue on how the registers work.

Very nice! Unfortunately, I'm located in Germany, too, so I won't be able to get one of these boards either.

I seem to have found the V6363 (not a typo, it's close to the V6366 but not the V6366) detection code in TULIP's diagnose/setup utility. They write 80h to 3DFh to enable extensions, then poke 20h (data port 3DEh) into extended register 29h (index port 3DD), read back 3DFh and finally write 03 into 3DFh again. If the 3DF readback contains 0C1h, the V6363 is detected.

nice find

Can you try whether this ID method works for the V6366 too, maybe with a different signature byte?

yeah, let me try. Should work using the debug command, shouldn't it?

Very likely. The normal bios stuff does not access the 3DD-3DF range, so it should be safe to run those as single debug commands.

So o 3df 80 // i 3df // o 3dd 29 // o 3de 20 // i 3df // o 3df 03 should do it. It's interesting to see whether the 3df value changes when you write 20 into the indexed register.

for the first and second ones I get C1 back

Looks like the chips are similar.

btw, what tool do you use to disassemble and debug the BIOS?

Try replacing the o 3de 20 command by o 3de dF, so toggling all bits in that register, and check whether the C1 disappears.

I own an older version of IDA Pro.

Of course, toggling the bits might mess up the V6366 configuration, and you might need to use the monitor switch hotkeys to recover.

yeah

when I issue o 3de df, the screen goes blank

For BIOS disassembly, the older freeware version of IDA (version 5.0) should be good enough. I don't recall whether the new freeware version (7.0) is still useful for 16-bit BIOS code.

and stays blank

try o 3de 20 to recover

the system seems locked up and does not react to ctrl+alt+del

that didn't help either, let's try again

Oops, didn't expect that.

But you should still be able to power-cycle it.

yeah that worked

Let me check the value programmed by the BIOS into index 29

Hmm, its zero. I expected to find something with bit 20h set.

hm... the system does not lock up if I do this,

but still the screen goes blank and stays blank

Some code in the PC7640 BIOS does the CGA-typical snow-avoidance stuff, waiting for the retrace bit. If poking those bits makes the refresh no longer happen or visible, a wait like this might deadlock.

interesting

let's try some other values

Yeah, you could try to find out which bit makes the screen go blank, or if something else happens to register 3df

ok

Okay, I just tried this:

select register 29, then read from 3de (gives BF)

then I poked into 3de: 0, 1, 2, 4, 8, 10, 20 (w/o poking into 3de again)

when I poked 20 the screen went blank

I was able to get back with the screen blanking hotkeys though

let's try again with resetting the index register

Ineresting. When you first tried it with writing 20 there, you observed c1 on 3df without the screen going black, didn't you?

yeah

I suppose something changed the index register inbetween

That would be surprising, as no software accesses that register during normal operation. But possibly the chip clears or advances the index on every data access.

when I poke a 1 into register 29, I get a single white vertical stripe on the screen

and when I send more numbers, I get more striped

stripes

sending 20 clears them

OK, so maybe 20 has some other function than the lower bits.

Are the stripes added on top of the image, or does the image vanish on poking 1

super weird

basically, column decimal 52 (0 indexed) is made wider

the content of the screen does not change

I suppose the index register is reset after each write to a data register

Do you mean character column 52 or pixel 52?

the character

all further columns are shifted to the right appropriately

Strange. I currently have no idea what useful feature could have this (side) effect.

me neither

0x29 is 41, let's see what the other registers do

If I poke 1f to 28, I get garbage on the screen

if I poke 0, screen goes off (recoverable)

Do you have the initial values at hand?

I could paste them here if not.

I have not

If you could send me the whole set (or add them to the answer) that would be nice

writing 2 makes the screen flicker and display 40 columns twice

other values often make the screen go blank

I suppose this is some timing value

Edited into the answer

thanks

I finally found the V6363 code in the tulip BIOS (it's included in some MAME ROM sets). They use 29h = 00h for chip ID, not 20h as the diagnostic tools does.

ok

Ah, they have a more sophisticated detection algorithm: Then they set 29h = 40h, and expect to read 80h from 3DFh. Likely 40h enabled true readback of 3DFh

ok

And here is a register set they upload into the 6363 to force MDA timings for "color emulation):

Sorry, reformatting was incomplete, I will rewrite that message

I have mapped out register 28: fuz.su/~fuz/text/registers.txt

how are registers 00-1f initialised on the Schneider?

That's the palette stuff. I quoted that in the answer.

A significant difference is that the tulip board uses bit 3 in the first byte for colors 8 to 15 (the bright ones).

Ah, I see

I guess that bit goes straight into the intensity pin.

Oops, I mean bit 2 of course, value of that bit: 04

Bit 0 (value 01) seems to be the primary color of the hatching pattern, as it is 0 for black and 1 for white.

ok

do you have one of these TULIP computers? Which model is it exactly?

No, I don't. I downloaded the resources from the internet today.

I got the BIOS from MAME and the diagnostic tool from vetusware.com, linked from a forum thread.

I see.

Err, obviously I did not get the BIOS from MAME - they don't distribute copyrighted stuff. I got the BIOS from a ROM set for MAME.

There are some similarities, not to my surprise. V6363 register 30 seems to force the horizontal total register (6845 index 00) for example.

can you confirm that the chip allows access to the CRTC through ports 3d4 and 3d5?

The V6363 is, just like your V6366 driven by a plain old CGA/MDA BIOS. It's just once initialized using the table quoted above if the computer is set into "color emulation" mode.

cool!

I was wondering since e.g. BOCHS documents these registers to be only available since EGA

EGA/VGA has a different layout of those registers, which is "heavily inspired" by the 6845.

The registers on CGA/MDA are the real 6845 registers, which behave different.

makes sense

See here for a CGA register list: github.com/achernya/iap-6.828-website/blob/master/readings/…

The ports at 3d4/3d5 are directly passed to the Motorola CRTC chip. The ports 3D8/3D9/3DA are implemented in discrete logic on the CGA board.

The CGA and MDA have quite similar design (except for the missing graphics mode), but differ in address decoding. MDA decodes 3bX instead of 3dX. The 6845 chip and its behaviour is completely identical, though.

V636x 33 seems to override CRTC register 03 (sync pulse width), and V636x 34 seems to override CRTC register 04 (vertical total - 1). V636x 36 overrides the maximum scanline register (character height -1).

I have the impression that 38-3E is another set of overrides used for graphics modes.

possible

So I just tried something. I started a game called paku paku which uses the hacked 160x100 pseudo-graphics mode

it causes the screen to go blank and then hangs the system

so clearly that didn't work

That mode is quite easy to emulate, if varying the character height is supported. So I guess it is not. I used to have a breakout clone using the 160x100 mode.

This mode also fails on EGA/VGA cards, because their 3d4/3d5 register usage is incompatible with the CGA usage.

makes sense

I read that 8088MPH (the ultimate CGA composite output demo) also fails on V6363 based cards. Their setup is quite similar to the 160x100 mode.

interesting. Where did you read that?

vcfed.org/forum/…

What's the difference between the V6363 and V6366?

The V6366 has advertised flat panel support (e.g. with support for 640x400 panels that are addressed like two 640x200 panels), while the V6363 does not. That chip is only meant for "real" cathode-ray tubes.

Makes sense

Perhaps this makes it easier to find application notes

The modes advertised in the product brief are identical. This includes support for digital monitors with 9bpp (3bits per component, called "linear RGB").

I refuse to call the 10-page document a data sheet, that's why I call it "product brief".

Considering the whole family (V6355, V6363, V6366, V6377, V6388), it's still the V6366 with most google hits. Probably that one survived as "cheapest CGA/MDA compatible sensible flat-panel controller".

surprising that no application notes remain

I guess they were never scanned. Might also be that Yamaha claims copyright on them and forbids distribution.

possible and very shitty

are you aware of any libraries that might have 'em?

There are some forum posts from around 18 years ago by people claiming to have data books with hardcopies of the data sheet.

Hm... maybe they still have them

Like here: electronicspoint.com/forums/threads/…

Or here: verycomputer.com/31_4ec9911709b553d7_1.htm

yeah, I saw that one

and that one too

Or more like here: verycomputer.com/31_b1bcb5083d13af28_1.htm

Yes, I supposed your Google turns up the same result aas my Google.

This link turns up on google and might be interesting: 4donline.ihs.com/images/VipMasterIC/IC/YAMA/YAMAS00459/…

but I get a 403, which sucks

I'm very confident now (by comparing numbers) that indeed V6366 30-37 are CRTC override values for "text mode" and 38-3F are override values for "graphics mode", as determined by 3D8, Bit 1. 31/32/37 and 39/3A/3F do not have 1:1 correspondence in 6845 registers, so there might be hidden gems in those registers, but I am not sure.

ok

The vertical timing for "CGA graphics on MDA monitor" is way off in the "color emulation" table, unless the chip has hardware support to repeat every second scan line.

I guess it does.

It must have. Otherwise it couldn't display 200 lines on a 400 lines Plasma display

which CRTC registers are being overriden?

there are 16 CRTC registers, aren't threre?

nice find btw

bit 7 of register 63 could be the display disable bit btw

it makes sense turning it on before changing the CRTC configuration

30/38 overrides horizontal total (CRTC00); 33/3B overrides sync pulse width (CRTC 03); 34/3C overrides vertical total (CRTC 04); 35/3D overrides vertical total adjust (CRTC 05); 36/3E overrides maximum scanline (CRTC 09).

Display enable sounds valid too, but I consider "write enable for 20..3F" more likely.

OTOH, no, it can't be that.

what can I do to test the hypothesis?

You can write to the registers in the 20ish range without that bit being set.

Just set it and test whether the panel goes blank.

remember, I did that before

well, I didn't know what value that bit had, let's test

Otherwise, you can play with register 34, text mode vertical total. If you decrease it from 19 (now) to something like 17, the bottom text lines should disappear.

all numbers are hex in my last sentence.

writing 80 to register 63 causes the screen to be rotated right by a about 30-ish columns

with the columns on the left having a slightly garbled font

Better write E7 there.

The bios initializes it to 67

Ah, garbled font. Interesting. Maybe you hit the 9pixels/character mode by clearing the other bits in that register.

E7 causes the screen to be shifted to the left by about 10 columns with the right hand side being blank

the font is garbled too

67 does the same thing

Hmm, strange. According to my theory, register 63(decimal) should be used in graphics mode only.

(shifted left by 8 characters to be precise)

ehm... I used register 63 hexadecimal

I am surprised that writing to that register has some effect at all.

did you mean 63 to be decimal originally?

let me try register hex 34 instead

writing to hex 34 has no effect

There is most likely no register above 3F(hex).

sorry

Now try writing E7 to 3F hex and write to 34 again.

I forgot to disable write protect again

Which write protect do you mean?

80 to 3DF?

let me try again (the 3df one)

what shall I write to 34?

Its 19h now. Write 17h.

makes the screen go out

It should mess up the lowest one or two text lines. Or go out of sync.

probably the latter

Use the hotkey to restore.

writing 19 makes the screen come back. It blinked for a short time when I wrote some other value, so I assume it just goes out of sync

So you were able to make the screen go out without setting bit 7 in register 3F? Then my suspicion about that bit being write protect for the timing registers is wrong.

ehem... what shall I write to 3F?

yeah, I was able to

Try writing E7 to 3F, and if the screen goes out, your theory about that bit being "CRTC disable" is likely correct.

3F is at 67 now.

does nothing

maybe it only does something to an external CRT? Let's try 37 instead

turns off the cursor

The default of 37 is different.

cursor stays off if I wrote 67

It's 60.

Or E0 with the top bit set.

if I write 1b (like in the MDA setup), I get about twice the number of lines but each line has a garbled font

garbled as if the first and last scan lines of each character were used

and the screen is repeated horizontally

The proper value for your plasma display is 60

given that, perhaps 37 is about the number of horizontal pixels per character?

Maybe there is a clock-divide-by-2 somewhere in that register. Double pixel clock means half character width, so you would get two repetitions horizontally.

possible

00 gives two repetitions and a fast cursor

Just to be clear: We are talking about two repetitions left/right, and also the double amount of lines?

Or is one repetition at the top and one at the bottom?

If we get two repetitions top/bottom, you likely stumbled over the "split panel" bit. As far as I know, all 640x400 panels are logically two 640x200 panels driven (nearly) at the same time.

one repetition at the top, one at the bottom

the bottom 3 bits seem to be the cursor offset from the base line

On the other hand, a "split panel" bit would not make sense in the mode-specific registers in the 3x range, as the panel type does not change when switching text/graphics mode.

Probably the bottom three bits control how the 6845 cursor shape registers are mapped to real cursor shapes.

possible

setting bit 3 (08) disables the cursor

Or it moves it out of the character cell. We can't be sure its designed as disable bit, even if it physically disables the cursor.

possible

I guess one of the bits is the text-mode expansion bit.

okay, it does not

The CRTC registers (even the override ones) are programmed for an 8-line character cell. Yet you get a 16-line character cell on your screen.

This mapping has to be enabled by some bit.

my hypothesis was wrong

if the least significant bits are 0-7, the cursor is raised by that many 8th of a cell

bit 08 is weird

sometimes it disables the cursor completely, sometimes it seems to cause the cursor to blink over the whole character

The plasma settings all have 60 in bits 5/6. I suppose they cause the 200 to 400 line expansion. The CGA-text-on-MDA setting has 00 there and actual CRTC values for a 14-line character box, and the CGA-graphics on MDA (which needs to double every other line) has 20 there.

Perhaps 20 doubles the odd lines and 40 doubles the even lines...

possible

let's try 20 and 40

20 causes a flickering screen and a garbled font. The first 10 lines are repeated after the normal screen contents

40 is similar but only 4 lines are repeated

in both cases, the beginning of the screen is incorrect

The 20 thing matches my expectations. If the screen expects 400 lines (doubled from 200), but it only gets every other line doubled, we only have 300 lines per frame.

You could try counter that by increasing the character height register.

Let me calculate that for a moment

bit 80 seems to do something too

If only every other line is doubled, we need to produce 400/1.5 = 266 lines. A character box of 11 pixels should do the trick, as this will produce 275 lines, which is quite close to 266.

what do I need to set?

So writing 20 to 37 and writing 0A to 36 should yield in a stable image.

But the characters will look weird.

ok, moment

Default of 36 is 07 (8 lines per character, which is doubled to 16)

the image does become stable

Are all characters cut at the bottom?

no

it looks a bit like every other (?) scan line is missing

Hmm, then it's not as easy as I expected. I expected to see the first 11 rows of the 8x16 characters.

every even one from odee lines, every odd one from even lines (or the other way round=

the number of rows is still 25-ish

ah not quite

maybe 23.5 ish rows

if I set 37 back to 60 with this mode, each character is display 1.5 times vertically

which seems correct

Right, thats expected.

So setting it to 20 does not just cut the bottom of the repeated characters, but it somehow skips lines compared to 60.

I mean, I might have gotten this wrong

after all, debug's command line is not the ideal test patten

okay, I did get that wrong

indeed, you can see the characters repeated vertically

What setting? 36=0A, 37=60?

the difference between 20 and 40 is that 20 is a bit more squished vertically

yeah

Can you try 36=0F, 37=00?

This should result in a 8x8 character box.

And a 50-line mode.

No.

25-line mode with strange font.