ljbk wrote: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?
Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
ljbk wrote:As far as i know, the SW can not influence the hardware wake up states. It can detect them and eventually handle them.
calimero wrote:ljbk wrote: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?
calimero wrote:ljbk wrote: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?
calimero wrote:^
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 wrote: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.
danorf wrote:ljbk wrote: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.
npomarede wrote:Hello
I tested your program on my French PAL 520 STF,and unfortunately, it doesn't workI 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 wrote: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
ljbk wrote:
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 wrote: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.
npomarede wrote: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 ?
ljbk wrote: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.
ljbk wrote: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.
Users browsing this forum: No registered users and 4 guests