last day (1546 days later) » 

fuz
9:00 PM
with 24 = 2 it does work though
 
Maybe the kanji-assisting modes with half-width characters below 8 pixels do not work in 8-bit RAM mode. The V6366 has half of the RAM data pins disconnected in the Schneider PC7640.
 
fuz
possible
anyway, 24 = 6 and 24 = 5 led to a blank (but syncing) screen
 
Hmm, we tried attribut 7, attribut 87 (normal + blinking) and 78 (inverse + dark gray foreground), and with 24 = 1 we always have the same display? No change in color and no change on repetition?
 
fuz
yes
exactly that
interesting: I switched to 24 = 8 and then back to 24 = 2 and about 2/3 of the screen came out garbled
sorry, the whole screen came out garbled
it displayed an almost repeated pattern
 
Your findings about register 24 are consistent with the dumps we have: your PC has 02 there (character cell 8 pixels), whereas CGA emulation on MDA (which outputs standard MDA timing) ha 03 there (character cell 9 pixels, which is correct for MDA).
 
fuz
9:06 PM
yeah.
 
You reported a garbled screen too after you tried 00.
Can you try 0A and than back to 02?
So you only fiddle with bit 3 (value 08).
 
fuz
I've just been doing that
mode 24 = 0a is weird
 
in what way?
 
fuz
the cursor behaves as in mode 2, but only the top half of the screen shows text
and that text is such that of each line either the first or second half is displayed but not both
if I hit newline, the last line I typed swaps between first half and second half, left half of the screen or right half
wait no
it's always the first half of the line
like some sort of dual-column display
 
or you entered a 40-column mode?
 
fuz
9:09 PM
it also appears that it's not really the beginning of the line
 
maybe you divided the pixel clock to the panel by 2?
 
fuz
rather, some columns are missing as if there were extra attribute bytes
possible
 
Or wait. The product brief indicates that the chip support 8-bit panels.
Your panel is a 4-bit panel.
 
fuz
I see character 0, 1, 4, 5, 8, 9, and so on of each text line
but not 2, 3, 6, 7, and so on
 
But you see the characters in full?
 
fuz
9:11 PM
yes
 
OK, then it is more like another control bit for extended width character modes.
 
fuz
possible
 
If 30 is still at 64, can you try 24=09 then?
 
fuz
let me see
similar effect
 
This switches into character width 7 again, but now we have more bytes to play with.
 
fuz
9:14 PM
now, only character 0, 4, 8, ... of each line are displayed twice each
note that there are no gaps between the characters (24 = 0a was the same)
 
No gaps is a direct consequence of the 7-pixel cell.
With 24 = 0A, the gap should have been there.
 
fuz
what I mean is that the missing characters are missing, there's no blank spot or anything
the line just doesn't have them
 
I propose to skip testing the unusual text modes for now, as they might need a different hardware configuration. No way to fit kanjis into a 4K character ROM.
 
fuz
yeah
 
Perhaps the card considers all those characters double-width and tries to fetch the second half by asserting an address bit that is not connected (RA4 comes to mind...)
There might also be the intention to latch character codes into further address lines for a way bigger prom.
 
fuz
9:20 PM
yeah
let me quickly inspect the other bits of register 24
 
So next thing to try is 24 = 12, setting the 08 bit back to usual.
Great minds think alike ;)
 
fuz
bits F0 don't seem to do anything visible
let's try register 25
 
Bit 0 might be clock select.
 
fuz
sending 1 gives me a white screen
 
Your chip is clocked with 14.318MHz and 18 MHz, and it needs 14.318 MHz for the external monitor and 18 MHz for the plasma display.
 
fuz
9:24 PM
sending 3, gives me a flickering, slightly less bright white screen
 
Default is 31.
Keep the 3 in the upper digit for now.
 
fuz
ok
 
30 for external monitor (I suspect 14 MHz), 31 for plasma (I suspect 18 MHz).
 
fuz
the MDA card has 95 here
 
Right. That card has 14.318 MHz in CGA mode and 16MHz in MDA mode.
It also needs to select the non-CGA clock.
That's why I guessed that this bit is clock select.
 
fuz
9:26 PM
if I set 25 = 95, I get a hatched screen with a bunch of 3s in it
could it be memory organisation?
when I go back, I have parts of the video RAM filled with garbage
 
Yes, the SRAM/DRAM toggle might be in that register.
 
fuz
when I set it to 30, the screen becomes less bright
 
That might be a consequence of a lower refresh rate. I don't know about plasma screens that well.
 
fuz
yeah
 
Do you have a tool to measure vsync?
I mean a program that polls the vsync status bit and tells you how many hz you have.
 
fuz
9:28 PM
sadly not
do you have one?
 
I might have written one once, but I have to start digging.
And if I did, the target of that program was VGA, but it shouldn't matter, CGA is compatible in that regard.
 
fuz
yeah
I have turboc on the machine, I can write one real quick
 
I have a turbo C program that was intended for a different purpose, but contains a subfunction to measure vertical frequency.
I can upload it to some webspace. Wait a second.
 
fuz
sure
 
This is a tool to adjust the vertical blanking on VGA cards to lower the refresh rate.
It contains the function testfrq that outputs the refresh rate to the screen.
The point of the program was to slow down video output to help games keep up with the video card.
 
fuz
9:35 PM
needs mytypes.h
 
replace that include by "typedef unsigned long ul"
testfrq doesn't need anything else.
 
fuz
interesting how you worked at FU Berlin
I work at the adjacent Zuse Institute
 
I did a PhD in physics in 2011. But let's not get in details in a publicly recorded chat room. I have no idea who is going to scrape the data from stackexchange in the next 10 years.
 
fuz
sure
turbo C 2.01 doesn't like your code. Perhaps openwatcom is nicer
 
Its written for Borland C++ 2
Turbo C does not like inline assembly, but you should not have any inline assembly left if you strip it down to just testfrq.
What's the matter with turbe C 2.01? Oh, let me try myself, I have turbo C 2 on my XT right next to me.
 
fuz
9:41 PM
I'm trying to compile it with OpenWatcom at the moment
 
Ah, you also need typedef unsigned int ui;
Or pick up the complete mytypes.h from userpage.fu-berlin.de/~mkarcher/mytypes.h
The use of sizeof() inside #if statements in that header is totally nonportable, but it works with borland c++, and likely already with turbo C.
 
fuz
yeah
 
I hereby grant CC0 on both of those files. They are not interesting for any modern stuff anyway.
#if sizeof(foo) == bar also works in Turbo C 2.0
I installed from old floppies, probably I should get the update to 2.01
 
fuz
hm...
I can't get it to build with open watcom
uff, not sure if I have a Borland installaiton anywhere
let's defer this until later
 
I stripped down vfrq.c to only contain gettimer and testfrq, and main just calls testfrq.
Works fine on my Turbo C 2.0 installation.
 
fuz
9:54 PM
can you send me the file?
 
No Problem.
If you trust me, I can just send you the EXE file.
It works on my XT, and measures 70.15 or 70.16 Hz.
Which is correct for VGA.
 
fuz
I do trust you, but having the source as well would be great
 
OK, I updated the C file to only contain what u need and put the EXE file right next to it.
I am not responsible for split seconds lost on the computer timer caused by the program forcefully resetting the IRQ0 timer channel...
I do that to make sure the timer is in a mode that counts "properly".
IRQ0 also works in square-wave output mode (remember, ISA IRQs are edge triggered), but in squared-wave mode, the time chip counts the high phase and the low phase by 2, so getting a proper count reading is more difficult.
 
fuz
yeah
I get 60.13 Hz
now let's see what happens after poking reg. 25
 
If my guess is right, 47.73
 
fuz
10:01 PM
I get 47.82
bingo
 
If not, still 60.13
 
fuz
for 25 = 30
 
So, this bit is for sure clock select.
I calculated the expected value by 60.13 / 18 * 14.318
If Bit 01 is clear, the chip uses the pixel clock at X1 (pin 96), which is OSC from the ISA bus, which is supposed to be 14.31818 MHz.
If Bit 01 is set, the chip uses the pixel clock at X2 (pin 97) which is created by a local 18.000MHz oscillator.
 
fuz
interestingly, setting 25 = 33 also selects the slower clock
 
The observed difference between my expected value and the actual value is most likely due to my program not considering the baseline time needed to read the timer chip.
 
fuz
10:05 PM
sure
30, 32, 33, and 34 all select the slower clock, 35 selects the faster clock again
so I suppose it's two bits for clock selection?
 
Might be.
But the chip only has 2 clock inputs...
 
fuz
weird
 
Maybe bit 2 selects a different clock selection method.
Like picking the clock from some bit of the CGA mode register instead of Bit 01 of register 25.
 
fuz
could be
value 25 = 21 leads to a white screen
and a throughly trashed video RAM
25 = 11 gives me a hatched screen with a bunch of 3's and e's
and a working cursor (yay)
 
Might be that Bit 10 set to select SRAM mode, and Bit 20 is set to select 8-Bit mode.
 
fuz
10:11 PM
can the V6366 even write to the video RAM?
possible
the mda card has 25 = 95
so bit 4 does mean something
 
The tulip card runs in 8-bit DRAM moe.
At least, there are 2 4-bit DRAM chips on that card.
The V6366 mediates the CPU writes.
 
fuz
so perhaps bit 20 is for DRAM?
 
As soons as debug scrolls the screen, the V6366 generates the signalling required for writing.
 
fuz
makes sense
if I set 25 = 71, the graphics don't change
however, if I type anything, the cursor moves to the first column and then the BIOS gets stuck
typing Ctrl+Alt+Del leads to a blank screen but no progress
 
So it messes up CGA compatibility completely if you set 40.
 
fuz
10:15 PM
could be
if the bios waits for vblank to finish, it could be that 40 disables this
maybe 80 is MDA/HGC compat?
 
Typically, the BIOS waits for any sync, because you can write a couple of characters in hsync.
80 might be vsync polarity on the monitor sync output.
CGA has low-active vsync, and MDA has high-active vsync.
This is exploited by multi-mode monitors to detect the number of raster lines.
EGA uses the same sync polarity as MDA, as both modes have ~350 visible lines.
 
fuz
recall that the MDA mode setting is 95, so that's probably not it
oh wait, you mean 80 is polarity?
oh yeah, could be
 
Yes.
40 might be the layout of the status register.
On CGA, VSYNC is in 08. On MDA, VSYNC is in 80.
Bit 08 does not toggle (or it is a dignostic video readback bit, not sure) on MDA cards.
Waiting for bit 08 to toggle will yield an infinite loop if the status register is in MDA mode.
 
fuz
I can test that with a short assembly snippet
 
Sure, go ahead.
Status register is 3D8
 
fuz
10:22 PM
isn't it 3da?
 
Do not try to read 3BA because of "MDA mode". The address bits A4-A9 are decoded externally.
Yes, 3DA. You are right.
 
fuz
I know
 
On the PC7640, the external decoder is fixed to decoding the range 3D0-3DF
 
fuz
I've prepared the following program:
mov
mov dx, 3dd
mov ax, 7125
out dx, ax
mov dx, 3da
in al, dx
mov bh, al
mov dx, 3dd
mov ax, 3125
out dx, ax
mov dx, 3da
in al, dx
int 3
does that look correct?
 
I am still baffled that the PC7640 has logic to decode the character code for 9th-column-expansion, if that computer does not intend to drive 720-pixel panels or MDA monitors...
 
fuz
10:26 PM
it does? but where?
 
Yes, looks correct. But I am unsure how much a single sample of 3da is worth.
 
fuz
I get 06 for both
so that wasn't it
 
I propose a loop like
mov bx, FF00
mov cx, FFFF
in al,dx
and bh,al
or bl,al
loop <address of in instruction>
This will result in bh having all bits set that were set all the time and in bl having all bits clear that were clear all the time.
you can monitor which bits are used to indicate blanking by that.
 
fuz
possible
however, shouldn't the status register change immediately?
also, on a real MDA card, the status register should always have the top 5 bits turned on
 
If just the assignment of the retrace active bits changes, and no retrace is active, how are you going to see it?
 
fuz
10:30 PM
because bits 06 are still set, despite them having no meaning on MDA
 
The MDA compatibility (especially detecting HGC vs MDA) of the V6363 is known to be flaky. I would not rely on knowledge about bits of less importance in the status register.
 
fuz
I see
maybe we can just go ahead with the next register then, there doesn't seem to be much of use here
 
Bits 02 and 04 are lightpen inputs on the CGA card. I don't see why they should be hidden in "MDA mode". Yeah, feel free to skip it.
We are still looking for a bit that enables AD14 as bank select bit. You should recheck the register 25 bits that didn't do anything in text mode, whether they unlock banks two and three.
 
fuz
yeah
 
Bit 80 might be that function, too. It doesn't have to be sync polarity, but sync polarity has to be somewhere.
 
fuz
10:36 PM
none of the bits in reg 26 seem to do anything and that register is 0 in all default configurations
it is!
hurray
 
It is what?
You mean Bit 80 in 25 is bank 2/3 enable.
?
 
fuz
when I set 25 = 31, BC00 is a mirror of B800
when I set 25 = B1, BC00 is a separate memory bank
so yeah
 
OK, so this bit is mirrored to AD15/GPE.
This does not yet bean that this bit enables the video card to output bank number bit 02 to AD14.
 
fuz
yeah
 
But we have at least half of the solution.
We known how the CPU can access the whole 32K of memory.
If register 26 does not do anything in text mode, it might control color depth in graphic modes.
 
fuz
10:40 PM
could be
 
Color depth is a bit difficult to probe with the internal plasma display, though. If the machine were here, I would connect it to my EIZO FlexScan monitor in 64-color-mode.
 
fuz
I do have an RGB monitor but it's B/W only
btw, if I go back to 640x400.bin and set 25 = b1, nothing changes
 
Fixed frequency at MDA?
Set b5
 
fuz
no, it's a CGA monitor (not sure)
 
Yeah, they exist, too. They run at CGA sync frequencies, and map color input pins to gray scales.
They were quite common as cheap graphic-capable displays before Hercules cards were common.
 
fuz
10:45 PM
It's an Olivetti 1231/HA01
I suppose bit 80 only effects text modes
as it doesn't seem to do anything in graphics mode
 
If it happens to be a rebadged Hantarex MDU 1231, it would be a grayscale VGA monitor. This matches a forum post I have seen about someone getting your Olivetty monitor bundled with a PS/2 Model 30 computer. That computer has a 15-pin video socket (but it can produce CGA compatible timing).
In graphics mode, BC00 keeps a mirror of B800?
Even if you set bit 80?
 
fuz
sorry, I mixed things up
the monitor I mean is a Commodore 1402
I must have accidentally swapped them when I moved
yeah, even if I set bit 80
 
What happens if you set bit 80 and Bit 04?
 
fuz
wait a second
I think I made a mistake
 
The 1402 is a MDA-type monitor.
18kHz hsync, 50 Hz vsync.
 
fuz
10:55 PM
interesting
this is not ad15 on after all
I deceived myself: of course the video RAM changes when the screen scrolls
 
Too bad.
If BC00 is no mirror image of B800, BC00 does not change when you scroll.
 
fuz
yeah
 
You could use that as better test.
 
fuz
btw, 40 being the status register layout doesn't make a lot of sense: it is not set in the MDA default configuration
 
It does make sense. That's a configuration to interface to a MDA monitor while making CGA software happy.
 
fuz
10:57 PM
possible
 
So the status register must be in CGA layout for that to work.
Interfacing an MDA monitor, but being mostly CGA compatible the whole point of the magic TULIP configuration. It's called "color emulation" by TULIP.
 
fuz
I see
I wonder if it does the whole hatching thing
 
In all other configurations, the extended registers of the V6363 are kept at their power-on default.
If I remember correctly, the Tulip PGA configuration says that the color emulation mode does the hatching stuff as well.
 
fuz
interesting. This means there is a way to configure the CRT output to use the hatching circuit
 
Yes. The 6363 has no flat-panel output, but the hatching stuff is still in the product brief.
I check where I found that product brief.
 
fuz
11:06 PM
on to register 27!
 
Default is 8B
 
fuz
register 27 is probably a timing register
 
What kind of timing?
 
fuz
setting it to any other value causes completely garbled output on the screen
 
It might also be a "override enable" register.
 
fuz
11:11 PM
the external screen has 08 here, MDA has 2B
 
It is quite similar in your plasma configuration and the CGA-on-MDA emulation, whereas the external screen config has just a single bit set.
 
fuz
yeah
setting ab makes no difference
0b causes a blank (albeit syncing) screen
same with 2b
 
You could try putting the overwritten values into the 6845 registers, and check whether setting 88 still destroys your image.
Obviously, you need 80
 
fuz
why do I need 80?
 
Because you reported you get an image with 8B (default) and AB, but not with 0B and 2B.
 
fuz
11:14 PM
sending 27 = fb causes only half of each character to be printed, and each line is repeated horizontally
9b works fine
perhaps bit 40 doubles the pixel clock and double scans the image?
 
which half of the character? left half?
 
fuz
left half
nah, that pixel clock idea makes no sense
 
I still expect we find a 8-bit panel setting somewhere.
The symptoms make sense for that.
If the chip sends the whole 8-bit image at once to the panel, but the panel only picks up the left 4 bits, you should get what you describe.
 
fuz
makes sense. But then, why are the lines repeated?
 
Because the card only sends half of the clock cycles needed to shift a whole line into the panel.
 
fuz
11:19 PM
possible
 
I guess they have a shift register for loading the next line while driving the previous line.
 
fuz
I thought, maybe this is for greyscale rendering
it would make hardware design easy if each line is repeated twice, so you can do greyscale by first sending a strong pixel and then a weaker one
 
That's kind of how DLP projectors work.
 
fuz
yeah
It's just a kind of PWM
 
The product brief says "Selection of 1-, 2-,4- or 8-bit parallel transmission of data to the panel".
 
fuz
11:24 PM
this would explain why the extenral monitors need separate values: CGA and MDA monitors are pixel-serial
 
In 1 or 2 bit modes, there should be vertical stripes on the pixels not provided, and the right half of the image should be stretched out between the stripes.
The chip is claimed to do 4-bit parallel transfer to a 640x200 panel and pixel serial transfer to a CGA monitor at the same time.
 
fuz
If I send 2b, only every 4th pixel is driven and the screen is unstable, showing three diagonal stripes of pixels
6b is blank syncing screen
 
As your laptop has a 640x400 panel, the panel+plasma capability can not be used.
 
fuz
yeah
 
you wrote 2b two times. Did you mean that?
 
fuz
11:26 PM
no
 
every 4th pixel driven sounds like 1-bit (serial) mode.
 
fuz
however, if the external monitor can be driven at 640x400, that would be terrific as that means I can make a simple level converter to drive a VGA monitor
 
There should be a setting where 2 of 4 pixels are driven. This is the 2-bit mode.
 
fuz
0b is like 2b but only two stripes are really visible (a third one occassionally has a few pixels)
 
Well, you can not. The VGA monitor expects 31.5 kHz horizontal frequency, and to reach that at 640 pixels with a sensible amount of blanking, you need 25MHz pixel clock.
The PC7640 only has 18MHz pixel clock.
 
fuz
11:29 PM
hm... sucks
00: flickering black screen
01: non-flickering black screen
03:same as 01
0A: same as 00
05, 07, 09: same as 01
 
Why don't you try the low nibble while the high nibble is "correct" (i.e. indicating 4-bit mode)?
 
fuz
I'm doing this right now
 
So, 80, 81, ...
 
fuz
If I use 81, everything is fine
80 is flickering and displays a shifted screen missing the first half or so
the lsb might again select a clock
bit 02 enables hatching mode
 
We also need to find a bit that enables the "dual scan" panel mode. No idea whether it is in this register, though.
 
fuz
11:35 PM
what does "dual scan" mean again?
 
A 640x400 panels that illuminates two lines at the same time, one in the upper half and one in the lower half.
 
fuz
I see
If I set 27 = 81, then black, green, red, brown are rendered as black
blue, cyan, magenta, light grey as white
intensity is ignored
 
The palette setup ignores intensity.
The bright colors have exactly the same palette entries as the dark colors.
 
fuz
I know. I just wanted to be descriptive
 
Hmm, that nearly matches the lowest palette entry bit. With one exception at red.
Let me double-check the palette values I wrote in the answer.
 
fuz
11:41 PM
I don't think the palette values affect this: when I change the palette using palette.exe, nothing on the screen changes
 
The palette values are correct as given. So we just get: anything with blue renders white, anything without blue renders black.
Disabling palette mapping seems not that useful then.
 
fuz
I wonder if this is part of setting up MDA-compatible attribute bytes
but it doesn't really make sense
bit 01 is the underline bit in MDA and I haven't seen anything underlined
 
The product brief claims that palette registers can even be used with RGB output, so they are not just for hatching. But it is likely that hatching is auto-enabled on the panel output if palette mode is enabled.
 
fuz
palette is just for configuring the hatching used
 
palette on monochrome monitor / flat panel configures the hatching. Yamaha claims you can also use the palette on color monitors (to get the "out of 64" and "out of 512" color modes).
 
fuz
11:47 PM
ah, I see
 
Keep in mind that underlining is determined by bits 0 to 2 (mask 07). You need blue enabled, and green and red disabled at the same time to get underlining.
 
fuz
yeah
 
If you didn't have blue characters on the screen while performing all the tests you already did, you could have missed an underline enable bit.
 
fuz
the palette program has characters of all colors on the screen
so it should have been visible
 
On the other hand, typically, underline location is configured by setting the scanline number that the underline should appear in. If no underline is wanted, set underline location to 31 or something like that.
 
fuz
11:54 PM
though maybe they just displayd a full white character
 
That makes the registers 31/32 likely candidates to contain the underlining configuration.
I don't think you ran the palette program while you found out that 20 or the upper four bits of 24 have no effect.
 
fuz
he
indeed
 
And yes, the palette program display character number 219, a full block.
You don't see underlining in it.
 
fuz
yeah
If I do

f b800:0000 4000 40 01
and then set 27 to 81, I get all black @ characters
no underline in sight
 

  last day (1546 days later) »