horizontal scrolling on ST

[ljbk]

Hi !


Going back to the sync switches business and the impact in horizontal scrolling, i have just found out that i can detect via SW not 2 but 4 different wake up states for my Atari 1040 STF Rev. C !!!

The first difference is detected like before via the effects in the updates of sync register at address $FFFF820A.
There are two sets of timings: the early one and the late one. Let's call them early_820A and late_820A.
The reason for this is that the FFFF820A register is located only in GLUE that works at 8 MHz directly with the CPU, so it can be updated at CPU cycles 0, 2, 4, 6, ... so the preceding multiple of 6 instruction as impact on the timing of the update inside GLUE afecting the generation of the Display Enable signal that will then trigger the Shifter and the MMU.
That is also confirmed by the fact that only data bits 0 and 1 enter the GLUE allowing the updates of significant bits in FFFF820A and FFFF8260: the registers that are needed to produce the VSYNc, HSYNc and DE signals.
The MMU on its own will only allow the CPU access to the main memory, Shifter registers and internal counters registers (including the video address registers $FFFF820x) on mutiple of 4 cycles. This can be on cycles 0, 4, 8, 12, ... or 2, 6, 10, 14, ...
On the other multiple of 2 cycles, the MMU is reading data for the Shifter if Display Enable is active: 2, 6, 10, 14, ... or 0, 4, 8, 12, ...

As to go synchro code we sync with the $FFFF8209 register, we in fact sync with the MMU.
In one of these two FFFF820A set of timings, we can see that the TOS screen appears 2 pixels shifted to the right from RESET. This means that the MMU is two CPU cycle late in providing the data to the Shifter compared to the other FFFF820A set of times. So if we sync with a delayed MMU, we have to do the FFFF820A changes 2 cycles ealier in GLUE for this set of timings. And that is exactly what happens, the same effects are available but we have to do everything 2 CPU cycles earlier.
So we have:
- early_820A that corresponds to the old wake up state 1 where the screen appears shifted 2 pixels to the right;
- late_820A that corresponds to the old wake up state 2 (the most frequent with my machine) where the Nostalgic Main Menu does not work correctly;

The second difference is detected via the effects in the updates of resolution register at address $FFFF8260.
There are three sets of timings: the early one, the middle one and the late one. Let's call them early_8260, middle_8260 and late_8260.
The reason for this is the fact that this register consists in fact of two registers: the GLUE_8260 and the Shifter_8260.
The GLUE_8260 can be updated every 2 cycles and is used to produce the VSYNC, HSYNC and DE signals.
The Shifter_8260 can only be updated every 4 cycles when the MMU allows it: on cycles 0, 4, 8, 12, ...
or cycles 2, 6, 10, 14, ...
So we can have at least for periods of 2 cycles:
Glue_8260 / Shifter_8260:
Low / Low
Low / Med
Low / High
Med / Low
Med / Med
Med / High
High / Low
High / Med
High / High
So depending if the updates to $FFFF8260 are done at the same time inside GLUE and the Shifter or are 2 cycles later in the Shifter, we have at least two different situation that combined with a possible delay between the MMU and GLUE (see above) lead to at least 3 different set of timings for effects with updates to $FFFF8260 register.

Early_8260, middle_8260 and late_8260 set of timings allow the same effects but with 2 clock cycles between them of difference.

So we have the following combinations:

early_820A / early_8260 that corresponds to wake_up state 1 (dificult to get with my machine)
early_820A / middle_8260 that corresponds to wake_up state 3 (less common form of wake_up state 1)
late_820A / middle_8260 that corresponds to wake_up state 4 (less common form of wake_up state 2)
late_820A / late_8260 that corresponds to wake_up state 2 (the most common with my machine)

I attach a program that can detect the current wake up state.

There are other wake up states but that can not be detected by SW because they correspond to discrepancies between the internal cycle of the Shifter that works at 32 MHz and the wake up status of GLUE and the MMU.
An example of this is the funny Spectrum 512 dots. It depends if the write of the color register (ordered to the Shifter by the MMU in the CPU R/W multiple of 4 CPU cycle) happens before the color register is read to produce the RGB signal. In most cases the video signal was already produced so the color only really changes at pixel + 1. But sometimes it already occured so you get the new color for pixel 0 (funny color) or as the GLUE HSYNC/DE signals are not as precise as the Shifter clock, you get something in the middle (sometimes correct color / sometimes not). These flashing pixels or 16 pixels vertical black bars (see below) due to diferente internal Shifter cycles and relative GLUE unprecision (compared to the Shifter) can also be triggered by the motor of the drive to be active or not.
Another example of internal Shifter cycle is the type response and the timing of it to resolution changes while Display Enable is active:
- what to do if N pixels of the 16 where outputed in Low resolution and now we get High ?
- what to do if N pixels of the 16 where outputed in Low resolution and now we get Med ?
- what to do if N pixels of the 16 where outputed in Med resolution and now we get High ?
- what to do if N pixels of the 16 where outputed in Med resolution and now we get Low ?
- what to do if N pixels of the 16 where outputed in High resolution and now we get Med ?
- what to do if N pixels of the 16 where outputed in High resolution and now we get Low ?
N can be 0, High resolution shifting and ouputing occurs at 32 MHz,Med resolution shifting and ouputing occurs at 16 MHz and Low resolution shifting and ouputing occurs at 8 MHz.
Experience shows that the data comming from the MMU goes to internal register(s) before it is loaded to the ouput register(s) where it is shifted every 1, 2 or 4 Shifter cycles.
Experience also shows that if less than 4 words are required to complete the 4 words needed to produce Low resolution bitmap, the screen will start earlier by 12, 8 or 4 cycles depending on the words needed from the MMU.
Experience also shows that it is possible to force that buffered data out at least with some wake up states by means of the stabilizer (wake up 2 at least), forcing the Shifter to wait for new fresh 4 words from the MMU before displaying the bitmap.
There are some other possible impacts of having these old words inside the Shifter like vertical black bars: 16 pixels or bitmap, 16 black pixels. Again, this depends on internal Shifter start/reset cycle and it can not be detected by the SW. It can happen that for the same wake up state (1, 2, 3 and 4) we can have situations where the extra words at start lead to screen shift, lead to vertical bars, screen shift for line N and a diferent shift for line N+1, vertical bar for line N and a 16 pixels shifted vertical bar for line N+1 ...

There are at least 16 sweet spot timings in a normal hozintal line (512 cycles) where you can do effects: 5 with FFFF820A and 11 with FFFF8260 like Left Border, Right Border, stabilizer, BLANK line, 0 bytes line, start like if 60 Hz, end like if 60 Hz ... and i am counting of 1 for the dozens of 71/50 or 60/50 switches for each case.

For the purpose of 4 bit sync scrolling for normal screen, i have seen it work with wake up state 2 (most of the times), wake up state 4 (always), wake up state 3 (only once).
I have never seen it work for wake up state 1 (at least -4 shift never worked).


Sorry if you found this uninteresting.


Paulo.

[Dio]

Not at all. Next time I have the logic analyser on the ST I'll use your program and verify that the four wake up states correspond to the four different DE to screen start latencies that I observed last time I was investigating this issue.

I'm not certain there can be discrepancies because of the higher clock inside the shifter though. As each of the lower frequency clocks is dependent on the higher frequency one, synchronisation seems likely to be automatic to me. However, it may be clock skew effects - each fourth tick of the 32MHz clock must be a a few gate delays ahead of the 8MHz clock - assuming the clock dividers are just D-type flipflops in Shifter and MMU, the 8MHz clock is probably about 50ns behind. I haven't been able to get an exact figure for the skew on the analyser though - its resolution is only about the same as the skew, I really need a GHz digital scope to measure it properly.

Experience also shows that it is possible to force that buffered data out at least with some wake up states by means of the stabilizer (wake up 2 at least), forcing the Shifter to wait for new fresh 4 words from the MMU before displaying the bitmap.

There must be a simpler way the buffered data is cleared than just the stabiliser. Consider the 158-byte line case - that always flushes the Shifter's buffer, not reading the last word and generating no last 16 pixels on the line but otherwise starting the next line normally, no 4-pixel shift. This is the one I've been trying to understand, because it's a simple and predictable case and it always works. If that one can be worked out I think it should shine a lot of insight on exactly how the Shifter buffer clear works.

[ljbk]

There must be a simpler way the buffered data is cleared than just the stabiliser. Consider the 158-byte line case - that always flushes the Shifter's buffer, not reading the last word and generating no last 16 pixels on the line but otherwise starting the next line normally, no 4-pixel shift. This is the one I've been trying to understand, because it's a simple and predictable case and it always works. If that one can be worked out I think it should shine a lot of insight on exactly how the Shifter buffer clear works.

I am sorry to contradict you but my experience shows that the 158 bytes line or any of its variants (like 184) does not clear the incoming words.
I have a stable Degas Elite bee screen with one 158 bytes line (rest is 160 bytes at 50 Hz PAL) in front of me and i can see that the first 16 pixels of the screen are using data from the end of the pic (left in the Shifter).
Wake up state is 2.
How did i create this ?
I have a program where i can test and switch between different situations by pressing a F key.
If i do a 71/50 switch with 20 cycles between them at pixels 277 and 297 (16 cycles before 60 Hz RB switch and 4 after), i will get a 160 bytes line and an unstable screen with the several lines with different shift starts and planes (different number of words left in the Shifter at the end of the screen).
If i switch to the same situation but with a 60/50 switch, i will get the 158 bytes line and a stable screen.
The problem is that the screen will not always show the same: it will depend on the number of words that have been left previously inside the Shifter. I managed 3 different screens. I don't know why i can't get the 4th.
If the Shifter incoming registers would have been cleared then we would get always te same stable screen.
Don' t ask me why then the next line does not start "shifted" but i assume it has to do with the 60/50 switch effect inside the GLUE (HSYNC / DE timings).

The same strange situation occurs with the 204 bytes line (no right border). The 2 words (from the +44 bytes read) are kept inside the Shifter and used at the start of the next line but the screen does not start shifted by 8 pixels to the left.
Also that line without stabilizer does not clear the words as i can get different stables screens coming from an unstable situation.

Paulo.

[Dio]

OK, thanks for the update.

I'm not entirely clear what you're describing here. On what line is the 158-byte line? And you say it does wrap around to the top of the screen?

Raises more interesting questions. If that's the case, are demos that use the 158-byte line case to open the lower border (e.g. the BIG demo) do some changes during vblank that manage to force the shifter to flush? And given what we know about the internals of the ST, how is it possible for it not to shift the screen to the left if there are held words?

(My basic point still stands: if we can develop a detailed understanding of this most simple case - simple because it involves a single frequency change, which is in a Glue register only, and has no sensitivity to wake-up state - and I think it will shed a lot of light on the whole thing).

[ljbk]

Hello !

The test line is around line 24 or 25 counting from 0.
Line 0 is used for sync.
I have then a variable nop jump to allow me to start at a desired time spot during the line, a fixed delay of about 24 normal lines (to show the results of the test) with or not exg before the sync switch.
I have then a variable delay up to the second sync switch that can end or not with exg.
Then i have the second sync switch.
Then the rest are normal lines.
When some data was kept in the Shifter, i can see that the top corner is not white and the results part bitplanes are wrong (i see duplicated results ).


Meanwhile, i upload here the updated 4bit shifting bees with the new wake up detection.

Paulo.

[Dio]

Thanks. I shall muse on this.

[npomarede]

Hello

I tried beeshft0.prg on my PAL STF.

First, I don't really understand, how is it supposed to move the picture, what is the pattern ? It seems to scroll vertically, with sometimes a random 4 pixels scroll ?

As we know from your previous forest demo that 5 line vertical hardscroll is already possible, maybe this version should do only 4 pixels horizontal ? Given the results I have, it would be easier to follow I think, as I see some plane shifting but it's hard to know which scroll position is was.

Or maybe you could use f1-f4 to change only horizontal position and keep the same vertical position when scrolling is stopped with alt ?

For the results :

in STF(2) :
I get planes shifted in what seems to be 2 horizontal scrolling cases (maybe 8 and 12, can't really say, hard to see on my tv)

in STF(3) :
scroll 0, 8 and 12 seem to be stable. scroll 4 gives plane shifting (head of the bee is yellow), but it sometimes gives plane shifting + interlacing effect : even lines and odd lines are shifted in what seem to be 8 pixels on each line : all even lines are shifted 8 pixels to the right, relative to odd lines. For a few VBL, this interlacing effect seem to change, as if even lines were 8 pixels to the right, or odd lines were 8 pixels to the right. After a short while, it gets "stable", but the interlacing effect remains (as if 4 bytes remained at the end of each line, creating a scrolling only every 2 lines)

So far, I wasn't able to get STF(1) or (4), neither any result where all 4 horizontal scrolling position were good.

I wonder if some of the plane shifting I see are not due to the overscan combinations also used at the same time to scroll vertically ?
Maybe we could have a version where f1-f4 means no vertical scrolling at the same time to be sure 2 unstability causes are not combined ?

Nicolas

[ljbk]

Experience also shows that it is possible to force that buffered data out at least with some wake up states by means of the stabilizer (wake up 2 at least), forcing the Shifter to wait for new fresh 4 words from the MMU before displaying the bitmap.

There must be a simpler way the buffered data is cleared than just the stabiliser. Consider the 158-byte line case - that always flushes the Shifter's buffer, not reading the last word and generating no last 16 pixels on the line but otherwise starting the next line normally, no 4-pixel shift. This is the one I've been trying to understand, because it's a simple and predictable case and it always works. If that one can be worked out I think it should shine a lot of insight on exactly how the Shifter buffer clear works.

First i must correct my original statement that is not correct.
The buffered data can not be forced out.
What the most used stabilizer does it that no matter the number of words in buffer, the next line will start unshifted.
Line 158 case causes 1 word to remain in buffer but the next line to start unshifted IF when arriving to that line 158 the number of words in buffer was 0 and the line started unshifted and the Shifter was not drawing black columns and we are in wake up state 2.
IF in wake up state 2, with the Shifter not drawing black columns, we get to line 158 with a variable number of words in buffer and a variable screen shift then after line 158 we will not get always the same situation. This is why line 158 is not a stabilizer one.

[Dio]

I'm not so concerned about its use as a stabiliser, just the case where it's used to remove the lower border with (as I thought) no sideeffects. I'm looking for the very simplest cases to investigate here .

[ljbk]

I'm not so concerned about its use as a stabiliser, just the case where it's used to remove the lower border with (as I thought) no sideeffects. I'm looking for the very simplest cases to investigate here .

Ok, but the situation is the same.
At line 199, in a normal line with a normal Shifter status (no shift and no black columns), you switch to 60 Hz before the right border spot and 4 things probably happen:

1- The GLUE detects 60 Hz at the end of the timing of the NTSC screen, and disables the DE signal 4 CPU cycles early;
2- The Shifter is expecting a 4th word from the MMU to build the last 16 pixels of the line but that word does not arrive because the MMU does not get the DE signal active it needs from the GLUE to allow the memory reading and so the set of 4 words remains incomplete. The internal Shifter shifting registers are probably not loaded and we get border color instead of 16 bitmap pixels;
3- The GLUE detects 60 Hz at the end of the normal PAL screen and is lured to think it is in NTSC and opens the lower border proceeding with new DE signal on the next line;
4- The Shifter starts the next line with some words in the buffer but with an internal status of "no shift" and so the line starts at the normal place and the 3 words in buffer are not displayed otherwise we would get a -12 shift;

Paulo.

[ljbk]

I tried beeshft0.prg on my PAL STF.

First, I don't really understand, how is it supposed to move the picture, what is the pattern ? It seems to scroll vertically, with sometimes a random 4 pixels scroll ?

The movement should be vertical (up/down) and from time to time shifting: -12, -8, -4, 0, 0, -4, -8, -12
You can watch it here:
http://www.youtube.com/watch?v=ThA6iCyKfqU

As we know from your previous forest demo that 5 line vertical hardscroll is already possible, maybe this version should do only 4 pixels horizontal ? Given the results I have, it would be easier to follow I think, as I see some plane shifting but it's hard to know which scroll position is was.

Or maybe you could use f1-f4 to change only horizontal position and keep the same vertical position when scrolling is stopped with alt ?

As far as i know, 4 bit shifting displaying correcly the picture (without bitplanes switched) is not possible without sync scrolling because you need to treat the extra words in the Shifter that come from one VBL frame to the next VBL frame.
If you don't want the sync scrolling then you should use the TOS shifting program and check the wake up state with WAKE_UP.TOS or i can update that TOS shift program with the new wake up detection.

4BIT.PRG will give the following results:
-1 => no shift => GREEN TOS DESK;
-2 => 4 pixels shift => BLUE TOS DESK;
-3 => 8 pixels shift => GREY TOS DESK;
-4 => 12 pixels shift => RED TOS DESK;

If you see black columns, interlaced shifting or do not see the refered TOS DESK background colours when starting from original TOS colours in Low Resolution then that shift is not working for your machine and wake up state at that time.

For the results :

in STF(2) :
I get planes shifted in what seems to be 2 horizontal scrolling cases (maybe 8 and 12, can't really say, hard to see on my tv)

in STF(3) :
scroll 0, 8 and 12 seem to be stable. scroll 4 gives plane shifting (head of the bee is yellow), but it sometimes gives plane shifting + interlacing effect : even lines and odd lines are shifted in what seem to be 8 pixels on each line : all even lines are shifted 8 pixels to the right, relative to odd lines. For a few VBL, this interlacing effect seem to change, as if even lines were 8 pixels to the right, or odd lines were 8 pixels to the right. After a short while, it gets "stable", but the interlacing effect remains (as if 4 bytes remained at the end of each line, creating a scrolling only every 2 lines)

So far, I wasn't able to get STF(1) or (4), neither any result where all 4 horizontal scrolling position were good.

I wonder if some of the plane shifting I see are not due to the overscan combinations also used at the same time to scroll vertically ?
Maybe we could have a version where f1-f4 means no vertical scrolling at the same time to be sure 2 unstability causes are not combined ?

Ok, first i wonder why i did not get wake up state 1.
I know that your STF is from another revision than mine.
I hope that there are not 820A and 8260 different timings for the same HW conditions (unsync between chips) with your machine compared to mine.

Second, i wrote that it worked on my machine most of the times in wake up state 2 not always as until now in wake up state 4.

Third, results with wake up state 3 are as mine.

But let's talk a bit more about the Shifter.
Experience shows that there are several visible effects on screen possible out of Shifter unstability when displaying a normal 160 bytes line in PAL:
1- black 16 pixels columns appeared interlaced with 16 bitmap pixels;
2- screen shifting occurs at -12, -8, -4 due to having 3, 2 or 1 word in the buffers when starting the line;
3- interlaced screen shifting occurs (one line at a position a the new line at another position);
4- no screen shifting occurs despite having words in the buffer at the end of the display of the previous line (158 and 204 lines case): either the 1 and 2 words respectively have been thrown away at the end of the line or a "no shift" condition is present leaving the words to be scrapped and the screen to be started at the normal position;
We can define that as Shifter_draw_status(draw_columns, shift_status, words in buffer).

Normal case is of course (false, no_shift or shift, 0).

What we need are cases:
- (false, no_shift or shift, 0) : position 0;
- (false, shift, 1) : position -4;
- (false, shift, 2) : position -8;
- (false, shift, 3) : position -12;

Those 4 cases but be self sustained if only 160 lines are drawn. That is why i showed that TOS can sustain this.

What is needed for a correct 4bit normal screen scrolling:

1- An unstabilizer method that can provide the 4 cases described above starting from a normal situation, for all wake up states, without having to do sync switches at every line otherwise we use Alien 4bit method;

2- A sync scroller set of lines that provides, for all wake up states, a way to control the low byte from the screen offset and enters the unstabilizer drescribed above with a normal Shifter condition (false, no_shift or shift, 0);

There are many unstabilizer methods. We can say that almost any sync switch provides some kind of unstability.
The TOS shifting and Bee shifting programs use similar methods but not exactly identical based on a switch from low to medium followed from a switch from medium to low while the MMU is reading the data and the Shifter is displaying it.
The distance in clocks between the two switches defines the number of words in buffer an so the following screen shift.

The most common stabilizer has proved to work as required, at least in wake up state 2, as long as the Shifter is displaying data at the time. So if the right border is open and we do the 71/50 switch corresponding to the stabilizer then the following 160 bytes line will start unshifted from the normal place:

Shifter status at the end of the line:
- (false, no_shift or shift, 0) : position 0;
- (false, shift, 1) : position -4;
- (false, shift, 2) : position -8;
- (false, shift, 3) : position -12;

will be:
- (false, no_shift, X) : position 0;

when starting the next one.

So, the TOS shift program only consists of:
- a 204 bytes line with stabilizer;
- a 160 bytes line with a LOW/MED/LOW unstabilizer during screen display;

The Bee shift program consists of:
- 5 variable lines to control the byte offset where the last unstabilizing line has a stabilizer;
- a 160 bytes line with a LOW/MED/LOW unstabilizer during screen display at a slight different position;


What are the results ?

Sometimes, we get columns for some positions especially in wake up state 1, 3 and less often in 2.
Sometimes, we get interlaced shifted lines for some positions.
Sometimes, it works !

As there are many unstabilizer methods and also several possible stabilizer methods and 4 wake up states, some giving different results probably depending on SW undetectable Shifter wake up states for the same main wake up state, and as each different byte lengh line provides its own unstabilizing effect, this is a work in progress that can be resumed like a set of the possible following functions:
Input_Shifter_Status -> [820A switch or 8260 switch at a MMU timing for one of 4 wake up states] -> Output_Shifter_Status

Describing these functions depending on each possible input case is required to get this feature to work better.
Considering that there are now 13 (yes, i found a new one) different lines with different byte sizes and 4 wake up states and several possibilities for each of those 13 lines and sync switches, the amount of work expected is quite important.

By the way, one thing i detected is that the disk drive effects and the Spectrum 512 flickering pixels tend to stabilize after some time of the machine running (you either get stable funny pixels ot normal pixels) in wake up state 2. May be it has to do with the Shifter internal clock status reaching a stable point.


Paulo.

[Dio]

1- The GLUE detects 60 Hz at the end of the timing of the NTSC screen, and disables the DE signal 4 CPU cycles early;

I assume this is the case; I can show this one on the logic analyser.

2- The Shifter is expecting a 4th word from the MMU to build the last 16 pixels of the line but that word does not arrive because the MMU does not get the DE signal active it needs from the GLUE to allow the memory reading and so the set of 4 words remains incomplete. The internal Shifter shifting registers are probably not loaded and we get border color instead of 16 bitmap pixels;

They're definitely not loaded; the last 16 pixels are lost and border colour.

4- The Shifter starts the next line with some words in the buffer but with an internal status of "no shift" and so the line starts at the normal place and the 3 words in buffer are not displayed otherwise we would get a -12 shift;

Right, the 'words to read before transfer to shift regs' counter must be set to 0 somewhere between the end of the previous line and the start of the next. But this (probably?) isn't caused by any register write because it (probably?) doesn't snoop FF820A. So the condition that causes it must be deducible from the external signals presented to the Shifter (and there aren't many; the only control logic is CS, R/W, LOAD and DE). My suspicion is that it is something to do with DE, since I can't actually understand why the Shifter needs to see DE. I have quite a few STs in the spares box now, and I'm probably going to do some experiments cutting the DE pin and seeing what happens.

The VHDL for the Suska project implies some of this:

Code: Select all

	-- This process is responsible to synchronise the load cycle during
	-- the horizontal sync pulse and to control the cycle during video
	-- data transfer from the MMU to the SHIFTER (DE = 1).
	variable LOCK: boolean;
    begin
    	wait until CLK = '1' and CLK' event;
		if DE = '0' and SHFT_STRB = '1' then
            LOAD_CYCLE <= C4;
         ...

My VHDL isn't quite up to understanding the SHIFT_STRB logic well - the implication is that it's set once per 4 clock cycles in low res, which given the code above doesn't seem to fit the observable behaviour - and it is further confused by the additional resolutions that the VHDL supports.

[npomarede]

The VHDL for the Suska project implies some of this:

Although it's always interesting to look how other projects are trying t emulate the ST in HW instead of SW, last time I looked at the VHDL code, my feeling was that it was a very basic implementation of the shifter, not emulating all known effects used in demos. My guess is that they're adapting their VHDL code to run as many demos as possible, but I don't think they do it using informations we don't know yet.

Nicolas

[Dio]

I know some of the people working on VHDL have done it by side-by-side-ing with an existing chip and verifying the exact same signals come out of the FPGA as the original chip when presented with the same inputs.

But I agree that even if that's the R&D technique there's no guarantee that all the internal cases have been covered; in addition, it's unclear exactly what ST the results are being compared with. I've been using it to guide research rather than taking it as gospel.

[npomarede]

I know some of the people working on VHDL have done it by side-by-side-ing with an existing chip and verifying the exact same signals come out of the FPGA as the original chip when presented with the same inputs.

But I agree that even if that's the R&D technique there's no guarantee that all the internal cases have been covered; in addition, it's unclear exactly what ST the results are being compared with. I've been using it to guide research rather than taking it as gospel.

In the end, having different projects and different research directions is interesting and can help shed some new light, but regarding the YM and the FDC emulation for example, even if they got the same results as the original chip in their comparisons, some cases were missing last time I checked (15 volume table instead of 31 for example, some fdc timings, ...). It's hard to design some tests that cover all the known and not-so-known behaviours to do a side by side comparison, but studying these from the HW point of view with signal analyzer and SW point of view with some repeatable tests can certainly help understanding the inner work.

[ljbk]

Hi !


Just something to think about.

As i explained before there are two sets of $FFFF820A timings the early_820A (wake ups 1 and 3) and the late_820A (wake ups 2 and 4) with the main difference a delay of 2 cycles in the MMU in the first case compared to the GLUE as we see the "normal" screen shifted by 2 pixels to the right.
This means that for one of the two cases the GLUE will create transitions in the DE signal while the MMU is feeding the Shifter with bitmap data. That is especially the case at the spots for the 158 bytes line and 4 CPU cycles later for the right border openning.
Now imagine what can be the different behaviours of the DE slave chips (MMU and Shifter) if while doing a word copy the DE changes. May be everything is taken care (maybe with other signals by the GLUE) and the word copy always happens before or after a possible change in the DE.

Another interesting thing to be observed with a logic analyser is the 0 bytes lines.
Is the DE started at all by the GLUE or only for 2 CPU cycles not giving time to the MMU to transfer any word to the Shifter ?


Paulo.

[Dio]

Wake-up states aren't relevant to the 158-byte case though - it just works on all STs (even the STE I think).

The one thing I do know is that the minimum DE to LOAD latency is 3 CPU clock cycles (since the four wake up states have latencies of 3, 4, 5 and 6 between DE and the first LOAD). I measured that on the logic analysed last year. My presumption is that the MMU samples DE in order to decide if the next MMU phase is a video or refresh phase probably 2.5 CPU clocks before the LOAD occurs (other options include 3 or 2, if the logic relies on setup time, or maybe even 2.25 or 2.75 if the MMU is using both edges of the 16MHz clock as a timing reference).

When it comes to zero-byte lines, that predicts that:
- if there is no DE at all, a zero byte line can be generated in all wakeup states.
- otherwise to generate a 0 byte line the DE pulse must last 2 clocks, and it will only work in two of the wakeup states (where the DE to load latency is 5 or 6 cycles)
- in the other two wakeup states (3 and 4 cycle DE to load latency), or if the DE pulse lasts 4 clocks, it should generate a two-byte line instead

Last time I had the analyser on I didn't have the software to hand to generate the various special cases on demand. As you say, it's worth checking what DE actually occurs.

[ljbk]

Hi !

0 bytes lines with border color instead of bitmap are possible for all 4 wake up states i defined with my machine.
You can get them with a 71/50 switch or with a 60/50 switch aproximatly at the same MMU time spot:
- 3 different time spots for 71/50: early (W1), middle (W3 and W4) and late (W2);
- 2 different time spots for 60/50: early (W1 and W3) and late (W2 and W4);

I have never managed a 2 bytes line.

At the moment, i can have for all 4 wake up states the following line lengths for which i can later on provide SW for you to test:
1- 0;
2- 14 (NEW);
3- 54;
4- 56;
5- 80;
6- 158;
7- 160A(normal) and 160B(start and end like NTSC but in PAL);
8- 162;
9- 184;
10- 186;
11- 204;
12- 206;
13- 230;


Paulo.

[Dio]

If someone else has written the software, I'll gladly not do it myself .

I was wrong to think a 2-byte line is possible. It's the 162-byte line I was thinking of. I'll look at defining a set of 16 signals that I can capture for each of these cases which will provide us with useful data to consider; I will also try to work out a setup for measuring when hsync starts with each of these cases (trickier to capture, it can't just be intercepted on the leg of a DIP IC).

Something else worth considering measuring (which can be measured in software, or I can extract it from DE on the analyser) is the horizontal period in each of these cases.

[AtariZoll]

I think I have to give up this project since it seems to be to difficult. I have only used Easyrider and it needs a file to dissamble.

Well, there is another way to make some not to extensive changes in games: instead disassembling, what needs really lot of time, study code and find relevant parts, then add new code for movement, with scroll, in free RAM (there is always little free space in 512K. Or above 512K if no other way), and just put jumps, jsr from game code to new routine(s) .
Of course, this is not easy too, but surely much less time needed.

[nativ]

rip all data then make a new one!! probably easier!

[Dio]

At the moment, i can have for all 4 wake up states the following line lengths for which i can later on provide SW for you to test:

One thing worth doing is during the test make sure the colour output conveys some useful information: if I capture one bit each of RGB then there's 8 different states that can be communicated. Something like border red, screen green would be nice and clear (and allow easy distinguishing of any rogue 0's output). Albeit hard on the eyes .

I reckon the signals list is DE, LOAD, CS, RW, R2/G2/B2 at shifter, HBLANK at the monitor port or the clock nudger, BLANK will have to be on one of the diodes, RAS/CAS off the DRAM to help label which phase the MMU is on and DTACK, CLK and A23 (to allow the writes to the sync reg to be spotted) at the CPU. Two free if we can think of anything else.

[ljbk]

At the moment, i can have for all 4 wake up states the following line lengths for which i can later on provide SW for you to test:

One thing worth doing is during the test make sure the colour output conveys some useful information: if I capture one bit each of RGB then there's 8 different states that can be communicated. Something like border red, screen green would be nice and clear (and allow easy distinguishing of any rogue 0's output). Albeit hard on the eyes .

That can be arranged .

I reckon the signals list is DE, LOAD, CS, RW, R2/G2/B2 at shifter, HBLANK at the monitor port or the clock nudger, BLANK will have to be on one of the diodes, RAS/CAS off the DRAM to help label which phase the MMU is on and DTACK, CLK and A23 (to allow the writes to the sync reg to be spotted) at the CPU. Two free if we can think of anything else.

Considering the effects that can be triggered by the SW, i would advice to check carefully the BLANK signal and the HSYNC signal as you can have:
- BLANK with any line length with MMU reading;
- BLANK on the right side of the screen only;
- BLANK with 0 bytes line and MMU not reading;
- BLANK and screen scrolled one line down (no line at all);

Please tell me when you need those PRGs, including the number of "special lines" you need per screen (199, 10, 1 ...), or send me a PM when the time is right for you.

Paulo.

[Dio]

Whenever it's done is fine, my interest is currently piqued and I've tidied the office enough to get all the bits out of the garage .

One line per frame, with the shifter reset at VSYNC, is ideal. Doesn't really matter what line it's on. I just need an easy triggering condition. I was going to look for writes with A23 set, so keeping the count of those down (I imagine a few to reset the shifter and then the test) will be good.

[Steven Seagal]

@ljbk
Just to mention it, there's kind of preliminary support for beeshift in Steem SSE 3.5.2 if you choose "wake-up state 2".
It works with the previous version "5", but with the latest version "0", the program doesn't detect "WU state 2", it does state 1, but then it's garbage because Steem emulates the shifts only in "WU state 2" for now.