Little help please

[Petari]

I'm working on hi-color video playback together with Cyg and Douglas Little - so it includes hi-color picture displaying on ST, STE machines too. There is one issue what results in small errors in displayings in some cases, caused by different timings in video circuits on diverse machines and emulators. Furthermore, it may change by warming of machine.

Errors look like:





SW for testing:     http://atari.8bitchip.info/TIMINGC.ZIP

Mostly testing on STE, Mega STE is interesting. Please, run TTP executable, and enter 1A and look carefully what is on screen errors are not big - bad color dots, mostly at same hor. pos, so like stripped vertical bars. Exit with space, then check other s -1B, 2A, 2B .
If can, do check with cold machine, and later with warmed up - but turn off for short between tests - it is important, because timing scheme sets only by power-up.  Then write here which ones looked good, which bad - and when.

My STE, when is cold shows well A or B in 50%-50% cases. When is warmed shows always A correct.  Emulators whow B correct (Steem and Hatari).  My Mega STE shows correct A or B even when warmed up. I don't expect situation that none will be shown correct, but who knows - then would like to see screenshot of it - but it may be problem if no capture card.
 

[jvas]

When do you consider the computer "warmed up"?

[Petari]

Here, warmed-up means only couple minutes after first power on - internal warming of chips is relevant. So, consider your machine warmed up after 2 minutes (my experience with STE).

And here is video playback with popular UltraSatan and STE:

http://atari.8bitchip.info/DebrisUS12fps.avi

It was made with Mega STE and UltraSatan. STE is good too, of course - must run on 8MHz CPU clock. I need to fix some things yet in playback SW, mostly related to diverse filesystems and drivers possible. As already said earlier:  this will work only if disk and adapter are enough fast, so min transfer rate is 1100KB/sec.  And you need to defragment partition on which large AV file will be copied.
SW and example AV file in couple days ...

[Petari]

Here is video, good for UltraSatan playback, something interesting for Atari fans, from 25 years ago: 

http://atari.8bitchip.info/HCPL158.ZIP

22MB. Player SW and instructions included. Works on ST too, without sound.  In case of problems test speed with:

http://atari.8bitchip.info/ahpt.html

Video of playback: http://atari.8bitchip.info/AscUS.avi

When SD card is slow:    http://atari.8bitchip.info/Slowc.avi

With classic hard disk: http://atari.8bitchip.info/ClHard.avi

Same video with overscan (not for US) :  http://atari.8bitchip.info/Asc.avi

If someone with IDE adapter and CF card want video playback, please let me know - write couple words about your specs.

[kovacm]

1st cold star

1a ok
1b errors
2a ok
2b errors

2nd cold start

1a ok
1b errors
2a ok
2b errors

3th cold start

1a ok
1b errors
2a ok
2b errors

4th cold start

1a ok
1b errors
2a ok
2b artefacts

errors looks like exactly like:
http://atari.8bitchip.info/Err1.png
http://atari.8bitchip.info/Err2.png

1 minute pass between cold starts.
temperature in room 17 Celsius
cold start = power off for 5 sec.

---

after 4th time I play some demos for 20 minutes... (Cyg's: Japan and StreeArt and Japan looks great! it is crazy to see so much colors on screen with animation... - but there are also glitches on some screens!)

after that, I run test again:

---

5th cold start (after 20 minutes)

1a errors like: http://atari.8bitchip.info/Err3.png
1b ok
2a errors like: http://atari.8bitchip.info/Err4.png
2b ok

6th cold start

1a ok
1b error http://atari.8bitchip.info/Err1.png
2a ok
2b error http://atari.8bitchip.info/Err2.png

7th cold start

1a ok
1b error http://atari.8bitchip.info/Err1.png
2a ok
2b error http://atari.8bitchip.info/Err2.png

8th cold start

1a error http://atari.8bitchip.info/Err3.png
1b ok
2a errors like: http://atari.8bitchip.info/Err4.png
2b ok

9th cold start

1a ok
1b error http://atari.8bitchip.info/Err1.png
2a ok
2b error http://atari.8bitchip.info/Err2.png

---

My STe serial number:

520 STE UK
3123251


so I would say it is definitively connected to temperature.
when STe is cold, A version works alway (with same error), when is warm, complete mess!

where is exact problem? what timer "go crazy"?

[Petari]

Thanx for detailed tests.
I think that explanation is actually pretty simple:  in normal usage, exact timing of write to shifter color registers - so, setting colors on ST, STE is not relevant. There are 4 cycles available for it - because CPU write cycle is 500nS. Most likely, write happens in 2nd or 3rd cycle. Normal usage means writing to color registers in Vertical blank - border period . Change will be visible only in first active screen line. 
STE designers just did not have in mind that it may be needed to have exact timing for this - color changing during scanline draw to monitor.

[kovacm]

But on ST there is no such problem?

It is timer A or simple instruction count?

[Petari]

Some people noticed same problem on ST too.
Not Timer A, and not instruction count. Here we have case of only 1px difference (what is 125nS). Instructions take minimum 500nS - 4px.
It is just little shift, possible different delay in logic by MMU and Shifter chip. And result is that concrete write to shifter RAM happens 1 cycle (125nS) sooner or later. It may be even very small difference - around some 20nS, if it is at border between 2 cycles.

[kovacm]

I see...

So there is no way to measure this delay except by user looking at screen?
(and than user had to choose correct executable?)

It looks like quite random

Is it connected to something else or only to write to ram with one cycle delay?

[Petari]

It maybe can be measured with some logic analyser, if can access all relevant points (some may be inside chips only), but will help not much.
Yes, it seems pretty much random. And yes, one cycle delayed RAM write.

Unfortunately, it is not enough to choose correct executable. You need to make whole conversion of image sequences with converting SW set to timing A or B - and it is the slowest part . Douglas Little made some workaround, by masking problematic pixels - but it has drawback that reduces available colors - and often we have already too little colors.  All in all, no perfect solution.
Adding some delay between MMU and shifter would help likely, but it is not easy to do for average STE user

[kovacm]

I just stumble on this two threads at atariforum:

http://www.atari-forum.com/viewtopic.php?f=15&t=13267

http://www.atari-forum.com/viewtopic.php?f=68&t=9056

I still did not read them, but it looks like same problem!

[Petari]

Yeah, it is exactly the same issue. Thanks.
Too bad that it is practically impossible to find related threads at AF - there is too much post (and most of them is really not useful).
They used term 'wakeup' - something what never would came out of my limited brain 

[kovacm]

^
yes... we definitivly need "web 3.0" or AI, "global database"...


btw I post link at AF to quite detailed description of shifter: http://hxc2001.free.fr/yaquoidedans/atari_ste/index.html

but it is on french

[Petari]

I tried that wakeup.tos in my STE and Mega STE .  The result is always  1 (cold).  It means that it is not good for STE, and no wonder that another people got also 1 always on their STEs.
Btw. it works very similar like code, what I posted in hi-color thread (currently last post there). Only that I tested it only on STE machines, and concluded that can not determine timing reliable, while Ijor tested only on ST machine(s) .

All in all, I think that it is not possible to detect via SW in which timing STE is 'waked up' .  Because SW detects it via reading, but pixel errors happen during writing to shifter - and no way to know exact moment of that write - except of course by looking output image.

[Official Ninja]

My STe showed the A pictures with no errors cold and warm. The B pictures always show some kinda of error cold or warm.

I don't have a Mega STe hooked up at the moment. When I set it up again I'll try this out on that machine.