Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Sun Jan 07, 2018 11:51 am Yeah you should display black when mono is set on an otherwise color line, and you can ignore what happens after the stabilizer has run. Actually, in detail, the stabilizer skips BLANK start and the line is then displayed for a few more pixels until HSYNC kicks in which again means nothing should be displayed from there until BLANK is deasserted on the next line ;)

(The stabilizer is not used to "open" the right border - that's done via a 60/50Hz switch at cycle 376 and is not visible to the Shifter at all)
Wow, that's quite surprising actually. So, let me get this straight, if it wasn't for the stabiliser then the total number of LOADs on the line wouldn't be a multiple of 4, and I guess the length added by the stabiliser is the shortest available one that satisfies that requirement?

It also switches to 71Hz near the beginning of the line, presumably for the same reason, but since there are no LOADs in the shifter already, it displays black by default.

It's really useful that you told me that the switch happens exactly at cycle 444, because I've been guessing where to align the physical screen with the Atari's scanline cycle number. Now I can get it exact :D
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed »

Smonson wrote: Mon Jan 08, 2018 9:45 am Wow, that's quite surprising actually. So, let me get this straight, if it wasn't for the stabiliser then the total number of LOADs on the line wouldn't be a multiple of 4, and I guess the length added by the stabiliser is the shortest available one that satisfies that requirement?

It also switches to 71Hz near the beginning of the line, presumably for the same reason, but since there are no LOADs in the shifter already, it displays black by default.

It's really useful that you told me that the switch happens exactly at cycle 444, because I've been guessing where to align the physical screen with the Atari's scanline cycle number. Now I can get it exact :D
The "stabilizer" clears the extra words that would otherwise be left in the Shifter for next scanline, yes.

At the beginning of the scanline the switch to HI is done to make the GLUE start the line earlier than it would've otherwise :) That's how you "open" the left border.

For more information on the exact cycles, please see my "state machine" for the GLUE (ST, STE is slightly different):

Color:

Code: Select all

4    IF(71) H = TRUE
24    IF(60) BLANK = FALSE
28    IF(50) BLANK = FALSE
52    IF(60) H = TRUE
54    LINE = 508/512(/224)
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
Mono:

Code: Select all

4:        IF(71) H = TRUE
164:    IF(71) H = FALSE
184:    IF(71) BLANK = TRUE
188:    IF(71) HSYNC = TRUE
212:    IF(71) HSYNC = FALSE
In reality this is not how it's implemented in GLUE, but it's a simpler explanation on how to get to the accurate cycles. H is combined with V (separate vertical state machine) to form DE.

So, for the left border, even if the decision to start the line is taken at cycle 4, BLANK is still active and thus no graphics is displayed until cycle 24 or 28 depending on frequency.

Also, for the stabilizer, as you can see by going to 71 at cycle 444 and back at 456 it means the IF(!71) BLANK = TRUE doesn't happen. Additional pixels will thus be displayed until 512-50=462 (for a 50Hz line) when HSYNC kicks in which will enable BLANK and nothing should be displayed for the rest of the line.

I have much more on this written up on the Atari-Wiki but it's currently down and the only way to read it is through "view source" on the wiki pages ... http://www.atari-wiki.com/index.php?tit ... ction=edit
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Mon Jan 08, 2018 11:14 am The "stabilizer" clears the extra words that would otherwise be left in the Shifter for next scanline, yes.

At the beginning of the scanline the switch to HI is done to make the GLUE start the line earlier than it would've otherwise :) That's how you "open" the left border.

For more information on the exact cycles, please see my "state machine" for the GLUE (ST, STE is slightly different):
Thanks for that, you told me before about this info and I did check it, but I'm measuring the frame timing from VSYNC now, and I couldn't see precisely when that's generated from those tables.
I have much more on this written up on the Atari-Wiki but it's currently down and the only way to read it is through "view source" on the wiki pages ... http://www.atari-wiki.com/index.php?tit ... ction=edit
Maybe we need to move on from that wiki, it's been down for years. I've found quite a few text files and useful posts here and there, but when you need to know something it'd be good if there was a single location to check, rather than hundreds of pages of old forum posts. I often miss stuff while searching.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed »

Smonson wrote: Thu Jan 11, 2018 2:13 am Thanks for that, you told me before about this info and I did check it, but I'm measuring the frame timing from VSYNC now, and I couldn't see precisely when that's generated from those tables.
Yes I need to package the information better.

This is the vertical state machine. All these checks are at CPU/GLUE line cycle 502 (wakestate dependent):

Code: Select all

16: 60Hz BLANK = false; 
25: 50Hz BLANK = false;
34: !50Hz V = true (60Hz and mono screen start)
47/63: 50Hz V = true (short/regular top border GLUE)
234: 60Hz V = false
247/263: 50Hz V = false
260: 60Hz VSYNC = true
258: 60Hz BLANK = true
308: 50Hz BLANK = true
311: 50Hz VSYNC = true (happens at around cycle 30 or so, so very early)
434: 71Hz V = false;
500: mono VSYNC (not sure I verified this, calculated from VSYNC length being one scanline and total # of scanlines is 501)
The line where VSYNC happens is counted down to from when the frequency of the next frame was selected within VSYNC for the current. So a vsync cannot be "skipped" by changing frequency/resolution.

I uploaded a new LA trace for full frames at 32MHz resolution to A-F. You should be able to get most timings you need from that - just let me know what else you need :)
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

No *new* news, but just so you know I'm still alive, I've done a new run of prototype boards with a connection for vsync, and that's working fine.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: Project: HDMI/DVI out for STFM

Post by rpineau »

Thanks for the update :)
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
rubber_jonnie
Site Admin
Site Admin
Posts: 10389
Joined: Thu Aug 17, 2017 7:40 pm
Location: Essex
Contact:

Re: Project: HDMI/DVI out for STFM

Post by rubber_jonnie »

Nice Job :)
Collector of many retro things!
800XL and 65XE both with Ultimate1MB,VBXL/XE & PokeyMax, SIDE3, SDrive Max, 2x 1010 cassette, 2x 1050 one with Happy mod, 3x 2600 Jr, 7800 and Lynx II
Approx 20 STs, including a 520 STM, 520 STFMs, 3x Mega ST, MSTE & 2x 32 Mhz boosted STEs
Plus the rest, totalling around 50 machines including a QL, 3x BBC Model B, Electron, Spectrums, ZX81 etc...
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

I'm not quite done with the unavoidable side-project that is keeping me from working on this (80% through it), but I had enough time recently to add static electricity protection for the DVI socket and get a run of prototypes made. Just tested that new board tonight and it works fine.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

New things today and yesterday:
  • Added ESD protection to the DVI port
  • Added connections for switches/jumpers to the PCB
  • Added selectable aspect ratio (switch 1) - toggles between 640x400 and 720x400 with 40-pixel left/right borders (for widescreen TV)
  • Added selectable borders on/off (switch 2) - changes to resolution 720x480 with 40-pixel border on all sides, or 800x480 with 80-pixel border on left/right and 40px on top/bottom (depending on aspect ratio setting)
Most things work including Spectrum 512 (except for some odd black pixels in the 512-colour palette) and most overscan/palette tricks, like in menu disks.

One thing that's bugging me is that the position of the screen randomly moves left or right by a couple of pixels between power-cycles. I suspect this is the "wake-up states" everyone's always talking about. Reset doesn't affect it. It's annoying because it makes it harder to implement the fullscreen no-borders mode at 640x400. I'm gonna have to make something that detects where the edge of the screen is and adjusts the position - but it won't work if there's some overscan on the left.
User avatar
exxos
Site Admin
Site Admin
Posts: 23437
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post by exxos »

Great stuff! :cheers:

If the pixel shift only happens between power ups, does it matter really ? I think most would opt to put up with it rather than lose the left border totally.

There is still the option to tap into Vsync and Hsync on the system, if that would help ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Post Reply

Return to “FPGA DEVELOPMENT”