horizontal scrolling on ST

[calimero]

As far as i know, the SW can not influence the hardware wake up states. It can detect them and eventually handle them.

how can you detect wake up state??

you can expose wake up state to user but you can not detect it by software. right?

[dml]

As far as i know, the SW can not influence the hardware wake up states. It can detect them and eventually handle them.

how can you detect wake up state??

you can expose wake up state to user but you can not detect it by software. right?

I would speculate that if the CPU is delayed by 1 or more clocks in state 1 (vs state 0) then it can be raced against another hardware state or event in some way. There will be one instruction missing from a video frame (well, skewed so one drops off the end) or something to that effect? Not sure of the details but trying to schedule something near the end of the display or end of a line, and running out of time could form a basis for detection. The trick would be to avoid relying on the same device (e.g. video) for synchronizing the start of the detection. So it probably has to involve 2 different devices - video and MFP - one to sync the CPU, one to race against.

I don't know the answer but I'd be looking in that area if I was going to try.

[ljbk]

As far as i know, the SW can not influence the hardware wake up states. It can detect them and eventually handle them.

how can you detect wake up state??

you can expose wake up state to user but you can not detect it by software. right?

Hi !

Go here:
http://dhs.nu/files.php?t=single&ID=136

I offered this source code to the community quite a while ago.
If you dig around my posts and ijor posts from 2006 in this forum you will find the same stuff.
Search for wake up state ...

Paulo.

[calimero]

^
I read thread about Wake Up states but I did not understand that you find way to software detect in which state ST is booted?!

Petari try to figure out how detect boot state: http://forum.8bitchip.info/software-17/ ... lp-please/

if you did find way, can you explain idea/principle in few words? (I am really not good in reading asm.)

[ljbk]

^
I read thread about Wake Up states but I did not understand that you find way to software detect in which state ST is booted?!

Petari try to figure out how detect boot state: http://forum.8bitchip.info/software-17/ ... lp-please/

if you did find way, can you explain idea/principle in few words? (I am really not good in reading asm.)

Hi !

I already had a chat via email with him.
This is something else: another type of hardware wake up state. That problem is related to changing the colors on the fly and the chips are not synched as usual and some funny color dots appear. This is the well know Spectrum 512 funny dots problem because this was when it appeared.
As far as i know, that one can not be detected by the SW.
The one that can be is the one related to sync switches.
Depending on that wake up state, a sync switch to remove a border or to do another effect will work or not at specific pixel equivalent location.
So you just have to set up one or several sync switch tests. One response pattern corresponds to a STF waking up in state 1. Another one corresponds to a STF waking up in state 2.
From that moment on you know the code to apply to the machine your program is running on.
This is the only way i know to have a 4 line ( sync + 3) sync scroller ...

Paulo.

[calimero]

^
I did not realize that there is ANOTHER wake up state problem!

one funny solution come across my mind regarding spectrum-512-wake-up state:
you could draw TWO simple message on screen:
"PRESS LEFT SHIFT TO CONTINUE" and
"PRESS RIGHT SHIFT TO CONTINUE"
but one that will be visible in first wake up state, and other visible in second so you will see always ONE message on screen.
and depending from user keystroke you will branch your program accordingly

[Dio]

I'm not sure that those are two different cases. Although it's possible: I've shown with a logic analyser that there are 4 different wake up states, they correspond to the cycles of latency from DE being asserted by Glue to MMU issuing the first video access cycle. The two states that can be detected in software correspond to the latency being 3 or 4 vs. 5 or 6, because both chips have a 4 (8MHz) cycle state machine and the state counters aren't reset, but the CPU can read and write the syncmode register on a 2-cycle boundary rather than a 4-cycle boundary in the ST (but not the STE).

[ljbk]

As far as i remember (again i would have to digg in my reasearch from 2006), you can have the funny dots both in wake up state 1 and 2.
On top of that, you can have flashing dots: sometimes they show one color and some other time they show another color and that can change without cold reset to your STF. Sometimes it depends if the disk drive motor is running or not. This looks to be a similar behavior to the fullscreen mode failing to show some groups of 16 dots along the line. Sometimes it happens for all lines. Sometimes only for some. In those cases you see 16 pixels of bitmap then 16 black pixels and so on. But the video counter is ALWAYS incremented in the normal way no matter any of those effects hapenning.
When this happens the solution is to cold reset and hope the result will correspond to a stable situation.
By stable situation, i mean a case where you will not have any flashing, no matter if it is related to dots or fullscreen.
There is of course a way to overcome the color problem. You should not use the logical color that is changing for the transition pixel. Example: you should not use logical color 1 for the 5th pixel starting from the left in a Spectrum 512 pic.
Of course Spectrum does not care about this. But if you build a color converter let's say from BMP to SPU, then you can take this into account.


Paulo.

[dml]

There is of course a way to overcome the color problem. You should not use the logical color that is changing for the transition pixel. Example: you should not use logical color 1 for the 5th pixel starting from the left in a Spectrum 512 pic.
Of course Spectrum does not care about this. But if you build a color converter let's say from BMP to SPU, then you can take this into account.

That is exactly how I dealt with it when I first noticed what was happening (sometime around '92 I think).

[Dio]

If it changes on a dynamic basis, it's nothing to do with the wakeup state. Perhaps more likely then is a setup time violation somewhere in the chipset, so sometimes something clocks on time and sometimes it clocks a cycle later.

This can be seen on the Spectrum, for example, because INT is asserted only 40ns earlier than the signal is tested despite requiring a setup time of 80ns. Most Z80s respond in time but some don't, and others can change from one mode to the other as the machine warms up.

[ljbk]

I will share that if i resume that research, because those tests were left unfinished and not so well organized as my 25+ years old sources
I can't share that at the moment because i would have to look where exactly are the files that do that in the hundreds of sync tests i have done in 2006. Doing this is the same as to resume the research with some ideas i have in my head .

But for the moment i am ST-busy with Hextracker as i have a lot of features and ideas i would like to include.

Paulo.

Ok, no problem.
I'll try to be here at the right time to see what you achieved on this subject and speak about it with you.

Remember the 4 bit sync scrolling by Alien in 1991 (Let's do the Twist in PYM) ?
That technique only works with fullscreen lines no left/no right border and does not work on STE.

For years, starting in the late 80s, i noticed that in some cases after the sync switches occured and bug happenned in the program when returning to TOS the screen was sometimes shifted and the bitplanes changed in a full border (normal) screen.

I tried for years, to manage to understand this and to produce a program that would be able to generate each shift but there was always one case missing. Last time i tried was in 2006 and then again i managed the 4 shifts in 1 wake up state but only 3 shifts in the other one.

Well this quest has finally ended !
I can now shift an entire screen by 0, 4, 8 and 12 pixels with 1.5 scan lines on my STF in both wake up states.
This means that a sync scrolling hardscroll with a 4 pixel granularity should be possible with 5.5 scan lines maximum: 4 to set the offset and 1.5 to set the 4 bit shift.
As for Alien technique, you need a video memory for each of the 4 possible shifts and 4 bitplane orders.
The only advantage of this over classic hardscroll is that you don't need to pre-shift the input data on the left or on the right depending if the screen goes left or right. You just feed it with a new 16 bit word. So you save a bunch of memory.
On the other hand, if you do nothing you will see a bit of flickering on the left and/or right of your screen because it is your screen that is really moving left or right, so you have to reduce the size of your screen to 320 - 12 = 308 pixels and to the proper masking with some ANDs for these extreme left and right 16 pixels if you want to hide this.

I guess this probably does not work on STE, but that machine does not need it.
On my STF, the machine needs to be really well synchronized. It can happen that normal fullscreen works and this does not.

Of course emulators do not support this !!!

Have fun !
Paulo

[npomarede]

Hello
I tested your program on my French PAL 520 STF,and unfortunately, it doesn't work I get planes shifting, but no 4 pixels shift with correct color (I started the prg in low res) :

Using wakeup.tos to check the wakeup state :
- in wakeup 2 (warm), key 1 restores the screen to normal, keys 2,3 and 4 shift planes when back to TOS
- in wakeup 1 (cold), key 1 restores the screen, key 2 gives the same result as 1, keys 3 and 4 shift planes

So, I'm afraid the quest is not over yet

Nicolas

[ljbk]

Hello
I tested your program on my French PAL 520 STF,and unfortunately, it doesn't work I get planes shifting, but no 4 pixels shift with correct color (I started the prg in low res) :

Using wakeup.tos to check the wakeup state :
- in wakeup 2 (warm), key 1 restores the screen to normal, keys 2,3 and 4 shift planes when back to TOS
- in wakeup 1 (cold), key 1 restores the screen, key 2 gives the same result as 1, keys 3 and 4 shift planes

So, I'm afraid the quest is not over yet

Nicolas

Well, maybe there is a mis-understanding here:
The TOS screen should appear shifted and with different colors: 1 is normal green.
In the other cases, as the bitplanes order is changed, the colors change and you get grey with 4 for example.

0010 Green

0001 Red

0100 Blue

1000 Grey

I do not change the bitmap in the video memory.

My machine wakes up more than 90% of the times in wakeup 2, so i made sure that this was working on wake up state 1 for my machine as long as it is perfectly synchronized.

Now, if this does not work on all STFs, there is not much i can do because it works on mine and i have no other to test.

Paulo.

[npomarede]

Well, maybe there is a mis-understanding here:
The TOS screen should appear shifted and with different colors: 1 is normal green.
In the other cases, as the bitplanes order is changed the colors change and you get grey with 4 for example.

0010 Green

0001 Red

0100 Blue

1000 Grey

I do not change the bitmap in the video memory.

My machine wakes up more than 90% of the times in wakeup 2, so i made sure that this was working on wake up state 1 for my machine as long as it is perfectly synchronized.

Paulo.

Yes, I misunderstood, I thought pixels would be shifted and color would be correct.
As it quite difficult to see how many pixels were shifted when back to TOS when color are also mixed, maybe you could do a version that doesn't exit when pressing 1 to 4, but apply the med/lo switch to the current screen and move the plane also to keep correct color (maybe with a small pattern to fill a part of the screen, to really be able to see the changes on the screen)

Nicolas

[dml]

Very cool. Impressive to see these things surfacing after so many years

[ljbk]

Yes, I misunderstood, I thought pixels would be shifted and color would be correct.
As it quite difficult to see how many pixels were shifted when back to TOS when color are also mixed, maybe you could do a version that doesn't exit when pressing 1 to 4, but apply the med/lo switch to the current screen and move the plane also to keep correct color (maybe with a small pattern to fill a part of the screen, to really be able to see the changes on the screen)

Nicolas

Well, i did it like this to show that the Shifter change is self sustained.
I will try to do another version of this later that shows the wake up state detected and that offers the possibility to delay one of switches to a bit later in the 2nd scan line to see if it works on more machines.
Of course the best would be to have a real intro screen to take advantage of this but this will be impossible in the next weeks.

Paulo.

Edit:
Here is another version (V05) with the second line switch delayed by 20 cycles (5 nops).
May be your machine prefers this one .

[npomarede]

Yes, I misunderstood, I thought pixels would be shifted and color would be correct.
As it quite difficult to see how many pixels were shifted when back to TOS when color are also mixed, maybe you could do a version that doesn't exit when pressing 1 to 4, but apply the med/lo switch to the current screen and move the plane also to keep correct color (maybe with a small pattern to fill a part of the screen, to really be able to see the changes on the screen)

Nicolas

Well, i did it like this to show that the Shifter change is self sustained.

You could have a version that doesn't exit when pressing 1-4 (and adapt a pattern on screen to show that the shifting is taking place), and once you press another key, the program exits without restoring anything in the shifter.
I did this to test all the overscan types on STF and under Hatari : I draw a small vertical line at different position and for different line length. When you display the screen is looks like random pattern, because each line is 160 bytes, but when you enable all the different overscan combinations on each line, all the vertical pattern of each combination get aligned in a single big vertical line, which confirm everything is working correctly (or is correctly emulated). This is much simpler than writing a small intro and give an immediate visual output.

I will try to do another version of this later that shows the wake up state detected and that offers the possibility to delay one of switches to a bit later in the 2nd scan line to see if it works on more machines.
Of course the best would be to have a real intro screen to take advantage of this but this will be impossible in the next weeks.

Paulo.

Edit:
Here is another version (V05) with the second line switch delayed by 20 cycles (5 nops).
May be your machine prefers this one .

Thanks, I will test it later.
By the way, do you think these med/lo switches that need to be done on cycles X could be delayed on cycles X+16*n ? The shifter's state should be the same every 16 cycles, so it should work (but this line would be altered in a different way) ? Or does it really need to be done on the beginning of the line ?

Is the right border removal + stabilizer the trick to make it work in a stable way on the whole screen ?

Nicolas

[ljbk]

You could have a version that doesn't exit when pressing 1-4 (and adapt a pattern on screen to show that the shifting is taking place), and once you press another key, the program exits without restoring anything in the shifter.
I did this to test all the overscan types on STF and under Hatari : I draw a small vertical line at different position and for different line length. When you display the screen is looks like random pattern, because each line is 160 bytes, but when you enable all the different overscan combinations on each line, all the vertical pattern of each combination get aligned in a single big vertical line, which confirm everything is working correctly (or is correctly emulated). This is much simpler than writing a small intro and give an immediate visual output.

I just wanted to make a very simple program that shows the thing working and standing.
I have such a program to test every time position for the type of switches i want to do.
Hatari does not support some of the possible things like:
- right border removal with 71/50 switch;
- Blank line with 60/50 switch (used here: http://pouet.net/prod.php?which=53126 in the first lines (source available at DHS) and in the Overscan Demos (F6 screen big scroll (top of the screen flickering pixels));
- Blank line with 71/50 switch;
There i have only to press F7/F8/F9/F10 to see the Degas Elite Bee moving left and right and changing colors;

I can provide you later a list of the effects possible on my machine and the respective timings in both wake up states.

By the way, do you think these med/lo switches that need to be done on cycles X could be delayed on cycles X+16*n ? The shifter's state should be the same every 16 cycles, so it should work (but this line would be altered in a different way) ? Or does it really need to be done on the beginning of the line ?

Is the right border removal + stabilizer the trick to make it work in a stable way on the whole screen ?

More than getting the thing to work, the important thing is to understand what we are doing.

One of 71/50 switches in a fullscreen like code is called a stabilizer. That thing like resets the Shifter reading bitplanes because it read some words it could not use to display bitmap.
But our goal here is to leave the Shifter with predefined number of words in the pocket when it starts to display the screen:
- 3 (screen shifted by 12 pixels because only 1 word will be read before the 4 are available to draw the bitmap);
- 2 (screen shifted by 8 pixels because only 2 words will be read before the 4 are available to draw the bitmap);
- 1 (screen shifted by 4 pixels because only 3 words will be read before the 4 are available to draw the bitmap);
- 0 (screen shifted by 0 pixels because the 4 words will be read to draw the bitmap);
In order to have always the same unstabilizer code (MED/LOW switch), you need the situation to be stable before: so you need the stabilizer.
Guess what, the stabilizer only really works you get to that time stamp in the line drawing and the Shifter is reading data. The only way to have that for sure AND to avoid that the previous unstable situation will become stable with the 1st line of the next frame is to have no right border.
The unstabilizer code will work at any place during the drawing of the 2nd line. The code provided in the 1st program is the first possible position for my machine. You can delay the "jsr (a4)" by 1 nop, 2 nops, ... 5 nops (like in V05) ... 20 nops up to around 7x nops.
There will be visual impact but we can BLANK the lines with the respective 60/50 switch.
The first words used for the first 16 pixels of the screen will come from the top of the video memory !!!
Another problem with this is that there is no easy way for the SW to guess if the Shifter is in that situation or not but it might be possible.

I hope this was not too boring.

Enjoy,
Paulo.

[npomarede]

I just wanted to make a very simple program that shows the thing working and standing.
I have such a program to test every time position for the type of switches i want to do.
Hatari does not support some of the possible things like:
- right border removal with 71/50 switch;
- Blank line with 60/50 switch (used here: http://pouet.net/prod.php?which=53126 in the first lines (source available at DHS) and in the Overscan Demos (F6 screen big scroll (top of the screen flickering pixels));
- Blank line with 71/50 switch;
There i have only to press F7/F8/F9/F10 to see the Degas Elite Bee moving left and right and changing colors;

I can provide you later a list of the effects possible on my machine and the respective timings in both wake up states.

Are you sure you tested this with latest Hatari 1.7 ?
- right border removal : there's a case for this, but it's the one used in enchanted land. Maybe not the same as yours. As far as I know, no demo uses this switch so far.
- blank line with 60/50 : it works for me in Overscan Demos, no flickering pixels
- blank line with 71/50 : there're 2 versions of this in Hatari, one at the beginning of the line and one near cycle 500 (used in "No Buddies Land")

It's possible you have other timings for these effects ; but so far, I only added in Hatari timings that I could verify by running the corresponding demo/game.
Of course, if you can provide a program to check these cases, I will add them to Hatari (as well as testing them on my STF)

Nicolas

[ljbk]

Hi Nicolas !

In order to help you we need to use the same pixel / timing concepts.
I use the one related to the Spectrum 512 color changing.
When i do:

lea $FFFF8209.w,a0
moveq #32,d0
wscreen:
tst.b (a0)
beq.s wscreen
sub.b (a0),d0
lsl d0,d0
...

the last lsl used to sync with the electron will end its execution at pixel 053.
In order to open the right border using a 60/50 switch, the change to 60, has to occur precisely at pixel 293 to work with both wake up states.
In wake up 2, it can also occur at pixel 295 (exg or similar non multiple of 4 cycles instruction before the 60 switch).
In wake up 1, it can also occur at pixel 291 (exg or similar non multiple of 4 cycles instruction before the 60 switch).
If you do it at pixel 291 in wake up state 2 like Leonard does in part of the Nostalgic Main Menu, it will not work.

If you can translate that 293 to your timing then you will be able to translate all other infos i can give to you.
The Blank 60/50 switch is done for example at pixel -55(60) and back to 50 at pixel -47 but there are more possibilities.

Just tell me if you can translate this to your units (cycle number).

I will have a two weeks break now.
We can talk about that later and i can provide to you via email the program i refer.

Paulo.

[npomarede]

Hi Nicolas !

In order to help you we need to use the same pixel / timing concepts.
I use the one related to the Spectrum 512 color changing.
When i do:

lea $FFFF8209.w,a0
moveq #32,d0
wscreen:
tst.b (a0)
beq.s wscreen
sub.b (a0),d0
lsl d0,d0
...
the last lsl used to sync with the electron will end its execution at pixel 053.

Hello
under Hatari (and it would be the same under Steem, which also uses cycles since beginning of the line to check for shifter's timings), I get this for the sync code :

cpu video_cyc= 32352 96@ 63 : $0129f8 : 9c10 sub.b (a0),d6
IO read.b $ff8209 = $12
cpu video_cyc= 32360 104@ 63 : $0129fa : ed6e lsl.w d6,d6
cpu video_cyc= 32396 140@ 63 : $0129fc : 2291 move.l (a1),(a1)

So if the instruction after lsl is at pixel 53 for you, it means cycles 140 for me. As 1 cycle is 1 pixel, we would get :
cycle_hatari = 87 + pixel_paulo

But this doesn't seem to match with right border example you give ; most demos will do this to remove right border :
move.b d0,(a0) at cycle 372
move.b d2,(a0) at cycle 380

So, change to 60 Hz is effective at cycle 376, which would mean pixel 376-87=287 for you, which is not your value of 293.
When you say the change has to occur precisely at pixel 293, do you mean the move.b is at pixel 293, or the write is completed at cycle 293 ? (in the case of move.b dx,(ax) that takes 8 cycles, the write is completed after 4 cycles)

I think we might not have the same units here too, we need to be sure.

An other example, in your 4bit.prg, these are the Hatari timings for right border removal + stabilizer :

cpu video_cyc= 32628 372@ 63 : $012a14 : 1a80 move.b d0,(a5)
sync=0x00 video_cyc_w=32632 line_cyc_w=376 @ nHBL=63/video_hbl_w=63 pc=12a16 instr_cyc=8
cpu video_cyc= 32636 380@ 63 : $012a16 : 1a82 move.b d2,(a5)
sync=0x02 video_cyc_w=32640 line_cyc_w=384 @ nHBL=63/video_hbl_w=63 pc=12a18 instr_cyc=8
-> move.b on cycle 372, change to 60 Hz on cycle 376, back to 50 Hz on cycle 384

cpu video_cyc= 32696 440@ 63 : $012a1e : 1c82 move.b d2,(a6)
shifter=0x02 video_cyc_w=32700 line_cyc_w=444 @ nHBL=63/video_hbl_w=63 pc=12a20 instr_cyc=8
cpu video_cyc= 32704 448@ 63 : $012a20 : 4e71 nop
cpu video_cyc= 32708 452@ 63 : $012a22 : 1c80 move.b d0,(a6)
shifter=0x00 video_cyc_w=32712 line_cyc_w=456 @ nHBL=63/video_hbl_w=63 pc=12a24 instr_cyc=8
-> move.b on cycle 440, change to hi res on cycle 444, back to low res on cycle 456.

What would be your pixels values for this case ? If we consider the point where the write is effective, I think we should have cycles_hatari = 83 + cycles_paulo

At the moment, Hatari is limited to multiple of 4 cycles/pixels when taking writes into account, so this requires some hacks to handle the "exg" case to get a 6 cycles precision, but appart from that, it's really easy to add other timings for border removal.
If you can send me your test program later, I will add those not supported yet.

In order to open the right border using a 60/50 switch, the change to 60, has to occur precisely at pixel 293 to work with both wake up states.
In wake up 2, it can also occur at pixel 295 (exg or similar non multiple of 4 cycles instruction before the 60 switch).
In wake up 1, it can also occur at pixel 291 (exg or similar non multiple of 4 cycles instruction before the 60 switch).
If you do it at pixel 291 in wake up state 2 like Leonard does in part of the Nostalgic Main Menu, it will not work.

I remember some discussions here with leonard about this. I never really checked this so far, but does it mean that the "decision" made by the shifter to stop a 50 Hz line is in fact at a position 4X+2 and not 4X ? So the write to 60 Hz can be on cycle 4x or 4X+2 ? (99% of all demos usually do a write at cycle 4X, not 4X+2 (except the case for nostalgic))

Nicolas

[ljbk]

Hi !

Sorry for this delay in replying but first i was on holidays and then i was in hospital for a surgery ...
I am still in "recovery mode".
Here i attach a more visible example of the shifting technique already linked with a normal sync scroll.
This means i can set the byte offset and the shift -12, -8, -4 and 0.
From what i know at the moment, it is clear that this new 4 bit sync shift and scroll allows things that were up to now impossible for an Atari STF especially if it only had 512KB.

The program will not even try to run on STE and your STF must be really synched for this to work.

Enjoy,
Paulo.

PS: Nicolas, if you want please provide me with your email (via PM) so that i can give you all explains and send the files you might need.
This time this thing did not work correctly with wake up state 1 and neither does the first program work now. I have so much trouble in getting my machine to wake up state 1 that may be there are sub wake up state or a non sync case of wake up state 1. A thing is for sure, last time it worked correctly and now i get the behaviour you described: shift -4 (4 pixels to the left) does not work and the 3 others (-12, -8 and 0) do. May be i could force a 4 pixels shift with a early start and early end (start like 162 bytes line and end like 158 bytes line) but it would have to be done at every line and so the spirit of this trick would be lost.
Anyway, it works with wake up state 2 and that is the state i get with my machine more than 90% of the times ...

[npomarede]

Hello paulo,
thanks for providing a more "graphical" test program, I will try it on my STF as soon as possible (I was also in holidays and will need some time to catch up with atari related questions). Hopefully you will recover soon and we can improve shifter use both on real HW and emulation wise.
I PM you my email.

Nicolas

[calimero]

regarding horizontal scrolling game, I just bump on Son Shu Shi. It has nice 8 directional scrolling and big playfield with lots sprites!

http://www.youtube.com/watch?v=eqHeugxa9Y8

[Zamuel_a]

That is an STE game so not so special with scrolling there