Closed yksoft1 closed 6 years ago
It's using the smooth scrolling line register (port 76h). Not yet emulated by Dosbox-x.
To clarify, there is an unimplemented block of I/O ports 70h to 76h that control the text layer.
One of them is explicitly named the "smooth scroll line" register for vertically panning text like that.
The others control line height, etc.
It's interesting to note that unlike VGA, changing the number of scan lines per text row requires programming the same count into the GDC and ports 70-76h even. Strange results happen if you let them get mismatched.
I forgot to link to the document in question!
Normal console register values are:
port 70h: 0x00 port 72h: 0x0F port 74h: 0x10 port 76h: 0x00 port 78h: 0x00 port 7Ah: 0x00
The display behaves as if each character row height is determined by counting from port 70h value to port 72h value.
Port 70h 0x00 and port 72h 0x0F means a 16-pixel high character cell.
If you change port 70h to 0xFF, the console gets somewhat messed up because the text display counts as if 17-pixel high display while the GDC is still counting as if 16 pixels high per character row. You can restore normal display (scrolled down 1 pixel) by setting port 70h to 0xFF and port 72h to 0x0E.
Port 74h seems to control how many lines of the character cell it will display before displaying blank lines.
So this would mean the 20-line mode (with 20-pixel high character cells showing a 16-pixel high character bitmap) is just port 70h set to 0xFE (-2), port 72h set to 0x11, and port 74h set to 0x10 still. 0xFE to 0x11 inclusive is 20 pixels apart.
Port 74h seems to control the number of the character row counter at which the CG blanks the cell. 0x10 doesn't blank anything, while values less than 0x10 blank the CG cell at that line. The blanking is determined by the row within the character cell, not the display.
I just used CTRL+F6 to toggle 20/25-line mode.
Register values in 20-line mode:
port 70h: 0x1E port 72h: 0x11 port 74h: 0x10
So I was right about port 72h. Port 70h seems to indicate that the register is really only 5 bits wide, not 8 bits wide implied by the undocumented PC-98 reference, though that doesn't invalidate the idea of writing 2's complement offset to it. Regardless, my guess was correct.
I will correct this text if port 70h is wider on other hardware.
The default register values in 78h-7ah means that line 0 is always scrolled. Writing port 76h with default values causes the first line to scroll.
Those registers as usual act like they're 5 bits wide.
I suppose port 78h is written in 2's complement form to describe the starting line so that the hardware can just count up until rollover to zero, and then begin the scroll region.
The scroll region doesn't appear to affect the hardware cursor.
TPAINT.EXE in DOSLIB has been updated to permit playing with the 70h-74h registers to help me understand how they work.
Port 74h acts like the character scanline row in the bitmap at which the display blanks the cell. If you set port 74h past 0x10, then the cell will repeat the bitmap until blanking.
The blanking point is based on the count from the value to 0x70 to 0x72, not the scanline row from the beginning of the character row.
Text height/display/vertical position registers 70h-74h even are implemented.
Next I will study the behavior of registers 76h-7ah even to determine exactly how the scroll region works.
All ports 70h to 7Ah even are implemented now, as well as the scrolling text region.
One PC-98 game I test with a scrolling introductory text screen works properly now.
Please try the latest commit.
Please try the latest commit.
Still not working in Legend of Heroes II after " PC-98: Real hardware does not let the scroll region of the text layer… ". although CRTC warnings disappeared.
Try the latest commit again, I found the mistake that prevented it from working.
Try the latest commit again, I found the mistake that prevented it from working.
Scrolling is smooth now, but there are some vertical black lines in CG layer.
Can you provide an animated GIF or video of the closing screen?
I'm guessing from the screenshot the lines follow the text up, then pop back down with more text? If so, the game might rely on something else with the hardware to make the text wrap around, which is not yet emulated by DOSBox-X.
Perhaps display partitions in the GDC's character mode work differently from "graphics or mixed mode". Perhaps they work on a character row basis rather than scanline basis as the graphics GDC apparently does.
Testing on real hardware, no, the display partitions of the text layer (CG) counts in scanlines too. That's not it.
Are there any other games using scrolling in this way?
Hold on a second... the scroll region is implemented by using an entirely different address and row counter from the GDC while in the scroll region, which does not obey the display partitions. That might be the problem.
The first screenshot at the top of this issue shows the "STAFF" text getting cut off as if a display partition is moving upward, so the game is obviously using display partitions. Perhaps the black lines will not show if the display partitions are properly implemented within the scroll region, and will allow the staff roll to appear continuous.
I think the latest commit should resolve the problem with scrolling. Thank you for your patience.
Thank you, this time the staff roll seems flawless. You seemed to fixed a problem that Anex86, T98-Next and Neko II all didn't.
It scrolls like this in DosBox-X with following messages generated.
Neko Project II and Anex86 also had quirks on this (This game had a rather high difficulty level so they probably didn't test playing it to the end), however T98-Next did at least emulated the smooth text scrolling for this game's staff roll.