commodore.gen.tr

Youtube'da milletin projelerini izlemek falan insanı odaklandığı yerlerden hakikaten saptırıyormuş.

https://www.youtube.com/watch?v=LpRaHkqjqJk (https://www.youtube.com/watch?v=LpRaHkqjqJk)

Şunu izledikten ve Jim Brain'in aşağıdaki linkteki switchsiz, kablosuz şöyle olur mu gibi önerisini gördükten sonra bu projeyi yapmaya karar verdim.

http://cbm-hackers.2304266.n4.nabble.com/Switchless-ROMs-td4662130.html (http://cbm-hackers.2304266.n4.nabble.com/Switchless-ROMs-td4662130.html)

İlk videoda paylaştığım mod kernal'ın 8K'lık bir rom'da tutulduğu c64'ler için. Switch'siz ancak iki adet kablo gerektiriyor yine de.

Benim hedeflediğim board'lar ise 250469 no'lu kernal ve basic'in bir 16K'lık rom'da bulunduğu C64'ler. Elimde hali hazırda bu rom'u soketli olan bir C64 olduğu için denemesi de kolay olacak.

Bu projeyi uçtan uca yapacağım ilk proje olarak ele alacağım. Bu sefer breadboard üzerinde takılmak yok. Gelişme aşamalarını şu şekilde sıralayabilirim.

1. Genel olarak işleyişi ve devreyi kafada kurgulama [YAPILDI]
2. Devrenin şemasını çizme [YAPILDI]
3. PCB'yi tasarlama ve üretme (Özay'ın önerdiği EasyEDA üstünden sipariş edeceğim direkt) [YAPILDI]
4. PCB yolda beklenirken Microcontroller ve C64 tarafı için kod yazma [YAPILDI]
5. PCB'lerin gelmesi, Test&Development. [YAPILDI]
6. PCB tasarımının revize edilmesi. Malzeme siparişi.
7. Kullanım klavuzu hazırlama, ince işçilik.


Projenin tasarım aşaması bitti, hedeflediğim gibi 250469 board'larda canavar gibi çalışıyor :)

gwpgLJTUj-I

1. Genel olarak işleyişi ve devreyi kafada kurgulama

Bu basic ve kernal rom'larının birleştirildiği rom'lar haliyle 8k+8k = 16k. Cpu'nun adres bacaklarından A0 ile A13 arası hatları kullanıyor.

Projede yaygın kullanılan 64K kapasiteli 27C512 eprom kullanmayı düşünüyorum. Normal şartlarda sadece kernal'ı değiştirip, basic'i aynı bıraksak basitçe 4 değişik kernalin yüklenebildiği bir mod da yapabilirdik.

Benim hedeflediğim çözümde ise,

1. Basic aynı kalmak üzere 7 farklı kernal olabilmeli. (Projeyi ilk açarken hatalı bir şekilde 8 yazmışım bu arada :) )
2. Herhangi bir switch yahut kabloya ihtiyaç duymamalı.

Şimdi ilk gereksinimi çözmek için C64'ün bellek modeline bir göz atıyoruz.
Basic C64'de A000-BFFF adresleri arasında yer alıyor, Kernal ise E000-FFFF arasında. Ancak bunlar bu 16K rom'da adreslenirken 16K'lık çipin A13 adres hattının 0 ya da 1 olmasına göre ayrılıyorlar. 0 ise basic rom seçilmiş oluyor, 1 ise kernal.

Yeni 64K'lık rom şu şekilde organize edilmiş olacak,

Kernal 7 - E000 - FFFF
Kernal 6 - C000 - DFFF
Kernal 5 - A000 - BFFF
Kernal 4 - 8000 - 9FFF
Kernal 3 - 6000 - 7FFF
Kernal 2 - 4000 - 5FFF
Kernal 1 - 2000 - 3FFF
Basic    - 0000 - 1FFF

7 adet kernal arasında switch yapabilmek için 3 seçim sinyaline ihtiyacımız var. (2^3 >=  7)

111 -> Kernal 7, 001 -> Kernal 1 olacak. 000'da basic olduğu için bu seçim anlamsız oluyor ve kullanıldığı durumda c64'ümüz açılmaz.

Mevcut rom üstündeki A13 hattının Basic ve Kernal açısından seçici olduğundan bahsetmiştik. Bu durumda A13 sıfır olduğunda yeni koyduğumuz 64k'lık eprom'un en üst üç adres biti her zaman sıfır olmalı. A13 bir olduğunda ise 7 kernal'den istediğimizi seçmemiz mümkün.

Biraz kafa yorduktan sonra da bu işi basitçe PLA'dan gelen A13 hattını bizim 3 adet olan her bir seçim hattımızla VE mantık kapısıyla bağlayarak çözebileceğimizi görüyoruz.

Yani Eprom'un ekstra olan adres bacakları şu şekilde olacak,

A15 = PLA_A13 AND SEL2
A14 = PLA_A13 AND SEL1
A13 = PLA_A13 AND SEL0

Bu şekilde PLA_A13 sıfır değerini içerirse A13, A14, A15 sıfır olmakta, yani seçtiğimiz 8K her zaman üstteki bellek şemasında en altta bulunan basic'i göstermekte. PLA_A13 bir olduğunda ise SEL sinyallerimizde seçtiğimiz bank neyse o bank'taki kernal'e erişim olacak.

Bu şekilde 64K rom içine basic sabit kalmak üzere 7 adet kernal'i seçebiliyoruz. Buraya kadar sadece 7 adet kısmına cevap bulduk aslında.

Saat geç olmuş; switchsiz ve kablosuz kısmına daha sonra geleceğim. Bu noktadan sonra 2 alternatif var, birinde kullanılabilecek custom kernal sayısı 6'ya iniyor. Okuyana egzersiz olarak kalsın şimdilik.

Bence ATtiny13 gibi boşta 3 adet output ve 2 adet input pini olan bir MCU ile kolaylıkla yapılabilir bu dediğin. Şöyle ki:

* 3 adet output EPROM A13, A14, A15'i kontrol edecek.
* 1 adet input PLA_A13'ün değerini okuyacak
* 1 adet input RESTORE tuşu kontrol edecek, 5 saniyeden uzun basılırsa bir sonraki BANK'a geçiş yapacak, tabi önce yazılımla senin yukarıda verdiğin formülle A13, A14, A15'in değerlerinin hesaplaması gerek.

Böylece C64 tarafında herhangi bir yazılıma da gerek kalmaz, tembel işi. :D

basitlik iyidir banada oldukça olası ve mantıklı göründü

Hala Kiss prensipleri diyorsun :)
Basitlik iyidir ancak sadelik daha iyidir :) Bu çözümde Restore tuşundan rom çipine doğru kablo lehimlemek gerekecek. Ha mevcut durumda da çoğu C64 için rom çipinin sökülüp soketli hale getirilmesi gerekiyor ancak en azından mod bittiğinde bir yerden bir yere bir kablo uzanmıyor olacak.

Attiny konusunda üstüne bastın, çek ayağını :) Attiny kullanmayı düşünüyorum zira :)

1. Genel olarak işleyişi ve devreyi kafada kurgulama

Evet efendim, C64'de 7 kernal beri gel oğlan beri gel türküsünü daha yeni söylemiştik. Kalan kısmımız işin switch'siz ve kablosuz olma kısmıydı.

Switchsiz kısmı basit aslında... 3 adet seçim hattımızı bir microcontroller kontrol edeceği switchsiz kısmını çözüyoruz. Tam bu sözleri yazarken kablosuz olması ile ilgili de fantastik bir fikir geldi aklıma bu arada :) Buraya da kısaca not düşüp o alternatifi şimdilik kenara bırakıyorum. Switch işlemini yapacak microcontroller'a bir adet accelerometer bağlayabiliriz, böylece Iphone'larda filan olduğu gibi bilgisayarın belli bir hareketini algılamak mümkün olur. Kernal değişimini de C64'ü hareket ettirerek yaparız. Tabii bu esnada açık olması lazım bilgisayarın. Ram'de çalışan crash etmeyeceğini bildiğimiz özel bir uygulama çalışırken yapılabilir.

Neyse bu ihtimali de bir köşeye atıp orjinal fikrimize odaklanalım. Şimdi burada mevzu şu. Devre sadece rom'a bağlanacağı için elimizde işimizi çözecek nitelikli sinyaller yok.

Elimizde olanlar şunlar : Adres hatları (A0..A13), Data hatları (D0..D7), Ouput enable hattı (/OE ) ve besleme hatları yani GND ve 5v VCC.

Başka çözümlerde olduğu gibi kullanıcı girişine dair bir şey almak istesek bir yerden hat çekmek gerekiyor.

Jim Brain'in de önerdiği yönteme benzer bir çözüm aklıma geliyor.
Aslında daha önce sid player projemde apartman blokları şeklinde yapmıştım devrenin değişik bileşenlerini. O esnada da bağlantıların sağlıklı olup olmadığını test etmek gerekmişti ve benzer bir çözümü hali hazırda kurgulamıştım.

6502 forumlarında hatta bu konuda yaşadığım bir sıkıntıyla ilgili çözüm arayışına girişmiştim. Orada daha detaylı bilgi var.

http://forum.6502.org/viewtopic.php?f=4&t=3378 (http://forum.6502.org/viewtopic.php?f=4&t=3378)

Temelde orada yapmaya çalıştığım şey şuydu. Rom üstüne attığım program microcontroller ile haberleşebilsin diye tüm işi adres decoding yapıp 2 tane sinyal üreten bir devre kullanıyordum. Belli bir adres aralığı bir interrupt sinyaline, bir diğer adres aralığı da başka bir interrupt sinyaline decode oluyordu. Böylece rom'a atılmış ve bu bilinçle yazılmış bir program doğrudan iletişim hattı olmayan microcontroller'a bilgi aktarabiliyordu.

Şimdi bakıyorum da biraz over design yapmışım, iki interrupt sinyaline, komple address decoding'e falan gerek olmayabilir. Özenle seçilecek tek bir adres hattı da bu iş için kullanılabilir.

Bundan sonrası da işin zor kısmı aslında. Tek bir adres hattını dinleyen microcontroller'ın yapılan bütün bellek erişimleri arasından kendisine ulaşmaya çalışan c64 programımızın özenle yaptığı bellek erişimlerini ayıklayıp "hmm tamam, c64'de çalışan program 3 no'lu kernal bank'ına switch etmemi istiyor" diyebilmesi gerekiyor. Tasarladığımız erişim düzeni c64 üzerinde şimdiye kadar yazılmış programların belleğe erişim düzeniyle tetiklenmemeli.

Aslında buraya kadar olan kısımda şematik ve pcb çizimi için elimizde tüm doneler mevcut. Pcb'ler elime ulaşana kadar C64 tarafında çalışacak program ve microcontroller üstünde çalışacak programla ilgili daha detaylı düşünüp çözümü ortaya koyabilirim.

Sistemin kullanıcı arayüzü haricen çalıştırılacak bir program aracılığıyla olacak. 7 değil de 6 kernal ile yetinelim dersek de bu programı da bir kernal imajı haline getirip ilk kullanılacak kernal haline getirebiliriz. Bunun uyumluluk açısından sakıncaları olabilir. Bu gereksinim için de devre şemasına ve pcb'ye bir dip switch eklenebilir. Zira microcontroller'a her açılışta belli bir seçimin yapılıp yapılmadığını iletmesi seçim yoksa da default kernal'a boot etmesi için bank switch emri göndermesi gerekecek.

Geçenlerde devrenin şemasını çizdim. Yalnız EasyEda ile yıldızımız pek barışamadı, biraz erken terkettim bu uygulamayı. Eagle'da şematik çizme konusunda biraz bir şeyler kapmıştım, onda devam ettim. Pcb tasarım kısmında da şimdilik autorouter üç kağıdından faydalandım.

Şematik aşağıdaki gibi,

(http://www.commodore.gen.tr/forum/index.php?action=dlattach;topic=14781.0;attach=23275;image)

Eagle schematic ve board dosyaları da şurada :
http://www.tepetaklak.com/data/7kernalmod.zip (http://www.tepetaklak.com/data/7kernalmod.zip)

Ola ki biri açıp derse, daha sonra pcb'nin alt ve üst katmanlarına ground layer ekledim. Tamamen gözümden kaçmış :)

Pcb tasarımından memnun kalırsam prototip amaçlı üretime göndereceğim. (Henüz sipariş söz konusu değil)

Bir yandan da attiny üstünde nasıl bir kod yazacağım onu şekillendirmeye çalışıyorum kafamda. Sürekli adres hatlarını dinlemesini istemiyorum. Kullanıcının kernal seçimi yapacağı zaman dilimi oldukça kısa olacak, geri kalan zamanda düşük güç moduna geçsin istiyorum. Tabii burada da uzun süre uyursa gelecek komutları kaçırma durumu olacak. Interrupt ile uyansın desek dinleyeceğimiz bit sayısı 1 olduğu için bununla karşılaşma olasılığı çok yüksek olduğu için çok mantıklı olmayacak.

Açılışta 3-5 dakika çalışsın sonra uyusun desek aslında çok da mantıksız değil. Ortada üretilen bir şey yok bu arada sadece yazılı düşünüyorum :)

C64'de çalışan programın özenle yaptığı adres erişimleri için de fuzzy (bulanık mantık) bir state machine (durum makinesi) kullanmayı düşünüyorum.

Örneğin benim dinleyeceğim adres hattı A0 olsun.
Fuzzy olmasından kasıt şu : A0 adres hattının 0 yahut 1 olması durumundan ziyade. Belli bir zaman diliminde A0=0 olan erişimlerin toplam erişim sayısına oranı esas input olacak.

Bu arada devre şemasını çizerken geçici olarak karar verdiğim A0 seçiminin çok da doğru bir seçim olmadığını anlamış bulunuyorum. Zira işlemci yazdığım programı çalıştırırken de bellekten komutları ve komutların operand'larını getirmek için belleğe erişiyor. Anlamlı bir şeyler yapabilmek için en 2 byte'lık opcode'lar kullanmak gerektiği için kod çalışırken A0'ın toggle etmesi kaçınılmaz. Bu da hataya sebep olacağı için dinleyeceğimiz adres hattının yüksek adres hatlarından birinde yeralması gerekiyor.

Beri yandan attiny'e /OE de bağlı, yani aslında /OE=1 iken yani rom seçilmemişken bunu sayacağım erişim olarak kabul etmeyebilirim. Programın rom'dan çalışması durumunda /OE de sürekli toggle edeceği için yine aynı şey geçerli. Ancak kullanacağım biti A13 seçersem ve kodumu da 8K'lık kernal rom alanının alt 4k'lık bölümünde çalıştırırsam A13'ün programın çalışmasından dolayı toggle etmesinin önüne geçerim.

Şimdilik ona A13 diyelim.

İyi ki aceleye getirip pcb'yi sipariş etmemişim :)

Neyse ne diyorduk, bilgi girişimiz fuzzy olacak. Birim zamanda A13 adres hattının 1 olduğu adreslere gelen erişim sayısı / birim zamandaki toplam erişim sayısı benim girişim olacak.

Durum makinesinin şu durumlarının olması gerekiyor.

- Bilgi almayı bekle
- Senkronizasyon  * N
- Bilgi almaya başla
- Kernal 1 * M
- Kernal 2 * M
- Kernal 3 * M
- ....

Burada öncelikle senkronizasyon kısmını açayım. Microcontroller ile işlemci arasında bahsettiğimiz örnekleme diliminin başlangıcı için bir senkronizasyon olmadığı için kabaca bunu sağlamak gerekiyor. Kabaca çünkü fuzzy lojik çalışacağımız için belli sapma değerlerini kabul edebiliyor olacağız. C64 ilk açıldığında ister istemez kernal devreye girdiği için ve A13 hattını toggle edecek erişimler yapacağı için durum makinemizin c64'de çalışacak programla bir senkronizasyonu olmayacak. Tasarlayacağımız durum makinesinin senkronizasyon durumları bu zaman kaymasını azaltmaya yönelik olacak. C64'de çalışan program da durum makinesini "Bilgi almaya başla" durumuna getirene kadar senkronizasyonu sağlayacak durumları atlatacak şekilde erişimlerini yapacak ve sonrasında bilgi göndermeye başlayacak. (C64'de teyp turbolarında kullanılan pilot sinyali de aşağı yukarı bu şekilde çalışıyor sanırım)

Sonrasında da her bir kernal seçiminin durum makinesinde birbirinden farklı şekilde kodlanması gerekiyor. Bunun için durum makinesinde bir kernal seçimini kabul etmek için N adet örneğin uymasını bekleyeceğiz. N ne kadar yüksek olursa herhangi bir programın açılışta kazara kernal'i değiştirme ihtimali o kadar düşüyor.

Senkronizasyonu yaptığımızı kabul edelim,

Misal kernal 1'i seçmek için programımız,

birim zaman diliminde,

1. 100 erişim yapıp 25'ini A13 = 1 iken yapıyor,
2. 100 erişim yapıp 50'sini A13 = 1 iken yapıyor,
3. 100 erişim yapıp 75'ini A13 = 1 iken yapıyor,
4. 100 erişim yapıp 25'ini A13 = 1 iken yapıyor,
5. 100 erişim yapıp 50'sini A13 = 1 iken yapıyor,
6. 100 erişim yapıp 100'ünü A13 = 1 iken yapıyor,
7. 100 erişim yapıp 0'ını A13 = 1 iken yapıyor
...
...
N. 100 erişim yapıp 50'sini A13 = 1 iken yapıyor

Burada örneğin
0 erişimi >=0, <=Threshold gibi algılamak lazım.

aynı şekilde,

25 erişimi >=25-Threshold&nbsp; <25+Threshold

Kernal seçimini tanıyacak geçişe uygun olmayan tüm girdileri de "Bilgi almayı bekle" durumuna göndereceğiz.

0, 25, 50, 75, 100 şeklinde 5 fuzzy girdimiz olduğunda N tane sıralı girdi kabulu için 5^N girdiyi doğru göndermesi gerekiyor herhangi bir programın. Örneğin N'i 6 yapsak toplam 5^10 = 9.765.625 adet girdiyi bizim beklediğimiz sırada göndermesi gerekiyor herhangi bir çalışan programın. Senkronizasyon aşamasını düzgün geçse bile bu aralıkta seçeceğimiz 7 değişik kernal seçimine uygun bilgi geliyor olması çok düşük ihtimal.

Muhtemelen çok daha basit bir çözümle de aynı sonuca ulaşabiliriz ancak bu çözümün şöyle bir avantajı var. Bu algoritmayı kurup çalıştırmanın ciddi realtime yani hassas zamanlama gereksinimleri yok.

Mikroişlemci değil de CPLD gibi bir şey kullansaydık realtime ve tüm adres hatlarını kullanarak yine bir sonlu durum makinesi ile de aynı çözümü uygulayabilirdik. Fuzzy logic uygulamamıza da gerek kalmazdı. Tabii ortaya çıkan hardware biraz daha tuzlu olurdu ve zaten bu işi yapmak için de CPLD kullanma becerisine sahip olmak lazım :)

İlginç bir proje olduğu kesin... Okuyunca anlamıyor olsam da muhakkak anlayan arkadaşlar vardır... Emeğin için çok teşekkürler...

İnsanlık için küçük, ancak benim için büyük bir adım... Tasarladığım pcb'nin siparişini verdim :)

Daha önce Eagle kullanarak bir şeyler yapmaya çalışmıştım. Bu sefer EasyEda'yı bir deneyeyim dedim ancak şematik kısmında bus sinyallerini çizerken sıkıntı yaşadım. Internette bilgi arayınca da sağlam bir bilgi dağarcığına ulaşamayınca direkt eski dost Eagle'a geçtim.

Eagle'da iyi kötü şematik kısmını hallettik, board tasarımına geçtik falan derken eagle'ın klasik stabilite sorunları, bug'ları, saçmalamaları falan bezdirdi. Daha önceden kulağıma niyeyse Kicad bug'lı diye çalınmış hiç denememiştim. Nette Kicad'e geçtim çok memnunum şeklinde bir kaç yorum okuduktan sonra denemeye karar verdim.

Basit olsa da devreyi yeniden çizmemek için bir çevrim aracı aradım ve buldum,

https://hackaday.com/2015/12/27/eagle-to-kicad-made-easy/

Youtube'da Contextual Electronics diye bir kanalda 3-5 video izleyerek kolayca ısındım programa.

Benim bu iş için ideal programım Kicad'miş onu anladım. Bir kere program çok deterministik. Eagle gibi işleri kolaylaştıracağım derken içinden çıkılmaz bir hale sokmuyor. Eagle'da board tasarımına başladıktan sonra devre şemasında değişiklik yapmak çok sıkıntılı, bunda ise oldukça basit, yine aynı şekilde footprint değişikliği falan gayet kolay.

Girdileri, çıktıları belli bir kaç program bir arada aslında. 2-3 gündür kullanıyorum bir kere dahi programların göçtüğüne yahut beklediğimin aksi bir şey yaptığına rastlamadım. Eagle için bunlar çok olağan şeyler.

Tabii en güzeli free bir yazılım olması, eagle'ın free versiyonu bile tam anlamıyla free değil zira ticari bir tasarım yapıp satmanız mümkün değil. Layer, boyut, şematik sayfa sayısı sınırlaması da yok.

Neyse efendim, bakayım benim 5 prototip board için verdiğim 12.5 dolar belki çöpe gidecek ancak benim için iyi bir deneyim oldu.

Aşağıdakiler sırasıyla, devrenin yeni şeması, EasyEda'nın gerber görüntüleme aracından board'un önyüz görüntüsü ve arka yüz görüntüsü.

Prototip olduğu için elemanların silk screen üstündeki etiketlerine/değerlerine falan fazla özenmedim. Devre şemasında da accelerometer çözümü ile adres hattı dinlemeye dayanan çözümü bir arada deneyebilmek için ucuz bir accelerometer modülünün z eksen çıktısı ile adres hattı arasında seçim yapacak bir jumper pad ekledim.

Bu arada yazılım konusunda henüz hiç çalışmadım, vakit bulursam ilk iş accelerometer modülünü kullanmayı düşünüyorum. Sonrasında da pc üstünde fuzzy state machine olayının bir simülasyonunu yapacağım.

Hangi Kernal'lar olacak ? Bu arada ellerinize sağlık güzel çalışma. Bundan çoğaltmayı dusunuyormusunuz ? Talip olabilirim.

ilk aklıma gelenler standard kernal + jaffy dos (sd2iec için) + exos.. geri kalanı talebe göre belirleyebiliriz. jiffy dos lisans gerektirdiği için muhtemelen benden çıkan rom'lar üstünde bu kernal olmaz. tabii isteyen istediği 7 kernal'i bir araya getirip yazabilir.

Nejat'cım yaz beni listenin başına ;)

Ellerine , emeğine sağlık...

Henüz elimde çalışan bir şey yok bu arada. Prototip pcb'ler geldi sadece, üstünde epey bir çalışmak lazım daha.

kolay gelsin abi iyi çalışmalar

@i_r_on takip ediyorum güzel bir proje olacak.

Tünelin ucu bombok bir yere çıktı :)

Arada update geçeyim bari de belki bir el atan, yol gösteren çıkar :)

İlk etapta gelen prototip pcb'lerin sağlığını kontrol etmek için pcb'lerden birine montajı tamamladım ve elimdeki soketli* c64c board'a takmaya çalıştım.

(http://www.commodore.gen.tr/forum/index.php?action=dlattach;topic=14781.0;attach=23947;image)

Bu noktada yaşadıklarımı yazsam muhtemelen 4-5 paragraf yazı olur o yüzden kısa geçiyorum. Ben eldeki pcb'lerin sağlığını kontrol edeceğim derken c64'ün ağır hasta olduğunu fark ettim. Bu da işin yazılım ayağını epey bir sekteye uğrattı.

Nihayetinde Attiny85 üstüne attığım kodla bir şeyler yapabildim.

mWdeX7mWdNg

Burada kernal switch etmenin genel mantığı çalışıyor mu diye 1'den 7'ye her kapanış açılışta sıradaki rom'a switch eden basit bir yazılım var. Attiny85 için yazılımı arduino ile yazdım. Kod eepromdan son seçilen kernal no'sunu okuyor, switch ediyor, bir arttırıyor ve eeprom'a yazıyor. Ve en önemlisi, çalışıyor :)

İş biraz ciddiyete binsin dediğim noktada, ilk olarak accelerometer (ivme ölçer) kullanıp c64'ü açtıktan sonra havaya kaldırıp, indirdiğimde eprom'u switch edeyim dedim. Bu da çalıştı. Bu aşamaya kadar kullandığım kernal rom set'i tamamen dummy. Açılıştaki c64 yazısı, c65, c66, c67 falan diye değişiyor sadece.

Dur dedim şöyle kanlı canlı jiffy'si olsun, exos'u olsun efendime söyleyeyim sd2iec için özel yazılmış kernal olsun bir şeyler deneyeyim. (İşe yarayacak custom kernal bulmak da epey zor, aşağıdaki yaptığım seçim saçma sapan oldu)

Şöyle bir set yaptım,

1- Standard Kernal
2- Cockroach turbo rom (ne alaka?)
3- Datel tubo rom
4- Exos v4
5- Jiffy dos

not: indirdiğim yerde itin biri Türk diyerek haksız yere ismi Özkan (ozkano sen misin?) olan birine hakaret etmiş.&nbsp;
http://www.nightfallcrew.com/27/07/2009/jiffydos-kernal-roms-manual-download-linkjiffydos-kernal-roms-manual-download-link/ (http://www.nightfallcrew.com/27/07/2009/jiffydos-kernal-roms-manual-download-linkjiffydos-kernal-roms-manual-download-link/)

Ben tamamen bilime faydası dokunsun diye indirdim, onu belirteyim.

6- Sd2iec
7- Buraya ne koydum unuttum bak...

Neyse efendim, başladık denemeye. Standard kernal sıkıntı yok, Cockroach turbo rom ona da geçti, Datel bıdı bıdı ona da geçtik. Exos'a gelince ekranda bir M-R yazısı. Jiffydos'a geçiyoruz ortalık dağılıyor. Sd2iec custom kernal aynı şekilde. Standard kernal'e geçince yine sıkıntı yok, devamında da öyle falan...

Hemen sıralı otogaz sistemi olan atiker'e, pardon sıralı kernal switch yapan yazılıma geçtim. Durum onda da aynı.

Neyse daha da fazla uzatmayayım, tünelin ucunu anlatayım. Sorunun attiny85'in rom'u switch etme zamanlaması ile ilgili olduğunu değerlendirdim. Şöyle ki, c64'e elektrik verildiğinde Attiny85'in seçim yapacağı çıkışlar input modunda ve low pozisyonunda olacağı için her zaman standart kernal seçili olarak açılacak c64.

Ancak ben attiny85'in c64 reset sinyalini daha sindirmeden çalışır vaziyette olacağını düşünmüştüm. (İşin pratik tarafına dair de ölçümlerim vesaire var fakat tam olarak sindiremediğim için yanlış bir şey paylaşmış olmayayım.)

Netice itibariyle, denediklerim, bulduklarım.

1 - Attiny85'de olabildiğince hızlı bir başlangıç yapabilmek için Atmel studio'ya geçtim. Fayda sağlamadı.

2 - Eeprom okuma fonksiyonunu kaldırıp doğrudan jiffydos'u seçen bir kod çalıştırdığımda c64 jiffydos ile açılıyor. Bunu da sadece belli internal osc. ve sut fuse değerleri ile yapabiliyor. Başa eeprom okuma fonksiyonu konunca çalışmıyor. (Oysa eeprom okuma nanosaniyeler mertebesinde bir olay... içine düştüğüm zamanlama kıskacı bana bu kadar az zaman bırakıyor olamaz)

Çalışan iki custom kernal'in de çalışabilmesinin sebebi olarak açılışta standard kernal ile ortak kod içermesi olabileceğini düşünüyorum. Oturup incelemedim pek tabii. Ancak bkz. 4.


3 - Commodore C64 kısa board'larda reset devresinden 556 çözümünü çıkarıp RC + 7414 schmitt trigger çözümüne gitmiş. Service manual'lerde 500ms reset süresi bahsediliyor hep ancak teoride bu kısa board'ların reset süresi 726ms civarı olması lazım. Elimdeki daha eski 250466 , 250425 board'larda kontrol ettiğimde bu sürenin 1.5 saniye civarlarına bile çıktığını gördüm. Kullandığım güç kaynağından mı bilmiyorum, nano saniyeler mertebesinde epey gürültü oluyor reset hattında. (Yazıyı bitirince DC adaptör denemesi yapacağım)

http://www.lemon64.com/forum/viewtopic.php?t=65932 (http://www.lemon64.com/forum/viewtopic.php?t=65932)

4 - Tespit ettiğim bir başka fenalık ta şu şekilde. Power on sırasında kernal'i seçemedim. Ortalık dağıldı eyvallah. Ancak kartuş üstünden c64'ü reset ettiğimde de bu problemli olan rom'lara switch edemiyorum. Bu aşamada aslında benim kernal mod devremin işi çoktan bitmiş ve devredeki 27c512 eprom'un yüksek adres hatlarını doğru bir şekilde seçmiş oluyor.

Özellikle de bu son maddeden dolayı şüphelerim tamamen elimdeki hasta c64'e ve güç kaynağına yönelmiş durumda. Eski daha fazla güç isteyen board'lardaki yüksek reset süreleri de gücün açılışta 5v'a çıkmakta epey zorlandığı hissini uyandırdı bende. Reset fonksiyonunda kullanılan kapasitörler stabil hale gelemeyen 5v hattı yüzünden muhtemelen geç doluyor ve reset sekansının geç başlamasına sebep oluyor. Attiny'e başlangıç kodunda eklenen yahut çıkarılan eeprom okumasının da bu derece ciddi etki ediyor olması kısmı ise hala muamma.

*fena tamir görmüş... soketli olması beni daha baştan uyandırmalıydı diyorum

"not: indirdiğim yerde itin biri Türk diyerek haksız yere ismi Özkan (ozkano sen misin?) olan birine hakaret etmiş"
kavga mı var? nerede? :D

Şu aşağıdaki linkte yorumlarda.

http://www.nightfallcrew.com/27/07/2009/jiffydos-kernal-roms-manual-download-linkjiffydos-kernal-roms-manual-download-link/ (http://www.nightfallcrew.com/27/07/2009/jiffydos-kernal-roms-manual-download-linkjiffydos-kernal-roms-manual-download-link/)

Türk olduğundan daha sonra dem vurulan Özkan isimli arkadaş "Utanmıyor musunuz bunları download ettirmeye Jim Brain bunu hala lisanslı olarak satıyor ... ..duklarımın demiş."

Biri de ona tepki olarak şöyle bir genelleme döktürmüş.

"Thanx guys for the files!!
Don’t give a fuck to this idiot Ozkan mates! He is probably fucking Turkish loser as I see…"

Bir USB powerbank ile yalnızca +5V vererek deneme yapabiliriz. Bu board (250469) sadece DC 5V ile açılabiliyor (SID uyanmıyor tabii).

Ek not: Exos-v3 ve JiffyDos kernalleri RAM kontrol rutinini atlıyor. Yani hızlı açılıyorlar. SD2IEC'yi bilmiyorum, birkaç tane var onlardan. Ama o da hızlı açılanlardansa problemi hıza (RAM'ın hazır olmamasına?) bağlayabiliriz bir olasılık.

Aynen, bunu yaptım ben de yazıyı yazdıktan sonra. Elimde atari için aldığım 7 pin din fişlerden vardı. Ucu dağılmış bir ipad usb kablosunu bu fişe lehimledim.

2 amper verdiğini iddia eden bir adaptörle denedim. C64 çalıştı ama benim sorun çözülmedi :(
Hadi açılışta çalışmamasını anlarım ama resetten sonra çalışmaması enteresan. Bu arada attiny üstünde eepromdan okuma ve yazma başarılı ve durduk yerde attiny'nin reset yemesi / brown out olması gibi bir durum da olmuyor.

Yine güzel bir proje. Heyecanla takip ediyoruz. Listeye eklenelim gene  ;)

Hızla ilgili mevzu da dediğim gibi 1 byte eeprom okuma varken çalışmıyor. Yokken ve port'a hardcoded bank numarasını verirsem çalışıyor.

Eeprom okuma da alt seviyede,

Son yazmayı bekle,
Adresi set et
Okuma kontrol flag'ini ekle
Datayı oku (4 cycle)

Şeklinde. Toplasan en fazla 8-10 avr cycle. İlk işlem (mantıken hemen sonuçlanması lazım) belirsiz süre alabilir diye doğrudan register erişimi ile de yaptım, sonuç yine aynı.

Jiffydos'u çalıştıran kod

Çalıştırmayan kod


@byeni : Bu gidişle bu projeye sipariş toplayamayacağız :) Henüz daha benim bile işimi göremiyor :)

@ilker : Hafıza temizleme muhabbetini sen yazınca uyandım. İş bir araç markasının sorun tespit işine döndü :) Vanilyalı kahve alınca çalışmıyor, normal alınca çalışıyor araba filan.

Sorun muhtemelen arka arkaya, ram içeriği temizlenmeden kernal switch etmekten kaynaklanıyor. Jiffynin ufak varyantları arasında switch etmeyi deneyeceğim yarın.

Bu c64c'lerin hafızalarını uzun süre silmemek gibi bir sabıkası var. Muhtemelen jiffy ve çalışmayan diğerleri bir yerlerde belleğin sıfır olduğu varsayımını yapıyorlar.

Edit : Gerçi bilemedim. Kernal yazan adamın böyle varsayımlara girişmemesi lazım. Bugün denerken bir ara hep siyah ekranda kalan 7. Rom seçimimin ne olduğunu da gördüm bu arada. Dead test cart imiş. Üstteki teorimi de çürütüyor biraz bu.

okumuştum abi, ben de gıcık oldum salağa, salak hem ülkeden ötürü aşağılamaya çalışıyor hem de Turkish'in t'sini büyük yazmış. beyin sızıntı yapıyor, alkolle tamamlıyor herhalde diye düşünüyorum, gerzek gavur... bende makara olsun diye gidip dövelim manasında yazmıştım :)

edit: Türkish yazmışım iyi mi :)

Şimdi, sistemi tam anlamadığımdan soruyorum: Kaldırıp indirirken kernal değiştirip reset mi atıyor? Önce hangisini yapıyor? Hem kaldırırken hem de indirirken iki defa ivmelenme olduğu için iki defa reset atıyor ama ağanın resetinin üstüne reset olmayacağı için program counter aynı kalıp kernal değişiyor olabilir mi? Böylece benzer kernallerde çakılma olmazken, epey değişik kernallerde program counter yeni kernalin abuk bir yerin başlıyor olabilir (ilk reset devam ederken ikincisi program counter'ı FFFC'ye almayacağı için). Ayrıca kernal'deki RAM kontrolü hep aynı yerde, uzun süre  dolandığı için bu switch sırasında program counterın yeni kernalde geçersiz bir komuttan devam etme olasılığı düşüyor). Sistemi bilmediğimden yalnızca bir teori bu tabii.

Reset atma gibi bir yeteneği yok malesef. Test için kullandığım yapıda acceloremeter'ı da devreden çıkardım.

Ama mantıken yapacağı şey şu,

1- C64 açılır, devre eeprom'undan okuduğu kernal seçimini 27c512'ye yansıtır. Attiny'nin C64'den önce çalışır hale geleceğini varsayıyorum burada. (C64'ün full reset sinyali ile bir kıyaslayacağım)
2- Kernal seçimi yaptıracak aksiyon alınırsa kernal switch yapılıyor, yeni kernal numarası eeprom'a kaydediliyor.  (C64 açık iken havaya kaldırılıp indirilmesi mesela, ya da ileride adres hatlarından birini dinleyip bunu yapmayı düşünüyorum.)

Bu sorundan dolayı daha aslında 1 no'lu aşamadayım. Eeprom'da kayıtlı jiffydos'un kernal no'su okunup 27c512'nun yüksek adres bacaklarına bu değer set edildiğinde c64 jiffydos ile açılmıyor. Eeprom'dan okuma yapılmaz ise açılıyor.

C64 açıldıktan sonra switch yapılması durumunda crash olmasına razıyım yani. Bunun için rom kullanmayan bir program yazıp crash olmasının önüne geçeceğim ileride.

Hatta daha önce vazgeçtiğim halde kernal seçimi yaptıracak özel bir kernal koymayı bile ciddi ciddi düşünmeye başladım. Böyle bir şey yaparsam açılışta kernal switch etme gibi bir derdim kalmıyor. Her zaman sıfır no'lu kernal ile açılacak, bu kernal da rom kullanmayıp ram üstünden gerekiyorsa kernal seçimini yaptıracak yahut seçili olan kernal'a boot edecek.

Mevcut haliyle kernal değişimini nasıl yapıyoruz? Jumper mı var?

Eğer deneme amaçlı her açılışta yeni kernal'a geçiyorsa, attiny kernal'i değiştiremeden C64 default kernal ile çoktan açılmış, program counter kernalde bir yerlerde dolaşmaya başlamış ve tam o sırada da attiny yeni kernal'i devreye almış ve program counter kendini yabancı topraklarda bulmuş olabilir.

Bu, benzer kernallerde her değişimin sorunsuz gözükmesini açıklıyor.

Ama işte bunun antitez'i de şu, sadece eprom okumayı kaldırdığım zaman ki bunun zaman karşılığının nano saniyeler mertebesinde olması lazım sistem her seferinde düzgün çalışıyor :) (akşam eprom okumanın başına ve sonuna gpio toggle yapıp logic analyzer ile bir süre ölçümü yapayım bakayım)

Bu arada kartın fotosuna göre bu Attiny85'te kristal yok. Yani 1MHz'de çalışıyor (dahili osilatör 128KHz x8 multiplier). Şimdi Datasheet'e baktım, şöyle bir şey de demiş:

"When the EEPROM is read, the CPU is halted for four clock cycles before the next instruction is executed. When the EEPROM is written, the CPU is halted for two clock cycles before the next instruction is executed."

Bu arada bizim 6510 0.35 MIPS. Bu ise 1 MIPS... 6510'un program counter'ı okuyup dallanması, tahminen BRK kadar bir zaman alsa 7 us kaybediyoruz açılışta. Tabii 6510'un PC'yi FFFC'deki değerle yüklemeden önce kernal'in değişmesi şart. Yani ~2 us içinde. Halbuki Attiny daha eeprom okur yazarken 6 us'ye maloluyor, ilgili komutları işlemesi vb. daha var. Hızını kristalle 8 MHz'ye çıkarırsak eğer, eeprom kaybı 6/8 us'ye düşüyor. Komutların da 3 kat hızlı işlendiğini düşünürsek 10/8 us içinde yaklaşık 10 atomik komut işletebiliyoruz. Aslında eeproma yazma işini de geciktirirsek 12 cycle'ımız var demektir. Attiny'nin interruptlarını da kaparsak ve ilk iş kernali değiştirirsek 8MHz'lik bir attiny ile 6510 $FFFC'yi okumadan önce kernali değiştirme şansı var gibi.

Kernal seçimi için jumper yok. Yöntem seçimi için jumper var. Accelerometer ile veya A13'ün switch edilmesiyle olacak ikinci yöntem.



Çoğu (belki de tüm) AVR 8-bit mikrocontroller'larda dahili osilatör var. Kristal takmadan da kullanabiliyorsun. Bu osilatörler 8mhz / 6.44mhz ile de çalıştırabiliyorsun, yahut PLL'i de devreye sokup 16mz de çalıştırabiliyorsun. Bu üç alternatifi de değişik SUT (start up time) değerleri ile denedim. 6.44mhz ile çalıştı sadece.

Bu noktada aslında tek başına hıza güvenmek istemiyorum, güvenemem de zaten. Attiny'nin çalışmaya daha erken başlayacağı varsayımıyla hareket ediyorum. 6510 işlemcisinin reset süresi epey uzun. Spek'e göre 700 küsür milisaniye, ben gerçi pratikte 260ms gibi bir şey ölçtüm. AVR için verilen zamanlama bundan çok daha az. Tabii pratikte bu böyle oluyor mu iyice irdelemek lazım.

Osiloskopta bir kanalda 5v hattını bir kanalda da eprom switch etme sinyalini kıyaslasam aslında bana fikir verir. Sıkıntı şu ki ben osiloskopu kullanmaya bu derece aşina değilim :)

Logic analyzer sıkıntı çıkarmayacaksa ilk onunla kontrol ederim.

Attiny, gücünü Eprom soketindeki +5V'dan alıyor değil mi?
6510 ile aynı +5V izine bağlı. Her ikisi de şalter açılır açılmaz elektrik alıyorlar.
Şu an şemayı/kartı tam anımsamıyorum ama 250469'da güç verilir verilmez 6510'da bir gecikme yaratacak bir şey yok diye anımsıyorum. Reset sinyali farklı tabii, ama ilk güç aldığında hemen koşup PC'yi FFFC-D ile yüklemiyor muymuş? Akşam bir bakayım anakarta.

Yemek yedikten sonra bizden zihinsel performans isteyenlere "la bi' dur beynime kan gelsin" deriz ya. O hesap :)

Zamanlama, belleğin temizlenmemesi vesaire hepsi hikaye sanırım. Yeni bir eprom yazıp deneme yaptım.

0 - Standart Kernal - OK
1 - Jiffy - OK
2 - Dead test - OK
3 - Jiffy - FAIL
4 - Dead test - OK
5 - Jiffy - FAIL
6 - Standart Kernal - FAIL

Sanki durum şu, Dead test basic kullanmadığı için hangi slotta olursa olsun çalışıyor. Diğerleri sadece En alt 4 slotta çalışıyorlar.

Yani, ya tasarımımla alakalı, ya yine gözden kaçırdığım yazılımsal bir detay ile alakalı, ya da montaj ile alakalı bir durum var.

En azından sıkıntıyı bir köşeye sıkıştırdık, araştıracağımız kısımlar azaldı :)

Ve mutlu son :)

B portunda sadece PB0/PB1/PB2 ile ilgilendiğim halde DDRB'yi ve PORTB'yi niye bodoslama set edemediğimi anlamış değilim ancak aşağıdaki kod çalıştı. (İlk yaptığım youtube'a da yüklediğim arduino denemesinin çalışmış olmasından hareketle hızlıca tekrar koda yöneldim.)

Kod şu,


Basit hali çalıştığına göre fantaziye yönelebiliriz artık biraz :)

Bu projeyle ilgili accelerometer ile kernal seçimi için epey bir fantazi yapmıştım, türlü sıkıntılardan dolayı olaylar istediğim gibi gelişmedi. Epey bir ara vermiştim. Yakın zamanda yeniden başladım.

Bir de yazılım yollu yöntemden yürüyeyim dedim.

Burada daha önce yazdığım aşağıdaki sistemle başladım önce,

http://www.commodore.gen.tr/forum/index.php?topic=14781.msg183908#msg183908 (http://www.commodore.gen.tr/forum/index.php?topic=14781.msg183908#msg183908)

Aklımda herhangi bir zamanlama ayarı yapılmadan göndericinin hızına adapte olabilecek bir mekanizma vardı. Sonra birden uyandım, ben aynı işi aslında IRQHack64 kartuşunda da yaptım hatta onun ESP8266 versiyonunda ve başlayıp ama bitmeyen V2 versiyonunda da biraz farklı şekilde de olsa uygulamaya çalıştım.

Bu işi yapmak için Kernal+Basic rom'un olduğu yerde modüle edebileceğimiz bir sinyale ihtiyacımız var. Eski board'larda deneme yapmak zorunda olduğum için kernal'in /CS sinyalini önce bu iş için kullandım. Ancak bu sinyal ile ilgili şöyle bir sıkıntı tespit ettim, tüm interrupt'lar durdurulsa ve kernal'e bilfiil erişim olmasa bile mütemadiyen bu sinyal değişip duruyor. Devam edebilmek için eski board üstünde PLA'dan gelen /BASIC ve hali hazırda zarar görmesin diye çıkardığım SID soketi üzerindeki Sid'in /CS&nbsp; sinyalini denedim. Onlarda /KERNAL sinyali gibi bir sıkıntıyla karşılaşmadım.

Yeni board'larda rom'un chip select sinyali /KERNAL AND /BASIC şeklinde. /KERNAL sinyali ile ilgili sıkıntıyı çözmeden finale ulaşmam mümkün değil ancak yine de ilerledim.

Yöntem şu, C64 tarafında kernal switch edecek program açılışta hiç BASIC'e erişmiyor. Daha sonra 0 göndermek için basic bellek alanında bir adrese tek bir erişim yapıyor, kısa bir süre bekliyor sonra bir erişim daha yapıyor. 1 göndermek için de aynı şeyi yapıyor, tek farkı 1 göndermek için arayı 0 göndermeye göre biraz daha uzun tutuyor,

Yani /BASIC sinyalinin görüntüsü şöyle oluyor

(http://www.commodore.gen.tr/forum/index.php?action=dlattach;topic=14781.0;attach=26031;image)

Attiny85 tarafındaki lojik de şu, dinlenen sinyalin her 1'den 0'a geçişinde bir interrupt tetikleniyor. İlk interrupt olduğunda zaman tutmaya başlıyor, ikinci interrupt olduğunda iki interrupt arası geçen zamana (B-A) bakıyor, kontrol eden programın gönderdiği sürelerle uyumluysa tamam bir bit aldım diyor.

Peki, Basic'e normal şartlarda erişen bir program da bu aynı süreci tetiklemez mi? Tetikler. Bu yüzden attiny özellikle dinlediği kernal seçim programından 24 bitlik özel bir bit dizisi gelmeden devamında gelen 8 bit'i işleme almıyor. Yani sıradan çalışmadan ötürü basic belleğine yapılan erişimler hem bizim belirlediğimiz düzene uymalı hem de bu rastgelelik içinde 24 bit'i bizim belirlediğimiz ile aynı olmalı ki bizim microcontroller'ı afallatsın. Microcontroller üzerinde çalışan program zaman uyumsuzluğu varsa herşeyi baştan başlattığı için rastgele bir kernal değişikliği olma ihtimali iyiden iyiye azalıyor.


Neyse efendim sadede geleyim, değişik sorunlarla epey bir uğraştıktan sonra nihayetinde çalıştırmayı başardım :)

OBxgCRnvcg8

Harika haberler IR_O_n. Eline sağlık.

Bu gayet süpersonik bir şey olmuş.

Peki bir sonraki açılışta son seçimi anımsıyor ve hep o kernal ile başlayabiliyor mu?

Yurtdışı ticari potansiyeli de var bunun ayrıca ;)

Pek tabii, ikinci bir seçim yapılmadığı sürece son yapılan seçim geçerli oluyor.

c64 adına iyi olmuş tebrikler ancak bunun benzeri amiga1200 için lazım :D

C64'e geç sahip olduğum için doğrudan PC'ye geçtim zamanında. Amiga benim için hem yazılım hem de donanım anlamında oldukça bakir bir alan. Kullandığım teknik aynı mantıkla /OE hattı olan herhangi bir rom çipinde aynen kullanılabilir. Tabii bir de ROM'a erişimin yazılım ile kapatılabiliyor olması gerekiyor. Bunun için tek gereken N adet rom'u yazacak daha büyük bir eprom, uygun bir adaptör pcb ve amiga tarafında bu switcher'ı destekleyecek bir yazılım.

Bu arada, sonunda ilk c64'üme kıydım ve bu projenin testleri için kernal+basic rom'unu desolder edip mod'u uyguladım. Bir iki tökezleme, debug vesaireden sonra düzgün çalıştırmayı başardım. Tek sorun bazen kernal'i switch etmemesi, onu da logic analyzer ile deneye deneye çözerim muhtemelen.

Geriye pcb tasarımını sadeleştirme, yükseklik profilini azaltma gibi şeyler kalıyor. 250469 board'larda kernal rom tam da keyboard için koyulan metal bracket'ın altına geliyor. ICSP header'ını diğer tarafa atmam lazım, DIP 7408 yerine küçük üç tane smd and kapısı koymam lazım filan.

Header'ı lehimlemezsen yerini de değiştirmene gerek kalmaz. Programlayacağın zaman erkek pinleri takıp bir tarafa çekiştirerek temas etmesini sağlar ve programlarsın. ;)

Design mecburen değişti, o yüzden pcb'yi değiştirmek kaçınılmaz :) Diğer tarafa alınca yükseklik problemi kalmıyor. Fantazi header var bir tane accelerometer için, wire jumper var, onları da kaldıracağım. Debug için bir led ekleyeceğim falan.

Ekleme kablolarla falan çalışır hale gelmesi bile büyük başarıydı bu arada benim için :)

Bu iş tamamdır,
Remaining bugs i.r.oned out :P
Canavar gibi çalışıyor, sıra geldi pcb tasarımını revize edip sipariş geçmeye.

gwpgLJTUj-I

Eline emegine saglik I_R_on. Mukemmel otesi. Bir kac bug nazarlik kalsin :)

@i_r_on sabah sabah iyi geldi, gözümüz gönlümüz açıldı  :). Listeye şimdiden girelim mi??

Listeyi yakında açarım. Pcb siparişi geçtikten sonra eski board'lar için de bir çözüm düşünmem lazım. Camiada herkes ekmek kutucu :)

Ellerine sağlık hocam. Maaliyet belli olsun listeye benide eklersen sevinirim. Bu arada youtube da c64 mods olarak gezinirken bu senin yapmış olduğun kernal switch hakkında adamın biri de güzel bir sey yapmış. Paylaşmak istedim. Selamlar.

pwgi78XEeNc

eline sağlık güzel olmuş

@aegis : Benim yaptığıma aslında bunun bir tık gelişmişi diyebiliriz. Benim yaptığımda kernal'i söküp yerine pin header yahut entegre soketi lehimlemek yeterli oluyor. herhangi bir yere kablo çekmeye falan da gerek kalmıyor. Bu mod'un bir farklısı daha var onda da restore tuşuna kablo çekiyorlar, açılışta restore tuşuna basarsan kernal'ler arası seçim yapılıyor.

Tabii renkler ve zevkler tartışılmaz, ille de kasanın dışına bir şey çıkaracağım, kasayı delip switch takacağım diyenler çıkacaktır.  Bu yaklaşımı ben hem sevmiyorum hem de şahsen beceremiyorum :) 

Bu tip hardware mod'lardaki en büyük handikap çiplerin hali hazırda soketli gelmiyor oluşu.

PCB siparişini de verdik bakalım, hadi hayırlısı.


(http://www.commodore.gen.tr/forum/index.php?action=dlattach;topic=14781.0;attach=26219;image)

Ayıp ediyosun Eşref, senin için özel edition bile çıkarırız toplantıda :)

Saol abi :) çalıştırmayı anlasam yeterli olur çok utanıyorum zaten yapamadım diye :) Laptopumuda getireyim ben en iyisi.

Aşağıdaki mesajımda eski board'larda /KERNAL sinyalinin pürüzsüz olmaması sebebiyle sıkıntılı olduğunu yazmıştım.

http://www.commodore.gen.tr/forum/index.php?topic=14781.msg198098#msg198098 (http://www.commodore.gen.tr/forum/index.php?topic=14781.msg198098#msg198098)

Bir süredir bu sorunla uğraşıyorum. C64 tarafında yazılım yollu temiz bir /KERNAL seçim sinyali elde etme çabalarım malesef sonuç vermedi.

Ölçme biçme değerlendirme sonucu gözüken şuydu : Eski PLA'larda VIC bus'ı bırakırken PHI2 high'e geçtiği noktada bir şekilde /KERNAL combinatorial logic'ini de etkileyecek bir sinyali geç değiştiriyor. Öyle ki, ekran kapalı bile olsa bu hatalı yapılan /KERNAL sinyal seçimlerini logic analyzer'da görüntülediğinizde 25 adet badline'ı (bu anlarda ~41 mikro saniye kernal'in yanlış seçimi yapılmıyor) ve video blanking anlarını /KERNAL sinyali üzerinde görebiliyorsunuz.

/CHAROM ve /KERNAL hattını ve bunların input'larını logic analyzer'da daha derinlemesine inceleyince muhtemelen yazılım yollu bir çözüm de mümkün olabilir ancak dün farklı bir şey deneyince olaya donanım + yazılım yollu bir çözüm bulabildim.

Bir deneyelim bakalım diyerek kernal'e erişim yaptığım kodun başına ve sonuna romu açma ve kapama kodu eklemiştim. Hepi topu 40 küsür kernal okuması yaparken bahsettiğim bu rastgele kernal seçimine denk gelmeyebilirim demiştim. Tabii bu da işe yaramadı, arada bazı okumaların öncesinde 41ns'lik bu hatalı /KERNAL seçimlerini izledim yine.

Konuyu şurada gündeme getirdikten sonra gelen cevaplardan sonra bir başka şey denemeye karar verdim ve bu nihayet işe yaradı.

http://cbm-hackers.2304266.n4.nabble.com/Weird-KERNAL-line-on-old-boards-td4666871.html (http://cbm-hackers.2304266.n4.nabble.com/Weird-KERNAL-line-on-old-boards-td4666871.html)

Kısa kesiyorum,

41ns'lik hatalı /KERNAL seçimlerini 500ns'lik bilfiil benim gerçekleştirdiğim seçimlerden ayırmak için hali hazırda kernal rom'un üstünde bulunan diğer sinyallerden de faydalanabilir miyim diye baktım. Daha önce bunu kernal'de okunacak adresin bir kaç bit'ini spesifik yaparak denemiştim ancak başarılı olamamıştım (Kernal seçildiyse ve adres bit'leri şöyle şöyle ise bunu geçerli kabul et gibi )

Aklıma Rom'u açıp / kernal erişimi yapıp / tekrar rom'u kapattığım kısımda cpu'nun gördüğü adres hatlarını özel yapma fikri geldi. Tabii bunu kernal'de erişilen adresin de uygun olarak seçilmesi tamamlıyor.

Hali hazırda soketi piyasada olduğu için SID çipi üstündeki en yüksek adres hattı olan A4'ü kullanmayı denedim.

Buna göre /KERNAL hattını 500ns high / low / high durumuna sokacak aşağıdaki kod bloğum çalışırken yapılan erişimin haricinde cpu'ya hep A4=1 olan adresler sürdürecek. /KERNAL seçimini sağlayacak erişim ise A4=0 olan bir adrese yapılacaktı.


Soru : Üstteki koda baktığınızda ve yine yazdıklarımı dikkate aldığınızda tutarsız gibi gözüken bir kısım var. Bu nedir? Aslında niye tutarsız değil?

Böylelikle rom'un açılıp da kernal'e benim yaptığım erişim olan bir cycle'ın dışında cpu adres bus üzerinde A4 hattını hep 1 olarak sürecek, LDA $F000 komutunda yaptığı tek read esnasında ise A4'ü 0 yapacak.

Tam test kodu aşağıdaki gibi,

Donanım + yazılım yollu çözüm demiştim, işin donanım tarafında da Attiny85'e giden sinyal artık /KERNAL yerine (/KERNAL OR A4) olmuş oldu. Devrede 1 adet iki gate OR kapısına ihtiyaç var artık.

Test devresini bozmadan full yazılım yollu başka denemeler daha yapacağım. Badline'larda hatalı /KERNAL sinyali üretilmiyor olması bir işaret. FLI / FLD / Linecrunch ve benzeri efektlerde badline'lara müdahale edilebiliyor, bunlar denenebilir veya soruna tam olarak hangi sinyalin yol açtığı bulunarak bunun üstünden bir yazılım geliştirilebilir.

Bugün (yani dün akşam) TETU Commodore 64'te oyun oynamak istedi ve SD2IEC'ten oyun yüklemek için SD2IEC kernal kullandım. Gerçekten çok pratikmiş. Bu vesileyle tekrar ellerine emeğine sağlık diyorum. ;)

Çorbada bizim de tuzumuz olsun. Kısmetse ben de bir ara oyun odasını hizmete açacağım. Bizimki daha retronun kalbine inmedi, indiğinde neler olacak çok merak ediyorum :)