ST SHIFTER operation ?

General discussions or ideas about hardware.
User avatar
exxos
Site Admin
Posts: 2566
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Thu Oct 26, 2017 12:49 pm

Working it out like this..

(planer)...........(chunky)
Word 1 16px, or 2 pixels
Word 2 16px, or 2 pixels
Word 3 16px, or 2 pixels
Word 4 16px, or 2 pixels.

So same MMU speed could only output 8 pixels per 4 word load.. So double MMU speed would be needed to gain back 16 pixels...

So we could have I think..

320 x 200 x 128 colours with double clocked shifter for chunky mode.

Chunky mode for 640px would need 4 pixels per word, which doesn't fit. We could only use 4 bits per pixel.. So with intensity bit..

RGBi RGBi RGBi RGBi

Basically only 8 colours. Or 16 colours with intensity bit. Though would be limited to basic colour sets.. such as..

(If anyone can do a script to output the colours which would be available then it would help!)

RGB i
000 0 = black
100 0 = medium red.
100 1 - bright red.

Somewhat limited colour palette, but still 16 colours in 640x200 in chunky mode.. as to if that was actually useful mode or not.......

or

640x200 in 16 colours planer mode with double clocked shifter.
320x200 in 256 colours planer mode with double clocked shifter.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

troed
Posts: 224
Joined: Mon Aug 21, 2017 10:27 pm

Re: ST SHIFTER operation ?

Post by troed » Thu Oct 26, 2017 5:13 pm

exxos wrote:
Thu Oct 26, 2017 12:49 pm
640x200 in 16 colours planer mode with double clocked shifter.
320x200 in 256 colours planer mode with double clocked shifter.
Yes, this is what we can get. It's strictly limited by the speed of the MMU, how much data it can send per line. I do believe 256 color chunky is better than 8 bitplanes. In the latter case you would need 256 palette entries in the Shifter, and decode those at some memory address. If chunky you would just hardcode a 256 color selection that is output as decoded by each byte in memory. The MMU will LOAD words but the Shifter can then treat those as two bytes per word internally.

320x200x256 would help a lot with indie game conversions like the ones done by Anima etc. If the mod becomes popular enough so that a lot of people install it ... ;)

User avatar
exxos
Site Admin
Posts: 2566
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Thu Oct 26, 2017 5:44 pm

troed wrote:
Thu Oct 26, 2017 5:13 pm

Yes, this is what we can get. It's strictly limited by the speed of the MMU, how much data it can send per line. I do believe 256 color chunky is better than 8 bitplanes. In the latter case you would need 256 palette entries in the Shifter, and decode those at some memory address. If chunky you would just hardcode a 256 color selection that is output as decoded by each byte in memory. The MMU will LOAD words but the Shifter can then treat those as two bytes per word internally.

320x200x256 would help a lot with indie game conversions like the ones done by Anima etc. If the mod becomes popular enough so that a lot of people install it ... ;)

Yes, I long for the day of a new MMU. If we had one using SRAM we could pretty much clock the thing that really high speeds, the new shifter wouldn't care how fast the data is loaded as it would be asynchronous, so more power to the bandwidth of course more data we can send over to the shifter for whatever purposes.

I could program in a 256 colour palette with eight bit planes, I saw in the Atari memory map there is a place allocated for the TT for such a palette structure. So the address ranges are already in place. Tho wiring up 256 registers, along with decoding 256 addresses for the palette loading is something I would probably not look forward to :lol:

We simply do not have the bandwidth for more than 128 colours in chunky mode.. Like I say my previous post, the colour selection would be a little limited, but should not really be a problem as it is still 128 colours. It would still allow pixel access, worst case you would have to alter two pixels at once and update a whole word, the scrolling stuff about the screen should be a lot faster than accessing four words.. This is more of the programming thing... And with the option of more colours as well would be good I think.. Again are not really familiar with how stuff is shifted around screen, I know about pre-shifting, but this really would not be needed with 128 colour chunky mode, so must save some CPU time or at least ram starters...
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

troed
Posts: 224
Joined: Mon Aug 21, 2017 10:27 pm

Re: ST SHIFTER operation ?

Post by troed » Thu Oct 26, 2017 9:25 pm

Well, the calculations of what can be done are quite simple. It's best to think of them in bandwidth terms:

MMU at 16MHz will latch&LOAD 80 words per scanline, 200 scanlines per VBL in low/medium.

80 words is 1280 individual bits. 200*1280 is the total bandwidth per VBL the MMU can handle.

Now lets see what we can do with that.

* If we want 320 pixels and 200 lines, that gives us 1280/320 = 4 bits per pixel. 4 bitplanes, 16 colors.
* If we want 640 pixels and 200 lines, we have 1280/640 = 2 bits per pixel. 2 bitplanes, 4 colors.
* If we want 640 pixels but double the number of lines to 400, halve the number of words per scanline, the total bandwidth limit means we have to halve the bits once again. 1 bit per pixel, monochrome.

Alright, so, if we double the MMU clock, 160 words per scanline - what can we do then? The total bandwidth is now 2*1280*200.

* 320x200 means 2560/320 = 8 bits per pixel.
* 640x200 means 2560/640 = 4 bits per pixel. This is the "double-low" mode I have running in my STFM.
.. etc.

Ok, so, now it's time to remember that the MMU is pretty dumb. It knows nothing about _how_ the ST videomode is actually decoded. The only thing the MMU does is to latch&load words. The whole concept of bitplanes stems from how the Shifter interprets the words it reads from RAM. A new Shifter can change that.

So, let the Shifter interpret each word as two pixels, a chunky 256 color (8 bit) 320x200 mode. Since this is just how the Shifter interprets the video ram, the MMU doesn't need to know about it, and a coder will just poke bytes freely in the video memory. The coder doesn't "send" words or modify two pixels at the same time etc. It would simply mean that a move.b d1,(a0,d0.w) would set an individual pixel. It would be very similar to the Falcon true color mode which is 65536 colors per pixel (a word).

Exactly what colors the Shifter uses for the value 0-255 isn't really important, it might well be some RRRGGGBB or hard coded palette.

Gunstick
Posts: 25
Joined: Tue Aug 22, 2017 12:42 pm

Re: ST SHIFTER operation ?

Post by Gunstick » Fri Oct 27, 2017 7:31 am

Something does not add up.
EDIT: maybe me got it wrong, anyhow here is my take on a byte chunky mode instead of words

In color lookup mode, you have 2 pixels, coded as ABABABAB
All the As make the color index for the first pixel, that's 2*2*2*2 = 16. That's a 16 color mode. And the Bs make up the second pixel.

If you use a direct color mode you have this: RrGgBbXx
That's a 3 bit color mode with transparency (or intensity). Makes 2*2*2=8 colors selectable in 2 intensities: 16 fixed colors

If you use 1 pixel per byte you have a 160x200 resolution, something which was often emulated in demos.
It gives you 1 byte per pixel mode as AAAAAAAA, with a color lookup table of 256 colors at once.
Or a true color mode as RRGGBBXX, with 128 colors in 4 intensities with 4 shades per color (and 160 pixels per line)
Or the skewed 256 color mode you mention: RRRGGGBB (again 160 pixel per line). This is still practical as anyone using such a mode will use it in byte mode. If you like planes changing, you either use a planes mode or set some pixels to 0 on your program as RR0GG0BB.

As it's a shifter, fancy tricks are possible, like having one line in planes and the next in pixel mode.

Making a new shifter? Add an overscan bit.

Georges

User avatar
exxos
Site Admin
Posts: 2566
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Fri Oct 27, 2017 8:06 am

@ Gunstick

Are you taking into account we are double clocking the MMU and doubling the data rate to the shifter ? We can either double the scan line resolution or double the colour data.


@ troed

One thing which hasn't been considered yet, is that while the frame rate is 50 frames per second, this is of course needed for CRT screens, as any refresh rate slower than this would cause a terrible flicker.

However on a LCD screen, they do not really have this issue I think. I think they could be usable at say 25 frames per second refresh rate and I think the LCD screen would not flicker.

So my thinking is to slow down Vsync to the MMU, as I understand it it is a reset line for the video-based counter. So every slow to signal down, the MMU could output 400 pixels vertically before resetting with Vsync.

Of course the extra vertical resolution would mean Vsync to the monitor would have to be doubled, so it would be more a VGA resolution, than a TV one.

Of course as the MMU and shifter are going to take twice as long to draw 400 pixels vertically, the frame rate halves from 50 times a second to 25 times per second. On a CRT this would not be possible really, but on a LCD I think it could be.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Atarian Computing
Posts: 180
Joined: Tue Aug 22, 2017 4:27 am

Re: ST SHIFTER operation ?

Post by Atarian Computing » Fri Oct 27, 2017 9:44 am

Although low FPS on LCD doesn’t cause any flickering, it does cause jerky/laggy mouse control. That’s partly why it was a big deal to step up from the early 4K 30Hhz monitors to higher refresh rates.

User avatar
exxos
Site Admin
Posts: 2566
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Fri Oct 27, 2017 11:38 am

Atarian Computing wrote:
Fri Oct 27, 2017 9:44 am
Although low FPS on LCD doesn’t cause any flickering, it does cause jerky/laggy mouse control. That’s partly why it was a big deal to step up from the early 4K 30Hhz monitors to higher refresh rates.
Never thought about the mouse.. I was thinking a lot of games are pushed to get 2FPS :lol:

I suppose that would be the "price" for the higher resolution. I don't know if it's possible to fake 25FPS in software somehow to see the effects of the lag ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
IngoQ
Posts: 546
Joined: Tue Aug 22, 2017 8:38 am
Location: Germany

Re: ST SHIFTER operation ?

Post by IngoQ » Fri Oct 27, 2017 11:59 am

25Hz refresh rate is out of specs for almost all TFT panels. Native refresh rate is almost always 60Hz, that's why a 50Hz scrolling screen appears a little jerky.
Ingo :geek:

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupéry

User avatar
exxos
Site Admin
Posts: 2566
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Fri Oct 27, 2017 12:20 pm

IngoQ wrote:
Fri Oct 27, 2017 11:59 am
25Hz refresh rate is out of specs for almost all TFT panels. Native refresh rate is almost always 60Hz, that's why a 50Hz scrolling screen appears a little jerky.
I guess it depends if the data is buffered or not, no idea. As if the screen data was buffered, the screen would still refresh at 50hz, but the data wouldn't change..

My monitor will do 25hz interlaced. doesn't seem jerky, just flickers like buggery.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Post Reply