ST SHIFTER operation ?

[keli]

I found this diagram that shows the high level relation ship between DE, HSYNC and BLANK on Jean Louis-Guérin's Atari site



I'm not sure how much more information it adds nor how accurate it is, but I thought I'd post it here just in case.

[exxos]

Adding two traces that Dio made a long time ago over at A-F, and I used as a basis for some of the thinking around the GLUE statemachine.

Odd... CS basically doing nothing...

Assume DE HI is no video data, and the shifter LOADs data, though would have expected just 4 clock cycles on load or something..



With so many shifter LOAD pulses when DE=HI, maybe its actually loading in a entire pixel line at once, then shifting the whole line out in one go, rather than just 4 words at a time, it would do 320 load pulses... Saying that it would be 320 x 4 = 1280 load pulses.. doesn't seem right either..

Kinda seems its loading data when the shifter is not outputting to the screen.. assuming DE low tells the shifter to output data.. then DE high would be the borders.. Which would mean the shifter is loaded with data while the border is being drawn.. but as we can do full screen.. that doesn't add up either.

[rpineau]

CS is only used to access the Shifter registers, not used during the actual display.
The MMU does the memory access and place the data on the shifter bus during the display time.

[exxos]

Makes sense..

Question is, why is the shifter LOADing so much data in one go.. looks to be like 100 cycles, hard to tell from the image.

I guess 16 pixels 4 planes is 4 words per 16 pixels, so would need 80 words for a scan line of 320px.

( 320 / 16 ) * 4 = 80 words...

As there is a lot of LOAD pulses, then it could well be the shifter is loading in 80 words at once. Would mean the actual shifter registers are a lot larger than originally thought..

[troed]

Makes sense..

Question is, why is the shifter LOADing so much data in one go.. looks to be like 100 cycles, hard to tell from the image.

I guess 16 pixels 4 planes is 4 words per 16 pixels, so would need 80 words for a scan line of 320px.

( 320 / 16 ) * 4 = 80 words...

As there is a lot of LOAD pulses, then it could well be the shifter is loading in 80 words at once. Would mean the actual shifter registers are a lot larger than originally thought..

Did you read the Alive 11 article? http://alive.atari.org/alive11/oscan2b.php

MMU latches the video address and then signals LOAD. Shifter then reads a word into the IR registers, while the RR registers are shifted out. When the RR registers are empty, the IR registers (four words) are copied into IR, rince and repeat.

Code: Select all

Number_of_read_bitplanes = 0
REPEAT
 IF Load is active THEN IR[Number_of_read_bitplanes] = Data sent from MMU
                        Number_of_read_bitplanes = Number_of_read_bitplanes + 1
 IF Number_of_read_bitplanes == 4 AND IF DE is active
    THEN RR1 = IR1; RR2 = IR2; RR3 = IR3; RR4 = IR4
 IF Number_of_read_bitplanes == 4 THEN Number_of_read_bitplanes = 0
END_REPEAT

As soon as GLUE DE goes active the Shifter starts to rotate out the RR registers (palette lookups) and the MMU starts latching and LOADing.

/Troed

[exxos]

I did read it yes. Though the timings you posted through me somewhat.

Looking at it again, it looks like DE goes high the shifter to output data, actually assumed it was active low signal .

Blanking low, and HSYNC goes high the same time, obviously there would be no data needed at this point other than the background border colours so this actually makes more sense that way.

keli posted similar timings but HSYNC looks inverted to what those logic analyser results are.

I will assume that when DE goes low, this is the point where the border colour is drawn, then a little time later we have the blanking signal and horizontal sync pulse.

In any case, never mind

I was thinking about running a simulation of the shifter in my simulation software, but a lot of the IC's such as binary counter etc not actually in the simulation library this would mean I would have to recreate them gate by gate be no fun at all.

The altera design software does have a simulate at all, but I have not yet than that out yet as I've only just started using the software. The software is very flexible on setting up various IC functions. So what I will probably do is start off by building the banks of shifters, and bank select, and see if I can input some dummy values for the load lines.

This of course is going to take a lot of time to do as am still getting used to the software and really busy with work at the moment as well. But I did make a start..

1.jpg (35.82 KiB) Viewed 5396 times

Idea here is that the load signal is clocking a two bit binary counter, which then goes to a one of five decoder. The first four lines select one of the four 16 bit registers, then the fifth bit will be used as a banks zero or bank one select.

As discussed before I think a bank swap will work just the same as a bank copy. At least in my mind anyway it seems easier to use a bank swap.. Though when I draw this out I could change my mind

If I get some time on Thursday I will start adding the registers to this.. I am having tomorrow off and plan on doing is little as possible

[exxos]

I did a quick knock up just of the load registers...

1.JPG (398.04 KiB) Viewed 5381 times

I think I realise why a copy is used between shifter banks.. The problem I see here is the load signal from the MMU has to be used as the clock, to clocking the data to reach shifter register. This means I cannot really link the 32 MHz clock at the same circuit.

So the output register would always be run on the pixel clock, assuming here 32 MHz.

Question is really how to take the output of all these load registers and passing them to the output register without causing any glitches anywhere.

I have a binary counter in this, it is also clocked by the load signal. Then over one of four (actually five in this case currently) is used as a chip select signal as to select one of the four shifters to accept data.

Active low and active high parts I have not figured out yet will try and work that out tomorrow..

Though currently I see a problem that the load signal cannot really be used to select the next register because as soon as a low signal activates the binary count will go up one and it will be practically impossible to select the first shift register..

So probably what I will do is add a flip-flop onto the load signal, so the load signal happens first and there will be a clocked delay before the next if there is selected.. I still need to think about this, of course open to suggestions if anyone has ideas on how to go about this..

EDIT:

I found a better shifter block.. This one should allow bank select to work as there is a pin for loading or shifting.. Probably what would be better is to use the 32 MHz clock for actually clocking the data into the shifter rather than using the actual load signal.. Actually would be still using the load signal but in combination with 32 MHz clock. Basically when load is low it will use of 32 MHz clock to clog the data in.

The only slight side effect here is that the data would be clocked multiple times while load is low but as this is all going to be done the same shifter I do not think it would really matter anyway...

EDIT2:

2.JPG (345.88 KiB) Viewed 5376 times

So LOAD has to be LOW (inverted high) and 1 of 5 has to be high. when both are high, the shifter is enabled to clock in data.

eq4 of the 1 of 5 decoder will set all 4 shifters in turn to LOAD. Then on the 5th clock, is bank swap to set them all in shift operation..

I do half see a issue as we need to load in "1 of 4" but output all at the same time in the second shifter bank, not "1 of 4".. so need to think about that some more...

Could possible be a "copy" would be easier... Just have a 16 bit latch "front end" and use LOAD to latch the data. Would be easier I think. Then some other clock to load the data into the shifter registers in one go then output...

Just seems to be like this "copy" would cause a "stutter" in the pixel line drawing as every 16 pixels, there would be a small delay during the copy..

Has anyone noticed a "gap" in between blocks of 16 pixels on the screen?... could be really hard to see on a monitor..

[exxos]

Okay I updated circuit again just as I had a few moments.. This is with the idea of bank switching rather than bank copy..

1.JPG (431.7 KiB) Viewed 5365 times

The load line is inverted, so load is assume load is assumed to be active high after the inversion...

So basically the start-up is assume that all outputs of the decoder or zeros for start-up, in any case it is a matter..

What happens is on the first count EQ0 goes high the top and gate. Load line goes high into the and gate also so we then get an output. The or gate also goes high and enables the first shift register.

When the load line then goes low, data is latched in the first register, and the binary counter then council one more. So now EQ0 goes low and output of the first and gate also goes low, and all gate also goes low.

Now EQ1 goes high and the process repeats where data is latched on the second shift register.. And so on...

EQ4 is the bank select... Actually realises should be on the binary count output not the decoder but anyway...

EQ4 gets inverted so it is now high which selects load on each shift register.

When the count gets up to 5, EQ4 will then stay high for the next four cycles.. Now the load signal goes low, and sets all the shift registers into shift mode.

As we now need to clock each of the four registers at once for all four bit planes, EQ4 is also connected to the all gate so that when it goes high it enables all the clocks on all four shift registers. So every 32 MHz clock all four shift registers will shift out a bit.

Shift register bank one will be basically a copy of this circuit, only the clock enables will be non-inverted.. I need to wire up this obviously and will post an updated circuit later...


EDIT:

Corrected bank select on the binary counter circuit...

2.JPG (425.99 KiB) Viewed 5365 times

[exxos]

Bank one now wired in..

3.JPG (498.29 KiB) Viewed 5361 times

The second bank basically just has inverted shifter LOAD and ENABLE lines.

Of course the OR gates basically set parallel operation for either bank, basically just an override for the individual shifter select signal. As a left and right banks are inverted, the shifter will either be loaded individually, or shifting all in parallel... At least that is the idea

[exxos]

I've almost finished the circuit for the copy method..The while designing this I think I just realised thing as well..

My bank switching circuit makes the assumption that the MMU is precisely timed for loading the registers fully at exactly the same time this run out of bits shift. For example if the MMU finishes the four words input and the shifter has only shifted out maybe 10 pixels, it would then be forced to reload the data start shifting the new data around, and it would result in six missing pixels.. As I do not know the exact timings with all this is probably not a good idea to go down that route...

With the copy method, the four words can be loaded, and they are basically stored until the shifter runs out of data. In which case I would need to count to 16 to keep track of what has been shifted out of the shifter, then on the 17th clock cycle switch the shifter to load operation, load the data, next clock cycle would loop back to count zero start counting again and the shifter will start shifting bits from the zero again.

The thing is with this is more asynchronous to the loading of the data versus the outputting of the data. This way the shifter literally waits until all pixels have gone, and then it requests data from the latches. This way the loading speed is independent of the shifting speed.. This can actually mean the MMU can input data at virtually any speed it would not matter as long as it was loading data quicker than it was been outputted. I think this would be a good route to go down for future designs modifications.

With my bank switching circuit is to unknown relationships between the loading four words, versus the timings of what is being outputted by the shift registers. I think it would be bad to assume the MMU is shifting data at exactly the right speed to load the shifters from. In reality the MMU needs to load the data in advance offers to give the copy circuit time to operate.


EDIT1:

1.JPG (493.43 KiB) Viewed 5351 times

This is the copy circuit. Basically we have the one of four decoder again which acts as a select line to one of the 74273 latches. Data is latched when the load line toggles. Basically the all gates act as a clock inhibitor.. So that part is relatively simple..

I'm not really sure about the reloading of the shift registers.. Basically how I have this wired is that when the counter reaches 15, the and gate goes high, and the shift registers are loaded on the next 32 MHz clock cycle.

The bit I don't know if it is right, is that I do not know if the loading of data will affect the shifter outputs or not. I assume it shouldn't do but it might need to be actually done on the 16th clock cycle. As if the data changes immediately after load, this is the next pixel data. So I'm a bit confused over if this will actually lose pixel 15 or not..