ST SHIFTER operation ?

General discussions or ideas about hardware.
User avatar
exxos
Site Admin
Site Admin
Posts: 13741
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
YouTube: https://www.youtube.com/user/exxosuk
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Mon Oct 16, 2017 3:25 pm

rpineau wrote:
Mon Oct 16, 2017 3:08 pm
Here is an quick diagram of how the 4 bit plane mode works on the ST :

Image
I could probably do with a actual example of what data is in each word.. Single bit in each word can be one or zero, four times over for planes means basically 4 bits to select one of the colour palette registers (0-15).

So we actually have steam bits per word, so I assume these 16 bits relate to 16 pixels on screen ?

So something like...

0000000000000001
0000000000000001
0000000000000001
0000000000000001

Would draw 15 pixels, all black, and the last pixel would select colour 15 from the palette ?
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ?

keli
Posts: 95
Joined: Tue Aug 22, 2017 1:34 pm

Re: ST SHIFTER operation ?

Post by keli » Mon Oct 16, 2017 3:43 pm

exxos wrote:
Mon Oct 16, 2017 9:49 am
keli wrote:
Mon Oct 16, 2017 8:03 am
You'd probably need 8 of them. 4 for the data currently being loaded from memory and the other 4 for the data being shifted out to the screen.
Possible yes. I was thinking with a 64bit shifter register, that 16bits would get shifted out, then the top bank of 16bits (which would have been shifter to bank 2 and now empty) would then get loaded.
The problem is that for the first pixel in a group of 16 you need bit 0 of the first word, bit 0 of the second word, bit 0 of the third, and bit 0 of the fourth. The next pixel index is generated from bit 1 of each word, and so on. The shifter uses up each bit of the four bit planes in parallel -- So while shifting out the 16 pixels, you'll need to have space to store the next four words before you can use them. -- There is not enough information to output any pixels until you have all four words.

keli
Posts: 95
Joined: Tue Aug 22, 2017 1:34 pm

Re: ST SHIFTER operation ?

Post by keli » Mon Oct 16, 2017 3:48 pm

exxos wrote:
Mon Oct 16, 2017 3:25 pm
I could probably do with a actual example of what data is in each word.. Single bit in each word can be one or zero, four times over for planes means basically 4 bits to select one of the colour palette registers (0-15).

So we actually have steam bits per word, so I assume these 16 bits relate to 16 pixels on screen ?

So something like...

0000000000000001
0000000000000001
0000000000000001
0000000000000001

Would draw 15 pixels, all black, and the last pixel would select colour 15 from the palette ?
Correct... well the first 15 pixels are colour 0 from the palette, not necessarily black, and the last pixel is index 15 as you guessed.

User avatar
exxos
Site Admin
Site Admin
Posts: 13741
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
YouTube: https://www.youtube.com/user/exxosuk
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Mon Oct 16, 2017 3:51 pm

keli wrote:
Mon Oct 16, 2017 3:43 pm
The problem is that for the first pixel in a group of 16 you need bit 0 of the first word, bit 0 of the second word, bit 0 of the third, and bit 0 of the fourth. The next pixel index is generated from bit 1 of each word, and so on. The shifter uses up each bit of the four bit planes in parallel -- So while shifting out the 16 pixels, you'll need to have space to store the next four words before you can use them. -- There is not enough information to output any pixels until you have all four words.
Yeah, pretty much as mentioned above I think.

There must be some banks swapping going on here.. Because we have 4 banks of 16-bit shift registers, but of course we cannot load anything into those as we need all four words can only come one word at a time. So like you say we probably do need eight banks of registers..

So by default banks zero is selected and the MMU loads each word into bank zero, and then the shifter outputs them..

At the same time the MMU still be wanting to load data, in which case it would have to load into bank one.

Then I guess after 16 clock cycles there will be a flip-flop circuit to flip to bank one, in which case now bank one is shifted, and banks zero is now getting the new data from the MMU.

Not sure if I explained this well, but it makes sense in my head it least :) :lol:
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ?

keli
Posts: 95
Joined: Tue Aug 22, 2017 1:34 pm

Re: ST SHIFTER operation ?

Post by keli » Mon Oct 16, 2017 4:10 pm

exxos wrote:
Mon Oct 16, 2017 3:51 pm
There must be some banks swapping going on here.. Because we have 4 banks of 16-bit shift registers, but of course we cannot load anything into those as we need all four words can only come one word at a time. So like you say we probably do need eight banks of registers..

So by default banks zero is selected and the MMU loads each word into bank zero, and then the shifter outputs them..

At the same time the MMU still be wanting to load data, in which case it would have to load into bank one.

Then I guess after 16 clock cycles there will be a flip-flop circuit to flip to bank one, in which case now bank one is shifted, and banks zero is now getting the new data from the MMU.

Not sure if I explained this well, but it makes sense in my head it least :) :lol:
From the Alive 11 description it looks like there are the following registers:

Code: Select all

LoadIndex: 2 bits, incremented by one after every /LOAD
RL[0] to RL[3]: 16 bits each. When /LOAD is pulled low RL[LoadIndex] is latched from the data pins.

PixelIndex: 4 bits, incremented by one on every pixel emitted.
RR[0] to RR[3]: 16 bits each. Each one is shifted by one bit on every pixel clock.
On every clock, when shifting the RR registers, the top bit from each one become bit 0 through 3 in an index into the palette registers.
When PixelIndex wraps around to 0, RR[0] though RR[3] are loaded with a copy of the contents in RL[0] to RL[3].

The effect would be the same as you describe, except instead of swapping the "loading" vs "shifting" roles, a copy is performed instead.

User avatar
exxos
Site Admin
Site Admin
Posts: 13741
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
YouTube: https://www.youtube.com/user/exxosuk
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Mon Oct 16, 2017 4:18 pm

That kind of sounds like every load pulse the next buffer register is loaded..

This is my quick mockup so far...
shifter.png
shifter.png (12.97 KiB) Viewed 2404 times
I have made the assumption here that both banks of registers are being clocked the same speed, in reality the MMU could actually load the data quicker than the shifter needs it, but I do not know this at the moment either way...

So data initially goes into bank zero, but then they would have to be a specific wait time of 16 clock cycles before the MMU should load more data.. So this look like it may not be actually correct...

The basic idea was that there would be 128 bit counter for bank select, where the most significant bit would be high or low for 64 clock cycles. So on the 65th clock cycle banks zero or bank one would be selected.

So probably there is actually a another small counter to select banks zero 16 bit banks. Basically a one of four selector which is clocked by the MMU load signal..

Of course I do not actually know the load sequence of the MMU, but the at least using load as a one of four selector for the banks, the speed in which the MMU loads of data would actually be irrelevant, providing of course it is actually faster than the shifter is outputting the data...

EDIT:

So it would be like this..
shifter2.png
shifter2.png (16.4 KiB) Viewed 2402 times
So each 16 bit bank is connected directly to the MMU databus.. And which bank is selected is based on a one of four counter, which is clocked on the load line..

Of course it probably is a bit more complicated as bank one would also need saying databus as input, but that would not really be a problem anyway, is just getting a bit messy to draw now :lol:

The problem I see there is, there would have to be some sort of disable on the banks zero clock line, as we in this case would not clock a shift registers the same time as the output register...

This probably now makes more sense why a copy is done rather than a bank swap...
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ?

keli
Posts: 95
Joined: Tue Aug 22, 2017 1:34 pm

Re: ST SHIFTER operation ?

Post by keli » Mon Oct 16, 2017 4:33 pm

exxos wrote:
Mon Oct 16, 2017 4:18 pm
So it would be like this..

shifter2.png

So each 16 bit bank is connected directly to the MMU databus.. And which bank is selected is based on a one of four counter, which is clocked on the load line..
You will not be shifting 64 times. Each register in the bank will get shifted in parallel, so only 16 shifts happen, which means your shift counter only need to count to 16. (4 bits)

User avatar
exxos
Site Admin
Site Admin
Posts: 13741
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
YouTube: https://www.youtube.com/user/exxosuk
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Mon Oct 16, 2017 4:40 pm

keli wrote:
Mon Oct 16, 2017 4:33 pm
You will not be shifting 64 times. Each register in the bank will get shifted in parallel, so only 16 shifts happen, which means your shift counter only need to count to 16. (4 bits)
ahh yep, 16 banks of 4..
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ?

User avatar
exxos
Site Admin
Site Admin
Posts: 13741
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
YouTube: https://www.youtube.com/user/exxosuk
Contact:

Re: ST SHIFTER operation ?

Post by exxos » Mon Oct 16, 2017 4:46 pm

http://www.ti.com/lit/ds/symlink/sn54ls165a.pdf

So it seems a generic shifter does have a gated clock.. The data can be loaded in and the clock can be "stalled"...

While I think about it, has anyone noticed like the planes split apart on fast-moving objects on the screen? I have noticed this for a while actually..

Because while testing GB6 the blitter test rapidly moves the square screen, but I sometimes see likely out of phase box which is drawn in red, of course the box being drawn is simply black-and-white but it is like it has a very fast-moving shadow but in red which is a couple of pixels out of sync with the actual black-and-white box..

I wonder if this is down to glitches in the shifter.. With copying data from one bank to another, there must be some glitch somewhere with palette selection and delays in the actual copy in relation to what is actually being drawn on the screen..

It might not be that, but possibly using a bank select might be a better method as it will simply be faster and I cannot really see things glitching, but of course these are just my initial thoughts..
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ?

User avatar
rpineau
Site Admin
Site Admin
Posts: 529
Joined: Thu Aug 17, 2017 6:08 pm
Location: USA
Contact:

Re: ST SHIFTER operation ?

Post by rpineau » Mon Oct 16, 2017 4:49 pm

The "split plane effect" is happening on app that need more than 1 VBL to move things horizontally.
This doesn't happen in demo as we keep everything in one VBL with multiple screen buffers.
So this is a pure code issue, not hardware issues.
Working ones : MegaSTE (68020) / TT030 / Falcon with AB040 & Eclipse / 1040STF
Need testing : Falcon with CT2

Post Reply

Return to “HARDWARE DISCUSSIONS”