] Hi!
]
] This message is intended for VDP-aholics and emulator programmers. I am
] examining the V9938 timing details to help Marat improve fMSX. I discovered
] some things about the line interrupt I never heard about before.
Hi Maarten,
One year ago (on 9 dec 1999, subject 'Re: SCREEN7/8 VRAM mapping solved'), I
already sent a message to Marat, on which I copied you and a few others,
which exactly explains the behaviour that you describe in this mail.
To copy and paste from my message, regarding HR, VR, IE1 and FH:
--------- start of quotation
*** About the HR/VR topic: this is how it works according to me:
*** HR:
HR is very straightforward:
-HR=1 during 'display time'
-HR=0 during 'horizontal border, horizontal retrace'
I have put 'display time' and 'horizontal border, horizontal retrace' between
quotes because HR does not only flip between 0 and 1 during the display of
the 192/212 display lines, but also during the vertical border and during the
vertical retrace.
*** VR:
VR is a little bit tricky
-VR always gets set to 0 when the VDP starts with display line 0
-VR gets set to 1 when the VDP reaches display line (192 if LN=0) or (212 if
LN=1)
-The VDP displays contents of VRAM as long as VR=0
As a consequence of this behaviour, it is possible to program the famous
overscan trick, where VRAM contents is shown in the borders:
Generate an interrupt at line 230 (or so) and on this interrupt: set LN=1
Generate an interrupt at line 200 (or so) and on this interrupt: set LN=0
Repeat the above two steps
*** The top/bottom border contents during overscan:
On screen 0:
1) The VDP keeps increasing the name table address pointer during bottom
border, vertical retrace and top border
2) The VDP resets the name table address pointer when the first display line
is reached
On the other screens:
1) The VDP keeps increasing the name table address pointer during the bottom
border
2) The VDP resets the name table address pointer such that the top border
contents connects up with the first display line. E.g., when the top border
is 26 lines high, the VDP will take:
'logical' vram line
TOPB000 256-26
...
TOPB025 256-01
DISPL000 000
...
DISPL211 211
BOTB000 212
...
BOTB024 236
*** About the horizontal interrupt
All relevant definitions on a row:
-FH: Bit 0 of status register 1
-IE1: Bit 4 of mode register 0
-IL: Line number in mode register 19
-DL: The line that the VDP is going to display (corrected for vertical scroll)
-IRQ: Interrupt request line of VDP to Z80
At the *start* of every new line (display, bottom border, part of vertical
display), the VDP does:
-FH = (FH && IE1) || (IL==DL)
After reading of status register 1 by the CPU, the VDP does:
-FH = 0
Furthermore, the following is true all the time:
-IRQ = FH && IE1
The resulting behaviour:
When IE1=0:
-FH will be set as soon as display of line IL starts
-FH will be reset as soon as status register 1 is read
-FH will be reset as soon as the next display line is reached
When IE=1:
-FH and IRQ will be set as soon as display line IL is reached
-FH and IRQ will be reset as soon as status register 1 is read
Another subtile result:
If, while FH and IRQ are set, IE1 gets reset, the next happens:
-IRQ is reset immediately (since IRQ is always FH && IE1)
-FH will be reset as soon as display of the next line starts (unless the next
line is line IL)
*** About the vertical interrupt:
Another relevant definition:
-FV: Bit 7 of status register 0
-IE0: Bit 5 of mode register 1
I only know for sure the behaviour when IE0=1:
-FV and IRQ will be set as soon as VR changes from 0 to 1
-FV and IRQ will be reset as soon as status register 0 is read
A consequence is that NO vertical interrupts will be generated during the
overscan trick, described in the VR section above.
I do not know the behaviour of FV when IE0=0. That is the part that I still
have to test.
--------- end of quotation
Kind regards,
Alex Wulms
--
Visit The MSX Plaza (http://www.inter.nl.net/users/A.P.Wulms) for info on
XelaSoft, Merlasoft, Quadrivium, SD-Snatcher on fMSX, the MSX Hardware list,
XSA Disk images, documentation, Japanese MSX news from Ikeda and lots more.
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
