Project: HDMI/DVI out for STFM
Posted: Sat Nov 25, 2017 9:09 am
Alright, then yes, to make this overscan compatible some additional work is needed. The description below will be valid for "sync clean" demos/games - not all are and it's very difficult to generalize them. Specific testing and analysis might be needed for those.Smonson wrote: ↑Fri Nov 24, 2017 1:22 pm Because the shifter doesn't see vsync and hsync, I don't use them at all. But so far it hasn't been necessary because the leading edge of DE is all you need in order to know when a scanline has begun, and therefore if you know how long each line is, you can add hsync near the end. Same principle for vsync: I detect the first scanline in the frame by a DE-to-DE delay of longer than 2048 32MHz clock cycles.
The description below is the "state machine" I researched (building upon the shoulders of giants) and published on the defunct atari-forum wiki. I've since for my internal use started to write it as pseudo code following Ijor's description of how the GLUE actually works, but haven't published it anywhere yet. The state machine description will be good enough for this description.
Code: Select all
4 IF(71) H = TRUE
24 IF(60) BLANK = FALSE
28 IF(50) BLANK = FALSE
52 IF(60) H = TRUE
54 IF(60) LINE = 508 ELSEIF(50) LINE = 512
56 IF(50) H = TRUE
164 IF(71) H = FALSE
184 IF(71) BLANK = TRUE
372 IF(60) H = FALSE
376 IF(50) H = FALSE
450 IF(!71) BLANK = TRUE
LINE-50 IF(!71) HSYNC = TRUE && H = FALSE
LINE-10 IF(!71) HSYNC = FALSE
Code: Select all
WS1 (DL6): screen DE is FREQ 56, RES 57
WS3 (DL5): screen DE is FREQ 57, RES 58
WS4 (DL4): screen DE is FREQ 58, RES 59
WS2 (DL3): screen DE is FREQ 59, RES 60
There are thus (resulting from the table above) 12 different possible scanline lengths in the ST, resulting from DE being raised/lowered at different "locations" - or not at all (!): 0, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206, 230 (in bytes).
(again, low/medium res, and there are some variants depending on 50/60Hz starting positions which is visibly offset on screen)
I'll think a bit on what might be possible to do here.
Well, the quick solution might be to make a passthrough board to the original STE Shifter, and only route the "ST Shifter" signals to the HDMI-Shifter instead of the original? I haven't looked at possible overlap though, but the STE Shifter does a lot more other things not of interest for this mod.I don't have an STE, but it looks like the shifter is inside a much bigger 84-pin ASIC. Fortunately there's tons of room in the Cyclone-II so reimplementing the whole thing should be possible, so it could become a similar project. I've only used about 1,500 LEs out of 4,600 available, to get this far. And since this is literally the first time I've ever used an FPGA, I assume my verilog code is very inefficiently using the LEs.
/Troed