Gönderen Konu: Donanım Penceresinden NewSchool  (Okunma sayısı 2546 defa)

0 Üye ve 1 Ziyaretçi konuyu incelemekte.

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Donanım Penceresinden NewSchool
« : 10 Mart 2020, 16:38:02 »
Donanım Penceresinden NewSchool

Merhaba,

Bir kısmınızın zaten bildiği üzere, bir yılı aşkın süredir Skate ile beraber 8-bit bir bilgisayar tasarlamaya giriştik. Son zamanlarda çeşitli ortamlarda, bölük pörçük, bilgisayarın özelliklerini, projenin ne durumda olduğunu, ilk prototip PCB’mizi ve hatta bazı ekran görüntülerini paylaşmaya başlamıştık. Geçenlerde Alco’nun dile getirmesiyle, bu bilgileri derleyip toparlayıp bir NewSchool güncesi oluşturmaya karar verdim.

Bundan sonra sıralı bir kaç post halinde, NewSchool’un ne olduğunu, neden böyle bir projeye giriştiğimizi, teknik özellikleri nasıl belirlediğimizi, projenin ne durumda olduğunu özellikle donanım penceresinden gördüğüm kadarıyla cevaplamaya çalışacağım. Talep gelmesi durumunda ilerleyen postlarda, elektronik tasarım ve hatta FPGA mimarisi de dahil olmak üzere daha detaylı teknik paylaşımlarda da bulunmak isterim.

Proje henüz tamamlanmaktan çok uzak olsa da tünelin sonundaki ışık artık kendini gösterdi. Bu vesile ile bu konu altında ilerleyen günlerde projenin gelişimini de muhtemelen paylaşıyor olacağız.

Öncesinde

Günümüz teknolojisi ile artık birkaç kişilik mikro ekiplerin, değil bir bilgisayar tasarlamak, bir işlemci hatta grafik kartı tasarlaması bile neredeyse imkansız hale geldi. Bu işler için artık kalabalık ekipler, milyonlarca dolarlık yatırım bütçeleri, ekipmanlar ve yazılımlar kaçınılmaz. Halbuki 80’lerde, iyi bir mühendis, “koskoca” C64’ün donanım tasarımına son direncine kadar hakim olabiliyordu. Al Charpentier, 1981 Ocak-Kasım ayaları arasında, büyük oranda manuel olarak VIC-II çipini tasarlamış ve çalıştırabilmişti. Aynı süreçte Yannes, SID çipini tasarlamış ve birkaç ay içerisinde 1982 CES fuarında C64 boy göstermişti.

Benzer şekilde Amiga 500’ün ortaya çıkış hikayesi de beni hep etkilemiştir. Bir şekilde o bilgisayarların tasarlandığı yıllarda, o ekiplerden birinin içerisinde olmayı hep hayal etmişimdir. 1982’de beş yaşında olan ben, o bilgisayarların tasarımında rol oynayabilecek seviyede bilgi birikimine en erken 15-20 yıl sonra erişebilecektim.

Yıllar içerisinde elektronik bilgim geliştikçe, C64 donanım tasarımı beni daha da çok etkiler oldu. Artık C64’ün donanımı neredeyse ezbere biliyordum ancak teknoloji o kadar ilerlemişti ki, 8-bit bir bilgisayar tasarlayıp çalıştırabiliyor olmanın da hiçbir anlamı kalmamıştı. Bu arada PC dönemi çoktan başlamıştı, 40’lı yaşlarımda geri döneceğimden habersiz, C64 ve AMIGA sevdamı içimde bir yerlere gömerek hayatıma devam ettim…

Beş yıl kadar öncesinde, önce C64 indi tozlu rafından. Doberman, megaOne, HDMI-64 projelerinden sonra sıra AMIGA’ya geldi. O da HDMI-520 ile nasibini aldı. Ancak halen bir bilgisayar tasarlama hevesim onu gömdüğüm yerde unutulmuş duruyordu, ta ki Skate ile iki yıl öncesinde yaptığımız bir sohbete kadar…

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #1 : 10 Mart 2020, 17:18:04 »
Başlangıç

David Murray’ın (the 8 Bit Guy), Commander X16 projesini başlatması sonrasında, henüz tasarım aşamasında olan bu proje için Skate’in bazı önerileri olmuştu. Kendisi daha detaylı anlatacaktır, hatırladığım kadarı ile, yazılım için gereksiz ve anlamsız yük oluşturan, blok kopyalama ve benzeri bazı işlerin donanım tarafından yapılması yönünde fikirler öne sürmüştü. Ancak ekip, bu tarz konuların öncelikleri arasında olmadığını belirterek bu istekleri geri çevirmişti.

Skate bana bu anekdotu anlattığında, zaten hep bir bilgisayar tasarlama hayalim olan ben hiç düşünmeden önerimi ortaya attım: “Boşver onları, biz kendi bilgisayarımızı kendimiz yapalım…” 😊

İş bölümünü gayet kolay hallettik. İstemleri ve özellikleri beraber belirleyecektik. Donanım tasarımı ve elektronik geliştirmeleri ben yapacaktım. Yazılım ve kernel tasarımın patronu da Skate olacaktı. David Murray’ın deyimi ile biz de kendi “rüya bilgisayarımızı” yapacaktık.

NewSchool adı da aslında programcıya kolaylık sağlayacak olan bu tarz işlemlerin eski usul değil, güncel teknoloji ürünü FPGA ve benzeri yeni yöntemler ile desteklenecek olmasından gelmektedir.

Bu arada NewSchool projesinde amaçlarımız dahilinde ticari kazanım ya da satış olmasa bile, tasarım bittiğinde istenildiği kadar üretilebilmeliydi. Yani en azından Skate ve bende en az birer kopya olacağından, el yapımı nadide bir kart olmayacaktı. İşte bu sebeple tasarım başlangıcında, kullanılacak tüm parçaların günümüzde halen üretilen ve temin edilmesi olası parçalar olmasına özen gösterdik.

Commander X16 Özellikleri ve NewSchool ile karşılaştırılması

Hızlıca yukarıda sözü edilen David Murray’in rakip bilgisayarının özelliklerine bakacak olursak, 8MHz hızında çalışan bir WDC6502 işlemci etrafında kurulu bir sistem olduğunu görüyoruz. Vera adında FPGA ile geliştirilmiş bir grafik modülü ve normal işlemci hafızasından izole 128KB grafik hafızası mevcut. Dolayısı ile ekranda görüntülenecek tüm grafik unsurları, Vera’nın hafızasına upload edilmek durumunda. İşlemci VIC-20’de olduğu gibi sabit 40KB’lık bir low memory’e ve 2MB içerisinden seçilebilir 8KB lık bir high memory’e erişebiliyor. David Murray’in projeye ilişkin en önemli beklentilerinden biri, açılır açılmaz C64’de olduğu gibi, BASIC çalıştırabilmesi.

Commander X16 ile NewSchool’un, ileride göreceğiniz üzere oldukça fazla ortak noktası mevcut. Örneğin aynı işlemciyi kullanıyor olmamız, görüntü çipi olarak FPGA kullanıyor olmamız örnek olarak gösterilebilir.

Ancak çok net farklılıklarımız da mevcut. Örneğin bizim BASIC gibi bir derdimiz hiç olmadı. Bu bilgisayarı, 6502 kodu yazmayı bilmeyen bir kitlenin, BASIC öğreneceği kullanıcı dostu bir platform olarak hiç görmedik. Zaten 6502’de adam akıllı bir şeyler yapmak isteyen bir programcının ilk yaptığı iş, BASIC ROM’u kapatmak oluyordu.

Proje bittiğinde seri üretimini yaparak satmak gibi bir derdimiz de olmadığı için, birçok durumda çeşitli kaygılardan uzak, hızlı ve efektif kararlar verebildik. Öncelik her zaman için bizim isteklerimiz oldu, kitlelerin ne isteyebileceği ile hiç ilgilenmedik. 😊

Commander X16, görüntü üretimi için normal hafızadan izole edilmiş 128KB bir RAM kullanıyordu. Bu ileride teknik detaylarda değineceğim üzere, Vera görüntü modülünün tasarımını kolaylaştırıyor. Zira aynı hafızaya hem Vera hem de işlemci aynı anda erişmek durumunda kalmıyor. Ancak biz bu konuda zor yolu seçtik, C64 de olduğu gibi görüntü modülümüzün tüm hafızayı görebilmesini istedik. Bu sayede 128KB gibi bir sınırımız olmayacağı gibi, sprite, karakter seti, hatta framebufferlerı RAM’de istediğimiz yere koyabilecek ve birkaç yazmaç değişikliği ile page switching yapabilecektik. Tabi ki aynı anda hem işlemci hem de görüntü modülü aynı hafızaya aynı anda erişmek durumunda olacağından donanım tasarımı da daha kritik hale gelecekti, bunu göze aldık.

Commander X16’da sabit bir 40KB lık RAM ve sadece 8KB’lık switch edilebilir bir pencere tasarlanmıştı.  Biz bunun yerine işlemcinin gördüğü tüm 64KB’lık alanı, 4 adet 16KB lık pencere halinde, 1MB içerisinden seçilebilir şekilde tasarladık. (Bu noktada Commander X16 tasarımında neden bu şekilde bir karar verildiğini halen anlayabilmiş değilim, teknik bir zorluğu olmamasına rağmen seçilebilir bölümü 8KB ile sınırlamak bana hiç de anlamlı gelmiyor.)

Bu arada WDC65C02 14MHz hızında çalışabilmesine rağmen, Commander X16 8MHz saat hızında çalışacak şekilde tasarlanmış. Bunun muhtemel sebebi kart üzerinde işlemci haricinde bu hızda çalışamayacak bazı elemanların bulunması olabilir, bilmiyorum. Ancak biz NewSchool’u 12.5MHz hızda çalıştırmayı hedefledik ve çevre elemanları da buna göre seçtik. (Neden 14MHz’de çalıştırmadığımızın basit bir cevabı var. Görüntü çıkış formatı olarak seçtiğimiz VGA sinyalinin piksel frekansı 25MHz olduğundan, bunun tam katı bir değer kullanıyor olmanın bazı teknik avantajları vardı.)

Son olarak bilindiği üzere 6502 komut seti, ZP bölgesinde daha hızlı çalışır. NewSchool tasarımında ZP bölgesini de switch edilebilir olarak tasarladık. Bu sayede 6502 için, hafızanın en lezzetli yeri olarak görülen bu 256byte’lık alan artık sınırsız hale gelmiş olacaktı. Yani 1MB hafıza içerisindeki istediğimiz bir bölümü alıp, sanki ZP’miş gibi çalıştırmak mümkün olacaktı.

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #2 : 10 Mart 2020, 20:37:56 »
İŞLEMCİ

Bir bilgisayar yapıyorsak ilk seçilmesi gereken ve belki de en önemli parça işlemci olmalı. Keza tüm mimari işlemci etrafında şekilleniyor olacak. Hesap makinasından öte, göze ve kulağa hitap edebilen işler yapabilecek minimum mimari 8-bit olmalıydı ve zaten proje başından beri o şekilde gelişti.

Günümüzde halen üretimi devam eden Z80 veya 6502 ailelerinden biri seçilebilirdi. Tabi ki bu noktada tercihimiz 6502 ailesi oldu. 6502’yi günümüzde WDC firması üretiyor. (https://www.westerndesigncenter.com/wdc/)

Firmanın ürünleri arasında, 8-Bit W65C02 ve 8/16-Bit W65C816 işlemcileri bulunuyor. C64 zamanlarından aşina olduğumuz 6510 assembler kodları çok büyük oranda bu işlemciler ile uyumlu. Hatta 6510’un undocumented kodları ve birkaç kodun farklı çalışması dışında tamamen aynı denebilir.

Başlarda 65C Ailesinden, 16-Bit veriyoluna sahip W65C816 işlemcisini kullanmayı da düşündük. Çünkü W65C02 deki 8-Bit veriyolu ile desteklenebilecek maksimum hafıza 64KB iken, 16-Bit veriyoluna sahip W65C816 ile 16MB hafıza desteklemek mümkün oluyordu. Tabi ki bizim hedeflediğimiz hafıza da 64KB üzerinde olacaktı. Ancak bu işlemcinin de doğal olarak destekleyebileceği maksimum hafızanın 64KB ötesinde olmasından başka sempatik bir tarafını da göremedik. 64KB üzerindeki bir hafızayı da bank değiştirme yöntemiyle zaten 8-Bit veri yoluna sahip bir işlemci ile de çözebileceğimizden, bu işlemciden kısa sürede vazgeçtik, bilindik 8-Bit 6502’nin güncel versiyonu diyebileceğimiz W65C02 ile devam etmeye karar verdik.

İşlemci seçimi sonrasında karar verilmesi gereken ikinci önemli birim, görüntü oluşturma çipi olacaktı. Ancak günümüzde üretilmeye devam eden ve aklımızdaki özelliklere sahip bir görüntü işlemcisi mevcut olmadığından bu kısmı FPGA ile kendimiz yapmaya karar verdik. Bu konuya yazının ilerleyen kısımlarında bolca değineceğim için hızlı geçiyorum.

Bu bir rüya bilgisayar olacağından, seçmiş olduğumuz unsurlar dahilinde, yapılabilecek en üst seviyedeki bilgisayarı tasarlamak istiyorduk. Örneğin W65C02 işlemcisi maksimum 14MHz de çalışabiliyordu. C64’ün 1 MHz hızında çalıştığını düşünecek olursak, sadece işlemciyi güncel bir versiyona çekerek 10 katın üzerinde bir hız artışı sağlayabilecektik. Tabi ki bu işlemci ile beraber çalışan çevre birimlerinin de daha hızlı çalışmak zorunda olmasını da beraberinde getiriyordu.

İşte bu noktada artık seçeceğimiz diğer birimlerin de hızı önemli olmaya başladı.

HAFIZA

NewSchool’un hafızasını başlarda 1MB RAM + 512KB ROM olarak tasarlamıştık. 1MB RAM, hemen hemen her türlü amaç için yeterli görünüyordu. 512KB ROM, her ne kadar yeni birimleri destekleyecek KERNEL kodu C64’e göre çok daha büyük olacak olsa da birden fazla KERNEL’e bile rahat rahat ev sahipliği yapabilecek büyüklükte idi.

İşlemciyi maksimum hızı olan 14MHz de çalıştıracağımızı varsayarsak 70ns erişim zamanlı hafıza çipleri işimizi görecekti. Ancak görüntü üretici ve benzeri diğer birimlerin de aynı anda aynı hafızaya erişeceğini düşündüğümüzde, çok daha hızlı hafıza çipleri kullanmamız gereği gün gibi ortadaydı.

Bilirsiniz C64 de işlemci 1MHz de çalışıyor olmasına rağmen, RAM’ler 2 katı hızda çalışır. Keza Phi2 dediğimiz sistem saatinin düşük ve yüksek periyodlarında, sıra ile hafızaya VIC-II ve 6502 erişir.

NewSchool için de benzeri bir durum gerekliydi. Görüntü üreten birimin kesintisiz bir şekilde hafıza erişimi olmalıdır ki ekranda raster hangi bölgeyi tarıyor ise o bölgedeki grafiği (arka plan, karakter seti, sprite vb…) hafızanın ilgili bölümlerini okuyarak anlık olarak üretebiliyor olmalıydı.

Bu noktada hafıza bant genişliği hesabını yapmak oldukça karışık bir hal almaya başlıyor ve aslında ilginçleşiyor. Örneğin, hangi renk uzayında, hangi çözünürlükte grafik desteği sunacağız? Kaç sprite aynı raster satırında basılabilecek? Karakter setlerinin yapısı ve boyutları ne olacak benzeri tüm soruların cevaplarını verebilmiş olmak gerekiyor ki, RAM ciplerinin erişim zamanlarının en az kaç ns olması gerektiği hesaplanabilsin.

Bu noktada, biraz kervan yolda dizilir mantığı ile hareket ederek, piyasada bulanabilecek en hızlı RAM çiplerini kullanmaya karar verdim. 10ns erişim zamanlı 1MB tek çip Statik RAM. Artık bir önceki paragrafta kısaca üzerinden geçtiğimiz sorulara cevaplar verebilmek çok daha kolay olacaktı. Zira hafıza bant genişliğimiz belli idi ve CPU erişimi dışında kalan zamana ne sıkıştırabilirsek onu destekleyecektik. :D

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #3 : 10 Mart 2020, 21:03:27 »
RENK SAYISI

Esasen renk sayısının seçimi, estetik kaygılardan öte teknik bir konu. En az 16 rengi destekliyor olmamız zaten gerekliydi, keza 80’li yıllarda tasarlanmış C64 ve hatta o dönemdeki birçok 8-Bit bilgisayar bile 16 rengi zaten destekliyordu. Verilmesi gereken karar üst sınırın ne olması gerektiği idi.

İşte bu noktada konuyu teknik yönden değerlendirdiğimizde, 16 renk 4-bit ile temsil edilebiliyorken, 256 renk 8-bit ile temsil edilebiliyordu. Yani aynı çözünürlükte bir grafik için renk sayısını 16 kat arttırıyor olduğumuz halde, hafızada kaplanan yer sadece iki katına çıkıyordu. Bize en efektif gelen renk derinliği de bu oldu. Zaten 256 renk, bu kapsamdaki bir bilgisayar için hayli hayli yeterliydi. 320x240 tam ekran 256 renk bir bitmap hafızada 76K civarında bir yer kaplıyordu.

5,6,7 bit/piksel gibi 32,64,128 renk paletleri ise hiç düşünmedik bile. Hafızadaki her byte ancak tam sayıda pikseli temsil edebiliyorsa kullanım açısından efektif olabilecekti.
Bu karar verildikten sonra daha zor bir konu kendiliğinden ortaya çıktı. Bu sözü edilen 256 renkli palet hangi renklerden oluşacaktı? Daha zor bir karardı zira artık bu teknik olmaktan öte, tamamen artistik bir seçimdi.

Bu noktada topu açıkçası taca atarak, bu artistik kararı tamamen teknik bir şekilde çözdük. Kullanıcı kendi 256 renk paletini kendisi belirleyebilecekti. Tabi ki her ne kadar kullanıcı kendi renklerini belirleyebilecek olsa da bir varsayılan palet sunmak gerekiyordu. Bunu da gene bir gece discord retrojen kanalında konunun uzmanlarına da danışarak birkaç saat içerisinde belirledik. 😊


Varsayılan NewSchool Paleti

Sonuç olarak, NewSchool mimarisinde, 256 renkli bir Color Lookup Table olacaktı. Kısaca CLUT olarak adlandırdığımız bu 512 byte’lık hafıza (ya da yazmaç) bölgesi, kullanıcı tarafından tanımlanabilir 256 rengin RGB değerlerini içeriyor olacak. Her bir renk bileşeni 4-bit ile temsil ediliyor olacak. Her bir palet girdisi için 12-bit gerekirken, gene hafıza hizalama açısından, her bir renk girdisine 16-bit ayıracaktık.

Bu arada Skate’in özellikle istediği bir mevzu da hangi renk yada renklerin şeffaf olacağına kullanıcının karar verebiliyor olmasıydı. Aslında bu bilgisayar ile kodlanabilecek efektler düşünüldüğünde çok da mantıklı bir istek. Donanımsal olarak şeffaf rengin önceden belirlenmiş ve değiştirilemiyor olması aslında efektif olarak kullanılabilecek renk sayısını 256’dan 255’e düşürmüş oluyor. Aynı zamanda örneğin şeffaf renge ihtiyaç duymayan bazı efektlerde, özellikle color cycling gibi algoritmalar yazıldığında süreksizliğe sebep olacaktı. Aynı şekilde birden çok rengin o an için şeffaf olarak tanımlanabilmesi ile, fade in/out, disolve gibi efektler sadece palet girdileri ile oynanarak kolaylıkla üretilebilir olacaktı.

Bunu uygulamak teknik olarak mümkün olsa da getireceği donanımsal bir yük olacaktı. Video grafik üreticisi her bir pikselin renk değerini hesaplarken, o piksele etkisi olan, arkaplan, bitmap, karakter seti, sprite gibi unsurları z derinliklerine göre önden arkaya doğru sıralayarak, şeffaf olmayan bir palet girdisine denk gelene kadar bir sonraki unsurun renk değerini okuyacak şekilde çalışmalıydı. Eğer şeffaf rengin girdisi biliniyor olsaydı, unsurlar teker teker okunurken, her birinin piksel değerini CLUT tablosundan çekmeye gerek olmayacaktı. Ancak şimdi, rengin şeffaf olup olmadığı CLUT içerisindeki o kullanılmayan 4 bitten birinin içerisine yazıldığından her bir unsurun renk değeri önce CLUT’dan çekilecek, ilgili rengin şeffaf olup olmadığına karar verilecek, şeffaf ise bir sonraki unsura geçilecekti.

Kısacası ekranda görüntülenecek her bir piksel için tek bir CLUT lookup yapılacakken, şimdi o piksele etkisi olan her bir unsur için ayrı ayrı CLUT lookup yapılacaktı. Aslında bu noktada sözünü ettiğimiz bu donanımsal yükü göze almışken, yapılabilecek bir başka teknik güzellik daha kendiliğinden ortaya çıkmış oldu. Bu konuya daha sonra tekrar değinmek üzere, şimdilik geri kalan o 3-bit ile neler yapmış olabileceğimizi sizin hayal gücünüze bırakıyorum… 😉

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #4 : 10 Mart 2020, 21:23:06 »
VIDEO ÇIKIŞI

NewSchool’un video çıkışının analog VGA olacağını duyan birçok arkadaşım, neden HDMI çıkış yapmadığımızı sordu. Esasen FPGA ile HDMI çıkış üretme noktasında yeterince tecrübem olmasına rağmen, HDMI çıkış üretmenin bazı sıkıntılı yanları da var.

Öncelikle HDMI sinyalini elektriksel standart ve veri içeriği olacak şekilde iki ayrı açıdan irdelemek gerekiyor. FPGA ile HDMI verisini üretmek mümkün olsa da aslında tam olarak elektriksel gereksinimleri karşılamak mümkün olmuyor. Salt FPGA ile üretilen HDMI çıkışı elektriksel standartları tam karşılamadığı için de her TV seti ve monitörde sorunsuzca gösterileceğinin bir garantisi yok. Elektriksel standartları tam olarak sağlayan bir çıkış sinyali üretmek için, bu iş için özel olarak üretilmiş, HDMI transmitter çiplerinden birini kullanmak gerekiyor. Maalesef bu çipler de sadece HDMI Alliance üyesi firmalara satılıyor. Zira aslında pek bilinmese de HDMI sinyali açık lisans değil, HDMI sinyalleri ile bir şekilde ilgisi olan bir cihaz üretebilmek için lisans sahibi olmak gerekiyor.

İşin yasal kısmını bir yana bırakacak olursak, bir şekilde bu çipleri Çin piyasasında el altından temin etmek mümkün olabiliyor, bir şekilde el altından çiplere ait dokümantasyonu da edinmek mümkün. Ancak gene de çıkış çözünürlüğü çok da yüksek olmayacak ve hatta günümüz standartlarına göre oldukça düşük sayılabilecek bir bilgisayar için HDMI çıkış yerine analog VGA çıkış kullanmak bana açıkçası daha otantik geldi. Bu arada analog VGA girişinin halen birçok monitör ve TV seti tarafından desteklendiğini de düşünecek olursak, şu an için bu seçimin bir dezavantajını görmedim.

Hazır söz çözünürlüğe gelmişken, neden 320x240 piksel tercihinde bulunduğumuza da kısaca değinmek isterim. Esasen, analog VGA sinyali zaten bilindiği üzere 640x480 pikseldir. Bu seviyede bir bilgisayar için bundan daha da yüksek çözünürlükleri desteklemek gibi bir niyetimiz zaten hiç olmadı.

Peki neden en azından 640x480 değil?

640x480 çözünürlüğünü doğrudan destekleyecek olsaydık, tek bir framebuffer ya da 8bpp tam ekran görüntü için, 300Kbyte üzerinde bir hafıza ayırmamız gerekecekti. C64’ün 320x200 lük, 1bpp monochrome hi-res modunu düşündüğümüzde, bu çözünürlüğü 8bpp olarak kullanabiliyor olmak bile bize gayet yeterli geldi. Aslında çözünürlük düşük olsa bile 256 renk kozu uygun şekilde kullanıldığında, piksellerin tek tek sayılması oldukça güç olmaktadır.

Aynı zamanda hafıza tüketiminin yanı sıra, 320x240 destekliyor olmak işlemci gücünden de 4 kat tasarruf etmek anlamına geliyordu. İşlemci saat frekansımızın C64’e göre en az 10 kat daha yüksek olacağından bahsetmiştik. Eğer 640x480 destekleseydik bu avantaj gene C64’e kıyasla 2.5 kat artışa tekabül edecekti. Yani güncel işlemci kullanarak elde ettiğimizin avantajın büyük kısmını yüksek çözünürlükte görüntü üretmek karşılığında geri vermiş olacaktık.

Hatırladığım kadarıyla çözünürlük konusunda Skate ile tek bir konuda fikir farklılığımız olmuştu. Ben 320x240 içerisinde, alttan ve üsten border bırakarak, 320x200 piksellik bir çalışma alanımızın olmasının daha doğru olacağını düşünmüştüm. Çünkü 320x200, 8bpp bir tam ekran görüntü, 64KB altında yer kaplıyordu, birden çok framebuffer kullanılacağı durumlarda hafızada güzelce 64KB’lık sınırlar dahilinde hizalanabilirdi. Ayrıca C64 de 320x200 çözünürlükte çıkış üretiyordu. 😊 Skate ise kullanabildiğimiz maksimum alanı kullanmanın daha doğru olacağı yönünde fikrini öne sürdü, zira C64’te o border’ları açmak için kırk takla atıyorduk. 😊

Dezavantaj olarak 320x240, 8bpp görüntü hafızada 76KB gibi yer kaplıyor olacaktı. Aslında bu hafıza hizalama noktasında teknik bir zaruret olmamasına rağmen, geçmişten gelen alışkanlıkların ötesinde bir dert olmadığı konusunda hemfikir olduk ve çıkış çözünürlüğünü 320x240 olarak belirledik.

Özetle;
-   Bu cihaz üzerinde yüksek çözünürlüklü video oynatma vb. amaçlarımızın olmaması,
-   Nispeten düşük çözünürlükte çıkış üretmenin hafıza ve işlemci tüketimini azaltacak olması,
-   Kullanılacak karakter setinin 8x8 gibi rahat bulunabilir ve tasarlanabilir olması,
-   Özellikle piksel art çalışmalar için bu çözünürlüğün çok daha uygun olması,
-   80’lerin retro ruhunu daha çok yansıtacak olması,
-   Zaten 256 renk gibi bir lüksümüzün olması
Gibi sebepler ile bu çözünürlükte karar kıldık.

Şimdi burada mecburen uygulamak zorunda kaldığım bir ahlaksızlıktan ve bu sayede üretebiliyor olduğumuz bir efektten bahsederek konuyu kapatacağım.

Her ne kadar çıkış çözünürlüğümüzün 320x240 olduğuna inansak da aslında gerçekte çıkışımız 640x480. 😊 Çünkü modern monitör ve TV setlerinde desteklenen en düşük çözünürlük bu. Ayrıca Endüstri Standardı VGA sinyali de 640x480@60Hz olarak belirlenmiştir ve standartlara göre güncel tüm monitörlerin en azından bu çözünürlüğü desteklemeleri zorunludur.

Peki bu nasıl oluyor? FPGA içerisinde tüm işlemler 320x240 çözünürlüğü ve zamanlamasına göre hesaplanıyor. Hatta aslında gerçekte olmayan sanal bir raster gene bu çözünürlük ve zamanlamasına göre, sanal bir ekranı tarıyor. Gene bu sanal raster ile işlemci interruptları üretiliyor vb… FPGA içerisinde bu işlem ile eş zamanlı olarak çalışan ayrı bir devre, üretilen her bir satırı alıyor ve scan doubling yaparak, çözünürlüğü iki katına çıkarıyor. Yani sanal raster 320 piksel genişliğinde bir satırı tararken, bir başka devre bir önce taranmış olan ekran satırını alıp, iki katı hız ile aynı sürede iki kere 640 piksel satır olarak tarayarak çıkışa gönderiyor. (Gerçek rasterin tarama hızı, sanal rasterin iki katı ancak gerçek rasterin taradığı piksel sayısı, sanal rasterin taradığının dört katı. Çünkü sanal raster bir adet 320 piksellik satır taradığı sürede, gerçek raster iki adet 640 piksellik satır tarıyor)
İşte bu sayede, işlemci tarafından set edilebilen bir yazmaç biti ile, scanline efekti yapabiliyoruz. İki kere çıkışa gönderilen satırlardan birinin luma değerini bir miktar kısarak (tamam gereksiz havalı bir kullanım oldu bu, sadece RGB değerlerini 1 bit sağa kaydırıyoruz diyelim), kendimizi 80’li yılların fosfor ekranına bakarken buluyoruz… 😊


Scanline efektine dair bir örnek...

Dikkatli okuyanlar belki fark etmiştir, yukarılarda bir yerlerde 60Hz lakırdısı geçti. Evet biz PAL bölgedeyiz, ancak NewSchool ekran tazeleme hızı 60Hz. Bu animasyonların daha akıcı görünmesine katkısı olacak bir nüans ancak 50Hz için yazılmış müziklerin çalınmasında ileride başımıza ciddi dert açacak gibi duruyor. Neyse onun için de bazı çözümlerimiz olacak. Müzik demişken, ses ile devam edelim …

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #5 : 10 Mart 2020, 22:40:55 »
SES

Ses çıkarmayan bir bilgisayar tasarlıyor olmamız tabi ki düşünülemezdi. Aslında bu konuda teknik olarak uygulanabilecek en kolay çözüm, basit iki ya da daha çok kanallı DAC tasarlamak olabilirdi. Bu sayede kullanıcı, çeşitli hızlarda örneklenmiş sesleri hafızada bir yerlere yerleştirecek, DAC yazmaçları ile loop ya da single olacak şekilde bu bölgelerin çalınmasını sağlayabilecekti. (Amiga500 de olduğu gibi) Bu şekilde mod tarzı parçaların çalınması ve oyunlar için ses efektlerinin üretilmesi mümkün olabilirdi. Ancak herhangi bir sebeple bir ses sentezlenmek istenildiğinde, gene tüm yük işlemciye düşecekti.

Üzerine ince ince düşünerek tasarladığımız bu rüya bilgisayarın ses konusunda sadece bir digital sample player olmasını hiç istemedim. Bu bilgisayar bir şekilde ses sentezleyebilmeliydi. Basit bir ses sentezleyicisi tasarlamak çok zor olmasa da bu noktada ruhu olan ya da bir şekilde geçmişte kendini kanıtlamış bir çip seçerek yola devam etmek daha doğruydu. Zira ikimiz de ses sentezlenmesi konusunda yeterli bilgi birikimine sahip değildik. Günümüzde üretilmiyor olsa da halen bulunabilir olan Yamaha YM2612 çipini kullanabileceğimizi düşündük ve bir uzmanına danışmaya karar verdik. Konuyu Matahari’ye açtık.

Matahari, Yamaha seçimimizi destekledi ve hatta daha da öteye götürerek, doğrudan çipi kullanmak yerine FPGA içerisinde gerçeklememizin daha sempatik olabileceğini söyledi. Bu sayede çip tercihini ileride değiştirebilecektik ve gerektiğinde de modifikasyonlar yapabilecektik.

Bir başka görüşü ise, bu gibi çiplerden birden fazlasının aynı kart üzerinde bulundurarak, her bir çipin kendi kimliğini ön plana çıkaracağı geniş bir ses rengine sahip bilgisayar tasarlamanın daha doğru olabileceği yönündeydi.

Konuyla ilgili olarak kendi RAM’i olan DAC’lardan, çiplerin metalik tınılarını bastırmak üzere tasarlanacak analog çıkış filtrelerine kadar çok çeşitli konularda tavsiyelerde de bulundu. Teşekkür ederiz…

Kullandığımız FPGA’in sınırlı kapasitesi sebebi ile, ses çipini FPGA içerisinde gerçeklemek pek mümkün görünmüyordu. Bu sebeple Yamaha YM2612 çipi ile devam etmeye karar verdik ancak Matahari’nin birden çok ses çipi tavsiyesi ve özellikle her bir çipin kendi kimlikleri konusundaki görüşü aklımdan çıkmıyordu. Çok mantıklı gelmişti. Tabi “ses çipi” ve “kendi kimliği” tanımları bana nedense SID çipini çağrıştırdı. 😊 Konuyu Skate’e açtım, O da hemen kabul etti. Rüya bilgisayarda hem YM-2612 hem de SID çipi bulunacaktı.

SID çipinin mono olan çıkışını hem sağ hem de sol kanala mix edecek şekilde bir analog çıkış katı tasarladım. YM-2612’nin zaten stereo olan çıkışları ise doğrudan ilgili kanallara gönderiliyordu. Her iki çip için de çıkışta sabit analog filtreler bulunacaktı. Ses konusu da en azından teorik olarak bir şekilde çözülmüştü.

Teknik açıdan değerlendirdiğimizde, projenin başında vermiş olduğumuz bir kararı, şimdilik sadece ses konusunda göz ardı etmiş olduk. Evet, SID artık üretilmiyordu, bulunması da zordu. Ama en azından birkaç farklı bire bir uyumlu SID alternatifi projesi vardı ve halen üretilmekteydi.

SID ve YM2612 ile ilgili bir başka problem ise, işlemciyi çalıştırmayı düşündüğümüz 12.5MHz gibi yüksek hızlarda bu çiplerin çalışamayacak olmasıydı. Bunun için FPGA içerisinde bir çözüm uygulamayı planladık. İşlemci yüksek hızda bu ses çiplerine yazmak istediği değerleri push edecek, FPGA bunu bir FIFO buffer içerisinde tutacak ve daha yavaş bir hızda ses çiplerine iletecekti. Henüz bu kısmı gerçekleştirmedik ama planımız bu yönde.

Bu çözümün ileride bize bir avantajı daha olacaktı. 60 fps ile çalışan işlemcimiz ile, eskiden 50 fps için yazılmış SID müziklerini çalmak istediğimizde bir derdimizin olacağından bahsetmiştik. İşte bu FIFO buffere push edilen değerlerin, ne zaman ses çiplerine yazılması gerektiğini de eğer bu sırada organize edersek, bir derdimiz daha çözülmüş olacaktı.

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #6 : 10 Mart 2020, 22:56:05 »
Giriş Çıkışlar ve Dış Dünya

Bu noktada artık güncelliğini tamamen yitirmiş ve hatta piyasada bulunamayan, PS/2 klavyeler, ATARI tipi joystickler, kendine özgü protokolleri olan mouse’lar için destek vermeye çalışmak yerine, tek bir güncel USB Host portu bırakmayı uygun bulduk. Bu USB portu ile, çeşitli kablolu/kablosuz USB klavye ve mouse, joystick ve hatta memory stickler için destek vermeyi planladık. Tek bir USB portun yetmeyeceği düşünülebilir, ancak bir USB HUB kullanılarak portun çoklanması mümkün. Belki ileride yeni bir PCB revizyonu yapacak olursak (ki muhtemelen yapacağız), USB HUB’ı PCB üzerinde tasarlayarak birden çok USB portu bırakabiliriz.

Cross development ve debug desteği için ayrıca bir USB bağlantı noktası daha düşündük. Bu port ile NewSchool doğrudan PC üzerinde çalışan debug uygulamamız ile haberleşebiliyor. Bu uygulama ile NewSchool çalışırken eş zamanlı olarak tüm hafıza ve yazmaçlara erişebiliyor ve hatta manipüle edebiliyoruz. Hatta öyle ki, NewSchool üzerinde ilk zamanlarda henüz bir işlemci bile yokken, yazmaçlara erişerek grafik modlarını set edebiliyor, ekran belleğine yazarak ekranda görüntülenmesini sağlayabiliyorduk.

Bu debug portunun bir başka görevi ise, NewSchool dahilinde bulunan Flash ROM’u okumak ve programlamak. Bu sayede KERNEL, Karakter Seti ve benzeri değişiklikleri, ayrıca bir flash programlayıcıya ihtiyaç duymadan, PC üzerinde çalışan debug uygulamamız ile yapabiliyoruz.

Bunun haricinde ekstra bir genişleme yuvası bırakmadık, ihtiyaç olacağını da düşünmüyorum. Eğer ekstra bir ihtiyaç ortaya çıkarsa, USB üzerinden haberleştirebileceğimiz gibi, eğer ek bir donanım ihtiyacı olmayacaksa, kolaylıkla FPGA içerisinde de bu ihtiyacı karşılayabiliriz.

DEPOLAMA

Kaset, floppy gibi bilindik çeşitli retro depolama cihazlarına destek vermek istemedik. Keza artık günümüzde, güncel bir bilgisayar ile bu medyaların kullanımı çok da anlamlı değil. Bunun yerine şimdilik sadece tek bir SD kart yuvası olmasının yeterli olacağını düşündük.

AUTISTIC

Temel amacı görüntü oluşturma olan ve FPGA içerisinde tasarladığımız çipin kod adı AUTISTIC ve isim babası Skate. AUTISTIC, aslında sadece görüntü üretmekten öte, aynı zamanda işlemcinin hafıza erişimi, birtakım işlemlerin hızlandırılması (block fill, DMA copy, hardware multiplication vb…), ses çiplerine yazılacak verilerin senkronizasyonu, PC iletişimi, belki SD kart ve USB giriş çıkışı gibi görevleri de üstleneceğinden, aslında tasarladığımız bilgisayarın en önemli unsuru haline gelmiş oldu. Tüm bu sayılan görevleri de tek bir cycle gecikmeden tam zamanında yerine getiriyor olmalı ki, üretilen görüntüde herhangi bir artifact oluşmasın. İşte tam da bu sebeple, bu kadar çok farklı işin mükemmel bir senkronizasyonla tam zamanında icra edecek olmasından ötürü çipin adını AUTISTIC olarak belirledik.

AUTISTIC Teknik detaylarına belki daha sonraki postlarda değiniriz ancak şu an için belirli olan özellikleri şu şekilde sıralayabiliriz:

-   320x240 - 8,4,2,1 bit/piksel, (256,16,4,2) renk bitmap
-   Ayrı anda faklı bir katmanda açılabilecek, 40x25 satır, 8x8 piksel, 8,4,2,1 bit/piksel karakter ekranı
-   Aynı raster satırında maksimum 16 adet, 8,16,24 veya 32 piksel genişlikte ve maksimum 256 piksel yükseklikte, 8,4,2,1 bit/piksel sprite gösterimi
-   700-800 cycle/line işlemci hızı


NewSchool PCB'si, ilk sürüm üretime girmeden önceki son tasarımı

Şimdilik paylaşacaklarım bu kadar, NewSchool'un ortaya çıkışı ve donanım mimarisi hakkında biraz da olsa fikir verebildiğimi umuyorum.
Projenin ilerleyen safhalarında görüşmek üzere...

Çevrimdışı 68k

  • Retro Meraklısı
  • ***
  • İleti: 247
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #7 : 11 Mart 2020, 22:27:34 »
Süpermiş  8) elinize sağlık, gelişmeleri merakla takip ediyor olacağım  :)

Çevrimdışı gibraltar

  • Retro Meraklısı
  • ***
  • İleti: 140
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #8 : 11 Mart 2020, 22:52:40 »
eins, projenizin ayrıntılarını lütfen aktarmaya devam ediniz, sabırsızlıkla takip ediyorum.


Sayın retrojen pano erkine not: Son zamanlarda forumda oldukça fazla bilgi seli kıvamında girdi oldu. Bunları forumun dışında bir yerlerde düzenli bir formatta görmek mümkün olsa keşke. Ne bileyim düz a4 formatında, mizanpajlı falan gibi...  ??? 
Bilgehan Korkmaz

Çevrimdışı fullgrim

  • Retro Meraklısı
  • ***
  • İleti: 143
    • Adventure Attacks!
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #9 : 13 Mart 2020, 00:20:32 »
Discord grubundan uzak olduğumdan haberim yoktu, çok ince düşünülmüş bir projeymiş, umarım seri üretime geçebilirsiniz. Madem yorum yazdım, bir amatör olarak kıytırık bir öneri de yapayım: açılışta direkt BASIC çalıştırması otantik olarak daha ilgi çekici olabilir. Ek bir ROM ve devreden çıkaracak bir switch sistemi ile sanırım her 2 tarafı da mutlu edebilirsiniz; isteyen BASIC ile başlar, isteyen de BASIC ROM'u donanımsal olarak devre dışı bırakıp başlar.

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #10 : 13 Mart 2020, 09:09:13 »
Selam fullgrim,

Seri üretmek gibi bir planımız şimdilik yok ama BASIC konusunda, istenirse, bilgisayar açıldığında çıkan konsoldan kolaylıkla yüklenebilir. Esas dert açık kaynak bir BASIC seçip, bu bilgisayara göre özelleştirilmesini sağlamak... Belki Skate yada bir başka gönüllü bu işe talip olabilir... :D
 

Çevrimdışı Alcofribas

  • Yönetici
  • Özgür Retrocu
  • *
  • İleti: 1925
  • "Kahraman olmak, dürüst olmaktan kolaydır" Luigi P
    • Sizin Amstrad
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #11 : 13 Mart 2020, 14:08:04 »
Bu konu başlığına yakışır şu videoyu da ekleyelim hemen.


Çevrimdışı hades

  • RAAT
  • Retro Meraklısı
  • *
  • İleti: 143
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #12 : 13 Mart 2020, 16:10:55 »
NS'nin açılımı aslında New Spectrum. 65c02 kamuflaj amaçlı olup gerçek cpu 20Mhz'lik Z80.
NS-02 Z80 tabanlı olacak. Kesin bilgi yayalım.

Şaka bir tarafa NS'nin bir de Z80'li versiyonu olsa süper olur.

Çevrimdışı eins

  • RAAT
  • Retroman
  • *
  • İleti: 25
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #13 : 13 Mart 2020, 16:28:21 »
Şaka bir tarafa NS'nin bir de Z80'li versiyonu olsa süper olur.

Abi, onu da senden bekliyoruz... ;)

Çevrimdışı Skate

  • RAAT
  • Retroman
  • *
  • İleti: 60
Ynt: Donanım Penceresinden NewSchool
« Yanıtla #14 : 13 Mart 2020, 23:36:58 »
İlker çok güzel özetlemiş New School'un hikayesini. Hatta o kadar güzel özetlemiş ki üzerinde kalem oynatamayacağım, her şey birebir anlattığı gibi gelişti.

Öncelikle projenin şu ana kadar olan gelişmesinde ne yazık ki çoğunlukla beyin fırtınasından öteye geçen bir katkım olamadı. Projeye ilk başladığımızda donanımın ortaya çıkmasının epey zaman alacağını bildiğim için tamamen boş durmamak adına Commodore 64'ün kernal ve basic ROMlarını çöpe atıp, sıfırdan bir kernel kodlamaya başladım. Ekteki videoda ilk çalışır örneklerinden birini görebilirsiniz.



Burada cursor'ın blink etmesinden, klavye matrisinin çözümlenmesine her şeyi sıfırdan yapmak durumunda kalıyoruz. Komutlar için bir parser yazmak ve bunu ilgili fonksiyonlara yönlendirmek gerekiyor. Kernel'i KickAssembler ile geliştiriyoruz. Olabildiğince esnek bir yapı sağlıyor bize. Kaynak kodlardan bir kaç örnek;

Kod: [Seç]
.var commandsList = List().add(
List().add("cls", ClearScreenWithPrompt),
List().add("ver", ShowVersion),
List().add("reset", HardReset)
)

// Process Command
ProcessCommand:
lda CommandIndex
.for (var i = 0; i < commandsList.size(); i++) {
cmp #i
bne !+
jmp (CommandPointers+(i*2))
!:
}
rts

CommandList:
.for (var i = 0; i < commandsList.size(); i++) {
.var commandName = commandsList.get(i).get(0)
.for (var j = 0; j < commandName.size(); j++) {
.var char = commandName.substring(j, j+1).charAt(0)-64
.byte char + ((j == commandName.size() - 1) ? 128 : 0)
}
}
.byte 0

CommandPointers:
.for (var i = 0; i < commandsList.size(); i++) {
.var commandAddress = commandsList.get(i).get(1)
.byte <commandAddress
.byte >commandAddress
}

Sonuç olarak yeni bir komut mu eklemek istiyoruz? Başta tanımlanan commandsList'e

Kod: [Seç]
List().add("komutismi", EtiketIsmi),

gibi bir satır eklediğiniz durumda artık command line'a yazacağınız "komutismi" komutu algılanıyor ve kodun içindeki "EtiketIsmi" etiketinin olduğu yere atlanıyor. Tabii bunlar hep başlangıç seviyesi kodlar ve bu noktada pauseladım çalışmaları. Çünkü örneğin C64'ün keyboard matrisini çözümleme koduna ciddi bir zaman harcıyorsunuz ama sonuç olarak New School'da yapacağımız şey ile yakından uzaktan alakası yok, yapılan şeylerin çoğu çöpe gidecek. Bu nedenle bu noktada kernel kodlamaya devam etmek için donanımın bitmesini beklemeye kadar verdim. Tabii ki başka çalışmalarım da oldu bununla ilgili, o konudan bir sonraki postta bahsedeceğim.