Re: 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 pmBecause 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.
The cycles above are as seen by the CPU, in low/medium res. Additionally, the ST has four wakestates where changes to the RES and FREQ registers are delayed due to offsets between CPU and GLUE clocks. Example from cycle 56 in the above table for the four wakestates:
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
DE takes immediate effect in the Shifter, but is picked up later by the MMU which then starts LOADing (DCYC) the Shifter after yet another slight delay. I think for your purposes you might be able to skip all the wakestate and delays stuff though.
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.