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:
(https://forum.8bitchip.info/proxy.php?request=http%3A%2F%2Fatari.8bitchip.info%2FErr1.png&hash=68ffb4a601f96d07f23200fc7827f52e2ca01d91)
(https://forum.8bitchip.info/proxy.php?request=http%3A%2F%2Fatari.8bitchip.info%2FErr3.png&hash=cc5fb8aeaa6a712f41a2d45346736e728c8c4e13)
(https://forum.8bitchip.info/proxy.php?request=http%3A%2F%2Fatari.8bitchip.info%2FErr2.png&hash=797291afef90956026f3f6ff8b918a0fbd2887a9)
(https://forum.8bitchip.info/proxy.php?request=http%3A%2F%2Fatari.8bitchip.info%2FErr4.png&hash=6c521e733869ea6711226ab5b09b80948a1d7016)
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.
When do you consider the computer "warmed up"?
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 ...
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.
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 :D 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"?
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.
But on ST there is no such problem?
It is timer A or simple instruction count?
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.
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?
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
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!
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 ;D
^
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 :(
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.
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.
Atari MegaSTe Rev.G 1.44MB 4MB RAM, 2.06 UK TOS Ser.:A1194014845, Reversed AC plug.
- Cold: All wrong. 1A and 1B dot errors+shaking screen.. 2A dot errors that appear and disappears +little shaking. 2B dot errors static.
- Warm: All wrong like in cold but 2A. No errors there. Perfect image.
Atari 520STe Ser.:A19B3007467, 4MB, TOS 1.6 UK, bad dma chip, Normal way AC plug:
Cold and warm: 1A and 2A dot errors, few. 1B and 2B OK
Atari 1040STe Ser.:A1307336, 4MB, TOS 1.62 UK, good dma chip, Reversed AC plug:
Cold and Warm: 1A and 2A OK. 1B and 2B, dot errors, few.
Seems confusing.... ???
Hope this helps!
Thanx for testings. It helps for sure.
It is little confusing, but as said, ST(E) is not designed with accurate palette color writing timing in mind. So, 1 T state (125nS) variation happens depending on something by powering on. In normal usage it is completely unnoticeable.
I need to inform some people, like S. Seagal and Cyg. First may add wakeup setting for STE in Steem. Second should update hiSteColor for Timing A in 54 color mode.
Here is regular Steem 3.2 with only changed to TimingA:
http://atari.8bitchip.info/SteemTimingA.zip
Just copy it to your Steem DIR and use to see difference. If compare hi-color screens of hard disk adaptations, latest ones, you will see that errors are same as on YouTube videos of games. By me, it should be default Steem timing, since most of STE machines are in TimingA in most of cases.