Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
Post Reply
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 »

Smonson wrote: Mon Nov 27, 2017 12:26 pm OK, it's not just me then :lol:
nope :)

Only other way I could think as if on power up, the blanking pin is active and generating the white screen.. IE DE is not being pulsed at all. Then would need a counter to count up how long the DE pulses have been missing for.. and if missing for "a while" the shifter assumes a "reset".. A kind of "watch dog timer"..

AFAIK there is only the palette register, colour changes AFAIK can't reset anything else full screen demos wouldn't work. Possible resolution changes could trigger a internal reset... but again it also would double up that the shifter doesn't output any data for a while and blanking is active for a few frames...

maybe you could check blanking and DE on power up and see if DE is inactive for a while during power up or resolution change ?
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.
keli
Posts: 97
Joined: Tue Aug 22, 2017 1:34 pm

Re: Project: HDMI/DVI out for STFM

Post by keli »

exxos wrote: Mon Nov 27, 2017 12:43 pm
AFAIK there is only the palette register, colour changes AFAIK can't reset anything else full screen demos wouldn't work. Possible resolution changes could trigger a internal reset... but again it also would double up that the shifter doesn't output any data for a while and blanking is active for a few frames...
I don't think you can reset anything on resolution change. I remember an application that changed between medium and low res on every scan line (GFA Raytracer iirc), showing a work area in spectrum-like 512 color low res and a vertical tool bar in 4 color medium res.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed »

Emulating the Shifter is not _that_ easy. Yes, the Shifter does "reset" in strange and mysterious ways. Ijor is the one that has the best knowledge of this, but it's correct that in many cases words are "left over" in the internal registers and carry over to not just the next scanline but also next frame.

There are threads on A-F with more information, I'll get back to this later when I have a bit more time. Keeping words in the Shifter on purpose is what allows 4 pixel sync scrolling, and I also make use of the behaviour in {Closure} with my stabilizer-less fullscreen scanlines (which is why you see shifted planes if you don't emulate it properly)
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 »

keli wrote: Mon Nov 27, 2017 1:57 pm I don't think you can reset anything on resolution change. I remember an application that changed between medium and low res on every scan line (GFA Raytracer iirc), showing a work area in spectrum-like 512 color low res and a vertical tool bar in 4 color medium res.
I think it would be OK to reset the shifter from one scanline to the next in a normal ST video mode, because each scanline begins on LOAD 0 and with no preexisting data in the shifter's registers. I was clearing its state on the assertion of DE before, just on the assumption that it was sensible to do so, but obviously the real shifter doesn't work like that.
troed wrote: Mon Nov 27, 2017 2:46 pm Emulating the Shifter is not _that_ easy. Yes, the Shifter does "reset" in strange and mysterious ways. Ijor is the one that has the best knowledge of this, but it's correct that in many cases words are "left over" in the internal registers and carry over to not just the next scanline but also next frame.
I've just been staring at the schematic posted by Ijor in the shifter decap thread on atari-forum, it seems... ridiculously overcomplicated would be one way to put it!

I don't understand why they would make the chip with these complex reset mechanisms that they then went on to never use. *shrug*
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 »

Smonson wrote: Tue Nov 28, 2017 1:55 am I think it would be OK to reset the shifter from one scanline to the next in a normal ST video mode, because each scanline begins on LOAD 0 and with no preexisting data in the shifter's registers. I was clearing its state on the assertion of DE before, just on the assumption that it was sensible to do so, but obviously the real shifter doesn't work like that.
Sounds like a good idea to "rest" on VSYNC. I think DE could even be low all the time in terms of overscan stuff. The amount of times DE pulses should be relative to the scan line pixel length (x4 for 4 bit planes). So I think we can rule out DE being used as any sort of "reset" system.

Smonson wrote: Tue Nov 28, 2017 1:55 am I don't understand why they would make the chip with these complex reset mechanisms that they then went on to never use. *shrug*
They wouldn't have done.. Atari I presume would be looking for quick and simple and minimal gates. So thinking towards something gets "reset" obviously isn't right here.

EDIT:

Just thinking out load.. but maybe LOAD isn't clocking the data into the shifter, but just more of a enable signal to latch data. Maybe on power up the shifter resets to count 0 and simply counts up automatically on its own each time and never drifts. The clocks between MMU and Shifter are in sync...

EDIT 2:

DE just sets the shifter to display pixels or not, DE can be tied high all the time, so nothing screws up in that signal.

LOAD must load data into the shift registers.

I assumed LOAD clocks the shifters with data, and its probably correct. Obviously there is something else here. As if we did a resolution change the LOAD cycles would be some "odd" number..and cause bit planes shits... or would they ?

We don't get bit planes shifts in general, so I can only assume the MMU completes all load cycles in any particular resolution. On this basis, we don't need to "reset" the shifter counters at all.

In terms of a system crash, this is mostly CPU.. the MMU is kinda doing its own thing with the video, regardless of what the CPU is doing. So I still think the MMU would complete a even (correct) number of LOAD pulses.

EDIT3:

Looking back at this...
50hz_video clock DE to load to screen latencies.png
50hz_video clock DE to load to screen latencies.png (28.51 KiB) Viewed 5740 times

DE goes HI about 8 clocks before the MMU starts loading DATA.. Maybe a clue...

If the machine powers up and DE is high all the time, then the number of LOAD pulses wouldn't change..

If the machine is running as normal, maybe DE low for more than 4 clocks is what "clocks out" the shifter data and resets the counter... Then LOAD uses to clock the count from 1-4 as normal.

Trying to think how it would work...

I mean is simply DE is LOW and LOAD is HIGH, then use that to reset the 1-4 counter.

Then when DE goes HI, the condition is false, and the counter uses LOAD to count 1-4. This would mean the counter is reset every scan line...

This would mean DE basically becomes the reset signal... I forgot what the question was now ? :lol:
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:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

exxos wrote: Tue Nov 28, 2017 8:59 am So I think we can rule out DE being used as any sort of "reset" system.
I wish it was that simple. I believe DE is an input to the reset mechanism, which I don't fully understand because I don't know what some of the schematic symbols Ijor has used mean.

Sorry I don't have time for a proper reply tonight, I've stayed up way too late again... argh
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 »

Smonson wrote: Tue Nov 28, 2017 12:25 pm I wish it was that simple. I believe DE is an input to the reset mechanism, which I don't fully understand because I don't know what some of the schematic symbols Ijor has used mean.
In my waffle above, I thought DE could actually be the reset signal. I doubt its going to be anything complicated.
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:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

So I finally got an old TV so I can actually use 50Hz programs without moving the entire setup into the middle of my lounge room. And I've made a few small bits of progress here and there.

I have a couple of questions, hoping someone can help me out here:
  1. On a real ST, does Spectrum 512 show a bunch of colours in the screen border area when it's just displaying the image? In Steem SSE, it does if you enable a wake state, but not if you set it to "ignore". I always see colours in the border with my setup.
  2. Can anyone suggest a program that displays a static image that extends into the overscan area? Preferably something that lets you specify which image, a picture viewer for example. With demos, there's usually crap flying everywhere and it's really hard to see what's going on.
The project is basically on hold while I set up a website for my finacee's business, but I can still think about it while I'm in the shower :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: Wed Jan 03, 2018 8:28 am [*]On a real ST, does Spectrum 512 show a bunch of colours in the screen border area when it's just displaying the image? In Steem SSE, it does if you enable a wake state, but not if you set it to "ignore". I always see colours in the border with my setup.
I think testing with Hatari instead of STEem might help here. The current wakestate-code in STEem isn't really emulating the hardware but more of an in-between thing that works with the code that has already been published and tested. I'm quite sure Spectrum 512 has a uniform border color.
Can anyone suggest a program that displays a static image that extends into the overscan area? Preferably something that lets you specify which image, a picture viewer for example. With demos, there's usually crap flying everywhere and it's really hard to see what's going on.
I'm guessing left/right is of most interest? I believe I have some code by Evil/DHS that only displays a fullscreen, made for calculating number of visible lines. Both ST (230 byte) and STE-specific (224 byte) line variants.
Res 416x 240 and similar. It is wakestate sensitive.
I think it's important to separate GLUE-MMU wakestates (WS1-WS4, can be tested in software) and Shifter(-MMU) wakestates (not completely researched, but "Spectrum 512 black pixels" is one. Cannot be detected from software, only visually).

GLUE-MMU wakestates only exist on ST, not STE.
Shifter-MMU wakestates, at least some, exists on both ST and STE.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed »

I asked Evil for the programs - here you go :)

http://ae.dhs.nu/tmp/oversc.zip

/Troed
Post Reply

Return to “FPGA DEVELOPMENT”