The SECRET VIDEO MODE in an ST: 400 lines in COLOR (and with 72 Hz)!

[czietz]

I guess I found something interesting:

You can switch an ST to a "hidden" video mode where you get 400 lines in color instead of the usual 200 lines. Differing from previous attempts of achieving new resolutions, this neither needs hardware modifications, nor is there any sort of interleaving involved. The new mode has a vertical refresh rate of 71-72 Hz (like the monochrome mode) and will thus display on mostly any VGA monitor; you just need a regular ST-RGB->VGA cable.

Now, I'm no graphics artist to introduce this mode with a beautiful picture, but you'll find my test picture at https://www.chzsoft.de/storage/400-lines-in-color.jpg. If you look closely, you can see that each block consists of 16 lines (either 8 red and 8 green or 8 blue and 8 yellow). There are 25 blocks. If you do the math, you can easily see that I indeed have managed to display 400 lines:



PS: The horizontal resolution gets halved, though. Thus, you can have 320x400 with 4 colors or 160x400 with 16 colors.

[Frank B]

Certainly is. Do you have more details?

[shoggoth]

This is pretty cool. How do you enable these modes?

[troed]

This is fantastic. I've spent a lot of hours trying to achieve something like this. How are you running GLUE in one mode (high) and Shifter in another (color)?

[mrbombermillzy]

Wow. If this is running at 71/2Hz, theres possibly an option for some temporal colour mixing too. Please, tell us more!

[ijor]

This is fantastic. I've spent a lot of hours trying to achieve something like this. How are you running GLUE in one mode (high) and Shifter in another (color)?

As many brilliant ideas, it is almost obvious and trivial once you have been told. I have been told already, but I'll let Chrisitian reveal the secret

Btw, more than for actual display, I thought it could be useful for extra overscan/scroll switches that otherwise put SHIFTER in an unstable mode.

[dsp56001]

Maybe a bset.b #1,$ffff8260.w could help ?

[czietz]

This is fantastic. I've spent a lot of hours trying to achieve something like this. How are you running GLUE in one mode (high) and Shifter in another (color)?

I can indeed have Glue and Shifter in permanent disagreement about what the video mode is. The key to this is that Shifter doesn't have a any notion about /UDS and /LDS. If I byte-write to $FF8261, the 68000 CPU will helpfully but the byte on both D15-D8 and D7-D0 and Shifter will update its mode register. Glue however will notice that I didn't access $FF8260 and will not update its copy of the mode register.

So, all my program does is...

Code: Select all

MOVE.B #2, $FF8260		' Switch both GLUE and Shifter to mono
MOVE.B #0, $FF8261		' Switch Shifer back to low-res

As ijor mentioned, this is so trivial I couldn't believe someone hasn't found this before.

The only drawback is that you have to keep TOS from detecting that no monochrome monitor is connected and subsequently resetting the computer. For my test, I chose the somewhat brute-force method of redirecting the VBL/VSYNC interrupt which is where TOS does this check.

It also works the other way around, you can have Glue with color timing but Shifter outputting monochrome pixels. That would get you a resolution of 1280x200 monochrome in either 50 or 60 Hz. However it'll probably hard to find a suitable monitor for that.

I have successfully tested this on both my STF (Ricoh and IMP chipset). Right now, it doesn't work properly on my STE, even though I think it should. Maybe I have to time these writes differently on the STE?

[npomarede]

This is great !
Guess I will have to add this to Hatari, but this will require a few changes as video conversion routines don't expect this mix

[Cyprian]

This is fantastic. I've spent a lot of hours trying to achieve something like this. How are you running GLUE in one mode (high) and Shifter in another (color)?

I can indeed have Glue and Shifter in permanent disagreement about what the video mode is. The key to this is that Shifter doesn't have a any notion about /UDS and /LDS. If I byte-write to $FF8261, the 68000 CPU will helpfully but the byte on both D15-D8 and D7-D0 and Shifter will update its mode register. Glue however will notice that I didn't access $FF8260 and will not update its copy of the mode register.

So, all my program does is...

Code: Select all

MOVE.B #2, $FF8260		' Switch both GLUE and Shifter to mono
MOVE.B #0, $FF8261		' Switch Shifer back to low-res

nice finding

It also works the other way around, you can have Glue with color timing but Shifter outputting monochrome pixels. That would get you a resolution of 1280x200 monochrome in either 50 or 60 Hz. However it'll probably hard to find a suitable monitor for that.

lets add interlace and we could have GEM in 1280x400

go further
in additional lets open bottom border

[Moulinaie]

I have successfully tested this on both my STF (Ricoh and IMP chipset). Right now, it doesn't work properly on my STE, even though I think it should. Maybe I have to time these writes differently on the STE?

Nice if you find the tip for the STE.

Do you think that something equivalent works with the TT ?

Guillaume.

[troed]

The only drawback is that you have to keep TOS from detecting that no monochrome monitor is connected and subsequently resetting the computer. For my test, I chose the somewhat brute-force method of redirecting the VBL/VSYNC interrupt which is where TOS does this check.

That vector is $46E - just point it to an RTS.

I agree it's quite obvious once you explained it - and now I predict a lot of interesting new demo effects to come from this! As long as GLUE is in color then monitors will accept the signal, and the Shifter manically outputting lots of pixels will just make for some really nice dithering one bitplane possibilities.

[troed]

Btw, more than for actual display, I thought it could be useful for extra overscan/scroll switches that otherwise put SHIFTER in an unstable mode.

Doing hi/lo GLUE tricks without the Shifter picking up on them. Would've been nice if the byte trick was the other way around, but I agree it's worth looking into in more detail

[ube]

Great! Now I have to update the firmware in the ubeswitch to take this mode into account.

[Smonson]

Hmm, there's a very interesting side-effect of this.

On an ST boosted to 16MHz which has a custom shifter, as in the case of my HDMI mod, it means you could do a 320x200x256 video mode relatively easily.

[Smonson]

I think I spoke too soon... I just realised the colour depth is only 2 bits in this mode and not 4.

[tin]

Great findings! I’m also having a very keen interrest seeing this discoveries impact on sync switches.

[dhedberg]

Very neat trick indeed! Looking forward to some new demos utilizing this on the ST as well!

[BenOVR]

Awesome

[evil]

Nice research czietz!

The good news is that it works on my STfm:
http://ae.dhs.nu/pics/160x400.jpg

The bad news is that it doesn't work on STe (two tested). The output is black. Even if the mainloop goes haywire and add.w $0123,$ffff8240.w in a loop there is nothing on screen. The OSSC reports 35.8 kHz / 71.47 Hz refresh rates.

Perhaps I'm doing something wrong here, but as it works on the ST, it seems not.

Test source (and binary with cute cat):
http://files.dhs.nu/files_util/160x400.zip

[alien]

Random crazy thought: if one had a monitor which supported a 30Hz refresh rate... one could perhaps do this switch at some point when the screen in low/midrez ends, delay vsync and get a 16 colour 500 and some line screen. Good for displaying static pictures...

The fact one would only turn off output to the colour pins for a few cycles should possibly make the resolution switch easier to hide.

[czietz]

The bad news is that it doesn't work on STe (two tested). The output is black. Even if the mainloop goes haywire and add.w $0123,$ffff8240.w in a loop there is nothing on screen. The OSSC reports 35.8 kHz / 71.47 Hz refresh rates.

Yes, this is what I observe on my STE as well. Coming from mono mode, when I write 0 to $FF8261, the Shifter switches off its mono output but it doesn't output anything on its RGB outputs, either. I've made it work the other way around, though: Coming from color mode, when I write 2 to $FF8261, the Shifter will start outputting on its mono output while the timing (generated by GSTMCU) stays at 50/60 Hz.
So, the question is: are there any prerequisites (timing?) to switch the STE Shifter into color mode?

[BlankVector]

czietz, you are a genius
It is incredible that no one has found that for 33 years...
This opens the door to a whole new generation of demo effects. I'm sure amazing new prods will appear shortly.

Am I wrong, or I am the one who recently put you on that way by pointing you to the hidden 334x200 mode on STe
http://www.atari-forum.com/viewtopic.php?f=1&t=23461

[evil]

The bad news is that it doesn't work on STe (two tested). The output is black. Even if the mainloop goes haywire and add.w $0123,$ffff8240.w in a loop there is nothing on screen. The OSSC reports 35.8 kHz / 71.47 Hz refresh rates.

Yes, this is what I observe on my STE as well. Coming from mono mode, when I write 0 to $FF8261, the Shifter switches off its mono output but it doesn't output anything on its RGB outputs, either. I've made it work the other way around, though: Coming from color mode, when I write 2 to $FF8261, the Shifter will start outputting on its mono output while the timing (generated by GSTMCU) stays at 50/60 Hz.
So, the question is: are there any prerequisites (timing?) to switch the STE Shifter into color mode?

More observations on STe:

1. Booting in colour mode, set 60=2, 61=0: No image, no background colour
2. Booting in colour mode, set 60=2 (don't set 61): No image, no background colour
3. Booting in mono mode, set 60=2, 61=0: No image, no background colour
4. Booting in mono mode, set 60=2 (don't set 61): Monochrome image

The STe have a VGA-adapter that can be switched between colour and mono then sent to OSSC on to a HDMI-screen. The OSSC nicely display the ST output frequencies and that matches what can be expected.

The unexpected thing is that test 3 does seem to switch over to colour, I would have expected it to display a monochrome image.

[czietz]

Am I wrong, or I am the one who recently put you on that way by pointing you to the hidden 334x200 mode on STe
http://www.atari-forum.com/viewtopic.php?f=1&t=23461

You're right. After reading Steven Seagal's explanation of that 334x200 resolution, I confirmed what he wrote by looking at the GSTMCU's internal schematic that I have. Then I thought: What other registers might be affected by this? And I came up with the mode register.