Bocsánat, ezt a rom.bin -t mivel tudom kicsomagolni?

Köszi

[ Guests cannot view attachments ]

Most már grafikus felületen konfigurálható az SD kártya emuláció, és lehetőség van tömörített formátumú snapshot és demo file-ok mentésére (ez a "Machine configuration" ablakban engedélyezhető, de a Ctrl+F9-el készített "quick snapshot"-ra nincs hatása). A tömörítő sebességét sikerült többé-kevésbé elfogadhatóra javítani, összehasonlításképpen a Total Eclipse demo elejéről készült snapshot mérete:
  166082 byte - az emulátorral mentve (Alt+S)
  525131 byte - ugyanez kicsomagolva
  166023 byte - újra tömörítve a parancssoros epcompress-el, hasonló paraméterekkel (-blocksize 65536 -maxoffs 65536)
  163585 byte - parancssoros epcompress, maximális tömörítés (-raw -9 -maxoffs 262144)
  167285 byte - gzip formátum 7za-val (parancssoros 7-Zip) létrehozva, ez kisebb file-t készít mint az eredeti gzip és zip programok

Kártya (azaz jelenesetben VHD) cseréhez, ezeket az infókat kaptam a hardver tervezőjétől:

A kártya detektálásának lépései:

1. kártyacsere ellenőrzése

2. ha volt kártyacsere, akkor az inicializáló rutin meghívása -> ez már jelzi, hogy van-e működőképes kártya az adott foglalatban

3. inicializálás után lehet hívni a blokkszám lekérdezését


Az SD kártyákat mindig inicializálni kell behelyezés után, addig semmilyen művelet nem végezhető velük. A 2 foglalat INSERT és DISKCHNG jeleit közösítettem, mert a CPLD-ben már fogytán voltak az erőforrások. Így, ha bármelyik kártyát kiveszik vagy újat tesznek be, a DISKCHNG bit aktiválódik (sajnos mind kivételre, mind pedig behelyezésre aktiválódik a bit, ezzel nincs mit tenni). Az inicializáló rutin az összes foglalatban lévő kártyát újrainicializálja, függetlenül, hogy ott nem is volt változás. Ezt érdemes figyelembe venned, ha az a terved, hogy az 1Hz-es megszakításból figyeled a kártyacseréket.

A jelenlegi SDEXT verzió még nem foglalkozik vele Így kártya csere után Not ready lesz, mivel nem lett inicializálva a kártya.
Ennek az emulációja még hiányzik. (Azaz, hogy csere után várjon az inicializálásra.)
Ha ez is meglesz, akkor már az új ep128emu segítségével készülhet a következő SDEXT

Ez megoldható lenne, bár a file méret ellenőrzésnek az is a célja, hogy ne lehessen nem ROM file-t betölteni.

Esetleg legyen egy figyelmeztető kérdés, hogy tényleg akarod-e
Alapvetően régen EP-n úgy tároltam a ROM fájlokat, hogy olyan hosszú amennyi kód van benne. Most is pl az SDEXT04 az csak 5289 bájt amit fel kellett kerekíteni 64K-ra, hogy elfogadja.

talán a flash emuláció helyett elég lenne a korábbi megoldás ami csak a 7-es szegmenst lapozza és nem írható?

Végülis emulátoron a fájlok frissítésével/konfigurálásával meg lehet oldani a ROM frissítést, flash emuláció már csak flashelő program fejlesztéshez érdekes. De az megoldható Xep128 alatt is.

Itt pontosan mit is kell tenni az emulátornak?

Az írás/olvasás parancsok Not ready-t adnak vissza (sd_wait_ready), amíg nincs inicializálva (sd_init) a kártya (típustól függően CMD1 vagy CMD41 parancs).

Itt pontosan mit is kell tenni az emulátornak? Az Xep128 forráskód szerint ez olvasható az 1-es regiszteren, és ennek az írásakor az 5. bit beállítása törli a lemezcserét:

case 1: // status reg: bit7=wp1, bit6=insert, bit5=changed
                   (insert/changed=1: some of the cards not inserted or changed)

Nos, a Xep128-ban valojaban tenyleg nincs olyan, hogy "nem inicializalt a kartya". Elfogadja azokat a parancsokat, amit ilyenkor szokas csinalni, de ezek hianyaban is mukodne, ami mondjuk persze sajna nem egyezik a valosaggal, de "fix" SD image eseten ez elvileg tul sok vizet nem zavar, ha az SDEXT amugy is tutira megcsinalja, akkor valodi gepen is megy. Az mas kerdes, hogy "hot swap" eseten persze jo, ha ez is tesztelheto ...

A 9-es parancsnál hiányzik még a lemez méretének a lekérdezése, ezt ugyan VHD megnyitásakor az emulátor kiszámítja, de jelenleg nem olvasható.

Marmint ez Xep128-ban - elvileg - benne van. Vagy ugy ertetted, hogy ep128emu-ban nincs? _size_calc() fuggveny modositja a _read_csd_answer tombot, amit a 9-es parancs visszaad aztan. A fenti fuggveny a sdext_check_and_set_size()-bol van hivva. Hmm ... ha minden igaz Arra persze nem eskudnek meg, hogy ez igy tuti jo most, ahogy van. Ha jol remlik Zozo tesztelte (meg o is kerte ezt), es par probalkozas utan jonak tunt szerinte. *Ha* jol emlekszem Ami megmaradt az az, hogy nagyokat karomkodtam magamban, hogy milyen pepecs munka a CSD valaszt atirni, meg az egesz meret dolgot csinalni

Most már lehetőség van snapshot mentésre is, de ez csak az SRAM és flash ROM tartalmát tárolja és a ROM lapozóregisztert, illetve hogy a hardver engedélyezett-e.

Az jo Xep128-ba beletettem *nemi* igazan nem tul pontos ep128emu snapshot loading-ot meg anno, de a fo problemam mindig az volt, hogy WD/disk support-ot lusta voltam csinalni, SD-t meg az ep128emu nem tudott, ez nemikepp rontott a hasznalhatosagon

Amugy szerintem a Xep128-al nem is nagyon fogok tobbet foglalkozni, nincs ertelme, az ep128emu kvazi mindenben jobb, most meg mar biztosan, mert ugye eddig volt par elonye azert a Xep128-nak (SD kartya, eger ...). Igazabol a letrejottet is az az igeny szulte, hogy kellett nekem par dolog, de az ep128emu es foleg a C++ dolgokhoz kozom nincs (marmint, hogy abba irtam volna bele, sajat emulator helyett).

de a fo problemam mindig az volt, hogy WD/disk support-ot lusta voltam csinalni,

Mire megcsinálom neked, hogy ne fagyjon le az EXDOS WD nélkül, már nem is érdekel?

eddig volt par elonye azert a Xep128-nak (SD kartya, eger ...).

Z180? Elöbb-utóbb aktuális lesz

A nem használt bitek 1-esek

Ez biztosan így van? Az eddigi & 0xE0-al működik, viszont | 0x1F-re módosítva a ROM nem találja az F: után a többi logikai meghajtót. De máshol is lehet a hiba.

Szerk.: a ROM csomag már nem aktuális, mivel az EXDOS frissült, ezért egyelőre töröltem, hamarosan újat készítek.