SpritesMind.Net

in theory, yes
but nothing's better than real tests

Eke wrote:1/ right border + right blank is still 23 pixels count: however, this is meant to be 15 +8 pixels, not 14 +9 pixels as you measured...

That documentation is probably highly accurate for 32 cell mode, there does appear to be some very minor difference in 40 cell mode.

Of course there may be a difference between when these events happen and when they show up in the VDP status register...

Eke wrote:4/ measure IPL1/IPL2 when both Hint and Vint are set on line 224

I assume this is because of the mention of the hardware problem in the manual? It's not really described very well.

They work exactly as you'd expect, with the timings Jorge has already shown.

The only time you'll get a problem (and, this is highly unlikely) is if a very long 68K instruction just happens to start immediately before the HINT is sent to the 68K. The 68K won't respond to the HINT until the beginning of the next instruction, by which time the IPL lines have been changed to reflect a VINT instead. IIRC, the system will cancel the HINT but the CPU will take the VINT vector, and on return from the VINT code it will take the VINT again. It's probably not going to look much different on a scope because the correct lines are still triggered at the correct time.

Bump


While the DRAM cart still has programming errors, I can now run custom code on the console, I have set up an UV eprom on a breadboard connected to the cartridge port. (It's 512kByte too)

There are 78 EDclk cycles (All Mclk/4) from H-int falling edge to sync pulse falling edge

(Picture comming later)
EDIT: Here it comes:


This is Horizontal interrupt with a VDP setting of #$E0 (MOVE.w #$8AE0, $C00004)

The second blue pulse is the vertical interrupt.



At last! I could make the VDP output this one in here (the PIXEL CLOCK ), whew!

Both are in "H40" mode.

Thank you for all this info Jorge.

When you say :

Line 31 (in NTSC) is the first VDP-drawn line.

Does it means that V-Counter not = 0 when the first line is drawed?

I don't know about V-counter... I need to code that in the H-int to store it's value on line 31.

And I don't really understand the H-int register... Is it to select a line where the interrupt happens or is it to generate interrupts every X lines?

The H-Int register is decremented every line.
When his valor is < 0, an interrupt is generated.
So if you put 0 in H-Int Counter, you have an interrupt evry line, with 1 every 2 lines ...

thanks for that

so Hint on line 224 occurs exactly 788 Mcycles before Vint, this is indeed approx. 14.7 us

and Hint occurs exactly 16 pixels (2 cells) ie 128 Mcycles before the start of the right border...

Jorge Nuno wrote: And I don't really understand the H-int register... Is it to select a line where the interrupt happens or is it to generate interrupts every X lines?

it lets you configure the line interval between interrupts
0 means interrupt occurs every line
1 mean sinterrupt occurs every two lines
etc

if you consider H-interrupt is occurring at the end of a line, it can occur on every line from the line that precedes line 0 (line 261 in NTSC mode) to the last line of display (line 223 generally)

PAL V28, H40


Blue is EDclk;
Yellow is Csync;
Purple is YS;
Green is IPL2 (asserted for H & V Ints);

PAL mode has 314 lines:






Here is where the VDP draws stuff, other than the border color:





And here it ends:





Hint on line 128 (I need to re-check this one) : (osc line #182)




From Hint asserted to right border color it's 24EDclk cycles (All Mclk/4)



This is Vint:





The left color border (26EDclks (all Mclks/4)):





The right color border (28EDclks (all Mclks/4)):





Right Blanking (18EDclks):




Additional measures and summary and lulz (assuming you can read my handwrite )


(BTW A.Mclk/4 means: All Mclks/4)


Seems to be the same as NTSC, with the exception of the # of lines/ vertical period

There! Anything I forgot about PAL V28/H40?

Remaining:
V30 H40 PAL
V30 H40 NTSC (even without Vsync, there is IPL, I think)

V30 H32 PAL
V30 H32 NTSC
^^are theese possible?

V28 H32 PAL
V28 H32 NTSC

thanks again , this is very interesting

PAL mode has 314 lines:

are you sure about that ? Could it be the oscilloscope is counting the first one or the last one twice ? This seems indeed weird as most documentations tell there are 313 lines in PAL mode, which is also more logical since PAL standard is 625 lines (312.5 *2) ...

From Hint asserted to right border color it's 24EDclk cycles (All Mclk/4)

this seems different from NTSC... you measured 32 EDCLK ?

V30 H40 NTSC (even without Vsync, there is IPL, I think)

V30 H32 PAL
V30 H32 NTSC
^^are theese possible?

V30 NTSC modes have "out of bound" vertical timing, you will get a rolling screen but it could be interesting to measure the timings and understand what exactly is off-limit.

Eke wrote:thanks again , this is very interesting

PAL mode has 314 lines:

are you sure about that ? Could it be the oscilloscope is counting the first one or the last one twice ? This seems indeed weird as most documentations tell there are 313 lines in PAL mode, which is also more logical since PAL standard is 625 lines (312.5 *2) ...

Not sure, but probably not, becuase the osc can trigger on any line (other than 1 or > 314)

Eke wrote:

From Hint asserted to right border color it's 24EDclk cycles (All Mclk/4)

this seems different from NTSC... you measured 32 EDCLK ?

I'll re-check this one, against Hsync pulses (I could be tricked by YS being triggered before the border)

Eke wrote:

V30 H40 NTSC (even without Vsync, there is IPL, I think)

V30 H32 PAL
V30 H32 NTSC
^^are theese possible?

V30 NTSC modes have "out of bound" vertical timing, you will get a rolling screen but it could be interesting to measure the timings and understand what exactly is off-limit.

Vertical sync is never pulled low with V30+NTSC.

what's the interrupt interval in V30+NTSC ? I know ints happen, for example, when you start Ristar in 50Hz, it will set up 240line res, now when you set the system to 60Hz you get rolling image, and about ~2x slower music. The game has its sound VBL timed on Z80.

Jorge Nuno wrote:

Eke wrote:

From Hint asserted to right border color it's 24EDclk cycles (All Mclk/4)

this seems different from NTSC... you measured 32 EDCLK ?

I'll re-check this one, against Hsync pulses (I could be tricked by YS being triggered before the border)

Indeed it's 32 EDclks. blame YS

32Edclks from IPL2 \__ to YS \__
28Edclks from YS \__ to YS /--- (before Hsync pulse)
18Edclks from YS /--- to Hsync \___

Sum of IPL \__ to Hsync \__ is 78 Edclk cycles (All Mclk/4)

\__ means falling edge;
/--- means rising edge.

TmEE co.(TM) wrote:what's the interrupt interval in V30+NTSC ? I know ints happen, for example, when you start Ristar in 50Hz, it will set up 240line res, now when you set the system to 60Hz you get rolling image, and about ~2x slower music. The game has its sound VBL timed on Z80.

In V30 NTSC:
IPL2 has a frequency of 30Hz, and there are no half-lines, neither vsync, neither vblank (pic later)
EDIT here V28:


And here V30:


I couldn't check if Vint is in the same line, or if it is 8 lines down (probably the latter), I hadn't other reference to compare.

____
The pixel clock seems to be unrelated to EDclk. In H32 mode Edclk still has the frequency change in the Hsync pulses, but the pixel clock didn't seem to change on Hsync pulses... (Or I set the wrong bit, forcing Hsync to 1 always)

____

What's the next thing on top of the testing cue?

What's the next thing on top of the testing cue?

well, this is very complete already...

here's what I have in mind:


. testing how IPL lines behave when interrupts are masked on 68k side... i'm curious to know if both interrupts are made pending forever by the VDP or if they are automatically cleared at some place (beginning of a new frame for example). Measuring INTACK signal for this one could eventually be useful to see if there is any activity on that line even when 68k does not acknowledge interrupts...

. measuring VCLK and ZCLK output by the VDP to see how they are synchronized with the other clocks (MCLK, EDCLK.. and eventually the pixel clock) an dwith the video signals (YS,VSYNC,HSYNC)

. determining what's the role of /MRE0 input signal

. measuring VRAM bus activity to determine read cycles timings during active display (is that even possible to access those signals ?) without any CPU access

. measuring the output level of R,G,B signals for each color


some of those are a little bit crazy I admit

Eke wrote:

What's the next thing on top of the testing cue?

well, this is very complete already...

here's what I have in mind:


. testing how IPL lines behave when interrupts are masked on 68k side... i'm curious to know if both interrupts are made pending forever by the VDP or if they are automatically cleared at some place (beginning of a new frame for example). Measuring INTACK signal for this one could eventually be useful to see if there is any activity on that line even when 68k does not acknowledge interrupts...

Seems easy, I just need to STOP #$2700

Eke wrote: . measuring VCLK and ZCLK output by the VDP to see how they are synchronized with the other clocks (MCLK, EDCLK.. and eventually the pixel clock) an dwith the video signals (YS,VSYNC,HSYNC)

V and Z are probably out-of-sync with the others because of the /7 dividing (easy)

Eke wrote: . determining what's the role of /MRE0 input signal

I never saw this one going low by the MD, but I can force it myself (med-hard). What else should I look into, to check for potencial changes?

Eke wrote: . measuring VRAM bus activity to determine read cycles timings during active display (is that even possible to access those signals ?) without any CPU access

Insane, but possible.

Eke wrote: . measuring the output level of R,G,B signals for each color

Buffered through the video encoder chip or the RAW VDP output?

Eke wrote: some of those are a little bit crazy I admit

Yup.