Enterprise Forever

:HUN => Programozás => Topic started by: Zozosoft on 2006.May.16. 00:37:25

Title: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.16. 00:37:25
Code: [Select]

  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

:-)
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.16. 13:39:38
Quote from: "Povi"
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 :) )
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.17. 20:13:23
Kicsit tovább fejlesztve :-)
Code: [Select]
 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
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.18. 22:09:26
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)
Title: Re: EP-s FDISK fejlesztése
Post by: MrPrise on 2006.May.18. 22:35:05
Quote from: "Zozosoft"
Már ilyet is tudunk :-)

Hú, de izgalmasan néz ki! :-) Hajrá!
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2006.May.19. 00:51:30
Nagyon klassz!!!! Grat!
Title: Re: EP-s FDISK fejlesztése
Post by: geco on 2006.May.19. 02:24:14
szimpatikus, amit a képernyõn látok.:)
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.22. 23:07:52
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 :-) )
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.24. 22:18:10
Lassan kezd valahogy kinézni is :-)
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2006.May.24. 23:51:32
Csodálatos! :-)  GRATULA! (Hátha itt reagálsz is...  :-D)
A BigDos -on mit is értünk egyébként...?
Title: Re: EP-s FDISK fejlesztése
Post by: MrPrise on 2006.May.25. 08:25:08
Quote from: "Zozosoft"
Lassan kezd valahogy kinézni is :-)

Szép színes! :-D
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.25. 10:18:10
Quote from: "Ep128"
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...
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2006.May.25. 11:55:31
És 16 bites logikai szektorcímzésû FAT16 partitiot mikor fogunk használni? :)
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.25. 12:30:22
Quote from: "gafz"
É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.
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2006.May.25. 13:01:30
Kézzelfogható hardware mikor lehet belõle?
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.25. 14:01:00
Quote from: "gafz"
Kézzelfogható hardware mikor lehet belõle?

Tigriant kell kérdezni :-)
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.26. 16:16:20
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...)
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2006.May.27. 20:19:54
Quote from: "Zozosoft"
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...
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2006.May.28. 00:48:18
Zozo által tanultunk valami alapvetõt... :-)
(Köszi!)
Már nem lep meg, hogy ennyire túlkomplikálták ezt (is)...
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.02. 00:17:31
Mivel most már aktuális a téma, így kezdetnek kiszedtem az általános szoftverfejlesztõs topicból az elõzményeket :-)
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2008.March.02. 00:29:40
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.
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2008.March.02. 00:45:09
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:
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.02. 00:45:59
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.
Quote
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!
Quote
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
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.02. 00:48:38
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)
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2008.March.02. 00:59:46
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:
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.02. 01:02:12
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 :-(
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.02. 01:09:05
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 :-)
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2008.March.02. 01:16:19
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.02. 01:22:46
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 :-)
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2008.March.02. 01:50:52
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' ...
Title: Re: EP-s FDISK fejlesztése
Post by: gafz on 2008.March.02. 01:53:29
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...
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2008.March.02. 13:02:25
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...
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.03. 19:48:58
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.03. 22:06:29
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 :-)

Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2008.March.04. 00:22:32
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 :-)
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.June.30. 00:47:14
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.

Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.June.30. 13:48:48
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ú...


Quote
Ú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"?
Title: Re: EP-s IDE ROM fejlesztése
Post by: IstvanV on 2009.June.30. 18:18:29
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.
Title: Re: EP-s IDE ROM fejlesztése
Post by: IstvanV on 2009.June.30. 18:35:11
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:

Code: ZiLOG Z80 Assembler
  1. RDCIKS:         PUSH BC
  2.                 EXX
  3.                 LD B,0
  4.                 LD C,(IX+COMB)
  5.                 EXX
  6.                 LD C,(IX+DLB)
  7.                 LD A,RD+DATA
  8.                 EX AF,AF'
  9.                 LD A,RD+WR+DATA
  10.                 EXX
  11. RDCIK:          EX AF,AF'
  12.                 OUT (C),A
  13.                 EX AF,AF'
  14.                 OUT (C),A
  15.                 EXX
  16.                 INI
  17.                 INC C
  18.                 INI
  19.                 DEC C
  20.                 EXX
  21.                 DJNZ RDCIK
  22.                 EXX
  23.                 CALL ERRORKERD
  24.                 POP BC

Code: ZiLOG Z80 Assembler
  1. RDCIKS:         PUSH BC
  2.                 LD B, 0
  3.                 LD A, (IX+DLB)
  4.                 EXX
  5.                 PUSH BC
  6.                 PUSH DE
  7.                 LD B, 2
  8.                 LD C, (IX+COMB)
  9.                 LD DE, (RD+DATA)*257+WR
  10. RDCIK:          OUT (C), D
  11.                 OUT (C), E
  12.                 EXX
  13.                 LD C, A
  14.                 INI
  15.                 INC C
  16.                 INI
  17.                 EXX
  18.                 OUT (C), D
  19.                 OUT (C), E
  20.                 EXX
  21.                 LD C, A
  22.                 INI
  23.                 INC C
  24.                 INI
  25.                 EXX
  26.                 JP NZ, RDCIK
  27.                 DJNZ RDCIK
  28.                 POP DE
  29.                 POP BC
  30.                 EXX
  31.                 CALL ERRORKERD
  32.                 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.
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2009.June.30. 20:48:11
A türelmeteket eszelõsen irigylem!  ;-) Mikre rá nem jöttök már, õrület!  :lol:
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.June.30. 22:15:21
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 :-)
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.01. 16:29:40
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.
Title: Re: EP-s IDE ROM fejlesztése
Post by: Ep128 on 2009.July.01. 18:49:00
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
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.01. 20:10:07
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2009.July.02. 00:09:03
Tök jó, hogy Te miket tudsz a múltból (is)...  :)
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.02. 12:03:40
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.
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.02. 13:28:41
FreeDOS 1.0: nincs semmilyen vacakolás!

Lassan jöhet a Windowsok tesztelése, csak az macerásabb, nem elég egy boot floppy...
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.02. 15:35:17
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 :-) )
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.02. 20:29:01
Más is rájött (http://medical.nema.org/dicom/2007/07_12pu.doc), hogy a Microsoft programozók hülyék:
Quote
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.
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.02. 22:40:24
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...
Title: Re: EP-s FDISK fejlesztése
Post by: IstvanV on 2009.July.03. 19:06:48
Egy lehetséges probléma:

Code: ZiLOG Z80 Assembler
  1.                 LD B,0
  2. DCIK:           LD A,RD+DATA
  3.                 CW
  4.                 DLR
  5.                 LD (HL),A
  6.                 INC HL
  7.                 DHR
  8.                 LD (HL),A
  9.                 INC HL
  10.                 DJNZ DCIK
  11.                 EI
  12.                 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 :?:
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.04. 00:17:17
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...
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.04. 13:42:50
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 :-)
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.04. 22:30:46
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.July.05. 09:06:07
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...
Title: Re: EP-s IDE ROM fejlesztése
Post by: IstvanV on 2009.July.09. 17:13:40
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 ?
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.09. 22:56:30
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...
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.10. 20:48:37
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.
Title: Re: EP-s IDE ROM fejlesztése
Post by: IstvanV on 2009.July.14. 14:33:08
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ó ?
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.15. 23:57:20
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:
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.16. 21:32:57
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:
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.19. 01:03:15
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:
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.23. 21:39:37
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ó :-)
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.July.27. 22:49:03
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 :-)
Title: Re: EP-s IDE ROM fejlesztése
Post by: IstvanV on 2009.July.28. 15:33:34
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 :)
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.July.28. 22:18:58
Ú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.
Title: Re: EP-s IDE ROM fejlesztése
Post by: IstvanV on 2009.July.28. 22:54:25
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:
Code: [Select]
>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:
Code: [Select]
>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
Title: Re: EP-s FDISK fejlesztése
Post by: IstvanV on 2009.July.29. 15:44:16
Ú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.
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.July.29. 15:46:56
Ú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!
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.July.30. 11:10:32
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.July.30. 11:24:32
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:
Title: Re: EP-s FDISK fejlesztése
Post by: MrPrise on 2009.July.30. 12:41:08
Ez a módszer a Microsofttól lett átvéve  :ds_icon_cheesygrin:
:smt082
Title: Re: EP-s FDISK fejlesztése
Post by: szipucsu on 2009.July.30. 12:56:08
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.July.30. 14:34:34
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...
Title: Re: EP-s FDISK fejlesztése
Post by: IstvanV on 2009.July.30. 15:11:09
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 :?:
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.July.31. 22:38:19
ZozoTools javítás ? :)
Javítva  :oops:
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.July.31. 23:17:36
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:
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.August.09. 08:40:17
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.August.09. 08:50:56
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.August.09. 19:05:59
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...
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.August.09. 19:21:26
Végre egy béta teszter aki nem lustálkodik, hanem tesztel :-)
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.August.09. 20:03:03
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)
Title: Re: EP-s FDISK fejlesztése
Post by: IstvanV on 2009.August.10. 11:56:23
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:
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.August.10. 21:20:06
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.August.10. 21:36:46
ISDOS probléma megoldva: csak gyökérkönvtárból működik...  :oops:
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.August.10. 22:21:54
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...
Title: Re: EP-s FDISK fejlesztése
Post by: IstvanV on 2009.August.25. 22:47:56
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:
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.August.26. 07:05:59
Igen, még a törlés (DELETE) is rizikós.
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.December.19. 19:50:23
Ú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:
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 20:00:22
nade ezt be kene tegyem az epromba, nem ?

vagy van valami szuper tool amivel felul lehet irni az- epben az eprom tartalmat ? vagy mi ?

Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.December.19. 20:05:28
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: )
Title: Re: EP-s IDE ROM fejlesztése
Post by: Lacika on 2009.December.19. 20:08:36
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 20:09:46
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 ...

Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2009.December.19. 20:11:21
Megnéztem: az előzőben is benne van ez a hiba.
Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.December.19. 20:15:51
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:
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 21:08:14

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


Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.December.19. 21:18:39
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ó.
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 21:30:54

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



Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 21:40:15

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.

Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 21:51:46

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



Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.December.19. 21:54:14
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 21:58:19
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 ?

Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.December.19. 22:09:30
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 :-)
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 22:15:00
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 ?


Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 22:21:24
aaaaaaaa, hulyeseg ... hat az nem fogja megoldani a ciklikussagot ...

hagyjuk ...

Title: Re: EP-s IDE ROM fejlesztése
Post by: Zozosoft on 2009.December.19. 22:25:52
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!
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 22:54:50

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.



Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 23:00:53

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

Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 23:08:01
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 ?


Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 23:16:55

Na jo, vili, azer 19, mer az egy 1.8+winyo, de az EPDOS -bol sosem volt bovitos verzio, csak rom ?

Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2009.December.19. 23:21:33
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 23:22:25
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.

Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.19. 23:54:18
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 ?


Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.20. 20:17:40

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 ?

Title: Re: EP-s FDISK fejlesztése
Post by: Z80System on 2009.December.20. 20:21:09
vagy vegulis az is jo lenne, ha az epdos 1.9 - bol csinalna valaki bovitos varziot.

rom -bol bovitest csinalni nehez ?

Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2014.December.22. 10:15:24
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.
Title: Re: EP-s FDISK fejlesztése
Post by: Lacika on 2014.December.22. 21:25:28
Megtörtént!
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2015.January.03. 17:53:34
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...
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2015.January.03. 23:20:55
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 )
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2015.January.03. 23:23:34
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:
Title: Re: EP-s FDISK fejlesztése
Post by: Ep128 on 2015.January.03. 23:27:39
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! ;-) )
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2015.January.03. 23:33:25
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.
Title: Re: EP-s FDISK fejlesztése
Post by: lgb on 2015.April.20. 08:53:50
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).
Title: Re: EP-s FDISK fejlesztése
Post by: Zozosoft on 2015.April.20. 09:04:38
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...
Title: Re: EP-s FDISK fejlesztése
Post by: lgb on 2015.April.20. 09:35:43
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.