20/06/2010 itibarıyle 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 modifiasyonları 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. 15/06/2010 itibarıyle 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ıyle 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ıyle TRDOS * TRDOS kernel taslağı, 12_6_2010 itibarıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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ıyle 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...