sonraki »

[ilkerficicilar]

Dosya şurada:

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 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.

[Simon (Özay Turay)]

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

[LW3D]

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

teşekkürler

[ilkerficicilar]

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
(600 Sterlin istemiş!)

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

[KNG]

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.

[ilkerficicilar]

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ı.

[i_r_on]

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.

[ilkerficicilar]

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:

Kod:

Teyp PS/2 USB
---- ---- ---
  A    3   4
  B    4   1
  F    1   2
 D,E   5   3

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.

[i_r_on]

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/[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?

[KNG]

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

[ilkerficicilar]

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

[i_r_on]

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

[i_r_on]

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,

Kod:

	LDA #$EA		
	STA (ACTUAL_LOW), Y
	INY			

	LDA #$EA	
	STA (ACTUAL_LOW), Y	
	INY			

	LDA #$EA		
	STA (ACTUAL_LOW), Y	
	INY			

	LDA #$EA		
	STA (ACTUAL_LOW), Y	
	INY			

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.

[ilkerficicilar]

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.

[i_r_on]

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.

Kod:

WAIT
	BIT BITTARGET	
	BVC WAIT

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.



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