commodore.gen.tr

Dosya şurada:

http://cbm.ficicilar.name.tr/dosya/geossnap.zip (http://cbm.ficicilar.name.tr/dosya/geossnap.zip)

Bunun içindeki GEOSSNAP dosyasını SDcard'a atıyoruz, SDcard'ı IRQhack64'e takıyoruz, menüden bunu seçiyoruz, IRQhack64'ün tuşuna uzun süre basarak autoboot haline getiriyoruz. Bu sayede C64'ümüz 8 saniye içinde GEOS ile açılıyor. Kullanabilmek için 8 no'lu sürücüde bir GEOS disketine veya SD2IEC'ye hâlâ ihtiyaç var gerçi. Commodore-O tuş kombinasyonu ile taktığınız GEOS disketini yeniden okutabilirsiniz.

Bu GEOSSNAP dosyasını hazırlamak için yapılan adımlar ise şöyle:

1. GEOS source'u https://github.com/ytmytm/c64-GEOS2000 (https://github.com/ytmytm/c64-GEOS2000) adresinden indirilir.

2. Daha önce bir yerlerde bahsetmiş olduğum optimizasyonlar yapılır ve derlenir.

3. Oluşan dosya pucrunch ile sıkıştırılır.

4. Sıkışık dosyaya müdahele edilerek açma işleminden sonra $0400-$46FF ile $5200-$8FFF arasını $BB değeri ile doldurması sağlanır ardından $5000'a zıplaması sağlanarak normal GEOS boot işlemini başlatması sağlanacak şekilde kaydedilir.

5. Bu yeni geos kernal yüklenir. Disket sürücüye GEOS diski takılır ve çalıştırılır.

6. GEOS freeze edilir. $8492 adresine $00 değeri yazılır (disk turbo yüklü değil bilgisi için) ki bu freeze image'ı yüklediğimizde disk işlemleri doğru çalışabilsin.

7. Bu yeni imaj kaydedilir. Super Snapshot 5 kullandım (Megaone kartuşu hazır olunca bu kartuşun imajını Megaone ile çalıştırmak mümkün olabilecek). 201 block'a indi. Yukarıdaki $BB ile doldurma işlemini de zaten dosya boyutu küçültmek için yapmıştık. 202 blok'tan fazla olursa IRQhack64 ile yükleyemiyoruz (I/O alanıyla çakışıyor).

8. Sanırım ayrıntılar bu kadar.

EZLgPM4m_Zw

Bu tarz trick'ler projelerimize değer katıyor. Teşekkürler. :)

Maşallah 10 saniyeye düşmüş...Zamanında böyle çözümler olsa, yer yerinden oynardı herhalde :)

teşekkürler

30 yıl kadarcık geç kaldık :)

Bu arada, bizim çözümümüz çok çok daha hesaplı. Daha hızlı olan 1541 Ultimate II için istenen 2. el fiyatı şöyle mesela:
http://www.ebay.co.uk/itm/Commodore-64-1541-ULTIMATE-2-with-tape-adapter-/401100011622?hash=item5d636c7866%3Ag%3AnPoAAOSwcBhWUE~X (http://www.ebay.co.uk/itm/Commodore-64-1541-ULTIMATE-2-with-tape-adapter-/401100011622?hash=item5d636c7866%3Ag%3AnPoAAOSwcBhWUE~X)
(600 Sterlin istemiş!)

Şimdi, bizim çözümü tamamlayacak bir diğer unsur batarya destekli RAM'a sahip bir GEORAM/NEORAM.

Arka plan müziği ile daha bir hoş olmuş :) teşekkürler, tebrikler, irqhack64 elime ulaşınca deneyeceğim.

Kartları yapan tüm arkadaşlara da tekrar teşekkürler.

Teşekkürler. vpr.net 'teki Jazz radyosu açık. Hem güzel seçimleri var hem de sıfır monolog ve reklam... Önerilir :)

Bu arada, C128'de doğrudan u36 GEOS EPROM'u çözümünü de denemiştim. ROM+1571 yaklaşık 46 saniyede açıldı. Bir ara farklı yöntemlerle açılış sürelerini tablolamalı.

Başarılı bir çalışma olmuş. Bir sd card daha aldım geçenlerde, nihayet ben de sd2iec irqhack64 kombosu deneyebileceğim.

tam da bu anda aslında geos ile kullanmak için bir mouse adaptörü süper olurdu.

Bu arada IRQHack64'ün I/O altına transfer yapmaması tamamen bir tercih oldu. Yapamaması için bence hiç bir sebep yok zira kendisi CIA/VIC/SID vesaire hiç bir i/o cihazını kullanmıyor. Prg'ler genelde diskten yüklenecek şekilde hazırlandığından i/o altına yükleme isteyen bir örnekle karşılaşmamıştım. Teypten yükleme yapılabiliyordur muhtemelen ancak diskten yükleme için herhalde bir önyükleyici şart oluyordur.

Eprom'da değişikliğe gidilerek i/o altına yükleme yapılabilir.

Pratik örnekleri varsa denemek isterim.

Olsun, böyle daha zorlayıcı oldu :) İlk deneme 213 bloktu.

Genelde bir Freezer'la kaydedilen oyunlar vb. böyle büyük boyutlu oluyor. Kendi yükleyicileri olduğundan sorun olmuyordu normal kullanımda. Artık hemen her oyun online bulunabildiğinden pek de gerekli değil gibi. Yine de Eprom'da A9 37'yi A9 34 yaparak çözebiliriz gibi. Bu arada, bir düşünce deneyi olarak byte başına 40 mikrosaniye daha kazanamaz mıyız acaba?

Mouse adaptörü yeni bir proje fikri gibi gözüküyor.

Bense yazılımla halletmeye çalışıyorum. Son hali verilmemiş üç ayrı yöntem için GEOS mouse driver:

1. NEOS mouse için. Yazdığım driver gerçek cihazda az sorunluyken (ivmesiz) VICE'ta sorunlu (zıplıyor pointer).
2. Modifiye seri mouse için. Seri mouse mu kaldı diyerek öyle bıraktım. Sitede bir yerlerde olacak yirmi yıllık sürücüsü.
3. PS/2 mouse için. Bunu eskiden yazmıştım. Şimdiyse GEOS driver için ayrılan alana sığması ve polling ile çalışması gerekecek (PS/2 protokolündeki remote mode ile [0xF0]).

Bağlantı için dümdüz datasette portundan bağlantı düşündüm:


Gerisi bildiğimiz PS/2 protokolü.

Okuma işlemini borderlarda yapmak lazım. Doğru dürüst çalıştırabilirsem, kablosuz mouse'un alıcı devresini C64'ün içine tıkıştırma planındayım.

Yine de Arduino mouse adaptörü daha uyumlu bir çözüm olacaktır. Ama 1351 mouse'u taklit ettirmek zor olabilir.

Bu arada, light pen ile de fena kullanılmıyor GEOS. Kablosuz light-pen yapılırsa o da kullanışlı bir çözüm olur. Dokunmatik ekran kaplaması da bir çözüm, ama baktıklarım epeyi pahalıydı. Aslında, C64c'de sağ alt köşeye, logo'nun olduğu kısma bir touch pad de eklenebilir bir olasılık.

Mouse için bence joystick portundan standart olandan bir şey düşünmek lazım. Ben o konuya girersem çıkamam :) Daha sırada bekleyen projeler var.

Biri şu aşağıdaki projeyi üretime geçirse aslında biz de nemalansak :)
http://svo.2.staticpublic.s3-website-us-east-1.amazonaws.com/ (http://svo.2.staticpublic.s3-website-us-east-1.amazonaws.com/)[m]ouse/

Sonrası bir kaç ucuz ps/2 mouse edinmeye bakıyor :)

Şu an 1 byte'ı 37 mikrosaniyede falan transfer ediyoruz, 40 mikrosaniye nasıl azaltacağız? :) Ben fizikçi değilim valla anlamam o işlerden :)

Ancak arduino ile c64 sallıyorum her 8 byte transferinde senkron olabilirlerse interrupt'a girme / çıkma overhead'i kısmen ortadan kaybolacağı için 3-4 misli hızlanma sağlanabilir. Soru işareti şu : Senkronizasyon sağlanabilir mi? Kanaatim şu : assembly kodu yazılırsa sağlanabilir.

Yarın osiloskopum gelecek, timing anlamında denemeler yaparım belki önümüzdeki hafta.

interrupt rutini içinde ardı ardına 2'nin katlarında load ve store yapmak, load sonralarında eprom'da bank switch yapma üzerine düşündüğüm şey.

sen de mi aynı şeyi düşünmüştün?

http://svo.2.staticpublic.s3-website-us-east-1.amazonaws.com/%5Bm%5Douse/ (http://svo.2.staticpublic.s3-website-us-east-1.amazonaws.com/%5Bm%5Douse/)

Bu uzun zamandır aklımda fakat tek sorunum zaman. Keşke Özay bunu gündemine alsa :)

:) bir zaman makinesi yerleştirmemiz gerekecek demek ki IRQhack64'ün 37 mikrosaniyelik transferini 40 mikrosaniye daha kısaltmak için.

Senkronize transferde bilmediğim bir durum var: Acaba Atmel ısındığında hız düşürür mü? Farklı modüllerde farklı kristal kullanılmış olabilir mi gibi.

Yine de daha bir instant olabilirmiş gibi geliyor. 50K'yı 1-2 saniye içinde atabilmeliydi aslında. Hedef: 2 Saniyede GEOS boot :)

Pro mini üstündeki internal oscilator kullanılmıyor aslında. Baktım da orjinal pro mini tasarımında resonator kullanıldığı ve bunun hassasiyetinin %0.2 olduğu söyleniyor. Benim kullandıklarımdaki kristal görünümlü ancak alıcı gözle bakmadım.

Osiloskopum geldi, şu an şehir dışındayım. Gelince transferi 6502 saatine senkron edebiliyor muyuz bakacağım.

2 saniyeye rahat ineriz bence :)

Hesaplamalarıma göre nmi handler içindeki veri transfer bloğunu 4 defa uygularsak 2.5 misli hız artışı sağlanabiliyor. Sallıyorum 16 defa tekrarlarsak ve senkronize olabilirsek ise bu hız artışı 3.23 misli falan oluyor.

Yani kod şöyle bir şey olacak,


Yani LDA #$EA (*) sonrası arduino'nun her seferinde yaklaşık 8 c64 cycle'ı bekleyip bank switch yapması lazım.

*burada EA aslında arduino'nun switch ettiği eprom bank'ına işaret ediyor.

Osiloskop ile istediğim ölçümü yapamadım, bir de logic analyzer ile denerim belki. Ancak deneme yanılma ile de tutturulur bence.

Esas problem bütün transfer kodlarını 4'er byte gönderecek şekilde değiştirmekte. Zamanlama önemli olduğu için döngü kullanmak işi bozabilir. Bu yüzden nmi zamanlamasına dokunmadan transferi yapan metoda 4'er byte göndermem lazım.

:) Bence bu olur. Önemli olan LDA'lar ve her biri arasındaki o 8 mikrosaniye page değiştirmek için fazlasıyla yeterli.

Konuyu takip edemeyenler için kısa not: Yukarıdaki LDA-STA-INY grupları aslında EPROM'un apayrı yerlerinde yer alıyor, ardışık gibi ama değil. Hangi grubun çalışacağına Arduino karar veriyor, 6510 ise onları ardışık olarak görüyor.

Şimdi bu örnekte anlaşılan 10 mikro saniyede bir page değiştirilecek. Önemli olansa, zamanlamayı kaydırmamak gibi görünüyor. Örneğin, 2.1 mikrosaniyelik bir kayma 4. grubun doğru eprom page'i içinden okunamamasına yol açabilecek.

Osiloskop ve logic analyzer'ı kenarda bırakıp deneme yanılma ile bir şeyler yapmaya çalıştım. 4 byte transferi başarısız oldu.

Şöyle bir sorunsal var, Interrupt'a girmeden önce ana döngü var. Interrupt geldiğinde burada kaç cycle bekleneceği belirsiz.


BIT komutu ve BVC (dallandığı için) 3 cycle'lık komutlar. Interrupt'a girilmeden önce 0-3 cycle belirsiz bir süre var. Uzun transferlerde senkron olmaya engel durumlardan biri bu.

Ancak yaşadığım problem muhtemelen bundan kaynaklanmıyor. Zira aralara NOP'lar serpiştirdiğimde de zamanlama tutmadı.

 

2 byte transferi ile uğraştım, menüye dosya isimlerinin transferinde bir abukluk oluyor ancak onun dışında her şeyi güzel güzel transfer ediyor. Hazır optimize etmişken şu nefret edilen şeritleri de kaldırdım. Nop'ları azalttım. 51K'lık Ghost'n goblins'i mesela data transferi anlamında sadece 1.8 saniye zaman alıyor :)

Senin GEOS yükleme süresine ne kadar etki eder bilemem.

Videodaki Karateka 45K, SynthCart ise 8k. Kahverengi renk falan siyah ile değişecek, normalde debug amaçlı olarak rom'da duran değişik renkler var kartuş takılırsa nerede takıldığını anlamak için.

NBOScjIFYiM

ps: Wizofwor'un menü ile deneyemedim, en son under construction durumda olduğu için.

O ne! E uçmaya başlamış bu.

Tek rakibi Türk DMA Yolları :)

Bu son deneysel halinin ve production halinin ziplerini alabilmemiz mümkün mü?

Bence senkron olamamasının sebebi delayMicroseconds()'ın hassas olmaması. Zaten kendi içinde bir 1/16 mikrosaniyelik epsilona sahip. Üstüne bu komuta girip çıkarken de kayıp yaşıyor. O gecikmeleri birer ikişer kısaltarak deneme yanılmayla tutturabiliriz senkronu gibi geliyor.

Ya da i_r_on Arduino'dan kurtulup yavaş yavaş Atmel Studio'ya (dolayısıyla saf AVR GCC'ye) geçecek. :D

Source'ları akşam eve gidince paylaşırım. delayMicroseconds'ı inline assembly'e çevirmek kolay. Zaten 2 byte gönderimi ile kazanılan hız beni kesmedi, 40k'yı 1 saniyede göndermem lazım :)

Muhtemelen 4 byte gönderimi de çalışacaktı, sıkıntı menünün gönderilmesi sırasında yaşanıyor tahminimce. Onu çözersem aslında olay çözülüyor.

Bu arada hakikaten şerit yerine düz tek renk ekranla geçiş daha hızlı olduğu izlenimini uyandırıyor. Şeritler bizim beynimizde eski teyp yüklemelerinden kaynaklı  "bekle kardeşim" bölgesini uyarıyor herhalde :)


Bu projede artık zor, hardware'i de baştan design edip yazılımı da oraya kaydırmak aklımdan geçmedi değil. Bir sonraki projeye kısmetse. Gerçi belli de olmaz, kaşınırım falan yine çok kesin konuşmayayım.

:) beynin "bekle kardeşim bölgesi" güzelmiş.

Test versiyonunun source'ları şurada.
http://www.tepetaklak.com/data/IRQHack64Nmi2Byte.zip (http://www.tepetaklak.com/data/IRQHack64Nmi2Byte.zip)

Ben bir iki eprom silip 4 byte transferi deneyeyim :) 6 cycle şerit operasyonundan da kazanmışken ciddi fark yaratacak muhtemelen.

Takip ediyorum da bu gidişle commodore açıldığı anda geos gelicek sanırım :) Bravo yani.

Kolay Gelsin.

@gameretro : ilker sd2iec'ten de bir yüklemeden bahsediyordu. O yüklemenin süresine IRQHack64'ün bir katkısı maalesef olamayacaktır.

@ilker : sahi ne kadar bir data yüklüyor?

8sn'de yüklemeyi denemiştim demek ki arayı kaçırmışım onun üzerine combo yaparak devam ediyorsunuz diye algıladım olayı.Cevap için Teşekkürler.

Tabii ki takibe devam :)

4 byte ile de çalıştı bu arada. Çalıştığında %25 daha hız artışı oldu. Stabilite daha kötü. Şunu farkettim, arduino hız için değil flash boyutu için optimizasyon yaptırıyormuş gcc'ye. Inline assembly ile 6502'nin 0.985mhz pal clock'unu da düşünüp delay rutini yazdım ancak adam gitti onu inline kodun içine gömmek yerine call ile çağırdı. Assembly çıktıda delay rutinini oluşturan nop'ları da optimize etti mi etmedi mi anlayamadım.

Hıza göre optimize et demek için platform.local.txt içinde değişiklik yapılabiliyormuş onu denedim. Bu sefer de compile / link'te enteresan bir hata aldım.

En son tekrar delayMicroseconds'a dönüp elle tweak ettim. Menü transferi arada göçse de esas transfer takır takır çalışıyor. Transfer rutinini monoblok assembly ile yazmak lazım tam stabil olması için.

4 byte'lık versiyon şurada.
http://www.tepetaklak.com/data/IRQHack64Nmi4Byte.zip (http://www.tepetaklak.com/data/IRQHack64Nmi4Byte.zip)

Bu arada fonksiyonları inline edemiyor olmak da gerçek hızı görememek için bir etken. Bir şekilde hıza göre optimize ettirmek lazım. Size artışından dolayı menüyü kartuş üstünde saklamayız olur biter.

50KB yüklüyor: http://cbm.ficicilar.name.tr/dosya/geossnap.zip (http://cbm.ficicilar.name.tr/dosya/geossnap.zip)

Bunun içindekini çalıştırıyoruz IRQhack64 ile. Şak diye GEOS gelecek olasılıkla :)

gcc'de -O0 parametresi işe yaramadı mı ki?

Bir bakayım.

Bu arada ben de KissUtilityPack'te son rötuşları yaptım. Arşiv içindeki PRGs'dekiler IRQhack64'ün kısa yol tuşlarıyla (0-7) da çalışabilmesi lazım: http://cbm.ficicilar.name.tr/dosya/KissCart-UtilityPack-v1.4.rar (http://cbm.ficicilar.name.tr/dosya/KissCart-UtilityPack-v1.4.rar)

pragma directive'i ile -O0 seviyesini inline fonksiyonların olduğu dosya için denedim ancak başka bir kütüphane derlenemedi. Bir de -flto opsiyonu varmış, onu da denedim collect.exe bıdı bıdı diye başka bir hata verdi o da.

Aslında ne kadar yüklüyor diye sorduğum disket sürücüden ne kadar yüklediğiydi. Anladığım kadarıyla bu crunch'lı, uncrunch'ta vakit gidiyor daha çok.

sd2iec bağlı olmadan denedim 5 sn.'de açtı. i/o bölgesine yükleme gerekiyor falan demiştin, öyle bir versiyon varsa onu da deneyebilirim.

Aslında bu crunch'sız ama bol bellek transferli. GEOS çalışırken Vice ile tam bir bellek snapshot'ı alabilirim sanırım. 0002'den ffff'a kadar yükleme yapmasının önünde bir engel yok bence irqhack64'ün. I/O runtime kopyasını da GEOS'un 2. ekranı olan $6000 koyarız. Çok az bir bellek transferi ile hallolur gibi. 64k sdcard'dan 1-2K da RAM'dan  I/O'ya.

Optimizasyon parametreleri ise neden sorun çıkarıyor acaba?

Bilemiyorum valla. Kurcalayıp halledeceğim bir ara. Şu an zaten stabil değil, her türlü zamanlamayı sağlamlaştırmam lazım.

Diğer konuda paylaştığın d64 imajını attım sd2iec'e. Geossnap'i IRQHack64 ile yükledim. Geos içinde içeriğini listelemeye çalışınca sürücü hatası verdi. Öncesinde sanıyorum sd2iec'de bu d64'ü seçtirmek için bir şey yapmak lazım.  Özay'ın açıklamalara bir bakayım.

Loader rom'u bellek ayarını $34 yapacak şekilde değiştiriyorum bu arada. $D020'ye yazan tüm yerleri de kaldırmak gerekti, yoksa yüklenen şeyi ezerim.

Deneme yapmak için büyük bir program imajı bulmam lazım. Vice'ta freeze işini beceremedim.

ps: aşağıdaki linkten bakıp çalıştırdım bu arada :)
https://www.c64-wiki.com/index.php/sd2iec_(firmware (https://www.c64-wiki.com/index.php/sd2iec_(firmware))

$34 dedim ben ama kafam karıştı.


Ram'e yazma anlamında aslında bellek konfigürasyonu etkili değil. Tek istisna I/O bölgesi. Her yeri RAM yap seçeneği %x00 ise default nmi handler'ın çalışmasını engelleyecek. Şimdi I/O altına yazabileyim ama Kernal ROM'dan da okusun seçeneği hangisi emin olamadım.

Şu herhalde?
%0xx: Character ROM visible at $D000-$DFFF. (Except for the value %000, see above.)

Yani $33? Karakter rom okunabilir hale geliyorsa burada, yazma yapılınca da ram'e mi yazar acaba?

Cengiz gibi ustaların affına sığınarak sesli bir video çektim.

63dpO5cVcg0

Merhaba retro oyun severler diye girecektim videoya az daha :)

Günaydınlar, hocam sd kartın içeriğini paylaşman mümkün mü?

@i_r_on : Kartuşun çalışması hakkında çok güzel bilgiler sağol...

Videodan da anlaşılıyor ki bu IRQhack64 hızlı. Oyunların crunchlanmamış sürümleri ile oyundan oyuna geçmek ışık hızında olacak neredeyse

Sahi, acaba bir video arşivi listesi mi yapsak CGTR'de?

Giderek harika şeyler görüyoruz.

Bu arada, C128'in 2MHZ hızı için de bir transfer rutini düşünüyorum.
C64 modunda $d030'a 01 yazarak 2MHz'e geçebiliyor. 00 yazınca tekrar 1MHz'e düşüyor.

Sanırım 2-3sn'de GEOS'a kadar inebiliriz. (not: autoswap.lst'a bir geos imajı koyup açılışta SD2IEC'nin sonraki tuşuna basabiliriz. Alternatif olarak gerçek 1541'de GEOS diski varsa geosnap onu kullanabiliyor.)

Bu hız için GeosSnap'i de baştan yaratmak gerekecek.

Bu arada, $01 değerleri için:

Bizim hiç Commodore 128'imiz olmadı ki :(

Bu tablolarla ilgili sıkıntı hep Read için neresi kullanılacak onu vermeleri. Halbuki I/O bölgesi özel. Buradan 3 değişik yerden okuma yapmak (char rom / io / ram), 2 değişik yere de yazmak mümkün (ram/io)

Rom'dan okuyorsan, yazdığında da ram'e yazarsın genel kuralından hareketle $33 kullanmak gerekir diye düşünüyorum.

Evet, 33. Yoksa ROM'dan çıkıyoruz. Bu arada elektronikçiler çarşısını biraz deştim demin. İki yeni sürpriz proje yolda :)

@arnavutrafet : aşağıdaki linkten indirebilirsin. Hvsc klasörü 200-300 mb falandı onu dahil etmedim.

http://www.tepetaklak.com/data/SdContent.zip (http://www.tepetaklak.com/data/SdContent.zip)

@ilkerficicilar : Merak ettim neymiş bu sürpriz projeler?

Çok teşekkürler.

@i_r_on Sürpriz :) İpucu: modern teknolojiyi C64'le buluşturma ve minyatürizasyon amaçlı.

Güç kaynağını değiştirme ve küçük lcd ekran bağlama?

%50 sürprizi kaçtı!.. Max660 kullanarak C64'e giren güç fişi kadar, yani parmak ucu kadar bir adaptör yapılabilir gibi görünüyordu. Çarşamba gibi geliyor parça, onu deneyeceğimdir. Bir ucu C64'e girecek, diğer ucuna da bir cep tel şarjı ucu takılıyor.

Diğeri ise ESP8266... C64'e Bluetooth taktıysak WiFi niye takamayalım diye bakınınca bunu buldum. Şimdilik tek sorun ATE0 ve AT+CIOBAUD=9600 komutunu gönderebilmek. TCP/IP stack vb. bu pul kadar cihazın içinde.

Eğer 9600bps fiber hızında(!) wifi'ye çıkabilirsem, şunu deneyeceğim:

AT+CIPSTART="TCP","192.185.46.66",80
AT+CIPSEND=38
GET / HTTP/1.0\nHOST: commodore.gen.tr\n

Arkasından gelen veriyi de artık şu Hyperlink programına vermenin bir yolunu bulmak gerekecek: http://www.armory.com/~spectre/cwi/hl/manual/hl25ic.html (http://www.armory.com/~spectre/cwi/hl/manual/hl25ic.html)

Ya da sadece telnet BBS'lere bağlanırım... Hele bir önce C64'le WiFi'ye bir çıkalım da. Kullanımı zor değil: http://wiki.iteadstudio.com/ESP8266_Serial_WIFI_Module (http://wiki.iteadstudio.com/ESP8266_Serial_WIFI_Module)

Aklıma gelen üçüncü şey de wifi idi ne yalan söyleyeyim :)

Arada sırada uğraşma fırsatı bulabiliyorum. Zamanlama konusunda esas sıkıntı çıkaran naneyi tespit ettim. Arduino üstünde milisaniye cinsinden zamanlamayı takip eden bir interrupt var. Zamanlamayı bu bozuyormuş. Kritik yerlere girip çıkarken interruptları kapatıp açtım,  4 byte gönderimi stabil hale getirdim. 8 byte'ı da bir deneyeyim dedim. Onda da ilk denemeler başarılı.

Olur da hızlı çalışmasında bir sorun olursa diye kartuş üstündeki butona 1 byte / 4 byte / 8 byte hızlar arası switch etme özelliği ekledim. Kartuşu tasarlarken bileydim turbo butonu koyardım :)

Geos crunch'lı hali ile 4 saniyeye indi. Crunch edilmemiş olsa herhalde 2-2.5 saniyede falan açılacak.

8 byte sınır, eprom'da kod yazacak yer kalmadı :) Zaten 8'in ötesinde kazanılacak hız artışı  byte sayısı arttıkça 0'a doğru yakınsıyor. Hep interrupt'a girme ve çıkma maliyetini byte başına bölüştürdüğümüz için böyle.

!!! Amanın :)

C64 için 2 saniyede 50K gayet süper bir hız... 8 byte/IRQ da öyle.

Oyunların da Crunch'sız, Intro'suz hallerini bulmak gerekecek. Eskiden yüklemede hız ve yer kazandırsın diye yapılanlar darboğaz haline geldi artık resmen.

Bu arada, Arduino'daki interrupt hiç aklıma gelmemişti... Giderek İspanyol adına benzeyecek olan TurboIRQhack64-8 için çok teşekkürler :)

Bu interrupt meselesi aslında benim başıma sid player'da da sıkıntı yaratmıştı ancak bu sefer geç uyandım meseleye.

Sana bir soru sorayım, Şu an eprom'daki bank switch'i dönüp implied addressing kullanan komutların (INY, NOP vesaire) üstüne getirmeye çalışıyorum. LDA #$EA'nın dışındaki alınan byte'ın saklandığı STA (ACTUAL_LOW), Y  kısmında bir yere denk gelmiş olsa sorun olur mu sence?

Crunch başa bela hakikaten ancak onun da yer kazanımının dışında iki kullanım sebebi daha var anladığım kadarıyla. Birincisi introcu egosu, diğeri de hakikaten freeze falan yapılarak save edilen bir şeyse mecbur compact edilmek zorunda saklanan şey.

Hakikaten de kartuşlar yükleme süresinin en az 5-10 misli decrunch'ın bitmesi, üstüste koyulmuş intro'ların geçilmesi sürüyor :) Eskiden koyulmuş Triad, Fairlight, Ikari vesairenin introsu neyse de 2010 küsür senesinde koyulmuş introyu geçmek beni darlandırıyor :)

LDA'yı geçtikten sonra bir soun olmaması lazım, ne de olsa komut bankların hepsinde aynı, CPU'nun belleğe erişimi zaten izin verildiği müddetçe oluyor, komutu yanlış okuma olasılığı olmaması gerek.

Bu arada, hızlı bir Crunch bilen var mı?

Bugün GEOS'u 16KB'lık Eprom'a sıkıştırmayı başardım, EasyFlash'a yazdım, ince ayar isteyen bir iki ufak pürüz dışında çalışıyor. Gelgelelim IRQhack64'te aldığım tadı alamadım :) Pucrunch kullandım, iyi sıkıştırıyor ama yavaş.

Ben de öyle düşünüyorum. Bugün NOP'u da kaldırıp bir deneme yapayım bakayım. delayMicroseconds yerine tam cycle zamanlarını tutturacak avr nop'larından macro'lar yapmıştım, onları kaldırıp tekrar delayMicroseconds ile deneyeyim. Zamanlama tam tutsun diye döngüsüz nop'ları koyunca kod baya şişiyor.

Hız testlerini yapmak için güzel bir yöntem buldum bu arada. Menüyü 1 byte metodu ile transfer edip dosya listesini çekmeyi 8 byte ile yapınca transferin kalitesi hızlıca test edilebiliyor.

Kartuşun yeni hızını doğru bir şekilde yansıtabilmek için bana da delice crunch'lanmamış oyunlar lazım.