ST Chipset decap

GFA, ASM, STOS, ...

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: ST Chipset decap

Postby npomarede » Sat May 07, 2016 7:53 pm

troed wrote:
alien wrote:My 4 bit hardscroll had a weird feature: it was offset by k+4n pixels versus the normal beginning of a line (n = 0, 4, 8, 12). Because k wasn't 0, (but small, although I don't remember the value)


k == 1 IIRC

/Troed

Yes, that's what is used in Hatari (1,5,9,13) and IIRC too it was mentioned in the ST Magazine articles.

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Mon May 09, 2016 12:00 pm

alien wrote:My 4 bit hardscroll had a weird feature: it was offset by k+4n pixels versus the normal beginning of a line (n = 0, 4, 8, 12). Because k wasn't 0, (but small, although I don't remember the value) ... If you have time and interest, Ijor, I'd be curious why that is.


This is because the timing that Shifter see the resolution change is not aligned to ... well, it's not aligned to anything, but most important here, it is not aligned to the point where the pixel counter starts counting at the start of the line.

When the counter starts, right after the first LOAD pulse, Shifter is already in med rez. So the instruction that changed to med rez contributes only partially to the scroll effect (not 8 cycles). As exactly why K it is one (and say, not two), I can't tell without performing very precise simulations.

If you would do something like this: Change from mono to low (as a classic left overscan), only then to med, then n nops, then back to low. Then probably you won't have any K offset.

By the way, I am not completely sure that K is always the same, are we? There might be a wake up effect that could move K by half a cycle (one med rez cycle).

By the way two: Is this very stable? I mean, it looks like sometimes might suffer from the "every other 16 pixels background" effect.

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Tue May 10, 2016 1:55 am

Below is a seudo simulation waveform of the 4-bit hard scroll.
NOTE: the timing is not exact. This is just for the purpose of illustrating the idea of the K offset.

Seudo-4bit.png


The two vertical guides mark the moment that the resolution changed. First from mono to medium, then to low. Between both changes there are exactly 8 cycles.

However, by the time that the resolution changed to medium, the pixel counter didn't start counting. Counting starts only after the first LOAD pulse (light blue), that activates the cntrEn signal (red). The reload will be aligned according to the shifted value of this counter. This is what actually scrolls the display, the reload timing.

So shifter doesn't count 8 cycles at medium rez, but less. Then the reload position would be displaced less than 8 cycles. This gives the offset that is not multiple of 4.
You do not have the required permissions to view the files attached to this post.

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Wed May 11, 2016 12:38 am

ijor wrote:By the way, I am not completely sure that K is always the same, are we? There might be a wake up effect that could move K by half a cycle (one med rez cycle).


I think we are -- my articles say K = 1, and I don't remember seeing any variation on that.

ijor wrote:By the way two: Is this very stable? I mean, it looks like sometimes might suffer from the "every other 16 pixels background" effect.


Yes, AFAIK, it is very stable: I only heard of it failing on one STf. We tested it on all the models we had at ST-CNX, which was a large varied collection: some of which had very old chips which started displaying the top line earlier than standard chips, messing up fullscreen overscan. We had a report of an STf that didn't accept it, but that it also had other issues with overscan and had a flakey power transformer, but of course I didn't test it on every STf. We did know that 4bit hardscroll did not work on STes. (I think the 16 pixel pattern issue)
Alien / ST-Connexion

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Wed May 11, 2016 1:04 am

ijor wrote:Below is a seudo simulation waveform of the 4-bit hard scroll.
NOTE: the timing is not exact. This is just for the purpose of illustrating the idea of the K offset.

Seudo-4bit.png


The two vertical guides mark the moment that the resolution changed. First from mono to medium, then to low. Between both changes there are exactly 8 cycles.

However, by the time that the resolution changed to medium, the pixel counter didn't start counting. Counting starts only after the first LOAD pulse (light blue), that activates the cntrEn signal (red). The reload will be aligned according to the shifted value of this counter. This is what actually scrolls the display, the reload timing.

So shifter doesn't count 8 cycles at medium rez, but less. Then the reload position would be displaced less than 8 cycles. This gives the offset that is not multiple of 4.


Thanks for looking into it.

Yes, the reload timing is what I thought for the +0/+4/+8/+12 delay. Could the +1 delay have something to do with the pixClk which seems to lose a beat at the mono->mid rez transition? (or is that not an exact timing?) FWIW here is the code used to achieve the effect:

13 pixel shift:
move.b d2, (a0) # mono d2 = 2
nop
move.b d1,(a0) # mid rez d1 = 1
move.b d0,(a0) # low rez d0 = 0
or.l d0,d0
nop

9 pixel shift:
move.b d2,(a0)
nop
move.b d1,(a0)
nop
move.b d0,(a0)
or.l d0,d0

5 pixel shift:
move.b d2,(a0)
nop
move.b d1,(a0)
or.l d0,d0
move.b d0,(a0)
nop

1 pixel shift:
move.b d2,(a0)
nop
move.b d1,(a0)
or.l d0,d0
nop
move.b d0,(a0)

(Of course this is updated as desired using Self-Modifying-Code, and a0 = ffff8260).
Alien / ST-Connexion

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Wed May 11, 2016 1:00 pm

alien wrote:
ijor wrote:By the way, I am not completely sure that K is always the same, are we? There might be a wake up effect that could move K by half a cycle (one med rez cycle).


I think we are -- my articles say K = 1, and I don't remember seeing any variation on that.


Yes, I mixed up things. Wake up states do affect the alignment between mid rez and low rez. But that is something different than this case.

Could the +1 delay have something to do with the pixClk which seems to lose a beat at the mono->mid rez transition? (or is that not an exact timing?)


No, because even if timing is exact (which is not that much exact), at that time the counter didn't start yet, so it doesn't matter. What matters is exactly how many times pixClk incremented at the faster (med rez) frequency. And this depends on the exact timing of when the Shifter clock mux detects the change of resolution back to low.

The exact timing is tricky, because the resolution change is not fully syncronized to Shifter internal clocks. But if you check the waveform, you can see that pixClk incremented 10 times at the faster clock. This translates to 5 extra increments, and 5 modulo 4 = 1!

Thanks for the code!

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: ST Chipset decap

Postby npomarede » Thu May 26, 2016 12:13 pm

Hi Ijor
In his old article about overscan, Alien described a "shifter reset" sequence by doing med/low switches once per VBL in order to empty any possible IRx registers of the shifter (to avoid having the screen shifted by 1 word when exiting a fullscreen demo).

We know it's not possible to detect when the shifter is in a state where spectrum 512 images are not correct for example, and this is explained by your research.
But do you think it could be possible to have a similar sequence, using hi/med/low switches at very specific points, to be sure shifter's counters are "re-aligned" with the correct places ?

On my STF for example, the demo "death of the left border" by TNT will always gives the "vertical 16 pixels black band every 32 pixels" when the STF is in the WS3 states (in other states, screen is correct). In WS3, others fullscreen demos are of course working without black bands effect. This reminds me a post by Troed who said he had a test program that gave reproducable defaults after several freq switches.
Specific code about this demo by TNT is that there's no right stabiliser, but the hi/lo switch to remove left border is a little longer :
- hi/lo switch at position 0/16
- 60/50 switch at position 376/388

What do you think ?

Nicolas

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Fri May 27, 2016 2:27 am

Hi Nicholas,

I was going to write a comprehensive description of the Shifter stabilization concept. I need to tie a couple of things before.

One thing that I yet don't fully understand, is how and why GLUE-MMU wakestates affect the shifter. I need to redo some of my old research, because I did it based on two wakeup modes only. Somebody have the LA traces performed by DIO capturing the four wakestates? They don't seem to be here in the forum. He posted a few traces, but not the ones that show the different wakestates.

npomarede wrote:In his old article about overscan, Alien described a "shifter reset" sequence by doing med/low switches once per VBL in order to empty any possible IRx registers of the shifter (to avoid having the screen shifted by 1 word when exiting a fullscreen demo).
...
But do you think it could be possible to have a similar sequence, using hi/med/low switches at very specific points, to be sure shifter's counters are "re-aligned" with the correct places ?


I'm not really sure that there is one universal process to realign shifter counters that would work in every case, other than executing the CPU RESET instruction. The problem is that Shifter, except at hardware reset, never really resets the plane/words counter.

Before I starting researching this issue, I thought that stabilization produces some kind of internal reset on Shifter. But it really doesn't. What the stabilization switches do, is to provoke the "every other 16 pixels" bug, but for a good effect. The idea is that the bug makes Shifter to delay the Reload process one or two LOAD pulses (as with the bug). If Reload is delayed, the plane/word counter is delayed as well (because the counter is reset after a Reload).

Yeah, I will post simulation waveforms of this at some point.

On my STF for example, the demo "death of the left border" by TNT will always gives the "vertical 16 pixels black band every 32 pixels" when the STF is in the WS3 states (in other states, screen is correct). In WS3, others fullscreen demos are of course working without black bands effect. This reminds me a post by Troed who said he had a test program that gave reproducable defaults after several freq switches.
Specific code about this demo by TNT is that there's no right stabiliser, but the hi/lo switch to remove left border is a little longer :
- hi/lo switch at position 0/16
- 60/50 switch at position 376/388


I would need to check it, possibly to simulate it, to describe exactly what is going on. But i can tell you already that the exact timing of the right switch doesn't matter. 50/60 Hz switches don't affect Shifter, except, of course, indirectly as a consequence of altering the line length. So any switch that opens the right border (without changing rez) should be the same for this purpose. The different timing of the left switch that changes rez, is, of course, very relevant.

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Fri May 27, 2016 4:09 am

FWIW, here is the shifter reset code from my article:

reset_shifter:
move.l #$VBL_routine, $70.w
moveq #5,d0
loop:
move.b #1, $ffff8260.w
stop #$2300
clr.b $ffff8260.w
stop #$2300
dbra d0, loop
rts

VBL_routine:
rte
Alien / ST-Connexion

User avatar
troed
Atari God
Atari God
Posts: 1217
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: ST Chipset decap

Postby troed » Fri May 27, 2016 9:37 am

ijor wrote:One thing that I yet don't fully understand, is how and why GLUE-MMU wakestates affect the shifter.


Not sure what you're thinking of - my naïve explanation is that it's due to timing. Depending on WS there will be a 0-3 cycle difference in when DE and/or RES changes. I have some notes to the effect of the Shifter clearing "less words" depending on wakestate. And heat. The "cold/warm" substates that clearly exist also have that effect.

I actually failed somewhat with my new fullscreen scanlines as used in Closure. You might've seen my thread on how to "snoop the bus" - which was all a try to see if it was possible to detect the "every other 16 pixels" substate from software. The "new scanline" works (more or less) always in WS1, WS3 and WS4. However, in WS2 (with the shortest delay from DE-to-LOAD) I have one codepath that works in "cold" and one that works in "warm" - but the wrong codepath for the substate will show "every other 16 pixel" bands. So in the released demo I simply opted for one of them (the "cold", I think) since I failed detecting when it happens from software.

It's my hope that your incredibly detailed descriptions on how the Shifter synchronizes will allow us to solve this :) It's what I will spend time on once I find some time to spend ...

/Troed

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Fri May 27, 2016 11:44 am

alien wrote:FWIW, here is the shifter reset code from my article


Ah, not exactly switches, but whole frames at each rez. I missed that.

But if you can spend so much time, then it might be better to execute the RESET instruction. That is guaranteed to work. Of course, it is much more invasive as will affect things that you might prefer to avoid.

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Fri May 27, 2016 12:19 pm

troed wrote:Not sure what you're thinking of - my naïve explanation is that it's due to timing. Depending on WS there will be a 0-3 cycle difference in when DE and/or RES changes.


Yes, wakestates changes the timing between DE and REZ switches, and between DE and LOAD pulses. BUT, because of the way that Shifter deals with the DE signal, it shouldn't matter.

Shifter used DE to detect the start and the end of the line. Shifter restarts the pixel counter when it detects the line starts. It considers that a line starts when it receives the first LOAD pulse after DE was asserted. What matters is the LOAD pulse timing. It doesn't matter if DE was asserted one cycle ago, two cycles ago, or more. All it matters is that by the time of the LOAD pulse, DE was already active.

The end of line detection is a bit more complex but it follows the same idea. The exact timing of DE is not relevant.

Actually, this is probably by design. Not too long ago I thought that Atari wasn't aware about wakeup/wakestates issues, at least not initially. At this point, after studying Shifter internals, I am almost sure that Atari "knew"!

And heat. The "cold/warm" substates that clearly exist also have that effect... However, in WS2


Well, what SEEMS to be happening is that SHIFTER and GLUE wakestates are related. Conceivable, the same environmental conditions that provoke a given GLUE-MMU wakestate, also (almost) always provoke a corresponding SHIFTER-MMU wakestate.

So, possibly, it is not exactly that (GLUE-MMU) WS2 doesn't work, but the failure is because of the SHIFTER wakestate that usually happens when the machine wakes at GLUE-MMU WS2.

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Fri May 27, 2016 12:34 pm

troed wrote:...I have one codepath that works in "cold" and one that works in "warm" - but the wrong codepath for the substate will show "every other 16 pixel" bands. So in the released demo I simply opted for one of them (the "cold", I think) since I failed detecting when it happens from software.


As I said, I think that unfortunately there is no way to detect SHIFTER "states" from software. But one simple way to visualize one SHIFTER wakestate, is the alignment between low and med rez.

Put some kind of pattern on the screen alternating lines at low and med rez. Some design that will make easier to spot the exact alignment between both resolutions. It will change slightly (a single med rez pixel, I think) depending on the wakestate.

Note that the absolute position doesn't matter here. This depends on the GLUE-MMU wakestate. I am talking about the relation between low and med resolutions.

User avatar
troed
Atari God
Atari God
Posts: 1217
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: ST Chipset decap

Postby troed » Fri May 27, 2016 12:35 pm

ijor wrote:The end of line detection is a bit more complex but it follows the same idea. The exact timing of DE is not relevant.


I'll think a bit more and comment later.

ijor wrote:
And heat. The "cold/warm" substates that clearly exist also have that effect... However, in WS2


Well, what SEEMS to be happening is that SHIFTER and GLUE wakestates are related. Conceivable, the same environmental conditions that provoke a given GLUE-MMU wakestate, also (almost) always provoke a corresponding SHIFTER-MMU wakestate.

So, possibly, it is not exactly that (GLUE-MMU) WS2 doesn't work, but the failure is because of the SHIFTER wakestate that usually happens when the machine wakes at GLUE-MMU WS2.


I try to not call what I'm thinking of wakestate because it isn't set at boot (like Spectrum 512 pixels, which most certainly is one - and might be what you mean). The "cold"/"warm" substate really does change during a single boot. I.e, Closure in WS2 works when the machine ("Shifter" - so far not conclusively proven but likely) is cold but will show more and more bands of 16 blank pixels when the machine is running until all lines every other 16 pixels are blank. I've then tried, in that same boot, to change to my other codepath which then works.

I've also made notes when I made my first 1+3 scanline non-fullscreen syncscroll and there was a clear difference in the amount of words the Shifter cleared at the end of the line (IR registers) between "cold" and "warm", in several wakestates. More in WS2, no difference in WS1, IIRC.

/Troed

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Fri May 27, 2016 8:00 pm

ijor wrote:Ah, not exactly switches, but whole frames at each rez. I missed that.

But if you can spend so much time, then it might be better to execute the RESET instruction. That is guaranteed to work. Of course, it is much more invasive as will affect things that you might prefer to avoid.


I also had some "fix everything that possibly could be wrong" code that I ran after my experiments and that code included a RESET instruction. However it also caused the frame to jump on my monitor (50Hz -> 60Hz -> 50Hz), which was undesirable, and it may have had other effects I don't remember. I may be misremembering, but I also think it didn't always work, whereas the the above code did force the Shifter to reset as I wanted reliably. Perhaps RESET only clears the IR registers at certain points? Anyways, I'm operating on 20 year old memories at this point, and I'd have to go test everything out again to be sure.

How are you simulating the Shifter? Do you have a netlist or a verilog implementation? (or VHDL, which I never learnt)?
Alien / ST-Connexion

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Sat May 28, 2016 3:45 am

troed wrote:I try to not call what I'm thinking of wakestate because it isn't set at boot (like Spectrum 512 pixels, which most certainly is one - and might be what you mean). The "cold"/"warm" substate really does change during a single boot. I.e, Closure in WS2 works when the machine ("Shifter" - so far not conclusively proven but likely) is cold but will show more and more bands of 16 blank pixels when the machine is running until all lines every other 16 pixels are blank. I've then tried, in that same boot, to change to my other codepath which then works.

I've also made notes when I made my first 1+3 scanline non-fullscreen syncscroll and there was a clear difference in the amount of words the Shifter cleared at the end of the line (IR registers) between "cold" and "warm", in several wakestates. More in WS2, no difference in WS1, IIRC.


Yeah. I realized you were talking also about current (not wakestate) conditions. I just was too lazy to elaborate about it. But as long as GLUE wakestates are also involved, it is the same thing. That is, as long as you are talking about GLUE wakestates combined in some way (and you do), it stills implies that GLUE wakestates affect Shifter. And as I said, they shouldn't, or at least I don't see how.

Of course, if wakestate aware code changes the code path because of the current wakestate, then the modified code path might make a difference for Shifter. But not the wakestate itself.

I'm still not 100% because I haven't seen LA traces of the four wakestates. The traces are important because the analog delays related to the clock chain division. Those delays are very hard to quantify precisely from the chip logic. So that's something better seen tracing or scoping the signals.

But I still suspect that GLUE wakestates here are just incidental. It is about SHIFTER wakestates, and of course, as you say, about current (not wakeup) conditions.

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Sat May 28, 2016 4:02 am

alien wrote:I may be misremembering, but I also think it didn't always work, whereas the the above code did force the Shifter to reset as I wanted reliably. Perhaps RESET only clears the IR registers at certain points?


You are (partially) right! Yes, hardware reset might not perform actually a clean Shifter reset. The IR (plane/word) counter (actually a shift register) is not the problem. That one is always cleared on hardware reset. The problem is the pixel counter ...

Reset will not clear the pixel counter correctly if DE is active. And GLUE keeps running the video logic (DE,BLANK and SYNCs) on hardware reset. To work properly, reset must be still asserted when DE is not active.

How are you simulating the Shifter? Do you have a netlist or a verilog implementation? (or VHDL, which I never learnt)?


Yes, I am coding a verilog simulation model together with the schematics drawing.

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Mon May 30, 2016 12:03 am

ijor wrote:
alien wrote:I may be misremembering, but I also think it didn't always work, whereas the the above code did force the Shifter to reset as I wanted reliably. Perhaps RESET only clears the IR registers at certain points?


You are (partially) right! Yes, hardware reset might not perform actually a clean Shifter reset. The IR (plane/word) counter (actually a shift register) is not the problem. That one is always cleared on hardware reset. The problem is the pixel counter ...

Reset will not clear the pixel counter correctly if DE is active. And GLUE keeps running the video logic (DE,BLANK and SYNCs) on hardware reset. To work properly, reset must be still asserted when DE is not active.


Yes that fits what I remember. Thanks!

ijor wrote:
alien wrote:How are you simulating the Shifter? Do you have a netlist or a verilog implementation? (or VHDL, which I never learnt)?


Yes, I am coding a verilog simulation model together with the schematics drawing.


Cool! I hope you will be releasing it too. I'd really like to look at it! :D
Alien / ST-Connexion

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Fri Jun 10, 2016 9:20 pm

ijor wrote:Yes, wakestates changes the timing between DE and REZ switches, and between DE and LOAD pulses. BUT, because of the way that Shifter deals with the DE signal, it shouldn't matter...
What matters is the LOAD pulse timing.


I was wrong. Some testing and some thinking made me realize my mistake ...

For the end of the line, it is not exactly the LOAD pulse timing what matters, but the internal Reload pulse timing. The latter hapens sometime after the LOAD pulse. If Shifter is unstabilized in such a way that it read one word too much, then the Reload pulse would happens around the DE edge timing. So definitely it might stabilize or not depending on the wakestate putting the DE edge before or after the Reload.

npomarede wrote:On my STF for example, the demo "death of the left border" by TNT will always gives the "vertical 16 pixels black band every 32 pixels" when the STF is in the WS3 states (in other states, screen is correct)...
Specific code about this demo by TNT is that there's no right stabiliser, but the hi/lo switch to remove left border is a little longer :
- hi/lo switch at position 0/16
- 60/50 switch at position 376/388


This is the "early" switch that doesn't need a stabilizer in some specific wake state, or it is something else?

User avatar
alien
Atari maniac
Atari maniac
Posts: 85
Joined: Sat May 01, 2004 4:01 am
Location: USA
Contact:

Re: ST Chipset decap

Postby alien » Sun Jul 17, 2016 3:53 am

Hi ijor, I'm curious whether you've had any chance to learn anything new on this topic since your last update.
Alien / ST-Connexion

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Thu Jul 28, 2016 4:11 am

Hi Alien,

Sorry, was busy for a while and recently came back from a trip ... Some news shortly.

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Wed Aug 17, 2016 2:43 am

I made a pause with the Shifter (and GLUE) work. I needed to understand some MMU timings. So I spent some time on the MMU.

I opened a thread on the hardware subform about the MMU:

viewtopic.php?f=15&t=30241

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: ST Chipset decap

Postby Steven Seagal » Sun Sep 24, 2017 12:24 pm

ijor wrote:
GLUE DE off at emulator cycle 376 for a regular 50hz line.
Timer B triggers at cycle 404 = 376 + 28
28 = GLUE-MMU latency 8 + prefetch 16 + Shifter latency 4


Timer B interrupt lattency is related to GLUE, MFP and CPU delays. Again, MMU and SHIFTER are not involved. Anyway ...
It has jitter, it is not fixed. Will try to elaborate in a separate thread. Doesn't belong here, not much related to the thread topic.


Coming back to this, thx, it was confusing because the delay between DE and timer B IRQ was so close to the delay between DE and first pixel displayed.
Now I understand, in fact the MFP observes timer B input (DE) and needs some (MFP) clocks before it even decides it has changed, so there starts the delay.
I also get that it is off-topic, but it didn't look so because I thought the signal came from the Shifter... :)

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1992
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: ST Chipset decap

Postby Steven Seagal » Sun Sep 24, 2017 12:43 pm

More on topic, after having carefully re-read this thread, I intend to use those findings if possible in a future version of Steem (4.0).

Specifically, the two 4bit counters should be emulated because they seem to be enough to explain pixel and plane shifts we observe on the STF (maybe not the STE yet?).

I have two questions for the moment (maybe more later :) ):

1. When 4 words have been loaded but no RELOAD happened, because the pixel counter<16, and the MMU asserts LOAD again, what does the Shifter do? Does it load the new word, shifting previous words and losing the first word? That would explain some plane shifts.

2. In one example you assumed two words are loaded after previous scanline and the Shifter will self stabilize this scanline.
Is this after a right-off (line +44)?
In the example, the pixel counter never stopped. What kind of trick would cause that? Still the right off?

ijor
Hardware Guru
Hardware Guru
Posts: 3163
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: ST Chipset decap

Postby ijor » Mon Sep 25, 2017 3:07 am

Hi Steven,

Steven Seagal wrote:1. When 4 words have been loaded but no RELOAD happened, because the pixel counter<16, and the MMU asserts LOAD again, what does the Shifter do? Does it load the new word, shifting previous words and losing the first word?


Yes, the IR registers (as named in the Alien model) can be described as a kind of SHIFT array or FIFO. The FIFO/SHIFT is clocked by a LOAD pulse coming from MMU. No matter what, a LOAD pulse would push one word and discard the last one on the FIFO (the last word in the FIFO is the one that entered first).

2. In one example you assumed two words are loaded after previous scanline and the Shifter will self stabilize this scanline.
Is this after a right-off (line +44)?
In the example, the pixel counter never stopped. What kind of trick would cause that? Still the right off?


It is not a real life example. I just simulated that DE is misaligned so that two words remained from the previous scan.

There are many situations that can lead to the pixel counter not stopping. The logic stops the counter when a Reload happens after DE was deasserted. That would normally be after the last LOAD coming from MMU. The pixel counter can't be stopped before the actual Reload because the Reload logic depends on it.

But if DE is misaligned as in the example you mention, a Reload won't happen at the end of the line after DE is deasserted. That's actually why two words remain in the IR buffers. Without the last Reload the pixel counter won't stop.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 1 guest