Jo Engine: JO_480p Makefile Option

[fafling]

480p is certainly there for compatibility with 31 khz arcade machine monitors. Maybe they planned to hook an STV board to such a monitor. Or it could have been used for a special monitor such as the Hi Saturn Navi LCD screen.

Anyway, to answer part of the original question and address issues with @stevekwok 's list, high res does not decrease VDP2 framerate, and neither does interlacing, except in single interlaced mode (and I'm not even sure that the console actually enforces that). Virtua Fighter 2, a high res double interlaced game, does run at 60 fps, not 15 !

The high res mode always has 60 fields per second which can display 60 different frames in progressive and double interlaced mode. VDP2 manual is incorrect about the latter in p. 14, and it seems SGL enforces a 30 fps framerate in double interlaced based on that inaccuracy (also reported by @Ponut and written in the SGL reference for slInitSystem). Since Jo Engine is using SGL, it inherits of that software limitation.

 

[stevekwok]

480p is certainly there for compatibility with 31 khz arcade machine monitors. Maybe they planned to hook an STV board to such a monitor. Or it could have been used for a special monitor such as the Hi Saturn Navi LCD screen.

Anyway, to answer part of the original question and address issues with @stevekwok 's list, high res does not decrease VDP2 framerate, and neither does interlacing, except in single interlaced mode (and I'm not even sure that the console actually enforces that). Virtua Fighter 2, a high res double interlaced game, does run at 60 fps, not 15 !

The high res mode always has 60 fields per second which can display 60 different frames in progressive and double interlaced mode. VDP2 manual is incorrect about the latter in p. 14, and it seems SGL enforces a 30 fps framerate in double interlaced based on that inaccuracy (also reported by @Ponut and written in the SGL reference for slInitSystem). Since Jo Engine is using SGL, it inherits of that software limitation.

1. If VDP2 dot clock was doubled or quadrupled, whether the CPU clock is also doubled or quadrupled?
2. If CPU clock cannot be doubled or quadrupled, then what are the layout of cycle patterns?
3. If VDP2 dot clock can be doubled or quadrupled, why bother to use interlace modes?

 

[rorirub]

Thanks for the info. There has to be some configuration where 480p works connected to a TV via SCART right? Or why include it. I have a hunch the VGA modes might be more compatible on modern displays.

There isn't any combination, SCART does not carry more than 480i. I mean it technically can but it's simply not a standard, unlike for example Component cables which can do 480p or even 720p - if the set supports it. You'd need special cables with extra hardware in them to allow games to support optional 480p. But in that resolution you essentially limit yourself to 1/3rd of the capabilities of the VDP2 and I don't even know how badly the VDP1 gets gimped. It's not like the Dreamcast where you can just make the game optionally work in 480p, it would require a total rewrite of anything bare the most basic puzzle game.

I'm not sure how VGA compatible either modes are, but a 31KHz CRT can display them fine (you'll need to use RGBHV signal).

As for why include it? Because this is Sega. May as well ask why make a lightpen based picture editor out of the 32x, or an internet powered karaoke amplifier out of the Saturn....

 

[slinga]

@rorirub: HD RetroVision makes a set of component cables for the Saturn: Other Consoles — HD Retrovision. Do you think it would be possible to achieve 480p via that cable on a modern television? They appear to be sold out otherwise I would order a set and test it out.

I just think it would be interesting to make a 480p demo. I'm not trying to upscale existing games.

 

[fafling]

@rorirub In 480p, VDP1 uses a 16 bpp framebuffer, so it's 320/352 x 240, automatically upscaled to match the display resolution (p. 14 and 37 of VDP1 manual).

 

[Ponut]

30dps, 30fps, 25dps(P), 25fps(P), N
Hi-Res Graphic A: 2
640x224, 640x240, 640x256(P)
Hi-Res Graphic B: 3
704x224, 704x240, 704x256(P)

This I'm sure is false. I've run 704x224 in 60 hz in a demo before, on a real system.
And this was by sprite (VDP1) graphics which means that whole chain of command was operating at 60 hz.
It's progressive scan, there is no reason for the sync rate to be reduced.

There is also no doubt that the _hardware_ explicitly allows the even and odd fields to be different command lists in interlaced video modes,
I've seen SGL give incongruent decisions on when to drop the sync from 30 hz to 15 hz as sometimes you see the even scanlines be incomplete.

My main "point" was about how the libraries expose this to you.
Replacing SGL is not trivial, so I am mostly concerned with how it works.
I don't have an extensive knowledge or extensive reading of the manual, especially with how VDP2 works.
But I really really should have remembered that hi-res modes go to 8bpp which makes the framebuffer 1024x256
because I spent a lot of time making sure that worked in 3D (which imo believable 3D necessitates light shading) 🙂

 

[antime]

1. If VDP2 dot clock was doubled or quadrupled, whether the CPU clock is also doubled or quadrupled?
2. If CPU clock cannot be doubled or quadrupled, then what are the layout of cycle patterns?
3. If VDP2 dot clock can be doubled or quadrupled, why bother to use interlace modes?

The pixel clock is generated by VDP2, derived from the same PLL output that feeds the CPU, but there's no other relationship between them. Old SD TVs can't display a progressive image with more lines than lines per field, so interlace modes are required. Also keep in mind that horizontal and vertical resolution are quite independent in the analog TV world.

 

[fafling]

In 352/704 mode, VDP2 frequency is 28 Mhz , it can outputs pixels at multiples of that frequency, which gives the dot clock or pixel clock :

• One pixel every 4 cycles in normal mode => 7 Mhz (453 pixels per raster in NTSC, excess pixels over 352 correspond to the hblank interval)
• One pixel every 2 cycles in high res or exclusive normal modes => 14 Mhz (906 pixels per raster in high res NTSC, excess pixels over 704 correspond to the hblank interval)
• One pixel every cycle in exclusive high res mode => 28 Mhz

Pixels per raster calculation : pixel clock / (framerate x number of rasters)
In normal NTSC : (28600000 / 4) / (60 x 263) = 453

The increase of the pixel clock comes with increasing restrictions on the capabilities of VDP2, including less timings available for vram access. Interlacing doesn't require to increase the pixel clock, thus has no such restrictions.

 

[stevekwok]

Thanks guys 🙂

I made a mistake, the VDP2 dot clock does can be doubled(but cannot be quadrupled), the cycle pattern layout also has some changes in Hi-Res or special monitor modes, since I haven't touched that part for a long time, I've forgotten about this:

T0 to T7 are in effect when the TV screen is in Normal mode, but only T0 to T3 are in effect for the high-resolution
or special monitor mode; T4 to T7 are ignored.

So here is the final version of the list:

dps: fields per second, fps: frames per second, P: PAL, I: Interlaced, N: Non-interlaced,
E: EDTV(31kHz monitor, VGA), H: HDTV(Hi-Vision monitor)
C0: 8-cycle pattern, C1: 4-cycle pattern

60dps, 60fps, 50dps(P), 50fps(P), N, C0:
Normal Graphic A: 0
320x224, 320x240, 320x256(P)
Normal Graphic B: 1
352x224, 352x240, 352x256(P)

60dps, 30fps, 50dps(P), 25fps(P), I, C0:
Normal Graphic A: 0
320x448, 320x480, 320x512(P)
Normal Graphic B: 1
352x448, 352x480, 352x512(P)

60dps, 60fps, 50dps(P), 50fps(P), N, C1:
Hi-Res Graphic A: 2
640x224, 640x240, 640x256(P)
Hi-Res Graphic B: 3
704x224, 704x240, 704x256(P)

60dps, 30fps, 50dps(P), 25fps(P), I, C1:
Hi-Res Graphic A: 2
640x448, 640x480, 640x512(P)
Hi-Res Graphic B: 3
704x448, 704x480, 704x512(P)

60dps, 60fps, N, C1:
Exclusive Normal Graphic A: 4
320x480(E)
Exclusive Normal Graphic B: 5
352x480(H)

60dps, 60fps, N, C1: (Special High-Resolution Graphics Mode)
Exclusive Hi-Res Graphic A: 6
640x480(E)
Exclusive Hi-Res Graphic B: 7
704x480(H)

 

[fafling]

Still incorrect :

• The machine does not restrict the framerate in double interlaced mode, so VDP2 outputs 60 fps, not 30. Again VF2 is a 60 fps game, not 30.
• VDP2 pixel clock must be quadrupled to display high res on a 31 khz monitor at 60 fps. It can be quadrupled since it matches VDP2 frequency. And it is quadrupled, otherwise the crazy restrictions in that mode have no reason to be there.

 

[stevekwok]

• The machine does not restrict the framerate in double interlaced mode, so VDP2 outputs 60 fps, not 30. Again VF2 is a 60 fps game, not 30.

Yes, VF2 is a 60fps game, but here f means field, not frame.

• VDP2 pixel clock must be quadrupled to display high res on a 31 khz monitor at 60 fps. It can be quadrupled since it matches VDP2 frequency. And it is quadrupled, otherwise the crazy restrictions in that mode have no reason to be there.

It's impossible, since there is no 2-cycle pattern at all, 4-cycle pattern is the minimal.

 

[fafling]

Regarding VF2, this is worth a million words :



Like I said, VDP2 pixel clock has to be quadrupled to display high res on a 31 khz monitor at 60 fps, with VDP2 outputting one pixel every cycle to the video encoder. So how can it work while maintaining the cycle pattern to 4 timings, the same as NTSC high res which displays twice as less pixels ?

First, NTSC high res mode shows that, to output one pixel to the video encoder every 2 cycles, VDP2 is actually able to compute 2 RGB pixels every 2 cycles. Those 2 pixels are the first and second image pixels resulting from the priority processing and required for color calculation. With color ram mode set to 0, VDP2 can compute those 2 RGB pixels every 2 cycles with both graphic layers being in palette format.

With that in mind, here's how the constraints of VDP2 in exclusive high res listed p. 13 of the manual make it possible to display a single high res graphic layer at 60 fps, changing the displayed pixel every cycle :

• NBG0 and NBG1 are using the same graphic data.
• Both layers are downscaled by 50% so the graphic has to be in 16 or 256 colors palette format (p. 129 of VDP2 manual), and for both :
  (coordinate increment X) = 2
• NBG1 is offset horizontally by 1 compared to NBG0 so :
  (screen scroll value X NBG1) = (screen scroll value X NBG0) + 1
• H counter is increased by 1 every 2 screen pixels in exclusive high res mode (p. 23 of VDP2 manual), so it's increased by 1 every 2 cycles of VDP2. Which means that for each pair of consecutive even and odd screen pixels :
  (H counter) = (even screen pixel X) / 2
• So every 2 cycles, using a 4 timings cycle pattern, the horizontal coordinates of NBG0 and NBG1 are computed with the formula given p. 126 of VDP2 manual :
  (coordinate increment X) X (H counter value) + (screen scroll value X)
• For NBG0 it gives :
  2 x (even screen pixel X) / 2 + (screen scroll value X NBG0) = (even screen pixel X) + (screen scroll value X NBG0)
• For NBG1 it gives :
  2 x (even screen pixel X) / 2 + (screen scroll value X NBG0) + 1 = (odd screen pixel X) + (screen scroll value X NBG0)
• So the horizontal coordinates of NBG0 and NBG1 are those of 2 consecutive graphic pixels that are to be displayed on a high res screen line for on cycle each.
• NBG0 and NBG1 have the same priority with special priority disabled, so NBG0 is on top and NBG1 is behind (table 11.1 of VDP2 manual). So NBG0 is the first image pixel and NBG1 is the second image pixel.
• As explained before, both pixels can be computed every 2 cycles of VDP2 with color ram 0, which is one of the specs of p. 13.
• At this stage, all VDP2 has to do is cut its processing short before color calculation (which explains why p. 13 says it mustn't be enabled), and send the first image pixel (NBG0) for one cycle to the video encoder, then send the second image pixel (NBG1) on the next cycle.

Note that the 50% downscale constraint means that cycle pattern requirements are doubled for pattern name and character/bitmap patterns. So 256 colors character/bitmap patterns use all 4 timings of a vram half/partition for one NBG. It means that NBG0 and NBG1 can't share the same 256 colors graphic data in vram, it has to be duplicated in a different vram half/partition for each NBG.

 

[stevekwok]

Regarding VF2, this is worth a million words :



Like I said, VDP2 pixel clock has to be quadrupled to display high res on a 31 khz monitor at 60 fps, with VDP2 outputting one pixel every cycle to the video encoder. So how can it work while maintaining the cycle pattern to 4 timings, the same as NTSC high res which displays twice as less pixels ?

First, NTSC high res mode shows that, to output one pixel to the video encoder every 2 cycles, VDP2 is actually able to compute 2 RGB pixels every 2 cycles. Those 2 pixels are the first and second image pixels resulting from the priority processing and required for color calculation. With color ram mode set to 0, VDP2 can compute those 2 RGB pixels every 2 cycles with both graphic layers being in palette format.

With that in mind, here's how the constraints of VDP2 in exclusive high res listed p. 13 of the manual make it possible to display a single high res graphic layer at 60 fps, changing the displayed pixel every cycle :

• NBG0 and NBG1 are using the same graphic data.
• Both layers are downscaled by 50% so the graphic has to be in 16 or 256 colors palette format (p. 129 of VDP2 manual), and for both :
  (coordinate increment X) = 2
• NBG1 is offset horizontally by 1 compared to NBG0 so :
  (screen scroll value X NBG1) = (screen scroll value X NBG0) + 1
• H counter is increased by 1 every 2 screen pixels in exclusive high res mode (p. 23 of VDP2 manual), so it's increased by 1 every 2 cycles of VDP2. Which means that for each pair of consecutive even and odd screen pixels :
  (H counter) = (even screen pixel X) / 2
• So every 2 cycles, using a 4 timings cycle pattern, the horizontal coordinates of NBG0 and NBG1 are computed with the formula given p. 126 of VDP2 manual :
  (coordinate increment X) X (H counter value) + (screen scroll value X)
• For NBG0 it gives :
  2 x (even screen pixel X) / 2 + (screen scroll value X NBG0) = (even screen pixel X) + (screen scroll value X NBG0)
• For NBG1 it gives :
  2 x (even screen pixel X) / 2 + (screen scroll value X NBG0) + 1 = (odd screen pixel X) + (screen scroll value X NBG0)
• So the horizontal coordinates of NBG0 and NBG1 are those of 2 consecutive graphic pixels that are to be displayed on a high res screen line for on cycle each.
• NBG0 and NBG1 have the same priority with special priority disabled, so NBG0 is on top and NBG1 is behind (table 11.1 of VDP2 manual). So NBG0 is the first image pixel and NBG1 is the second image pixel.
• As explained before, both pixels can be computed every 2 cycles of VDP2 with color ram 0, which is one of the specs of p. 13.
• At this stage, all VDP2 has to do is cut its processing short before color calculation (which explains why p. 13 says it mustn't be enabled), and send the first image pixel (NBG0) for one cycle to the video encoder, then send the second image pixel (NBG1) on the next cycle.

Note that the 50% downscale constraint means that cycle pattern requirements are doubled for pattern name and character/bitmap patterns. So 256 colors character/bitmap patterns use all 4 timings of a vram half/partition for one NBG. It means that NBG0 and NBG1 can't share the same 256 colors graphic data in vram, it has to be duplicated in a different vram half/partition for each NBG.

This video explains nothing.
Output: 1080p@60hz? First, Saturn doesn't support 1080p. Second, 60hz means 60 fields per second(30 frames per second), because VF2 runs in Hi-Res interlace mode. Please note, resolution(graphic mode) is decided by software, it has nothing to do with what monitor connected to the console.
Which means even if the game runs with a 31Khz monitor, it's still in Hi-Res interlace mode, rather than progressive mode. If it shows that it runs in progressive mode, it's must been converted by the OSSC, not the original output of the console.

Why it can run at 60fps in 480p in Exclusive Hi-res mode with 4-cycle pattern? Because in Special High Resolution Graphics Mode, NBG0 and NBG1 are interleaved horizontally, VDP2 process one unit(two pixels) per dot cycle. But it outputs one pixel per pixel cycle. Here actually it's just we saw it from different perspectives. The dot clock cannot be quadrupled(since there is no 2-cycle pattern), but the pixel clock can be quadrupled for output in the Exclusive Hi-Res modes.

 

[fafling]

Seriously, LOL.

 

[stevekwok]

Seriously, LOL.

Thanks buddy 🙂
I've never seen a guy who is such serious on tech details.
It's great that we've made everything clear eventually. It's what we discussed for.
I hope that the discussion improve and update our knowledge instead of who wins in the discussion.

 

[slinga]

My HD Retrovision component cables came in today. I tested Component -> OSSC -> HDMI and Component -> direct TV and the results were identical for the 480P resolutions. The EDTV modes appeared to work but the Hi-Vision modes did not. My TV labelled the signal as 720x480p.

320x480 non-interlaced EDTV (VGA), progresive scan. Displays fine.

640x480 non-interlaced EDTV (VGA), progresive scan. Horizontal jail bars in places. When switching to 16:9 mode the image appeared to take up the full screen.

The Hi-Vision modes did not work at all. On the OSSC they did not sync, on my TV they produced a garbage signal.

 

[slinga]

Anyone have a SCART input built directly into their TV? The last test I would like to perform is trying to obtain a 480P signal via a SCART cable plugged directly into a TV. I assume this is safe but I have no idea. Any volunteers?

 

[hitomi2500]

I have a TV with a built-in SCART. Digital one though, it does some kind of an auto-sync magic when i connect an old i8275-based PC, so the test might be not very authentic.

Don't have any Saturn-to-scart cables, but i can probably solder one, or maybe order somewhere. I will check if any of my s-video cables have the corresponding pins (we need RGB and sync, right?).

 

[slinga]

Honestly this is quite out of my area of expertise. I'm using this cable: Sega Saturn RGB SCART NTSC PAL PACKAPUNCH.

 

[hitomi2500]

Ok, i ordered one, hope delivery won't take long.