Retrojen Forum
Dijital Sanat => Kodlama => Konuyu başlatan: Pe@ceR - 05 Temmuz 2013, 16:47:21
-
80'lerde basic hantal ve kaplumbağa hızında takılırken makine dilini keşfettik ve ucundan köşesinden de olsa 6502 makine dili ile programlar yazmaya başlamıştık.
Bunu yaparken makine dilini anlayıp kodlara çeviren programlar olmadığından direkt matrix filmindeki gibi bilgisayarla sayılar aracılığı ile haberleşmeyi öğrendim. LDA STA DEX DEY gibi komutlar yerine doğrudan doğruya hex kodlarını hafızaya #A9 #AA #85 #00 #C8 #D0 gibisinden yazarak programlar ve oyunlar üretirdik.
Yıllar geçince yaş da 40 lara yaklaştıkça bu hazır kodlar hafızadan uçup gitmiş.
Şimdi yeniden ufak ufak makina dilinde yeniden kodlar yazmaya çalışıyorum. Tabi Oric üzerinde.
Yabancı kaynaklardan ufak ufak yeniden hatırlamaya çalışıyorum kavramları ama kaplumbağa hızında ilerliyorum.
Özellikle adresleme meselesi devreye girince kafalar karışıyor.
Absolute, indirect , indexed indirect, indirect indexed v.b. derken hangisi neydi karışıp gidiyor.
Nette elbette çok sayıda kaynak var ama hepsi başka bir yerinden konuya dalıp çorbaya çeviriyor.
6502(6510) assembly dilini ve komutlarını küçük örneklerle açıklayan kaynak var mı bildiğiniz?
Mesela basit toplama çıkarma işlemleri, blok hafıza kaydırma, ekranda byte ve bit olarak scroll kodları gibi şeyler olabilir.
-
LDX #$00
LOOP LDA KAYNAKADRES,X
STA HEDEFADRES,X
INX
BNE LOOP
RTS
Kaynak adresten, hedef adrese 256 baytlık veriyi taşır ve RTS ile programdan çıkılır.
Z80 karşılığı ise;
LD HL,KAYNAK
LD DE,HEDEF
LD BC,VERİ MİKTARI
LDIR
RET
6502 (6510)'da tek döngüde max. 256 bayt taşınırken, Z80'de 65536 bayt taşınabilir.
-
http://nightnetwork.org/writings_tr/6502_makine_dili/chunk/index.html (http://nightnetwork.org/writings_tr/6502_makine_dili/chunk/index.html)
Yeterli olacaktır bence bu adres.
-
Hmm güzel bir kaynakmış teşekkürler !
Malesef tam değil. Birçok bölümün eksiği var. Birkaç kelime yazılıp bitirilmiş. Keşke tamamı olsaydı..
-
C64 Türkiye (http://www.retrodergi.com/list.php?dir=./Dergiler/C64%20Turkiye/&title=C64%20T%C3%BCrkiye&sub=Bilgi%20Payla%C5%9Ft%C4%B1k%C3%A7a%20Artar)'de de var. Her ne kadar C64 baz alınarak anlatılmış olsa da faydalı olabilir.
Not: Retrojen e-Kütüphane (http://retrojen.org/lib/mag)'den download edebilirsin.
-
İnceliyorum, teşekkürler.
-
İnceliyorum, teşekkürler.
ingilizce sorunu yoksa,
http://6502.org/tutorials/ (http://6502.org/tutorials/)
Yalnız 6502 öğrenmek yetmiyor, oric'i yalayıp yutmak lazım bu işlere girişirken. Örnek, Zx Spectrum Ula'sını çalışırken z80 bilgimi hızla ilerlettiğimi farkettim. Bu tür bir deneme/yanılma süreci güzel öğretiyor.
-
Yok 6502.org u baya bir karıştırdım. Çok fayda göremedim.
-
Nightlord'un dokümanlarına göz attın mı?
http://nightnetwork.org/writings_tr/6502_makine_dili/chunk/index.html (http://nightnetwork.org/writings_tr/6502_makine_dili/chunk/index.html)
6502 makine dilini deneysel düzeyde mi kullanacaksın, ciddi bir proje mi amaçlıyorsun?
-
Bundan iyisi, Şam'da kayısı: Easy 6502 (http://skilldrick.github.io/easy6502)
-
Attım bookmarks'a :)
-
Nightlord'un dokümanlarına göz attın mı?
http://nightnetwork.org/writings_tr/6502_makine_dili/chunk/index.html (http://nightnetwork.org/writings_tr/6502_makine_dili/chunk/index.html)
Bunu hatim ettikten sonra http://nightnetwork.org/writings_tr/c64_grafik_programlama/chunk/index.html (http://nightnetwork.org/writings_tr/c64_grafik_programlama/chunk/index.html) adresindeki VIC programlamadan devam edersen baya bir ufkun açılacaktır. Garantili. :)
-
Teşekkür ederim ama benim amacım Oric üzerinde makine dili ile işleri hızlandırmak. Haliyle c64 grafik programlama beni biraz aşıyor..
-
Başlık gözünü korkutmasın. Sprite haricinde VIC'in diğer sistemlerde olmayan yaptığı çok da bir şey yok aslında. Nightlord'un grafik derslerini Oric'e uyarlaman çok da zor değil. İhtiyacın olan Oric hakkında bir referans dökümanı edinmek. Sanıyorum zaten vardır sende böyle bir şey. Gerisi tercüme yeteneğine kalıyor.
Mesela ilk ders hatırladığım kadarıyla raster'ı yakalamak üzerine. Önce her çalıştığında border rengini değiştiren bir irq rutini yazıyor. Raster IRQ için VIC'te bir register var, onu set ediyor. CIA'da ikinci bir register var IRQ'ları tetikleyen onu set ediyor. Program iki kere VIC'e, bir kere de CIA'ya başvuruyor. Bir de IRQ ile işimiz bittikten sonra rutin işleri halleden kernel rutinine dallanıyor program. Bunun Oric karşılığını bulman lazım.
Update:
Hay bin kunduz! Dehşet içinde farkettim ki Oric'te Raster IRQ yokmuş! Bu durumda her satırda 64 cyle zaman harcayan bir kodla bekleme yaparak ekranın aynı noktaya gelmesini beklemek gerekiyor.
In theory, yes. Unfortunately, the Oric lacks any way to sync to
the horizontal or vertical retrace (no vertical blanking IRQ).
You would have to tweak your routine so that it executes in
exactly the same number of cycles it takes for the ULA to output
a scan line. That's 64, if I recall correctly.
-
Siteyi zaten makine dili üzerine googllarken görmüştüm ancak birçok bölümn sadece başlığı atılmış ve devamı getirilmemiş. örneğin scroll mevzusu v.b.
evet Oric'in şahsına münhasır bir grafik mevzusu var :) Örnein c64'deki renk kodlamasını ayrı yaptığımız 1000 byte'lık hafızası çok özendirici bir durum :)
-
Oric'in grafik modlarını araştırdıkça yavaş yavaş Tramiel'e hayran olmaya başlıyorum galiba. 1K bellek kazanmak için grafik yeteneği feci budamışlar.
-
Oric'de VIA timerları var iki tane. Yani CIA'nın birebir karşılığı olan şekilde yok ancak timer elbette ki var ve bunlar kullanılarak interrupt yazabiliyorsunuz. Timerlar iki tane olduğu için de hem IRQ, hem NMI C64'deki gibi simüle edilebilir.
Bu Oric nedir, ne değildir araştırdığım seneler öncesinden kalan teorik bir bilgi. Tek satır kod execute etmişliğim yoktur. Yarı güvenilir bir bilgi olarak alabilirsiniz.
-
Dehşet içinde farkettim ki Oric'te Raster IRQ yokmuş!
O c64 ve amstradcılara özel bir treat dostum :)
-
Kaç saattir google'ın altını üstüne getirdim. Oric'te raster satırı nasıl yakalanır hiç bir bilgi bulamadım. Tek öğrenebildiğim grafik işlerinin cpu ile paralel yürüdüğü ve bu sayede sekron tutrmanın fazla sorun olmadığı(?) Devamını birileri bulup paylaşır diye bekliyorum artık.
Oric için iki satır kod bulamadım ama bu araştırma "Computer Graphics during the 8-bit Computer Game Era" adında çok şık bir dökümanla karşılaşmama vesile oldu. Aşağıda linkini veriyorum. Oric ararken buldum ama malesef Oric'ten hiç bahsemiyor.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.152.2465&rep=rep1&type=pdf (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.152.2465&rep=rep1&type=pdf)
@ref: Anlamadım sizde de mi yok raster IRQ?? Ben bunun çok standart bir özellik olduğunu zannediyordum halbuki.
-
Slm. Burada biraz bilgi var Oric grafikleri ve raster hakkinda. Sayanin altinda raster kaynak kodu da var.
http://www.defence-force.org/computing/oric/coding/part_7/index.htm (http://www.defence-force.org/computing/oric/coding/part_7/index.htm)
-
Slm. Burada biraz bilgi var Oric grafikleri ve raster hakkinda. Sayanin altinda raster kaynak kodu da var.
http://www.defence-force.org/computing/oric/coding/part_7/index.htm (http://www.defence-force.org/computing/oric/coding/part_7/index.htm)
O source code yalnızca $a000'dan itibaren 200 tane renk değeri set ediyor. Eğer bunlar doğrudan raster color olarak map ediliyorsa 8 bit döneminden Atari 800 ailesinin display list'ine benzer bir desteği var demektir. Atari coding'e aşina olmayan ve display listleri bilmeyenler için Amiga'nın copper'ı dersem herhalde daha fazla kişi anlayacaktır. Kısacası donanımsal olarak her raster satırı başında zamanlamayı otomatik yakalıyor ve dilediğimiz değişikliği otomatik yapabiliyor demektir. Bu değişiklik normalde foreground/background'u rengi değiştirmenin yanı sıra grafik modu, point eden grafik adresi gibi şeyleri de içerir. Oric'de ya böyle bir destek var (ben bilmiyordum olduğunu) ya da o kod olayın tamamını ifade etmiyor.
Edit: Biraz daha inceledim, sıralı olarak yazmıyormuş değerleri. Sanırım Oric'de her karakter satırının başında color ve graphic mode ifade eden 2 byte var, onları set ediyor.
-
Cıks o raster o raster değil kafanız karışmasın :)
Defence force'das verilen kod, text modu ile hires modunu karıştırarak text ekranında iken hires grafikleri gösterme ile ilgili bir trick sadece. Denildiği üzere ekranda gösterilen byte'ın text mode mu grafik modu mu olarak gösterildiğine dair verileri değiştiriyor sadece. Karakter satırının başı değil de tıpkı renk ve zemin rengini satır içerisinde herhangi bir yerde değiştirilmesi esasına dayanıyor.
Oric'de KESİNLİKLE piksel başına renk kodlaması ya da buna ayrılmış ekstra bir renk haritalaması belleği yok.
Senkronizasyonla ilgili olarak olay tamamen interruptla ilgili. Ekran yenilenme hızı ile işlemci hızının senkron edilmesi üzerine denemeler var. Örneğin şurada ekranda aynı adrese kırmızı ve sarı rengi hızlıca koyup oric'de normalde olmayan portakal rengi'ni elde etmek üzerine bir çalışma var. renk değişimini yanıp sönme değil de gözün algılayabileceği sabit bir hıza getirmek için de cycle arası hesaplamalar yapılıyor. Detayını ben de çok bilmiyorum ama oric'in teyp çıkışından yapılan bir işlemle "vsync" deniyor bu konuya.
http://forum.defence-force.org/viewtopic.php?f=4&t=944 (http://forum.defence-force.org/viewtopic.php?f=4&t=944)
"19968 = 64*312 is the precise number of cycles of the screen raster.
However, to get an interrupt every 19968 cycles, you must program the VIA timer with a value of 19966, because the VIA adds two cycles to each count (19966, 19965, 19964,.... , 2, 1, 0, -1, 19966, 19965, 19964,...). "
Yeni geliştirilmekte olan şu oyunda da mesela girişte bu senkronizasyonla ilgili bir ayar (vertical retrace senkronizasyonu) yaptırılıyor. Teyp çıkışına ait donanımsal bir vsync hack kullanılmadan yazılımsal bir senkronizasyon yapılıyor
More tests, now with (preliminary) sfx and more (http://www.youtube.com/watch?v=7WeFgFSwEJ4#)
-
Detayını ben de çok bilmiyorum ama oric'in teyp çıkışından yapılan bir işlemle "vsync" deniyor bu konuya.
http://forum.defence-force.org/viewtopic.php?f=4&t=944 (http://forum.defence-force.org/viewtopic.php?f=4&t=944)
"19968 = 64*312 is the precise number of cycles of the screen raster.
However, to get an interrupt every 19968 cycles, you must program the VIA timer with a value of 19966, because the VIA adds two cycles to each count (19966, 19965, 19964,.... , 2, 1, 0, -1, 19966, 19965, 19964,...). "
RAAT #01'de bu konuşuldu ama tam olarak nelerden bahsedildi veya kimler muhabbete dahil oldu bilmiyorum. Gecenin bir yarısı elde kırmızılar, sanki garden party'de borsa veya sosyete dedikodusu yapılır türden bir görüntü var gözümün önünde. Belki Ref hatırlar tam olarak konuşan ve konuşulanları...
-
RAAT'da oric'de hiçbir interrupt mekanizmasının bulunmaması konuşuldu. Elbette elinizde sadece "timer" bulunan bir makinede sizin aldığınız tüm zamanlamalar bilgisayarı açtığınız analog zaman birimiyle ölçülebilir ve bu zaman birimi televizyonunuzu açtığınız zaman birimi ile örtüşmeyecektir. Dolayısı ile TV'nizin ne zaman vertical retrace aşamasını girdiğini bilemeyeceksiniz, bu ortamda da dikey senkron problemdir. Bu sebepten tüm demo ve oyunlarda, görüntüde yırtılmalar *olabilir* (ya da şanslı iseniz olmayadabilir).
Yanlız bu retrace gibi saniyenin 50'de birinde gerçekleşen bir olayı el-göz koordinasyonu ile tespit edebilecek bir sistem buldularsa bu sorunu çözülmüş sayabiliriz. Her durumda şimdiden kafamın alamayacağı kadar karmaşık, cycle sayma, timer kontrol etme gibi çılgın programcılık pratiklerinin uygulanması şart olacaktır.
Eh ama retro'nun en güzel yönü bu değil mi? Yokluklar içinde birşeyler üretmek, o yoklukları yok etmek? Bu arada multiplayer'a Oric de götürmüştüm ama amigadan başka birşeyi çalıştırmaya fırsat bulamadık. Eğer bir program daha yapacak olursak oric'den de bahsedeceğimden emin olabilirsiniz.
-
RAAT'da oric'de hiçbir interrupt mekanizmasının bulunmaması konuşuldu.
Tolga'ydı bahseden sanırım.
-
Enteresan bir konu ben o forumda okuduklarımdan anladıklarım ve önceden bildiklerimle iki yorum yapayım.
RAAT'da oric'de hiçbir interrupt mekanizmasının bulunmaması konuşuldu. Elbette elinizde sadece "timer" bulunan bir makinede sizin aldığınız tüm zamanlamalar bilgisayarı açtığınız analog zaman birimiyle ölçülebilir ve bu zaman birimi televizyonunuzu açtığınız zaman birimi ile örtüşmeyecektir. Dolayısı ile TV'nizin ne zaman vertical retrace aşamasını girdiğini bilemeyeceksiniz, bu ortamda da dikey senkron problemdir. Bu sebepten tüm demo ve oyunlarda, görüntüde yırtılmalar *olabilir* (ya da şanslı iseniz olmayadabilir).
Buraya ufak bir düzeltme: aslında televizyonun ne zaman v-sync yaptığını biliyoruz. Çünkü TV v-sync işlemini gelen video sinyalinden ötürü yapar. Yani burada bilgisayar ne zaman derse TV o zaman v-sync yapar. Oricteki problem sanırım şu. Eğer timerlar reset anından itibaren saymaya başlasaydı ve siz programınızı run ettiğinizde de saymaya devam ediyor olsaydı o zaman programda timer değerini okuyup rasterin nerede olduğunu kestirebilirdiniz. Sanırım bu durum yok ve timer siz set ederseniz başlıyor çalışmaya. Bunun olabileceği en erken nokta da program run etmeye başladıktan sonra. Programın ne zaman run edeceği ise belirsiz (program adını yazıyor kullanıcı falan). Bu yüzden bir ekranda toplam kac cycle var ise o kadar cycle'da bir çalışan ve diyelim ki ekran rengini değiştiren bir rutin yazarsanız ekranda her defasında aynı yere denk gelen bir efekt elde edebilirsiniz ama vsync olmadan bunun ekranın "neresine" geleceği muamma olacak. Bu da bizi bir sonraki noktaya getiriyor.
Yanlız bu retrace gibi saniyenin 50'de birinde gerçekleşen bir olayı el-göz koordinasyonu ile tespit edebilecek bir sistem buldularsa bu sorunu çözülmüş sayabiliriz. Her durumda şimdiden kafamın alamayacağı kadar karmaşık, cycle sayma, timer kontrol etme gibi çılgın programcılık pratiklerinin uygulanması şart olacaktır.
Bu sanıldığı kadar el göz koordinasyonu gerektirmeyecek. daha çok bir knob'ı çevirmek gibi olacak. sonuçta software ekranda nereye geldiğini bilemediği ama sabit bir şekil sunacak ve diyecek ki "bu şekli hede tuşu ile aşağı, hödö tuşu ile yukarı kaydırabilirsiniz. Şimdi ekranın en altına getirin. Sonra enter'a basın" böylece açılıştaki belirsizliği elimine edip ekranda ne nerede onu anlamış olacak.
-
aslında televizyonun ne zaman v-sync yaptığını biliyoruz. Çünkü TV v-sync işlemini gelen video sinyalinden ötürü yapar. Yani burada bilgisayar ne zaman derse TV o zaman v-sync yapar.
evet evet, elbette. Tabii bu asamada yine oric"in kendi donaniminin ne zaman vsync istedigini bilmiyoruz. Aslinda boyle onemli bir konu neden atlanir (hele ki bir kablo ile eklenebiliyor iken)... Biraz sinclairde 32 renk desteklemek yerine 8 renk+flash attribute'unu tercih etmelerine benziyor. Sadece aptalca bir karar.
-
My beloved Oric'imden bahsediyorsunuz ama ben anlamıyoğ . Yine de hoşuma gidiyoğ :)
-
My beloved Oric'imden bahsediyorsunuz ama ben anlamıyoğ . Yine de hoşuma gidiyoğ :)
nightlord'un mis gibi açıkladığı gibi, aslında o kadar da zor bir iş değilmiş.
1.Yazılım ekranı istediği zaman çizmeye başlıyor.
2. Sonra sana bir "ayar düğmesi" gösteriyor, bu ayar düğmesi sayesinde çizimi ayar kadar geciktirerek biraz geç çizmeye başlıyor.
3. Sen o düğmeyi, yırtılma ekranın dışına çıkana kadar çeviriyorsun. Sonra zamanlama tutturulmuş oluyor ve timer resetleniyor.
4. Oyunun belli aşamalarında timer kontrol edilerek oric'in hangi aşamada olunduğunun kontrol edilmesi, gerekirse beklenmesi ve ya da çizimin başlatılması gerçekleşiyor.
-
Onu anladım bir nebze. Ama teyp çıkıından donanımsal vsync hack nasıl işliyor aklım almıyor.
-
Yani burada bilgisayar ne zaman derse TV o zaman v-sync yapar.
Burada "bilgisayar" dan ne kastedildiğine bir açıklama getirmek lazım. TV, V-Sync'i video chip'i (ULA) ne zaman VSync yap derse o zaman yapar. Genellikle video chiplerinin içinde satır ve pixel'leri sayan counter'lar bulunur, VSync, HSync gibi sinyaller bunların üzerinden oluşturulur. Bu counter'lar da CPU'dan bağımsız çalışır genellikle (bilgisayardan kastın CPU olmadığını söyleme gereği hissetmem bu yüzden). Benim bildiğim kadarıyla, Oric'teki sorun, video chip'inin VSync çıkışının CPU'ya bir şekilde (interrupt ya da başka şekilde) bağlı olmamasından kaynaklanıyor. En ideali interrupt olması olurdu tabii, ama bir adresten VSync durumu okunabiliyorsa bununla da busy-wait vs. yapılarak senkronizasyon sağlanabilir.
Ayar dügmesi fikri esasında güzel, ama ancak sistemde birebir refresh rate ile aynı aralıkta çalışabilen bir timer varsa iş görür (Oric'te var mı emin değilim). Tam olarak 50Hz'de çalışabilen bir timer yoksa o zaman o senkronizasyon da zaman içinde bozulacaktır. Timer olmasa da teoride bu çözüm çalışır ama pratikte o frame aralığına (20ms) denk gelen cycle sayısını tam tutturabilen kod yazmak imkansıza yakın olur sanırım, hele 6502'de.
Oric'teki VSync hack'i detaylı incelemedim ama şöyle çalıştığını tahmin ediyorum. Muhtemelen CPU tape girişini direkt olarak okuyabiliyor. Video portundaki Sync çıkışı alınıp tape girişine verilirse CPU her frame'i çizip işini bitirdikten sonra sürekli olarak tape girişinden aldığı Sync sinyalini izleyip (busy-wait) VSync perioduna girildiğini anlayabilir. Tabii tam emin olmak için hack'i incelemek lazım dediğim gibi.
-
Yani burada bilgisayar ne zaman derse TV o zaman v-sync yapar.
Burada "bilgisayar" dan ne kastedildiğine bir açıklama getirmek lazım. TV, V-Sync'i video chip'i (ULA) ne zaman VSync yap derse o zaman yapar. Genellikle video chiplerinin içinde satır ve pixel'leri sayan counter'lar bulunur, VSync, HSync gibi sinyaller bunların üzerinden oluşturulur. Bu counter'lar da CPU'dan bağımsız çalışır genellikle (bilgisayardan kastın CPU olmadığını söyleme gereği hissetmem bu yüzden). Benim bildiğim kadarıyla, Oric'teki sorun, video chip'inin VSync çıkışının CPU'ya bir şekilde (interrupt ya da başka şekilde) bağlı olmamasından kaynaklanıyor. En ideali interrupt olması olurdu tabii, ama bir adresten VSync durumu okunabiliyorsa bununla da busy-wait vs. yapılarak senkronizasyon sağlanabilir.
Burada ben de özellikle "bilgisayar" dedim (CPU demedim). Yani v-sync sinyali bilgisayarda bir yerlerden geliyor olduğu için. Oric'te video sinyali üreten çip ile CPU'nun arasında herhangi bir senkronizasyon mekanizması (ne hardware irq bağlantısı ne de CPU tarafından okunabilir bir raster veya v-sync register) olmadığı daha önceki postlarda geçtiği için daha detaya inmemiştim.
Burada aşağıdaki varsayımı yaptım. Bu vesileyle bir hardware gurusunu yakalamışken bu varsayımı bir senin kontrolünden geçireyim :)
Video çipindeki counter'lar CPU'dan bağımsız çalışsa da aynı clock sinyali ile sürülüyorlar, (tam olarak değil tabi, bu sinyal mesela C-64'te 8'e bölünür vs. ama yine de senkronizedirler). Keza timer'lar da çoğu zaman sistem clock ile sayan bir mod destekler (yine C-64'te CIA timer'ları mesela). Dolayısıyla bu makinelerde bahsettiğin bir frame aralığının tam olarak kaç cycle olduğu net şekilde bilinir. Hatta bir satırın da kaç cycle olduğu tam olarak bilinir.
Bu yüzden bilgisayar ilk açıldığında video çipindeki counterlar eğer deterministik bir değerden saymaya başlıyorsa, CPU dan bağımsız bile olsalar, eğer cycle'ları reset anından beri sayan bir timer olsaydı (ve bu timer frame time kadar cycle'da bir resetlenseydi) o zaman v sync hep o timer'ın belli bir değerine tekabül ederdi. (ki mesela C-64 de aynen böyle bir timer vardır, açılıştan itibaren bir frame'de bir kere irq trigger eder. (bu timer tam reset anında saymaya başlamaz tabi. yani bu bir hw feature değil ama sayım boot rom tarafından deterministik bir zamanda yani reset anından n cycle sonra başlatılır ama buradaki tartışma açısından bu aynı kapıya çıkıyor) )
Yani eğer Oric de boot prosedürünün bir parçası olarak timer'ını başlatıyor olsaydı, Oric yazılımları timer'dan deterministik bir değeri okunduğunda v-sync zamanı olduğunu bilebilirdi. Bu boot zamanında olmadığı için Oric yazılımlarının timer ile yapabilecekleri herşey video çipindeki sayaçlara göre öngörülemez bir noktada kalıyor.
Bu varsayımlar dizisinde atladığım veya yanlış çıkarımladığım birşey varsa düzelt abi :)
-
Burada ben de özellikle "bilgisayar" dedim (CPU demedim).
Ben de tahmin ettim zaten o şekilde düşündüğünü ama thread içinde yanlış anlama olmasın öyle bir detaya inme gereksinimi hissettim.
Burada aşağıdaki varsayımı yaptım.
Vardığın sonuçta benim görebildiğim kadarıyla temelde herhangi bir yanlış yok. Ben de zaten "refresh rate ile aynı aralıkta çalışabilen bir timer" derken bahsettiğin durumu kastetmiştim.
Ama varsayımlarının arasında doğru olmama ihtimali olan bir tanesi var, o da video çipindeki counter'ların deterministik olarak saymaya başlamaları olayı. Bu da şöyle olabilir, Oric'in Reset hattı ULA'daki Vertical Line sayacına bağlanmamıştır, reset'te counter undefined bir değerde geliyordur. Sorun değil, çünkü ilk değeri ne olursa olsun kısa sürede sayaç overflow olup sıfıra dönecek ve ondan sonra normal işlevini devam ettirecek, bir daha da resetlenmesine zaten gerek yok. Fakat bu da CPU ile senkronizasyonun kurulamaması anlamına gelir yine.
Peki neden bağlanmamış olabilir Reset hattı? Tabii ki hardware'i basitleştirmek için. Özellikle eski çiplerde acaip trickler kullanılmış basitleştirme amaçlı. Mesela Atari TIA'da bu VSYNC HSYNC sayacı normal counter bile değildir, LFSR (Linear Feedback Shift Register) denen bir yapıdır, aynı görevi görür ama 1, 2, 3 diye saymaz, onun yerine karışık ama deterministik bir sequence'da gider, fakat hardware olarak çok daha basittir normal counter'a göre.
Bu arada, Oric'te gerçekten durum nedir, Reset bağlı mıdır, değil midir, onu bilmiyorum, tahminen ancak uygun şekilde kod yazarak ya da osiloskopla sinyallere bakılarak anlaşılır, ben sadece varsayımların fail olabileceği bir duruma teorik bir örnek verdim.
-
vay anasini sayin seyirciler. super bir data oldu bu retromaster. Benim gibi donanım tasarımına en son 348, 445, 446'da (14 yıl olmuş:( ) bakmış biri için tabi böyle tricky optimizasyonlar kırk yıl akla gelmeyecek şeyler. Ben hep bu grafik çiplerini sayaç kullanıyor varsıyordum. LFSR'ye baktim. hakkaten counter'dan çok daha basit (XOR'lusu mesela). Ama bu sefer bu sayaçları kullanarak memory adresi elde edip memory tarama olayı zorlaşıyor olmalı. Mesela bahsettiğin Atari'de ben belleğe bitmap dizmek istersem satırlar sütünlar saçma sapan yerlere mi diziyorum? yoksa böyle lookup table falan mı yapıyorlar? (donanımda demek istiyorum)
-
Ama bu sefer bu sayaçları kullanarak memory adresi elde edip memory tarama olayı zorlaşıyor olmalı. Mesela bahsettiğin Atari'de ben belleğe bitmap dizmek istersem satırlar sütünlar saçma sapan yerlere mi diziyorum?
Atari TIA'nın durumu çok özel esasında, çünkü o 2600'de video RAM yok :). CPU ile TIA tamamen senkronize çalışıyor. Playfield TIA içinde 20-bit'lik bir register'dan oluşuyor, onu da her satırda horizontal retrace sırasında CPU update ediyor, bu sayede farklı satırlarda farklı görüntü elde ediliyor. Aynı şey sprite'lar için de geçerli, onlar da 8-bit'lik register'lardan ibaret.
Edit: Bu arada yukarıda VSYNC sayacı demişim, ATARI TIA ile uğraşalı çok zaman geçtiği için aklım karıştı sanırım, HSYNC sayacı olması lazımdı. TIA'da zaten VSYNC sayacı yok, satır sayma işini de CPU hallediyor, VSYNC sinyali doğru zamanda bir register'a yazılarak oluşturuluyor.
-
Kaybolacaksa da bu başlık altında kaybolsun ki bulması kolay olsun :)
6502 emulatorü nasıl yazdığını anlatmış.
A Nicely Written 6502 Emulator in Common Lisp [PDF]
(http://redlinernotes.com/docs/cl-6502.pdf?)