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:

Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Wed Nov 01, 2017 9:34 am TOS boot process can be seen in the disassembly in ST Internals, if not in the actual TOS source available. It writes to video mode registers of course, but I'm not sure it reads. Maybe some HBL interrupts etc could be affected.

In any case, booting from a diagnostic cartridge is often a good way to get a clean boot as early as possible with minimized interference from other stuff.
I can see CS pulsing occasionally (about once per frame if I'm remembering right). I don't have a copy of the TOS source to check, in fact I didn't know it existed until now.

I don't have a diagnostic cartridge either, but it was working in mono with the HxC disk selection menu so I should be able to at least get it back to that point, if I haven't introduced any further hardware issues.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

keli wrote: Wed Nov 01, 2017 11:34 am Since you mention 50Hz, I'm assuming you're dealing with PAL frequencies. A PAL frame supposedly consists of 625 scan lines (visible and invisible lines) transmitted as two 50Hz interlaced fields. The Atari image, being progressive basically treats each field as a separate frame, but note how the number of total scan lines is uneven. This means that every other frame would be slightly shorter than the first, if we assume the ST matches the PAL standard exactly. Is that what you are seeing? Are the frames alternatively 312 and 313 lines or is the frame length actually 312.5?
Urgh, if that's the case, then it's a pain in the butt. I thought that the Atari always generated 313-line frames in 50Hz, from what I'd read on forums... I mean, at the worst, it would mean buffering an extra scanline I guess... but the logic to handle that situation would be way more complex. I'll deal with it if it comes up.

The frame lengths I'm seeing differ by a lot more than one line though - so there's definitely a bigger problem here as well. It looks more like a combination of 50Hz, 60Hz, and 70Hz frames so I am really leaning towards reading from the video mode register as being the first problem to solve.
User avatar
exxos
Site Admin
Site Admin
Posts: 23495
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Project: HDMI/DVI out for STFM

Post by exxos »

Smonson wrote: Thu Nov 02, 2017 12:00 am It's so hard to debug things like that when all you have to communicate with the outside world is 3 LEDs.
I "feel" your pain :)
Smonson wrote: Thu Nov 02, 2017 12:00 am I can see CS pulsing occasionally (about once per frame if I'm remembering right). I don't have a copy of the TOS source to check, in fact I didn't know it existed until now.
Is it doing a read or write though ?

Also what happens if you use the RGB drivers on the ST instead of HDMI ?
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.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

exxos wrote: Thu Nov 02, 2017 9:33 am Is it doing a read or write though ?
Both, but I have made an assumption that RW is LOW for a register read - when I should be driving the shifter bus - and HIGH for a write. But I have no real way to confirm.

Another assumption (I seem to be making a lot of these lately) is that the shifter needs to drive it's data bus for the exact duration that CS and RW are asserted together.
exxos wrote: Thu Nov 02, 2017 9:33 am Also what happens if you use the RGB drivers on the ST instead of HDMI ?
Nothing - I have shifter pins 21-29 grounded on my test board, and I can't plug the real shifter back in because I've replaced the IC socket with pin headers.

But with VSYNC all over the place, there's no way it could drive a real monitor anyway. I wish I knew why it was working before! The next thing I'll try is getting rid of the 10K pulldown resistors on the data lines. They weren't on the stripboard version, so... worth a shot.

This has gotta be something specific, because the pattern of frames switching between frequencies seems to be following a pretty specific pattern.
User avatar
exxos
Site Admin
Site Admin
Posts: 23495
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Project: HDMI/DVI out for STFM

Post by exxos »

Smonson wrote: Thu Nov 02, 2017 12:26 pm Both, but I have made an assumption that RW is LOW for a register read - when I should be driving the shifter bus - and HIGH for a write. But I have no real way to confirm.
I would assume it would follow the CPU RW states as the CPU program the registers ?

Smonson wrote: Thu Nov 02, 2017 12:26 pm Another assumption (I seem to be making a lot of these lately) is that the shifter needs to drive it's data bus for the exact duration that CS and RW are asserted together.
Data should be held while CS is active, I would assume data is latched on the edge.
Smonson wrote: Thu Nov 02, 2017 12:26 pm But with VSYNC all over the place, there's no way it could drive a real monitor anyway. I wish I knew why it was working before!
Is VSYNC stable from the GLUE ? Also how you generating a signal for the HDMI port ? I don't know anything about HDMI, but assume it still must still have the VSYNC in there somewhere.
Smonson wrote: Thu Nov 02, 2017 12:26 pm The next thing I'll try is getting rid of the 10K pulldown resistors on the data lines. They weren't on the stripboard version, so... worth a shot.
pullups are normally used, I don't see why you would need pulldown resistors ?
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.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Project: HDMI/DVI out for STFM

Post by rpineau »

RW follow the 68K polarity :
RW high for a read
RW low for a write

And yes you need to drive the bus during the whole time /CS is asserted.

Rodolphe
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

exxos wrote: Thu Nov 02, 2017 1:27 pm
Smonson wrote: Thu Nov 02, 2017 12:26 pm Both, but I have made an assumption that RW is LOW for a register read - when I should be driving the shifter bus - and HIGH for a write. But I have no real way to confirm.
I would assume it would follow the CPU RW states as the CPU program the registers ?
Sorry, I had it around the wrong way. High for a read when the shifter should drive the bus. I've tried both without any difference so far. Next time I'm in front of it I'll compare CPU RW with shifter RW and see if they're the same.
exxos wrote: Thu Nov 02, 2017 1:27 pm
Smonson wrote: Thu Nov 02, 2017 12:26 pm Another assumption (I seem to be making a lot of these lately) is that the shifter needs to drive it's data bus for the exact duration that CS and RW are asserted together.
Data should be held while CS is active, I would assume data is latched on the edge.
That's good, the simpler the better.
exxos wrote: Thu Nov 02, 2017 1:27 pm
Smonson wrote: Thu Nov 02, 2017 12:26 pm But with VSYNC all over the place, there's no way it could drive a real monitor anyway. I wish I knew why it was working before!
Is VSYNC stable from the GLUE ? Also how you generating a signal for the HDMI port ? I don't know anything about HDMI, but assume it still must still have the VSYNC in there somewhere.
Nah, VSYNC from the glue isn't stable... Looking at the frames on the scope, they vary between 50Hz and 71.2. It really looks like the Atari just switches between 50, 60, or 71.2 based on some unknown factor. Within one frame, all the scanlines are the same length, either 40 or 80 LOADs.

The HDMI signal is based on timing generated inside the FPGA. I've ensured that each HDMI frame is the same length as the Atari's frame in terms of the number of 32MHz clocks, so it will remain in synch as long as the Atari frame rate is stable. Although it doesn't start and end simultaneously with the Atari - there will be an offset delay of approximately one scanline.
exxos wrote: Thu Nov 02, 2017 1:27 pm
Smonson wrote: Thu Nov 02, 2017 12:26 pm The next thing I'll try is getting rid of the 10K pulldown resistors on the data lines. They weren't on the stripboard version, so... worth a shot.
pullups are normally used, I don't see why you would need pulldown resistors ?
I added them because of the level shifting buffers - since the data lines are sometimes floating, the pulldowns are there to prevent high-frequency oscillation. Electrical noise was a problem on the stripboard prototype, so I wanted to make sure it also wouldn't be a problem on the new one. However, I don't see noisy signals anymore... the power of a ground plane I guess.

I have series resistors on the bus, so the pulldowns could be pulling down too much. It's on the list of things to try.
User avatar
rpineau
Posts: 534
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Project: HDMI/DVI out for STFM

Post by rpineau »

VSync shouldn't change like that.
Once the video mode is selected it's either a color mode , which depending on the country is 50Hz or 60Hz, with 15.75 kHz Horizontal sync
or it's monochrome and it's 71.2Hz Vertical sync with 35.7 kHz Horizontal sync.
The mode is based on the "mono" pin on the video connector being pulled low when a monochrome monitor is plugged in and goes to I7 (pin 29) on the MFP (which is read by the TOS and if you change when the machine is on, it triggers and interrupt and reboot the machine). This pin has a pull-up with a 1K to vcc.

Data lines (and address lines) should be pulled up on 68K systems, not down.

So I'll say the first step is to fix the pull-down to be pull-up.
Then figure out why Vsync is doing what you see (we're not doubting you when you say it swings between all of this frequencies.. we've seen our share of weird thing on Atari :) ).

Rodolphe
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

rpineau wrote: Fri Nov 03, 2017 1:46 am Data lines (and address lines) should be pulled up on 68K systems, not down.

So I'll say the first step is to fix the pull-down to be pull-up.
I don't think there's any difference in this case, the shifter's bus isn't connected to the 68K. As long as it's not oscillating between two logic states, it shouldn't matter.

I'm happy to get rid of them entirely though, because the ST's ability to read these lines at all is more important than noise. If that noise is really a problem and not just a wrong assumption from me, I can use a weaker pull up or down in the future to try to prevent them drifting around.

As for the video frame parameters constantly changing, I'm working off this hypothesis at the moment:
  • The 68901 interrupts the CPU when the mono-detect line changes; OR the ST reads that bit from the 68901 on bootup
  • Then TOS writes the appropriate video mode value directly into the shifter's video mode register without caching it in a RAM variable
  • Some interrupt handler or handlers reads the shifter's video mode register directly and writes video parameters into the GLU according to what it sees there
It's possible that some hardware issue could also cause it. I may have killed some part of the Atari when constantly unplugging and replugging connectors... I'll get to the bottom of it soon enough.
keli
Posts: 97
Joined: Tue Aug 22, 2017 1:34 pm

Project: HDMI/DVI out for STFM

Post by keli »

Smonson wrote: Fri Nov 03, 2017 6:12 am
  • Then TOS writes the appropriate video mode value directly into the shifter's video mode register without caching it in a RAM variable
The value is in fact cached in RAM at 0x00044C (sshiftmd system variable).
Smonson wrote: Fri Nov 03, 2017 6:12 am
  • Some interrupt handler or handlers reads the shifter's video mode register directly and writes video parameters into the GLU according to what it sees there
The GLUE shadows the low two bits of the video mode register automatically. The OS does not need to update these separately (a shame really, since having them at separate addresses could probably be useful to get exotic graphic modes.)
Post Reply

Return to “FPGA DEVELOPMENT”