09/11/2011 itibarıyla TRDOS * Device driver çalışmalarımda FreeDOS'un himemx.exe XMS sürücü dosyasını yükleyip çalıştırdım. Ayrıca bazı büyük ve eski oyun programlarını ve assembler (FASM) programlarını çalıştırmayı denedim. Programlar çalışmadı ama FASM (dos) bir kez exedemo.asm dosyasını derledi (ve o program çalıştı: hello world! dedi) fakat başarıyla çalışma olmadığından msdos/freedos/rxdos uyumsuz dosya prosedürleriyle uyumlu çalışma sağlamakta ısrar etmekten vazgeçtim. * TRDOS'u mevcut 9/11/2011 haliyle arşivleyip bundan sonraki çalışmaları RxDOS'un (dissecting dos) process management (1995) açıklamalarına ve kaynak koduna kısmen dayandırarak ve MSDOS'un bu ay başında internetten indirdiğim 6.0 kaynak kodundan faydalanarak, 'load and execute process' ten başlayıp, geriye doğru değişikliklerle yenilemeye karar verdim. Yeni Kernel daha fazla MSDOS ve RxDOS Kernel (structure) uyumlu olacak. Buna karşılık, TRDOS'un Singlix'i geliştirmek için uyarlanmasında DOS'un memory management veya file handling yönetmlerini değil, TRDOS'da ilk kez tasarladığım yöntemleri geliştirerek uygulayacağım. TRDOS'un yeni kernel'i ise DOS'a device mantığıyla daha fazla benzeyecek. * Elimde UNIX v1.0 PDP 11 kaynak kodu olduğundan önce 8086 Unix (çok basit haliyle) geliştirip sonra Singlix'e geçmeyi düşünüyorum. Fakat, kısa vadede (2011 bitmeden 2012'nin ilk aylarına sarkacak şekilde) TRDOS'u RxDOS kaynak kodu ve MSDOS 6.0 kaynak kodundan faydalanarak ama taklide kaçmadan (bazı structure'lar ve fonksiyonları geriş ve çıkışlarında mecburen aynı olacak) Faz 3 olarak geliştirip tamamlayacağım. (Eski versiyon -> 2005, Bu versiyon -2009/2011 Faz 2 burada sonra eriyor. TRDOS Faz 3 bundan sonraki ve son aşama. Yeni TRDOS Proje adı: TRDOS3.) 05/11/2011 itibarıyla TRDOS * Device driver initialization prosedüründe ekrana başlama/yüklenme mesajı gelmeme sebebinin trdos kernel interrupt handler'larının aktifleştirmemsi olduğunu fark ettim (run prosedürü içinde içinde aktifleştiriliyordu ve programdan komut yorumlayıcısına dönüşte resetleniyordu. Aygıtın başlatılması (device_init) prosedüründe trdos kernele ait dos interruptlarının aktifleştirilmesini sağladım ve işaret koydurup, daha sonra resetlenmesini önledim, aksi takdirde aygıt sürücü ile interrupt vektörleri ilişkisi kesilirdi. Bu yöntemi uygulayınca, bazı dos device driver'ları init mesajlarını vermeye başladı. 30/10/2011 itibarıyla TRDOS * 27 ve 28 Ekim 2011 günü TRDOS'un device driver'ları tanıması ve kullanabilmesi için yaptığım çalışmalara devam ettim. Henüz sonuç çıkmadı. Aygıt sürücüleri init mesajlarını göremedim. Kendi yazdığım basit device driver taslağı ise init mesajını veriyor. * 30 Ekim günü kontrol maksatlı DEVLIST komutunu ve ilgili prosedürleri yazdım. (Device listesini basit bigilerle satırlar halinde yazıyor.) 23/10/2011 itibarıyla TRDOS * 9 Ekim 2011 ve 23 Ekim 2011 günü TRDOS'un device driver'ları tanıması ve kullanabilmesi için DEV_INIT.ASM dosyası açıp bu dosya içine gerekli prosedürleri yazdım. 24/09/2011 itibarıyla TRDOS * INT 27h Terminate and Stay Resident işlevselliği için gerekli ekleme ve değişiklikleri yaptım. * Çalışan programın başka bir programı çalıştırması (INT 21h AH=4Bh ile) durumunda çalıştıran/parent programın PSP adresini 'PSP_Address' değişkenine geri döndürmek için (dosya kapatma işleminde doğru PSP adresi lazım) proc_create_psp prosedüründe ve ayrıca, int 20h ve int 21h AH=4Ch dönüşlerinde gerekli değişiklikleri yaptım. * DRV_FS.ASM içinde dos dosya adı uzantılarında "$,-,#" karakterlerinin uygunluğu için düzeltme gerekiyordu onu yaptım. 19/09/2011 itibarıyla TRDOS * INT 21h Fonksiyon AH = 56h Rename file (Move directory entry) kodunu yazdım. (INT_21H.ASM) * FS dosya sistemi dosyalarını DOS 8+3 formatına çevirirken "$,-,#" karakterlerini de geçerli olarak kullanması için gerekli düzeltmeyi yaptım. (DRV_FS.ASM) 18/09/2011 itibarıyla TRDOS * Varsa MAINPROG.CFG dosyasına göre başlangıç tamam. "*" remark (boş geç) ve "echo" komutu ile "mainprog.cfg" dosyasından basit işlemler tamam. Kernel bir kez mainprog'a geçerse (daha önceden startup.cfg varsa oradaki "shell" komutuna göre varsayılan/default shell olan internal mainprog'a geçmeden external shell'i başlatabilir. Bu kısmı daha sonraki aşamalarda yazacağım). MAINPROG.CFG dosyasının içine yazılan tüm tanınan komutlar sırasıyla uygulanır ve dos içindeki en son komuttan sonra, normal çalışmaya geçilir (proc_dos_prompt döngüsü içine girilir.) (AUTOEXEC.BAT'ın çok basit bir karşılığı.) * proc_change_current_directory prosedüründe iyileştirme ve son directory bulunamdığı zaman bulunduğu yere kadar doğru göstermesini sağlayan düzeltme yaptım. (Dönüşte alt dizinlerden en son bulunanı gösteriyor. Fakat kayıtlamıyor. Yani restore current directory olursa, kayıtlanmış en son durumuna geri dönülüyor.) 17/09/2011 itibarıyla TRDOS * 12 byte'tan uzun (path içeren) program dosya adı yazarak program çalıştırma tamam. 15/09/2011 itibarıyla TRDOS * İç ve dış komutlarda az düzeltme yaptım. Özellikle 8 byte'dan fazla dış komut (path içeren program dosyası adı) çalıştırmaya yönelik işlem değişikliğini (MAINPROG.ASM içinde) yaptım. * PATH değişkeninin directory'leri içinde aranarak bulunan ve yüklenen program dosyaları normal dönüşlerde/çıkışlarda, programı çalıştırmadan hemen önceki current directory'e başarılı dönüş yapıyor. (Directory adlarını root'tan başlatarak PATH'a yazmak şart olabilir. Kontrol etmedim ama böyle olması daha uygun, aksi durumda alt dizinler relatif olduğundan PATH karma karışık olur, arama root directory'den başlatılmalı.) * CTRL + BREAK dönüşünü dün değiştirmiştim; bazı programlarda dönüşte aksama oluyor ama yapacak bir şey (şimdilik) yok. Geri dönüşte komut yorumlayıcısıyla bağlantı kesilebiliyor. "Bad command or file name!" dönüyor. Program CTRL + BREAK tuşlarını kullanmadan başka tuşlara göre (kendi kontrolünde) sonlanırsa, bu arıza olmuyor. 14/09/2011 itibarıyla TRDOS * TRDOS run komutu olmaksızın program adı ve ve path ile çalışıyor ayrıca programlar ctrl-break ile opsiyonlu olarak sonlandırılabiliyor. PATH değişkeni üzerinden dosya bularak çalıştırma tamam, dönüşte problem var (run'dan önceki dizine dönmediği oluyor, komut bağlantısı kesiliyor, belki es=ds=cs değil veya başka bir sebepten...) 11/09/2011 itibarıyla TRDOS * internal (cmd_run) ve external (cmd_external) komut çalıştırma ve program dosyası yükleyip çalıştırma prosedürlerinde (CMD_INTR.ASM) hata düzeltme maksatlı değişiklik yaptım. Bu kapsamda find_first_file prosedürü girinde ES=CS ataması yaptım. Bu prosedür girişte dosya adı FindFile_Name adresiyle girse dahi aynı adrese (farklı segmentve ofsetten geldiğini varsayarak) kopyeleme yapıyor. Bu kısım gereksiz gibi görünse de, başka girişlerde gerekli olduğundan bu kısmı değiştirmedim. ES'nin CS'den farklı olarak find_first_file prosedürüne giriş yapması (open_file prosedürüne ikinci girişte) ilk çıkışta ES farklı olduğu için, uzantısı değişen program dosyasının (COM olarak arandıktan sonra EXE olarak aranacakken) bulunamamasına sebep oluyordu. Bunu düzelttim. 10/09/2011 itibarıyla TRDOS * RUN komutunuda değişikliğe giderek RUN komutunu iptal etmeden, dosya adını uzantısı ve path varsa doğrudan; dosya uzantısı yoksa sırasıyla COM, EXE uzantıları ekleyerek, program dosyası aratıyorum. Dosya adında path yoksa ve dosya bulunamamışsa, path uygulayarak (çevrim) dosyayı yenden aratıp, bulunursa yükleme şeklinde CMD_INTR.ASM içinde cmd_run ve cmd_external kısmında önemli değişiklikler ve eklemeler yaptım. Bu şekilde dosya çalıştırmada path environment değişkeninin/dizgisnin kullanılması ile (hata düzeltme kısmı hariç) TRDOS'un çok önemli bir geliştirme aşamasını geçmiş oluyorum. 05/09/2011 itibarıyla TRDOS * INT 21h, Function AH=7 ve AH=8 fonksiyonlarını yazdım. (INT_21H.ASM içinde) 04/09/2011 itibarıyla TRDOS * INT 21h Memory block allocation, deallocation fonksiyonlarını ekledim, modify memory allocation prosedüründe düzeltme yaptım. TRDOS kernelin kendi içinde dosya yükleme ve kapatma esnasında kullandığı bellek atama tipiyle bellek atama ve belleği serbest bırakma işlevini bozmaması ve yanlış segmenti bellek atama tablosundan silmemesi için, DOS ile INT 21h üzerinden uyumluluğu koruyabilmek için, INT 21H üzerinden 8 farklı (herbiri için 1 bit kullanarak ve F8-FFh arası atama kodlarını ayırarak) bellek ataması (fonksiyon 48h) yapmaya olanak veren prosedür yazdım. Dolayısıyla bellek serbest bırakma işleminde sadece F8-FFh atama kodlu INT 21H ile atanan segmenti boşaltabilmesi (hatasız deallocation) için böyle bir çözüm buldum. Aksi takdirde mevcut prosedürü çağırınca başladığı segment için aynı atama kodunu gördüğü tüm bellek bölümünü seri olarak boşaltacaktı. 03/09/2011 itibarıyla TRDOS * PATH komutunun SET ile aynı environment block'tan işlem yapacak şekilde gerçekletiridim. * PROMPT komutunun düzenlediği TrdosPromptLabel'i SET komutuyla düzenlenen Envrionment Block'a bağlamdım; böylece SET komutu PROMPT atasa dahi TRDOS Mainprog sadece kendi TrdospromptLabel değişkeninden/yerinden prompt etiketi kullanıyor. Bunu böyle bırakmamım iki sebebi var; birincisi prompt almayı TRDOS için karmaşıklaştırmamak, basit bırakmak, mevcut iyi halini korumak. İkinci amacım kullanıcı seviyesinde veya başka bir komut yorumlayıcıyla kullanılabilevcek prompt ile ROOT promptunu (veya mainprog promptunu) ayrı tutmak. * COPY komutu kapsamında create fs file prosedürü 32MB'dan büyük FS section açamadığından 32MB'dan büyük dosyalarda write işlemi esnasında küçük boyutlu section eklemeleri oluyordu. (Küçük eklemelerin sebebi dosyaya yazma esnasında gelen ilave sektör talebinin az olması; ki, bu normal çünkü kullanıcı programının ileride ne kadar yazacağını kernel şimdiden tahmin edemez.) Bu aşırı hız kesiyordu ve hız azalması percent printing esnasında belirgin görülüyordu; yani, 32 MB'a kadar ilk sectiona yazarken hızla ilerleyen yüzde daha sonra çok yavaşlıyordu (Örneğin 37MB dosya için %85'den sonra yavaşlama oluyordu.) Çözüm için önce create_fs_file prosedürünün ne kadar data sektörlük section oluşturduğuna baktırdım, üst sınır (65534) ise ve dosya daha büyük ise gerekli olan ek sektörleri içeren (yine en çok 65534) bir ek section oluşturmaya çalıştım. Sonra ek section oluştururken durumu "+" ve "." işaretleriyle göstermeyi düzenledim. Böylece önce "/-\|" sonra "+." ve sonra "%" işateri ile kullanıcıya işlemin devam ettiğini gösteriyorum. FAT için create file prosedüründe tek cluster yeterli olduğundan sadece % gösteriyorum. FS'de tüm dosyayı tek section yapmaya çalışmam okuma ve disk kullanma verimliliği için. FAt'ta clusterlar sabit büyüklükte olduğunu yapacak bir şey yok. 02/09/2011 itibarıyla TRDOS * SET komutu ile ilgili geliştirmeler. * COPY komutu write percent printing (>16MB) düzeltmeleri. (FILE.ASM içinde) 01/09/2011 itibarıyla TRDOS * SET komutu ile ilgili düzeltmeler. 30/08/2011 itibarıyla TRDOS * SET komutu ile ilgili düzeltmeler. 29/08/2011 itibarıyla TRDOS * SET komutunu eski yarım kalan TRDOS çalışmasından türeterek yeniden programladım. Ama önemli ölçüde farklı oldu ve kernel dışındaki belleğe opsiyonel atamalı oldu (512 byte) sadece set gerekirse atanıyor. Ve msdos uyumlu olması içi aynı şekilde zero tail ile düzenledim. msdos uyumu set komutunu zorlaştırdı ama düzeltilecek hatalar, psp'de adreslenmesi, set edilmiş environment stringlerin tamamı silinince environment blocku bellekten silme (deallocation) gibi ilerletmeler dışında esası tamamlanmış oldu. Path, sheel ve prompt'a özel muamele gerekiyor... 21/08/2011 itibarıyla TRDOS * Çözdüğümü sandığım ama bugüne kadar devam eden FAT32 dosya sisteminden FSINFO sektöründen sonraki sektörlere ilgisiz yazma yaparak FAT'ı bozması probleminin ikinci ve asıl sebebinin get_first_fre_cluster prosedüründe fsinfo sektörünün 'next free cluster' alanında yer alan cluster adresinin kontrol edilmesi ve gerekiriyorsa set_first_free_cluster prosedürünü çağrılıp yeni değerin kayıtlanması işleminden kaynaklandığını saptadım. Set_first_free_cluster prosedüründe BX fsinfo sektörü girişi (bx>0) olduğu zaman cx=1 (yazma sektör sayısı) eşitlemesi yapılmaması ve yazılan sektör sayısının fazla olması nedeniyle yazma işlemlerinde FSINFo sektöründen FAT'a taşma oluyor ve FAT bozuluyordu. Bugün düzelttim. Artık FAT32 dosya sisteminin dosya yazma (cluster ekleme) veya dizin oluşturma işlemi esnasında (bu sebepten) bozulma ihtimali/durumu kalmadı. 11/08/2011 itibarıyla TRDOS * Uzun süredir beni uğraştıran, FAT32 dosya distemine yazma işlemi esnasında FAT'ın bozulması problemini çözdüm. Sebebi yine basit çıktı. BX register'inin içeriği değiştiği halde FAT buffer segmente eşit olduğu varsayımıyla yeniden atama (;mov bx, word ptr [FAT_Buffer]) yapmamam, FAT Buffer segmentinin sıfırlanıp, FAT buffer'in diske yanlış bellek bölgesinden (genel olarak sıfırıncı segmentten 3 sektör) yazılmasına yol açıyordu, bu da dosya sistemini bozuyordu. Basit bir sebebi daha önce de olduğu gibi, yine günlerce araştırıp farkedemememiştim. Bugün çözmüş oldum. 07/08/2011 itibarıyla TRDOS * DRV_INIT.ASM içinde "FAT partition validation" prosedüründe FAT partitionları yanlış okutan bir hata fark ettim. Bu hata son değişikliklerin dl'de fiziksel sürücü numarasını bozması ve dl'ye yeniden fiziksel sürücü ataması yaptırmadan boot sektörü okutmamdı. Sonuçta sürücü içeriği yanlış kuruluyordu. Ayrıca, extended partitionun altındaki partitionun boot sector adresi yanlış hesaplanıyordu. Bunları düzelttim. * FILE.ASM içinde create_file prosedüründe düzeltme yaptım. * DRV_FS.ASM içinde create_fs_file prosedüründe düzeltme yaptım. * INT_21H.ASM içinde find_first_file ve find_next_file prosedürlerinde attributes giriş çıkışına göre düzeltmeler yaptım (FDWRITE.COM'u çalıştırırken bu programın içinde find first file fonksiyonunun ms-dos'ta found dönerken tr-dos'ta not found ile dönmesi hatasını düzelttim. Giriş attributes'i 27h olduğu halde çıkışta 27h ile AND işlemi sonucunun 27h olmaması file not found error döndürüyordu. Sonuçta, '27h içeriğinin herbirinin olması durumu şart değil, bunlardan birinin olması yeterli, bunların hiç biri geçerli değil ise dosya bulunamadı say' anlamında düzeltme yaptım.) 01/08/2011 itibarıyla TRDOS * Save_fat_buffer, save_directory_buffer prosedürleri ve ilgili diğer prosedürlerde ufak iyişeştirmeler yaptım ve kullanmadığım ek emniyet tedbirleri uyguladım. (FAT12-16-32 dosya sistemini yanlış yazarak veya buffer'arı diske eksik yazarak sistemi bozmamak için.) * DRV_INIT.ASM içinde trdos'un extended partitionu doğru görmesini önleyen, eski kodun artığı gibi fazladan duran kodlardan kaynaklanan hatayı düzelttim. (Start sector değerini yanlış hesaplamaya sebep oluyordu.) 31/07/2011 itibarıyla TRDOS * Extended partition'un altındaki partitionun logical dos drive olarak doğru yüklenememe problemi olduğunu gördüm. Bunun için drv_init.asm içinde 30/07/2011 ve 31/07/2011 işaretli düzeltmeler yaptım. * DRV_FAT.ASM ve DRV_FS.ASM içinde bazı küçük düzeltmeler ve değişiklikler yaptım. * Belleğe sığmayan dosyaların kopyelenmesinde dosya sistemini tahrip etmesi veya hata vermesi problemi devam ediyor. FS dosya sistemine bazen doğru kayıt yaparken, FAT32'ye yanlış kayıt yapması problemi devam ediyor. * Sector buffer üzerinden COPY (belleğe sığmayan dosyalar) işlemindeki dosya sistemini bozma veya hata verme problemini çözdükten sonra, copy komutunu geçip, INT 21h, set, path, (autoexec.bat'ın muadili) startup konfigürasyonu, 'run' yerine dosya adıyla komut çalıştırma ve 64K kernel'e sığarsa iso 9660 dosya (atapi cd-rom) sistemini read only dos drive olarak trdos kernel'e bağlama işlemlerine başlayacağım. TR-DOS 2. versiyonu yazmadan önce, 1. versiyonun kaynak kodu üzerinden 32 bit singlix işletim sistemini geliştirmeyi düşünüyorum. (2002'den buyana... Şimdiki TR-DOS ilk versiyonun yeniden canlandırdığım hali; yani, önceki 1. versiyon, 1998-2002 presentator/p2000.com ve tr-central çalışmalarına dayanan 2005 yılı başlangıçlı basit bir taslak halindeyken, yeni TRDOS v1.0 çalışmalarıma 2009 yılında başladım. Zaten bu dosyanın en altında ilk durum bildirimi için 7/7/2009 tarihini vermişim.) * Sinclair spectrum için geliştirmiş trdos işletim sistemiyle isim benzerliği 29/07/2011 itibarıyla TRDOS * Yeni DRV_INIT prosedürü (versiyon 4) önceki gün sadece primary FAT partition'lar için çalıştı FS ve extended FAT partition'lar için çalışmadı, dün ve bugün asm kaynak kodlarında düzeltmeler yaptım. Bugün için TRDOS extended FAT ve Singlix FS partition'ları görmüş oldu. Böylece yeni TRDOS Drive Initialization kodu yazımını (BugFix veya iyileştirme gerekebilir) tamamlamış oldum ve uygulaması gerçekleşmiş oldu. 24/07/2011 itibarıyla TRDOS * Son FAT32'yi bozan kopyeleme hatalarını düzeltemeyince DRV_INIT.AS üzerinde çalıştım ve bu dosyadaki DRV_INIT prosedürünü büyük ölçüde değiştirip, iyileştirdim. TRDOS.ASM içinde ufak değişiklik yaptım. * Save FAT Buffer ve Save Directory Buffer prosedürleri için dosya ve dizin yazan herhangi bir komutun sonunda kendi buffer'larında 'buffer changed/written' işareti varmı diye bakılacak. Varsa işlem tamamlanacak. Bunun amacı ani kapatma veya elektrik kesilmesinde içeriği değişen buffer'ı (yazma işareti "2" olacan) diske kayıtlanmamış halde bırakmamak. ("0" geçersiz, "1" diskten okunduğu gibi, "2" değişmiş anlamında...) Şimdilik bu hususu erteliyorum. 18/07/2011 itibarıyla TRDOS * 9 sektörlü FAT buffer floppy diske yazma işlemini pek hızlandırmadığı için 3 sektörlü buffer kullanımına geri döndüm. * Write file prosedüründe RW buffer ile yazmada FS dosya sistemine hata verdiren prosedürü araştırmaya devam ediyorum. "get section for file sector" dönüşünde hata oluyor... 17/07/2011 itibarıyla TRDOS * Write file işlemine % sayacı ekledim. Bu sayaç dosya boyutuna bağlı olarak sektör veya 64K sektör için sayaç aktivasyon alt sınır kontrolü yaparak copy source file to destination file prosedürü içinden ayarlanıyor. * FAT buffer size'ı floppy diske yazma işlemini biraz daha hızlandırabilmek için 9 sektöre çıkardım DRV_FAT.ASM içinde gerekli değişikleri yaptım. * Büyük dosyalarda (rw buffer'li işlemlerde) sebebini bulamadığım hataar devam adiyor. Bu hatalar create file aşamasından sonra oluşuyor. Tanımlanmamış 50h, D0h gibi dönüş oluyor. Bunun sebebi bugün en son düzeltmeyi yapmadan önce bellek atamasında boş yer olmadığı zaman okuma yama için referans alınan rw buffer size'ı küçültmediğim halde atanan bellek bölümünü küçültmem ve taşma olabilir. Sonraki günlerde çözmeye çalışacağım. 16/07/2011 itibarıyla TRDOS * FILE.ASM içinde copy file ve write file prosedürlerinde gereken bazı düzeltmeleri yaptım. (rw buffer ile büyük boyutlu dosyaları kopyelemeyi aksatan ve invalid data -0Dh- hatası döndüren kusurları düzeltmiş oldum.) * DRV_FS.ASM içinde add new section prosedürüyle 32MB'a kadar mümkün olan en yüksek boyutlu section oluşturmak için COPY komutuyla ilgili bazı düzeltme ve iyileştirmeler yaptım. * Windows iki adet primary partition oluşturmadığı için Linux KDE'de oluşturduğum primary FAT32 partitionu diskmanager'mkdosfs' adıyla FAT32 CHS (OBh) olarak kayıtlamış (0Ch -> LBA daha uygundu). Ayrıca boot sector'ün hidden sectors alanına partion'un başlama adresi yerine SIFIR sayısı girmiş. DRV_INIT prosedürünü extended partition'da bunun için partition table'dan başnagıç adresini alarak logical dos drive'ın başlama adresine ekliyordu (toplama işlemine katılan hidden sectors 0 olduğu için) fakat primary parition için bu düzeltmeyi yaptırmamıştım; bugün extended veya primary ayrımı olmaksızın, tüm 0Bh partitionlara aynı işlemi yapacak şekilde düzelttim. (Bu düzeltme olmadan C: olması gereken FAT32 partition TRDOS'da hem var görünüyordu hemde işlevsizdi, D: drive olması gereken Singlix FS partition D: ile aranırken C: gibi görünüyor ama içine doğru işlem yapılamıyordu.) 14/07/2011 itibarıyla TRDOS * FILE.ASM içinde 'copy source file to destination file' prosedüründe'insufficient memory' hata dönüşü durumunu (max. kesintisiz bellek bölümü atamasında sektör sınırlarına göre budama yapılınca istenen büyüklük 1 eksildiği için hata dönüşü oluyordu.) düzelttim. * Numeric tail (~) içeren dos dosya adının aynen kopyelenmesi durumda FS dosya sistemindeki dizin dos uyumlu hazırlanırken "~" karakteri geçeriz sayılıp, onun yerine "_" karakteri konuyordu. Sonuçta, 'create fs file' ile oluşan dosya adı 'open file' prosedürünün 'find first file' aşamasında 'file not found' hatasını döndürüyordu. Bu durumu düzelttim. 13/07/2011 itibarıyla TRDOS * 'rw buffer' kullanarak dosyaya yazma (belleğe sığmayan büyük dosyaları kopyeleme) işleminin çok yavaş olması nedeniyle write_file prosedürü içindeki okumayı gerekmedikce yaptırmamak için ve ayrıca buffer size'ı mümkün olduğunca fazla tutup read ve write geçişlerini (farklı diskler arasında geçişleri) azaltmak için, FILE.ASM içinde bazı önemli değişiklikler yaptım. Ayrıca, hata dönüşü durumunda atanmış buffer'ı bellek atama tablosundan düşürmek (serbest bırakmak) için düzeltme yaptım. * TRDOS şimdiki durumda yazma işleminde hata olunca oluşturulan hedef dosyayı silmiyor. Hedef dosya boş veya kısmen yazılmış olabilir. (FS için boş ama tüm sektörleri atanmış, FAT için sadece 1 cluster atanmış hali, 'create file' sonrası halidir.) * Singlix FS dosya sistemli sürücüye dosya adında "~" karakteri olan dosya aynı adla kopyelenmek istendiğinde, create file prosedürü çalışıyor ama dosya adında "~" karakteri alt çizgi "_" olduğundan, 'file not found' hatası dönüyor. Bu uyumsuzluğu gidermem lazım veya 'invalid character in file name' olarak dosya adını red ettirmem lazım. (Long name'i olan dosyalar "~" karakterini barındırdığı için çok rastlanacak bir durum.) 12/07/2011 itibarıyla TRDOS * 'rw buffer' kullanarak dosya kopyeleme (belleğe sığmayanlar için, open mode 0 ile source file açılıp, read file yapılan işlemler) işleminde ilk 64KB + 1 okunan dosya cluster'ı dışında 'get_next_cluster'işleminin last cluster yerine first cluster'dan başlaması seklindeki hata dosyaları 64KB (tek seferden okunan max. buffer size) + 1 (source file) cluster'ı takip eden datayı baştan alarak kopyeletiyordu. Bu hatayı düzelttim. Yani, COPY işleminde <=64KB'lık bloklar halinde dosya okuma ve yazma işlemlerinde farkedilen kusur kalmadığı için, belleğe sığmayan 700 KB ve üstü dosyaları doğru kopyelemeyi başarmış oldum. (FILE.ASM içinde, 'read_file' prosedürü bugfixleri.) 10/07/2011 itibarıyla TRDOS * 'create_file' prosedüründe sadece FAT file sytem için kopyelenecek dosya boyutu kadar boş dosya oluşturmamak ve işlemleri hızlandırmak maksadıyla bx=FFFFh şeklinde bir işareti dikkate alma değişikliği. * 'copy source file to destination file' prosedüründe rw buffer üzerinden (open mode 0) okuma ve yazma işlemleri için hata düzeltme, iyileştirme ve kısmen yazma gerçekleştiği halde EOF'tan önce read file işleminde hata dönüşü oması durumuna göre düzenleme yaptım (FILE.ASM içinde) ve ayrıca bu duruma uygun olarak (CMD_INTR.ASM içinde) COPY kumutu dönüşünde düzenleme yaptım (CL register'i okuma hatasını gösteriyor), fakat kısmen yazma gerçekleştiği için, kaynak ve hedef dosyalar kapatılıyor ve hedef dosya diske kayıtlanmış oluyor. (Yazma hatası yok ise clc dönüyor ama okuma dosya sonuna ulaşarak tamamlanmamış ise, CL register'i >0 ile dönüyor. 0 -> hata yok.) 09/07/2011 itibarıyla TRDOS * FILE.ASM içinde 'read_file' ve 'write_file' prosedürlerinde iyileştirmeler yaptım (buffer'lı okuma ve yazma için). 05/07/2011 itibarıyla TRDOS * 'DMA crossed 64KB segment boundary' error dönüşünün asıl sebebinin segmentin 64KB'ı devirmesi ve offset değerinin geri dönmesi değil, belleğin 64KB'lık bölümleri arasında sınır ihlali (256 byte birinde, 256 byte diğerinde olmak üzere iki peşpeşe 64KB segmentin arasında geçiş) olduğunu ve fiziksel adresleri kullanarak çalışan DMD controller'ın 16 bit offset'in resetlenmesi dolayısıyla bu hatayı verdiğini internetten ilgili dökümanları okuyarak anladım. (04/07/2011) *Çözümün DISK_IO.ASM içinde 09h error dönüşünü başka bir buffer kullanma veya kaydırma v.s. yöntemlerle sağlanmasının saçma olacağına, MEM_INIT.ASM içinde proc_allocate_memory prosedüründe AND işlemiyle segment boundary check yapmanın yani 256 byte'lık atamalarda bellekteki 512 byte'lık bölümlerin sınırlarını aşmayan okumalar yapmanın bu hatayı kolayca düzelteceğini saptadım ve uyguladım. (proc_chs_read prosedürü INT 13h disk read fonksiyonunu sadece 1 sektör okumak için kullandığından, 512 bytelık sınırlarla bölünmüş atamayı garantiye almak yeterli) * TRDOS memory allocation table 256 byte değil, 512 byte'lık hücreler halinde düzenlenmiş olsa idi, bu hata olmayacaktı, ama, bu kez de 256 byte atamaları ve PSP'den sonra program blokunun gelmesi işlemleri aksayacak veya uzayacaktı. O halde gereken yerlerde 'segment boundary check' yapılmalıydı. En kolay yöntem MAT'ta 256 byte'lık offseti gösteren register'ı boundary check değeriyle test işlemine sokmaktı. Örneğin: 512 byte için boundary check değeri '1' olup, '1' ile 'and' işlemine sokulan offset değeri '0' sonucunu vermezse, 512 byte'Lık bölüm sınırından 256 byte taşma var anlamına gelecekti ve DMA controller'ın 64 KB'a yakın veya 64KB'ı geçen işlemlerinde INT 13h 09h hatası ile dönecekti. (BoundaryCheck değeri '3' olursa, bellek 1024 byte sınırlı atanacak anlamına gelir. Fakat '1' dışındaki değeri kullanmak gerekmedi.) * Bu şekilde CHS okumalarında (ve yazmalarında) DMA controller'ın segment hatası döndürmemesi için TRDOS kernel'in ilgili tüm dosyalarında 'call proc_allocate_memory' kodu olan kısımlarda 512 byte boundary check (dx=1) veya boundary check devre dışı (dx=0) değişikliklerini yaptım. DX register'ı bu prosedür girişinde boşta olduğu için onu kullandım. * Segment Boundary Check için PSP veya OFDT'yi içeren ön 256 byte için yukarıdaki 'and' işleminden '0' olmayan sonuç alma esasına dayanan değişiklği yaptım. (1 saat sonra). Çünkü FILE.ASM içinde 'load file' prosedürü için gerekli. 20/06/2011 itibarıyla TRDOS * DISK_IO.ASM içinde chs_read ve chs_write prosedürlerinde düzeltme gerekti. (Dün çözdüğümü santığım DMA controller hatası tekrarladı, çözüm olarak her bir sonraki sektör için BX'i aynı bırakıp, ES'yi 32 artırmak (32*128=4096*16 = 64K = 512*128) yöntemini seçtim. 19/06/2011 itibarıyla TRDOS * CMD_INTR.ASM, DIR.ASM ve FILE.ASM içinde 'parse_path_name' prosedürü 'file or directory name is not existing' (al=1) stc dönüşü ile ilgili düzeltmeler yaptım. Yani dosya veya directory adı belirtilmeyen dir, copy ve move komutu kullanımında hata dönüşü durumu düzeldi. ('dir c:', 'copy file.ext d:') * load_file prosedürünün özellikle 64'dan büyük veya segment sonunu aşan (ES:BX -> BX = 100h iken) dosya yüklemelerinde sebebini uzun süredir çözemediğim hatanın (TRDOS kernel'den 'Drive not ready or read error' hata dönüşü oluyordu ama INT 13h2den hangi hata kodu dönüşü olduğuna dikkat etmemiştim, stc yönlendirmesinde asıl hata kodunu kullanmıyordum.) Error 09h -> 'DMA crossed 64 KB segment boundary' hatası oldunu ve BX'in 256 gibi, 0 veya 512 olmayan bir sayı içermesi durumunda DMA controller'ın (16 bit) 64K sınırını aşmasından kaynaklanan hata kodu olduğunu fark ettim. FILE.ASM içindeki Load_File prosedürüne ES:BX buffer addresini ES:100h yerine (yeni ES değeri eski ES+10h) ES:0 ile giriş yaptırarak çözdüm. 12/06/2011 itibarıyla TRDOS * TRDOS.ASM ve MEM_INIT.ASM içinde memory initialization işlemlerinde düzeltmeler yaptım. (Kernel'in belleğe yerleşimi) 11/06/2011 itibarıyla TRDOS * 'proc_allocate_memory' ve 'proc_memory_init' prosedürlerinde düzeltme/iyileştirme yaptım. 31/05/2011 itibarıyla TRDOS * Main proc içinde include olan DIR.ASM ve FILe.ASM TRDOS.ASM içinde include olarak değişti, ASM dosyalarının iç sıralanışında kısmen değişme oldu. * FILE.ASM dosyasının boyutunu boş atamayla 256 byte büyüterek disk A ve B için dir listesinin oluşmasını sağladım. Sebebi belli olmayan bir aksiliğe geçici çözüm oldu. Ayrıca FILE.ASM içinde proc_open_file prosedüründe değişiklikler yaptım. Yine de, 64K'nın üstünde dosya okuma işleminde hata veriyor. Bellek atama hatası olması lazım, overwrite yapıyor olması lazım. FAT 16 formatlı C diskinde bu hatayı yapmıyor. (BOCHS emulatörde denedim...) 30/05/2011 itibarıyla TRDOS * 'mem_init.asm' içinde 64K'dan büyük memory allocation için 256 byte'lık hücre sayısı girişi eklemesi yaptım. 'file.asm' içinde open_file için 64K'dan büyük dosya açarken bellek atamasında hata farkettim (peşpeşe olduğu garantili boşluk ataması değil, peşpeşe olmayabilecek 64K atamaları yapıyordu). * A ve B sürücüsünün dir komutu artık çalışmıyor, muhtemelen buffer allocationla ilgili, bu durum file.asm dosyasında değişiklik yapınca oluyor. Bu günkü değişiklik dir listesini A ve B'den boşalttı... Fakat aslında 64K'dan büyük dosyaları açarken yaptığı hatayı düzeltmeye çalışıyordum, hedefe bir adım daha yaklaştım, şimdi overwrite'ın nerede olduğunu veya program kodunun nerede aksadığını bulmam lazım, BOCHS emulatör programında aksayıp, gerçek A'dan çalışırken aksamayabilir, deneyeceğim... Ama her iki durumda da kesin çözüme gideceğim. 29/05/2011 itibarıyla TRDOS * 'show' komutunda tab stop iyileştirmesi tamam (artık tab stop'ları tam doğru uyguluyor) * Geçici 'readfile' komutu ile file open for read (mode = 0) ve read_file prosedürleri kontrolü doğrulama ile sonuçlandı. (>64K dosya boyutu için 'full open' yapan show komutu ile (her seferinde 1 byte okumak üzere 'buffer open' ve 'read_file' yapan 'readfile2 komutu aynı ekran dökümü verdi ev aynı yerden kusursuz dosya sonu çıkışı/dönüşü yaptı.) Buna göre, 'copy' komutu prosedürlerindeki belleğe sığmayan büyük dosyaların (open mode 0 ile açılıp) kopyelenmesi kusurunu düzeltirken, 'read_file' hatası olmadığını doğrulamış oldum; hata başka yerde. 21/05/2011 itibarıyla TRDOS * 'proc_copy_source_file_to_destination_file' prosedüründe gereken bazı düzeltmeleri yaptım. * Open_file prosedüründe belleğe sığacak dosya büyüklüğü (full open veya sector buffer open) kontrolünde, DX = 16 olan (1MB) sınırı DX=8 (576 kB) olarak değiştirdim. Aynı değişikliği (bir seferde okunacak veya yazılacak byte'ların üt sınırı) 'read_file' ve 'write_file' prosedürlerinde de yaptım. * 'proc_load_FAT_root_directory' prosedüründe directory buffer ataması (deallocation) işleminde bugfix gerekti. Düzelttim. * 'open_file' prosedüründe 'load_file' prosedürü stc ile dönünce dosya için ayrılmış bellek restelenmiyordu; bu nedenle Load error durumunda 'close_file' işlemi yapan 'loc_open_file_check_load_error' kod kısmını ekledim. 19/05/2011 itibarıyla TRDOS * 'copy' komutunun FILE.ASM ve CMD_INTR.ASM içindeki değişiklikleri tamamlandı. 18/05/2011 itibarıyla TRDOS * 'move' komutu başarıyla tamamlandı. * 'copy' komutunun FILE.ASM içindeki prosedüründe 'move' komutuyla aynı mantığa göre önemli değişikliklere başladım. 17/05/2011 itibarıyla TRDOS * FILE.ASM içinde 'move source file to destination file' prosedüründe düzeltmeler yaptım. (Dün ve bugün ...) 15/05/2011 itibarıyla TRDOS * FILE.ASM içinde 'move source file to destination file' prosedüründe düzeltmeler gerekiyordu. Bu düzeltmeleri yaptım. MOVE komutunun son duruma göre çalışmasını henüz kontrol etmedim. Kaynak dosyanın erken silinmesini önleyen kontrolleri ekledim (4 fazda taşıma), böylece hedef dosyanın dizin girişi başarıyla gerçekleşmeden kaynak dosyayı sildirmiyorum. Ayrıca 'update parent dir lmdt' prosedürünün FS dosya sistemine işlem yapmaya çalışmasını önleyen düzeltme yaptım (çünkü öyle bir şey gerekmiyor ve ayrıca mümkün değil). 01/05/2011 itibarıyla TRDOS * Gereken düzeltmeleri yaparak MOVE (farklı directory'de RENAME) komutunun FAT ve FS prosedürlerini tamamladım. Ancak, komutun farklı source ve destination kombinasyonlarında kusursuz çalışması için düzeltmeler gerekecek. (Şimdilik böyle kalsın.) * COPY komutunda destination directory name yok ise aynı isimle kayıt yapıldığında source directory'e kayıt yapıyor ve mevcutluğu kontrol etmediğinden iki adet aynı dosya oluşuyor. Aslında komutun girildiği andaki current directory'e kayıt olması ve her durumda mevcutluğun kontrol edilmesi lazım. Bu kusuru ileride düzelteceğim. (Şimdilik kalsın...) 30/04/2011 itibarıyla TRDOS * DIR.ASM içinde proc_update_parent_dir_lmdt ve proc_make_directory prosedürlerinde Logical DOS Drive Description Table adresi olan DS:SI'yi çağrılan prosedürlerden dönüşte korumaya yönelik bazı düzeltmeler yaptım. (Şimdiye kadar kendini belli etmeyen Bug'ları Fix'lemiş oldum.) (Genel olarak prosedürden nasıl dönüldüğüne bağlı. Çoğunlukla DS:SI korunuyor görünse de dönüşün farklı noktadan olması beklenmedik bir hataya yol açacaktı. Örneğin: MKDIR komutu 'add new sub dir cluster' ile çalışacak olsa idi hata yapacaktı. Bu nedenle push-pop ile koruma eklentileri yapmak gerekti.) * MKDIR komutu prosedüründeki hatanın (Bug) aynen 'create file' prosedüründe de bulunduğunu fark ettim. FILE.ASM içindeki proc_create_file prosedüründe aynı sebepli düzeltmeyi yaptım. * Tüm bu düzeltme gerektiğen hataları MOVE komutunun prosedürlerindeki hataları arayıp, düzeltirken fark ettim. 24/04/2011 itibarıyla TRDOS * move_source_file_to_destination_file prosedüründe düzeltme yaptım. 23/04/2011 itibarıyla TRDOS * INT 21h rename fonksiyonuna uygun olarak kernel içinde 'move' prosedürünü ve CMD_INTR.ASM içinde 'move' komutunu yazdım. Rename komutundan farklı olarak destination farklı directory'de olabiliyor ve overwrite olabiliyor. Farklı drive olamıyor. Eğer move komutu directory değiştirmeden kullanılıyorsa 'rename' komutu gibi uygulanır (rename prosedürüne dallanarak). Düzeltmeler gerekebilir. 'Move' komutu prosedürlerini INT 21h rename fonksiyonunun altında çalışacak şekilde hazırladım. 'Rename' fonksiyonuna henüz başlamadım. 17/04/2011 itibarıyla TRDOS * Invalid Function Call handler'ını INT 21H dışındaki interruptlarda interrupt numarası dahil mesaj verebilmesi için INT_21H.ASM dışına, IFC.ASM dosyasına taşıdım... 15/04/2011 itibarıyla TRDOS * Bugün INT_21H.ASM içinde 'modify memory allocation size' fonksiyonunda push-pop hatalarını düzelttim. 14/04/2011 itibarıyla TRDOS * Dün modify memory allocation size konusunda MEM_INIT.ASM içinde mevcut blok boyutunu, tahsis tipi ve max. mümkün blok boyutunu döndüren proc_return_memory_allocation_status prosedürünü yazdım. Bugün INT_21H.ASM içinde modify memory allocation size fonksiyonunu yazdım. 64K'dan büyük bellek ataması için peşpeşe 64K ataması yapılırken, segment değeri 0FFFh artıyordu, bunun hata olduğunu farkedip 1000h olarak artıran düzeltmeyi yaptım. (FILE.ASM içinde open file prosedüründe ve ayrıca INT_21H.ASM içinde modify memory allocation size fonksiyonunun huge allocation kısmında.) 12/04/2011 itibarıyla TRDOS * SINGLIX FS dosya sisteminde delete komutu kapsamında file not found hatasının sebebini buldum, düzeltim. (Delete directory entry prosedürüne girişte DX:AX'e FDT adresi atanmadığı için hata veriyordu. Prosedür içinde atama yaptım.) 11/04/2011 itibarıyla TRDOS * Delete file prosedürlerinde truncate clusters aşamasında oluşan hatayı düzelttim. (Delete directory entry prosedürü First cluster değerini döndürmediği için truncate file prosedürü doğru çalışması). İlgili prosedürlerde düzeltme ve iyileştirme yaptım. Rename file prosedürü için delete directory entry ve update parent dir lmdt aşamaları tamam. 10/04/2011 itibarıyla TRDOS * INT 21h Set Disk Transfer Address (DTA) fonksiyonu tamam. * INT 21h Delete File fonksiyonu tamam. * INT 21h Rename file fonksiyonu için proc_delete_file prosedüründe değişiklik yapıp, 'entry delete', 'unlink clusters', 'update directory lmdt' aşamaları ayrıldı. 'entry delete' ve 'update directory lmdt' başka bir prosedür oldu (rename için). Fakat aşamada free clusters hesabında hata yapıyor, eski durumla karşılaştırarak çözüm bulmam lazım. 09/04/2011 itibarıyla TRDOS * INT 21h Move File Pointer (Seek) fonksiyonu tamam. 02/04/2011 itibarıyla TRDOS * DVR_FS.ASM içinde 'proc_get_first_free_section' prosedürü MAT içinde 'first free sector' alanına geçerli olmadığı anlamında 'FFFFFFFFh' konulduğunda bunu geçerli ilk boş sektör olarak işleme koyan hataya sahipti, bu nedenle fs mkdir prosedürü hatalı dönüş veriyordu. Ve harddiskte yeni directory oluşturulmuyordu. Bugün bu hatayı düzelttim. 27/03/2011 itibarıyla TRDOS * INT 21h, Fonksiyon AH=47h 'get current directory' tamam... * INT 21h, Fonksiyon AH=19h 'get current drive' tamam... 20/03/2011 itibarıyla TRDOS * DVR_FS.ASM içinde yaptığım değişiklikle (create_fs_file) file size belirtilmediği (SIFIR olduğu) zaman Kernel'in eklenecek ilk dosya kesimi (section) için fdt + data sektör sayısını diskin boş (free) sektör sayısına göre belirlemesini sağladım. (2-17 arası) * FILE.ASM içinde (write_file) dosya pointer'ı dosya boyundan büyük olduğu zaman girişte prosedüre EOF bildirilmese dahi EOF muamelesi yapıp dosya boyutunu değiştirmesini sağladım. Böylece dosya büyüklüğü SIFIR olarak (INT 21H ile) yeni oluşturulan dosyanın içine yazılsa dahi dahi ilk yazma işleminde dosya boyunun SIFIR kalması kusurunu düzeltmiş oldum. (INT 21h 'Create file' fonsiyonunda dosya büyüklüğü belirsiz ve SIFIR olup, 'write file' ile dosyaya yazılan byte'ların dosya büyüklüğü olması gerekiyor. TRDOS Kernel'içindeki çağrılarda kopyeleme işleminde dosya büyüklüğü prosedürlere girişte bilindiği için, EOF olup olmama durumu önceden ayarlanabiliyordu. Böylece dosya sonu gelmeden 'eof' girdisi olursa 'truncate file' işleme konuyordu.) * Write file prosedürüne DX:AX = 0 girişinin doğrudan 'truncate file' işlemi (mevcut file pointer'ına göre) yaptırmasını sağladım. * 'Create file' ve 'write file' düzeltmelerinden sonra, dosyaların oluşturulması, açılması, okunması, yazılması ve kapanması (INT 21h dosya) fonksiyonları tamamlanmış oldu. Kalan dosya fonksiyonları daha basit, jritik aşama başarıyla geçilmiş oldu. Sadece SINGLIX FS dosya sistemine uyumluluk (compatibility) modunda erişildiği için (DOS dosya formatına çevrildikten sonra ve sanal dos directory buffer'ına kopyelendikten sonra erişim yapıldığı için, hemen akabinde yapılan directory işlemlerinde reset/refresh gerekmek ve bazı durumlarda doyas silinince veya boyutu değişince ilk takip eden directory işlemleri hatalı çıkış vermekte bu durumu daha sonra düzelteceğim.) 19/03/2011 itibarıyla TRDOS * INT 21h 'create file' fonksiyonu Singlix FS dosya sistemini bozuyordu. INT 21h 'create file' fonksiyonu 'proc_create_file' prosedürünü ve onun altında (Singlix FS için) 'proc_create_fs_file' prosedürünü çağırıyor. Sebebini dosya kesiminin (section) sektör sayısını (INT 21h dolayısıyla) SIFIR olarak (dosya boyutu DX:AX sıfır olması dolayısıyla) işlemlere başlatınca, proc_update_dat prosedürü cx = 0'dan döngüye girdiğinden (cx=FFFFh'ye düşerek tekrarladığı için) allocation hataları olması ve mevcut DAT'ın bozulması ve root directory'nin tahrip olmasıydı... Bu durumu düzelttim... Dosya boyutu sıfır olarak girilirse 'proc_create_fs_file' prosedürü sektör sayısını FDT+1 = 2 olarak ayarlıyor. (Singlix FS için create file prosedürünün belli bir dosya boyutuyla çağırılması en uygun durumdur. Fakat INT 21h içinden belli bir dosya boyutu ile çağırma olanağı yok, çünkü o aşamada dosya boyutu bilinmiyor veya fonksiyona girdisi yapılamıyor.) 13/03/2011 itibarıyla TRDOS * INT 21h 'create file' fonksiyonu ve 'write_file' fonksiyonları tamam fakat düzeltmeler gerekecek. * INT 21h Fonksiyon AH= 0Ah, 'buffered keyboard input' fonksiyonu tamam. (örnek int21.asm dosyasında olan dos fonksiyonları) 12/03/2011 itibarıyla TRDOS * INT 21h 'create file' fonksiyonu için FILE.ASM içinde 'proc_create_file' ve 'proc_make_directory' prosedürüne attributes girişi (CL ile) uygulamasını yaptım. DRV_FS.ASM içinde etkisi yok (sadece normal file ve normal directory) olarak yeni dosya veya dizin açıyor. Yani Singlix fs içinde yeni dosya veya dizin açarken INT 21h üzeriden attributes (nitelik) belirtilmesi (TRDOS için) geçersiz. 05/03/2011 itibarıyla TRDOS * INT 21h 'close file' fonsiyonu tamamlandı. * INT 21h 'read file' fonsiyonu tamamlandı. Opne, read, close file fonksiyonları 'READFILE.COM' programı ile test edildi. Tamam... 26/02/2011 itibarıyla TRDOS * INT 21h 'open file' fonsiyonu tamamlandı. (INT_21H.ASM) Open file ve close file prosededürlerinde (FILE.ASM içinde) bugfix'leri yaptım. (özellikle deallocate_memory işleminde hatalı boşaltma yapan önceden kalma kusurlarını düzelttim) Kontrol ve düzeltme için OPENFILE.ASM dosyasının derlenmesinden oluşan OPENFILE.COM test programını kullandım. 19/02/2011 itibarıyla TRDOS * Find_next_file prosedürünün int 21h içinden kullanılması için örnek dirlist.com programının msdos'ta (windows dos prompt'da) doğru çalışırken trdos içinde ilk 16 dir entry'den (short name) sonra devam etmeme sebebini boşuna kernel prosedürlerinin içinde aramışım. Sebep, 16 satırdan sonra enter tuşu mu yoksa esc tuşumu bakıp ona göre sonraki sayfayı veren, kernel'deki print_directory ve dirlist.com içindeki aynı prosedürde int 21h 'find next file' çağrısına (0Dh < 1Bh) cf=1 (stc) olarak girilmesi ve dönüşte stc (cf=1) olduğu için ESC tuşuyla aynı muamele yapılması (jc short ...). Bunu bügün INT 21h içinde girişte flags register'inin push edilen halini stack içinde 0FFFEh ile ve (AND) işlemine sokup CLC yaparak çözdüm. Böylece INT 21h girişte clc'yi kendisi yapıyor çıkışta kendisi hata döndürürse stack içindeki flags register'ini 1 ile veya (OR) işlemine sokarak stc yapıyor... Fakat, TRDOS INT_21h kodu orijinal giriş FLAGS değerini invalid function call durumunda yapacağı dökümde göstermek üzere (INT_FLAGS yerinde) saklıyor. (TRDOS INT 21h interrupt'ına girişteki gerçek FLAGS durumu, 'invalid function call' durumunda görülebilir) * Böylece günlerdir takıldığım, TRDOS kernel içinde mevcut 'find first file' ve 'find next file' prosedürlerinin ilgili INT 21h fonksiyon çağrılarına uyarlanması başarıyla tamamlanmış oldu. 16/02/2011 itibarıyla TRDOS * INT_21H.ASM find_next_file fonksiyonunda find_directory_entry prosedürüne iletilen cx değerinin 02dan farklı olması durumunda bir sonraki dosyayı aramamdan dönme kusuru basit idi ama 10 gün içide fark edemedim. Bugün fark ettim ve sonraki dosyaları (dirlist.com ile deneme yaptığımda) listemeleye başladı fakat bir sekötürn veya 1 cluster'ın ötesine gitmiyor bu kusuru da yarın veya daha sonra düzelteceğim. (Yine basit bir kusuru/eksiği zor bulmuş oldum.) 05/02/2011 itibarıyla TRDOS * INT_21H.ASM dosyasında modifikasyon ve eklemeler. Interrupt 21h'de find_next_file fonksiyonu eklemesi ve iyileştirme. 03/02/2011 itibarıyla TRDOS * INT_21H.ASM dosyasında modifikasyon ve eklemeler. Interrupt 21h'de find_first_file fonksiyonu eklemesi ve iyileştirme. 27/01/2011 itibarıyla TRDOS * CMD_INTR.ASM içindeki komutlarda, drive, path ve file name için yolu hazırlayan bölümler tekrarlıyordu, INT 21H için yazılacak yeni fonksiyonlar için de (find_first_file, open file gibi) aynı işler gerektiğinden, DIR.ASM içinde proc_set_working_path prosedürünü yazdım. Sürücü değiştirme, dizin değiştirme v.s. işlemler bunun içinde gerçekleşecek. Daha sonra CMD_INTR.ASM içindeki aynısının tekrarlarını silerek ve değiştirek tüm kernel kodunu kısaltacağım, sadeleştireceğim. 25/01/2011 itibarıyla TRDOS * write file içinden geçilen truncate_file prosedüründe dosya boyutu kısaldığı halde bunu FAT'a işlememe (1 cluster'ı geçmeyen dosya boyutları için) kusuru vardı, düzelttim. Add new cluster ve truncate cluster chain prosedürleri doğru çalışıyor. Truncate file prosedüründeki kusur 1 cluster'ı geçmeyen dosya boyutlarında cluster zincirinin budanması işlemini iptal ettirmemdi. (İlk cluster'ı sildirmemek için; fakat bu mantık yanlıştı, çünkü, ilk cluster'ı zaten silmeyecek bir kodlama prosedürde vardı. Benim yaptığım truncate işlemini başlatmadan bitirmek olmuştu. Bu hata da zor bulduğum ama sebebi basit hatalardan oldu.) 22/01/2011 itibarıyla TRDOS * Add new cluster prosedürüyle ilgili read file ve write file prosedürlerinde ufak değişiklikler yaptım. prosedürden dönüşte hataya sebep olan (dönüşte kullanılan) DI register değerinin değişmesi kusurunu düzelttim. Ayrıca truncate file prosedüründe düzeltme yaptım fakat sonuç vermedi. 20/01/2011 itibarıyla TRDOS * Dünkü çözümde/düzeltmede işlevini değiştirmeyen ama kodu iyileştiren ufak değişiklikler yaptım. 14/01/2011 itibarıyla TRDOS * Komut argümanlarını PDP+80'den itibaren MSDOS uyumlu olarak uyarladım. (cmdarg.asm/cmdarg.com ile sınamasını yaptım.) 19/01/2011 itibarıyla TRDOS * 64 kilobyte'dan büyük dosyaların show ve copy komutunda hatalı görünme sebebini çözdüm. proc_load_file (FILE.ASM) ve proc_load_fs_file (DRV_FS.ASM) prosedürlerinde ES segment register'ı read işleminden sonra update (+1000h) olması gerektiği halde önce update oluyordu. (Yani sector count'a göre buffer segment:offset taşıması/ötelemesi yaparken, offset doğru yerde kalıyor fakat segment okumanın sonunda değil başında öteleniyordu, dolayısıyla buffer 64KB ileri kayıyordu ve hatalı show ve copy'e sebep oluyordu...) 09/01/2011 itibarıyla TRDOS * Read-File ve Write_File prosedürlerini ve bunların altındaki prosedürleri gözden geçirdim. Dolayısıyla COPY komutu altında add cluster/section, truncate file işlemlerinde hata olmaması gerekiyor. Özellikle 64 KB üstünde doya yüklemede hata olmaması gerekir hata kalmışsa load file prosedüründen kalmıştır. 26/12/2010 itibarıyla TRDOS * FAT 32 dosya sisteminde mkdir komutunda (proc_make_directory) get_first_free_cluster (FAT32) prosedüründe disk_read için sektör sayısı 1 (cx=1) olması gerekiyordu, girişte cx>1 olduğu zaman (CX=0FFFFh) prosedürde takılma oluyordu. (Bellekte dos boot sektör buffer'ın devamında kernel üzerine yazdığı için.) Bu hatayı düzelttim. * Çok önemli diğer bir hata update_cluster prosedürünün FAT 32 kısmında FAT buffer'dan cluster offseti üzerinden cluster değeri alınacak iken ES segment registe'rına FAT buffer segment adresi yanlış atandığı için, yanlış ES:BX clusster kayıtlaması nedeniyle FAT 32 dosya sistemini bozuyordu. Hatta denemede 'mkdir singlix' komutu kullanınca Windows XP C: kısmen bozuldu scandisk ile düzelttim ve 2. windows XP partition'dan girerek toparladım. Dolayısıyla bu önemli hatadan döndürdüm. FAT 32 işlemlerinde başkaca hatalar olabilir. FAT 32 formatlı USB/Flash bellekte aynı şekilde takılma vardı (mkdir'de) düzelmiş oldu, dosya kopyelemede problemlerin bir kısmı düzelmiş oldu. Yine de FAT 32 yazma işlemleri henüz güvenli değil... 25/12/2010 itibarıyla TRDOS * Singlix FS mkdir prosedüründe parent dir DDT (DX:AX ile) gerektiği halde girişte (Current Dir FCluster) DX:AX'e taşınmadığı için invalid format (0Bh) hatasına sebep oluyordu. Bu hatayı düzelterek FS mkdir'in doğru çalışmasını sağladım. * Mkdir komutunda singlix fs file system için resetlenmiş buffer'dan yeni sub dir sektörlerine (boş) yazma yapılırken, birden büyük sector count (cx) kullanınca ES:BX'de buffer (her bir fazla sectör sayısı için 512 byte) ilerliyor dolayısıyla reset bozuluyordu, yazmayı 1 sektörlük döngüler halinde yapınca bu hata düzeldi. 05/12/2010 itibarıyla TRDOS * COPY komutu ve 'write file' bugfix'lerine devam... * "Create FS File" bugfix'i, "Add new FS section" bugfix'i ve ilgili diğer prosedürleri bugfixleri ile mevcut FS dosyasına section eklerken oluşan hataları düzelttim. "Create FS file" ile 64KB'tan küçük dosyalar hatasız kopyelenirken, dosya boyutu kısalırken (truncate) hata olmuyor ama uzarken (add new fs section) hata oluyordu, bu hata "free space" ile kendini belli ediyordu veya error dönüşünden... * Bugün ilk kez düzeltilmiş "add new fs section" prosedürü ile doğru sonuç veren multi section'lu dosya elde ettim. 'menuprog.asm' dosyasını (4283 kB) FAT'tan FS'e (fd) kopyeletirken, 512 byte ile create yaptırdım, kalan kısımı 'add new fs section' ile kopyelettim. Dosya kopyesi 1+2+2+2+2 = 9 sector olarak, (4283/512 = 8.365) 5 sectionda oluştu. Free space 9*512+5*512 olarak, 392704 byte iken 385536 byte'a düştü...Bu şekilde ilk multi section uygulaması başarıyla gerçekleşmiş oldu... (Multi section durumuna göre dosya açma ve kopyeleme prosedürlerini çok önce yazdığım halde, multi section ilk kez bugün dosyaya -write file- içinden uygulandı ve gerçekleşti...) * Multi section kopyelemede (floppy diskte) 2 sektör yerine 3 sektöre göre section büyüklüğü ayarlarken, load_fs_file prosedüründe dosyanın son kalan sektörleri (1 ile) ile son section sector count'u (3 iken) uyumsuzsa, çıkarma sonucunda negatif sayı stc döndürüyordu. Bu durumu düzelttim .(Kalan sektör sayısı section sector count'undan az ise, az olan kadar okuma/yükleme yapılması seklinde düzeltme...) * Yeni eklenen section'da free space'e göre belirli sayıda sektör bulundurma yönteminde (write file işlemleri gereğince ne kadar ekleme yapılacağı bilinmeden bir section eklemek gerektiği için) section sonunda kullanılmayan boş sektör kalıyor ama ilerideki eklemelerde gereksiz section kullanımı önlenmiş oluyor. 'Create file' ile açılan dosyada tek section'da tüm sektörler olabileceği halde, sonradan 'write file' ile büyüyen dosyalarda section sayısı artıyor ama section size küçük kalıyor. Bu durumu önlemek için, Singlix FS için uygulama programlarının 'create file' prosedürünü nihai dosya boyutu ile birlikte kullanması gerekecek. (Dosya kopyeleme, diskte boş yer var ise, "create file" ile başlamalıdır veya "write file" da önce dosya sonu yazılmalıdır ki dosya boyutuna göre yeni bir section oluşsun. Overwrite+add yerine delete+create...) 20/11/2010 itibarıyla TRDOS * RENAME komutu tamamlandı. * COPY komutu düzeltmeleri devam ediyor. 19/11/2010 itibarıyla TRDOS * FindFile, SourceFile ve Destination file structure'ları 126 byte iken 128 byte oldu (DirBuff_EntryNumber bunlara offset 127'de kopyelendi). Böylece bulunan dosyanın directory entry numarası kayıtlandığından direkt bu dosyaya erişmek daha kolay olacak. (RENAME komutuyla ilgili prosedürlerde gerekli oldu.) Ayrıca, 'long name entry length' ile longname_yes eşitlendi; yani dosya longname'e sahip ise, bu byte 0'dan büyük ve longname'in toplam dir entry sayısına eşit, bu sayı 0 ise longname yok demek. 16/11/2010 itibarıyla TRDOS * COPY komutunda düzeltmeler devam ediyor. Özellikle add new section, add new cluster durumu için hem COPY içeriğinde hem de dönüşte directory list'in güncelenmesinde düzeltme gerekiyor. Truncate durumu için dönüşte directory list'in güncelenmesi hatasını düzeltmem gerekiyor. COPY komutunda buffer üzerinden (source file'ı full open yapmadan) kopyeleme kısmını yazmam gerekiyor. * RENAME komutunun ilk halini çalıştırdım. Bu komut dosya veya dizinin adını değiştiriyor. Kaynak/Source/Eski dosya adı path içerebiliyor, destination/hedef/yeni dosya adı path içermeden geçerli bir DOS dosya adı olması gerekiyor. Attributes kontrolü de oluyor. RENAME komutu detaylarına devam ediyorum. 14/11/2010 itibarıyla TRDOS * COPY komutuyla Singlix FS dosya sistemine kopyelenen dosyaya, DOS directory entry date&time formatından çevirerek last modification date&time atama prosedüründeki yanlış sonuç veren işlem hatalarını düzelttim. 07/11/2010 itibarıyla TRDOS * Create fs file ve write file (fs) prosedürleri tamam, dün ve bugün hata düzelterek çalışır hale getirdim. İlgili diğer prosedürlerde şimdiki aşamada kendini göstermemiş bazı hataları da düzelttim ve ufak değişiklikler de yaptım. * Copy source file to destination file prosedüründe şimdilik 'write full open file' çalışıyor, read/write (buffer üzerinden belleğe tamamı yüklenmemiş dosyanın okunup yazılması) henüz çalışabilir durumda değil (ama çalışmaya çok yakın, çünkü hata düzeltilmesi gerekecek yerleri hariç hazır). * Write file prosedüründe 'add new cluster/section' ve 'truncate' durumlarına göre hata düzeltmek gerekecek. * Çok zor geçen, tamamen orijinal olduğu için, başkaca bir hiç bir işletim sistemi yazılımından yararlanmadan (dos uyumluluğu için read/write file ile birlikte) tasarladığım copy file prosedürleri tamamlandığında (read file ve write file ile birlikte) SiNGLiX işletim sisteminin de copy, read, write file işlevlerinin temelini oluşturacak. Sadece register'lar 32 veya 64 bit olarak değişeceğinden, daha basit ve daha hızlı hale dönüşecek. SINGLIX file ve directory r/w prosedürlerinde TRDOS'a göre gereken değişiklikler de olacak ama Singlix kernelinin dosya sistemi fonksiyonları TRDOS'taki kernel (dosya sistemi) fonksiyonlarına (yöntem ve içerik olarak) dayanacak. 31/10/2010 itibarıyla TRDOS * Create file prosedürünün hata dönüşünde free space kontrolü (update/tahsis edilen clusterların sayısına göre) ve delete file prosedürü altında truncate cluster chain prosedüründe silinen cluster kadar free space ekleme düzeltmesi yaptım. * COPY komutu prosedürlerini düzeltme çalışmasına devam ediyorum. 30/10/2010 itibarıyla TRDOS * FAT 32 dosya sistemi olan C diskinde DIR komutunun takılması sebebini buldum. 1GB ve daha büyük dosyalarda dosya boyutu yazılırken (DIR.ASM içinde proc_print_directory prosedüründe) DI register'i döngü başında 9 iken, file size rakam sayısı 10 olduğundan 'dec di' 0'ın altına düşüp 65535'e sebep oluyordu bu da takip eden prosedürde eksik rakamların boşluklarını space (20h) character ile doldurma işleminin kodu silmesine sebep oluyordu. DI'ye döngü başında 10 değeri vererek hatayı aylar sonra düzeltmiş oldum. Takılma sebebini load root/sub directory veya Get Next Cluster prosedürlerinde tahmin ettiğim için çözüm uzun sürdü. İlk kez dün akşam sebebin PAGEFILE.SYS gibi 1 GB'dan büyük bir dosyanın file size'ını yazarken proc_print_directory prosedürü içinde kilitlenlenme olabileceğini düşündüm ve bugün çözdüm. * COPY komutuyla ilgili FAT prosedürlerinde düzeltmeye devam ediyorum. Create File prosedüründe düzeltme yaptım. 26/10/2010 itibarıyla TRDOS * FILE.ASM içinde open_file prosedüründe allocation size OFDT'yi kapsamadığı için copy prosedüründe tahsisi yapılmayan son 256 byte (allocation unit) drive change esnasında overwrite oluyordu. (Directory buffer tazelemesinden dolayı...) Bu hatayı zor buldum ama düzelttim. Böylece, open file (mode 5) işlemiyle açılan source dosyanın, destination dosyasına geçiş yapılırken sonundan kırpılmasını önlemiş oldum. Bu hatayı fark edemememin sebebi diğer komutlarda (show'da v.s.) overwrite olmaması idi. Dolayıyla sürekli 'copy', 'create file' 'write file' ve 'get cluster for file sector' prosedürlerinden şüphelenip onlara yoğunlaşmıştım. Bugün kırpmanın son 256 byte olduğunu daha dikkatlice düşünüp, sebebi buldum ve çözdüm. Bugünden sonraki ilk aşama COPY komutunun diğer bugfix'leri ve singlix fs dosya sistemine (destination olarak) uyarlanması. 24/10/2010 itibarıyla TRDOS * DRV_FAT.ASM içinde update_cluster prosedürüne BugFix yaptım. BX:CX şeklinde olması gereken yeni cluster CX:BX şeklinde bekleniyordu gönderen prosedür BX:CX olarak gönderdiği için birden çok cluster'dan oluşan dosya ve dizinler hatalı kayıtlanıyordu veya kayıtlanacaktı. FILE R/W prosedürlerinde düzeltme yaparken gereken diğer düzeltmelerden en önemlisi bu oldu. Ayrıca Create file prosedüründe düzeltme gerekti. 20/10/2010 itibarıyla TRDOS * FILE.ASM için Open_File prosedüründe open mode 0,1 ve 2 için takılmaya sebep olan hataları düzelttim. Ayrıca Read_File ve Write_File prodedürlerin ufak düzeltmeler yaptım. Copy komutunun kopyeleme/yazma kısmı basit haliyle (ilk sektörde) doğru gerçekleşmiş oldu. Write_File prosedürünün kontrol ve düzeltme aşamasına devam ediyorum... (Bugün tamamlayamadım...) Hafta sonu FAT için kesinlikle, FS için muhtemelen tamamlanır sanıyorum. 17/10/2010 (Pazar) itibarıyla TRDOS * DISK_IO.ASM içinde LBA read ve write prosedürlerinde (disk_write ve disk_read içinde) DX:AX çiftinden oluşan 32 bit LBA adres dönüşte bozuluyordu; bu nedenle tekrarlı/peşisıra okuma ve yazmalarda DX:AX bozuluyordu ve hata dönüşü oluyordu. Bu hataları düzelttim... (LBA BugFix) * COPY komutu FAT dosya sistemi için çalıştı... (Create_File, Read_File ve Write_File prosedürleri çalıştı !) Saptadığım hataları ve FS dosya sistemi için gerekli (create fs file) prosedürünü yazmaya gelecek hafta sonu devam edeceğim... (İnşallah...) 16/10/2010 itibarıyla TRDOS * RMDIR, MKDIR komutlarının düzeltmelerini/bugfixlerini yaptım (calculate FAT free space ve update parent dir lmdt) ayrıca DEL komutunda olan update parent dir lmdt kısmını ortak 'update parent dir lmdt' prodedürüne çevirdim. (mkdir ve rmdir komutlarının -FAT- dönüş hataları düzeldi) Bu komutların FAT free space hesabında free space büyüklüğünün geçersiz (FFFFFFFFh) olması durumundaki yeniden hesaplama kısmını düzenledim. Bu komutlarda fark ettiğim bir hata kalmadı. * COPY komutunda create file kısmından gelen hatayı düzelttim bu hata da calculate FAT free space kısmından geliyordu. 10/10/2010 itibarıyla TRDOS * COPY komutuyla ilgili olarak ve aynı zamanda READ FILE ve WRITE FILE prosedürleri bunlarla ilgili OPEN FILE ve CLOSE FILE prosedür değişiklikleri, CREATE FILE, ADD NEW CLUSTER, ADD NEW SECTION ve TRUNCATE file prosedürlerini 1-2 ayda tamamlamış oldum. Şimdi bunlarla ilgili kodlarda gerektikçe düzeltmeler yapacağım... 19/09/2010 itibarıyla TRDOS * DRV_FS.ASM içinde truncate_fs_file, truncate_fs_section ve delete_fs_section proesdürleri tamamlandı. Düzeltme gerekebilir. * 'Write File' prosedürlerinin truncate (budama/kırpma) kısmı tamamlanmış oldu. 12/09/2010 itibarıyla TRDOS * Read file ve write file prosedürleriyle ilgili işlemler üzerinde 04/09/2010'dan itibaren çalışıyorum. Bunlar create file'dan sonra 'copy' komutunun çalışabilmesi için. MS-DOS uyumluluğu için read file ve write file kullanma ve open file üzerinde copy (source file to destination file) komutuna çalışıyorum. Yoksa, copy komutu daha basit olurdu ama dosya okuma ve yazma işlemlerin açık dosyaya uyarlamaz isem bu kez dosya boyutunun değişmesi, dosyanın edit yapılması v.s. sebeplerle copy komutundan ayrıca bir çok prosedür yazmak gerekirdi. Copy file komutunda dosya açma modu 'full open' veya buffer'la partial open olabiliyor. Dosya okumada open mode önemli ama dosya yazmada sadece verilen buffer adresinden başlayarak verilen sayıda byte sektöre yuvarlanarak gereken sayıda sektör diske yazılıyor ve yazılan sektör olmasına rağmen dosya pointer'ı istenen byte kadar ilerliyor. Dosya boyu değişebiliyor. * Write file prosedürde file pointer diske yazılacak pozisyonu gösteriyor yani buffer'daki pozisyonu değil. Böylece bufferın write file prosedüründen önce read file ile ve gerekirse başkaca hazırlanmasını takiben write file çağrılıyor. Open mode R/W olursa, write file file pointer'ları değiştirdiği için bu tür dosyada read işlemi pointer'ları değiştirmemeli. (file r/w, aynı Open file handle üzerinden ve aynı buffer'dan hem read hem write demek. Bu kez read file pointer'ını değiştirmeye gerek yok çünkü zaten dosya full open olmak zorunda, sadece buffer offset'inin başarılı olan write işlemini takiben bir sonraki write'dan önce ilerletilmesi gerekir.) * Buffer ile read veya write olursa (yani dosyanın tamamı bellek'te değil ise), işlem için byte count'u daima buffer size kadar veya ondan küçük olur. Bu durumda read file'da file pointer buffer'daki ilk byte'a denk gelecek bir sonraki okumanın dosyadaki yeridir. Write fle içinde file pointer bir sonraki yazmanın disk üzerinde dosyaya göre yeridir. (Yani dosyanın kaçıncı byte'ından başlayarak yazılacağıdır.) * Write file ve read file ile ilgili prosedürleri hem FAT hemde FS için aynı zamanda yazıyorum. * Dosya için belirlenen boyut veya EOF (dosya sonu) işareti dosyanın truncate yapılmasını (kırpılmasını) gerektirir bu durumda gerekli prosedürleri yazdım. FAT için ilk haliyle tamamlandı FS için devam ediyor. 15/08/2010 itibarıyla TRDOS * create file multi cluster silme durumunda free space'de bir cluster hata ihtimali var. 'createfile_ccounter' ile ilgili sebep bulunup düzeltilecek. * 'proc_create_file' prosedürü multi cluster'a ayarlandı yani dosya boyutu ne ise ona göre cluster'lar 0 doldurularak hazırlanıyor. Dosya botutu 0 ise sadece first cluster hazırlanıyor. Neden ms-dos'taki gibi cluster'ı olmayan entry oluşmuyor: Singlix FS'de mutlaka bir section oluşturmak gerekiyor. Çünkü header/dt ile section bitişik. Section için ideal olan tüm dosyayı kapsayan tek section olması. Bunun için prosedürünün dosya boyutu girişli olması lazım; FAT'ta ise first cluster tutamak oluyor. TR-DOS dosya boyutu SIFIR görünse dahi, first cluster'ı olan dosyanın cluster zincirini sildiği için hata yok. İleride INT 21h MSDOS uyumlu fonksiyonlar için create_file prosedürünü farklı çalıştıracağım, yani INT 21h'nin başka bir create_file (compatibility) prosedürü olacak. * TR-DOS kernel (taslağı) hemen hemen tüm prosedürlerinde (change drive ve change directory hariç) current directory ile çalıştığından uyumluluk modunda sürekli current directory değişikliği gerekiyor. Zaten CMD_INTR.ASM içinde çok olması da bundan. Current drive ve current directory kayıtları ile çalışmak başlangıçta/girişte işi uzatıyor ama devamında hızlandırıyor ve yollar kısalıyor. Yani faydası eksikliğini örtüyor. 14/08/2010 itibarıyla TRDOS * MKDIR komutu ile ilgili olarak (FILE.ASM içindeki proc_create_file prosedürü üzerinde çalışırken, bu prosedürün proc_make_directory prosedüründen türetilmesi dolayısıyla fark ettiğim hatalarla ilgili olarak) DIR.ASM dosyası içinde özellikle proc_make_directory prosedürünün 'add new cluster' kısımlarında ve ayrıca diğer kısımlarında da önemli düzeltme ve değişiklikler yaptım. (Singlix FS için mkdir komutu prosedürlerinde değişiklik yok.) * COPY komutunda FILE.ASM içinde 'proc_create_file' prosedürünü tamamladım ve 'copy_source_file_to_destination' prosedüründe önemli ilerleme sağlamış oldum; şimdlik oluşturulan dosyanın boş olan ilk cluster numarasını verip dönüyor. 09/08/2010 itibarıyla TRDOS * DELETE komutu prosedürünü diğer prosedürlerden çağırılması için CMD_INTR.ASM içinden FILE.ASM içine taşıdım. Böylece daha sonra delete file prosedürünü aynı kodları tekrar yazmadan bir prosedür çağrısı ile kullanmak mümkün oldu. Sadece sadece silme evet/hatır sorusuna kadarki kısım CMD_INTR.ASM içinde kaldı. 08/08/2010 itibarıyla TRDOS * DRV_INIT.ASM ve MAINPROG.ASM içinde yaptığım değişiklikle 'media changed' saptansa dahi (bochs emulator sürekli A: ve B: change drive geçişlerinde media changed döndürüyordu) aynı volume serial no ile dönen floppy/disket sürücülerde current directory'i reset yapmayı önledim. Bunun faydası aynı disk olsa dahi A: ve B: de change drive olunca sürekli root directory ile başlamak ve dolayısıyla current directory'i kaybetmek durumundan kurtulmak oldu. COPY komutuyla ilgisi: Source file bulunduktan sonra, destination file taraması ile değişen buffer'lardan dolayı tekrar source file drive ve directory'isine dönmek gerekiyor (dosyayı açmak için); o esnada sürücünün current directory'si bu modifikasyondan önce reset oluyordu. Bu durum bugfix'lenmiş oldu. 07/08/2010 itibarıyla TRDOS * COPY komutunun dosya açma aşamasına kadarki mantıksal yapısı tamam. 01/08/2010 itibarıyla TRDOS * Copy komutunun ana hatlarını CMD_INTR.ASM içinde belirledim. source file ve destination file mantığının başlangıcını başarıyla kurdum. Daha sonra detaylandıracağım. Aynı sürücüde aynı first cluster veya aynı FDT'ye sahip olan dosyayı kopyelemeyecek. Zaten destination file attributes müsait değilse permission denied dönüyor. Destination file bulunmuş ise OVERWRITE sorusu ve işlemleri için DestinationFile_Found işareti koyuyor. Başlangıçta mantığı FindFile structure'ını source ve destination file structure olarak FILE.ASM dosyasında kurarak geliştirdim. Ve ilk haliyle bir kaç yıldır başarıyla düşünemediğim COPY (farklı drive ve farklı directory'ler için) yapılanmasına bu kez başarılı bir giriş yapmış oldum. * COPY kumutu memory'de boş yer yeterli ise, dosyaı açarak kopyeleyecek. Boş yer yeterli değilse cluster'ı yükleyerek kopyeleyecek veya o da yeterli değilse, sektör esaslı (dosyayı açmadan sector buffer üzerinden) kopyeleme yapacak. * Destination file var ise, onun attributes ve dir entry datası ile last modification date&time ve size update'i ile çalışacak. Dosya küçülmüşse cluster zincirinden truncate yapacak, büyümüşse zincire ekleme yapacak. 31/07/2010 itibarıyla TRDOS * Singlix FS dosya sisteminin mkdir komutu tamamladım, hataları düzelttim. Directory oluştuktan sonraki free sector, first free sector, parent directory update ve directory buffer (in)validation/reset (yani yeni sub directory'nin dir komutunda hemen görünmesi) işlemlerini tamamladım. * FS için directory buffer compatibility (DOS tipi ve 2048 sınırlı) modunda olduğu için ve sadece fs directory yüklenirken mevcut entry'leri içerdiği için (current/aktif dir değişmedikçe directory buffer'daki listeye yeni directory ve dosya eklenemediği için) 'DirBuff_ValidData=0' yaparak resetleniyor ve böylece ilk kontrolde geçersiz olduğundan yeniden yüklemeye/listelemeye zorlanıyor. * 2048 bariyeri nedeniyle yeni dir için kontroller compatibility buffer'dan değil orijinal directory section datalarından yapılıyor, aksi takdirde 2048 içinde olmayan dosyaların duplicate durumu olurdu. Ayrıca, compatibility buffer'daki entry'ler boş ve silinmiş içermeden yüklendiği için boş ve silinmiş entry'leri bulmak için original fs directory section'larının data'sının taranması gekekiyor. (Dosya ve directory silerken bu şart yok.). 2048'den çok entry içeren dizinlerde, 'mkdir' komutunun çalışmasını engelledim. (FS'i bozmamak için ve buffer'ları 64K'da, 128*2048'de tutmak için.) * İşletim sistemini okuma hızlı, yazma yavaş ve garantili şeklinde geliştirmek gerektiği için, yeni dosya ve dizinlerin yavaş kayıtlanmasından çok, hızlı okunmasına önem veriyorum. 2048 sınırı v.s. bunun için yani DOS buffer'larını (1 MB belleğin boş kısımlarını) savurganca ve yavaşlatıcı kullanmamak için. Fakat, 2048 entry sınırı sadece TRDOS için var; SINGLIX işletim sisteminde kernel fonksiyonları/prosedürleri 80386 işlemcinin register'larına göre 32 bit olacağından, buffer'lar 64K ile sınırlı olmayacak ve dolayısıyla 2048 gibi (düşük) sınırlar olmayacak. 29/07/2010 itibarıyla TRDOS * Singlix FS dosya sisteminin mkdir komutunun altındaki "proc_make_fs_directory" prosedüründe root dir için 'R' kodunu dikkate almayan 'DD' kontrolü hatasını düzelttim. Bu hata root olan parent directoy için invalid data (0Dh) hata kodu döndürüyordu. 28/07/2010 itibarıyla TRDOS * SINGLIX FS dosya sistemi için DRV_FS.ASM içinde mkdir komutu prosedürü (proc_make_fs_directory tamamlandı. Parent directory içinde ilk boş veya silinmiş entry'yi arıyor bulamazsa ve entry sayısı 2048'den az ise yeni bir section ekliyor (get_first_free_section prosedürü ile) sonra parent dir'in son section'u üzerinden devam ediyor, boşa yeri kayıtlıyor sonra tekrar diskte ilk uygun seboş section yerini arıyor bulunca hem parent dir update'ini hem de new sub dir sectionunu diske yazıyor. Section size için diskin free sector count'una göre kabuller yapıyor. 32 MB'ın altında sadece 1 sector +1 section header, kullanıyor, yeni directory'nin ilk section'u için en çok 16+1 sektör ayırırken, eklenen section'lar için en çok 8+1 sektör ayırıyor. * FS mkdir prosedürün çalışmasını kontrol ettkten sonra hatalarını düzelteceğim. Sonra COPY komutu çalışmalrına başlayacağım. FS mkdir prosedürü ve ilgili alt prosedürleri dosya kopyelemeye uygun yazdım yani gereksiz çift dikiş/kod kullanmamak için disk allocation ve section ekleme mkdir ile aynı alt prosedürleri kullanacak. 05/07/2010 itibarıyla TRDOS * 3/4/5 Temmuz 2010 günlerinde DRV_FS.ASM içinde find_fs_dir_entry_with_number prosedürünü yeniden yazdım, entry offset'i sildim. Dosya numarasıyla arama ilk directory data sektörden başlıyor ve varsa (en çok) 65536 sektör kontrol edilene kadar devam ediyor. (0'ı görürse arama duruyor.) Bu şekilde düzeltme ile aramayı en baştan yaptırmam sonlardaki dosyanın bulunma süresini uzatıyor gibi görünse de (aslında dosyanın kaçıncı offsetten itibaren olabileceği bilinse bile) offset ve sektör kontrolü için dahi DDT okuma ve kıyaslama gerektiğinden dolaylı işlemler olmayınca prosedürden çabuk dönme olur. 27/06/2010 itibarıyla TRDOS * RMDIR için DRV_FS.ASM içinde eksik işlemleri tamamladım. DELETE_FS_DIRECTORY prosedürü boş directory'i siliyor son section'ı boş olup kendisi boş olmayanı ise tırpanlıyor ama directory boş değil hatası ile dönüyor. (Son boş section'u silerek diskte boş yer açıyor ve directory'i kompakt hale getiriyor. Bu arada Next'i boş olan DDT'ye next = 0 işareti yani son DDT işareti koyuyor. Prosedür CMD_INT.ASM'ye cf=1 ve ax = 0 ile dönünce bunun anlamı 'directory not empty' oluyor... cf= 0 ile dönünce 'deleted' anlamına geliyor... * 'proc_find_fs_dir_entry_with_number' prosedürü hata veriyor değişecek... şu şekilde olacak: entrynin tarama başlangıç numarası girildikten sonra bunun kaçıncı sektörün kaçıncı offseti olduğu hesaplanacak bir section açıldığı zaman o sectionun son sektörü kaçıncı sektör (bir sektör sayısı toplamı ile sector count toplanınca) bakılacak... eğer aranan sektör sectionun içinde ise sectionun kaçıncı sektörü olduğuna bakılacak ve section header adresi ile toplanacak ve yükelenecek direkt o sektör yüksenip offsete bakılacak... dosya/dir numarası eşit değilse bulunamadı dönecek... Yani: C sayısı offset C/128'de A bölüm tam sayısı sektör B kalan ise offset D sayısı sektör toplamı (başlangıçta sıfır) E sayısı sectionun sector countu ilk sectiona bakılacak D+E >= A ise aranan sektör section içinde değilse, next section yükelenecek D+E yeni D olup D+E(yeni) >= A durumuna bakılacak... bu art olacana kadar next section yüklelenecek... şart gerçekleşmeden end of sections olursa bulunmadı döner D+E>=A ise (E >= A-D) B=217 E=7 D=214 ise A-D=3, 3. sektörde işlemdeki sectionun 3. sektörünün B offseti karşılaştırılacaktır. A-D section içinde sektörün kaçıncı olduğudur (0= 1.) 20/06/2010 itibarıyla TRDOS * RMDIR için DELETE FS FILE prosedüründen türeterek DELETE FS DIRECTORY prosedürünü yazdım çalışıyor. Fakat boş DIRECTRORY'i silmesi için gerekli modifikasyonları henüz yapmadım. Sadece BOŞ directory'leri silmesi için ve ayrıca içinde dosya olmayan directory'leri silmesi için gerekli modifikasyonu yapmam lazım. * SHOW komutu FS Sub Directory'de 00h error code ile dönüyor, aslında hata yok gibi (Error code = 0) ama niçin hata ile (stc) ile dönüyor? bulup düzeltmem lazım. * RMDIR'de FS directory boş ise sil, son section boş ise directory'i son section'u silerek truncate yap (tırpanla) şeklinde matığı olan işlemlere devam ediyorum, bugün tamamlayamadım. Bu FAT mantığı ile aynı, yani diskte gereksiz bir boş section bırakmamak böylece mkdir ile rmdir'leri dengeye getirmek... Boş yeri optimizasyonla artırmak. 15/06/2010 itibarıyla TRDOS * RMDIR VE DEL komutu FAT32 için FSINFO sektöründe FirstFreeCluster değerini değiştirmiyor fakat bu değeri FFFFFFFFh yapıp geçersiz hale getiriyor. (Silme yapılmışsa calculate_fat_free_space (cluster ekleme ve çıkartma şeklinde çalışır) prosedürü geçersiz-hesapla anlamına gelen FFFFFFFFh işaretini koyuyor). MKDIR ve CREATE FILE gibi komutların veya prosedürlerin bu işareti görünce (FAT32 için) first free cluster'ı yeniden hesaplatıp kayıtlaması gerekir. Bu durumu/özelliği unutmamam lazım... 13/06/2010 itibarıyla TRDOS * DIR.ASM içinde proc_reload_current_directory prosedürü içinde loc_reload_fat_sub_directory kısmında sonsuz döngüye sokan bir hatalı cmp işlemi vardı, düzelttim ve FAT sub directory'nin yeniden yüklenmesi esnasında TR-DOS kernel'in takılmasına sebep olan hata ortadan kalktı. * RMDIR komutu SINGIX FS hariç tamamlandı. Bugfix işlemleri ve ait olduğu parent dir'deki değişiklik zamanı kayıtları doğru çalışıyor. Root ve Sub Dir'den rmdir yapınca hata vermiyor. Birden çok cluster'ı olan directory'nin boş olan son cluster'ı siliniyor ve 'directory not empty' mesajı veriyor fakat FAT dosya siteminde boş olan last dir cluster'ı silmiş oluyor. 12/06/2010 itibarıyla TRDOS * TRDOS kernel taslağı, 12_6_2010 itibarıyla FAT dosya sistemi alt dizinlerinde takılıyor (print directory çalıştıktan sonra tek dosyaya işlem yaparken), bunun sbeebini araştırken 25_1_2010 tarihli DIR.ASM ile problemsiz çalıştığını ama 26_5_2010 tarihinden itibaren takıldığı fark ettim. Dolayısıyla takılma sebebi DIR.ASM içinde bir prosedür... (Dosya veya dizin okuma ile ilgili...) 'DIR' komutu kullanmadan işlem yapınca takılmıyor... Bunu çözmem gerekiyor... Bugün için en son durum bu... * DEL komutunda, FAT dosya sisteminde parent directory'nin last modification date ve time bilgileri silme zamanına göre değişmiyordu bununla ilgili işlemleri ekledim. * RMDIR komutunun directory içi boş ise directory'yi silmesi, boş değilse ve en son cluster boş ise, en son cluster'ı silmesi fakat belli etmemesi işlemi tamam. (Sondan önceki bir cluster boş değilse komut 'directory not empty' ile dönüyor ama aslında boş olan son cluster'ı siliyor. Son cluster'ı boş ise silme amacı dizini boşken birden çok cluster'da tutmamak yani diski -dosya sistemini- daha verimli kullanmak.) * RMDIR komutu silinen cluster sayısı kadar boş yer açıyor, hem FAT'ta hem de free cluster count'ta gerekenleri yapıyor. Bunun için get_last_cluster prosedürünü kullanıyor (6_6_2010). Son cluster boş ise siliniyor ve first cluster2dan itibaren kontrol tekrarlanıyor, ne zaman first cluster ile last cluster aynı ise ve boş ise silinme kesinleşiyor. * RMDIR komutunda DEL komutu ile aynı şekilde lazım olan parent directory last modification date kayıtı gibi ortak kullanım eklentileri tamam. * RMDIR komutu Singlix FS dosya sistemi hariç tamamlandı fakat düzetme gerekebilir. 05/06/2010 itibarıyla TRDOS * RMDIR komutunu üzerinde çalışmaya başladım. DEL komutundan bozarak CMD_INTR.ASM içindeki ilk düzenlemesini yaptım. 'File not found' hatası yerine 'Directory not found' mesajına ayarladım. * RMDIR komutu çalışma deva ediyor. Yapılalacak işlemlerin sırası: - Directory var ise, bulunduysa... 1- Attributes müsait ise işleme devam et, yoksa 'permission denied'. Bu aşamayı geçtim... 2- Directory cluster (FS'de number) ve parent dir cluster'ı kayıtla. Bu aşamayı geçtim ama düzeltme gerekebilir... 3- Directory'nin son cluster'ını bul/yükle... İlk ile aynı ise boş mu diye bak; boş ise sil, değilse silme... ('.' ve '..' hariç dir içinde dosya/dir -short name- olmamalı ve root dir olmamalı.) Boş cluster ilk değilse ile aynı değilse otomatik kısaltma yap... (Kullanıcıya bilgi vermeden boş son cluster'ı veya section'u sil. Çünkü, fuzuli yer kaplıyor. Silinmiş dosyaların girişleri varsa!? ne olacak sonra düşüneceğim... Undelete gerekli mi!?) 4- Silinen directory cluster'larını FAT'ta boşalt.. Ve free cluster count'u değiştir. FS de denk işlemleri yap... 5- İlk ve son cluster aynı ise geöçerli giriş içermeyen directory'i parent dir entry'leri içinden sil... Parent dir entry'i silince parent dir'in son değişiklik tarihini kayıtla ... * ATTRIB komutu FS dosya sistemindeki directory'lere uygulanamıyordu, DRV_FS.ASM içindeki 'change fs file attributes' prosedüründe küçük bir hata düzeltme (bugfix) işlemiyle attrib komutunu singlix fs'deki directory'lere uygulanabilir hale getirdim. 26/05/2010 itibarıyla TRDOS * DRV-FS.ASM içinde FS dosyasının Attributes'lerini değiştiren prosedürdeki hatayı düzelttim. Artık doğru kayıt yapıyor. Hatanın sebebi 'or' instruction'ı ile FS'den alınan CH değeri 0FFh iken, yeni set edilen attrib değeri CL'de ne olursa olsun sonuç FFh çıkıyordu, bu da Dos attributes olarak 'NORMAL' yani BOŞ görüntü veriyordu. OR işlemini AND işlemi olarak düzelttim. * ATTRIB komutu tamamlanmış oldu. 23/05/2010 itibarıyla TRDOS * ATTRIB komutunu 17/12/2000 tarihli P2000.ASM dosyasından kopyeledim. Gerekli değişiklileri yaptım ve CMD_INTR.ASM içinde kayıtladım. Komutu Singlix FS dosya sistemine de uyarladım. Ancak Singlix FS sisteminde henüz tam doğru olarak attribute'leri değiştirmiyor. Yorgunluk ve uzun sürmesi nedeyle bugün sebebi bulamadım. Sonra düzelteceğim. * DEL komutunun iptal ve 'permission denied' dönüşlerinde current directory'ye geri dönüş kusurunu düzelttim. (Komut path içeriyorsa iptal geri dönüşü ile path'e göre değiştirilen current directory restore olmuyordu.) 22/05/2010 itibarıyla TRDOS * DELETE komutuyla ilgili 'Attributes' kontrolünü (FAT ve FS için) ('Permission denied !' kısmı) tekrar aktifleştirdim. DRV_FS.ASM içinde 'delete_fs_file' prosedüründe bir kaç önemsiz (iyileştirici, kısaltıcı) değişiklik yaptım. Böylece DELETE komutu tamamlanmış oldu. * DELETE komutu dönüşünde silme işlemi iptal olursa veya file attributes silmeye uygun değilse current directory'ye geri dönüşü garanti etmek için ('restore current directory' işlemleri CMD_INTR.ASM içinde değişiklik gerekiyor. 19/05/2010 itibarıyla TRDOS * DELETE FS FILE prosedürleri bugün itibayle tamamlandı. * DRV_FS.ASM içinde... Dünkü update_dat ekleme ve düzeltmelerinden sonra bugün free sectors son durumunu MAT'a işleme ve parent directory'nin son modifikasyon tarihini değiştirme prosedürlerini ekledim. * Bundan sonra bu prosedürlerde gerektiğinde düzelltme yapabilirim. Veya yeri geldikçe optimize edebilirim. Şimdilik işlevsel ve hazır... * Delete FS File işlevselliğinin yanısıra FS'te dosya ve dizin silme, ekleme işlemleri için bazı prosedürler şimdiden hazır oldu. 17/05/2010 itibarıyla TRDOS * DISK_IO.ASM içinde chs r/w prosedürünün next LBA adresi ile dönmesini sağladım. Yani bir sonraki disk erişim adresi ile dönüyor. DX:AX -> AX+CX, DX+Carry. Aksi durumda LBA rw next adresle dönerken chs rw dönmezse karışıklık (yanılma) olabilirdi. * DRV_FS.ASM içinde 'proc_delete_fs_file' prosedüründe iki yerde düzeltme yaptım. FDT silme işleminde 'E' işareti devre dışıydı, onu etkinleştirdim ve next FDT için DX:AX (17/05/2010 işaretli) çiftinin diskin mutlak (ofset olmayan) LBA adresini içermesini sağlayan değişiklik yaptım. ('push ax, push dx' yeri değişti.) 16/05/2010 (Pazar günü akşamı) itibarıyla TRDOS * Singlix FS dosya sisteminden dosya silme işlemlerinde 'proc_update_dat' ve onun altında 'proc_load_dat_sector' ve 'proc_write_dat_sector' prosedürlerini işledim. Bu prosedürler için, daha önce yazdığım, Singlix FS dosya sistemine startup file (Kernel) yükleyen 'BOOTFILE.COM' msdos programı, 'BOOTFILE.ASM' içindeki ilgili prosedürleri az değiştirerek (türeterek) kullandım. * DISK_IO.ASM içinde write fault (1Dh) hata kodunu kullandım. Ayrıca 'proc_disk_read' için 15h hata kodunu 1Eh (Read Fault) olarak olarak değiştirdim. CMD_INTR.ASM içinde 'write_error' mesajına göre ufak değişiklik yaptım. (15h -> 'Drive not ready' asıl olmak üzere ayrıca 'read error', fakat 1Eh 'Drive not ready or read error' oldu. 15h'yi diski okurken oluşan hata yerine diske erişim hatasına dönüştürdüm. (Henüz fazla uygulaması yok.) Permission denied, drive not ready ve write fault hataları da ayrıca işlenecek... (15h ile veya başka tek hata kodu ile dönmeyecek.) * 'Delete FS file' işinde bazı düzeltmeler ve MAT'ın işlenmesi kaldı... 09/05/2010 (Pazar günü akşamı) itibarıyla TRDOS * 0E5h işaretlemesi, 'FDE' işaretlemesinin arkasına alındı. Yani önce FDT silindi (FDE yapıldı), sonra compatitibility buffer'da directory entry offset 0'daki dosya adı ilk karakteri 0E5h yapıldı. Böylece FDT silerken hata dönüşü olursa, compatibility buffer'da dosyanın silinmiş görünmesi önlendi. Çünkü dosya silinemediği halde silinmiş görünmesi uygun olmaz. (Singlix FS'te original directory entry yani FS dosya numarası geçerli olsa dahi, FDT başlığı 'FDE' ise, dosya sistemi işlemlerinde dosya silinmiş gibi pas geçilir.) Silme işleminin eksiksiz olması için kalan aşamalar, Directory Entry'nin silinmesi, DAT'taki tahsis hücrelerinin serbest bırakılması ve MAT'taki free sektör alanlarına son durumun kayıtlanmasıdır. 09/05/2010 (Pazar günü öğleden sonrası) itibarıyla TRDOS * DRV_FS.ASM üzerinde 2 haftadır devam eden, 'delete file' prosedürü çalışmalarımda, aksaklıklar olmuştu. Dizinlerdeki ilk dosyalar hariç dosya sıra numarası (offset) yöntemiyle direkt istenen dosyanın beklenen/umulan sırasından başlayan arama/silme işlemi için offset yöntemi hata veriyor, silme aşamasında dosya directory entrylerine doğru olarak erişilemiyordu. Offset kullanılmazsa (sıfır ofset) ile tüm dosyalar bulunuyor ve silinmeye hazır oluyordu (delete_fs_file). Offset yönteminden vazgeçmedim (Çünkü dosyayı en baştan aratmak sonlardaki dosyalar için saçma dir-entry arama ve zaman kaybı olurdu.) Directory Compatibility buffer offsetini, original fs directory'de sektör ve entry (sektöre göre) offsete çeviren prosedürde bugünkü (9-5-2010) düzeltme ile problemi çözmüş oldum. * Düzeltme: Bazı şüpheli işlemlerdeki denemeler sonucunda, BX register'ı kullanılan ES:[BX]'li komutlar ve shift komutlarında değişiklikler yaptım. Ancak gerçek hata sebebini bugün farkettim; ('xor bh, bh' olan bir komutun 'xor bl, bl' olması gerekiyordu. BL'yi sıfırlamadığı zaman directory desciption table (DDT) sector buffer'a okunurken aslında ES:20h'ye okunuyordu; fakat kontrol ES:0h'den offset alınarak yapılınca daha önce FDT kayıtlanmış olan ES:8h'den sürekli dosyanın kendi FDT adresi alınıyordu. DDT adresi yerine FDT adresi gelince bunu ancak araya adresleri (numaraları) yazdıran geçici prosedürler sokarak farkedebildim. Ve yanlışlığın directory number'ın BX'teki (disk read buffer -> ES:BX) kayma nedeniyle 20h yerine 28h'de olmasından fakat 8h'den (bir önceki read sonucu FDT number) döndürülmesinden kaynakladığını anladım. (Çünkü içine bakılacak directory data sektörü doğru bulunamıyordu.) Aslında hatayı tam farketmem geçici olarak 64h'deki dosya adını okutmam ve hangisi buffer'a yükleniyor (dosya mı, dizin mi?) bakma kararımdan sonra gerçekleşti. Çünkü FDT/DDT 64h'deki dosya adı (gerçekte 44h'den bakıldığı için) boş döndü ve buradan Buffer'da kayma olabileceği (BX'in SIFIR'dan saptığı) şüphesi kesinleşti. Ve dikkatle bakınca aslında kolay bulunacak bir BX resetleme hatasını zor da olsa bulup düzeltmiş oldum. (Bir kaç dakikada bulunacak hatayı 2 haftada -bir kaç saatte- buldum.) * 'Delete FS file' prosedürü geçici olarak hiç bir şeyi silmiyor. Bundan sonraki aşamada gerçek silme işlemi ve free sector sayısının değiştirilmesini yapacağım. * FS dosyası silme işlemi sıralaması: 1- Önce FDT silinecek (FDE) olacak, işlem hata ile dönmezse... 2- Compatibility Buffer'daki entry 'E5h' işaretlemesi ile silinecek... 3- FS Directory entry silinecek (FFFFFFFFh olacak)... 4- DDT üzerinde son modifikasyon tarihi yenilecek... 5- Dosya ilk FDT adresinden itibaren DAT'tan silinecek DAT'tan başarıyla silinen her section için o sectiona ait sector count geçici bir free count değişkenine eklenerek sayılacak, dosyanın tüm section ve sektörleri DAT'tan silindkten sonra... Sector count kadar free sector count'a (Logical DOS DT'da) ekleme yapılacak. Free sector count'un son değeri MAT'a kayıtlanacak ve eğer ilk silinen FDT, görünen ilk free sektörden önce ise MAT'daki first free sector alanına yenisi kayıtlanacak... NOT: Silinen dosyaya (data sektörlerine) yazma olmadığı için, FDT, FDE olurken tarihler değişmeyecek. FS'te dosya sisteminde son değişiklik kayıtı yok ama, pas geçmemek için MAT'da boş bir-iki alana son kayıt tarihi ve son kayıt tipi (free sektör değiştirme gibi...) kayıtlanabilir. Bu dosya sistemindeki son modifikasyon takibi için faydalı olabilir. (Modifikasyonu yapan işletim sistemi veya program numarası da kayıtlanabilir.) 25/04/2010 itibarıyla TRDOS * Uzun zamandır takıldığım Singlix FS formatlı sürücüde dizine geri dönüş veya tekrarlarda programın Bochs emulatörde kill (programı disk işlem hatası nedeniyle sonlandırma) oluşturması veya 'drv not ready or read error' verdirmesini, directory buffer size belirleme hatası olduğunu (tam emin olamadan) farkettim. Yani, directory buffer (compatibility buffer) ile original fs dir buffer (section buffer) kesişiyor, çünkü sınırları görünen boyut ile kullanılan boyut aynı değil. (Detayına inmedim.) Bu problemi proc_load_fs_sub_directory prosedürü içinde directory buffer'ın sınır ve boyutunu belirleyen kod kısmını (25/04/2010 işaretli) düzelterek çözdüm. (Sektör sayısı kusurunu v.s. düzelttim.) Dosya: DRV_FS.ASM 24/04/2010 itibarıyla TRDOS * DRV_FS.ASM içinde bazı düzeltmeleri yaptım. * proc_reload_current_directory içinde bazı düzeltmeler yaptım. * FS dosya sistemi için CD komutunda bazen nereden takılıyor henüz bulamadım. Şüpheli: porc_load_fs_sub_directory ve alt prosedürleri. 23/04/2010 itibarıyla TRDOS * 'DEL' komutu (attribute'den) permission denied olarak dönünce ES register'ı DS'ye resetlenmediği için komut yorumlayıcı kontrol dışı kalıyordu, 'push ds, pop es' ekleyerek düzelttim. * DRV_FS.ASM içinde FS directory section buffer yükleyen load_fs_sub_directory kodunu ayrı bir section buffer yükleyen prosedüre dönüştürdüm. Bunun sebebi, delete işlemi için orijinal directory buffer'ın (section olarak) yüklenmesi... Önce bulunan compatibility buffer entry numarasından entry offset olarak find_fs_file_number (directory entry dizisi içinde) ile ilgili section yüklenecek ve oradan numara bulunacak (DX:AX) bulununan numara 0FFFF:FFFFh ile değiştirilecek ve ilgili sektöre kayıt yapılacak. Sonra directory'nin ilk DDT'si yüklenecek (sector_buffer'a) ve oraya modification date, time işlenecek ve kayıtlanacak. Sonra, disk allocation table'da file data kullanılıyor işaretleri silinecek (unklink) tahsis edilen sektörler serbest bırakılmış olacak. Sonra MAT'a yeni free size işlenecek. (En başta FDE işaretli FDT kayıtlanacak...) 21/04/2010 itibarıyla TRDOS * DISK_IO.ASM içinde CX (sektör sayısı) değerine göre ES:BX buffer değerlerini değiştirme şeklinde değişiklik yaptım. Bu arada ES:BX giriş değeri dönüşte beklendiği için, ES ve BX için push/pop yaptım. ES:BX değişmezken, DX:AX next sektör olarak dünüyor. Read error AL=15h olarak ve write error AL=1Dh olarak dönüyor. * Diğer ASM dosyaları içinde zaten AL=15h olarak dönen disk okuma hataları için tekrar AL=15h ataması yaptırmamak için bir kaç yerde düzeltme yaptım. 21/04/2010 olarak görünen dosyalarsa ufak değişiklikler oldu. 17/04/2010 itibarıyla TRDOS * DEL komutu sub dir için Delete_Long_Name bugfix'leri tamam. DEL komutu FS hariç tamamlandı... (DIR.ASM değişiklikleri...) 12/04/2010 itibarıyla TRDOS * DEL komutu bugfix'leri tamam. DEL komutu FS hariç tamamlandı... (save_directory_buffer, unlink_cluster ve delete_long_name değişti/tamam) CMD_INTR.ASM, DIR.ASM, DRV_FAT.ASM değişiklikleri... 06/04/2010 itibarıyla TRDOS * DEL komutunda bugfixler devam ediyor. Root directory'deki dosyayı siliyor gibi yapıyor (bufferde siliyor) fakat diske kayıtlarken değişiklik kayboluyordu. Sebebinin "Save Directory Buffer" prosedüründe root directory'i dikkate almamak (DX:AX=0) olduğunu farkedip düzelttim (FAT12 ve FAT16 için bugfix). Daha sonra FAT formatlı disketten FS formatlı diskete geçerken Boch emulatörde disk i/o hatasından dolayı takılma oluyordu (kill process) bu hata muhtemelen DX:AX=0 iken sub ax, 2 ve sbb dx, 0 komutlaır sonunda cluster numarasının anormal çıkmasıyla ilgili olabilir. (Root directory bugfix konusu.) save_directory_buffer hastı düzelince son durumma baktıktan sonra, FAT'ta silme işlemi FAT bufferın diske yazılması ve free clusters konusunda devredışı bıratığım işlemleri açacak ve sonuca bakacağım. FS formatlı diske geçişte hata verdiren durum devam ediyorsa çaresine bakacağım. 03/04/2010 itibarıyla TRDOS * DEL komutu (FS hariç) işlemleri tamam fakat hatalı çalışıyor. ve disk eşimini bozuyor. Longname'i olan dosyaları silerken de hata veriyor... 28/03/2010 itibarıyla TRDOS * DEL komutu için geçici kod çalıştırması tamam. proc_delete_longname prosedürünün disk write işlem sayısını azaltmaya yönelik modifikasyonu tamam. (sadece DirBuff_validdata=2 iken yazma işlemi gerekiyor, değişiklik yapıldı işaretine bakıyor, buffer'deki cluster değişirken veya ana işlem sona ererken yazmayı gerçekleştiriyor, aksi takdirde her bir entry değişince sektör yazacaktı, bu hız kesecekti). Save_directory_buffer prosedürü locate_current_dir_entry prosedürü tamam. Short file name önce silinecek, sonra long file name entry'leri silinecek sonra short file name ile ilgili file cluster'ları Fat'tan unlink yapılacak (silinecek) silinen cluster sayısı sayılacak ve free cluster sayısına eklenecek. FAT 32 ise free cluster count yerine (geçerlilik kontrolüne göre) yazılacak. FAT buffer'da fat hücresi değiştirilirken sürekli yaz yapmamamak için sektör değişikliği ve validation sayısı (2 ise) gözetilecek. (Yoksa büyük dosyalarda FAT'a yazmak uzan sürer...) MSDOS'ta smartdrv.exe ile yapılan disk'e hızlı yazma okuma işlemini TRDOS'ta buffer'a dikkatlice en az disk erişimi ile yazma yaptırrarak sağlamaya çalışıyorum; "MSDOS smartdrv olmadan çok yavaş disk işlemleri yapıyordu bu da her bir değişikliği tek tek kayıtlamasından kaynaklanıyor" saptamasıyla aynı duruma düşmemek için BUFFER işlemlerini smart yapmaya çalışıyorum. Çünkü TRDOS'ta smartdrv.exe benzeri bir uzantı düşünmüyorum. Herşey kernel içinde çözülmeli, int 13h'ye müdahale düşünmüyorum. * DEL komutunun FS dosya sistemi içindeki davranışını FAT işlemlerini tamamladıktan sonra yazacağım. * COPY komutuna geçerken, tasarlamamı kısmen yaptım ama programa işlemedim. COPY komutunda source file name bulunursa source file size , read mode olarak open yapılacak. Insufficient memory hatası verirse, MSDOS'ta olmayan open_file_cluster metoduyla açılacak yani dosya kısmen cluster'ı ile açılacak. yine insufficient memory olursa load_file_sector ile açılacak... Open file structure'da gerekli modifikasyon yapılacak. Sonra read_file'da file pointer ve okuncak byte sayısına göre sektör yüklenecek. sonra write_file ile buffe'rdan ikinci dosyaya (target_file) yazılacak. Yazma işlemi için target_drv'da boş yer yeterlimi? (sektör sayısı cinsinden) bakılacak... FS ise section hesaplarıyla boş yer kontrolü yapılacak. target_file_name formatı uygunsa, soruc_file ope yapılmaya çalışılacak. (hedef dosya adı uygunsuzsa veya disk uygun değilse boşu boşuna open file open cluster veya open file sector yapılmamalı.) 28/02/2010 itibarıyla TRDOS * DEL komutu eklendi (eski trdos cmd_intr.asm dosyasından değişikiklerle) Bulunan dosyasının directory'deki kaçıncı Entry olduğu (DirBuffer_EntryCounter) ve bunun longname'i olup olmadığı, varsa longname uzunluğu (LongName_EntryLength) kullanılarak, en başta read only değilse, dosya silinecek, free sector/cluster hesabına eklenecek ve sonra longname entry silinecek (EntryCounter sayısından, longname entry uzunluğu çıkarılacak, bununan sayıya karşılık gelen entry'den başlayarak her bir longname entry checksum ile karşılaştırıldıktan sonra silinecek). 21/02/2010 itibarıyla TRDOS * TRDOS Singlix FS sürücüsünden C olarak boot yapamıyordu, boot sektör kodu dönüşünde DL sürücünün fiziksel numarası (0 veya 80h ile) ile dönecek şekilde TRFS boot sektör kodunda değişiklik yaptım. DL=80h olursa TRDOS C:'yi current drive yapıyor. Bu değişiklik olmazsa TRDOS hard diskten başlarsa A:'yı göremediği zaman 'drive not ready or read error' hatası yazıyordu. Veya A:'ya geçiyordu. Bunu düzelttim. * SINGLIX FS hard disk partition formatlama hdformat.com ve bootfile.com (Şubat 2010) programıyla trdos.com'u TRFS partitionda 'startup file' yapınca trdos kernel şu haliyle disketten ve simülasyondan çalıştığı gibi çalıştı. hdformat.com hard diskin FS bölümünü formatlarken, bootfile.com FS startup file'ı DOS'tan FS bölümüne kopyelemeyi sağlıyor. bootfile.com DOS INT 21h open file, read file, close file fonksiyonlarını kullanıyor. Dolayısıyla standalone yada trdos içinden şimdlik çalışmıyor. 25/01/2010 itibarıyla TRDOS * Singlix FS sürücüsünde CD komutu işlevselliği tamam. * Show komutuyla açılan dosya kapanmıyordu, sebebi PSP yapısında offset 4 olan OFL (açık dosya listesi) sıra numarasının, OFDT (r/w) yapısında offset 2'de olmasıydı. (Önceden PSP içinde de offset 2'de idi ama msdos PSP ile uyumluluk için, OFL numarası alanını offset 4'e taşımışım; bu RUN komutuyla kullanıldığı için kapanış doğru gerçekleşiyordu. Ama, show komutu ODFT oluşturduğu için, OFDT'de aynı alan offset 2'de kaldığından kapanışta farklı numara görünüyor ve dosya kapanmıyordu. OFDT içinde OFL numarasını veren OF_OFL_SN offset değerini 4 yapınca hata düzeldi.) 24/01/2010 itibarıyla TRDOS * DRV_FS.ASM içindeki proc_get_next_section prosedüründe bugfix'ten sonra Singlix FS dosya sistemi içinde tek veya çok sektörlük COM veya EXE dosyası çalışma kusuru düzeldi. Artık FS içinden program çalıştırılabiliyor. * Longname komutunun singlix FS sürücülerine de uygulanmasını tamamladım. * Singlix FS sürücüsünde CD komutunun FS'e uygulanması aşamasındayım. 17/01/2010 itibarıyla TRDOS * Proc_allocate_memory prosedürü içinde bugfix. * Proc_load_fs_sub_directory ve proc_convert_fs_dir_entries_to_dos_format prosedürlerinde modifikasyon. * Modifikasyonlardan sonra diğer sürücülere geçiş (dir/liste) hatası düzeldi. Muhtemelen directory buffer'daki tahribat düzeldiği için geçişler düzeldi. 16/01/2010 itibarıyla TRDOS * FS dosya sisteminin DOS formatıyla gösterilmesi tamam. Bir directory'de en çok 2048 adet FS dosyası (64K buffer) gösterilebiliyor. (FS directory'de daha fazla dosya varsa, TRDOS kernel bunlara erişemez.) Ayrıca, numeric tail kısmını yazdım. Basis name'den numeric tail gereken veya gerekmeyen short name üretme işini tamamladım. TRDOS kernel şimdiki haliyle ~999'a kadar (farklı filename'lerden türeyen) aynı short name'i farklı hale getirmeye yönelik numeric tail ekleyebiliyor. * proc_open_File prosedürünün içindeki proc_load_file prosedüründen sadece FAT dosya sistemine erişiliyordu. Bu prosedür içinden, sürücüde FS dosya sistemi (FAT Tipi=0) olduğu için çağrılan, proc_load_fs_file olarak adlandırdığım, Singlix FS dosya sistemi içindeki dosyayı açan prosedürü yazdım. * FS dosya sisteminde 16'dan fazla dosya/dizin var ise dizin listeme (dir) prosedürü takılıyor (18'de takıldı, 16-18 arasında dosya aları bozuk geliyor) Dizindeki dosya sayısı 16'dan az ise hata vermeden listeliyor. Ayrıca, FS'de silinen directory entry FFFFFFFFh olarak işaretleniyor. dos directory entry formatına çevirme prosedürü (DRV_FS.ASM içinde) henüz bu durumu dikkate almıyor. Dolayısıyla silinmiş dosyanın FDT'sini FFFFFFFFh alarak dosya adı ve bilgilerine yönelirken 'drv not ready or read error!' hatasına sebep oluyor. Bu kusurları düzelteceğim. * FS sürücünün içeriği uyumluluk modunda yüklendiği zaman (proc_change_current_drive) diğer sürücülerin içeriğini görmek mümkün olmuyor. FS sürücüden ayrılıp tekrar geri dönünce de sürücü içeriği kullanılamaz hale geliyor. (DIR komutu ile v.s.) Bunun sebebi FS dosyalarına erişim prosedürlerinin (DRV_FS.ASM içinde) ve directory buffer'de olan değişikliklerin, işleyişi bozması olabilir. Yani sürücü değiştirği zaman kullanılacak değişkenler bozulduğu için erişim bozuluyor. Bu kusuru FS dosya sisteminde dosya listeme, açma ve çalıştırmayı tam sonuçlandırdıktan sonra düzelteceğim. 10/01/2010 itibarıyla TRDOS * FS dosya sisteminin DOS formatıyla gösterilmesi kısmen tamam. Numeric tail kısmını yazacağım. Ve FS sürücününden FAT sürücüsne geçince hata verme (directory'yi göstermiyor) sebebini bulup düzelteceğim. 03/01/2010 itibarıyla TRDOS * SINGLIX FS dosya sistemli sürücünün içeriği DOS uyumluluk modu içinde aynı dizin listleme formatıyla kayıtlanıyor. (Henüz dos dir entry formatına ve short name -basis name ve numeric tail- çevirme işlemleri tamam değil). * SINGLIX FS dosya sistemi listeme çalışması yaparken mevcut CHS okuma hatasını düzelttim (SecPerTrack ve Heads parametrelerini FAT CHS/BPB ile uyumlu hale getirdim, yani 'LD_BPB +' offset değerleri eşitlendi böylece CHS disk okumada SINGLIX FS formaytlı diskin içeriğinin doğru okunmasın sağladım.) 06/12/2009 itibarıyla TR-DOS * DIR komutu drive ve path içererek çalışıyor. RUN komutundaki path uygulamasını DIR komutuna uyarladım. (Davranışı aynı, dir girişi boş ise cdir kullanılıyor, RUN komutunda sürücü adı dosya veya path adı olmadan hata döndürürken, DIR komutunda ilgili sürücünün CDIR'i yeterli olduğundan hata döndürmüyor. Farkı proc_parse_path_name'den değil, cmd_dir'den uyguladım. proc_parse_path_name hata döndürünce, bu hata sürücü adından sonra PATH veya dosya adı olmaması ise, cmd_dir prosedürü bunu tesbit ediyor ve ilgili sürücünün Current DIR'ini kullanıyor.) * SHOW komutu RUN komutuyla aynı şekilde PATH içerebiliyor. (RUN ile tamamen aynı PATH çözümleme davranışı var.) * TRDOS kernelde FIND_FIRST_FILE prosedürünü yazarken DS:SI'de drv ve/veya path dahil asciiz dosya adı varsaymış ve bu anlamda DS'nin CS'den farklı olabileceğini öngörerek, prosedürü yazmıştım. Bu durumda TRDOS'un 2004-2005 taslağında find_first_file path kullanıyordu, 2009'da geçici olarak bu özelliği devre dışı bırakmıştım. Fakat en son proc_parse_path_name (2009) prosedürünü yazınca FFF data yapısının içinde FindFile_Drv (1 byte), FindFile_Directory (65 byte) FindFile_Name (13 byte) alanlarında drv (yeni sürücü veya current drv) ve PATH (yeni veya current directory=boş) dönüşü kullandım. (DS=CS) Dolayısıyla en son durumda FIND_FIRST_FILE başlarken PATH çözülmüş olarak başlayacak. Bu durumda change_directory (geçici değiştirme) dışarıda gerçekleşebilir. FIND_FIRST_FILE sadece o anki Current directory içinde dosya arayabilir. (Arayacağı dosya FindFile_Name içinde ascizz dosya adı) Sonuç olarak, FIND_FIRST_FILE prosedürü CDIR'e göre kısaltılacak ve iyileştirilecek. INT 21h içinden Find_First_File fonksiyonunda drv ve path olacak. Fakat bu problem değil. cmd_intr.asm'de kullanılan yöntemle find_first_file prosedürü çağrılmadan önce change_drive ve/veya change_directory ve sonra restore current_directory prosedürleri ile cdir ve cdrv fonksiyona girmeden önceki hale döndürülecek. Sadece 'change current drive' ve 'change current directory' fonksiyonlarında restore cdir/cdrv işlemi olmayacak. 05/12/2009 itibarıyla TR-DOS * RUN komutu girişi farklı sürücülü path içeriyorsa, sürücünün directory'si belirtilmemişse onun change drive esnasında restore edilen current directory'si kullanılıyor. Buna rağmen Bochs emulator (v2.4) içinde floppy drive media change status daima media changed (ah=6) gösterdiği için emülatörün floppy disk image'ı içinde iken daima root directory'e dönüş olduğundan 'cd' komutunda kayıtlanan cdir siliniyor (reset oluyor). Bu bir bug gibi görünmesine rağmen, emülatörün dışında, gerçek fd'den trdos boot olunca böyle bir durum olmuyor. Yani CDIR korunuyor. (CDIR'in korunması veya reset olması -> MAINPROG.ASM, change_current_drive, call proc_get_media_change_status, call floppy_drv_init) 29/11/2009 itibarıyla TR-DOS * RUN komutu PATH ile birlikte çalışıyor. Aynı zamanda CD ve diğer patrh/directory ile ilgili komutlarda (CD komutu 'CDh' imzasıyla kendini belli ediyor) proc_change_current_directory prosedürü farklı davranıyor. 'CD' komutunda değişen dizini dos sürücü tanım tablosuna kayıtlarken diğer komutlarda kayıt yapmıyor (şimdilik sadece 'RUN' komutu uygulaması gerçekleşti) böylece komutun argümanı olan path CDIR'ı bozmuyor, komuttan dönüşte CDIR restore oluyor. (Restorasyon 'RUN' komutunda INT 20h terminasyon kodu aşamasında gerçekleşiyor.) * RUN komutunda PATH değişkenine bağlı dizinlerde otomatik olarak dosya aratma aşamasına henüz gelmedim. Şu anda sadece girilen directory içinde dosya aranıp bulunduysa yüklenip çalıştırılıyor. Bugünden önce sadece 'CD' ile girilen alt dizinlerde veya ROOT'ta dosya çalıştırılabiliyordu. Örnek:'B:/> run trdos/erdogan/runme.com' formatında dosya çalıştırma bugün itibarıyla mümkün oldu. Komuttan dönünce root directory yine current directory oluyor. (B:/>) Fakat, çalışan dosyanın çalışması devam ederken cdir (B:/trdos/erdogan>) !.. Dolayısıyla içerideki cdir ile dönüşteki/dışarıdaki cdir aynı değil... Dönüşteki cdir içeriye girmeden önceki cdir... (previous cdir)... 25/11/2009 itibarıyla TR-DOS * COM dosyası için yüklenen sektör*512 byte'a 1024 byte YIĞIT boşluğu ekleniyor. Stack pointer (SP) allocation size (256 byte olarak) kadar segment adresinden yukarıda kullanılır. Örnek: Allocation size 120 (78h) ise, SP = 121*256, 7900h olur. (120+PSP= 121) Bu (SP'yi ms-dos'tan farklı ayarlayan, COM dosyası için ms-dos'tan farklı olarak, sadece kendi büyüklüğüne bağlı bir bellek bölgesi atayan) bellek tahsis/atama yönteminin uyarlamasını yaptım. (COM dosyası içinde stack boşluğu atamak gerekmiyor... Bu düzenlemeyi yapmasıydım, COM dosyası bellekte kendisine atanmış olmayan, örneğin: SP = 0FFFEh offset'ini kullanabilirdi. Bu da bellekte yüklü diğer bir dosyayı bozabilirdi. Yani STACK POINTER programa atanmış bellek içinde kalacak şekilde program çalışmaya başlatılmış oldu.) * COM dosyası 64000 byte'tan büyük ise 1024 byte YIĞIT boşluğu eklenmiyor. 65535 byte olarak bellek atanıyor. ve Stack Pointer 0FFFEh oluyor * TR-DOS'ta COM çalıştırmanın MS-DOS'tan farkı, dosya boyutunun en az 1024 byte üstüne SP atanması ve belleğin sadece COM dosyasını çalıştırmak için gerekli PSP+AllocationSize (dosya büyüklüğünün sektör sayısına ölçeklenmiş halinin en az 1024 byte stack boşluğu kalacak şekilde yukarıya taşınması şartıyla bellek ataması) kadar kısmının kullanılması. (MS-DOS tüm serbest belleği COM dosyasına tahsis etmektedir.) * Allocation Size PSP'yi veya OFDT'yi içermiyor... (Bellek atama tablosunda AllocationSize+1 100h byte hücreler olarak ve tek blok olarak aynı numarayla gösteriliyor.) Bunun sebebi, AllocationSize ile kasdedilenin programın kullanacağı kısım olmasıdır. PSP veya OFDT başlık muamelesi görüyor ve program boyutu içinde sayılmıyor. (Sadece COM dosyası için eklenen Stack boşluğu programın uzantısı sayılıyor. EXE dosyalarına ve okuma/yazma için açılan dosyalara stack boşluğu eklenmiyor. Sadece okunan/yazılan sektörlere denk düşürmek için, gerekiyorsa, sektöre göre düzleştirilmiş/ölçeklenmiş -dosya boyutunu aşan- bellek ataması yapılıyor.) * COM stack boşluğunun 1024 byte olması, daha küçük stack boşluğundan dolayı, stack'a ayrılan kısmı kullanan COM programlarının (RUNME.COM gibi) kendi kendini yemesini önlemek. (664 byte'lık RUNME.COM 32-64 byte stack boşluğu ile çalışmıyor, 256/512 byte ile kusurlu çalışıyor, 1024 byte stack boşluğu eklenmesiyle düzgün çalışıyor. Çünkü 940 byte offset'ten 1940 byte offset'e kadar 5'er atlayarak (CX=200) 'add DI, 5' ve 'mov byte ptr [DI+4], ah' şeklinde kayıt yapıyor. TR-DOS kernel RUNME.COM'u 2 sektör yükleyip +1024 byte bellek tahsisi yaptığından, stack pointer 2048 olarak program başlıyor ve SP değeri 1940'dan uzak olduğu için stack 'push' komutları çalışmayı bozmuyor. NOT: RUNME.COM (RUNME.ASM) TR-DOS'un geliştirilmesinde önemli rolü olan, eski ve çok kısa (664 byte'lık) bir demo programıdır. Ekranda yıldızlar/noktalar arasında belirlenmiş yazı gösterir ve basit animasyon yapar. TR-DOS kernel RUNME.COM'u diskten yükleyip başarı ile çalıştırınca (diğer bazı COM ve EXE'ler de sınanmıştır) DRV INIT prosedürünün, 'load and run executable' prosedürlerinin INT 20h'nin yani kısaca, dosya sisteminin ve kernel'in basit kurulumunun başarıyla gerçekleştiği anlaşılmıştır. DOS interruptlarını kullanmayan küçük EXE'lerin takılmadan çalışması da TR-DOS işletim sistemi çekirdeğinin 2009 EKİM-KASIM aylarında başarı ile ortaya çıktığını/canlandığını göstermektedir. 18/11/2009 itibarıyla TR-DOS * CLOSE FILE prosedüründeki kusurları düzelttim. Açılan MEMAT kayıtları dosya açılmadan önceki hale geri dönüyor. Bir dosya kapandığı zaman ona bağlı açık dosya var ise o da kapanıyor. (Diske kayıt yapılmaksızın.) MEMory Allocation Table'da 41h'den 60h'ye kadar PSP'ler 61h'den 80h'ye kadar OFDT'ler görünüyor. İlk olan daima PSP veya OFDT takip edenler açık dosyanın kendisi. 256 byte'lık hücreler şeklinde tahsis var. Open Files List'te 32 kayıt var. İlk kayıt yani offset 0, 41h veya 61h olarak MEMAT'ta yer alıyor. (Açık dosya ise...) 64+DosyaNo program/çalıştırma olduğunu, 96+DosyaNo okuma/yazma olduğunu gösteriyor. * MEMAT1.COM (MEMAT1.ASM) adlı MEMAT'ın ilk kısımlarını gösteren programcık yazarak oradan gördüğüm duruma göre kusurları düzelttim. Örneğin: MEMAT1.COM kendini daima 04h'den sonra (Dir Buffer) gelen iki adet 41h olarak gösteriyor. İlk 41h MEMAT1.COM'un PSP'si, 2. ise dosyanın/programın kendisi... PSP segmenti aynı zamanda dosyanın Handle'ı... İlk 41h'nin pozisyonu 256*MEMAT_Offset= PSPN'in addresi, bu sayının 16'ya bölümü PSP'nin segmentidir... Örnek: 09D0h segmenti... MEMAT'da 9Dh offset'inde görünür. * Dosya içinde dosya açıp kapama INTERRUPT'ların tekrarlanabilir girişi olmasını gerektiriyor. Yani INT 21h çalışırken başka bir program da INT 21h'ye girebileceği için. STACK problemi olmaması gerekiyor. Yani şu anki durumda INT21h'nin STACK/YIĞIT değeri tekil... başka bir program (TSR), INT ile araya girerse ve Kernel'in aynı stack pointer'ını kullanırsa program takılır. (İleride diğer aşamalardan sonra bu duruma uygun yapılandırmaya geçmem gerekecek.) 14/11/2009 itibarıyla TR-DOS * INT 21h ile ile bazı basit fonksiyonları gerçekleştirdim. Program INT 21h'den dönebiliyor. Fakat dönüşte directoy list v.s. tekliyor... Open_File veya başka bir aşamada bugfix gerekiyor. * CLOSE FILE prosedürünü yazdım. Dosyaları kaparken kayıtlamıyor. Dolayısıyla değişen dosyalar sahibi olan program tarafında kayıtlanmalı. Kapanan dosya sahibi olduu tüm dosyaları da kapatıyor. Ve bellekte kapsadığı yer boşaltılıyor. 11/11/2009 itibarıyla TR-DOS * Geçici ayarlarla (current directory içinden ve sadece FAT/FAT32 dosya sistemleri) RUN ve SHOW komutları üzerinden program çalıştırma, dosya görüntüleme, OPEN FILE, LOAD FILE prosedürleri gerçekleşti... 25/10/2009 itibarıyla TR-DOS * MEM yada MEMORY komutu tamamlandı, toplam kullanılabilir conventinal (trdos için real mode içinden erişilebilen) memory, toplam boş memory ve toplam ardışık boş memory büyüklüğünü veriyor. MEM_INIT.ASM içinde gerekli bazı düzeltmeleri yaptım. Prosedürü belleğin bir kısmından itibaren ve ilk uygun boş segmenti bulmaya göre yazdım. Fakat MEM komutunda bu segmenti kullanmadan, 21. hücreden itibaren boşa yer kontrol ediliyor. A20 hattı enabled ise bellek 1114112 değilse 1048576 olarak görünüyor. A0000h'den itibaren 0A, 0B... 0Fh şeklinde atama kodları var... Sonradan bunların arasına yerleşilebilir. (MEM INIT prosedürü UMB kullanılmıyor durumuna ayarlı.) * VOLUME komutunun disk seri numarasını göstermesini ekledim. 19/10/2009 itibarıyla TR-DOS * CD komutunda error dönüşü olunca bulunamayan directory görünüyordu, bunu 'path/directory not found' için directory level'ı bir geri alarak ve diğer hatalar için 'proc_change_current_drive' prosedürünü çağırarak düzelttim. Yani alt dizinlerde takıldığı yerden bir geriye, okuma hatasında veya diğer hatalarda geçerli mantıksal Dos disk sürücüsünün geçerli dizini yeniden yüklenip takıldığı yerden geriye alınıyor. * LONGNAME komutunda UNICODE karakterleri kayıtlamaya karar verdim çünkü diske dosya adı kayıtlarken orijinali kaybetmemek gerekiyor. 65 byte olan dizgi 130 byte ve arkasından 2 byte sıfır kayıtı olaarak yer 132 byte'a çıktı. Buna karşılık, ekrana yazarken sadece AL yazmacındaki dğer karakter olarak görünecek. (İleride UNICODE'dan Türkçe'ye v.s. ayıklama yaparken ek algoritma/prodedür gelebilir.) UNICODE kayıtlama 'LONGNAME' içinden değil 'proc_find_direntry' içinden çağrılan 'proc_save_longname_sub_component' prosedürü içinde yapılıyor. Böylece her dosya arama işleminde bulunacak kısa ada ait uzun ad kayıtlanmış oluyor. Örnek: 45h,04,03,02,01 olarak geriye kayan herbiri 26 byte isim parçası kayıtları... 18/10/2009 itibarıyla TR-DOS * LONGNAME komutu tamamlandı. 65 byte'a kadar dosya adını görüntülüyor. Büyüklüğü 65 byte'tan fazla olanları dikkate almıyor. 2 byte UNICODE karakter (ax) setinde ah> 0 ise al = "_" olarak gösteriliyor. ('ax'den 'al' karakterlerini gösteriyor.) (5 adet longname sub componenti dikkate alıyor, last long entry order >45h'yi yani 40h + sırano 45'den büyük ise dikkate almıyor... 5*13=65.) 17/10/2009 itibarıyla TR-DOS * CD komutu tamamlandı.. "." ve ".." işlem görüyor. Root'un altında 7 seviyeye inebiliyor. daha derine inmiyor... 12/10/2009 itibarıyla TR-DOS * CD komutu genel olarak çalışıyor ".." konusunda bug sayılabilecek bir prompt gösterimi var "cd ../../" promptta kendini gösteriyor ama geri gitmeye gidiyor bu düzeltilecek... Bunun dışında sürücüler arası geçişte current dir koruması ileri ve geri gidiş, çok seviyeli alt dizine atlama gerçekleşti. CD komutu en dip seviyesi root'tan sonra 7. Normalde diğer DOS uyarlamaları dip seviyesini sınırlamıyor ama karakter sayısını sınırlıyor. Diğer dos'larda directory karakter sayısı 80 ile sınırlı iken TR-DOS'ta dizinlerin/path olabilecek karakter sayısı 90 (7*12+6) 06/10/2009 itibarıyla TR-DOS * DIR Komutunda ".." olarak önceki directory'nin dir list içinde listenmesi tanıtıldı daha önce dir '.*' ie '..' listelenmiyordu... proc_convert_file-name'de dosya adımnın ilk iki karakteri '..' ise direkt onları kullanan değişiklik yapıldıi daha öce (2005'ten beri) sadece ilk noktayı tanıyordu. İkinciyi aradaki nokta kabul ediyordu. extension yok ise ikinci nokta düşmüş oluyordu. * CD komutunda FAT 32 root dir için, proc_change_current_directory içinde düzeltmeler yapıldı. Kontrol edilecek yine takılma varsa düzeltilecek. Deep dir level'lar kontrol edilecek. Root dir 'ROOT' olarak 'PATH_Array' level 0'da (ilk 16'nin ilk 4'ünde) işaretleniyor, orası boşsa set oluyor (floppy_drv_init reset yapıyor, hard disk bir kez set oldu mu öyle kalıyor) bunu kontrol ederek gereksiz yeniden yazmadan kaçınıldı. 04/10/2009 itibarıyla TR-DOS * CD komutu çalışıyor. Takıldığı yerlerin kontrolleri yapılacak. 12 byte dos formatıyla array hazilinde en çok 8 levelde (root + 7 sub dir level) path name tutuyor. Bunlar prompt ve dir için noktalı formata çevriliyor. Dir için 64 byte, prompt için ve asıl olarak 91 byte (7*16+7) current directory veya path name tutuluyor. En son level'a başarıyla gelimişse change directory gerçekleşiyor ve sürücü tablsouna cdir olarak '8*(12+4)' formatıyla) kayıtlanıyor. aralarda load root dir ve load sub dir standrad/otomatik gerçekleşiyor buffer işlemleri change dir'i karıştırmıyor. cd .., cd /, previous dir ve next dir formatları kontrol edilecek. Durumlar: Current_dir_level > 0 ise last_dir_level < current_dir_level ise previous dir (parent) mümkün, ve next sub dir (child) mümkün. Current_Dir_Level >7 ise child'e geçmiyor. CDir_Level = 0 (root) ise previous/parent'a geçmiyor. Eğer path veya directory adı "/" ile başlıyorsa (command buffer'dan) current_dir_level = 0 olarak ve last_dir_level proc_parse_path_name'dan dönenen göre belirleniyor, ve last_dir_level'a kadar root'tan itibaren seri yükleme ve geçiş yapılıyor (proc_locate_file ile) 27/09/2009 itibarıyla TR-DOS: * Disketle açılışta eski FAT12 FS (A:) üzerinden trdos.com yükleme (trfdboot.com trdos v1.0) üzeriden çalıştırınca 'get_next_cluster' gerektiren FAT32 (C:) dir listelemeden dönebiliyordu. Fakat bir kaç günden beri TRFS1 fd0: (A:) üzerinden trdos.com yükleyince FAT32 (C:) 'dir' komutu get_next_cluster'dan dönemiyor, takılıyordu. FAT12 ile bir kez fat_buffer set olunca bu takılma olmadığından sebebin fat_buffer pointer = 0 olduğunu anlayıp, get_next_cluster prosedürü içinde 23/09/2009'da yaptığım ama uygulamadığım bx>0 kontrolünü aktifleştirdim. Böylece, birden çok cluster'ı kapsayan DIR komutunun takılma problemi kalmadı. * Geçici 'find' komutu find-next_file'da cf= 1 dönüyordu böylece listeleme eksik oluyordu. Bu durum sebepsiz gibi görünüyor. Muhtemelen stack veya segment prefix problemi veya assembler'den kaynaklanan problem. Bunu find_next_file prosedürü başına 'push ds, pop ds' ! koyarak telafi ettim. İleride sebebini bulursam düzeltirim. 26/09/2009 itibarıyla TR-DOS: * MAINPROG.ASM içinde directory listeleme prosedürleri DIR.ASM'ye alındı. Fakat DIR.ASM TRDOS.ASM'de değil, MAINPROG.ASM içinde 'include DIR.ASM' oldu... (MAINPROG.ASM'yi ikiye ayırmış oldum, çok büyük olduğundan çabuk okuyamıyordum.) * Bochs Emulator hatası 'cmp word ptr [FindFile_MatchCounter], 0' komutu yerine 'xor cx, cx' 'cmp word ptr [FindFile_MatchCounter], cx' komutları kullandım ve and directory listeleme -sonraki dosyalar için- düzeldi. 'push ds, pop es' or 'push es, pop es' dahi hatayı düzeltiyordu!? push es pop es cmp word ptr [FindFile_MatchCounter], 0 ja short loc_start_search_next_file ... garip bir hataydı ve cx üzerinden sıfır kontrolü uygulayarak düzelttim. * Directory listeleme işlemini kilitleyen durumu önlemek için önceden tamamlanmış prosedürlerde ufak tefek değişiklikler yapıldı. Önemsiz olmakla birlikte dönüşü etkileyen veya farklı dallanma yaptıran değişiklikler '26/09/2009' olarak prosedür başlarına değişliklik tarihi ile işaretlendi. 23/9/2009 itibarıyla TR-DOS: * get_next_cluster prosedüründe ES: dahili işleme alındı, FAT_Buffer'dan içeride yüklendi. Dışarıya prosedür çağrılmadan önceki haliyle geri döndürüldü. Böylece mevcut içerilerden ES: değişikliği problemleri halledildi. FAT32 directory listeleme (multi sectors veya multi clusters'lı) düzelmiş oldu. (Current directory için 'DIR' tüm FAT12-16 ve FAT32 durumları için tamam...) 22/9/2009 itibarıyla TR-DOS: * FIND_NEXT_FILE prosedürüne sebepsiz görünen bir 'push ds, pop es' koyana kadar find_next_file (proc_print_directory için) görevini yapmıyor listeyi ilk satırda kesiyor (find_first_file sonucunda). Bu push ds, pop es'nin nerede sonucu etkilediğini bulamadım. Çünkü stc dönüyor ise lazım değil, dönmüyor ise, ds=es kullanılmıyor. Bu garip duruma BOCHS Emulatörü 2.4.1'de karşılaştım. Dosya sistemleri FAT 12 ve FAT 16. Muhtemelen FAT 32'de de aynısı olabilir. MAINPROG.ASM, proc_find_next_file prosedürü içinde geçici notla birlikte... 21/9/2009 itibarıyla TR-DOS: * Root directory'de listeleme (dir komutu) tamam. * volume komutu prosedürü daha sonra serial no gosterecek şekilde değiştirilebilir. * mem_init.asm için proc_deallocate_memory'de yanlış push pop sonucu DS'nin değişmesi bana 2 gün boşuna proc_change_drive prosedüründe hata arattı en son disk_read'dan hata döndüğünü farkettim, sebepsiz gibiydi load_root_directory hata dönüşü register detayına girince DS'nin memory allocation table segmente (bx) eşit olduğunu görünce durumu anladım. Çünkü directory buffer ataması yapılırken push edilen BX DS olarak pop ediliyordu bu da var olan bir buffer resetlenirken oluyordu, resetlenmezse olmuyordu (dir ve change drive komutununun kısmen çalışma sebebi, yani iki kez yazınca change drive çalışması veya sürücü değiştirince dir hatası oluşması) sebebini farkedince proc_deallocate_memory'yi düzelttim ve sürücü geçişleri root directory için hatasız gerçekleşti. Ve directory buffer'dan (current dir) listeleme hatasız gerçekleşti. (Tüm FAT ve FAT32'ler için) 19/9/2009 itibarıyla TR-DOS: * BOCHS 2.4.1 Dos emulatöründe TRDOS.COM FS1 boot (fd0 startup file) çalışması... (FSFD.EXE ile 1.44MB fd image file a.img'de FS1 dosya sistemi var, ona TRDOS.COM startup file yükleyip boot yaptırıyorum. B: yani b.img FAT12 fd, C: yani c.img FS1 hard disk olarak çalışıyorum.) * Komut uygulaması MAINPORG.ASM'ye konuldu. TRDOS.ASM kısmen boşaltıldı. Fakat MAINPROG.ASM'nin sadece komut uygulama-prompt kısmı onda kalmalı, diğer kısımlar kernel dosyaları (modülleri) içinde olmalı ki, ileride MAINPROG.ASM opsiyonel olabilsin. (İleride başka bir command manager veya değişik MAINPROG.ASM kullanılabilmeli.) * DIR komutu ve FIND komutu, find_first_file, find_next_file şimdilik sadece Current directory için (directory_buffer'da ne varsa) çalışıyor. (proc_change_current_drive directory_bufferi root olarak yüklüyor) yani root directory'den dosya listeliyor. İleride full pathname değişiklikleri ve eklemeleri yapılacak. * Change_current_drive'da A: boot drive, iken B:'ye geçilirse oradan C: (FS1) olursa, tekrar B: olduğunda ilk seferde B:ye geçmiyor fakat 2. denemede geçiyor. A:'dan C:'ye geçerse B:ye geçiyor. (A: diski FS1 dosya sistemi ve trdos.com.) Bunun sebebi change_currrent_drive içinde 'get_media_change_status' veya [SI][LD_MediaChanged] pointerine konulan değerlere bağlı işlemlerden biri. 'floppy_drv_init' prosedürünü A: veya B:'ye geçmeden kullanmamak için (açılışı yavaşlatmamak için) trick'ler yapıyorum (initialization signs) buna karşılık bir yerde B:'den C:'ye geçince C:'den B:'ye ilk dönüş olmuyor. (C: ile A: arasında geçiş problemi yok...) Ama ikinci dönüş girişimi başarılı oluyor. Sebebini bulup düzelteceğim. * find_next_file prosedüründe 'push cs, pop ds, push ds, pop es' geçici bunlar kontrol edildikten sonra çıkarılacak. şimdilik listelemeyi sağladığından kullandım. (ds veya es'nin uygun gelmediği yeri bulunca bunlar kalkacak (veya print_directory prosedürüne taşınacak)... * DIR komutunda en çok takıldığım yer, find_next_file'da "cmp dh, 0Fh" komutunun (dosyanın longname'i varmı kontrolü) cf=1 vermesi ve bunun return olması idi (previous attribute 08 idi)... Oysa dosya uygun bulunduğundan cf=0 ile dönmesi gerekirdi. Bunu atladığım için CF'yi etklieymeyen bir sürü instruction'a rağmen find_next_file cf=1 (stc) dönüyordu ve ilk dosya hariç listelenmiyordu. Hatayı 2-3 saatlik kontrol sonucunda CF=0 yapan tesadüfü bir komut ekleyerek (mov si, offset burasi, call proc_printmsg) farkedebildim. 15/9/2009 itibarıyla TR-DOS: * CMD_INTR.ASM command interpreter dosyası 'volume', 'prompt', 'CD C:' veya 'C:' benzeri change current drive komutlarıyla çalışmaya başladı. Change_Current_Drive'da hem Current_Drv (sayı) ghem Current_Dir_Drv (harf) olarak kullanılıyor. Eski (2005) TRDOS.ASM'deki 'DirBuff_Drv' yerine 'Current_Drv' geldi. 'Current_Drv' olan yerde iki kez işlem (ayrıca Current_Dir_Drv var) görünüyor. Bunlardan biri devreden çıkarılabilir. Current_Dir_Drv text olarak kullanılan kısmın parçası olduğundan korunacak gibi. 'Current_Drv' akıbeti programın kalan kısmına bağlı. 'Date', 'Time' komutları bu aşamada çalışıyor. 'Dir' komutu 'change drive' hariç hazır değil. 'Volume' komutu Volume Name, total ve free space bilgilerini ve FS bilgisini (Dos mantıksal sürücü adına bağlayarak) veriyor. Örnek: 'FAT 12 volume in drive A: is' şeklinde... 12/9/2009 itibarıyla TR-DOS DRV_INIT: * FAT dosya sistemli dos sürücülerine 'change drive' yapıldığı zaman 'change_current_dos_drive' prosedürü,'current_directory' yapısını sıfırlıyor ve eğer floppy drive 'media_changed' durumu var ise floppy_drv_init çağrılıyor. Bu iş'proc_get_media_change_status' prosedürü üzerinden yapılıyor. Ayrıca, LD_mediachanged = 6 ise (root directory'den varsa volume_name'i sürücü tanım tablosuna taşımak için işlem yap işareti drv_init ve floppy_drv_init prosedürleri tarafından yapılıyor), volume_name taşıma işlemi yapılıyor. 5/9/2009 itibarıyla TR-DOS DRV_INIT: * Bundan sonraki aşama directory listeleme. * FAT Volume Name taşıma (Get_FAT_Volume_Name) başarılı oldu ancak 'dos drive description table'a kopyeleme şimdilik uygulanmadı. * FAT root directory buffer yükleme (mem_init.asm, drv_fat.asm) ve ilk kullanım başarılı oldu. 23/8/2009 itibarıyla TR-DOS DRV_INIT: * DRV_INIT.ASM ve TRDOS.ASM'de 23/8/2009 tarihli geçici kod kayıtlarına dikkat! * FAT Volume Name şimdilik başarıyla taşınamıyor (TRDOS.ASM proc_print_volume_info). * FAT Volume Name'i directory içinden elde etme tamam, DOS Drive Description Table içine taşıma prosedürü yazılacak. * Floppy Disk'te meda change ve dos sürücü tanımlama tablosu yenileme işlemleri tamamlanmadı. Sonradan takılan floppy diskte media change tespit edilirse dos sürücü tanımlama tablosunun hemen güncellenmesi gerekiyor. Yani floppy_drv_init dinamik olmalı. Buna karşın hard idsk drv_init sadece başlangıçta çalışıyor. * FAT ve FS dışındaki dosya sistemleri (CD_ROM ve DVD dosya sistemleri) daha sonra installable file system prosedürleri olarak trdos kernel'e eklenecek veya trdos kernel extension olarak tasarlanacak. (Başka bir dosyadan yüklenecek.) * proc_load_FAT_root_directory ve proc_load_FAT_sub_directory prosedürlerinin DRV_FAT.ASM içinde yazılması ve DRV_INIT.ASM içindeki proc_get_FAT_volume_name prosedürünün bunlara uygun olarak değiştirilmesi tamam. * proc_deallocate_memory prosedürünün MEM_INIT.ASM içinde yazılması tamam. 12/7/2009 itibarıyla TR-DOS DRV INIT: * FAT 32 dosya sistemini hard diskten tanıyarak mantıksal sürücü olarak kullanıyor * proc_deallocate_memory başlangıç segmentinden itibaren belirtilen allocation tipine ait bellek kısmını serbest bırakması lazım. Bu prosedür proc_allocate_memory prosedüründen bozarak MEM_INIT.ASM içinde yazılacak * proc_load_FAT_root_directory prosedürü yazılacak. bu prosedür bh'de (bl=0) dos drive numarasından sürücü içeriğini okuyarak tüm root directory içeriğini Directory_Buffer_Size kadar ardışık sektörü yükleyerek bellekte hazırlayacak. hata varsa stc dönecek. * proc_load_FAT32_sub_directory prosedürü directory cluster'ı tamamen belleğe yükleyecek. (proc_get_fat_volume_name prosedüründe Directory_BufferSize direct olarak cluster size'dan hesaplanabilir... Şu anda DirBuff_LastEntry'den hesaplanıyor...) Fakat DirBuff_LastEntry cluster size'dan hesaplanmıştı... yani yumurta-tavuk durumu.) * DRV_INIT directory bufferi LastEntry numarasından kontrol ediyor farklı ise bufferi bellekten siliyor ve sonra tekrar bellekte yeni durumuna göre yer açıyor. Bu niçin fix bir dir buffer kullanmıyor: mümkün olduğunca fazla yer vermekten kaçmak için, ileride diğer FAT prosedürleri ve FS prosedürleri Dir Buffer bellek atamasını daha farklı yapabilir. Yani bellek yetmiyorsa silebilir. (TRDOS daima en az bir cluster en çok root directory size hangisi fazla ise o kadar Dir Buffer ile çalışacak. LastEntry kontrolü trdos ilk yazıldığında sektör sınırı kontrolü idi... Bir sonraki sektöre geçiyordu. Sektör sınırı last entry'e (RootDirEntries) gelmeden önce bittiğinde bir sonraki sektörü yüklemesi gerekiyordu. Hızlanmak için cluster esaslı yüklemeye geçtim. * Get_fat_volume_name prosedürü root directory'de Volumename bulursa onu 11 byte olarak Logical Dos Drive buffer'ındaki LD_VolumeName alanına taşıyacak. Yoksa boot sektördeki volumelabel kısmı devam edecek. 7/7/2009 itibarıyla TR-DOS DRV INIT: * TRFS ve FAT16 harddiski tanıyor (Partition id 06h ve yukarısı) * FAT12 partition ve FAT16 partition id 04h'i tanımıyor. (uygulamada kullanılmadığından...) * TRFS ve FAT free sectors'leri byte olarak doğru gösteriyor... * TRDOS FAT12,16,32 Volume Name'i şimdilik Boot sektörden alıyor. Root directory'deki volumename'i şimdilik görmüyor...