Vice'ın NTSC emulasyon problemleri

[skate]

Commodore 64'ün en iyi emulatörlerinden biri hatta en iyisi olarak kabul edilen Vice NTSC'ye (Amerika'nın görüntü standardı) gelince çok pis patlıyormuş. Bu zaten bilindik birşey anladığım kadarıyla ama ben yeni öğrendim. NTSC desteği biraz yama gibi eklenmiş. Hatta komik bir biçimde tamamen emülatör kullanarak kod yazan bazı programcılar Vice'ın emülasyon sorunları yüzünden yaptıkları efektleri sınırlamışlar (bunu bazı NTSC ürünlerinin notlarında ve ürünlere yazılan yorumlardan öğrendim). Gel gelelim CCS64 şimdilik düzgün emüle ediyor gibi gözüküyor NTSC'yi.

[endo]

Allah allah, Amerika'da emulator kullanmiyorlar mi? En azindan Vice'i? Ilgincmis.

[skate]

Az önce Viceteam'den Andreas Matthies'den mail geldi. Report ettiğim sprite buglarını çözmüş, bana da x64.exe'yi göndermiş. Bir sonraki Vice versiyonunda görürsünüz fixler arasında NTSC'deki sprite bugı muhabbetini.
 
@endo: ben de çok şaşırdım. ancak Mermaid'le konuşurken bu konuyla ilgili Mermaid de Vice'ın NTSC emülasyonunun çok kötü olduğunu söyledi ve illa ki NTSC scene'inden birilerine test ettirmemin doğru bir seçim olacağını söyledi. Netekim EFNet Türk IPlerini banlediği için (bazı serverlarda banned: turks yazıyor) bir türlü ulaşamadım NTSC scene'inin yer aldığı #c-64 kanalına. Avrupadakiler de konuya yardımcı olmak yerine "youtube'u banleyen ülke siz değilmiydiniz" şeklinde salak yaklaşımlarda bulununca tepem attı iyice...

[skate]

ılginç birşey öğrendim. Az önce Shane Fell'den 1 aydır beklediğim test sonuçları geldi, gerçek NTSC makineyle test etmiş. PAL ve NTSC'de sol borderda sprite koordinatları sıfırın soluna geçtiği zaman farklı değerlerden devam ediyorlar. ışin daha da ilginç yanı CCS64 PAL'ı NTSC ile aynı kabul ederek hatalı emüle ediyor. Vice'ın ise henüz yayınlanmamış 1.22.8 versiyonu düzgün emüle edebiliyor.
 
Aradaki fark şöyle.
 
PAL'da sprite 0'ın soluna geçince 255'den değil 248'den devam ediyor. Bu farkın doğma sebebinden emin olmasam da hep border açmak için borderı daraltıp genişletirken $d016'nın değerlerini değiştiriyor olmamızdan kaynaklandığını düşünmüşümdür.
 
NTSC'de ise bu böyle değil. Sprite olması gerektiği gibi 0'ın soluna geçtiğinde 255'den devam ediyor. Peki neden böyle bir fark olabilir? Aklıma gelen tek açıklama şu oldu. NTSC'de PAL'a göre fazladan 2 cycle olduğuna göre PAL'da tam sprite'ın 0 koordinatına denk gelen bir raster kayması NTSC'de daha solda bir bölgede kalıyor ve bu sebeple etkilemiyor bu geçişi. Ancak "peki bu durumda 255 değil de 255-16=239'a gelince bir kayma olması gerekmez mi?" derseniz "ne biliim ama olmuyor" derim.

[GnoStiC]

vice source repository yok galiba? sen 1.22.8 'i nerden buldun?

...
Vice'ın ise henüz yayınlanmamış 1.22.8 versiyonu düzgün emüle edebiliyor.
 ...

[skate]

test etmem için bana mailda attachment olarak gönderdiler. official versiyon olmadığı için yaymayı uygun görmüyorum. zaten NTSC fix harici ne gibi değişiklikler olduğundan benim de haberim yok. yakında 1.23 yayınlanır tahminimce.

[GnoStiC]

tamamdir abi

pandora port'una basliyayim diye dusunuyordum, official versiyonunu bekliyeyim..

v1.22 'de gp2x icin yaptigim degisiklikleri submit etmemistim, bari 1.23 'de diff'lerimi gonderiim adamlara da, official olsun..

[skate]

ben winuae takımında olduğunu falan biliyordum da vice'a da el attığını bilmiyordum. elimde 1.22.8'in sourceları olsa gönderirdim de elimde yalnızca x64.exe var. onu port etmeyi denememeni öneririm

[GnoStiC]

yanlis anlasilma olmasin; winuae takiminda degilim, toni willen ile pek anlasabildigimizi soyleyemem.. yaptigim patch'lere genelde buna ne gerek vardi diye cevap veriyor
toni'nin islerini takdir ediyorum ancak code'larinin cpu hungry oldugunu dusunuyorum. (ornek)
tabi kendi acisindan hakli, cycle exact/perfect emulation pesinde, bizse low end sistemlerde (psp, gp2x) kullanilabilir bir emulasyonun..

vice ise tamamen tesaduf oldu, dtv demosu izlemek istiyordum, vice'i cekip dtv patchlerini yapip (o zamanlar viceplus yoktu) linux'ta compile ederken, gp2x versiyonunu da yapayim dedim, arada ek ozellik isteyen oldu, onlari yaptim sonra biraz daha hizlandirayim dedim felan.. boyle iste

ben winuae takımında olduğunu falan biliyordum da vice'a da el attığını bilmiyordum. elimde 1.22.8'in sourceları olsa gönderirdim de elimde yalnızca x64.exe var. onu port etmeyi denememeni öneririm

[skate]

helal olsun kardeşim, çok önemli iki projeye destek veriyorsun. ben genellikle kıçım sıkışınca bug report+testing ile uzaktan destek veriyorum
 
gelelim senin tavsiye ettiğin optimizasyonlara. söz konusu olan kod parçası blitter function olmasaydı tavsiye ettiğin optimizasyonlara ukalalık bile diyebilirdim. ancak kritik noktalarda inline assembler bile kullansan kimsenin yadırgamaması lazım. tabii adamların endişesi büyük ihtimalle kodun okunurluğu. büyük ihtimalle benim 256b javascript kodlarıma dönmesinden korkuyorlardır source codeların ayrıca adamın haklı olduğu bir husus var, birçok compiler loopları terse çevirme gibi optimizasyonları "teoride" yapıyor. gel gör ki herhangi bir hız için optimize edilmiş C/C++ kodunu assemblerdan hız manyağına çevirebileceğimize inanıyorum. yani teoride derleyicilerin yapması beklenen birçok optimizasyon pratikte sanki yapılmıyor gibi geliyor bana. yanılıyor da olabilirim...

[GnoStiC]

gcc icin konusuyorum, cogu zaman yaptigi optimizasyonlara hayranlikla bakiyorum. ama bazen kafasi karisiyor, elle yardimci olmak gerekiyor (bu yuzden ozellikle register ve inline komutuna bayiliyorum)

loop'lari compiler'larin ters cevirebildigini bilmiyordum, kaldi ki bana mantikli gelmiyor.. eger kafasina gore optimizasyon yaptigini dusunerek ters cevirirse (ornegin uae'de), ekrana gelecek ornegin sprite'larin z-order'i ters duracaktir.

diger konuda da haklisin, richard (e-uae maintainer)'la konustugumuzda, yaptigim degisiklikleri ifdef ifndef 'ler arasinda gondermeyi uygun bulmustuk, ancak hem psp hem de gp2x icin port ettigim code'lar o kadar cok ifdef 'e neden oldu ki, code dedigin gibi okunmamaya baslanmisti..

psp ve gp2x'in donanimi, ekran cozunurlukleri belli ve sabit olunca, code icinde bizim icin gereksiz bir suru satir ortaya cikiyor.. ozellikle psp'de icache miss ciddi performans kaybina neden olabiliyor, gereksiz satirlarin kaldirilmasi, ise yariyacak yerlerin unroll edilmesi vs performans icin sart oluyor.. bu yuzden bu uae'ler fork olarak kalacak.. zaten pandora geliyor, ugrasmam heralde psp/gp2x ile :}

.. yalan olmasin psp'yi god of war icin kullanirim yine, gp2x'im de bozuk zaten ..

yani teoride derleyicilerin yapması beklenen birçok optimizasyon pratikte sanki yapılmıyor gibi geliyor bana. yanılıyor da olabilirim...

[skate]

loopların ters çevrilmesi başka açılardan problem yaratır haklısın. derleyicilerin en çok optimize etmeye yeltendikleri şey looplar olduğu için sonucu değiştirmeyecek ölçüde mümkün olan tüm optimizasyonların yapıldığını tahmin ediyorum. tabii bu durumda senin önerdiğim loopu ters çevirme gibi sonucu değiştirse de o anki durum açısından fark yaratmayacak optimizasyonlar çok mantıklı.
 
bu arada benim bildiğim kadarıyla optimizasyonu hıza yönelik yaparsan inline komutunu kullanmasan da otomatik olarak derleyici bu komut varmış gibi davranıyor. dediğin gibi "arada bir kafası karışıyor" diyorsan doğrudur, bu güne kadar yalnızca bir kez compilerın nasıl sonuç ürettiğini incelememi gerektirecek bir durumla karşılaştım x86 tabanlı sistemlerde. onda da tahmin ettiğimden çok daha iyi bir sonuç üretmişti. hatta inline komutunun otomatik olarak konulduğunun ya da diğer bir deyişle yüksek optimizasyon seviyelerinde inline komutunu koyup koymamanın bir değişiklik yapmadığını o zaman inceleyerek gözlemlemiştim. ben kesin bir subroutine'e gidiyordur, bir call vardır diye düşünmüştüm. ancak olduğu gibi plot fonksiyonumu loopun içine oturtmuştu bir güzel. hatta yanlış hatırlamıyorsam bu Turbo C++, Watcom C gibi 16 bit ve eski bir derleyiciydi.
 
peki adamlar projede inline assembler kullanmıyor mu hiç? yani blitter function gibi kritik noktalarda kullanılmasında pek sakınca görmüyorum ben. belki projeye katılan bazı programcılar üzerinde bir antipati yaratabilir ancak benim yıllarca kullandığım TinyPTC librarysinin en sevdiğim özelliklerinden biri memcopy, X bit -> Y bit RGB dönüşümleri gibi işlemleri, MMX mimarisini de kullanarak doğrudan assemblerdan yapmasıydı. o kütüphaneyi farklı ve hızlı kılan noktalardan biriydi bence. bu tür şeylerin Vice, UAE gibi projelerde de olduğunu sanırdım, yanılıyor muymuşum?

[GnoStiC]

bu arada benim bildiğim kadarıyla optimizasyonu hıza yönelik yaparsan inline komutunu kullanmasan da otomatik olarak derleyici bu komut varmış gibi davranıyor.

gcc 'de de -O parametresine verdigin degere gore bazi degerleri set ediyor.

ingilizceden turkceye cevrim programlarini kullanmissinizdir. eger cumlenin sonuna . ? koyarsaniz veya cumle icinde , ile ayirma yaparsaniz cok daha dogru sonuclar elde ediliyor.
o hesap, compiler'in ne yapmak istedigimizi tahmin etmesindense, ona direkt, "bak abi ben bunu su sekilde kullanmak istedim" seklinde elle yardimci olmaktan yanayim.

peki adamlar projede inline assembler kullanmıyor mu hiç?
...
bu tür şeylerin Vice, UAE gibi projelerde de olduğunu sanırdım, yanılıyor muymuşum?

kisaca "kullanmiyorlar" diyebilecek kadar hic/cok cok az kullaniliyor.

[skate]

Ben aeymur'un projesi için yakın zamanda Vice'ın 1541 emulasyonu bölümünü incelemiştim. Anlaşılan projenin geneline bir göz atsam iyi olacak. Herşeyi de sora sora öğrenecek değiliz ya