Enterprise Forever
:HUN => Programozás => Topic started by: Zozosoft on 2006.May.16. 00:37:25
-
100 PROGRAM "FDISK.BAS"
110 REM version 0.0
120 CLEAR SCREEN
130 EXT "ideread 41,0000,0,00000000,01"
140 PRINT "BOOT TYPE"," START SIZE"
150 FOR I=1 TO 4
160 CALL INFO(I)
170 NEXT
180 END
190 DEF INFO(SORSZAM)
200 LET MUTATO=446+(SORSZAM-1)*16
210 LET AKTIV=SPEEK(65,MUTATO)
220 LET TIPUS=SPEEK(65,MUTATO+4)
230 LET KEZDET=SPEEK(65,MUTATO+8)+SPEEK(65,MUTATO+9)*256+SPEEK(65,MUTATO+10)*256*256+SPEEK(65,MUTATO+11)*256*256*256
240 LET MERET=SPEEK(65,MUTATO+12)+SPEEK(65,MUTATO+13)*256+SPEEK(65,MUTATO+14)*256*256+SPEEK(65,MUTATO+15)*256*256*256
250 IF AKTIV=0 THEN
260 PRINT " NO ";
270 ELSE
280 PRINT " YES ";
290 END IF
300 SELECT CASE TIPUS
310 CASE 0
320 PRINT "Undefinied",
330 CASE 1
340 PRINT "FAT-12",
350 CASE 4
360 PRINT "FAT-16",
370 CASE 5
380 PRINT "Extended",
390 CASE 6
400 PRINT "BigDOS",
410 CASE ELSE
420 PRINT "Other",
430 END SELECT
440 IF TIPUS<>0 THEN
450 PRINT USING "#######":KEZDET;
460 PRINT USING "#######":ROUND(MERET/2,0);
470 PRINT "Kb"
480 ELSE
490 PRINT
500 END IF
510 END DEF
:-)
-
Nagy vagy Zozo! (Ö... mit is csinál ez a program? :) )
Belolvassa a 41H szegmens 0 címétõl kezdve a 0-ás vinyó 0. szektorát (1 darabot), azaz a particiós táblát.
Ezután sorban kiírja a 4 bejegyzéshez tartozó adatokat.
Egyelõre még csak a friss IDEREAD utasítás tesztelése, de lesz ebbõl még tényleges FDISK is :-) (elõbb kell még egy IDEWRITE is :) )
-
Kicsit tovább fejlesztve :-)
100 PROGRAM "FDISK.BAS"
110 REM version 0.0
120 ALLOCATE 9
130 CODE GETSEGMENT=HEX$("F7,18,67,69,C9")
140 CODE FREESEGMENT=HEX$("4D,F7,19,C9")
150 LET WS=USR(GETSEGMENT,0)
160 CLEAR SCREEN
170 EXT "IDEINFO "&HEXA$(WS,2)&",3FF0"
180 LET MAXDRIVE=SPEEK(WS,16374)
190 IF MAXDRIVE=0 THEN
200 PRINT "No Harddisk!"
210 GOTO 340
220 END IF
230 PRINT "IDE ROM at "&HEXA$(SPEEK(WS,16369),2)
240 PRINT "RAM area from "&HEXA$(SPEEK(WS,16370),2)&":"&HEXA$(SPEEK(WS,16372),2)&HEXA$(SPEEK(WS,16371),2)
250 PRINT "Detected: ";SPEEK(WS,16373);"controllers, ";MAXDRIVE;"disks"
260 PRINT "BOOT TYPE"," START SIZE"
270 FOR I=0 TO MAXDRIVE-1
280 PRINT "HDD-";I
290 CALL READS(0,I,0,1)
300 FOR J=1 TO 4
310 CALL INFO(J)
320 NEXT
330 NEXT
340 CALL USR(FREESEGMENT,WS)
350 END
360 DEF INFO(SORSZAM)
370 LET MUTATO=446+(SORSZAM-1)*16
380 LET AKTIV=SPEEK(WS,MUTATO)
390 LET TIPUS=SPEEK(WS,MUTATO+4)
400 LET KEZDET=SPEEK32(MUTATO+8)
410 LET MERET=SPEEK32(MUTATO+12)
420 IF AKTIV=0 THEN
430 PRINT " NO ";
440 ELSE
450 PRINT " YES ";
460 END IF
470 SELECT CASE TIPUS
480 CASE 0
490 PRINT "Undefinied",
500 CASE 1,11
510 PRINT "FAT-12",
520 CASE 4,20
530 PRINT "FAT-16",
540 CASE 11,12,27,28
550 PRINT "FAT-32",
560 CASE 5,15
570 PRINT "Extended",
580 CASE 6,14,22,30
590 PRINT "BigDOS",
600 CASE ELSE
610 PRINT "Other",
620 END SELECT
630 IF TIPUS<>0 THEN
640 PRINT USING "#######":KEZDET;
650 PRINT USING "#######":ROUND(MERET/2,0);
660 PRINT "Kb"
670 ELSE
680 PRINT
690 END IF
700 END DEF
710 DEF HEXA$(SZAM,HOSSZ)
720 NUMERIC I,M
730 STRING H$*8
740 LET H$=""
750 FOR I=1 TO HOSSZ
760 LET M=MOD(SZAM,16)
770 LET SZAM=(SZAM-M)/16
780 IF M<10 THEN
790 LET H$=CHR$(M+48)&H$
800 ELSE
810 LET H$=CHR$(M+55)&H$
820 END IF
830 NEXT
840 LET HEXA$=H$
850 END DEF
860 DEF READS(C,D,SS,SN)
870 EXT "IDEREAD "&HEXA$(WS,2)&","&HEXA$(C,4)&","&HEXA$(D,1)&","&HEXA$(SS,8)&","&HEXA$(SN,2)
880 END DEF
890 DEF SPEEK32(M)
900 LET SPEEK32=SPEEK(WS,M)+SPEEK(WS,M+1)*256+SPEEK(WS,M+2)*65536+SPEEK(WS,M+3)*16777216
910 END DEF
-
Már ilyet is tudunk :-)
(http://enterpriseforever.com/userpix/12_dscf3942_1.jpg.thumb.jpg) (http://enterpriseforever.com/userpix/12_dscf3942_1.jpg)
(jó sz** a fotó, de tán látszik a lényeg)
-
Már ilyet is tudunk :-)
Hú, de izgalmasan néz ki! :-) Hajrá!
-
Nagyon klassz!!!! Grat!
-
szimpatikus, amit a képernyõn látok.:)
-
Na már tudunk particiót csinálni, igaz még csak meglehetõsen fapados és ellenõrizetlen módon (INPUT MERET és hasonlók :-) )
-
Lassan kezd valahogy kinézni is :-)
-
Csodálatos! :-) GRATULA! (Hátha itt reagálsz is... :-D)
A BigDos -on mit is értünk egyébként...?
-
Lassan kezd valahogy kinézni is :-)
Szép színes! :-D
-
A BigDos -on mit is értünk egyébként...?
Anno már részletesen kifejtettem az Indexen :-)
Bigdos a 32 bites logikai szektorcímzést használó FAT16 partició, azaz 32 megánál nagyobb. Hivatalosan 1988-ban az MSDOS 4.0-val lett bevezetve.
Na ilyet nem fogunk EP-n használni, még egy jó darabig...
-
És 16 bites logikai szektorcímzésû FAT16 partitiot mikor fogunk használni? :)
-
És 16 bites logikai szektorcímzésû FAT16 partitiot mikor fogunk használni? :)
Valamivel elöbb :-) ahhoz csak kicsit kell majd árirni az EXDOS-t...
De elöbb mindenképpen teljesen, újrafordíthatóra vissza kell fejteni.
-
Kézzelfogható hardware mikor lehet belõle?
-
Kézzelfogható hardware mikor lehet belõle?
Tigriant kell kérdezni :-)
-
Beleraktam az FDISK-be, hogy ha nincs IDE vezérlõ akkor demo módban mûködik, fájlokból szimulálva a szükséges adatokat.
Így lehet ismerkedni a programmal :-)
Futatásához EPDOS 1.x szükséges! (SL,SS parancsok)
Mivel help még nincs, így néhány infó:
Nyitó képernyõn a felismert vinyók adatai láthatóak, méret, modelnév, sorozatszám (így 2 tök azonos vinyót is meg lehet különböztetni).
Vinyó kiválasztása után a 4 particó bejegyzés adatait láthatjuk, ill. ezek közül lehet választani a kurzorral. Alatta a szabad területek listája.
A kurzorral kiválasztott particiót tudjuk törölni Ctrl+Del-el. Ha üres (undefinied), akkor pedig a C megnyomásával tudunk létrehozni újat.
Létrehozásnál a szabad területek listájából választhatjuk ki, hogy hova szeretnénk tenni.
Ezután jöbb a program egyelõre még fapados része: meg kell adni a típusbájtot (1=FAT-12, 4=FAT-16, 6=BIGDOS, 12=FAT-32,stb), ha csak Entert nyomunk akkor 1, azaz FAT-12 lesz, mivel egyelõre ez lesz EP-n használva :-)
Utána a kezdõ szektort kell megadni, a kiválasztott szabad területen belül bárhol lehet, alapértelmezett a terület kezdõszektora.
Utána a méret, szektorokban megadva, alapértelmezett 65535.
Egyelõre még csak a 4 elsõdleges particiót lehet bizgatni, most jön majd az Extended kezelése (amit barmi logikátlanra sikerült megálmodni a Microsoftéknak...)
-
Egyelõre még csak a 4 elsõdleges particiót lehet bizgatni, most jön majd az Extended kezelése (amit barmi logikátlanra sikerült megálmodni a Microsoftéknak...)
Már ki tudunk listázni Exzended-et :-)
Bár senki nem kérdezte miért is logikátlan, mégis elmesélem, csak úgy az általános népmûvelés jegyében :)
Az elején kezdve: a vinyó elsõ (azaz 0-ás) szektora az ugynevezett Master Boot Record (MBR), ebbõl számunkra a 4x16 bájton elhelyezkedõ particiós tábla az érdekes.
Itt 4 elsõdleges (primary) particiót lehet létrehozni. Egy bejegyzés tartalmazza a partició típusát, kezdõ szektor sorszámát, és a méretet szintén szektorokban megadva. (Az õskövület CHS baromságokat most hagyjuk, EP-n ugyse foglalkozunk ilyen elavult baromságokkal :-) )
Valamikor úgy MS-DOS 3.1 környékén kezdték sejteni, hogy ez a 4 lehetséges bejegyzés kevés lesz, és kitalálták Extended DOS particiót.
Mondjuk én úgy csináltam volna, hogy a vinyó következõ szektorát is hozzácsapom az MBR-hez, abban elférne még 32 bejegyzés, amit bõven több mint szükséges, és marha egyszerûen megoldottuk a problémát...
Ehelyett úgy mûködik, hogy az Extended partició elsõ szektora egy újabb particiós táblát tartalmaz, az MBR-rel megegyezõ formátumban. (Ezt szokták EMBR-nek emlegetni). De az újabb 4 bejegyzésbõl csak kettõt használunk ki...
Az elsõ mutat a tényleges particióra, ezt nevezi a MS-DOS Fdisk logikai meghajtónak. Bejegyzésben szintén van típus, kezdõ szektor, méret.
Na itt van az elsõ marhaság, a kezdõ szektor nem a valódi kezdõ szektor száma! Hanem az EMBR-tõl számított távolsága! Vagyis, hogy ahhoz, hogy megtaláljuk a logikai meghajtó elsõ szektorát, össze kell adni ezt az értéket az Extended particiónk kezdetével.
De mi van, ha nemcsak egy logikai meghajtó van?
Ekkor jön a második bejegyzés: típusa Extended, a kezdõ szektor az elözõhöz hasonlóan az EMBR-tõl számított távolság, a méret pedig az elsõ logikai meghajtó után fennmaradt hely. Ez a bejegyzés mutat egy újabb EMBR-re.
Az elsõ bejegyzés mutat a logikai meghajtóra, viszont a kezdõ szektor már ettõl az EMBR-tõl van számolva! Vagyis a valódi szektor sorszámhoz úgy jutunk, hogy az elsõ EMBR-bõl kiszámoljuk a második helyét, és ahhoz hozzáadjuk ezt az értéket.
Eddigiek alapján ez végülis még logikusnak is nevezhetõ :-)
De az igazi meglepi akkor jön, ha van egy (vagy több) további logikai meghajtó is.
Ekkor a második EMBR második bejegyzése mutat a harmadik EMBR-re, ebbe nincs semmi meglepõ...
Amin kiakadtam: felrúgva az eddigi logikát, ennek a kezdõ szektora nem a második EMBR-hez képest van megadva! Hanem az elsõhöz!
Összefoglalva:
-az EMBR bejegyzései olyanok mint az MBR-é, de mégse, mert külön módszerrel kell számolgatni a kezdõ szektorokat.
-az egy EMBR 4 új bejegyzésébõl csak kettõt használnak ki (ill. az EP képes 4-et kezelni, akár fa szerû strukturát is lekövetni)
-egy EMBR két bejegyzése se egyforma, külön módszerrel kell számolni a kezdõ szektorokat.
Na ilyenkor szoktam fogni a fejemet, hogy Microsoft... és a CHS rémregényekrõl még nem is beszéltünk, az még egy külön értekezés lesz...
-
Zozo által tanultunk valami alapvetõt... :-)
(Köszi!)
Már nem lep meg, hogy ennyire túlkomplikálták ezt (is)...
-
Mivel most már aktuális a téma, így kezdetnek kiszedtem az általános szoftverfejlesztõs topicból az elõzményeket :-)
-
Mivel most már aktuális a téma, így kezdetnek kiszedtem az általános szoftverfejlesztõs topicból az elõzményeket :-)
Hmmm... ez a FDISK valóban béta változat. Ha partitiot törlök (ctrl+c) akkor ugyan törli, de invalid end of block hibaüzenettel leáll.
Ha új partitiot akarok létrehozni, akkor szintén leáll fenti hibaüzenettel, partitiot látszólag létrehozza, aztán formázási kísérleteknél invalid disk hibaüzeneteket küldözget.
-
Heuréka! Kisebb méretet megadva (jelen esetben 32000 szektor) már használható partitio jön létre, mûködik a format sõt az FDISK is a winyón van már! :lol: :lol: :lol: :lol: :lol:
-
Hogy kell használni az FDISK-et?
LOAD "FDISK.BAS" :-)
Indulás után ideális esetben látod a felismert vinyók listáját. Belsõ joy-jal mászkálsz, enter-rel belépsz a kiválasztott vinyóba.
Ekkor jön a particiós tábla, a 4 MBR bejegyzés között lehet mászkálni. Alul pedig a szabad területek listája.
Hogy lehet a jelenlegi BIGDOS partitiot törölni?
Ráállsz a kurzorral, és CTRL+DEL!
FIGYELEM!!! A program még nem tartalmaz semmilyen biztonsági funkciót, figyelmeztetéseket! Így a törlés szó nélkül végrehajtódik!
Szóval jól gondoljuk meg, milyen vinyón garázdálkodunk!
Hogy lehet FAT12 partitiot létrhozni????
Ráállsz egy unused MBR bejegyzésre, és C mint Create.
Ezután a szabad területek listájában lehet válogatni, hol helyezkedjen el.
A Type kérdésre 1-t kell megadni.
Start-ra meg kell adni a kezdõ szektor sorszámát. Az ellenõrizve van, hogy az elõzõleg kijelölt szabad területen belül van-e? Ha nem, akkor újra kérdez.
Size-re meg a méretet szektorokban, az ellenõrizve van, hogy nem-e lóg-e ki így a szabad területbõl. Ha kilóg, újrakérdez.
Fat 12 esetén a maximális mérethez 65535-t adjunk meg.
A kérdéseken Enter-rel is végig lehet lépegetni, akkor 1-es típus (FAT-12), a szabad terület elsõ szektorától, 65535 szektor méretû (vagy amennyi szabad) partició jön létre.
Ezután visszakerülünk a vinyólistába, újra belépve a vinyóba, már látszik az új partició a listában.
A jelen verzióban Extended particiókat még nem tudunk létrehozni.
Particionálás után hideg reset kell, ekkor már az EXDOS megkapja beláncolásra a particiókat, és lehet megformázni õket:
FORMAT F:
FORMAT G:
stb
-
de invalid end of block hibaüzenettel leáll.
Ha új partitiot akarok létrehozni, akkor szintén leáll fenti hibaüzenettel,
Igen, elöbb egy régebbi lett felrakva :-)
Ebben javítva van. (Egy END IF helyett volt END DEF)
-
Igen, elöbb egy régebbi lett felrakva :-)
Ebben javítva van. (Egy END IF helyett volt END DEF)
Jaj.... kipróbáltam az újabb FDISK-et, letöröltem a 2 meglévõ partitiot, hideg reset után meg hdd detectáláskor végtelen ciklusban detectálja újra meg újra a vinyót... :eek:
-
Következõ megjegyzés: az így létrehozott particiók, teljesen megfelelnek a szabványoknak.
Viszont a Microsoft szarik a saját szabványaira is (errõl már anno egy Enterpress cikkben elmélkedtem floppy lemez formátumok kapcsán...), így ezek a particiók PC-n, nem lesznek olvashatóak, legalábbis Microsoft operációs rendszer alatt! (Kiváncsi leszek, hogy Linux, OS/2, stb vajon mit szól majd ehhez...)
Errõl a problémakörrõl, majd még lesz egy hosszabb értekezésem itt :-)
Meg majd rohadt sok munka, hogy az egyszerû dologból rohadt bonyolult legyen, hogy a finyás windows is felismerje :(
Addig is PC-vel is olvasható particiót PC-n kell létrehozni, lehetõleg régi DOS-os bootlemezt és FDISK-et használva. De próbálkozni kell, mert az újabbak csak 16 mega alatti méretnél csinálnak FAT-12-t.
Sajnos az elterjedt partició buzeráló programok egyike se hajlandó FAT-12-t csinálni :-(
-
Jaj.... kipróbáltam az újabb FDISK-et, letöröltem a 2 meglévõ partitiot, hideg reset után meg hdd detectáláskor végtelen ciklusban detectálja újra meg újra a vinyót... :eek:
Na ettõl féltem! Hogy jönnek majd a felhasználók, és elkezdenek hibákat generálni :-)
Van másik vinyód kéznél? :-)
Erre most jobb ötletem nincs, mint PC-n letörölni :(
De nem ártana, ha eljutna hozzám legalább a tartalma (pl image fájlba lementve), hogy ki tudjam találni mi történt! Vagyis ha van másik, rakd ezt félre nekem :-)
-
Na ettõl féltem! Hogy jönnek majd a felhasználók, és elkezdenek hibákat generálni :-)
Van másik vinyód kéznél? :-)
Erre most jobb ötletem nincs, mint PC-n letörölni :(
De nem ártana, ha eljutna hozzám legalább a tartalma (pl image fájlba lementve), hogy ki tudjam találni mi történt! Vagyis ha van másik, rakd ezt félre nekem :-)
Ez az XP felismeri a lemezt, de nem rakja be a winyók közé, szóval a FAT-tal baja van, amin valahogy nem csodálkozom, elvégre magam hackeltem meg alaposan... image valószínûleg ugrott.
A winyó meg egy szép 325 Mbyte-os WD Caviar, pont EP-hez passzol. A másik egy 4 GByte-os Quantum, de azt most ki kéne ásni egy másik gépbõl... Na majd valamit kigondolok.
-
Winimage-val elvileg le tudod menteni imagefile-ba (lesz egy 325 megás file, de hátha össze lehet zippelni utána)
Utána meg ott XP alatt töröld le, particionáld meg XP módra, aztán kezdheted elölrõl a BIGDOS törléssel :-)
Aztán lássuk tudod-e reprodukálni a hibát :-)
-
Ez a partitionalás nekem még win alatt sem egyszerû.
Amit tettem:
Windows XP telepítõ CD-rõl indítok, elviszem a telepítést a partitionálás részig, létrehozok egy max. méretû partitiot, na itt megszakítom a telepítést, újraindítom a gépet immár windows CD nélkül, és láss csodát, a winyólistában továbbra sincs ott a jó öreg Caviar, de EP-n is marad a hibajelenség.... Talán segít, hogy minden érték 0-án áll a végtelen ciklusban a drive tulajdonságainál, mag kiírja hogy windows 95, ami a békebeli tartalma volt ennek a winyónak. Szóval sz@r van a levesbe' ...
-
Hoppla hopp. Mégis csak megjelent PC-n az a fránya Caviar, most formázom. Kíváncsi vagyok, mi lesz vele EP-n...
-
Ennél az XP -s módszernél tényleg sokkal egyszerûbb, ha mezei DOS lemezekkel, vagy pl. Win98 boot lemezzel indítasz, és FDISK -el particionálsz. De ha már mindenképpen win szörny, akkor legalább azon belül Partition Magic, vagy valami... (Utóbbinak DOS -os veriója is van.) Ez a Win lemezrõl boot -olás, és ott macera szerintem nem az igazi... Pláne, hogy XP, ami elég távol áll már "tõlünk", így amit az particionálás címén néha a vinyón elkövet...
-
PC-n onnantól kezdve, hogy túlléptek a FAT12-n, valószínüleg cluster méret optimalizálás okán, már 16M felett is FAT16-t hoznak létre a programok, nem is találtam egyetlen olyan programot se, ami engedné 32M-ig, vagy egyáltalán megkérdezné, hogy milyen FAT típusra gondolunk? (Csak nagyobb méreteknél lehet választani FAT32-t is)
Ami jó hír: ha 16 megás particiókat gyártunk, akkor még az XP is hajlandó FAT12-t létrehozni! Ezeket aztán kezeli a PC meg az EP is.
-
Jaj.... kipróbáltam az újabb FDISK-et, letöröltem a 2 meglévõ partitiot, hideg reset után meg hdd detectáláskor végtelen ciklusban detectálja újra meg újra a vinyót... :eek:
Gafz ezennel kiérdemelt egy bétateszter pirospontot a felfedezett bugért :smt023
A jelenség akkor lép fel, ha van vinyó a rendszerben, de nincs rajtuk egyetlenegy partició se. Ekkor elszabadul a IDE ROM partició listázó programja :oops:
Szerencsére nem végtelen ciklus, csak 256 :-) szóval sok türelem, és tovább megy :-) utána lehet FDISK-kel particiót csinálni, és megszünik a gond.
Az is megoldás, ha bekötünk még egy vinyót, amin van partició.
Következõ IDE.ROM-ban majd likvidálom a hibát :-)
-
FDISK v0.6
Felismeri a vinyóméretet olyan õs vinyóknál is, amik nem adják meg az identify device információs blokkban a 'current capacity in sectors' értéket.
Pl: Maxtor 7080AT 1990-bõl :-)
-
Hála a remek VHD-s mókának, végre egy este alatt sikerült kikísérletezni, hogy miért nem olvassa az MSDOS az EP-n formázott partíciót!
Na persze, hogy megint Bill bácsiék alkottak valami remek, szabványokat semmibe vevõ mókás operációs rendszert, hogy az a... :evil:
A PC-n amikor bootolásra használunk egy lemezt, akkor fogja beolvassa a boot szektort, és ráugrik az elejére. Mivel a szektor elején leginkább az adatok eléréséhez szükséges adatok vannak tárolva, ezért az elsõ pár bájton egy ugrás van, ami átugorja a logikai adatblokkot, és a további rendszertöltõ programra ugrik.
Az egyszerû naiv, szabványokat betartó programozó úgy gondolja, hogy neki ezzel az elsõ 3 bájttal nincs semmi dolga, ha nem akar boot programot írni. Benne is van az eredeti FAT szabványban, hogy "rendszernek fenntartva", tartalma nincs meghatározva:
[attachimg=1]
Ha nem foglalkozik vele az ember, akkor Bill bácsiék mûve ezt vágja az ember képébe:
[attachimg=2]
Hiszen ha az a 3 bájt nincs kitöltve, az olyan hatalmas helyreállíthatatlan hiba, ami megakadályozza az összes adat elérését...
Ha az elsõ bájton elhelyezünk egy EBH-t, a harmadikon pedig 90H-t, akkor végre megnyugszik, és hajlandó foglalkozni a lemezen lévõ adatokkal is.
Egyébként erre valószínüleg az IS fiúk is rájöhettek, mivel az EXDOS odarakja ezt... (egyébként anno a suliban ezek szerint ezért nem olvasta a sok hülye PC egyes Atari ST-n formázott lemezeket. EP természetesen igen :-) )
Na ha sikerült leküzdeni ezt a baromságot, még nem lehet hátradölni, ha elkezdenénk megnézni az EP-n feltöltött adatokat, akkor kiderül, hogy a hülye MS-DOS "természetesen" hibásan kezeli a lemezt...
Újabb több óra szívás után rá lehet jönni, hogy a formázó program nevének a végén a verziószámnak legalább 4.0-nak kell lenni! Ha 4-esnél kisebb szám van, akkor önkényesen kitalál saját logikai paramétereket, a boot szektorban megadott valódi paraméterekre meg nagy ívben tojik...
Egész pontosan a pont meglétét, és az elõtti karakter értékét nézi a rohadék.
Ezekután itt egy újabb IDE ROM, amivel már MS-DOS kompatibilis boot szektort lehet formázni. Legalábbis MS-DOS 5.0-val már jó :-) a többi mindenféle DOS meg WIN még ellenõrzésre vár.
-
Ha az elsõ bájton elhelyezünk egy EBH-t, a harmadikon pedig 90H-t, akkor végre megnyugszik, és hajlandó foglalkozni a lemezen lévõ adatokkal is.
Ebbõl a 90H az egy NOP, hát ez az tényleg létfontosságú...
Újabb több óra szívás után rá lehet jönni, hogy a formázó program nevének a végén a verziószámnak legalább 4.0-nak kell lenni!
Pontosítás, már a 3.1 is jó. A valódi ellenõrzésnél azt nézi, hogy a verziószám elsõ két karaktere nagyobb-e mint 2E33H, ha igen akkor jó, ebbõl következik ha pont helyett nagyobb kódú karakter van, pl _ akkor be lehet írni kisebb verzió számot is ilyen formában: 1_0
Ha 2E33H az érték (vagyis 3.), akkor vizsgálja a következõ karaktert, hogy nagyobb-e mint "0"?
-
Pontosítás, már a 3.1 is jó. A valódi ellenõrzésnél azt nézi, hogy a verziószám elsõ két karaktere nagyobb-e mint 2E33H, ha igen akkor jó, ebbõl következik ha pont helyett nagyobb kódú karakter van, pl _ akkor be lehet írni kisebb verzió számot is ilyen formában: 1_0
Akkor ezek szerint ez is jó: 0EBh, 3Ch, 90h, "mkdosfs" :)
PC-n onnantól kezdve, hogy túlléptek a FAT12-n, valószínüleg cluster méret optimalizálás okán, már 16M felett is FAT16-t hoznak létre a programok, nem is találtam egyetlen olyan programot se, ami engedné 32M-ig, vagy egyáltalán megkérdezné, hogy milyen FAT típusra gondolunk? (Csak nagyobb méreteknél lehet választani FAT32-t is)
Ami jó hír: ha 16 megás particiókat gyártunk, akkor még az XP is hajlandó FAT12-t létrehozni! Ezeket aztán kezeli a PC meg az EP is.
Én az mkdosfs-t használtam (Linux alatt), azzal be lehetett állítani FAT12-t 32 MB méretű partíciónál is.
-
Ezekután itt egy újabb IDE ROM, amivel már MS-DOS kompatibilis boot szektort lehet formázni. Legalábbis MS-DOS 5.0-val már jó :-) a többi mindenféle DOS meg WIN még ellenõrzésre vár.
Azt még meg lehetne nézni, hogy a hibakezelés miért nem működik az emulátorral :?: Bár lehet, hogy ez emulátor hiba miatt van; azt már tudom, hogy a READ/WRITE MULTIPLE az emulátorban nem jó (ha a ROM működik is), de ennek nem feltétlenül van jelentősége ezzel a problémával kapcsolatban.
Még egy lehetséges változtatás: az írás és olvasás sebességét kis mértékben javítani lehetne az alábbihoz hasonló részek (READ, READ MULTIPLE, WRITE) módosításával:
RDCIKS: PUSH BC
EXX
LD B,0
LD C,(IX+COMB)
EXX
LD C,(IX+DLB)
LD A,RD+DATA
EX AF,AF'
LD A,RD+WR+DATA
EXX
RDCIK: EX AF,AF'
OUT (C),A
EX AF,AF'
OUT (C),A
EXX
INI
INC C
INI
DEC C
EXX
DJNZ RDCIK
EXX
CALL ERRORKERD
POP BC
RDCIKS: PUSH BC
LD B, 0
LD A, (IX+DLB)
EXX
PUSH BC
PUSH DE
LD B, 2
LD C, (IX+COMB)
LD DE, (RD+DATA)*257+WR
RDCIK: OUT (C), D
OUT (C), E
EXX
LD C, A
INI
INC C
INI
EXX
OUT (C), D
OUT (C), E
EXX
LD C, A
INI
INC C
INI
EXX
JP NZ, RDCIK
DJNZ RDCIK
POP DE
POP BC
EXX
CALL ERRORKERD
POP BC
így ugyan valamivel nagyobb lenne, de a ROM nagy része egyébként is üres. Igaz, a gyorsulás sem túl jelentős, egy 720K körüli méretű file másolása 19s helyett 16-17s lett. A BC' és DE' mentése nem biztos, hogy kell; lehet, hogy a PUSH/POP utasítások törölhetőek.
-
A türelmeteket eszelõsen irigylem! ;-) Mikre rá nem jöttök már, õrület! :lol:
-
Azt még meg lehetne nézni, hogy a hibakezelés miért nem mûködik az emulátorral :?:
Leginkább azért mert még nincs hibakezelés :oops: elsõdleges cél, hogy hibátlan vinyóval jól mûködjön, aztán foglalkozunk a problémás esetekkel :-)
-
Na megnéztem, MS-DOS 5.0, 6.0, 6.2, 6.21, 6.22, 7.0, 7.1, 8.0 mindegyik ugyanarra kényes a boot szektorban.
-
Na megnéztem, MS-DOS 5.0, 6.0, 6.2, 6.21, 6.22, 7.0, 7.1, 8.0 mindegyik ugyanarra kényes a boot szektorban.
Remek... Akkor legalább következetesen voltak hülyék Redmondban... :smt043
-
Remek... Akkor legalább következetesen voltak hülyék Redmondban... :smt043
Voltak hülyébbek is: MS-DOS 4 ami nagyobb bukás volt mint a Windows ME és a Vista együtt véve :-), annyi adatvesztéssel járó hiba volt benne, hogy az emberek inkább ráfizettek, hogy 3.3-as DOS-t kapjanak... (http://everything2.com/title/MS-DOS%25204.0)
Annyira vacakra sikerült, hogy eddig nem is sikerült komplett példányt felkutatnom belõle :( amit találtam több helyen MS-DOS 4.0-nak nevezett csomagot abban is a 4.01-es IO.SYS és MSDOS.SYS van 1989.04.07-es dátummal. Tud valaki eredeti 1988-as 4.0-ás rendszerfájlokat?
A 4.01-et megvizsgálva még durvább dolog derül ki: nemcsak a verziószámos móka van benne, hanem azt is nézi, hogy MSDOS-e a rendszer neve? Ha nem akkor nem a boot szektorba írt logikai adatok alapján kezeli a lemezt, hanem Microsoftos szokás szerint saját kitalált adatok alapján.
És ha ez nem egyezik a lemez valódi logikai adataival, akkor gyorsan adatvesztés, fájlrendszer összeomlás lesz a vége. (Ugyan ez az újabb verzióknál is fent áll, ha nem stimmel a verziószám az izlésének!)
Ilyen súlyos hibáért programozás órán akkora egyest adnának, hogy kilóg a naplóból!
Itt még azért is durva a dolog, mert ekkoriban a Microsoft operációs rendszer koránt sem volt egyeduralkodó, gépeknek legalább a felén PC DOS volt, és volt DR-DOS meg egyebek is.
Még emlékszem is, anno 90 körül mikor kezdtünk ismerkedni a PC-vel az volt a vélemény, hogy IBM PC kompatibilis gépre IBM PC DOS való, MS-DOS csak valami gagyi utánzat valami nevesincs cégtõl :ds_icon_cheesygrin:
Mindenesetre az 5.0-ból már kiszedték ezt az MSDOS string ellenõrzést, õk is rájöhettek, hogy ez így nem kóser :-)
4.01-ben még nincs ez az EBH,xx,90H ellenõrzés.
-
Tök jó, hogy Te miket tudsz a múltból (is)... :)
-
PC-DOS, azért látszik, hogy végül is ezt az MS írta :-)
5.0-tól felfelé ugyanaz vonatkozik erre is mint az újabb MS-DOS-okra.
4.0 hasonló az MS-DOS 4.01-hez verziószámos móka van, EBxx90 nézés nincs, viszont a formatáló program nevének "IBM "-nek kell lenni, különben Invalid media type hibaüzenet. (Legalább nem áll neki hibásan kezelni mint MS-DOS 4.0)
3.3 EBxx90 nézés nincs, verziószámnak 3.1-3.9 között kell lenni, különben hibásan kezeli, formatáló programnak "IBM "-nek kell lenni, különben hibásan kezeli.
Néztem MS-DOS 3.3-at is, azt még nem tudtam rávenni, hogy figyelembe vegye a boot szektor adatait...
Novell DOS 7.0: formatáló program neve, verziója nem számít! Végre egy normális DOS :-) kicsit ront a képen, hogy EBxx90 hiányában hibásan kezeli a lemezt.
-
FreeDOS 1.0: nincs semmilyen vacakolás!
Lassan jöhet a Windowsok tesztelése, csak az macerásabb, nem elég egy boot floppy...
-
Lassan jöhet a Windowsok tesztelése, csak az macerásabb, nem elég egy boot floppy...
Win2000: EBH-t nézi, anélkül azt mondja nem felismerhetõ a fájlrendszer. A 90H nélkül megy, de a CHKDSK kiakad, hogy ismeretlen hiba. Formázó program neve, verziója nem érdekes.
Win95: Csak parancssor módban már kiveséztük mint MS-DOS 7.0, A Win futása alatt EB-90-et néz, nélküle hibaüzenet. Formázó név, verzió nem számít. Érdekes, hogy a Win95 kilépés menübõl indított DOS módban, ugyanez érvényes, pedig az elején F8-al indított DOS módban még számít a formázó program verziója.
És itt találtam egy érdekességet: Win 95/98/ME sunyi módon beleír a floppy lemezek boot szektorába, még egy egyszerû olvasás esetén is! És a nevet, verziószámot, más "kriksz-kraksz"-ra cseréli ki! Ami azt eredményezheti, hogy legközelebb valós DOS alól nézve már lehet, hogy hibásan lesz kezelve a lemez, hiszen láttuk, hogy a DOS-ok túlnyomó többségénél, ha nem tetszik a verziószám, akkor nem veszik figyelembe a boot szektor logikai paramétereit.
Hivatalos Microsoft leírás. (http://support.microsoft.com/kb/148637)
Nem hivatalos leírás. (http://www.ibiblio.org/pub/micro/pc-stuff/freedos/win9x/README.TXT)
Registry fájl a javításhoz. (http://www.filewatcher.com/m/NOVOLTRK.ZIP.18381.0.0.html) (Bár az EP-s azonosítókat még bele kéne tenni :-) )
-
Más is rájött (http://medical.nema.org/dicom/2007/07_12pu.doc), hogy a Microsoft programozók hülyék:
1. These three bytes should either be EBH,00H,90H (indicating a relative jump) or 909090H indicating NOPs. The bytes are for booting off the optical drive which DICOM does not standardize. Some programs use them to validate the disk. The use of EB0090H is known to be more commonly used and is the recommended choice. Readers of DICOM disks that use the PC File System should ignore this field.
2. While eight characters appear to be valid in this field, the use of “MSDOS4.0” is known to be the preferred choice for this string. Some systems, upon finding this field not set to “MSDOS4.0” will ignore the sectors/FAT field and use their own calculation. This may cause an error due to the calculation resulting in a different value than the sectors/FAT field.
Megjegyzés nem csak a sector/fat-ot hagyja ilyenkor figyelmen kívül, hanem a fõkönyvtár méretet is, sõt szerintem minden logikai paramétert, de ezt még tesztelni kell.
-
Win2000: EBH-t nézi, anélkül azt mondja nem felismerhetõ a fájlrendszer. A 90H nélkül megy, de a CHKDSK kiakad, hogy ismeretlen hiba. Formázó program neve, verziója nem érdekes.
NT4.0 detto. Remélhetõleg XP, VISTA, Win7 esetén se cifrázták...
-
Egy lehetséges probléma:
LD B,0
DCIK: LD A,RD+DATA
CW
DLR
LD (HL),A
INC HL
DHR
LD (HL),A
INC HL
DJNZ DCIK
EI
RET
ATA-5 vagy újabb interface esetén az IDENTIFY DEVICE az utolsó 2 byte-ban egy ellenőrző összeget tárol, ezért ilyenkor az A regiszter visszatérésnél nem mindig 0 lenne, és nem működne az :IDEIDENTIFY parancs. Vagy ennek nincs jelentősége, és az emulátorban maradjon 0 az utolsó 2 byte :?:
-
NT4.0 detto. Remélhetõleg XP, VISTA, Win7 esetén se cifrázták...
Nem cifrázták, ugyanaz :-)
Akkor a boot szektor kérdése úgy tûnik kitárgyalva, jöhet a particiós tábla, különös tekintettel az extended mókára... itt is lesznek nagy szívások a Microsoft "szabványkövetõ" programozói miatt...
-
ATA-5 vagy újabb interface esetén az IDENTIFY DEVICE az utolsó 2 byte-ban egy ellenõrzõ összeget tárol, ezért ilyenkor az A regiszter visszatérésnél nem mindig 0 lenne, és nem mûködne az :IDEIDENTIFY parancs.
Ok, bettem egy XOR A-t, addig is amíg nem lesz rendes hibakezelés :-)
-
Még egy lehetséges változtatás: az írás és olvasás sebességét kis mértékben javítani
Beépítettem ezt is.
Kisebb javítás még, hogy a 32 bites lemezazonosító számot beírja a PC-s helyére is.
-
Ott tartunk, hogy egy megfelelõ helyen elhelyezett EP által létrehozott 32M partíciót, rendben kezel az MS-DOS 6.2 és XP (remélhetõleg a többiek is :-) )
Már csak azt kell kitalálni, hogy a Microsoft kényes ízlésének pontosan milyen néhány elhelyezés felel meg a szabvány által elképzelhetõ rengeteg variációból...
-
Beépítettem ezt is.
Kisebb javítás még, hogy a 32 bites lemezazonosító számot beírja a PC-s helyére is.
Ezt a verziót már beépítsem egy új ROM csomagba, vagy még várható valamilyen fontos változtatás ?
-
Ezt a verziót már beépítsem egy új ROM csomagba, vagy még várható valamilyen fontos változtatás ?
Most épp a partíció detektálás alakul a legújabb tapasztalatok alapján. Pl. kiderült, hogy az XP-nek néha sikerül nem FAT12 típusú partíciónak jelölni a FAT12 partíciót...
-
Most épp a partíció detektálás alakul a legújabb tapasztalatok alapján.
Ez még alakul, de addig is egy kisebb, de fontos javítás: most már mûködik RL NEW után is a vinyókezelés. Vagyis sok ROM-os gépen is elindítható a SmallDemo, ha írtunk egy kicsit a ZT RL parancsával.
-
Ez még alakul, de addig is egy kisebb, de fontos javítás: most már mûködik RL NEW után is a vinyókezelés. Vagyis sok ROM-os gépen is elindítható a SmallDemo, ha írtunk egy kicsit a ZT RL parancsával.
Ez a verzió már kiadható ?
-
Ez a verzió már kiadható ?
Ezt már talán igen, ha nem rontottam el semmit :oops:
Felismeri a mindenféle hidden, LBA, stb FAT particiókat is. A boot szektorban ellenõrzi a fájl rendszer azonosítóját, hogy FAT12-e, ha igen, akkor a partíciós táblában megadott típustól függetlenül FAT12-nek veszi. Így felismeri a nem FAT12-nek jelölt FAT 12-t is. Ilyen keletkezhet pl akkor ha 8 giga feletti részre csinálunk az XP-vel 16 megás partíciót. 8 giga felett az LBA címzéses partíciók használhatóak, viszont a FAT12-nek nem csináltak külön típust... ezért rejti egy BIGDOSX típusú particióba ilyenkor a FAT12-t az XP.
Ezenkívül módosítva a partíciók sorba vétele, optimális esetben ugyanaz lesz a sorrend mint MS-DOS esetén, persze EP-n F-tõl kezdõdõen.
Memóriakezelésen kell majd még gyúrni, ha jól számolom most 12 partíció felett fog jól elszállni :oops:
-
Lehet, hogy hamarosan megint cserélni kell a ROM csomagot :( :oops: Úgy látszik, az új IDE.ROM nem találja meg az összes partíciót az ide126m.vhd-n (vagy csak én rontottam el valamit ?).
Javítva :oops:
-
Memóriakezelésen kell majd még gyúrni, ha jól számolom most 12 partíció felett fog jól elszállni :oops:
Egy kicsit alakítottam rajta, hogy ne szálljon el :-) Most 15 partíciót (F:-T:) kezel max, a korábbinál valamivel kisebb RAM igénnyel, így a Small Demo is fut több ROM mellett.
Remélem közben nem rontottam el semmi :oops:
-
ATA-5 vagy újabb interface esetén az IDENTIFY DEVICE az utolsó 2 byte-ban egy ellenõrzõ összeget tárol, ezért ilyenkor az A regiszter visszatérésnél nem mindig 0 lenne, és nem mûködne az :IDEIDENTIFY parancs.
Igazad volt, most kipróbáltam egy 120 gigás vinyóval, és tényleg kiakadt a régi ROM-mal az FDISK, az újjal már jó :-)
-
Kicsit javítgatott FDISK, fõképp optikai tuning :-) egy, tíz, sok száz gigás vinyó esetén se tolódjanak ide-oda a kijelzett értékek.
Törlésnél már rákérdez :-)
-
Egy kicsit alakítottam rajta, hogy ne szálljon el :-) Most 15 partíciót (F:-T:) kezel max, a korábbinál valamivel kisebb RAM igénnyel, így a Small Demo is fut több ROM mellett.
Remélem közben nem rontottam el semmi :oops:
Új IDE.ROM várható ezen a héten ? Ha nem, akkor frissítem a ROM csomagot ezzel a verzióval.
Az emulátor elvileg már készen áll a kiadásra, csak még megvárom, amíg Attus teszteli a fordítást a különböző Linux disztribúciókon :)
-
Új IDE.ROM várható ezen a héten ? Ha nem, akkor frissítem a ROM csomagot ezzel a verzióval.
Ha más hibát nem találtatok, akkor most a 48bites LBA jön, hamár szépen felismeri a 400 gigás vinyót is, kezelje rendesen :-)
De ez végülis az emulátor szempontjából nem lényeges.
Egy apróság a ROM konfigokhoz, egyelõre az IDE legyen magasabb szegmensszámon mint a ZT, hogy ne tûnjön el a ZT óra.
-
Egy apróság a ROM konfigokhoz, egyelõre az IDE legyen magasabb szegmensszámon mint a ZT, hogy ne tûnjön el a ZT óra.
Javítva a CVS-ben, áthelyeztem a 42h szegmensre (a ZT 40h/41h-n van).
Közben találtam egy lehetséges ZozoTools problémát (amelyet részben a korábbi LPT javítás okoz :oops:): a BRD/ESP/HUN ROM módosítja az LPT-t, és ezért ilyenkor az óra pozíciója más, illetve 318 soros lesz az LPT:
UK:
>BAC0 F4 92 3F 00 00 00 00 00 :t.?.....
>BAC8 00 00 00 00 00 00 00 00 :........
>BAD0 FD 10 3F 00 00 00 00 00 :}.?.....
>BAD8 00 00 00 00 00 00 00 00 :........
>BAE0 FC 10 06 3F 00 00 00 00 :|..?....
>BAE8 00 00 00 00 00 00 00 00 :........
>BAF0 FF 10 3F 20 00 00 00 00 :..? ....
>BAF8 00 00 00 00 00 00 00 00 :........
>BB00 FC 12 06 3F 00 00 00 00 :|..?....
>BB08 00 00 00 00 00 00 00 00 :........
>BB10 E4 12 3F 00 00 40 00 00 :d.?..@..
>BB18 00 00 00 00 00 00 00 00 :........
>BB20 F8 09 16 68 2C FB E9 01 :x..h,{i.
>BB28 00 DB 00 00 32 32 BA 35 :.[..22:5
HUN:
>BAC0 F4 92 3F 00 00 00 00 00 :t.?.....
>BAC8 00 00 00 00 00 00 00 00 :........
>BAD0 FD 10 3F 00 00 00 00 00 :}.?.....
>BAD8 00 00 00 00 00 00 00 00 :........
>BAE0 FE 10 06 3F 00 00 00 00 :~..?....
>BAE8 00 00 00 00 00 00 00 00 :........
>BAF0 FC 10 3F 1C 00 00 00 00 :|.?.....
>BAF8 00 00 00 00 00 00 00 00 :........
>BB00 F0 12 06 3F 00 00 00 00 :p..?....
>BB08 00 00 00 00 00 00 00 00 :........
>BB10 EB 12 3F 00 00 40 00 00 :k.?..@..
>BB18 00 00 00 00 00 00 00 00 :........
>BB20 F8 09 16 68 2C FB E9 01 :x..h,{i.
>BB28 00 DB 00 FF 32 32 BA 34 :.[..22:4
-
Úgy látszik, a BRD másodpercenként 50-szer felülírja az LPT végén a szinkron részt (talán azért, mert a módosított LPT "szabványosabb", és az eredeti EXOS LPT nem működött egyes TV-ken, és ezért van a német gépeken ez a "javítás" :?:) :ds_icon_frown:
Tehát a ZozoTools akkor lenne "BRD kompatibilis", ha csak BAC0h-ra írna FAh-t F2h helyett, és BB10h-t nem változtatná. Ez gyakorlatilag ugyanaz a megoldás, mint a régi verzió, csak javítja a 313 sor hibát.
De a BRD/ESP/HUN LPT felülírása is letiltható E50Ch-ra két 0 byte-ot írva, viszont az akkor eltérne az eredeti gépeken használt ROM-októl.
-
Úgy látszik, a BRD másodpercenként 50-szer felülírja az LPT végén a szinkron részt (talán azért, mert a módosított LPT "szabványosabb", és az eredeti EXOS LPT nem mûködött egyes TV-ken, és ezért van a német gépeken ez a "javítás" :?:) :ds_icon_frown:
Most, hogy mondod, kezd rémleni, hogy ezzel a felülírás problémával találkoztam anno, mikor készült az óra program!
-
Egy apróság:
Ha az FDISK nem talál HDD-t, kiír egy hibaüzenetet, rögtön törli a képernyőt, majd befejeződik a program futása. Az üzenetet inkább képernyőtörlés után kellene kiírni, hogy el lehessen olvasni.
-
kiír egy hibaüzenetet, rögtön törli a képernyõt, majd befejezõdik a program futása.
Ez a módszer a Microsofttól lett átvéve :ds_icon_cheesygrin:
-
Ez a módszer a Microsofttól lett átvéve :ds_icon_cheesygrin:
:smt082
-
Ez a módszer a Microsofttól lett átvéve :ds_icon_cheesygrin:
Kék képernyõ nem lesz? :D
Bár az elég talán a DOS ablakban is. Hogyan számol a spanyolos DOS felhasználó? uno DOS tres.
-
Ez a módszer a Microsofttól lett átvéve :ds_icon_cheesygrin:
:smt043
Ez jó... A hónap poénja!
Javaslom a program végén a következő kis gépi kódú rutint:
DI
HALT
És hogy Microsoft-kompatibilisek legyünk: a ZozoTools-ban a funkcióbillentyűk definiálásának befejezése után szólítson fel a program a gép újraindítására...
-
Most, hogy mondod, kezd rémleni, hogy ezzel a felülírás problémával találkoztam anno, mikor készült az óra program!
ZozoTools javítás ? :) Vagy maradhat így, és akkor csak az IDE.ROM-ot cseréljem az aktuális verzióra :?:
-
ZozoTools javítás ? :)
Javítva :oops:
-
Egy apróság:
Ha az FDISK nem talál HDD-t, kiír egy hibaüzenetet, rögtön törli a képernyõt, majd befejezõdik a program futása. Az üzenetet inkább képernyõtörlés után kellene kiírni, hogy el lehessen olvasni.
Ez is javítva :oops:
-
Ha jól értem az eddig leírtakat, extended partíciót még nem tudunk létrehozni, törölni?
Pfff... Egyébként érdekes, hogy Win98 alól kipróbáltam a PQ Magic 4-et (!) de FAT12-őt az sem tud kreálni.
-
Ha jól értem az eddig leírtakat, extended partíciót még nem tudunk létrehozni, törölni?
Igen :oops:
Pontosabban ki tudjuk törölni az egészet, de egyes logikai meghajtókat még nem.
Ha rányomunk egy Entert-t az extended-re, akkor a meghajtókat kilistázza.
-
Raktam fel az oldalra egy 126 megás vhd file-t. Ami menet közben kiderült:
ISDOS-t nem tudja a gép betölteni sem floppy-ról, sem HDD-ről. ha kiveszem az IDE.ROM-ot, ugyanaz a floppy működik.
Sajnos semmi perc alatt tönkrevágtam EPDOS-ból egy fél particiót. Sok mindent nem csináltam, némi MOVE, DELETE, ORDER elég volt hozzá... :(
Feltöltöm majd a hibás file-t. Sajnos ráeresztettem egy CHKDSK-t, így már nem lesz látható a a rengeteg WRONG CLUSTER, WRONG CLUSTER SIZE hibaüzenet, de a MBTMUSIC könyvárban gyanúsan sok lett a 8k-s méretű file...
-
Végre egy béta teszter aki nem lustálkodik, hanem tesztel :-)
-
Sajnos semmi perc alatt tönkrevágtam EPDOS-ból egy fél particiót.
Felraktam a sérült "meghajtót":
www.ep128.hu/ide126_corrupt.rar (http://www.ep128.hu/ide126_corrupt.rar)
-
Sajnos semmi perc alatt tönkrevágtam EPDOS-ból egy fél particiót. Sok mindent nem csináltam, némi MOVE, DELETE, ORDER elég volt hozzá... :(
Remélhetőleg nem emulátor bug :) :oops:
-
Zozo!
- A honlaprólletölthető (elveileg jó) VHD file H meghajtójára eressz rá egy CHKDSK-t!
- Próbálj bármelyik meghajtón EPDOS-ból létrehozni egy új könyvtárat. (Utána az ESC megnyomásával fűszerezhetjük az élményt.
- Ha file-t a akrom másolni A-ról HDD-re (EPDOS-ból), a könyvtár struktúra helyett egy ERROR CODE 155-öt kapok.
-
ISDOS probléma megoldva: csak gyökérkönvtárból működik... :oops:
-
Az emu-rovatban kicseréltem a disk image-et. A CHKDSK-tól megbolonduló partícióról letöröltem mindent és vissza másoltam. (Win98 alól.) Még megpróbálom reprodukálni a tegnapi hibát...
-
Sajnos semmi perc alatt tönkrevágtam EPDOS-ból egy fél particiót. Sok mindent nem csináltam, némi MOVE, DELETE, ORDER elég volt hozzá... :(
Hasonló problémával én is találkoztam EPDOS 1.9 alatt: az ORDER-t próbáltam használni egy nagy (16 MB) floppy image-n, és ez elrontotta a file rendszert :oops:
-
Igen, még a törlés (DELETE) is rizikós.
-
Újabb IDE ROM, módosított RAM kezeléssel: 128K-nál több memória esetén saját szegmenst foglal, így nem fogy az értékes hely a rendszerszegmensben. Ehhez a módhoz EXOS 2.1-nél újabb kell, mert mint korábban említettem a 2.0 és a 2.1 bugos abban az esetben, ha nem a rendszerszegmensben kér a bõvítõ RAM-ot.
Természetesen ellenõrzi az EXOS verziót az IDE ROM.
Tessék tesztelgetni, mit rontottam el közben :oops:
-
nade ezt be kene tegyem az epromba, nem ?
vagy van valami szuper tool amivel felul lehet irni az- epben az eprom tartalmat ? vagy mi ?
-
Egyelõre emulátorban tessék nézegetni, aztán ha mûködõnek tûnik, majd kapsz új epromot.
(Minden rendes háztartásban van EPROM égetõ :ds_icon_cheesygrin: )
-
Tessék tesztelgetni, mit rontottam el közben :oops:
Lehet, hogy ez eddig is benne volt:
Egy könyvtárat akartam EPDOS-ban átmozgatni egyik partícióról a másikra, de belefagyott. Pontosabban sokáig várt (világitó LED-del), utána újraindult a gép. Mindez Ep128emu-ból 640k_EXOS231_IDE_utils konfiggal.
-
olyant nem tunnal megcsinalni, hogy ezek a rom file- ok kilancoljak az epromba levo bovitot, es belancoljak magukat a floppyrol vagy winyorol ?
es akkor hw ep- n is lehetne hasznalni oket egybol, amig nincs az epromban cserelve a katyvasz ... ezzel hw- n is naprakeszen lehetne tesztelni ...
mert ugye bovitett gepekben van lenne ram az ilyen frissverzios .rom file- oknak ...
es akkor mondjuk exdos.ini -ben bene lenne hogy :zt override ide.rom "a:\ide.rom"
vagy valami ilyen, es hopp mar is a legfrisebbet hasznalnam, nem pedig ami az epromban van ...
-
Megnéztem: az előzőben is benne van ez a hiba.
-
Egy könyvtárat akartam EPDOS-ban átmozgatni egyik partícióról a másikra, de belefagyott. Pontosabban sokáig várt (világitó LED-del), utána újraindult a gép. Mindez Ep128emu-ból 640k_EXOS231_IDE_utils konfiggal.
Ez szerintem EPDOS 1.9 beta bug lesz :oops:
-
zozo,
ha epdosban f1- gyet nyomok az ide.rom -ra, akkor betolti, es leinicializalodik, detektal winyokat szinesben, meg minden,
es utana 2 epide.rom lesz a :rl - ben,
namost ha eloszor :rl 32h -t mondok akkor csak egy lesz, az 1.1 !
csak egy baj van. a :load azt irja ki az ide.rom -ra hogy
invalid file header
es nem tolti be, nem inicializalja le.
miert ? pedig akkor lehetne ugy tolni ahogy mondtam ...
-
csak egy baj van. a :load azt irja ki az ide.rom -ra hogy
invalid file header
es nem tolti be, nem inicializalja le.
LOAD-dal nem lehet ROM-ot tölteni, arra az EPDOS LROM parancsa való.
-
mar csak :) 2 baj van :
egyreszt az
:rl 32h
*** error 244
-et ad vissza ki az exdos.ini -bol, bar elvegzi a funkciojat, de attol meg kiirja ...
a nagyobbik baj, meg hogy ha az epdosban adom ki az f1- gyet az ide.rom -ra, akkor az leinicializalja az uj ide.rom -ot, de nem futtatja le az exdos.ini -t,
ha meg az exdos.ini -ben van a :lrom "a:\ide.rom" akkor miutan leinicializalodott az uj ide.rom, lefut az exdos.ini ujra es ciklikusan megy az egesz ...
talan a :epdos az exdos.ini vegen a baj ? de hataz kene oda, hogy elinduljon az epdos ...
-
nem nem az epdos a baj, kiszedtem es akkor ugyanugy lefut ujra az exdos.ini, csak a basic jon be,
az a baj hogy az uj ide.rom inicializalasa utan az ENTERPRISE felirat jon be,
mig EPDOS eseteben visszakapom az EPDOS- t.
-
es ha csak irok egy masik init newide.ini neven,
:rl 32h
:lrom "a:\ide.rom"
tartalommal, es mikor normal modon bejott az epdosom, akkor
:exdos a:\newide.ini
sem fut le rendesen, olyan mintha lefutna visszajon az epdos, csak nem inicializalodik le az uj ide.rom, nem lesznek winyok,
de mikor megegyszer beirom, kozvetlen utana, akkor mar leinicializalodik es vannak winyok ...
-
Kaptál bele F-es EXDOS.INI nézést :-) így ha ott talál valamit, akkor meg tudod törni a végtelen ciklust.
-
de ez csak azert fog mukodni, mert ide 1.0 van most nekem, es abba nincs meg f nezes,
de ha majd ma 1.1 ( f-et is nezos ) lesz az epromomban, akkor majd mar megin nem tok az ujabb verziora ( pld. 1.2 , 1.3 ) atvaltani betolteses modon ... igaz ?
szal ezzel nem megoldottuk, csak kikerultuk a bajt... nem ?
-
szal ezzel nem megoldottuk, csak kikerultuk a bajt... nem ?
Írsz egy gépi kódú programot ami lekérdezi az rom verzióját, és aztán annak függvényében hívja az LROM-ot :-)
-
ha kiveszem az eprom foglalatbol az
ide
epdos1.9
feliratu epromot,
akkor ha letezne olyan epdos, ami rendes rendszerbovito,
es azt betoltenem floppyrol az exdos.ini -be,
utana mar be tudnam tolteni lrom. mal az uj ide.rom -ot, nem ?
vagy van abban meg mas is ?
-
aaaaaaaa, hulyeseg ... hat az nem fogja megoldani a ciklikussagot ...
hagyjuk ...
-
Egyelõre arra tessék koncentrálni, hogy ez az 1.1-es jól mûködik-e, nem-e lett elrontva valami a nagy átalakításban!
-
Hat jo... :( megcsinaltam igy, hogy 2 exdos ini van, ami a winyon van az teszi meg azokat amiket kene neki eredetileg is,
es a floppyn levo csak atvaltja az ide romot. De nem nagyon tetszik ez a megoldas.
Viszont szerintem az epdos az nem annyira lett jovobe nezoen megirva ...
Pld. at akartam masolni F: -ra azt az exdos.ini -t ami oda kell, es akkor mikor mondom az epdosnak hogy copy,
akkor ugye nekiallna generalni egy fat az F:- rol ( ami ugye a hivatalos winyo image egy csomo jatek konyvtarral ),
es a fa mar nem jelenik meg, elfagy a generalasban valahol ...
ugyanez egy sima :copy - val az exdosban siman muxik...
szal ha vki biztonsagban akar winyon nyomulni, az batran hasznaljon exdos parancsokat,
mer sztm az epdos az nem birja kezelni a winyohasznalattal megnovekedett konyvtar es/vagy file szam / ossz file nev hossz novekedest.
-
hühühühűűűű :cry:
es raadasul egy sima hidegresetnel visszalancolodik a regi romban levo ide.rom is ... :(
hat en ugy latszik majd akko betatesztelek, ha mar final es epromban van ... :)
-
zozo mier hasznalunk meg mindig epdos 1.9 -et ha van 2.1 is,
es hol van ennek az 1.9 -nek a bovitos verzioja,
mert ha az epdos- ban van a rom loader,
akkor az epdos maga nem lehet .rom- ban csak bovitoprogiban, nem ?
-
Na jo, vili, azer 19, mer az egy 1.8+winyo, de az EPDOS -bol sosem volt bovitos verzio, csak rom ?
-
Na jo, vili, azer 19, mer az egy 1.8+winyo, de az EPDOS -bol sosem volt bovitos verzio, csak rom ?
1.7-bõl még volt.
-
nincs kulon olyan extension ami csak egy rom loader ?
es akkor kiszednem az epromot, es floppyrol lefutna az exdos.ini, abbol pedig a romtolto bovito, aztan johetne az epdos.rom utana az uj ide.rom, es annak hatasara meg az F:- rol az igazi beallitasokat tartalmazo exdos.ini,
es lenne egy franko rendszerem, esmivel teljesen ide nelkul indul, ezert kompatibilis a modszer az osszes tobbi ide.rom verzioval is.
-
tulajdonkepp ez lenne a kulcs ...
ha lenne egy rom tolto extension,
akkor barkibarmikor barmilyen romjat, romjait kidobhatna az ember epromjaibol/ epromhelyeirol,
kivetel termeszetesen az exdost- ha nem akarn magnorol betolteni a rom tolto extensiont es az exdos.rom -ot,
szal exdoson kivul minden purgalhato,
floppyrol toltheto lenne a romtolto extension, es utana egybol toltheto lenne az ide.rom,
utana mar WINYOROL tok gyorsan toltheto lenne tetszoleges szamu rom file ( epdos, asmon, akarmi ), es tobbe bovito programra nem is lenne szukseg,
csak a .rom verziokra.
igaz ?
man milyen kircsi lenne, mint egy PC- nel az OS, vagy a driverek, winyorol ( floppyrol vagy magnorol is, csak winyorol gyorsabban ) toltodnenek be a rendszerkomponensek ... kiraaaly ! nem ?
-
atneztem az ep128 utils reszleget, de nem talaltam olyan cuccot, ami boviteskent tartalmazna a
:lrom
parancsot.
Zozo, nem lehet, hogy az EPDOS forrasbol kidobni a tobbit, es az epdos lrom implementaciobol bovitest csinalni neked egyszeru ?
-
vagy vegulis az is jo lenne, ha az epdos 1.9 - bol csinalna valaki bovitos varziot.
rom -bol bovitest csinalni nehez ?
-
FDISK 0.8, IDE mellett SD-t is kezel már, más egyéb még változatlan.
Lacika! A leírásból (http://ep128.hu/Ep_Util/FDISK.htm), ezt a mondatot törölni kéne: "de futtatásához EPDOS 1.x is szükséges! (Az SL, SS parancsokat használja.) HDD használata esetén célszerű az 1.9-es verziót választani."
Ez a demó verziójú futásra vonatkozott, ami vinyó hiányában fájlokkal szimulálta a szükséges adatokat, akkor amikor még nem volt IDE emuláció az ep128emu-ban, de mivel már régóta van, ez így tárgytalan, a 0.8-ból töröltem is ezt a részt.
-
Megtörtént!
-
FDISK 0.9:
-Javítva a hiba, hogy már létező partíción is elfogadta a C gombot
-Extended partíció listázás bővítve, már a szabad helyeket is kijelzi, és üres partíciótól sem akad már ki :-)
-Extended listán belül CTRL+L átvált egy részletes nézetre, ahol minden paraméter látható. CTRL+N vált vissza a normál nézetre. A bővített listában látható a típusbájt (TYPE), 00 jelenti a szabad területet. EBR jelenti az adott területre mutató Extended Boot Record (Bővített boot bejegyzés) szektorcímét. Mögötte perjellel az, hogy az EBR hanyadik bejegyzése mutat az adott területre. Ez normál partíció esetén 1, szabad terület esetén 0 vagy 2. 0 azt jelenti, hogy az adott EBR nem létezik, címe számított az EBR láncban lévő "luk"-ból. 2 esetén az EBR blokk nem mutat normál partícióra, hanem egyből a következő EBR blokkra, ami elött kihagyott terület van. START/SIZE/LAST értelemszerű.
-lehet törölni külön-külön partíciókat az Extended-en belül, CTRL+DEL-t nyomva az adott partíción
-Lehet már partíciót létrehozni Extended partíción belül, szabad helyet tartalmazó soron kell C gombot nyomni, utána a kérdésekre válaszolni, hasonlóan a normál (Primary) particiók esetén.
Egy üres vinyó/SD kártya EP-hez elsőként létre kell hozni egy jó nagy extended partíciót (5-ös típusbájtot megadva), majd pedig azon belül a szabad területen C-t nyomni, majd minden kérdésre ENTER-t, ezt ismételni amennyi meghajtót csak akarunk :-) Utána hideg reset, és megformázni őket EXDOS FORMAT paranccsal.
1.0-ban jön majd a beépített gyorsformázás :-)
[ATTACH=1]
[ATTACH=2]
[ATTACH=3]
[ATTACH=4]
Végszóként: én el nem tudom mondani, mennyire gyűlölöm ezt az egész elizélt Extended partíció dolgot! :evil:
Szerintem valami vállalati bulin jól berúgva találták ki a Microsoft programozói...
A fő partíciós táblában (MBR) van ugye 4 bejegyzés, ami egy idő után kevés lett amikor elhagyták a 128 megát a vinyó méretek...
Az odáig ok, hogy akkor tegyünk be egy olyan elemet, ami mutat egy következő táblára (ez lett az EBR), ahol újabb bejegyzés van.
Itt már a 4 bejegyzésből csak kettő van használva, az első mutat az adat partícióra (PC-s szóhasználattal logikai meghajtó), és általában(!) a második a következő EBR blokkra.
Egy partíciós bejegyzésben meg van adva, hogy hol kezdődik az adott terület és a mérete.
Na de ez meg van bonyolítva, mert az EBR blokkokban nem ám a vinyó elejétől számolnak, ahogy az normális lenne!
Helyette az EBR-től...
Na de ez se egységes!
Ha adat partícióról van szó, akkor a konkrétan az adott területre mutató EBR-től számolunk. Ha a következő EBR-re mutató bejegyzésről, akkor pedig a lánc legelső EBR-jétől...
A dolgot még bonyolítja a szabad területek kérdése, ilyen területet 4 féle módon lehet felfedezni:
-teljesen üres EBR, ami a Extended partíció vége elött van
-EBR csak adat partíció bejegyzéssel, amelynek a vége az Extended vége elött van
-EBR csak következő EBR-re mutató bejegyzéssel, amely előtt kihagyott területt van
-EBR adat és EBR-re mutató bejegyzésekkel, azonban az adat partíció vége és a következő EBR kezdete elött kihagyott terület van
Érdeklődők megnézhetik az EXTENDED szubrutint a programban, mennyi gusztustalan elágazást kellett beépíteni mindennek a lekezelésére...
-
Hm... Részemről sík hülye vagyok mind ehhez, de miért erőltetjük annyira ezt az Extended dolgot...? Már PC -n is utáltam, soha az életbe nem hoztam létre magamnak, ha csak egy mód volt rá! Minden rendszeremet (de a nem rendszer partíciókat is) primary -re tettem folyamatosan! :-) (Jó, tudom, abból csak 4 lehet... :-P )
-
Hogyan csinálsz 4-nél több (4x32M=128M) partíciót nélküle az EXDOS-nak?
Egyébként én is utálom, de az már egy több éves tartozás volt :oops:
-
Igen, lentebb az elküldés utáni pillanatban hozzá is biggyesztettem zárójelben, hogy "ja, abból csak 4 lehet"... :-D Más mentsége nincs a létezésre! :evil: (Tudom, hogy Te jót akarsz vele, nem Téged szapullak! ;-) )
-
Az ötlet egyébként nem rossz, csak mondjuk az Intelligent Software csapatára kellett volna bízni a dolgot :-) Az EXOS/EXDOS tele van csomó tök logikus, szépen megvalósított listás/mutatós adatszerkezettel.
-
Nem mintha ertenek hozza, de a GPT (GUID Partition table) az vmi ujabb, alternativ es talan (?) jobb megoldas, mas OS-ek, EIF is tamogatjak manapsag, nem lenne erdemes azt is megvizsgalni? Nem tudom,abban van-e ilyen megkotes, hogy max 4 particio (aminek "workaround"-olasa ez az extended particio dolog mar eleve). Masreszt, gondolom, ha valaki eleg bator, csinalhat sajat szabvanyt is :) max pc-re kotve a disk-et nem lehet olvasni, pl IDEDOS (C64-re) meg sajat filerendszert is csinaltak, aminek koze nincs a FAT-hez. Bar teny, hogy ez utobbi azert csunyan kepes rontani a kompatibilitast ha PC-re kene kotni :) Bar Linux ala talan van hozza fuse (filesystem in userspace, nem a zx spectrum emulator itt a 'fuse' ...) modul.
GPT-ben ha jol remlik 128 (?) particio lehet mindenefele nagyobb trukk nelkul (mint az extended particio ganyolas az MBR-nel, ilyesmi ott nem kell).
-
Nincs értelme, GPT csak a 2TB feletti vinyókhoz kell. Mert az alap MBR-ben csak 32 bites szektor címek vannak, és az csak 2 terráig elég. Amúgy belül ugyanazok vannak.
És PC-n is csak 64 bites oprendszer alatt működik (legalábbis Windows fronton).
Nekünk 8 biten a 2TB is bőven elég :-D
Amúgy itt is visszaüt az, hogy a Microsoft a saját szabványait se tartotta be. Ha nem felejtették volna el kezelni a szektor méret mezőt a boot szektorban, nem kéne ilyenekkel vacakolni...
-
Nincs értelme, GPT csak a 2TB feletti vinyókhoz kell.
Ez azonban nem azt jelenti, hogy nem lehet kisebb hdd-hez is hasznalni, nem? :) En nem is a meretlimitacio miatt jegyeztem meg, hanem mert egyszeruen (-bben) (vagy nem ...) lehet tobb particiot letrehozni, mindenfele extra ganyolas (=extended particio) nelkul. Meg amugy is, ugy tunik, lassan majd eltunik az MBR (haha, lassan lesz az, lasd pl IPv6 vs IPv4 ...) mert mindenki az EFI-t akarja nyomatni az oskorszak BIOS (=valos modban stb fut, kb XT-nek nezve a gepet ...) helyett.
-
FDISK version 0.B
IDE és SD mellett kezeli a EPNET-en lévő CF-et, és az SF3 USB meghajtóját is.
+kisebb hibajavítások.
Most már tényleg az 1.0 jön, ami egyből meg is tudja formázni a létrehozott partíciókat :ds_icon_cheesygrin:
Különös tekintettel arra, hogy még nem tudunk EP-n FAT16-ot formázni :oops:
[attach=1][attach=2]
[attach=3][attach=4]