« first day    last day (1545 days later) » 

12:02 AM
Too bad we don't have a "mostly MDA" configuration dump. Your PC7640 BIOS provides a "mostly CGA" dump, because that one is used to restore a sensible CGA configuration after the panel has been used.
The "mostly MDA" configuration should point to the underline enabling mechanism.
 
fuz
yeah
So I checked reg 27 again
A1 gives us a 2 bit configuration
two scan lines written, two blank
and so on
 
And you only see the right half of the image?
 
fuz
yeah
ehm.. not two scan lines written
I mean two horizontal pixels written, two blank
the image is unstable on the left of the screen and gradually stabilises towards the right
really freaky
 
Yes, of course.
When you run in two-bit mode, the shift clock is twice as fast as designed.
 
fuz
so we have: 00 is serial, 40 is 8 bit parallel, 80 is 4 bit parallel, A0 is 2 bit parallel
 
12:10 AM
Pixels get shifted through the shift register, and the more left the pixels are, the more shift cycles they have undergone.
So if the shift register is overclocked, the leftmost pixels suffer most.
 
fuz
yeah
 
Switching to the slow clock should reduce the symptom in that case.
 
fuz
I can try
indeed
 
I suppose "serial" (where the shift clock is doubled another time) also provides a quite unstable image.
 
fuz
oh yeah
I've updated fuz.su/~fuz/text/registers.txt with these findings
 
12:13 AM
OK, that all makes sense. I wonder why they need three configuration bits for the modes, though.
20, 40 and 80 all affect the panel transfer width.
 
fuz
aren't there only two?
bit 5 is not used methinks
 
Then it should read "C0 is 2 bit parallel" methinks.
 
fuz
ehem... yeah
but c0 behaves as 8 bit parallel
let's try some more things
 
So C0 behaves like 40. No idea why...
Register 21 is "number of characters shifted per line". If you decrease it, you put only 79 new characters in the panel for a new scanline, so the ex-rightmost charactor did not get pushed out, but gets a second chance to be the leftmost character now.
 
fuz
wait what
 
12:20 AM
No idea how this interacts with character boxes that are not a multiple of the bus width, though.
 
fuz
okay, so c0 is indeed 8 bit parallel
40 is 2 bit parallel
maybe I got it wrong before?
 
Seems so.
 
fuz
makes more sense this way. I've updated the document
 
So 00 = 1bit, 40 = 2bit, 80 = 4 bit, C0 = 8 bit. Yes, this is an intuitive assignment.
 
fuz
I can make no sense of what 20 does though. It is set for MDA mode
maybe it assigns meanings to the pins on the external display connector?
 
12:23 AM
Not that likely. MDA video signal is output to LD3, whereas RGBI is simulatneously output to LD4..LD7.
No need to switch anything in that regard.
 
fuz
I see
bit 08 also does something as it is set for the external monitor on the schneider
(it's also set for the plasma configuration, but no idea in this regard)
 
MDA collides with flat 4-bit flat panel output, though.
So you could be right that it switches between panel bit 3 and MDA video.
 
fuz
A1 behaves like 81 though
 
Did you observe any effect of 20 yet?
 
fuz
I don't think so
I thought I did, but it was a fluke
I tested all of 01, 21, 41, 61, 81, a1, c1, and e1 previously
and found that 20 makes no observable difference
 
12:28 AM
The multiplex between panel bit 3 and MDA video could be implemented by just evaluating the panel bus width. So no need to control that with a separate bit.
 
fuz
interestingly, if I change 81 to 80, I see a shifted image with the beginning of each line missing
if it was that way, I would see noise in column 3
but I don't
 
Test it in 2-bit mode (i.e. 61)
 
fuz
I recall no difference between 41 and 61, let me try again
 
OK, in that case, forgot the theory about MDA video.
 
fuz
nope, no difference
 
12:31 AM
Back to CPU access to the second half of memory. Did you try the hercules memory bit (3df, bit 02) yet?
 
fuz
I think that bit has been on the whole time
I was always setting o 3df, 83
 
fuz
perhaps 40 makes a difference in graphics mode?
 
You mean 20?
 
fuz
uhm yeah
sorry, I'm getting a bit tired
 
12:34 AM
Yeah, we should quit soon. Work is calling tomorrow.
 
fuz
12:45 AM
0
A: How do I configure a V6366 graphics controller for 640x400 B/W?

fuzWith great help by user Michael Karcher we found the following details poking through the V6366 controller's innards: # ports 102 VDCS (something about switching to the external monitor?) 3d4 CRTC index port 3d5 CRTC data port 3d8 Mode control register 3d9 Color control register 3da statu...

 
1:15 AM
I found some register description for the V6388: cs.nyu.edu/~mwalfish/classes/ut/f09-cs395t/ref/hardware/vgadoc/…
Not very much like the V6366, but some bits might give us ideas how yamaha engineers think about flat panel driving configuration.
 
 
12 hours later…
fuz
1:29 PM
Cool! I see a lot of similarities.
 
 
2 hours later…
fuz
3:07 PM
Some people at the VzEkC foræ have posted that this could be similar to the Olivetti 640x400 graphics mode: forum.classic-computing.de/forum/index.php?thread/…
 
 
8 hours later…
10:47 PM
I also remembered the Olivetti / AT&T graphics solution. If I remember correctly, saw a laptop using one of the clones in 1992. The 640x400 mode is mainly enabled by a control bit in the Olivetti extra control register at 3de. This obviously conflicts with the Y6366 register assignment.
Did you get around to probe any further bits today?
 
fuz
not yet, I just got home 30 minutes ago
I can confirm that the Olivetti modes do not work
I want to try 37 and 3f today
Or do you have any other ideas?
I should perhaps write a program that displays a test pattern and probes whether display RAM got unmirrored
 
Yes, some test automation would be really helpful.
I expect some of the bits in 31 and 32 to be override enable bits. But maybe its just one bit that enables overriding.
 
fuz
ok
 
In the external monitor configuration, the actual CRTC registers are used. In the flat panel configuration, the overriden values are used. Something must switch between the configurations.
 
fuz
yeah
 
10:55 PM
The CGA-on-MDA configuration also uses register overrides, so it also needs the override to be enabled.
Hmm, didn't you already probe most of the bits in 37/3F, and they were about repeating lines and cursor offset?
 
fuz
I probed 37
maybe 3f is different
 
Might be. Graphics mode has no cursor, so the assignment might differ.
Although the re-scanning bits are the same in 37 and 3f.
 
fuz
yeah
figured that out, too
with 3f = 00 it's actually a pretty crip 640x200 mode
so how about 31 then
 
It's not 640x400 with two lines good, two lines garbage?
 
fuz
It's two copies of the 640x200 bitmap atop each other
 
11:01 PM
Oh, yes, of course.
 
fuz
I guess because rescan is disabled, the screen fits two copies of the screen
 
The bank count is still only two.
Exactly.
 
fuz
yeah
perhaps a good candidate for a 640x400 graphics mode
 
The panel ignores the premature VSYNC (also called FLM = first line mark).
 
fuz
if there is one that is
 
11:02 PM
With two banks, 256 lines (minus some management) is the limit.
 
fuz
iirc the number of lines on the screen is already controlled by some other register
oh yeah, I forgot that the 6366 sees the whole 32k at all times
so clearly, it can't try to render banks 3 and 4 but sees bank 1 and 2 again
 
Yes, the number of active lines is in CRTC 06. The number of lines (including blanking) is in 34 / 35
In my last sentence, "lines" means actually line-pairs or line-quadruples.
 
fuz
yeah
register 31 seems to shift the screen horizontally by the given number of characters
 
You are back to text mode?
 
fuz
yeah
you said 30-37 were for text mode, so I went back to text mode
 
11:07 PM
I am surprised we find another shifting register. We already have a shift register in 23.
31 in text is likely the same as 39 in graphics.
How do lines wrap around when you used register 31?
 
fuz
yeah
but the font is messed up in the wrapped lines
not all bits seem to affect shift
it seems... discontinuous?
 
The register might have two four-bit fields.
What kind of messed up is the font?
And do you mean its messed up on all lines past a specific column, or only on the first or last line?
 
fuz
hard to explain
all cwrapped around columns are messed up
the font is very readable, it looks like the first and last 2 (?) scan lines of each character are swapped or something
not sure
 
So what values did you try? Default is DC.
 
fuz
I tried f8 which makes the line start pretty far on the right
makes the screen have 18 columns before it wraps
 
11:15 PM
So we are missing 62 columns.
 
fuz
10 columns are lost in tn the wraparound
and after that, the line appears back at the beginning
with the garbled char set
 
10 columns are no surprise. The horizontal total override in register 30 is 59hex (or 89 decimal).
It should be horizontal cycle length minus 1.
 
fuz
makes sense
 
So we have 90 character cycles per scan line, whereas we have 80 characters per line.
 
fuz
incrementing reg 31 makes the start of the screen move left one column btw
 
11:18 PM
So this does something funky with the horizontal sync again.
 
fuz
probably
 
What happened when you played around with 23? Did you obeserve comparable wrapping?
 
fuz
ehem... I don't remember
 
OK, I'm checking chat history.
 
fuz
it's very similar
in fact, it seems equal, except the value is different
even the garbling seems to be the same
 
11:22 PM
Do effects add up?
 
fuz
I suppose so
let me try
 
So if you increase one register and decrease the other one, does the image return to the same state?
 
fuz
yes
they seem to cancel out
 
23 is global, 31/39 is text/graphics specific. Maybe that's why we have two of the registers.
 
fuz
if I increase 23, I need to decrease 31
reg 23 ignores the MSB
 
11:24 PM
The idea could be that you can move around with 23 using e.g. hot keys if panel size is smaller than the image size.
 
fuz
good idea
 
Whereas 31/39 might provide a mode-specific baseline for the panel sync pulse.
 
fuz
yeah
btw, bit 7 doesn't seem to be ignored for 31
whereas it seems to be for 23
 
Hmm, could 31 be some kind of horizontal sync start override?
 
fuz
so dc + 1f = FB = 251 dec. could be -4?
 
11:28 PM
Please test whether changing horizontal sync position (CRTC 02) also has an effect.
Default for text 80-char mode is 5C.
Likely no coincidence: 5C + 80 = DC
 
fuz
interesting
one thing I found is that I set the register to a very low value, onely the lsb seems to do anything
(register 31 that is)
let's try 5c
ehem... how do I access crtc 2 again? Was it 2 to 3d4 and then data to 3d5?
 
The idea of this register being horizontal sync position override makes less sense if we look at the CGA-on-MDA values. F8 would be 78 | 80. But the horizontal sync position for MDA mode should be 52, not 78 according to my documentation.
Yes, just as you write. But you can merge it into a 16-bit write.
 
fuz
I'm just doing this with o in debug
can this do 16 bit writes? I never checked
 
Won't work.
The video processor can not do 16 bit writes. That's why it works. The processor sees that the 16-bit write was not accepted and re-writes the top 8 bits to the successive address.
Oops, misunderstood you
 
fuz
I see
 
11:34 PM
debug can not do 16 bit writes.
 
fuz
writing to CRTC register 2 has no effect
 
But 16 bit writes work with the video card.
 
fuz
apparently
 
If you write using "o 3d4 2 // o 3d5 nonsense", the write won't end up in register 2.
 
fuz
really?
 
11:35 PM
While you type, the cursor position gets updated, and the index gets overwritten for that.
 
fuz
oh I recall, don't you need to set up the debug area
 
You need to write an assembly snippet to update CRTC registers.
like "a100 // mov ax, 5002 // mov dx,3d4 // out dx,ax // int 3 // // g=100"
 
fuz
I see
 
This will write 50 into register 2
 
fuz
oh yeah, that works
 
11:37 PM
Register 2 also moves the screen?
 
fuz
yeah
it's now shifted right by a bit
 
should be 12 characters.
 
fuz
it is
 
The value I told you is 12 characters off, as 5C is normal.
 
fuz
wait... it's less
5c shifts the screen too far to the left
 
11:39 PM
Makes sense that CRTC02 still works. This register was used by games for horizontal screen shaking effects.
 
fuz
in fact, two characters too far
 
Did you restore 23 and 31 to their sane defaults?
 
fuz
yeah
setting CRTC 02 to 5a does the trick
 
I cross-check the BIOS then. 5C as default is taken from a graphics card documentation book, not your BIOS.
 
fuz
do you recall what values the BIOS sets the CRTC registers up with?
 
11:40 PM
Yes, your BIOS uses 5A.
 
fuz
the tulip uses 52 here
makes sense
can you send me the full set so I can add it to the document?
 
OK, it's easier to paste than to write down:
71 50 5A 0A 1F 06 19 1C
02 07 06 07 00 00 00 00
 
fuz
does it differ for plasma vs. CRT?
 
No, it does not differ. The BIOS part that programs CRT values is completely plasma-agnostic.
 
fuz
ok
 
11:44 PM
The idea is that (as long as you don't switch monitors), you set up the 3dd/3de registers only once and then updating the CRT registers just does the right thing, even with a flat panel that does not use actual CGA timings.
 
fuz
makes sense
 
Actual 5A setting makes no sense for the plasma display, as it only has columns 00 to 59.
But with adjusting it "-4" as you calculated, 56 would be inside the valid range.
It seem to make sense that 31 is intended as "horizontal sync delta" register.
MDA default is 52. CGA default seems to be 5A (and my book is wrong here). CGA-on-MDA uses a F8 in this register, which is -8, exactly what you need to transform the CGA into the MDA value.
 
fuz
ok
 
Also matches for graphics mode: CGA uses 2D, HGC uses 2E (for 720 pixels). Tulip's CGA emulation uses a delta of -1, which would result in 2C. This is 2 character clocks off the 720-pixel values. (the sync comes 16 pixels early).
 
fuz
so it cuts off 16 pixels?
 
11:54 PM
It moves the image 16 pixels to the right.
 
fuz
ok
 
To recenter a 640 pixel image from a 720 pixel frame, a movement by 40 pixels would be requirec, though.
You wrote you get non-linear effects if you lower the value. I have some suspicion.
If we get below "-5A", the result overflows.
 
fuz
possible
 
CRTC 02 is 5A, and if we subtract more than 5A, horizontal sync pos is actually never reached. I wonder why we get a stable image with that at all...
 
fuz
good question
probably some sort of cheating in the V6366
 

« first day    last day (1545 days later) »